訳も知らないで

デザイン&プログラミングのことも書くし、それ以外のことも書く。

Atomic DesignでWebサービスのフロントエンドをイメージする

Atomic Designというコンポーネントを組み合わせてシステムを構築していく手法がイメージしやすそうだったので、実際にWebサービスのフロントエンドデザインに当てはめるとどんな感じになるのか考えた。

Atomic Designについてはこの辺を参照
Atomic Design | Brad Frost
珍しいワークフロー:Atomic Designの原則とSketchでデザインからプログラミングまで | デザイン | POSTD

CSS

Atomic Designの階層?を意識してスタイルを定義する。

  • ATOMS
  • MOLECULES
  • ORGANISMS
  • TEMPLATES/PAGES

各階層について

ATOMS

最小単位なので、ボタンやリンクといったものから、カラーやフォントなんかもATOMOSとして扱うようだが、 実際にコーディングすることを考えたとき、カラーやフォントといったコンポーネントを修飾するようなスタイル定義はATOMSから外したほうがわかりやすいのでは。

MOLECULES

ATOMOSを組み合わせた、テキストボックス+ボタンのような一つの処理をまとめたシンプルなコンポーネントのスタイルを指す。

ORGANISMS

MOLECULESを組み合わせた、ヘッダーナビゲーションとか検索フォームとか再利用可能なコンポーネントのスタイル。

TEMPLATES/PAGES

各ページごと、もしくはViewファイルごとのレイアウトを定義する。
ファイル名がURLだったりViewファイル名?になるイメージ。

CSSディレクトリ構成イメージ

コンポーネントに関しては↑の階層で整理して、それ以外をbaseやutilsみたいな感じで用意してあげるのがいいかなと。

  • base: サイト全体に及ぶようなベースとなるスタイルやリセットCSS、Sassの変数定義、@import用ファイルなど
  • utils: カラーやフォントなどコンポーネントを修飾するためのスタイル、コンポーネントとは呼べない汎用的なCSSなど
  • atoms
  • molecules
  • organisms
  • templates

実装

コンポーネントCSSCSS modulesなどで実装してあげるとキレイな感じがする(後述のJSから利用する)。
普通にCSS書く場合、CSSがグローバルなことは変わりないので今まで通りBEMとか使うことになるんだろうきっと。

HTML

もしRailsのPartialのようにView(HTML)ファイルが分割できるのであればORGANISMSはPartialに切り出す、みたいな方針にするのもアリかも…と思ったが、ORGANISMS以外の単位でPartialに切り出したいという場面は結構ありそうなので微妙かも。

HTML(Viewファイル構成)は切り離して考えても良さそう。

JS

React.jsやRiot.jsのようなViewも含めてコンポーネント単位で実装するようなものを使っていると、Atomic Designの考え方がそのまま適応できてわかりやすいのでは。 CSSと同じように4階層に分けて実装できそう。

MOLECULESやORGANISMSを実装してコンポーネントを呼び出したり、SPAでTEMPLATES/PAGESを作ったり。 Atomsを実装することはあまりなさそうかな??

スタイルガイド

スタイルガイドでATOMS〜ORGANISMS(+base, utils)の使用例を見れるようにする。

考えてみて

ほんとにイメージ通り実装できるかサンプルを作ってみたいところです(希望)