最初からCSSでデザインを作る
Figmaなどのデザインツールを使わずに、直接CSSでデザインを行う
最近のWeb制作の流れとしては、
デザイナがまずFigmaなどのデザインツールでデザインを作成し、
それを見ながら他の複数人のエンジニアが実装に落とし込む、
という流れを取ることが多い
しかし、最近に書かれた書籍である
や
あたりでは、「最初からCSSでデザインする」ことを推奨している向きがある
このあたりを見てみたい
参考
『WEB+DB PRESS Vol.133』 p.84~
微妙に異なる文脈か？
デザイナがFigma作ってエンジニアに渡すのではなく、デザイナも直接HTML/CSSコードを書いたほうが速いのような内容
関連
Figmaなどのデザインツールが貧弱だから、そもそもCSSで書いたほうが良い、となる
もう少し具体的に言うと、Figma上の表現と、CSS上の表現の乖離が激しいから。
デザインツールがもっと進化して、乖離を小さく出来るなら、そちらを使ったほうが速い、となる
デザインツールはレスポンシブデザインに弱い点がある
これは、
p.84~に書かれていて、なるほど、となった
著者が『Every Layout』の翻訳者でもあるので納得がいく
Figmaなどでデザインをする場合、mobile、tablet、PCなどの主要な画面幅をピックアップし、それに対してデザインを作ることになる
それらの間のデザインは表現できない
できるだけ具体的な指定をせずにCSSを書くというのを徹底して行う
そもそもmediaqueryを使わずに、任意の画面幅に対して適切な見た目になるようにする
これは、「任意の画面幅に対してデザインを考える」という感じではない
こういうふうに見せたい、という意図をCSSで書くだけ
結果的にどういう見た目になるのかは、ブラウザに委ねる
Figmaでも、Auto Layoutを使えば画面幅に応じて変化させたりは出来るが限界がある
例えば、flex-wrapに相当するものがない
デザインツール上ではコーナーケースを表現するのが効率悪い
デザイン時に状態変化を意識するみたいな話をどれだけ細かくやるか？ということ
ON/OFFの状態はもちろん、loading、error、遷移中、アニメーション、など
こういうコーナーケースについては、プログラミング言語で記述するほうが向いている
代数的データ型を用いることで、コーナーケースの洗い出しに役立つ
そういうコーナーケースが生じるかどうかも、実装の方針にも依る
実装を進めていく中で見つけて行くこともたくさんある
Component志向の限界
これも p.84~やここで触れられている
Component志向のlibraryの潮流や、それに付随してAtomic Designが流行った
しかし、そもそもすべてのデザインをComponentで表現することは、本質的に難しいのでは？と問い直す
これはmoleculesなのかorganismsなのか？という不毛な疑問が生じる
見た目が似てるが少し異なるComponentをどう扱うのか
Componentになりえない部分をどう表現するのか
例えば、Component同士のmarginなど
これは同様に、Figmaを見ただけでは、Componentの切り方が自明に決まらないことにも繋がる
同一人物がやるにしても難しいのに、他の人がやるのは本当に困難
デザイナがFigmaを作って、エンジニアがComponent実装したりすると、普通にズレる
いったんはそれで実装できたとしても、
後に変更があったときに、デザイナの意図で行った変更を、今の実装に反映するのが難しい、ということが起きる
Figmaからは意図が汲み取れないことも多い
ロジックの都合と、デザインの都合が異なることがある
これを会話でどうにかしよう、というのも無理な話だと思う
数が多すぎるし、粒度もバラバラなので
それなら最初からそういうコミュニケーションができるような言語で記述されるべき
その言語として、最初からCSSを使う、という発想
最初からCSSでデザインを作るを実践するためには、当然CSSを書くツールが重要になる
サクサク書いて、試行錯誤できるCSSが必要
そのツールとしてTailwind CSSが向いている
サクサク作れるし、Design System的な制限も細部に生きる
また、CSSを書く上でも、できるだけ具体的な指定をせずにCSSを書くようにする指針が必要
その指針として、Every Layoutが向いている
いつデザインツールを使い、いつCSSで作るか？
最初にぱぱっと作って全体的な雰囲気を確定させたいときは、デザインツールのほうが向いていそう
プロトタイプを作って人に見せる場合も速く出来る
ここで、敢えて詳細に作り込まないようにする
詳細な部分はCSSで作る
デザインカンプは使い捨てにする
アイディアを検討するためだけに使う
だいたい固まったら捨てちゃって良い
全てを設計してから実装するのでなく、さっさと実装にとりかかる
実装する中で詳細に気づける
短いサイクルで開発する
次に作るもののかんたんなversionを設計したら、実際に作ってみる
作業と設計を反復する
だからFigmaのメンテとかは必要なさそう
やるにしても最悪スクショとかでいい
リストの幅を縮めたときに、カードの個数を増やすか、カード自体を延ばすかとか