コンポーネント設計についてもやもやしていたところ、家族と出かけた蔦屋書店で遭遇。少々値が張るので躊躇っていたが、妻の後押しもあり購入。ありがとう。
第1章： UI設計における現状の問題を振り返る
- SPA(Single Page Application) の普及
- そろそろ何かしらフレームワークを覚えたい…
第2章： コンポーネント・ベースのUI開発
- 新規参入メンバーを最短で戦力化できる
- 2つのポイント
- 単一責任の原則
- 関心の分離
第3章： Atomic Design による UIコンポーネント設計
- ユーザーに取ってほしい行動プロセスを整理（＝関心の分離）
- 行動プロセスごとにデザインすべき対象を整理
- Molecules と Organisms の分け方
- Molecules： 他のコンポーネントのヘルパー
- 例えば著者情報やソーシャルボタンなど
- Organisms： 独立して存在できるコンポーネント
- Organisms が 別の Organisms の構成部品だったりするとかなり混乱する気が…
- Molecules： 他のコンポーネントのヘルパー
第4章： UIコンポーネント設計の実践
- React を使った実装は、すぐすぐには使いこなせなさそう
- WordPress と相性のいいものを学習したい。Vue.js？
- レイアウトしやすいコンポーネントのポイント
- 「コンポーネント自身がどのようにレイアウトされるか」という情報を持たない
- position / top / left / bottom / right
- width / height
- margin （padding / border はアリ）
- float / clear
- 「コンポーネント自身がどのようにレイアウトされるか」という情報を持たない
- コンポーネントの命名基準、参考になりそう。
第5章： UIコンポーネントのテスト
- サンドボックス（Sandbox）化： 外界と隔離された状態でテストできる
- お砂場遊び…的な由来
- コンポーネントはリキッド・レイアウトで設計すべき
- いろいろ自動化できるようだが、まだ敷居が高い…
第6章： 現場におけるコンポーネント・ベース開発のポイント
- エンジニアはボトムアップのアプローチ
- 最小単位のコンポーネントを組み合わせる
- まさに Atomic Design
- デザイナーはトップダウンのアプローチ
- 全体像から考え始める
- 特に紙媒体出身のデザイナーに顕著なのでは？
- 「パーツを先にデザイン」することはデザイナーにとって難しい → 解決法は？
- 地道に啓蒙する
- インターフェース・インベントリ
- コンポーネント・リストが時間とともに乖離しがち
- 自動化が理想
- Atomic Design の良いところだけを取り入れる
- Pages / Templates、正直わかりにくい
- デザイン・システムへの発展
- 同テーマの本が出ていたのであとで読みたい
考えたこと
- 実務ですぐに React を使うことはなさそうだが、Virtual DOM や カプセル化の思想は押さえておきたい
- そもそも WordPress ベースの案件で JavaScript フレームワークは導入できる？ → REST API を使うらしい
- “関心の分離”は UXデザイン設計に説得力あるかも。ワークしてみる
- ステークホルダーとの連携は永遠の課題。どんどんカイゼンしたい！
