本投稿は、2016/10/29にTAM Corokingにおいて行われた「CSS Talk vol.1」で発表した内容の元となる原稿のようなものです。当日のスライドは、こちらに用意しています。
レスポンシブデザインの定義
人によって「レスポンシブデザイン」と言われて想像するものは、少しずつ違うと思います。
よくあるのは、
- 「スマホ対応するやつでしょ」
- 「あー、メディアクエリ書くやつでしょ。画面幅に応じてデザインが変わるっていう」
このあたりが多いと思います。これらが複合的に合わさって
- 「サイトをスマホ対応するための技術」
- 「ワンソース・マルチユースで工数削減できる」
- 「メディアクエリをたくさん作れば、スマホだけじゃなく、タブレットにも対応できる」
- 「Googleが推奨してるんだよね」
- 「その一方で、デザインに制約が…」
- 「ソースの肥大化が…」
などというイメージをされることが多いと思います。どれも間違いではないのですが、この記事を進めるにあたり、ここでは、レスポンシブの定義を以下のようにします。
- Webサイトをスマホ対応させるためのアプローチ技術
- CSSメディアクエリを核とする
- ワンソース・マルチユース
とします。現時点でレスポンシブデザインの広義における定義として定まっているものかな、と思います。狭義には、2だけのことを指すかと思いますが。
スマホ対応のアプローチ技術
定義としてスマホ対応のアプローチ技術とした以上、別のアプローチについても提示しておきましょう。
- UA分岐
- サーバーサイド分岐
- PHPやRubyといった、ミドルウェアレベルでUser Agentを取得し、判定する手法。大抵はライブラリを使う（MobileDetect）
- .htaccess等、httpdレベルでUAを判定し、分岐する手法。ミドルウェアが使えない場合で行うことが多い。
- クライアントサイド分岐
- JSでUAを取得し、分岐させる。（サーバーサイドのアプローチが出来ない場合に行うことが多い。）
- サーバーサイド分岐
- レスポンシブ ←今回話したいこと
レスポンシブデザインに見受けられる４つの段階
レスポンシブの定義を行ったところで、早速レスポンシブには4つの段階があるということについてお話しましょう。
【フェーズ１】ダメポンシブ
個人的には、CSS3のメディアクエリが注目されはじめたのは2011年頃からだと思っていますが、その頃によく見受けられたレスポンシブサイトの状態です。
ダメポンシブの特徴はすべて不体裁という一言に尽きます。
- コンテンツが画面からはみ出す。レイアウトからはみ出す。
- コンテンツ同士が重なる。見えない部分が生じる
- コンテンツや画像のサイズが不自然に大きくなったり小さくなったりする
- コンテンツや画像のアスペクト比が正しく再現されない
また、ソースコード面では
- !importantの嵐
- 継承がとっちらかってしまい、メンテナビリティが極端に悪い。
これらは、すべてアダプティブデザインのWebサイトに対し、スマホ用のメディアクエリを切ったCSSを追記で当てることによって発生します。俗に言う**!importantの嵐**状態です。アダプティブをデザインした本人でもわけがわからなくなるでしょう。
基本的に、このフェーズはレスポンシブデザインとして納品できる状態ではないと考えます。
【フェーズ2】 ややポンシブ
ややポンシブの定義は簡単です。ダメポンシブの課題をすべて解決してしまえばいいのです。!importantの嵐であっても、しっかりCSSの仕様と継承の仕組みがわかっていれば、いずれ解決できます。全部のページを見て回って、おかしなところにすべてIssueを立ててしまえばいい。でも、それって「レスポンシブデザインなの？」という疑問はついてまわります。
ややポンシブの定義として不体裁はないが、UIとして洗練されていないというのが大きな特徴でしょう。例えば、
- 縦に項目が長いグロナビ
- アダプティブで水平8項目あるグロナビが、レスポンシブだと2列4行にわたるグロナビになったら、それはデザインとして洗練されているのでしょうか？
- メインのグロナビとは独立しているプライバシーポリシーや採用情報で使われるような小さなナビも、グロナビから分離してしまうが、それは本当に良いのでしょうか？
- ４階層、5階層と横に長くなるパンくずリスト。そのまま愚直にスマホデザインでも途中で折り返しながら表示するのは、スマートな表現でしょうか？
- そもそも項目数の多い、サイトマップ的なフッターグロナビ。
ナビゲーション系で課題が増えてきます。また、
- 画像のアスペクト比がスマホのポートレイト（縦位置）画面に合わない
- メインビジュアル等、アダプティブデザインでの画像は、横長画像が多く、ポートレイトでは、相対的に小さく見えてしまう問題。
といった現象も生まれます。
これも結局、アダプティブデザインを無理やりレスポンシブにするために発生する現象と言えます。
【フェーズ３】 ほぼポンシブ
ここからが、昨今で言われる「レスポンシブデザイン」的な要素を満たしてくるかと思います。もちろん、ほぼポンシブはややポンシブの課題をすべて解決している必要があるのですが、キモとなるのはレスポンシブでありながら、UIの洗練がなされているということに尽きるでしょう。
例えば、
- グロナビはハンバーガーメニューになる
- PCではちょこっとナビが分離しているが、スマホでは、グロナビ全項目がハンバーガーメニュー内に収められる
- メインビジュアルはアートディレクションの振り分けがなされる
こういったところが、ほぼポンシブと言えるのではないでしょうか。これらを実現するには、このあたりでそろそろ「アダプティブデザインに対し、スマホ用のCSSを追記する」というアプローチでは限界があり、レスポンシブを前提としたマークアップとスタイリングが求められてきます。またCSSの記述もかなり膨れ上がり、CSSだけでは実現できずJSに頼る部分も出てきます。従ってこのあたりで
- CSSプリプロセッサの導入（LESS、Sass、Stylus等）
- CSS+JSフロントエンドフレームワークの導入（Bootstrap等）
- モバイルファースト設計の導入
を検討したり、実施したりすることになるでしょう。
【フェーズ４】 （完全なる）レスポンシブ
**（完全なる）**というのは「本来目指さないといけない」という程度の意味であって、何事にも完全はないと思っています。でも、昨今のモバイル対応を考えると、レスポンシブデザインというのは、これぐらいやらないと、顧客の期待に添えないだろうな（＝要求レベルが高まってきているな）ということを感じています。
（完全なる）レスポンシブでは、ほぼポンシブの要件を満たした上で、下記のような課題をクリアします
- ブレイクポイント間で中途半端な見た目になるスタイルの解決
- 細かくブレイクポイントを切る
- 臨時のメディアクエリを切る
- マウスホバー時のデザインをタッチデバイスでは別の表現でアプローチさせる
- もはや画面幅だけでは判定できず、入力デバイスを判断する仕組み（JS）が必要
- ポートレイトだけでなく、ランドスケープ画面での見た目も考慮する
- 考慮できない場合は、ランドスケープ画面でアラートモーダルを出すなど。
- 幅1920pxなど、大きなモニタサイズなども、考慮する
- PCのRetinaディスプレイなど、高解像度モニターも考慮する
- SVGやアイコンフォントの積極的な使用、レスポンシブイメージの導入
これらは別に理想でもなんでもなくて、事例サイトに乗るような優れたデザインの案件を見れば、普通に実装されていたりします。結局は、ここまでやらないと、いい仕事として評価はされないのだろうなあ、というのが2016年現在の個人的な肌感覚だったりします。
ただ、これらをすべて実装しようとすると、とにかく時間が足りない。頭で分かってはいても、実装する時間、学習コストにかける時間、さらにそれをコーディングするスタッフに落としこむ時間。すべての時間が足りていない。これが残念ながら課題となっています。
フェーズ４の場合、人によっては「UA分岐でやったほうが早い」という人もいるかもしれません。しかし、レスポンシブとして受注している以上はその要件から離れた納品は出来ないので、UI/UXの洗練のためにはレスポンシブであったとしても、その実装は必要です。レスポンシブの定義を狭義の「CSSメディアクエリによる〜」というところにとどめていない（＝JS実装も含む）のは、こういう事情もあるからです。
4つの段階、チートシート
| ダメポンシブ | ややポンシブ | ほぼポンシブ | （完全なる）レスポンシブ | |
|---|---|---|---|---|
| 納品レベル | ☓ | ◯ | ◯ | ◎ |
| 特徴 | 不体裁 | UIが洗練されていない | いわゆるレスポンシブ | レスポンシブなのに気が利いている！ |
| 技術特徴 | CSS | CSS | CSS+JS | CSS+JS |
| 必要な知識 | CSSの基本的な理解 | 左記に同じ | メディアクエリ・JS・フレームワークの理解 | 左記のさらなる深い理解 |
| 顧客満足度 | 😡 | 😅 | 😌 | 😍 |
ほぼポンシブ以上を目指すために…
当日のイベントでは、この後、品質の高いレスポンシブサイトを効率よく制作するため、Zurb Foundationを有効活用しよう、という文脈でお話をしました。