[付属参考記事] Web制作者の行動分析と考察／HCDCモデル図が出来るまで
はじめに
この情報は、別の記事で紹介している「HCDCモデル図」がどのように作られたか。という背景説明に該当するものです。情報の最初からご覧になりたい場合は以下を先にご覧ください。
1段上のCSS設計・コーディングの概念図（HCDCモデル図）
HCDCとは、Human Centered Data Categorize の頭文字を取ったもので、制作者（人間）中心にコーディングを捉え、汎用性を意識した「分類」のことです。
この「分類」をもとに図化したものが「HCDCモデル図」となります。
この記事では分類の方を中心に説明します。
HCDCは恣意的にならないよう複数の制作者の意見を聞きながら分類していますが、何かを定めている以上、偏りが無いとは言えません。もしこの記事の内容が「根本的に違う」と感じたなら、そこから作られたHCDCモデル図もマッチしない事になり、逆に、HCDCモデル図はマッチしそうだが詳細が知りたい。といった場合は、こちらの記事で何か繋がるかもしれません。
また、以前投稿した「HTML+CSSコーディングの言語化」を背景としていますが、これよりも狭い範囲、切り口において分析・分類しています。
※この記事は標準化ノウハウ公開の一環として書いています。仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。
4つの分析・考察内容
HCDCによる分類内容は以下の通りです。
それぞれのセクションにて詳しく説明します。
-
作業ステップ
… 作業着手から実装までの制作ステップ -
データの役割
… コーディング時のデータ取り回しに必要となる役割 -
情報粒度
… 部品の使い方や粒度についての分類 -
堅牢性と再利用
… グローバルな影響を回避するための策と、再利用の要望をふまえた分類
1・ 作業ステップ
まず最初は、作業ステップについての分解・分類です。
制作者が完成予想図や全体の構成表などの資料を受け取り、全体ボリュームの把握や確認が終ったその後、どのような行動をおこなうのかをリスト化しました。
これらは、ほぼ同時におこなっているものになりますが、やっている事を疎結合で分解していくとこのようなステップになる。というものです。
以下のようになります。
6つのステップ
- 情報分解
- 粒度考案
- 命名考案
- 堅牢性と再利用の考案
- 制作管理・考案
- 実装
ステップの説明
- 1・情報分解
- デザインやワイヤーフレームといった完成予想図をコードで再現するために、まずは大きな情報の区分を確認しながら分解しているはずです。そうでなければ、効率的にコードに起こせないためです。
- 例えば、ヘッダーやメインエリア、フッターなどの大きな区域。そして、ブランディングエリアやナビゲーション。コンテンツエリアはどこからどこまでが１つの区域になっているか。など、ページ間の共通性も踏まえながら、視覚情報を情報の属性によって分解します。
- 2・粒度考案
- 近年のコーディングではWebページの視覚情報を部品やパーツとして捉えて管理する方法が主流となっています。このため、情報属性による分解とほぼ同時か、区分が終わった後に、どの粒度で部品化するのか（≒どの区切りでSassファイルに切り出すか）を考えるはずです。
- 大きな塊で影響を閉じてしまうのか、小さなパーツをグローバルに再利用するのかも考えるでしょう
- 3・命名考案
- どの粒度で部品化するかが決まれば、HTMLの記述を想定しながら、どの部品にどういった名前を与えて管理していくかを考案します。この時、次に記載する堅牢性と再利用設計も同時におこなうかもしれません。
- 4・堅牢性と再利用の考案
- セレクタの使い方とグローバルな再利用、HTMLの記述など、前ステップの2、3とも絡んだ複雑な設計ポイントになります。これについては別項にて考察・分類します。
- 5・制作管理・考案
- コードを記述するためのファイル名とそのファイルを管理するための方法を考案します。概念と設計が予測しやすくなるようにファイル構造を考える必要があります。
- 6・実装
- 上記を設計した後、もしくは同時に進めながらコードを記述します。 文書構造、見た目、働きという3種類を一つのWebページの中に融合していく作業といえます。
これらは、モデル図に直接影響するというよりも、何が必要かを行動ベースで把握するためのものです。
作業時の基本ステップであると同時に、後の手法構築のときに「何を定めておけば、制作者同士の意識を一致させられるのか」のマップにもなります。
2・ データの役割
つぎに、視覚情報や働きをコードに置き換えていく中で、「必要になる役割」を分類します。最小数で分けると以下のようにまとまります。
3つの分類
-
A・視覚情報や働きをつくりたい
… 視覚情報や働きをレンダリングするためのもの。実体。 -
B・部品を「塊」で制御したい
… 中身に部品を配置して位置決めやカラム落ちの制御をおこなうもの。入れ物。 -
C・コーディング用に便利に使える働きが欲しい
… AとBを便利に拡張するためのもの。利便性。
分類の説明
A ・ 視覚情報や働きをつくりたい
デザインを再現するための部品で、基本となる役割です。写真や見出し、テキスト、リスト、表、ロゴやナビゲーションなどの視覚情報が該当し、部品に付帯する動きなども含まれます。
CSS視点では「意匠用のスタイルを与えるもの全般」と言えます。少々強引ですが、もし、同じ視点でHTML側を見た時には、imgやp、h1～6、ul tableといったタグがこの要求にマッチするでしょう。
B ・ 部品を「塊」で制御したい
「A」の部品をコード上でひとまとめにして位置を制御したり、レスポンシブ時に便利に動かすための「枠」です。中に入る部品の大小は関係ありません。
コンテンツセクションに対するヘッダーやフッター、グリッドシステムのような透明な箱、サイドカラムを制御するための大きな仕切り、部品のラッパーやインナーなど、いくつか欲しくなる役割があります。
同じ視点でHTML側を見れば、divやsection、header footer main articleなどの範囲に意味付けするようなタグがこの要求にマッチするでしょう。
C ・ コーディング用に便利に使える働きが欲しい
後付けで加えられるような便利な役割のものです。具体的な例で言えば、ステートのclassであったり、単一プロパティで色やサイズを変えるなどのヘルパー系class等です。
マルチクラスで加える事もあれば、BEMのように変化も命名の一部とするパターンもあるでしょう。同じ視点でHTML側を見れば、i b u mark brやrubyなどが該当しそうです。
※上記、3種類の説明の中にHTML視点の説明がありますが、この例は半ば強引に区分けした例です。仕組み全体には影響しませんが、ものの見かたを変えればこうなる。程度の情報として捉えてください。
3・ 情報粒度
3つめは部品の粒度に関する考察です。
近年の一般的なコーディング方法としては、完成予想図などの視覚情報をコードに起こすために、情報をグルーピングして塊として切り出します。
なぜ切り出すかというと、その塊に名前を与え、部品と捉えてスタイリングするためです。この流れの中で「主となる情報の塊」と「構成する部品」という考え方が出てきます。例えば以下のようなイメージです。
何かの部品は、より大きな何かの構成部品です。オレンジ枠のように、「これ以上は他と同じに出来ない区画・塊」があり、それらの集まりで「Webページ」となっています。
これらの分類（分解）において、欲しくなる区分はおおよそ以下のようになります。
2種類の区分と4つの分類
A ・ 情報属性による自立性の高い領域・区画
- 1 ・ 独立した情報の塊 … オレンジ枠
B ・ 何かの一部として構成される部品
- 2 ・ 中程度の部品 … 緑枠
- 3 ・ 小程度の部品 … 赤枠
- 4 ・ 最小の部品 … 水色枠
捕捉説明
これらの分類は「粒度」という言葉で表すのが一般的になっています。粒度とは、元は「粒の大きさ」という意味の言葉ですが、コーディングにおける粒度とはレンダリング時の面積だけに依存せず、また、コード量だけでも判断できない抽象的な意味で使われます。粒度に言及した有名な仕組みはAtomicDesignですが、上記はAtomicDesignとは似て非なるものとお考え下さい。
4・ 堅牢性と再利用
最後は、スタイリングのアプローチに関する分類です。
誰もが「破綻しにくく、効率の良い状態でデータを管理したい」と考えることでしょう。
スタイリングのアプローチは、分解していくと堅牢性を高める方向と、コード再利用による効率化という二つの軸がありますが、どちらも必要になるケースもあります。
言語仕様の側面と、著名なCSS設計手法の本質部分を抜き出し、根本が異なる3つのパターンに分類しました。
3つのパターン
-
汎用部品の再利用
… スタイリング済の完成品を、グローバルに再利用するアプローチ -
HTML上の包括要素へのセレクタ
… 先祖要素の名前から、包括した部品へのセレクタを使ってスタイリングするアプローチ -
要素命名の工夫
… 命名の工夫による重複リスク低減と、詳細度を低く保つためのアプローチ
パターンの説明
※ 仮に、「text＝短いセンテンスのテキストデータ」と定め、これをもとに説明します。
1・汎用部品の再利用
HTMLとCSSの仕様上、class属性で名前を与えれば全てが再利用可能な部品となります。しかし、制作者中心に考えると、「再利用出来る状態にある」のと、「再利用したいかどうか」は全く別の次元の話です。
「1・汎用部品の再利用」の例は、制作者が部品を完成状態で再利用したいと望むパターンです。この場合、どこに置いてもスタイルが有効になるよう、命名を第一セレクタで指定してプロパティを記述するでしょう。
<span class="text">一行の短いテキスト</span>
<span class="text text-accent">一行の短いテキスト</span>
.text {
font-size: 0.75rem;
line-height: normal;
}
.text-accent {
color: orange;
}
つまりは、OOCSSが提唱する方向にあるアプローチという事になります。
2・HTML上の包括要素へのセレクタ
子孫(子)セレクタを用いて、HTMLコードで包括した内部要素をスタイリングする方法です。
.blockNameという部品の中に.textの要素を記述し、.blockNameからの子孫セレクタでスタイリングしています。
<div class="blockName">
<span class="text">一行の短いテキスト</span>
<span class="text text-accent">一行の短いアクセントテキスト</span>
</div>
.blockName {
padding: 1em 2em;
background-color: gray;
}
.blockName .text {
font-size: 0.75rem;
line-height: normal;
}
.blockName .text-accent {
color: orange;
}
.text {
/*グローバルなスタイルは与えない*/
}
これにより、子孫セレクタの条件に当てはまらない場所に.textを設置しても同じスタイルは適用されません。言い方を変えると、.textはグローバルに再利用できない（制作者はグローバルな再利用を望んでいないためこのようにしている）とも言えます。
この方法は、ともすれば様々な「意図しない影響」を生む原因となりえますが、古くから使われてきた一般的かつ有用なアプローチです。※なぜ意図しない影響が出るのかについては、書籍やWebなどで沢山の情報が見られるため、ここでは割愛します。
3・要素命名の工夫
要素命名を工夫することによって、堅牢性を高めながら詳細度を低く抑える試みです。有名なものはBEM記法です。「名前空間(親の部品名)＋内部構成パーツ名」でサイトの中で命名を一意化し、重複のリスクを回避します。
以下のような記述になります。
<div class="blockName">
<p class="blockName__text">一行の短いテキスト</p>
<p class="blockName__text--accent">一行の短いアクセントテキスト</p>
</div>
.blockName {
padding: 1em 2em;
background-color: gray;
}
.blockName__text {
font-size: 0.75rem;
line-height: normal;
}
.blockName__text--accent {
font-size: 0.75rem;
line-height: normal;
color: orange;
}
textの意味は、「短いセンテンスのテキストデータ」と定めましたが、上記の例ではBEM記法により単語が連結され、別の文字列blockName__textになっています。
機械であればこの二つを別の文字列として捉えますが、制作者はtextの意味を理解・認識したままです。つまり、「textという命名と、その名前が持つ意味を再利用して、別の要素の専用部品にした」 と言えます。（この例では、利便系にあたる.accentも同様です）
また、上記とは感覚が異なるものになりますが、プレフィックスを付与することでも、同じ名前を再利用できます。例えばtext → .c-textといった具合にです。textと.c-textは、機械から見れば別のものですが、人はその役割を予測・理解できます。
組み合わせや利用方法
このように、3つのアプローチはそれぞれ異なる特性を持ちます。いずれにしても「命名」を中心に考えるとそれぞれのアプローチに辻褄の合う説明ができます。
細かく考えれば他にも沢山のアプローチは思いつきますが、いずれも3種類からの派生として収まるのではないでしょうか。
どれを主とするのかは、サイト種別やデータ物量、同一部品の流用や類似部品の多さなどによって判断しなくてはならないでしょう。例えばページ数の少ないコーポレート系のサイトと、大規模なシステム管理画面では、理想の設計は異なるものになるはずです。
どれを使っても言語仕様上の「不正解」ではありません。何を使って何を制限するのかは、CSS設計手法やガイド・レギュレーションによって制作者が定めることになります。
分類の整理と図化
ここまで、様々な行動や欲求について分類してきました。
情報を正規化して図に起こすと、以下のようになります。
上記の4つのデータ分類にアルファベットで名前を与えたものが「HCDCモデル図」です。
関連情報
クレジット・その他
Ultimate Coding
概要・前提事項
- 設計・考案／構築／記事投稿
- @croco_works - Twitter
- 設計パートナー／技術検証
- @wildwest_kazya - Twitter
この仕組みは、組織所属時に業務効率化のために構築したものであり、許可を得た上で設計者本人が個人活動として公開しています。商用の制作や開発には利用していただけますが、仕組みを販売したり媒体化するなどの、制作以外での商用利用はご遠慮下さい。質問その他、何かあれば@croco_worksまでお声かけください。
Author And Source
この問題について([付属参考記事] Web制作者の行動分析と考察／HCDCモデル図が出来るまで), 我々は、より多くの情報をここで見つけました https://qiita.com/croo_works/items/9a0698097fba2312b9ad著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .