Webデザイナー/エンジニアの作楽ゆずです。
この記事では実務を通して浮き彫りになったレスポンシブの課題と、解決に導くシステムを作るために試行錯誤したことを前・中・後編でお伝えします。
主にデザイナーやコーダーの1~2年程の経験者向けの内容となっております。
まず大前提として、解決すると銘打っておきながら、すべてのコンテンツに対する一つの正解というものはないという、身も蓋も無い結論がございます。コンテンツによって最適なものは変わります。
しかしその中で実務で直面している課題、例えば文字の可読性・印象に残るレイアウト・短い納期に対する工数の効率性と汎用性など、それらに対して最良の妥協点を見つけることを目指しました。そしてその先にある目的は、省略できた工数をコンテンツの哲学や美学の探究と具現化への時間へ充てることです。
記事での便宜上の用語について
またこの記事では、便宜上いくつかの用語が出てくるので、その解説を先にいたします。
まずは、「SP」「TB」「PC」という用語です。これらは下記の通りのデバイスでブラウザをフルスクリーンで表示された時のCSSの画面幅もしくはデバイスを指しております。
- SP…スマートフォンの幅392px程度
- TB…タブレットの幅768px~1024px程度
- PC…ノートやデスクトップパソコンの幅1440px~1920px程度
デザインをハードウェアに依存することには、デバイスのシェア率・空間コンピューティング・ブラウザのフルスクリーン表示といった観点から個人的にはやや否定的な立場なのですが、現場の事情や工数といった現実的問題と便宜上これらの用語を使う必要があると判断しました。
次に、「モジュラースケール」「調和数列」という用語です。
シフトブレインの鈴木さんが執筆されました「音楽、数学、タイポグラフィ」という記事に登場する言葉です。モジュラースケールは、スケールを意味のある調和した比率を基いて決めるというもので、調和数列は、各項の逆数が等比数列になっている数列というものです。
最後に、「固定値型」「相対値型」「固定・相対値複合型」「スマホ特化型」という用語です。こちらは、unshiftの長谷川さんが制作されました「Responsive Samples」というサイトに登場する言葉です。これらの型は、レスポンシブで要素のサイズがどのように変動するかの実装方法で、それぞれ下記のような型となっております。
- 固定値型…pxやremなど、ビューポートの幅に依存しない絶対的な値を主に使用した実装方法。
- 相対値型…vwなど、ビューポートの幅に依存する相対的な値を主に使用した実装方法。
- 固定・相対値複合型…「固定値型」と「相対値型」を組み合わせた実装方法。
- スマホ特化型…ビューポートの幅が広い場合でも基本的にはスマホレイアウトで表示する実装方法。
これらの用語が出てくる「Responsive Samples」「音楽、数学、タイポグラフィ」はとても勉強になって、私の思考もこちらのサイトを元に巡らせていったので、是非ともご覧くださいませ。
システムの方向性について
まずシステムの方向性を策定するにあたって、「完璧なデザインではなく、最良の妥協点を見つける」というコンセプトを軸にしました。そして普遍的なもの（視覚や心理といった人間の特性や歴史から導き出されたデザインの法則など）からシステムの根幹を作ることで、より揺るがない強固なものになります。
システムの礎となるWebサイトの目的は、オリバー・ライヒェンシュタインさんの発言である「ウェブデザインの95%はタイポグラフィだ」のように、「読んでもらうこと」と定義づけます（勿論、その上に体験型コンテンツや情緒感の伝達など個々の目的が乗っかることも前提です）。そして優れたタイポグラフィは、皺眉筋の活動低下（あまり目を細めなくて済む）や検証で体感上に良い影響をもたらすなど、読んでもらう目的を助けることに大きな役割を果たします。つまり、タイポグラフィがシステムの根幹になりえるのです。
タイポグラフィについて
では、具体的にどのようなタイポグラフィが良い（多くの人間の特性にとって読みやすい傾向が高い）のでしょうか。読みやすさ=可読性を考えるにあたっては、「ウェブタイポグラフィ─美しく効果的でレスポンシブな欧文タイポグラフィの設計」という書籍から引用させていただきます（この本はタイポグラフィについてかなり詳細に書かれているのでオススメです！）。
可読性の高い段落は、行間、カラム幅、文字サイズの3つの要素が組み合わさってできています。本書では欧文の行の長さ（カラム幅）は45文字から75文字の範囲が好ましいとしています。和文ではこれらの文字数の半分強、24文字から40文字程度を目安にするとよいでしょう。
この引用から文字サイズを基準とした行間とカラム幅の目安が分かりました。では、可読性の高い文字サイズとはどの程度なのでしょうか。同書籍では、理想的な文字サイズは目から画面までの距離によって変わる、と綴られています。その距離とサイズは、30cmでは16px、45cmでは19px、60cmでは22px程度（おそらく欧文ベースなので和文ではもう少し小さいと思われる）とされています。勿論書体によってpx数は変動しますが、問題は現状その距離を測る術を持っていない、ということです。
そこで、ブラウザの幅に比例して目から画面までの距離が遠くなって文字サイズも大きくなる、と仮定します。SPでは30cmで16px、TBでは45cmで19px、PCでは60cmで22px、はたまたデジタルサイネージではそれ以上、といったイメージです。
しかしこれには問題があり、PCではブラウザをフルスクリーンで表示している保証が無いのです。
例えば、目と画面が60cm離れたPCの画面上で、ブラウザを任意のサイズにしていた場合、メディアクエリによって検知されたブラウザの幅と、仮定した目と画面との距離から導かれた文字サイズとの差異が発生します。例えば、目と画面が60cm離れたPCでブラウザ幅1024pxでWebサイトを閲覧した場合、メディアクエリはブラウザ幅を検知することで1024pxだからTBの文字サイズである19pxと表示されるのです。
このように、現状では目から画面までの距離に応じて最適な文字サイズを表示できることは難しいです。なのでコンセプトの「最良の妥協点」に立ち返り、また和文の使われている様々なWebサイトの文字サイズを調査して吟味した結果、一律的に16~20px程度の文字サイズが良いのではと結論づけました（ここについては中編・後編で後述します）。
文字サイズのスケールについて
可読性の高い文字サイズ（本文サイズ）の大きさが分かったので、そのサイズを元に他の文字サイズをモジュラースケールによって決めていきます。まず16~20pxの中で汎用的な16pxと仮定して、スケールの差がちょうど良くなる、かつ本文サイズの整数値と合致するパターンの多くなるように調和数列を用いました。
その結果、16（本文サイズ）* 6 = 96をベースに、96/2、96/3... という形で割っていきます。画像のように、10.666・12・13.714・16・19.2・24・32・48・64・96という数値になりました。一つ例外的に96/1.5=64という数値を出していますが、48と96の間が空きすぎてしまうことから、使いやすさを考慮して本文サイズの4倍である64を取り入れました。（実務においても、64px辺りのサイズのディスプレイテキストが欲しい場面がいくつかもあり）
これらの数値は本文サイズを基準にしているので、もし本文サイズが15pxや17pxに変わる場合、それに比例して他の文字サイズ全ても変わります。
さて、ここで一つ気になるのは小数点があるサイズです。一見整数に丸めた方が良いのではと感じることもありますが、調和数列によって選定された数値は和文ベタ組の本文のカラムと同じ幅において、行末が揃うパターンが多いというメリットがあります。
例えば13.714の場合、14に丸めた場合は本文が40文字までで割り切れる数は112, 224, 336, 448, 560の5通りに対して、13.714で割り切れる数は96, 192, 288, 384, 480, 576の6通りです。そして、6通りの方の数値は中編・後編で後述する本文サイズとフィボナッチ数列を用いた余白による設計と相性の良い数値となっています。このことから13.714という数値を採用します。
また他の懸念と考えられる、Webデザインにおいては分業的（デザイナーとコーダーが分かれている）観点から、コーダーを迷わせる数値である小数点を使わないことが配慮として掲げられる一面もありました。しかしFigmaの台頭により、Figmaでバリアブルとして数値を登録したり、バウンディングボックスを整数に丸めてくれたりする機能によってその懸念は払拭できると考えられます。
ここまで、システム根幹であるタイポグラフィや文字サイズのスケールなどを選定する考えをお伝えすることができました。次回の中編では、余白の設定やグリッドシステムを用いたデザインカンプの作成を書いていけたらと思います。
