レスポンシブWebデザイン

「レスポンシブWebデザインって結局どう設計してどう実装するのが最適なんだっけ?」に答えるまとめです。

設計フェーズのデザイナーとエンジニア向けです。

動機

ゼロからレスポンシブWebデザインを実現しようとした時に、質の低い情報が溢れかえっているせいで、何がスタンダードでどんな選択肢があるのかが全く分からず困ったので、信頼できる情報ソースを中心に調べたことと試行錯誤してわかったことをまとめました。

参考情報

GoogleやMozillaなどWebブラウザを開発する企業が出しているガイドラインを参考にします。これら以上に信頼できる情報ソースはこの世に無いと思います。

Responsive design - Learn web development | MDN

こちらはWeb開発者向けにMozillaが出しているレスポンシブWebデザインのガイドラインです。歴史や本質、基本的な実装方法について説明しています。

Responsive Web Design Basics

こちらはWeb開発者向けにGoogleが出しているレスポンシブWebデザインのガイドラインです。実装パターンと実装方法を具体的に説明しています。

Responsive layout grid - Material Design

こちらはGoogleが出しているMaterial Designというデザインガイドラインにおける、レスポンシブWebデザインのガイドラインです。図解とアニメーションがわかりやすいです。

ちなみに、日本語でいう「(色やフォントなどの)デザイン」だけでなく「(DBやコンポーネントなどの)設計」も、英語で"design"といったりするので、要注意です。

レスポンシブWebデザインとは

まず、レスポンシブWebデザインの定義を考えてみます。

Mozillaが出しているガイドラインを参考にします。

以下は、Responsive design - Learn web development | MDNからの引用です。

The term responsive design was coined by Ethan Marcotte in 2010 and described the use of three techniques in combination.

  1. The first was the idea of fluid grids, something which was already being explored by Gillenwater, and can be read up on in Marcotte's article, Fluid Grids (published in 2009 on A List Apart).

  2. The second technique was the idea of fluid images. Using a very simple technique of setting the max-width property to 100%, images would scale down smaller if their containing column became narrower than the image's intrinsic size, but never grow larger. This enables an image to scale down to fit in a flexibly-sized column, rather than overflow it, but not grow larger and become pixellated if the column becomes wider than the image.

  3. The third key component was the media query. Media Queries enable the type of layout switch that Cameron Adams had previously explored using JavaScript, using only CSS. Rather than having one layout for all screen sizes, the layout could be changed. Sidebars could be repositioned for the smaller screen, or alternate navigation could be displayed.

It is important to understand that responsive web design isn't a separate technology — it is a term used to describe an approach to web design or a set of best practices, used to create a layout that can respond to the device being used to view the content. In Marcotte's original exploration this meant flexible grids (using floats) and media queries, however in the almost 10 years since that article was written, working responsively has become the default. Modern CSS layout methods are inherently responsive, and we have new things built into the web platform to make designing responsive sites easier.

まとめると、レスポンシブWebデザインとは、デバイスに対応したレイアウトを実現するためのアプローチまたはベストプラクティスの集合であり、2010年に初めて提唱された際、fluid gridsfluid imagesmedia queryの3つの技術を組み合わせたものとして定義されていたいうことです。

2020年においても原則は全く変わっておらず、レスポンシブWebデザインは常にこれら3つの技術に集約されると言って良いと思います。

これら3つの技術の詳細については情報ソースを参照してください。2020年現在完全に常識になっている内容なので、みなさんすでにご存知だと思います。

レイアウトパターン

次に、より具体的なレイアウトパターンを考えてみます。

Googleが出しているガイドラインを参考にします。

以下は、Responsive Web Design Basicsからの引用です。

Most layouts used by responsive web pages can be categorized into one of five patterns: mostly fluid, column drop, layout shifter, tiny tweaks, and off canvas. In some cases, a page may use a combination of patterns, for example column drop and off canvas. These patterns, originally identified by Luke Wroblewski, provide a solid starting point for any responsive page.

まとめると、多くのレスポンシブWebデザインは以下の5つのパターンおよびそれらの組み合わせに分類できるということです。

  1. Mostly Fluid
  2. Column drop
  3. Layout shifter
  4. Tiny tweaks
  5. Off canvas

それぞれのパターンの詳細については情報ソースを参照してください。実際のコードとデモがめちゃくちゃわかりやすいので。

加えて、最近よく目にするのがスクロールを活用するパターンです(Mostly Fluidの一つとも言えます)。2020年4月現在、AmazonやNetflixなどが採用しています。スクロールはViewPort幅やコンテンツ量によってUIや実装を大きく変更する必要がなく、その上でカテゴリごとの一覧性や操作性も失われない、有用なパターンだと思います。

何をどう増減させるか

レスポンシブWebデザインは、一言で言うと、ViewPortの面積が増減した時にコンテンツのどの部分(対象)をどのように増減させるか(方法)を決断する行為と言えます。したがって、増減させる対象と方法の選択肢がわかれば、決断は容易かつシンプルになります。

というわけで、選択肢をまとめてみました。

ここでは、Responsive layout grid - Material Designの、columnsguttersmarginsという概念を一部利用します。

Columns, gutters, and margins

  1. Columns
  2. Gutters
  3. Margins

以下は、レスポンシブに増減させる対象と方法の主な選択肢です。

対象方法パターン
margins幅増減Mostly Fluid16pxを24pxにする
gutters幅増減Mostly Fluid16pxを24pxにする
columns幅増減Mostly Fluid80pxを120pxにする
columns数増減Column drop4カラムを8カラムにして下から右にコンテンツを移動する
UI文字サイズ切替Mostly Fluid16pxを20pxにする
UI配置切替Layout shifterナビ機能をフッターからヘッダーへ移動する
UI表示切替Layout shifterサイドバーをアイコンクリック時のみ表示するようにする

レスポンシブなフォント

フォントはMedia Queryで細かくサイズを切り替えるのがセオリーだと思いますが、もっとレスポンシブにしたい場合はvwという単位を使うと良いです。ただし、固定値と一緒に使わないと、拡大率が大きくなりすぎたり、ブラウザのズーム機能が効かなくなったりします。詳しくは以下の情報ソースを参照してください。

Using viewport units for responsive typography

有名なサービスの場合

次に、ここまでに見てきたパターンや考え方が、実際のサービスでどのように適用されているかを観察してみます。

ここでは、YouTubeとTwitterのWebをPC幅から縮小させる方向で観察してみます。

YouTube(ホーム画面)

ViewPort対応増減パターン
1320px~サムネイルとタイトルが可変columns幅増減Mostly Fluid
~1319pxサムネイルとタイトルが可変columns幅増減Mostly Fluid
左サイドバーのUIが小さく(アイコンだけに)なるUI表示切替 / columns数増減Layout shifter
左上のメニュークリック時のみフルサイズのサイドバー表示UI表示切替Off canvas
~1127pxサムネイルとタイトルが可変columns幅増減Mostly Fluid
1行に表示されるサムネイルが4つから3つになるcolumns数増減Column drop
~871pxサムネイルとタイトルが可変columns幅増減Mostly Fluid
左サイドバーが非表示UI表示切替Layout shifter
~495pxサムネイルとタイトルが可変columns幅増減Mostly Fluid

YouTube(動画視聴画面)

ViewPort対応増減パターン
1000px~視聴中動画とコメント欄の幅が可変columns幅増減Mostly Fluid
~999px右サイドバーが視聴中動画直下に移動columns数増減Column drop
全コンテンツが可変columns幅増減Mostly Fluid

Twitter(タイムライン画面)

ViewPort対応増減パターン
1265px~左右のマージンのみ可変margins幅増減Mostly Fluid
~1264px左サイドバーのUIが小さく(アイコンだけに)なるUI表示切替 / columns数増減Layout shifter
~1077px右サイドバーの幅が増減(固定値)UI表示切替Layout shifter
~987px右サイドバーが非表示UI表示切替Layout shifter
タイムラインの幅が可変columns幅増減Mostly Fluid

これらの観察結果から、一つのサービス内でも複数のパターンが組み合わされて適用されていることや、サービスによってブレークポイントの数や位置が異なることがわかります。

また、ここまでに見てきたパターンや考え方によって割と綺麗に分類・分析できるのも非常に面白いです。

デフォルト設計

最後に、私が考えるデフォルト設計を紹介します。

上記観察からも分かるとおり、最適解はサービスによって全く異なるので、実際はデフォルト設計をもとに適宜調整する必要があります。

ブレークポイント

まず、ブレークポイントの設定です。

Breakpoint system - Material Designを参考にします。

sm(スマホ): ~600px

md(タブレット): 601~959px

lg(PC): 960px~

同一ブレークポイント内でも結構幅があるので、まずは例えばiPhone X・iPad・MacBook Pro 13など、特定のデバイスを決めてそのViewPort幅を基準にデザインを始めるのがいいと思います。

また、どうしてもレイアウトが崩れるのでブレークポイントが2つでは足りないと感じる場合は、全体的にブレークポイントを増やしてレイアウトを変えるのもいいですが、可能であれば局所的にブレークポイントを増やして解決することをおすすめします。そちらの方が実装コストが低いからです。例えば、Twitterの~1077px幅では、右サイドバーだけブレークポイントを増やして対応しています。

ブレークポイント別実装方法

~600px

  • columns数は4。
    • パターン1:メインコンテンツ:4
  • 画面最上部にヘッダーを固定配置し、低使用頻度機能(サイドバー・設定関連・アカウント関連など)への導線を確保する。
  • 画面最下部にナビを固定配置し、高使用頻度機能へのアクセスを容易にする。
  • サイドバーは特定のイベント発生時のみ表示する。
  • ダイアログ(=モーダル)を積極的に活用する。
  • どの機能への導線を、どこに配置するかは、サービスごとの決断の問題。

601~959px

  • columns数は8。
    • パターン1:メインコンテンツ:8
    • パターン2:メインコンテンツ:6・左または右サイドバー:2
  • 画面最下部のナビは非表示にし、その機能をヘッダーに移殖する。

960px~

  • columns数は12。
    • パターン1:メインコンテンツ:12
    • パターン2:メインコンテンツ:8・サイドバー:4
    • パターン3:メインコンテンツ:8・左サイドバー:2・右サイドバー:2
  • ブレークポイントの下限をメインコンテンツ幅の最大値にする(max-width: 960px)。一覧表示系ページの場合はもっと広くても良い。
  • ViewPort幅と(サイドバーも含む)コンテンツ幅の最大値の差分はmargins幅増減で吸収する。
  • タッチパネルに特化したUIは適宜修正する。
  • スペースが余る場合は、追加機能よりも遊び心を入れてみる。必要以上の機能の存在はユーザーを疲弊させるので。

その他

  • カテゴリごとの一覧性を高めたい場合は、スクロールレイアウトの導入を検討する。

結論

何事もそうですが、セオリーやパターンで解決できる問題と決断の問題を区別して、決断の問題の解決に最大限のリソースを投下することができれば最高ですね。