Designを使ったコンポーネント指向のUI開発:破〜本稿は(序)(破)(Q)のシリーズの2番目の記事(破)になります。Designの実装例を説明していますので、そちらをご覧ください。Design(アトミックデザイン)とは、UI(画面)をコンポーネント単位で設計し、それらを組み合わせて使い回し可能なUIを作成するための手法です。Designの考えのものとUIコンポーネントを切り出していくことはいくつかの利点があります。UIを構築するための方法論でしかありません。独自に考える必要があります。実際に導入してみるといくつか乗り越えなくてならないハードルが存在することがわかりました。本稿(破)ではそのハードルを乗り越えるために、どのような工夫したのかを紹介します。同様に困っている現場の参考になれば幸いです。導入に際してやった3つのことについて説明します。各階層のコンポーネントの仕分け方で悩むことが多かったため、具体的なコンポーネントの定義をして共有しました。※以下でPowerPointという言葉が出てきますが、一旦まずは定義を紹介します。見た目に関することはこのモジュールで表現するPowerPointの一つの図形で表現できるもの(ラジオボタン・セレクトボックスなどのフォームは例外)Molecules(分子)AtomsとMoleculesから構成されるグループで、比較的小さいコンポーネント中身の文言や配置を変えることで使い回しが可能なもの別のOrganismsを跨いで出現するもの、または、これから出現することがわかっているものPowerPointの図形をグループ化して表現するものOrganisms(生命体)AtomsとMoleculesから構成されるコンポーネント広告のバナーのように、どのページに配置しても意味がわかる独立したコンポーネントデザイン上初めてでてくるもので、比較的小さいコンポーネントだが使い回すかどうか不明なもの。(未知の生命体)幅を固定しないとデザイン通りにならない、使い方が限定的なもの。PowerPointの図形をグループ化して表現するもの。概念ではAtomsの粒度は、ラベル、入力フォーム、ボタンなどHTMLタグレベルになります。実装していると、ラベル単位では粒度が細かすぎるように感じました。粒度が細かすぎるとそれをコンポーネント一覧に登録することが手間だし、増えすぎてコードの見通しも悪くなります。そこで、細かすぎずチーム全員が「これは最小単位のモジュールだ」と機械的に判別できる何かを探して辿りついたのがパワポの図形です。パワポの図形を使って以下のようにatoms(原子)を定義しました。パワポの図形をグループ化してつくる単位この考えでいくと、例えば次のように仕分けすることができます。Atoms(パワポの図形1つでつくれる)Molecules(パワポの図形をグループ化してつくる)上の例ではAtomsにもMoleculesにもbuttonがあります、これをつくることでボタンの中にアイコンをいれたボタンをつくりたい場合に、最小単位のアイコンを、最小単位であるはずのボタンが制御しなければはならないというジレンマを解消します。これにより、Atomsのbuttonは内側にあるアイコンの位置などは指定せず、色やフォント、シャドウのみを表現することに専念し、最小構成に保つということを守りつつアイコンや他のUIパーツを組み合わせたボタンを作成することができます。図形をグループ化して作ったコンポーネントの中にあるプレーンな「タイトル」や「テキスト」はグループ化して作ったコンポーネントの要素にします。グループ化した後の「タイトル」と「テキスト」はAtomsとして切り出すのではなく、cardの「タイトル」と「テキスト」になります。しないと、結局Atomsの粒度が細かくなりすぎてしまうためです。パワポの発想はチームの体制が関係しています。UI/UXディレクションとビジュアルデザインをやる人が別だったため、下のようなフローで作業していました。1UI/UXディレクターがパワポの図形を使ってワイヤーフレームを描く2それを基にデザイナーがデザインカンプをつくる3フロントエンドエンジニアがマークアップ画面をつくるときの起点はUI/UXディレクターで、UI/UXディレクターは図形をグループ化したり、コピペしてワイヤーフレームを作成していました。そこで、コンポーネントをパワポの図形単位で考えるといいのではないかと思いつきました。Designの悩みどころにMoleculesとOrganismsの判別があります。概念では「Moleculesは比較的単純で、Organismsは複雑で大きいコンポーネンント」であるとしていますが、判断できないコンポーネントが出現し、その都度悩みます。そこで、まずOragnisms(生命体)について調べてた結果、独立したコンポーネントと考えるのがよいと感じました。具体的には「広告バナーのようにどの別のページでもそのまま使えるもの」です。下からフェードインしてきたり、フローティングしてたり、埋め込まれてたりと大小様々な広告がありますが、どの画面にでても意味が通じます。広告には必ず訴求文が存在します。画像でもいいのですが、訴求文があるか、ヘッダーやフッターなどなくても意味がわかるコンポーネント、それを独立したコンポーネントとしました。次に、Molecules(分子)は適当につくると無駄に膨れ上がってしまうので「Organismsを跨いで使われている、使われる可能性があるもの」としました。親子コンポーネントの子コンポーネントに相当しますが、親から離れて別の親にも付いて行っちゃう子です。最後に、Organismsの子コンポーネントとして切り出したが、今後別のOrganisms内で使われるかわからない場合(Moleculesにするか悩む場合)があります。そんなときは、未知の生命体ということで、一旦Organismsにすることにしました。安易にMoleculesにせず、一旦Organismsにして、Organismsを跨いで使うようなコンポーネントだとわかればMoleculesにリファクタします。悩む時間がもったいないし、Moleculesにしても使わない可能性が高いからです。ここまで説明した仕分け方法をフローチャートで表現すると以下のようになります。導入に際してやったこと2:コンポーネント一覧の作成コンポーネントを作りすぎると、探すのが大変になりました。増えていくと、探すのをあきらめて新しいファイルを作成してしまうかもしれません。デザイナーも忘れて新しくデザインしてしまうかもしれません。この問題に対しては単純な話ですが、コンポーネント一覧を作成しました。DesignのUIコンポーネントを一覧化に使えそうな3つのツールを紹介します。どのツールを使うかはデザイナーの有無と使用しているフレームワークによって変わってきます。ZeplinSketchでデザインしたコンポーネントをエンジニアとシェアすることができます。デザイナー主導になります。デザイナーのスキルが必要です。Frost氏が数名の開発者と開発したオープンソースのツール。React、Vueは不要ですが、あくまでスタイルガイドなため、メンテが大変かも。Sketchと合わせてつかう方法が以下の記事で紹介されています。POSTDStorybookReactやVue.jsを使用しているプロジェクトではおすすめです。Nagisaのすゝめ本シリーズ(Q)では、Storybookを用いた具体的な開発例をご紹介したいと思います。いうものを提唱しています。コンポーネントを分解してKeynote等でリスト化する手順を説明しているもので、コンポーネントがチーム共通の認識で正しく切り分けられているかを振り返りには有用かと思います。開発前はKeynote等でもいいかもしれませんが、Web上で確認できるようしておいた方が使い勝手がよいかと思います。上で紹介したツールはどれもWeb上で確認できるツールです。導入に際してやったこと3:デザイナーとフロントエンドエンジニアで認識合わせデザイナーとフロントエンドエンジニアで進め方の認識合わせを行いました。やったことは主に次の3つです。先述した定義をデザイナーとフロントエンドエンジニアで共有します。Desingの考え方で階層分けされるとフロントエンド実装ではとても助かるので短絡的に導入しがちです。デザイナーからするとパーツからつくっていくのはかなり難しいため、デザイナーの理解が必要です。コンポーネント指向でデザインするのは大変なので、開発初期はデザイナーは今まで通りページ単位でデザインし、フロントエンドエンジニアがUIコンポーネントに分けるフローにしました。のちのちUIコンポーネントが溜まってきたらUIコンポーネントを使いながらデザインしたり、慣れてきたらデザイナーがコンポーネント分割をやることを目標にします。Designを導入する目的は、UI(画面)をコンポーネント単位で設計し、それらを組み合わせて使い回し可能なUIを作成するためです。すれば、(私の現場に限った話ですが)ゆくゆくはUI/UXディレクターもOfficeの図形でお絵かきではなく、コンポーネント一覧からコンポーネントを選び出しデザイナーなしでデザインカンプをつくれるようになるだろうし、さらに将来的にUI/UXディレクターが何かしらのツールで組み合わせたらマークアップも終わっている状態もつくりだせるとかもと思っています。....}といった3段階まではmodifierを用意して変えられるようにしておきます。拡張できるのはその段階までとデザイナーと認識あわせしておき、デザイナーはそれ以上の幅を持たせないように気をつけます。3エンジニアからフィードバックするコンポーネント切り出しをエンジニアが担っているならば、既にコンポーネント化しているかどうかはエンジニアが発見しやすいです。段階的な拡張の範囲外だったり、意味合いとして一緒なのに微妙に違うデザインを発見した場合は、エンジニアからデザイナーにフィードバックするよう心がけます。(破)のまとめ実際に導入してみて出てきた問題点に対して工夫したことを紹介しました。Designの理論と実装にはいくつか折り合いをつけなくてはならない点がありそうです。Designが再注目されています。Design実装の紹介と、フレームワークを使わない従来のHTMLとCSSだけでやった場合の両方をご紹介します。Designを使ったコンポーネント指向のUI開発...本稿は(序)(破)(Q)のシリーズの3番目の記事になります。Designを使ったコンポーネント指向のUI開発:破〜月別アーカイブHPスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。