投稿日:

WordBench神戸「レスポンシブデザインやるなら座談会」にて LT をさせて頂きました。


WordBench神戸

2012年8月26日(日)の、WordPress神戸の番外編勉強会、『レスポンシブデザインやるなら座談会』にて、『簡単!低コスト!楽しい!レスポンシブ デザイン ディレクション』という内容でライトニングトークをさせて頂きました。

以下に、その時のスライド資料を公開いたします。

簡単!低コスト!楽しい!レスポンシブ デザイン ディレクション from Yuji Nojima

低コスト案件においてレスポンシブWebデザインに取り組むときの、考え方、取り組み方などについて、ひとつの考えをまとめています。内容的には少し偏りがありますが、小規模かつ低予算な案件でのディレクションの一つの在り方として、参考になればと思ってのお話をさせて頂きました。

LTの後のディスカッションもまた大変興味深いお話をさせていただき、大変参考になり、刺激になりました。ありがとうございました。

LT発表

  • [LT] 制作の工数を下げるために、始めに打ち合わせておくべきこと
    @khoshino(星野さん)
  • [LT] 簡単!低コスト!楽しい!レスポンシブ・デザイン・ディレクション
    @yuka2py(野島さん)
  • [LT] WordPressレスポンシブデザイン実践困った集
    @nukaga(額賀さん)

ディスカッションのトピック候補

  • そもそもレスポンシブデザインは必要か?否か?
    • どんなケースで、どんなカタチで有用か?
    • レスポンシブ要らないコンテンツってどんなの?
    • Googleもレスポンシブ推奨?ほんとうかな?
  • レスポンシブデザインは「難易度が高い」「1つ作るよりコスト高」は本当か?
    • 考え方次第で逆転もあるかも?
    • レスポンシブデザインの目的別ディレクション
    • 低コスト優先の場合
    • 多デバイス対応優先の場合
  • レスポンシブ向きのデザインってどんなの?
    • レスポンシブ向きのデザイン。ちょっと厳しいデザイン。
    • 低コストなレスポンシブデザインとはどんなの?
  • レスポンシブ向きのお客さま、向かないお客さま
  • レスポンシブデザインの効果的なお客さまへの説明方法とは?
  • コスト高にならない、レスポンシブデザインの採用方針とは?

感想

レスポンシブWebデザインと言っても、それは単なる手段の一つにしか過ぎません。ですので、実際の案件では多くの課題に直面する場面があるようです。その中で、トラブルや事故を避けるために必要なこととして「クライアントとの風通しの良さ」という言葉が印象に残りました。

幸い、私はこれまで、クライアント担当者との直接お仕事をさせていただく機会が多かったのですが、確かに、営業やディレクターさん、プランナーさん等が間に入る時に、その人々がレスポンシブの制約や課題についての知識を整理できていなかったら、クライアントとの意思疎通が滞ってトラブルに繋がるケースが出てくるように思います。

今回のような勉強会に多くの方が興味を持って集まって頂けることからも、レスポンシブルなWebサイトは「これから」な手法かと思います。その中で、担当者の認識の誤りや知識不足によるトラブルが今後しばらくは続くことかと思いますが、それだけに、制作サイド…つまり、レスポンシブWebデザインの理解を進めた担当者と、クライアント様との「風通しの良さ」は、現実的な意味において、今は大切なんだろうな、と感じました。

投稿日:

Webデザインとポインティングデバイスの精度


最近、いわゆる普通の Web サイトを作る時にもレスポンシブルであることを考えてしまいます。…うん、いや、もう少し正確に表現すると「スマートフォンやタブレット、またPC環境などの多様なデバイスにおけるUIの利便性」について考えてしまいます。

個人的には、レスポンシブルなWebデザインは万能では無いと思っていますし、特に低コストなサイトでの「ワリとしっかりとした RWD」はむしろ不要と考えています。「PCスタイルのサイトで十分だよね」という感じ。

ただ、これだけスマートフォンが急速に普及した現在、それでも検討が必要なのは、「スマートフォン環境でもストレス無く操作できる UI」だとも思っています。分かりやすい例を言うと、縦に並んだテキストリンクが line-height: 1.4em とかだと、スマートフォンなどのタッチデバイスで正しくリンクをクリックするのはちょっとしたコツが居るわけですね。

これは「画面の広さ」ではなく、「ポインティングデバイスの精度」が問題なわけです。

今のいわゆるレスポンシブルな Web デザインは、主に画面の広さを基準としたものになっていると思っていますが、Windows 8 などが普及して、PC画面でもタッチインターフェースが一般化した時にはどうなんだろうな、と思います。

それで、ポインティングデバイスの精度で css を切り替えたりできないかな?と考えて少し検索してみたら、Javascrip ではありますが、次のコード片を見つけました。

でも、これは厳密にはポインティングデバイスの精度(例えばペンタブレットだと?)でも無いですし、そもそもタッチデバイスかどうかの判定には使えなさそうにも思います。なかなか難しそうです。

どなたか、良い方法やアイデアをご存知でしたら教えてください!

§

ここまで書いて来てアレなのですが、仮にタッチデバイスで操作されているかどうかを判定できたとしても、今度はそれをデザインにどのように動的にフィードバックするのか?というのは、その次にある大きな課題です。上に挙げた例への回答として、単純に line-height:2.5em; としたとして、それがデザイン的に適当なのかというと、それはまた別問題です。

ただ、こういった手法が在ればそれを使えることは Web 制作上の一つの道具になりえますし、レスポンシブルでない Web サイトを多様なデバイスからのアクセスに対して適応させる一つのアプローチになるのではないかな、と思ったりしています。

投稿日:

PHPFog と WordPress とファイル管理


[追記] 下記の方法より良い方法がありましたのでPHPFog/AppFog と WordPress とファイル管理 にて、紹介しています。

WordPress はその管理画面からサイト自体に様々なカスタマイズが行えることが特徴であり、強みです。それらのアップデートにおいては、主に wp-contents 内に必要なファイルがダウンロードされて追加されます。PHP Fog や DotCloud などの環境上に WordPress をデプロイしてもこれは同様なのですが、実はちょっと困ったことがあります。

問題

PHP Fog では、初期にデプロイされた後、WordPress の管理画面で行った変更については、git clone でも pull でも取得できないのです(わたしが知る限りなので、どなたか良い方法を知ってたら教えてください)。つまり、WordPress の管理画面から行った変更は、Git の管理下に無い、ということなのでしょうね。まあ、当たり前と言えば、当たり前なのですが、それを PHP Fog 上の master に commit する手段を、私はとうとう見つけることができませんでした。

解決策

管理画面からの変更は git clone でも pull でも取得できないのであれば、別の方法で取得するしかありません。とてもスマートとは言い難いのですが、私は  navphp というファイルエクスプローラをサーバー上に配置することで解決しました。手順は至って簡単でした。

navphp の設置方法

  1. navphp をダウンロード
  2. PHP Fog から git clone したリポジトリのルートに、navphp の zip を展開して配置
  3. navphp の、config.php を開き、$user と $passwd を自分用に設定

navphp でファイルを取得し、ローカルの WordPress データを最新にする

  1. navphp の管理画面にログインする。
  2. ファイルの一覧が表示されるので、WordPress 上の必要なリソースをダウンロードする
    • ダウンロードは、ファイル名/フォルダ名部分をクリックする
    • フォルダは zip されてダウンロードされるので、ダウンロード後に zip を解凍す る
  3. ダウンロードしたファイルで、ローカルのリポジトリを上書きする

 

以上の手順で、何か管理画面で変更を行った際には、手元のデータを最新にして、関連した変更をローカルリポジトリで行っていくことができます。例えば、管理画面でテーマをインストールし、その子テーマを作りたいときには、手元に親テーマのデータを持ってないと困ると思いまし、いずれにせよ、手元のリポジトリが最新で無いというのは、なんというか不安なものですね。

なお、この方法は dotCloud などの同じような課題のある PaaS 環境でも同じようにできる筈です。

 

投稿日:

PHP Fog の WordPress の日本語化


WordPress の検証には PHP Fog さんのサービスを利用させて頂いています。簡単に扱えて、WordPress セットアップもボタンを押すだけの2ステップ程度。かつ「無料」です。ボタン一つでサイトを破棄して、そしてまた簡単に新しくサイトを作ることも出来ます。検証用にはうってつけです。

その PHP Fog でセットアップした WordPress ですが、困った事に英語環境になっています。しばらくは気にせず使っていましたが、勉強会などのスライドに載せるスクリーンキャプチャが英語版の画面なのは、なんと無く切ない…。そこで、日本語化をやってみました。

手順は、Gitを使っている方だったら、非常に簡単で、以下の通りです。環境は WordPress 3.4.1です。

§

1. PHP Fog の App Console から、Git で clone する URL を拾ってくる。↓写真の赤枠のところです。

2. ローカルのファイルを置きたい場所に移動して、git clone でローカルにリポジトリを作ります。

3. ローカルリポジトリのディレクトリがアプリケーション名で作成されるので、その中に移動します。移動した先がそのままアプリケーションのルートディレクトリで、また WordPress のファイルも配置されています。

4. wp-config.php を開いて、WPLANG の定数定義を ja に変更します。

5. 次に、日本語のリソースファイルをダウンロードします。wp-content の中に languages フォルダを作成して、その中へ移動します。

6. WordPress の日本語リソースファイルを、WordPress の ja リポジトリから落としてきます。ちなみに、私が確認したときは、3.4.x 用のリソースが見当たらなかったので、とりあえず 3.3 用を使いました。

7. アプリケーションのルートディレクトリに上って、ファイルの追加と変更を Git にコミットし、最後に push します。

以上のような流れです。ネット上で「上手く出来ない」的な記事も見られますが、とりあえず私は問題無かったですね。いくつかの参照URLでは、落としてくる日本語リソースのファイルが違ってたりしているので、そのせいかも知れません。私はとりあえず、あったものをみんなダウンロードして入れました。