Every Layout × デジタル庁の汎用性が高い件
BLUE B NOSEでは、汎用性や再利用性、規格化を重視した構築環境を模索しています。今回は、Every Layoutやデジタル庁のデザインシステムを取り入れて使ってみた感想や、どんなふうに取り入れてみたのかなど、経験ベースの雑感をお伝えします。
ノーコードツールや自動化ツール、SassやPugといったメタ言語に、grantやgulpから発展してきたタスクランナーなど、Webサイト制作、より正確に言えばHTMLやCSS（+Javascript）の構築、コーディング環境はお手頃になってきましたが、だからこそ、先々を考えて構築することが難しくなってきました。
BEMやOOCSS、アトミックデザインといったCSS設計、ダークモードも踏まえた配色、カラーマネジメント、更にはAMPやレイアウトシフト等も含んだパフォーマンス、複数人による大規模リモート開発など、気にかけるべきことも多くなっています。
Twitter Bootstrapは分かりやすいけど若干ダサいし、無駄もある。Tailwind CSSは生理的に合う合わないといった問題、導入コストもある。CSS-in-JSやCSS Modules、Webコンポーネントもどこでも使えるとは言い難い。
そんな場面でも、難しいことを考えず、システマチックに使えそうなデザインシステム、オレオレフレームワークを実現できないかと筆者も試行錯誤を積み重ねた結果、Every Layoutにデジタル庁のデザインシステムを組み合わせるのが使い勝手が良いのではないか、という結論に至りました。
何をどう設定すれば、再生産性がそれなりに高く、部材の規格化も望めそうな環境が構築できるのか。
実体験の一部を簡単にご紹介します。
CSS設計は『Every Layout』で
飽くまでも筆者の体感ではありますが、2021年の年末に彗星のように現れて、彗星のように消えて行った感のある『Every Layout』（ヘイドン・ピカリング / アンディ・ベル著 ボーンデジタル）。
CSS設計の土台には、コレを用いるのがベターな気がします。
欧米スタイルだなぁと思うところも相当ある上に、そのままでは使いにくい構造、レイアウトも多々あるので、自分なりに使いやすい方法で書き換え、BEMなりOOCSSなりSMACSSなり、取り入れやすい文化に合わせて調整すると良いでしょう。
筆者は、コレに"o-"（オブジェクトの接頭語）を付けつつ、BEM風の命名規則でバリエーションを用意しつつ、Every Layoutに含まれないものを"c-"（コンポーネントの接頭語）、ヘルパーに"u-"（ユーティリティの接頭語）をつける形でコントロールしています。
clamp関数やmin/max関数にもこの機会に触れておくと、Media Query風のレスポンシブも転用できたり、使える手段が増えて良いと思います。
配色は、Material Design × Appleを軸にする
ベーシックな配色として、「リンクテキストの色は青、訪問済みは紫」というのを概ね踏襲しつつ、それ以外はAppleが掲げている「iOS、iPadOSのシステムカラー」（https://developer.apple.com/jp/design/human-interface-guidelines/color#Specifications）を基本的な色味と設定し、その上でMaterial Designの環境へ持ち込むと、センス関係なく、コントラスト比をある程度確保した形で、各部の色を設定できるでしょう。
ブランドのキーカラーがシステムカラーと近いとか、重要な色、プライマリーカラーとしたいなら該当する色と入れ替えたり、個別にセットしておいて、tintとshadeも自動生成しておくと、色のバリエーションが増えて良いと思います。
ただ、Sassの環境でHEXからMaterial Designで提唱されている、HCTへ直接入れることは難しそうなので、Material Designのサイト上で生成するか、Figmaにプラグインを導入して生成するか、多少妥協してOklchでカラーパレットを用意するかのいずれかを選択する形になると思います。
色を設定するだけで非常に長いコードを要することとなりますが、こちらで公開されているコード（https://github.com/drwpow/better-color-tools）をほぼそのまま踏襲すれば、HEXからOklchへ変換することは可能ですし、コレらを発展させて13段階あるカラーパレットの中間色（Level60相当の色味）を算出、段階的にLevel0〜Level100までの13色を自動生成する機能も作れます。
ただ、OklabやOklchとHCTの色空間の違いで、明るくする方は微妙に補正を加えないと思った色にならないこともあるので、そこは要試行錯誤でしょうか。
各色のパレットができたら、後述するデジタル庁のデザインシステム、特にスタイルの部分を参考にラベルを振りましょう。
余白はフィボナッチ数列、文字サイズは調和数列
SmartHRさんが出された『ちいさくはじめるデザインシステム』や
調和数列をもとにしたスケールから文字サイズを決定する手法
ハーモニック・モジュラー・スケールのためのSassライブラリとSketchプラグイン
などの記事でも言及されていますが、ハーモニックモジュラースケールを取り入れると、非常に使いやすいパラメータに設定できます。
「分子を8にした調和数列」を用い、中間のサイズが16px、1remになるよう大小サイズを計算するようにしましょう。この時同時に行間も同じ数列で計算するようにしておくと、概ねデジタル庁のデザインシステムと近い数値が算出されます。line-heightの時は、中間サイズは1.5ぐらいが無難でしょうか。
余白の方は8pxを起点にフィボナッチ数列倍で大きくしていくと、バランス良い数値になります。小さくする方は特に言及がありませんが、フィボナッチ数列倍の逆にするというニュアンスで、黄金比の逆数、1/1.618を順番にかけて行けば、バランスは保ったまま小さい数値も取得できると思います。
Sassでやる時は単位は後から設定しておいて、データを引っ張るときに単位もつける形の方が、コードの効率は良いかも知れません。現在の我々のコードではそこまで至っていませんが……。
そして算出できた余白を使って、外側のWrapperをセットしています。
読み物の幅は最大40文字（em）で`margin: auto;`を設定しますが、それより大きなWrapperはYahoo! Japan等を踏襲してmax-widthを設定するのも良いですが、昨今のモニターサイズを考えると狭くなりすぎる印象もあるので、モニターサイズに合わせて両幅16px〜104pxの余白を持たせるように設定しています。
clamp関数を入れ子にすることで最大値、最小値も動的に変更できますが、結構トリッキー？
生成できた文字サイズは、デジタル庁のスタイルに合わせて大小のラベルを割り振っておくと更に使いやすいかと。line-heightやletter-spacing、角丸の設定なども概ねデジタル庁のスタイルで良いと思います。
最終的には、デジタル庁のデザインシステムに当てはめる
色んな方法で設定データを自動算出する仕組みを構築していますが、最後の最後はデジタル庁が公開しているデザインシステム
をお借りして、Figmaで開いた時のスタイルの設定と、Material Designが提唱している色設定とを照らし合わせ、どこにどれを用いるかをピックアップしていきましょう。
Material Designが提唱している13段階の色味にきちんと則れば、ダークモードで切り替わっても見た目の印象をある程度保ちながら、十分なコントラストを保った配色をキープできるはず。背景色を設定するときには、テキストのカラーも一緒に変更するようにしておいて、中の要素は要所要所で`currentColor`を用いるようにしておくと、調整は更に楽になるでしょう。
ビビットな配色を保ちたいところはAppleからお借りしたカラーのまま使うようにして、ダークモードの場合の配色も、Appleが提案するままの色を使ってしまうのが無難ですが、ブランドカラーに関してはダークモード用に色を微調整した方がバランス良いかも知れません。
それでも最後はヘルパーが活躍しちゃう
こうやって整えた環境、オレオレフレームワークはそれなりに汎用性が高く、先月後半で必死に改修を進めたサンプル事例を作り変える場面でも、かなり活躍してくれました。余白や文字、配色に関してはほぼ無調整で使えるレベルだとも思います。
ただ、デジタル庁のデザインシステムを確認された方はお分かりかと思いますが、見出しに相当しそうなスタイルでも、デフォルトでフォントの太さに言及するような記述がほぼありません。取り回し、再利用性を考慮したら、それがベストだと言うのも、感覚的に分かりますよね。
テキストの右寄せだの左寄せだのもそうですし、コンテンツの最大幅をコントロールするのも、ブロック要素を左右、あるいは中央に寄せるのも同じで、結局はmodifierを増やすのが良いか、ヘルパーを足すのが良いのか、みたいなお話に落ち着きます。
再利用性、規格化をある程度進めるべく、デザインシステムを導入してみたところで、最終的な仕上がりはヘルパークラスが盛り盛りの、Tailwindっぽい仕上がりになっちゃいます。（最終的な生成物、出力されるCSSの容量や記述は大きく変化しますが）
CSSの肥大化を防ごうと思えば、プロパティごと、パラメータごとの記述になるのもよく分かるので、どれだけ完璧にやろうと思っても、最後の最後は構造体＋modifierかヘルパーです。始める前に面倒臭い気持ちは重々承知の上で、BEMやアトミックデザインへの落とし込みを考えたベストプラクティス、完璧主義の構築が出来ずに手を動かせないぐらいなら、「後から直す」と気楽に構え、適当な実装から着手してみませんか？
今後も「ラクにできる」を追求します
デザインシステムの導入、構築を始めたばかりのBLUE B NOSEでは、まだまだ小汚く効率の悪いコードだらけですが、今後も徐々に工数を減らし、再利用しやすい環境、導入さえすればどんどん構築を進めやすくなる環境の構築を目指し、日々改善を進める所存です。
導入事例のサンプルで出しているものに関しては、構築用のリポジトリもWordPressのテーマファイル向けのリポジトリも公開しているので、本記事の具体的な設定や実装等もそちらからご確認いただけます。
それに加え、今後はHP上でも、工数の最適化やナレッジの共有など、お役立ち情報を発信していきますので、ぜひそちらもご参照ください。
この記事が気に入ったらサポートをしてみませんか？