CSS Nite LP2 小久保さん(bA)のセミナーメモ
2006年12月08日
CSS Nite LP2で受講した小久保さんの回のアジェンダメモ。
いつものようにあくまで個人的なメモなので、よろしくお願いします[謎]
ーーーーーーーーーーーーーーーーーーーーーーーーーーー
「コンポーネントベースのWebサイト設計と開発」
今日の小田
コンポーネントベースのWebサイト設計と開発
大規模サイト開発の経験から生まれた開発手法
1.何の為のCSS？
CSSの何が嬉しいのか？
よく聞くフレーズ
「情報とデザインの分離」
それって本当？
CSSオフの時ってデザインされていない？
マークアップもデザイン
マークアップとは、ただの文字列に意味付けをする行為
意味付けというのは一定で普遍的なものではない
より伝わる為に意味付け
「誰に」「何を」「どういう風に」
それってデザインではないの？
だとしたら「情報構造」と「外観デザイン」の分離が正しいいいかたでは？
じゃぁ、CSSは一体なにがうれしいのか？
実は「外観情報の抽象化」が出来るのでは？
実装例を見ながら考えてみる
（写真参考）
つまりこれはどういうことか？
つまり「外観情報の抽象化」が行われている
多くの人は明示的に意識はしていない
しかしなんとなく感じている
だからCSSを使っているのでは？
→明示的に意識することで、この「抽象化」の恩恵に預かろう
2.情報構造の抽象化
HTMLには情報の抽象化の仕組みがない
一書いたHTMLのフォーマットを再利用できない（コピペするしかないから）
HTMLに元々ある要素
元々HTMLにある要素はそういう使い方ができる
なぜならそれらの要素は「名前」が付いていて「定義」されているから
カスタムの名前を定義する仕組みはある
例えばclass属性
しかし再利用可能になる訳ではない
ないなら作りましょう
自前でその仕組みをつくればいい
という訳で考えたのがコンポーネントベースの設計
3.コンポーネントベースの制作
すごく簡単にいうと
コンテンツ内で良くある組み合わせをあらかじめパーツとして作っておく
逆に言うと、「あらかじめ」用意されたパーツの組み合わせでページを作っていく事が出来る
進め方
まず意識の共有
コンポーネントの制作
コンポーネントリスト
デザイン
実装
コンポーネントコレクション
コンテンツ仕様書を元にページ展開
コンポーネントリストの制作
以下の３つをベースにまず作ってしまう
HTMLに元々ある要素
過去の経験から必要だと思われる典型的な要素
既存（現行サイト）から洗い出される要素
コンポーネントの分類
（本にも掲載があります）
分類のひな形があると、あまり実装に必要なものとしてはぶれないでいいのかな？と。
コンポーネントリスト
エクセルで作成された、要素名と使い方・使われ方の説明が入っている
また微妙に使われ方が変わる（カラースキームなどの違い）によってバリエーションとしてカウントしていく
各コンポーネントについて定義すべきこと
名前
外観
説明
分類
ソース
コンポーネントコレクション
定義されたコンポーネントの情報は一カ所に集約して共有出来るようにする
それを「コンポーネントコレクション」と呼んでいます。
それは、「見た目」を反映できるのであれば、HTMLベースでも、専用アプリでもなんでもいいので、集約する。
コンポーネントの利用
単に集約しただけでは効率的に利用するのは難しい
コピペだとミスが生まれる可能性もある
そこでDreamweaverのライブラリの活用
Dreamweaverのライブラリの活用
簡単で便利だけど、編集可能領域が作れない（→verUpに期待）
4.導入するときのポイント
「コンポーネント」の定義タイミングが遅い
コンポーネントの定義が曖昧なまま、コンテンツ仕様書、デザインPSDなどの成果物ができる
作業者は、前段階の成果物を受け、独自の解釈で要素を抽出して作業する
「これは見出し、本文、リード？」・・・・・・などなど
効率よいコンポーネント開発には
始めにつくる！
全員で共有をする
メリットとデメリット
メリット
工数が読みやすくなる
複数人による同時並行作業が可能
コンポーネント単位で検証ができる
デメリット
縛りだと思ってしまう恐れ
慣れていない事による不安
（コンポーネントの設計が出来ていれば、最終的なアウトプットは早くなるのに、ページ＝成果物が上げられない事によって、逆にコンポーネントを作る時間を削り、返って時間をかけてしまう結果になる）
（急遽入ってもらった場合のコミュニケーションコストの削減にもなる）
