Re: レスポンシブWebデザインのメリット、デメリット比較まとめ

2012年11月13日 著

レスポンシブWebデザインのメリット、デメリット比較まとめ - Photoshop VIPという記事がかなりはてブられているようなのですが、個人的に「そこはそうじゃないんじゃないかなぁ」と思うところが複数あったので、覚え書きしておきます。もっとも、当該記事の元ネタはThe opportunities and challenges of responsive design | Webdesigner Depotという記事なので、そちらに対する違和感、ということになるかもですが。

メンテナンスが楽？

レスポンシブWebデザイン（以下「RWD」）のメリットの筆頭に挙げられているのがこれなんですが、必ずしもそうとは言えないと思います。CMSのような仕組みの動いている環境であれば、デバイスごとに複数のHTMLファイルを出し分けていたとしても、RWDのようなワンソースマルチユース方式と遜色ない工数で内容の更新はできるわけで。むしろ、運用のなかで新しいモジュール（※ビジュアルデザイン構成上の最小単位を僕はそう呼んでいますが、環境によっては「コンポーネント」「デザインパーツ」みたいに呼ばれているアレです）が必要になった場合、特定のデバイス専用に作るよりはRWDのほうが工数は増えるでしょう。なので、どんなメンテナンスかという前提次第ですけど、一義的にRWDだからメンテナンスが楽、ということは言えないのではないかと。

一貫性のあるデザイン？

RWDとは関係ないように思うのがこの項目です。同じサイトであれば、どのデバイスで利用してもその表示に一貫性、少なくとも一定の幅に収斂したトーン＆マナーを提供して然るべきです。しかしそれは、RWDを採用しているかどうかとは関係ないはず。複数のHTMLソース出し分けを採用している場合であっても、一貫性のあるデザインは作れますし、作るべきです。逆に（敢えてひねくれて書きますが）RWDを採用しながら、「一貫性のない」デザインを作ることは原理的には可能です（あくまでも可能というだけであって、一般的にはそんなUIは作らないわけですが）。

親切、安心設計の操作性？

複数のデバイスで同じページ、同じサイトを利用するユーザーに対し、本当に「親切、安心設計の操作性」と言い切れるかは微妙だと思います。同じURLにアクセスするにせよ、多くのRWDでは特定のモジュール、特にナビゲーション機能を担うものの位置や表示がスクリーン特性に応じ変化するわけで、ユーザーに対しては少なからず学習コストを要求するはずです。それを本当に親切で安心と呼べるかどうか？もっとも、より一層RWDのような手法が広く浸透していけば、そういうコストも無視できるレベルになるのかもしれませんけどね。

現在のページ読み込み速度に対応？

表示速度をメリットとして挙げているようなのですが、むしろデメリットでしょう。テキスト主体のコンテンツであれば別ですが、一般論としては、RWDよりソース出し分けのほうが表示速度の面で利点が有ります。少しでもデータサイズが小さい方が、表示も早くユーザーにもうれしいのは確かですけど、そこを突き詰めれば、RWDではなくデバイス個別にソースを出し分ける（画像など読み込むリソースも当然個別に最適化する）ほうがファイルサイズは軽くなり、より高速な表示が期待できます。

開発時間の長さ？

既存サイトをレスポンシブ化するのは、ゼロから作成するときよりも制作時間がかかってしまうことが多いと書かれていますが、そのような施策は余程のことが無い限り避けるべきでしょう。既存サイトというのは大抵、デスクトップPC専用デザインのサイトであることが多いと思いますけど、それをコードベースにRWD化するのは、いろいろな面で無理があり過ぎます。そもそも「モバイルファースト」に則れないわけですから、無理が生じるのは当然。単に時間がかかるのみならず、中途半端な品質、出来映えになる懸念が大きいと思います。記事の後半で著者の方自身、既存サイトのレスポンシブ化はやめましょうとお書きになっていますが。

Internet Explorer 8で動かない？

IE8に限らず、メディアクエリーに対応していないブラウザに対し、respond.jsのようなものを読み込ませてまで（メディアクエリー対応ブラウザ相当の）表示を担保すべきかというと、自分はそうは思いません。RWDは、Webサイトの表示をモバイルを含むさまざまなデバイスに対応させるためのいち手法であって、同じデスクトップブラウザにおけるスクリーンサイズの変化に対応させる意義は薄いでしょう。小山田さんがレスポンシブ・ウェブデザインでの CSS コードの書き方で書かれているように、自分もメリットは少なく、デメリットが大きいと考えています。

拡大イメージ写真のディテールの低さ？

この項目もあまりRWD自体とは関係ないような......複数種の画像を用意しておき、スクリーンサイズに応じてJSで差し替える方式の手法や、クライアント側ではなくサーバー側で出し分ける手法、Adobe Scene7のようなサービスを利用する手もあります。なので、コストを度外視するなら、RWDを採用するからといってスクリーンサイズを中心とした、コンテンツ作成しかできなくなるということは無いはず。ことディテールの低さについて語るなら、RWD云々ではなく、高まる一方のピクセル密度に今後どう取り組むかっていう文脈のほうがしっくり来ます。

ナビゲーションメニュー充実度の低さ？

RWDを採用するとナビゲーションメニューが貧弱になる、とは思いません。事実、例に挙げられているStarbucksは、PCでみてもスマートフォンで見ても同じ項目がグローバルナビゲーションに並んでいるわけで（RWDですから当然といえば当然）、充実度という尺度がいかなるものかよくわかりませんけど、機能としての優劣が変化しているわけではないのでは？と思います。単にスクリーンサイズに応じた表現に切り替わっているだけの話しで、デメリットではないように思います。無論、物理的に小さなスクリーンであれば制約が厳しいのは確かであり、だからこそモバイルファーストで臨む必要があります。

ゼロから作るのはやめましょう？

フレームワークの使用をお勧めしているのですけど、プロトタイプ制作には向いていると思いますが、プロダクションレベルで使って良いかどうかは、プロジェクト次第でしょうね。フレームワークの利用経験は自分にはありませんが、便利な反面、意図せず無駄なコードが入ってしまう懸念もあるわけで、ある程度スケジュールに余裕がある前提においては、ゼロから作ってもよいと自分は思います。

ややRWDに対して批判めいたことを書き連ねましたけど、自分はRWDの有効性は認めたうえで書いているつもりですし、むしろRWD「も」いちWebデザイン手法として積極的に取り組んでいる立場なので、念のため。まぁこの記事の最大の違和感はというと、元ネタにあるopportunities and challengesを日本語でメリット・デメリットとして翻訳しているのが果たして妥当なのか？というところです。