だいぶ久しぶりになりますが、今回はあらゆる優れたウェブサイトの持続可能なHTML設計のために押さえておくべき原則についてまとめてみました。
カタログサイトやコーポレートサイトのような階層構造を持つサイト、ブログのような時系列情報が基本となるサイト、ウェブアプリケーションのフロントエンドなどにも、広く普遍的に適用できるように考えました。
基本方針
- サイト全体のデザインの一貫性を重視すること。
- 学習しやすいこと。
- 記憶しやすいこと。
- 繰り返し頻度の高い作業の負荷を優先して下げること。
- 特定の個人に依存せずに運用可能なこと。
- 過去の成果物を機械的に加工する可能性があることを前提にすること。後々から大規模な変更や加工がしやすいこと。
- テストしやすいこと。
全体設計指針
設計者と運用者の役割
チームは少人数の設計者と多人数の運用者で構成されます。
いずれの役割も、特定の個人に依存することなく、非属人的に共有可能な状態を維持します。
設計者優位を基本とする
基本は、部品や運用規則を設計者が決め、運用者はそれを尊守します。
しかし、運用者が利用にあたって新しい課題を発見することは常です。この場合は設計者にエスカレーションし、協議して設計を変更、更新します。
個別ページの特殊表現に対して全体の一貫性が優先される
個別の例外的な表現の自由さよりも、サイト全体のデザインの一貫性や規律を重視し、管理効率を維持するための方針です。
特定の個人に依存せずに運用可能なこと
顔も名前もスキルも不明な多数の第三者が運用することを前提に、誰が使っても理解がぶれないように設計します。非属人性。
誰にでも理解しやすいモジュール名をつけたり、単純で覚えやすいように設計したり、設計者と運用者が集まってレビューを行う機会を定期的に設けることなどが助けになるでしょう。
スキルレベルが最も低いメンバーを基準にする
想定されるメンバーの中で、最も経験やスキルレベルが低い運用者を基準に設計します。
特殊な専門知識をまったく持たない者を想定できる場合は、そうするべきです。
運用者に高い(あるいは特殊な)スキルを求めるほど、メンバーの採用条件が厳しくなり、チーム運営は苦しくなります。非属人性に対しても妨げる要因になるでしょう。
あらゆる要素について責任の所在を明確にする
何かを変更する要求があるとき、どこまでが影響範囲で、誰が合意すれば実行して良いかを把握できるようにします。
例えばディレクトリごとに imgフォルダをおくような習慣は望ましくありません。その画像を、誰が管理してどこから参照されているかわからないので、後々変更したいときに判断できなくなります。(結果、「そのままにしておこう・・・」と結論することになるでしょう)
最も良いのは、全てのリソースを、ページ個別とサイト全体のどちらかに分類すること、かつ、一部の複数のページ間でリソースを共有しないことです。
サイトや管理組織の規模によって、その中間の単位を設けることが適切な場合がありますが、必要最小限にとどめます。
共通要素の影響範囲を広くしすぎない
一箇所の変更の影響範囲が広すぎると、テストに時間がかかりすぎるため、事実上変更できない状況に陥ることがあります。
段階的な適用ができるよう、運用上テスト可能なサイズで分割して管理するのがよいでしょう。
どの程度で分割するべきかについては、チームの管理体制や意思決定、ワークフローなどを鑑みて調整します。
ドキュメントの量は少ないほうが良い
ドキュメントが厚くなるほど、読むこと自体の負荷が上がり、記憶しにくく、学習しにくくなり、結果として属人化につながります。
ドキュメント量は、共有された外部のドキュメントを参照したり、命名規則などから情報を伝えられる設計にして明示を避けることなどで減量することができます。モジュールの数を減らしたり、単純な作りにすることも有効です。
モジュールの設計指針
全ての要素はモジュールであると考える
ページを構成する再利用可能な部品の最小単位 を、モジュール(部品) と呼びます。
例えば、DOCTYPE宣言やHTMLタグを含む大きな部品や、ヘッダー、ナビゲーション、またコンテンツを構成する要素などは全てモジュールです。幾つかのモジュールを並べたり、入れ子構造にするなどして、組み合わせて1枚のページが構成されます。
一度しか利用しない一点物の部品も、やはり部品です。
サイト全体の規則に縛られない自由な表現が求められる場合、それも1つの部品として捉え、全体の規則の中に埋め込み可能なように閉じた空間に実装します。
各モジュールの制約を明記する
運用者がモジュールを使用するにあたり、正しい使い方や禁止事項などが明確に共有されているべきです。
モジュールは極力少ない方が良い
モジュールは不必要にたくさん作らないようにします。
モジュールが複雑だったり量が多いことは、学習を困難にし、属人化の要因になります。
運用者の裁量は小さい方が良い
各モジュールのオプションは必要最小限にとどめ、表現の自由度は低くし、運用者の裁量を可能な限り小さく設計します。
柔軟な設計は、属人的な解釈や用法を引き出すため、全体の規律を管理する効率を下げることにつながり、デザインの一貫性を削いでしまいます。また、大規模な機械的加工も困難にします。
モジュールの命名規則
モジュールのまとまりが明確になるような命名規則を採用する
慣れてきた運用者は、既存のページからソースをコピーして再利用することがあります。このときにも、誤った方法でソースを分解してしまわないように配慮する必要があります。
例えば、BEMはよい設計規則です。
モジュールの命名に連番を用いない
連番は記憶しづらいため、用いません。意味によって命名するべきです。
スタイリングの特徴にちなんで命名することは、あまり望ましくありませんが、特に客観的に連想しやすい特徴がスタイルにしか求められない場合に限り許容します。
利用頻度の高いモジュールは省略して短く、時々しか使われないモジュールはフルスペルで名付ける
繰り返し使う要素は記憶しやすいので、省略されていても意味解釈において不都合はありません。利用頻度が少なく記憶できないモジュールが、頭文字などに省略されていると、意味理解が困難になり、統一的な使い方が崩れていく要因となります。
例えば ボタンを意味する .btn クラスは、button を省略したものです。 .btn クラスはよく使われる要素なので、運用者は .btn だけで button だということを記憶できます。
一方 .hoge-fuga クラスはあまり使われる機会は多くないので、意味理解を記憶に頼るのは困難です。この場合、 .hf などと省略すれば、これの意味を知るために毎回ドキュメントを参照しなくてはいけなくなります。フルスペルで .hoge-fuga としておけば、それが何を意味する要素か、ドキュメントを参照しなくてもイメージできるようになり効率的です。
責任の所在が明確な命名規則を採用する
サイト全体の規則に縛られず自由に表現される要素は、該当ページ個別の空間に実装され、全体の規則の中に埋め込まれて利用されます。 サイト全体に属するものか、ページの個別のものかが判断できるように命名されるべきです。
例えば、 ページ個別に属するモジュールには cont_ 接頭辞を付ける、などの方法があります。
また、このような要素が多数あることは、管理効率を妨げます。少なくとも、サイト全体の中のどこに自由な部品があるかを、機械的に把握できるように設計し、むやみに増やさないよう努めます。
以上です。
これらの原則は、筆者がこれまでにウェブサイトデザインに携わった経験から導いたものです。 2年ほど前に Github 上で検討していたものですが、2019年10月14日時点の内容で転載したものです。
この先も新しいウェブサイトのデザインに適用し、新しい発見があれば更新していきたいと思います。