投稿元:
レビューを見る
molecule とか実際には再利用しないコンポーネントの方が多そうだけど、実際に再利用するかどうかよりも、どの階層に入るのかを意識することで、変にロジックと結びついたりとかせずに、責任がきちんと分離されたコンポーネントを書けるようになるところが、このフレームワークのえらいところかなと思った。
読者層を無理に広げずに React で開発経験がある人を想定して書かれているから、読みやすいし実践的だった。
投稿元:
レビューを見る
コーディングと同じように、関数を切り出す、機能を切り出す感じで、デザインも切り出して管理することで堅牢になるんだな。
投稿元:
レビューを見る
書名のデザインフレームワークを解説した一冊。デザイナーやUI/UXからやや遠い業務の担当なので少しでも理解できればと読んでみた。小さい単位で開発し、それを部品のように組み合わせるのはUI設計にも通じる考え方だったのか。AbemaTVのような大規模サービスで使われているという実績も頼もしい。
投稿元:
レビューを見る
・Frontend Frameworkの隆盛からComponent志向の転換
・サイロ化を排した組織論からデザイナーとプログラマーのコミュニケーションが増加したこと
などの急速な変化の中で、Atomic Designという1つの指針が生まれたのは必然にも思う。
Atomic Design自体はあくまで1つの指針であり、抽象的なものだ。
そのため購入前は「ふわっとした感じだろうなぁ?」と思いながら必要に迫られて購入した。
が、良い意味で裏切られることになった。
本書ではその考え方から、具体的なReactのサンプルコード、Storybookを使った開発やフロントエンドのテスト手法などを余すことなく書き記している。
そのためAtomic Designだけでなく、「最先端のFrontend開発」について具体的・体型的に学ぶことができる内容だった。
何よりReactのサンプルコードが美しく、純粋にコーディング指針としても勉強になる点が多くあった。
あくまで今にフォーカスした内容で1年後に読むような内容ではないと思うが、急速なフロントエンドの進化に追いつくためにも得るものが多い本だった。
投稿元:
レビューを見る
UIコンポーネントベースで開発をするフローというのに、長年課題を感じているので読了。
AbemaTVのフロント開発では本書のような開発が行われているらしい。
Atomicはまさに原子的なという意味で、UIの責務をきちんと分割し、最小のAtom単位でコンポーネントをデザインし、それをリスト化、きちんとテストもこなしてリリースできるようにすることで、非エンジニアや非デザイナーでもGitを使PRで修正が出せるというある意味現時点での理想形のフローだった。
中のReact実装は比較的読み飛ばしたが、そこも含めて確認できる本書はかなりよかった。
■目次
はじめに
第1章 UI設計における現状の問題を振り返る
1-1 アプリケーションのUIに求められる直感性
1-2 UI開発の現場1:JavaScriptの進化
1-3 UI開発の現場2:CSSの努力
1-4 UI開発の現場3:スタイルガイドの普及
1-5 UI開発の現場4:デザインカンプ・ファーストなUI開発ワークフロー
1-6 UI開発の現場5:UIフレームワークの普及
1-7 UI開発の現場6:Single Page Applicationの普及
第2章 コンポーネント・ベースのUI開発
2-1 なぜコンポーネント・ベースで開発するのか
2-2 堅牢なUI開発を実現する
2-3 開発作業を効率化する
2-4 コンポーネント・ベースUI開発がもたらすユーザー・メリット
2-5 コンポーネント設計の基本を知る
2-6 コンポーネント・ベースUI開発の現状
第3章 Atomic DesignによるUIコンポーネント設計
3-1 Atomic Designとは
3-2 UIコンポーネントの分割基準を考える
3-3 Atoms(原子)を設計する
3-4 Molecules(分子)を設計する
3-5 Organisms(有機体)を設計する
3-6 Templates(テンプレート)、Pages(ページ)
第4章 UIコンポーネント設計の実践
4-1 開発環境を準備する
4-2 UIコンポーネントの設計を考える
4-3 UIコンポーネントを実装する
4-4 コンポーネント実装におけるポイント
4-5 コンポーネントに適切なスタイルを与える
4-6 アプリケーションにおける統一性担保
4-7 UIコンポーネントを適切に命名する
4-8 アプリケーションとコンポーネントを接続する
第5章 UIコンポーネントのテスト
5-1 テスタブルなUIコンポーネントを作って高速で堅牢な開発
5-2 UIコンポーネントの単体テスト
5-3 リグレッション・テスト
5-4 ロジック・テスト
5-5 インタラクション・テスト
5-6 コード・カバレッジ
5-7 レイアウト・テスト
5-8 パフォーマンス・テスト
5-9 インクルーシブ・ユーザビリティ・テスト
5-10 A/Bテスト
5-11 CIツールを利用して継続的に自動テストする
第6章 現場におけるコンポーネント・ベース開発のポイント
6-1 エンジニアとデザイナーの問題解決におけるアプローチの違いを知る
6-2 デザインカンプとコンポーネント・ベース開発のかい離を解決する
6-3 長期の開発でコンポーネント・リストを死なせない工夫
6-4 平行実装で開発を加速する
6-5 小規模プロダクトにおけるコンポーネント・ベース開発のメリット
6-6 Webフロントエンドエンジニア以外の関心を引��
6-7 サービスに合わせてAtomic Designをカスタマイズする
6-8 サービスのフェースに応じて進化するデザイン・システム
投稿元:
レビューを見る
Atomic Designの解説書。Atomic Design 自体が機能についてのデザインの話なので当然ともいえるけれど、内容はかなり実装より。最初にAtomosやMoleculesといった特有の概念を解説した後は、Reactを利用した具体的な実装を通して設計から開発、テストまで解説となっている。内容盛りだくさんのため細かい実装部分についてはサンプルに頼ってる感じはあるけれど、内容は実践的でストーリーブックを利用した開発や、ユニットテストだけにとどまらないリグレッションテストなども含めた包括的なテストについても大きく紙幅をとっているのが良い。フロントエンド開発をするものにはとても学ぶところの多い有益な本。
投稿元:
レビューを見る
デザインのお勉強。
■コンポーネントの4つの特徴
1.カプセル化されている
2.置換可能である
3.再利用可能である
4.コンポーネントを別のコンポーネントを組み合わせて作成可能である
CSSの修正をデザイナー自身が行えることは、エンジニアにとってもデザイナーにとっても大きなメリットがあります。最終的なUIの見た目に責任を持つのは、デザイナーであることが多いです。エンジニアが見た目を変更するためにCSSを修正すると、エンジニアは、デザイナーを空いている時間に捕まえて、変更を確認してもらう必要があります。もしそこでOKが出なかった場合、再修正して、またデザイナーを捕まえて、何度も確認しなければいけません。見た目に関する指定は言語化が難しいため、こういったコミュニケーションはくり返されやすいです。
しかし、そのデザイナー自身がUIの見た目を実装レベルで変更すれば、リアルタイムで変更を確認できるため、二者間のコミュニケーションによる確認待ち時間は0になります。そして、変更した見た目にデザイナー自身がOKを出した後で、GitHubにプルリクエストすることになるので、エンジニアはコード・ベースのレビューだけに集中できます。UIをコンテナ―・コンポーネントとプレゼンテーショナル・コンポーネントに分離することは、職域ごとの関心も分離できるため、開発フローもスムーズになります。
■基本的な視覚デザイン要素を一元管理する
・余白の大きさ:コンポーネントとコンポーネントの間の余白など
・書体:明朝体、ゴシック体、手書き風など
・フォントサイズ:極小、小、中、大、極大
・色:背景、テキスト、テキストリンク、強調、成功、危険、警告
・アニメーション:持続時間やイメージングなど
・ボーダー:幅、角丸の半径
◇デザインの要素
1.色
2.線(直線、曲線、ジグザグ線、破線など)
3.図形(円形、三角形、四角形などの幾何学的図形や有機的図形)
4.質感・テクスチャ
5.空間(オブジェクト間の空間)
6.フォーム(幅、高さ、奥行きを感じさせる三次元的な視覚情報がある要素)
◇視覚デザインの原則
1.統一
2.バランス(要素の位置や大きさなどの視覚バランスで安定感や躍動感といった印象を制御する)
3.階層(視覚情報の優先度を階層的に整理することで視線をより大事な情報に誘導する)
4.尺度・比率(要素同士の相対的な面積比率を制御することは視覚に心地良いリズムを生む)
5.占有・強調(全体を占める法則を意図的に無視することで焦点を当ててもらいたい要素を目立たせる)
6.類似と対比(各所のデザインを類似させることでユーザーは迷わず情報を探せるが、類似したデザインばかりだと単調すぎて飽きてしまう。重点を置きたい情報には、ほど良く対比的な構造を与える)