コンポーネントベースの Webサイト設計と開発 - CSS Nite LP, Disk 2

[ コンポーネントベースの
Webサイト設計と開発
] 小久保浩大郎
(株)ビジネス・アーキテクツ
1/39 [ 自己紹介
] 2/39 自己紹介
• 小久保浩大郎
• 1976年生まれ
• 三重県出身
• (株)ビジネス・アーキテクツに2002年から参加
• マークアップデザインエンジニア
3/39 [ 今日のお題
] 4/39 今日のお題
• コンポーネントベースのWebサイト設計と開発
• 大規模サイト開発の経験から生まれた開発手法 – 大規模サイトじゃないと意味がない、というわけではない – 開発規模を問わず同様に起こっている問題はあるはず – 大規模サイトでは開発の過程で起こる問題も大きくなるの
で見つけやすい – そこで見つけた問題解決手法を汎用的な形にしたもの
5/39 目次
1. 何のためのCSS?
2. 情報構造の抽象化
3. コンポーネントの設計と制作
4. 導入するときのポイント
6/39 [ 1. 何のためのCSS?
] 7/39 CSSの何がうれしいのか?
•
•
•
•
よく聞くフレーズ
「情報とデザインの分離」
それって本当?
CSSオフの状態ってデザインされてないの?
8/39 CSSが有効のとき
これはデザインされている。
9/39 CSSが無効のとき
これはデザインされてない?
10/39 マークアップもデザイン
•
•
•
•
•
マークアップとは、ただの文字列に意味づけする行為
意味づけというのは一定で普遍的なものではない
より伝わるために意味づけするのでは?
「誰に?」「何を?」「どういう風に?」
それってデザインじゃない?
• だとすると別に「情報とデザインが分離」されてるわけ
じゃない
• 正しく言うなら「情報構造と外観の分離」
11/39 HTMLとCSSが担うデザインの領域 HTML HTML HTML CSS
CSS CSS Information Design 「情報構造」
Visual Design 「外観」 12/39 じゃあCSSは一体何がうれしいのか?
• 実は「外観情報の抽象化」ができることが最大の特長
13/39 実装例を見ながら考えてみる
• こんな表を作ってみます。
14/39 各実装例の類似点・相違点
• それぞれの類似点・相違点 – ソースの見た目はAとBが似てる – 情報構造と外観という点ではBとCが同じでAは違う
• Cが決定的に他と違う点 – 外観についての情報が抽象化されている
15/39 各実装例のメリットとデメリット
• 実装例A、Bのデメリット – 同じ記述が重複してソースが肥大化する – 修正の手間が増えてミスが増える – 全体を見通しにくい
• 実装例Cのメリット – 同じ記述をひとまとめにできる – 修正や管理が一箇所に集約できる – 全体が見通しやすい – セレクタを追加するだけで再利用可能
16/39 つまりこれはどういうことか?
• つまり「外観情報の抽象化」が行われている – 多くの人は明示的に意識していない – しかしなんとなく感じてるはず – だからCSSを使ってるのでは? 明示的に意識することで
さらにこの「抽象化」の恩恵に与ろう
17/39 [ 2. 情報構造の抽象化
] 18/39 HTMLには情報の抽象化の仕組みがない
• 価格表のフォーマットを再利用したいと思ったとき
←この表に名前をつけて使いまわせ
るとうれしいけれど… そういう仕組みはないの
でできない
単純にコピペするしかない
19/39 HTMLに元々ある要素
• 元々HTMLにある要素はそういう扱いができる(当た
り前ですが)
• なぜならそれらの要素は「名前」が付いていて「定義」
されているから
• カスタムの名前を定義する仕組みはある
• class属性
• しかし再利用可能になるわけではない
• そういう仕組みがあったら便利そう…
20/39 ないなら作りましょう
• 自前でその仕組みを作ればいい
• というわけで考えたのがコンポーネントベースの設計
21/39 [ 3. コンポーネントの設計と制作
] 22/39 すごく簡単に言うと
• コンテンツ内で良くある組み合わせをあらかじめパー
ツとして作っておく
• 逆に言うと
• あらかじめ用意されたパーツを組み合わせることでコ
ンテンツを作ることが出来る
23/39 コンポーネントリストの制作
以下の3つをベースにまず作ってしまう – HTMLに元々ある要素 – 過去の経験から必要だと思われる典型的な要素 – 既存(現行サイト)から洗い出される要素
24/39 コンポーネントリストの分類
• ブロック要素 – – – – – – – 文書タイトル 見出し 本文 リスト 注釈 表 画像・図版
• レイアウト要素 – – – – 2段組み 3段組み 左寄せ 右寄せ
• インライン要素 – リンク – 強調
• ナビゲーション要素 – – – – – – 前後ページ移動 親階層ページ移動 兄弟階層ページ移動 子階層ページ移動 関連ページ移動 同ページ内移動
などなど
25/39 コンポーネントリストのサンプル
26/39 各コンポーネントについて定義すべきこと
•
•
•
•
•
名前
外観
説明
分類
ソース
27/39 コンポーネントコレクション
• 定義したコンポーネントの情報は一箇所に集約して共
有できるようにする
• それを「コンポーネントコレクション」と呼んでます
• 形式 – HTMLベースのドキュメント – 専用のWebアプリ – WordとかExcelとか – 何らかのドキュメント
28/39 コンポーネントの利用
• 単に集約しただけでは効率的に利用するのは難しい
• コピペだとミスが生まれる可能性もある
• そこでDreamweaverのライブラリ
29/39 Dreamweaverライブラリの活用
•
•
•
•
•
簡単
便利
間違いがない
編集可能領域が作れない
バージョンアップに期待
30/39 [ 4. 導入するときのポイント
] 31/39 過去の経験
• 「コンポーネント」の定義タイミングが遅い – コンポーネントの定義が曖昧なまま、コンテンツ仕様書、デ
ザインPSDなどの成果物ができる – 作業者は、前段階の成果物を受け、独自の解釈で要素を
抽出して作業する • 「これは見出し?」「これはリード? 本文?」など
• 問題点 – 抽出・解釈が何度も行われる – 解釈にぶれが生じる可能性がある
32/39 効率よいコンポーネント開発のためには
• コンポーネントの定義を「最初に」することが肝要
• プロジェクトメンバー全員がその概念を共有する
33/39 進め方
• まず意識の共有
• コンポーネントの制作 – コンポーネントリスト – デザイン – 実装 – コンポーネントコレクション
• コンテンツ仕様書を元にページ展開
34/39 メリットとデメリット
• メリット – 工数が読みやすくなる – 複数人による同時並行作業が可能 – コンポーネント単位での検証ができる
• デメリット – 縛りだと思ってしまう恐れ – 慣れてないことによる不安感 • フローが違う • 最初のページが出来上がるタイミングが結構後の方
35/39 [ 最後に
] 36/39 [ 現在、ビジネス・アーキテクツでは
] 37/39 [ 絶賛人材募集中 ] 38/39 [ ありがとうございました
] 39/39