@rriver そうですね、なぜレスポンシブデザインという手法を採用したのか、がもう少し説明されていると良かったなと思いました。新しいから、だけではないと思いますし、設計思想的なものって評価として重要な要素ですので。

— sunami hokuto (@shokuto) May 2, 2012

たしかに、「なぜレスポンシブWebデザインを採用したのか」は、すごく重要な部分ですよね。
ということで、以下にまとめてみました。前回の投稿と同様に、これからレスポンシブWebデザインを導入したいと考えている方の参考になれば幸いです。

僕が携わった大学ウェブサイトのリニューアル・プロジェクトで、レスポンシブWebデザインを選ぶ際に考慮したのは主に以下の4点です。

1. 運営体制・制作環境
2. 複数サイトを運営することの問題点
3. CMSの可能性と課題
4. アクセス端末ごとにコンテンツが違うことの問題点

1. 運営体制・制作環境

レスポンシブWebデザインで制作をする際に必要な条件を、僕は以下のように考えています：

a. フレキシブルな制作体制

デザイナー、コーディング、コンテンツ制作担当が各役割の境界を超えて作業ができ、それぞれの担当が、レスポンシブWebデザインやその根底となる考え方などに精通している必要があります。また、そのためのプロセスを柔軟に調整しながら制作を進められるチーム環境が必要だと思います。

b. プロトタイプで検証できる

制作までの準備に時間を使いすぎず、早い段階でプロトタイプを作ってしまう。そして、そのプロトタイプを検証、修正、改善してファイナルプロダクトまで作り上げるという方法でないと、レイアウト、デザイン、コンテンツが流動的なレスポンシブWebデザインという手法での制作は難しいと思います。ある程度ワイヤーフレームなどで検証してもいいかもしれませんが、それを作ってる時間をプロトタイプを作る時間に当てた方が時間の有効的な使い方だと思います。

c. 細かい部分は任せてもらえる

詳細に関しては制作側に決定権があり、たとえばデスクトップでの表示には承認プロセスを経るとしても、他の端末での表示などは基本的な見え方やユーザビリティ以外については、すべて任せてもらう。任せてもらえるという意思決定者（コンテンツオーナー）との信頼関係、また、意思決定を任せてもらうための事前承認はすごく大切だと思います。

今回のリニューアル・プロジェクトは、 コンテンツ制作、デザイン、コーディングなど、制作全般をほぼすべて内製でできる環境で、少人数のチームで制作ができ、意思決定に関してもスピーディに行える環境で行えました。また、制作フローも以前からスパイラル型に近い方法で行うようになっていたため「プロトタイプ作成 → 検証」を繰り返し行い承認を得るというフローにも慣れていました。また、CMS導入も視野に入れコンテンツをモジュール化したページ制作をすでに行っていたため、ある程度、基盤となるものは揃っていました。

2. 複数サイトを運営することの問題点

現在、いわゆるデスクトップ向けウェブサイトとは別に携帯（ガラケー）向けのウェブサイトを運営しているのですが、2つ運営するサイトがあると単純に更新作業が2倍になるだけでなく、チェック作業も2倍、アクセス解析も2倍といったように、すべてが2倍になります。同じコンテンツを掲載していたとしても、デスクトップ向けのサイトを更新した際に、携帯版のものも更新しなければなりません。更新作業のリソースが分断されるため、クオリティをキープするのが難しくなるだけでなく、単純な更新忘れや更新のタイミングが遅れてしまうなど、運営が煩雑になりがちです。

さらに、僕が運営に携わっている大学ウェブサイトのようにバイリンガルでコンテンツを展開している場合、その作業がさらにその2倍になります。今後、スマホやタブレット端末のみでなく、まだ未知の端末向けにサイトを運営すること、また中国語や韓国語などの他言語展開を考慮すると、それらを複数の別サイトで制作し運営するのは限りなく非現実的です。ワンソースで複数の端末の表示に耐えうるサイトが作れる「レスポンシブWebデザイン」という手法は、リスクを負う価値のある魅力的なものでした。

3. CMSの可能性と課題

CMSには導入のメリットもあると思います。たとえば、

• コンテンツ制作を社内でクラウド化できる
• 更新に関する技術的ハードルが低い
• RSSやソーシャルメディアへの発信が自動化できる
• 震災などの緊急時でも更新できる運営体制を築ける

など。

しかし、CMSの導入や運営は安易に実行できるものではないと思います。ざっと思いつくだけでも、多くの課題や乗り越えるべきハードルがあります。

• 導入初期コストへの投資
• CMS運営コストへの投資
• 設計・構築などの負担
• ページの入れ込み作業などの負担
• マニュアルづくり
• 社内ワークフローの確立と社内教育
• 社内テクニカルサポート

など。

これらの詳細は割愛しますが、上記に一覧したものを見るだけでも、CMSの導入には担当者の相当な覚悟、根気、精神力、実働時間もさながら、かなりの導入期間が必要とされます。そのうえ、費用対効果が得られるのか、また、初期投資を超えるリターンが出るまでどの程度期間が必要かを考えると、よほど大きなメリットがないと導入に踏み切るのは難しいと思います。

さらに、更新の手間はCMSではない方法で運営するのとさほど変わらないのでは?という懸念もあります。複数のデザイン・テンプレートに対応していて、モジュール化されたコンテンツの出し入れがページ単位でコントロールできる高機能なCMSでも、管理や運営はそう簡単にはいかないことが容易に想像できます。

4. アクセス端末ごとにコンテンツが違うことの問題点

まず第一に、ユーザ目線からの問題点から。

現在、僕はiPhone、iPad、MacBook Airを持っていて、それぞれを用途やシチュエーション、気分などによって使い分けています。たとえばeBookはiPadで、ニュースリーダーはiPhoneとiPadで、Photoshopを使ったりコーディングをするのはMacBook Airで、といったように、用途別に使うこともありますが、通勤の際、電車で座れない時はiPhoneでeBookを読んだり、MacBook Airで作ったKeynoteプレゼンをiPadで人に見せたり、一つの端末でやっていたことを、他の端末で引き継いで行うことも多々あります。

複数の端末を使っていると、同じ行為を違うシチュエーションで行うことも自然に起こります。たとえば、デスクトップで見たウェブサイトに、同じ情報を求めてiPhoneやiPadでアクセスすることもあるわけです。

たとえば、

• 家でMacBook Airで見たときはサイトにあった情報が、携帯からアクセスしたら携帯サイトにリダイレクトされてしまって見つからない
• PCサイトへのリンクはあって、クリックしてみた
• しかし、PCサイトは携帯からでは使い勝手が悪く、結局情報を探すのを諦めてしまった

また、その逆で、携帯向けに作られたウェブサイトがデスクトップでは見られなかったり。結構頻繁に残念な思いをします。

今後、端末の種類が増え、利用コンテキスト（文脈）も多様になることを考えると、複数端末に同じコンテンツを提供することがユーザにとって親切な場合も多いのではないかと考えています。

第二に、今度は運営側から考えた問題点ですが、これは「運営の手間 = 人的コスト」です。複数のサイトを持つだけでもメンテナンスは大変なのに、それぞれの端末に最適化された違うコンテンツを常に更新された状態に保つには、相当の「手間 = コスト」がかかります。そのコストを払う余裕があったとしても、そこにリターンが見込めない限り、良い投資とは言えないと思います。

まとめ

最後にとても印象的だった出来事をご紹介します。
このプロジェクトのプロトタイプのデモを行った際、ブラウザのウィンドウサイズを変更して「レスポンシブWebデザイン」を見せた際、「へぇ、すごいね」という反応はありました。が、反応はその程度です。大げさに言ってしまうと、ブラウザのウィンドウサイズを変更して「おぉ～、すげぇ～」と喜んでいるのは制作側だけで、実際にウェブサイトを利用して顧客と接するスタッフにとっては、大切なのは必要な情報が分かりやすく掲載されていることや電話で顧客と話す際のナビゲーションの説明のしやすさだったりするわけです。

技術的な要素は、たとえばインフラを改善して効率化を計ったり、いままで出来なかったことを可能にするという意味で、とても重要です。しかし、そこに固執しすぎて、コンテンツなどの重要な部分をおろそかにしては本末転倒です。何においてもそうですが、重要なのはバランス感覚だと思います。ご紹介したリニューアル・プロジェクトでは、主に上記4つの理由でレスポンシブWEBデザインという手法を採用しましたが、条件や要件によっては、その他の手法がベストな可能性もあります。さまざまな要因を検証したうえで、ユーザにとっても運営側にとっても最適と思われる選択をするのが、ユーザ、サイトオーナー、サイト制作者の3者がハッピーになれる「幸せなウェブサイト」を作る鍵なのではないでしょうか？

これからの「ウェブ」は、未知の端末や未知の方法でアクセスされるようになる。それなのに、いままでのやり方で、いままでの「固定」された「ウェブ」制作をしていて良いのか？手法は必ずしもレスポンシブWebデザインである必要はないと思います。しかし、Frost氏が言うように「未来に優しい（Future-friendly）」ウェブサイトを作り始めることが、ユーザにとって一番の利益になる。そして、ユーザの利益は直接サイトオーナーの利益にもつながる。

テーブルレイアウトがCSSになり、ウェブ標準が広まり、そして、こんどはレスポンシブWebデザインのような「One Web」が議論される時代が来ています。「ウェブ」に変化が訪れる、すごく面白い時期だなぁと思う今日この頃です。

ニューヨークのR/GAという広告代理店でモバイル・ウェブ戦略、フロントエンド開発をしているBrad Frost氏が作成した画像で、彼のブログで提供してくれています。

自由に使っていいとのことですが、「クレジットの表示をしてどのように使ったかを教えてくれるとありがたい」とのことです。

これが「ウェブ」ではない

これが「ウェブ」

これが将来の「ウェブ」

手順は以下のとおり：

1. MacBook AirのKeynoteでプレゼンを作成
2. iTunes経由でKeynoteにファイルを追加
3. Keynote for iPadを開いてファイルをダウンロード

1. MacBook AirのKeynoteでプレゼンを作成

Keynoteで普通にプレゼンを作成。iPad向けに互換性を持たせるためのプレゼン作成方法はAppleサポートサイトで紹介されていました。

2. iTunes経由でKeynoteにファイルを追加

1. iTunesを開いて、デバイス > iPadを選んで、Appタブを開く
2. 「ファイル共有」の「App」一覧にあるKeynoteをクリックする
3. 右側で「追加」ボタンが押せるようになるので、クリックしてファイルを追加

3. Keynote for iPadを開いてファイルをダウンロード

1. こんどはiPad側からKeynoteを開きます
2. 「+」ボタンをタップして、「Copy from:」の下にある「iTunes」を選択
3. 先ほどiTunesで追加したファイルが出てくるので、それをタップ

これで完了。僕はiTunesで追加した時点でKeynoteのPresentations一覧にファイルが出てくるものと思っていたので、この「+」からファイルを追加するというのが想像つきませんでした。UIとかユーザビリティって難しいですね〜

ちなみにhttps://www.icloud.com/#iworkからファイルをアップロードする方法もあります。これだと、MacBook Airからファイルをアップして、iPadでファイルが表示されるまで、多少タイムラグがありますが、こちらのほうがシンプルだし手間が少なくて便利かもしれません。

There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.

— Stephen Hay (@stephenhay) January 7, 2011

(意訳)
モバイル・ウェブなんてものは存在しない。そこにあるのは、さまざまな方法で見る「ウェブ」だけだ。デスクトップ・ウェブも、タブレット・ウェブもない。ありがとう。

シンプルだけど、すごく深いツィート。

モバイル・ファーストやら、モバイル対応、タブレット対応だと騒がれているが、そこにあるのは1つの「ウェブ」だ。そもそもデスクトップ・ウェブという考え方だっておかしい。これは、レスポンシブWebデザインの根底にある理想論、または、哲学のようにも思えます。僕も、最近ではこちら寄りの考え方に傾いてきています。実際、レスポンシブWebデザインでサイト作ってますしね。

ただ、この考え方がすべてではないとも思っています。

この考え方一本で行けたら理想的ですが、現実はそんなにシンプルではないと思っています。ビジネス案件には、そもそものビジネスの目的や目標、コスト、期間、運営体制、社内政治、人間関係、人的リソース、スキルレベル、開発環境など、胃に穴があきそうなほどさまざまな要因があり、それらを調整して進めていく、そして最終的には目標を達成するという目的があります。目的を達成するのがモバイル・ウェブだった。というのもアリだと思います。

しかし…

またちょっと話は戻りますが、レスポンシブWebデザインのような手法が一般化され、さまざまな要因に耐えうる柔軟な制作プロセスが浸透して、「あぁ、やっぱりウェブは一つだったね」と言う日が来ることを、個人的には望んでいます。そうでないと「え、このサイト●×△（未来の端末）じゃ見られないの？」「え？家でMacで見たときはここに載ってたのに。。。」という状況が、いつまでたってもなくならないように思えるからです。

元記事の内容

まずは「モバイル・サイト」と「フル・サイト」の定義の確認から。

• ここで彼が使う「モバイル・サイト」とは、デスクトップ向けとは別のモバイルに最適化された別モバイル・サイトのこと。
• 「フル・サイト」とはデスクトップ向けのフル機能、フル・コンテンツを備えたサイトのことを指します。

また、Nielsen氏はこの記事のまとめ部分で、以下のように言っています。以下、英文の意訳です：

良いモバイル・ユーザ体験には、デスクトップ・ユーザを満足させるものとは異なるデザインが要求される。2つのデザイン、2つのサイト、それらを相互にリンクして機能させるのがよい。

数百のサイトでユーザビリティテストを行った結果、モバイルに最適化されたサイトのガイドラインは明瞭です：

• 余裕がある場合、モバイルに最適化されたサイト（またはモバイル・サイト）を構築するべき。モバイル端末を使ってサイトにアクセスする際、モバイル・サイトのほうがフル・サイトより断然ユーザビリティが良いことが分かっている
• モバイル端末でフル・サイトにアクセスがあった場合、モバイル・サイトに自動でリダイレクトするべき。現状、検索エンジンはモバイル・サイトを高いランクに位置づけることが少なく、モバイル・ユーザは頻繁にフル・サイトに誘導されてしまう
• フル・サイトからモバイル・サイトへ分かりやすいリンクを設置するべき
• モバイル・サイトからフル・サイトへ分かりやすいリンクを設置すべき

— Mobile Site vs. Full Site – Jakob Nielsen’s Alertbox, April 10, 2012

さらに以下のようなことも言っています：

• 様々なプラットフォーム（iPhone、Android、Windows Phome、BlackBerry）でテストしたが、端末間の差はなかった
• 10インチ以上のタブレットではフル・サイトがそこそこ使えるので、違うガイドラインが適用されるべき
• Kindle Fireなど、7インチ程度のミッドサイズの端末向けには、第3のサイトを作るのが望ましいが、たいていの場合、モバイル・サイトを提供することで問題ないだろう

このガイドラインにある2つの問題点

Nielsen氏がこの記事で紹介しているガイドラインには、大きく2つの問題点があると思います。

別モバイル・サイトとフル・サイトの2つの選択肢しか考慮されていない

このガイドラインで一番違和感が大きいのは、前提として「モバイルに最適化されたサイト」と「デスクトップに最適化されたサイト」の2つの選択肢しか考慮されていないところです。第3の選択肢として、レスポンシブWebデザインのような1つのサイトで複数でバイスに最適化するといった選択肢はまったく考慮されていません。

また、タブレット端末についてNielsen氏は「第3のサイトを作るのが望ましい」と言っています。モバイル端末やタブレット端末だけでなく、デスクトップ、テレビ、ゲーム機など、ウェブサイトの閲覧に利用される異なるスペックの端末が増えていくのは必至です。シェアの多い端末が新たに現れるごとにサイトを構築するのは、実装面でも運用面でも非現実的です。そんな中、一つの手法として頭角を表している「レスポンシブWebデザイン」が選択肢として考慮されていないのには違和感があります。

Nielsen氏は「Nielsen responds to mobile criticism （Nielsen氏、モバイルの批判に応える）」というインタビュー記事で「ユーザビリティの判断と実装の判断は別の話」と言っていますが、実装方法や運用・運営について考慮しないガイドラインは机上の空論でしかないと思います。

故に、このガイドラインは「別モバイル・サイト vs フル・サイト」という、2つの実装方法しか選択肢がなかった場合にのみ当てはまるユーザビリティ・ガイドラインとして見るしかない。制作者やデザイナーがこのガイドラインを批判した背景には、ユーザビリティに関して大きな影響力を持つNielsen氏に、彼らがそれ以上のことを期待していたからではないでしょうか？

モバイル・サイトとフル・サイトの相互リンクがユーザビリティ？

Nielsen氏は、モバイル・サイトで削った足りない機能やコンテンツは、フル・サイトにリンクすれば良いと言っています。もちろん、モバイル・サイトでは可能な限り必要な機能・コンテンツを揃えておくことを条件としています。しかし、フル・サイトでのユーザ体験は圧倒的に劣ると言っておきながら、足りない機能やコンテンツはフル・サイトにリンクすれば良いというのは短絡的だし、一種の諦めのようにも感じます。

たとえば、モバイル端末でサイトを閲覧したことがある方なら、以下のようなことを一度は体験したことがあると思います。

1. 検索結果に表示されたデスクトップ・サイトのリンクをクリックしたら、探していた機能のないモバイル版に自動でリダイレクトされてしまった。
2. フル・サイトなら情報があるかと思い、フル・サイトへのリンクをクリックしたが、フル・サイトのトップページへのリンクだったので、コンテンツをいちから探し直さなくてはならなかった。

自分も幾度となくこのような体験をして、モバイル・サイトへの信頼がかなり低くなりました。これをガイドラインにすることには、かなり違和感があります。

まとめ

さて、問題点のある内容ながらもモバイル・ユーザビリティについて考える機会を与えてくれたNielsen氏に感謝しつつ、この記事をまとめてみます。

モバイル・ユーザビリティに特化したガイドライン

このガイドラインは手法とユーザビリティを切り離し「大義としてのモバイル・サイト = モバイル端末からアクセスした際のサイト」のユーザビリティに特化するべきだったのだと思います。そもそも「別モバイル・サイト vs フル・サイト」とすることで、実装の手法が入ってしまっています。たとえば、今回のガイドラインにある「モバイル向けに要素を大きく表示する」といった内容は、実装や運営に関係なくどの条件にも当てはまります。どの実装方法を選んでも、このガイドラインを守れば最低限のユーザ体験を補填できるといった内容にするべきだったのではないでしょうか？

最後にひとこと

すこし話はそれますが、やはり「2つのデザイン、2つのサイト、それらを相互にリンクして機能させるのがよい」とは思えません。「1つのサイトを、1つのコンテンツで、複数デバイスに最適化する」方法のほうが、今現在、個人的にはかなりしっくり来ます。たとえば、「1つのサイトを、1つのコンテンツで、複数デバイスに最適化する」方法の1つである「レスポンシブWebデザイン」は課題は多いながらも、多くは解決できるものだと信じています。

また、以下の2つを理由に、そう感じています：

1. デバイスごとに複数サイトを運営するのは非現実的（これは実際に問題になっています）
2. ユーザに必要とされるコンテンツ・機能は、デバイスによって大きく変わるものではない（自分の実感以外、データなどの根拠はないですが）

2つ目に関しては、まだまだ検証が必要ですが、とても重要なことなので情報を集めていきたいと思っています。良い情報をご存知の方がいたら、ぜひコメント欄やTwitter (@rriver)、メールで共有お願いします！

参考リンク

元記事

• Mobile Site vs. Full Site – Jakob Nielsen’s Alertbox, April 10, 2012

批判・反対意見記事

• Designers respond to Nielsen on mobile （デザイナー、Nielsen氏のモバイルの考えを批判）
• Why We Shouldn’t Make Separate Mobile Websites（なぜ、別モバイル・サイトを作るべきではないか）
• Jakob Nielsen, Responsive Web Design, and Compromise（Jacob Nielsen、レスポンシブWebデザイン、妥協）
• Nielsen is wrong on mobile（Nielsen氏のモバイルの考えは間違っている）
• Mobile Isn’t the Lite Version（モバイルは簡易版ではない）

批判・反対意見に対するNielsen氏のインタビュー記事

• Nielsen responds to mobile criticism（Nielsen氏、モバイルの批判に応える）

プロジェクトの概要

大学のウェブサイトをリニューアルするにあたり、さまざまな状況や制限などを考慮、また、今後3〜5年を見据えて、レスポンシブWebデザインを取り入れた制作を行いました。大学公式ブログでもリニューアルについて紹介しているので、ぜひそちらもご覧ください。そこで書いたように、以下のような思いもあり、このリニューアルを行いました：

今回、新しい試みを行った背景には、このウェブサイトが「大学のウェブサイト」であることが大きな要因の一つとしてあります。
学生が切磋琢磨して自分を磨く場所、また、新しい知識を学び、試す場所である大学。そんな場所である大学のウェブサイトとして、常に新しいことにチャレンジしていくべきだと考えました。使い慣れたいつもの手法で、いつものようにやればだいぶ楽だった。。。なんて思うところも多々ありま す。新しいことゆえに問題が発生して困ることも沢山ありました。しかし、そこを知恵と工夫でどうにか解決して前に進んでいく。「大学」とはそういう場所だと考えています。

— ウェブサイトが新しくなりました！（2011年10月４日） – テンプルこぼれ話ブログ

採用した技術・手法

このリニューアルプロジェクトでは、これまでに慣れ親しんだ制作手法を見直し（ある意味ゼロから考えなおし）、以下のような技術を採用しました。

• メディアクエリ（Media Queries）を利用したレスポンシブWebデザイン
• フル可変レイアウト
• 1140 CSS GRIDをベースにしたグリッドレイアウト
• パフォーマンス最適化。YSlow!で86点を達成
• CSS Spriteの利用
• HTML5BoilerplateをベースにHTML/CSSを制作　※日本語されてる！
• IE6-8のMedia Queries対応にRespond.jsを使用
• IEのHTML5対応にHTML5Shivを使用
• IEのCSS3対応にCSS3 PIEを利用

半年間運営してみての雑感

レスポンシブWebデザインで作ったサイトを、半年間運営してみて思ったことを書き並べてみます。

ナビゲーションが難しい

複数階層を持つウェブサイトをスマホのような小さい画面に最適化してナビゲーションを実装するの難しい。サイト全体の構造をそのままに、ページの構成を調整してナビゲーションを快適に使えるようにするのはこれからの課題です。たとえば、最近ではFacebookのiPhoneアプリやSparrowなどのアプリでも採用されている、メニューボタンをタップすると画面が横にスライドしてナビゲーションが表示される手法がスタンダードになってくる気がしています。レスポンシブWebデザインでも、複数階層ナビゲーションの標準になるようなものが出てくると思います。それをいち早く、自分で作りたいですが。。。

ブラウザチェックの量が5倍くらい増えた

クロスブラウザでのチェックは、IE6も含め絶えず行っていたのですが、レスポンシブWebデザインにしたことで複数のブラウザ・タイプに加え、複数サイズ、複数デバイスでのチェックが必要になりました。ここをいかに効率化するかは、これからの課題になっていくと思います。便利なツールを使って、ある程度自動化する必要が出てくるでしょう。

レイアウト・デザインに対するかなりの考え方の割り切り、柔軟性が必要

レスポンシブWebデザインは、クロスブラウザでレイアウト表示がほとんど崩れないようにウェブサイトを制作するといった、今までの制作の考え方では到底無理な制作方法だと思います。また、制作のワークフローも、ウォーターフォール型、スパイラル型、アジャイル型を組み合わせたハイブリッドのようなやり方でないと、難しいのでは？と思います。

昔は1pxでもずれたら嫌だったたちでした。でも、最近は「そんなこだわり、逆にかっこわるい」と思うようになっています。それは制作者のエゴであって、ユーザを中心に据えた考え方ではないからです。

ページ構造、構成の重要性を再認識

レスポンシブWebデザインだと、同じコンテンツが複数の異なるレイアウトに落とし込まれるため、コンテンツをモジュール化して組み込んでいく必要があります。ページ・レイアウトの構造と文章構造を理解したうで、伝えたいコンテンツをモジュール化して、分かりやすく構成する能力が必要になります。これに関しても、今までのような固定された環境でのコンテンツ作りとはちょっと違った柔軟な考え方が必要になってくると思います。

画像の扱いはやっぱり難しい

1つの画像でサイズの違う複数デバイスに対応するのは、はっきり言って無理です（いまは無理矢理やってますが。。。Retina対応なんてのもありますし）。自動的に各デバイスに最適化された画像を提供できる仕組みが欲しい、そして、必要になってくると思います。JavaScriptを使ってデバイスごとに違う画像を読み込ませることもできますが、これはかなり非効率的です。画像や写真で伝えたいことが多く、画像の枚数が多いサイトだと、効率的な最適化の手法を見つけないと運営がきつそうです。

まだ詳しく見られていないですが、「Adaptive Images」あたりが、今のことろの現実的な路線でしょうか？なかなか良さそうです。ただ、Apache2とPHPが必須で、すべての画像処理に一度PHPを通すのでパフォーマンス面が気になるところです。あとは、先の話になってしまうとは思いますが、こういった仕組みをCSSやHTML自体に組み込む提案されつつあるようです。このAppleウェブサイトのiPad Retinaディスプレイ対応のような方法は、一時的な回避策でしかないように思えますし。。。

ウェブフォントを使いたい。けど…

上に書いたとおり、レスポンシブWebデザインでの画像の扱いには課題が残っています。そのため、テキストを奇麗に見せるための「テキスト画像」のようなものは出来るだけ避けたい。代替手法として、ウェブフォントは最適だと思うのですが、フォントの種類が豊富で、安定してクロスブラウザで使えるものがあるのかどうか？

Google Web Fontsも日本語がないですし、安定性やクロスブラウザの部分でも、まだまだ検証が必要な気がします。あと英語ならtypekitとかしょうか？日本語ならFONT+とかTypeSquareあたりは、有料ですが検証する価値がありそうです。テキスト画像の制作の手間を考えたら、有料でも安くつく、そんな気がしています。日本でのウェブフォントサービスについては、こんなまとめもありました。

テーブルの表示が難しい

カラムが少ないテーブルならまだしも、カラムも行も多いテーブルの場合、うまい見せ方がありません。データの多いテーブルは画像で見せるのもありかもしれませんが、運営面では非効率的ですし、ユーザにとってもあまり利便性が高くないように思います。悩ましいところです。

CSS3をフル活用すべき

サイト最適化の意味でもCSS3はフル活用すべきだと思います。ただ、IE向けにはCSS3 PIEなどのJavaScriptでの対応が必要になるため、ページの読み込み時間への影響もあるのではないか？と思っています。IEでのデザイン表示はある程度シンプルかして、CSS3の使用も最低限にとどめるのが得策かと思われます。たとえば他のブラウザでは角丸やグラデーションで表示していても、IEでは四角、フラットな色にしてしまうとか。

IE対応の線引

上のCSS3のところでも書きましたが、IEには最低限の対応をしつつも、ユーザビリティを確保できる程度のところで線引きをして、他のブラウザ向けには実装するその他の対応を控えるのもやむを得ないと思います。ただ、IE6以上でナビゲーションやページの閲覧に問題ないレベルにするのは必須だと考えます。※もちろん、アクセス解析データでユーザの使用するブラウザの確認は必須ですが。

[追記]
はてブのコメント欄で「なぜRespond.jsを使ってしまったんだろう…」というご意見をいただいていますが、IEに関しては、レスポンシブ対応なしで固定してしまっても良いのかもしれません。

よりフォーカスしたコンテンツ

これはレスポンシブWebデザインだからというわけではないですが、レスポンシブWebデザインでモバイル対応することで、コンテンツをユーザの求めるものに特化した、よりフォーカスしたものにする必要があると思います。

iframeの高さの調整が難しい

ウェブサービスを利用する際に、iframeを埋め込んでいるのですが、レスポンシブWebデザインだとiframeの高さをコントロールするのが難しい。現在はmedia queriesを使って、複数の画面サイズで表示させて一つ一つ高さを設定をしていますが、これがかなり非効率的です。JavaScriptなどで対応ができればいいのですが、まだできていません。まだまだ勉強不足なので、これからの課題です。

公式Shareボタンの設置が困難

できれば公式のShareボタンを使いたいのですが、JavaScriptが重かったり、各ボタンの表示レイアウトのコントロールが難しかったりと、なかなか課題が多いです。

やはりスマホ（モバイル）からのアクセスは急増している

日本でスマホが急速に普及しているというのもあると思いますが、レスポンシブWebデザインでリニューアルしたセクションで、モバイルからのアクセスが前年同時期比較で2倍に増加しました。

[追記: 2012/5/2 16:00]
はてブでコメントいただいたんですが、上記の比較はレスポンシブWebデザインの導入前、導入後で比較しないと意味ないですね。

スマホからのコンバージョンも普通に

当然といえば当然なんですが、スマホからのコンバージョンも普通にあります。ウェブサイトにアクセスするのはデスクトップPCがほとんどという時代は終わろうとしているのではないでしょうか？スマホでのネット環境が少しずつ充実してきている昨今、これからはネットはスマホでしか見ないという人も増えてくるはずです。デスクトップで使うのと同じように、スマホでもウェブサイトを使うようになるのでは？「コンテキスト」を見極めるのが重要になりそうです。

モバイル・ユーザは結構長いフォームでも入力して送信してくれる

モバイル端末では入力項目の多い、長いオンラインフォームはあまり入力してくれないだろうと想定していました。しかし、そんなことはなく、結構な長さのフォームでも入力して送信してくれます。ユーザは普通にスマホ（モバイル端末）でメールを打ったりしているわけですし、長い文章の入力にも慣れている。そう考えると「スマホだからあまり入力してくれない」という勝手な解釈は結構危険かもしれません。

モバイル vs. デスクトップ

先日Jacob Nielsen氏が「Mobile Site vs. Full Site」という記事で、個別のモバイル・サイトを持つのがベストだといった内容の記事を書いて、欧米では話題になっているようですが、レスポンシブWebデザインでモバイルに最適化する手法が確率してくれば、必ずしも個別モバイル・サイトでなくてはならないとは思いません。

レスポンシブWebデザインもまだまだ進化していくと思いますし、ノウハウがたまっていけば、個別モバイル・サイトに負けないレスポンシブWebデザインのモバイル・サイトが出来上がってくると思います。その可能性を考えたら、費用対効果や運営面でのリスクも考慮して、個別モバイル・サイトを作るのではなく、レスポンシブWebデザインを採用するほうが将来性がある気もしています。

サイトの寿命、リソース、運営体制、納期など、プロジェクトのさまざまな要件を考慮してのケース・バイ・ケースの判断になるとは思いますが…Nielsen氏の記事に関しては、近々、自分なりの考察をまとめてみたいと思います。[追記: こちらに書きました。]

まとめ

レスポンシブWebデザインという手法も、すべての要件を完璧に満たすものではないと思います。ただ、半年間実際に運営してみて、運営状況やその他の条件、要因を考えると、この選択は間違っていなかったと思っています。制作のハードルは高くなりますし、課題もたくさん残っていますが、そこに投資するだけの見返りはあるように感じています。

ネットのモバイル化はまだまだ始まったばかりです。レスポンシブWebデザインは、これから新しく出てくる未知の端末にも対応の可能性を持った手法だと思います。RWDをより良くする新しい技術も生まれてくると思います。ノウハウを蓄積して、ユーザ、サイトオーナー、制作者が、それぞれハッピーになれるインターネット環境を築ければ、もっとネットの可能性が広がっていくと感じています。

さて、これから一つ一つ課題を解決していきますか。

ウェブはだから辞められない。。。 → 腕まくり。。。

テンプレートを直接カスタマイズするのも良いですが、プラグインを入れればより手軽にコントロールができます。このプラグインでは特定の個別ページやWordPressのテンプレート・タイプ別での表示コントロールも簡単にできます。

「Custom Widgets」でコントロールできること

• 特定の投稿やページ、カテゴリなどにのみウィジェットを表示
• ホームページにのみ表示
• すべての個別投稿ページに表示（それ以外は非表示）
• スティッキーポスト（トップページの一番上に常に表示される投稿）にのみ表示
• コメントがオンになっている個別投稿ページ・固定ページに表示
• すべてのページに表示
• すべてのカテゴリページに表示
• すべてのタグページに表示
• すべてのアーカイブページに表示
• 検索ページ結果ページに表示
• 404 Not Foundページに表示
• 管理者プレビュー画面に表示

これだけあれば、たいていのニーズは満たしてくれそうです。

インストールの方法

WordPress管理が面の「プラグイン > 新規追加」から「Custom Widgets」で検索

「Custom Widgets」という名称のプラグインでThaSlayerさんが作者のプラグイン。「いますぐインストール」をクリックしてインストールします。

設定の手順

1. 表示をコントロールしたいウィジェットを選択

※赤いテキストはカスタムの設定がされているウィジェット

2. タイプ別、個別ページの設定

WordPressのテンプレート・タイプごとに設定が行えます。たとえば、ある特定の投稿にのみ表示したい場合は「posts」の「Edit」をクリックして、ウィジェットを表示したいページにチェックを入れます。

3. WordPressのテンプレート別の設定は、ページ下のほうにある一覧のところにチェックを入れるだけです。

英語が苦手な方は、内容は以下の通りです：

• ホームページにのみ表示
• すべての個別投稿ページに表示（それ以外は非表示）
• スティッキーポスト（トップページの一番上に常に表示される投稿）にのみ表示
• コメントがオンになっている個別投稿ページ・固定ページに表示
• すべてのページに表示
• すべてのカテゴリページに表示
• すべてのタグページに表示
• すべてのアーカイブページに表示
• 検索ページ結果ページに表示
• 404 Not Foundページに表示
• 管理者プレビュー画面に表示

WordPressはいろいろなプラグインがあって、ほんと便利ですね〜

「読み込み中」のくるくる回るアニメーションGIF画像を簡単に作れる便利なサイトがあったのでメモ。

AJAX的なことをやると必要になるロード中/読み込み中のアニメーションアイコン。ゼロから作ると結構手間がかかってしまいそうですが、このサイトを利用すれば、以下の4つを選択するだけでアイコンを簡単に作れます。

↓↓ こんなの ↓↓

アイコン作成の際に選択するもの

• アイコンの種類（Indicator Type）
• 背景色（Background color）
• 背景の透明化（Transparent background）
• アイコンの色（Foreground color）

アイコンの種類は、大きく分けてくるくる回るサークル系とファイル・ダウンロードの際によく見るバー系のものが数種類あります。

「Generated gifs are totally free for use（生成されたGIF画像は完全に使用無料です）」とあるので、商用も問題ないでしょう。

→ Ajaxload.info

SSLでウェブサイトに接続すると「このページには安全でないコンテンツが含まれています」と表示される時がある。ところがソースを見ただけではこの「安全でないコンテンツ」を探すの容易ではない。

そんな時に便利なのが、ブラウザの「デベロッパー ツール」にある「コンソール（Console）」。

Macだと「alt + ⌘ + i」で「デベロッパー ツール」を呼び出して「Console」のタブをクリック、または、ファイルメニューの「表示 > 開発/管理 > デベロッパー ツール」で表示させることができる。あとはページをリロードすると問題のある箇所が表示されます。

「安全でないコンテンツ」がページに含まれていると、たとえばGoogle Chromeでは以下のような表示になってしまいます。

せっかくSSLでつないでいるのに、逆にセキュアではない印象を与えてしまいますよね。

ユーザの方々に安心してもらうことが目的のSSL接続なのに、まったく台無しです。トラブルシューティングなどにはこういったツールを使って、すべてのコンテンツがSSL接続をしても問題ないようにしっかりチェックしたいですね。

キーボード操作でアプリ起動やウェブ検索、ファイル検索ができるAlfredがなかなか便利。Macユーザの方はご存知の方も多いかと思いますが、かなり良いのであえてご紹介。その昔、Quicksilverを試して挫折しました。が、Alfredのほうは長続きしそうです。

便利なのは以下の2つの機能。

• アプリの起動
• ウェブ検索

基本的な部分ではSpotlightでも同じことができるんですが、Alfredのほうが操作感が良く拡張性が高いです。特にウェブ検索では、Alfredは好みのウェブサイトを検索できるように設定（Custom Searches）できるのに対し、Spotlightでは「Webで検索」と「Wikipediaで検索」というオプションしか出てきません。

無料版のAlfredのもう一つの強みは、システム関連の操作です。たとえば「ss」というキーワードを「screensaver」に設定すると、Alfredをi呼び出して「ss」と入力するだけでスクリーンセーバーを起動できます。同様に「sleep」や「shutdown」なども操作可能です。

15ポンド（約2,000円 – 4/26現在）出して「Powerpack」なるものを買うと以下のようなことができるようになるらしく、さらに便利そう。

• 拡張機能が使える
• フォルダー・ファイル操作ができる
• iTunesのコントロールができる
• アプリを開くときに「最近開いたファイル」が見られる

Alfredのダウンロードはこちらから。

参考

• Quick Silverを超えた？AlfredでMacをカチャカチャ使う — 男子ハック
  基本的な使い方や設定がスクリーンショット付きで詳しく解説されています。分かりやすい。
• macの神ランチャーソフト・Alfredの設定について — 18thBlog
  Custom Searchesの設定の参考に