CSS 関連の記事を眺めて
ぼんやりしてる今日この頃。夏の生ぬるい風を感じながら「へー、うふふ」と思った CSS の記事をまとめる。
目黒で夜な夜な CSS 話がおこなわれているらしい。CSS in ERB in JS とかやってる人がいたっぽい。勉強会に興味があるけど、目黒か... 。
React Component のテンプレートパッケージ（というのか？）。使わないとわからないけど気になる。
グラデーションした要素だからその影もグラデーションする、というのは的を得てるんじゃないかと思う。
CSS 関連の記事を眺めて
ウェブ開発を爆速に！人気オススメCSSフレームワーク厳選38個まとめ【2018年最新版】
38 個もあったのか。Propeller はかわいい見た目してるし、サードパーティ製のものも含めたらコンポーネントの数も豊富。Material Design Lite は本家 Google が開発元で（GitHub のリポジトリ所有者が Google）、マテリアルデザインのガイドラインに沿ってつくられていると聞いて興味津々。Flexbox を使ったグリッドや従来のグリッドが多い中、Smart CSS Grid は display: grid を使ったグリッドのようなので、このフレームワークを使う人は今後増えるかも。
幅広く活用出来るWebサイトテンプレートまとめ25「25 Best Free Website Templates For Launching Your Website Today」
CSS というわけじゃないけれど、覚えておくことで役に立ちそう。また、こういうテンプレートのつくりを見ておくことで普段の制作に活かせる部分も多いと思う。
透過されない PNG 画像や CSS ハックは懐かしい。残念なことに条件付きコメントは消し忘れで残っているのを今でもたまに見かける。
テーブルのレスポンシブ対応。モバイルでは thead の項目を text-shadow を使って反復表示、calc() で配置箇所を決定している。切り替わるテーブルの見た目は良いと思ったけど、見た目が HTML の構造と紐付かなくなるからイマイチかなぁ。同じ見た目で display: table を display: grid にするのはどうだろう。
CSS で絵を描いたりだとか、ヤバイやつ。
Semantic UI Doc ( Collections - Message ) を読む
Semantic UI の Message を読んだ。メッセージにテーマは 3 個ある。
メッセージはタイトルと文章が枠で囲まれた見た目をしていて、近くのコンテンツを説明するのに使う。
いくつかコンテンツのタイプがあり、タイトルと文章の通常メッセージに以下を追加・置き換えすることができる。
- リスト
- アイコン
- 閉じるボタン
また、状態に関するスタイルは hidden と visible の 2 つがある。
以下のように見た目のカスタマイズもいくつかできる。
- 地面から浮いてるような見た目
- 枠をコンテンツ自身の幅に絞った見た目
- 他のコンポーネントにくっつけた見た目
- 警告メッセージの見た目
- お知らせメッセージの見た目
- 成功メッセージの見た目
- エラーメッセージの見た目
- 様々なカラーバリエーション
- 様々なサイズバリエーション
ページコンテンツを冒頭で説明したり、フォームの注意書きを載せたりするのに使えそうだと思った。
Semantic UI Doc ( Collections - Menu ) を読む
Semantic UI の Menu を読んだ。メニューにテーマは 4 個ある。
Flexbox を使ったナビゲーションの集合コンポーネント。
ナビゲーションの見た目はいくつか変更でき、タブのような見た目、グローバルナビゲーションような見た目 、サイドナビゲーションのように縦に並んだ見た目などがある。
コードはこんな感じで、.menu コンテナーとその子要素 .item がある。またナビゲーションのアイテムに吹き出しをつけた見た目にするなど、アクティブ状態を示すためのクラスも用意されている。
<div class="ui three item menu"> <a class="active item">Editorials</a> <a class="item">Reviews</a> <a class="item">Upcoming Events</a> </div>
ナビゲーションにはタイトルの他、説明文章やフォームの入力欄、ボタンやリンクを含むことができる。ナビゲーションのアイテムをマウスオーバー（またはクリック）したとき、ドロップダウンリストやポップアップを表示することも可能。同じ階層のナビゲーションを 2 つ並べることもできる。あとはサブナビゲーションも。
状態は 2 つ用意されており、マウスオーバー状態とアクティブ状態にそれぞれスタイルが当てられている。
ページの最上部にナビゲーションを固定させたり、アイテムを縦に並べたり、反転色にしたり色をつけたり、アイテムのコンテンツをアイコンにしたり、他のコンポーネントにナビゲーションをくっつけて表示したり、オプションもたくさんある。
設定を工夫すればページネーションなどにも使えるコンポーネントなので、使いどころは多そうだ。
デザイン原則をつくって「私たちが考える良いデザイン」を揃える
「デザインシステムを学ぶ 31 日」の 3 日目。今回はデザインシステムの前準備、デザイン原則について。
なぜデザイン原則は必要？
チームでデザインの善し悪しを判断するためにデザイン原則は必要だ。同じチーム内でもいろんな考え方を持つ人がいる中、原則をつくることで「これが私たちの考える良いデザイン」という認識を合わせやすくしておく。
そして、原則を守ってデザインを続ければ、やがてそれは外部からブランドと呼ばれるようになる。一貫された見た目や操作感がサービス全体の印象になるからだ。
デザイン原則があれば、これからつくろうとしているデザインシステムで役立つだけではなく、デザインレビューなど、様々な場面で役立つことになるだろう。
デザイン原則とは何を指すか
デザイン原則とは「チームで考えた "デザインのあるべき論" がまとめられたドキュメント」である。
たとえば Android デザインの原則 には、サービスを操作したときにユーザーに感じてほしいこと、そのために必要な設計方針がまとめられている。
また、デザイン原則ではあまり具体的な話はしない。Design Principles FTW や Design Principles にはいくつかデザイン原則のサンプルがあるが、どれも短い文章とそれを補足する 1 段落程度の文章で各原則が書かれている。あくまで原則なので、デザインを無理に縛り付けるようなことはしていない。
1 人でもデザイン原則は必要？
必要だと思う。
過去と現在の自分は考え方はよく違っていたりするが、デザイン原則のようにひとつ指標があれば、それをもとにして自分の考えを振り返ることができる。また原則を常に参照するようにしておくことで（本当はこれをデザインシステムでやりたい）、個人の制作物にも一貫性をもたせることができる。
デザイン原則のつくり方
実際チームでデザイン原則をつくるやり方を近くで見ていると、以下のようにしていた。
- デザイン原則の役割をチーム（または決裁者）に理解してもらう
- 原則を反映させたい組織やサービスを思い浮かびながら、それがどのようなデザインになっていれば理想かチームでアイデアを出し合う
- 話し合ったときに出てきたキーワードをもとにして原則を一度まとめてみる
- チームに共有しながら原則の内容や文章について推敲し、原則を完成させる
個人でデザイン原則をつくるときも 1 人でやるだけで基本は一緒。
参考
- デザイン原則の考え方として
- 日本語で書かれた原則のサンプルとして
余談
デザイン原則はデザインシステムと切り離して記事にしても良かったかもしれないな。
Semantic UI Doc ( Collections - Grid ) を読む
Semantic UI の Grid を読んだ。グリッドにテーマはない。
グリッドはサイトのレイアウトを格子状に整理して並べるのに利用する。CSS の技術としては Flexbox を使っており、グリッドのセル同士の余白は padding を利用して空けている。また、セルの持つ余白がグリッド上下左右の余白に影響を及ぼさないように、グリッドは周囲に負のマージンを持っている。
よくあるのは 12 列のグリッドだが、Semantic UI のデフォルトのテーマでは 16 列を採用している。テーマ変数をの値を操作することでこの列数は変更可能。
セル同士の余白を padding でとっているため、グリッドのセルに内側の余白をもたせたい場合は 1 つ HTML 要素をネストしなければいけない。
<div class="ui three column grid"> <div class="column"> <div class="ui segment"> <!-- セルの内側に余白をもたせたい場合は、要素を追加してその要素に余白を持たせる --> <img> </div> </div> ... </div>
グリッドはネストしたり、色つけたり、境界線をつけたりすることができる。
equal width を使えば行内を均等に分割した幅のセルがつくれる。このとき、子要素に当たる列の幅指定はいらない。
<div class="ui equal width grid"> <div class="column"></div> <!-- 1 行を 3 等分した幅になる --> <div class="column"></div> <div class="column"></div> <div class="equal width row"> <!-- 行を指定したので、ここで改行 --> <div class="column"></div> <!-- 1 行を 2 等分した幅になる --> <div class="column"></div> </div> </div>
グリッドの中身を中央に配置することもできるし、セルをそれぞれ左右の端に配置することもできる。
グリッドをレスポンシブに動作するが、固定幅で表示することもできる。
ここで書いたことの詳細は Grid (Definition) のページにまとまっている。
デザインシステムとは
昨日に続いて 「デザインシステムを学ぶ 31 日」の 2 日目。
デザインシステムとは
ブランドやプロダクトの一貫性を保つため、デザインをシステム化したもの。UI ライブラリー、フレームワーク、スタイルガイド、文章ガイドライン、ワークフローなどはこのシステムの一部にあたる。
デザインシステムがあるとどうなる？
つくったデザインに一貫性が生まれる。プロダクト内のどこかで「ボタン」の見た目を学習したユーザーは、別の場所でも同じようにボタンを発見・認知することができる。このような体験をユーザーにさせたいときにデザイナーはデザインで迷わなくて済むようになる（すでにコンポーネントがあれば既存の選択肢から選ぶだけ）。
そしてよくできたデザインシステムはデザイナーとエンジニアのコミュニケーションコストを下げる。Sketch などで作成したデザインデータとプロダクトのコードがシームレスにつながり、一部はデザイナーの意図した変更をエンジニアを介さずにプロダクトに反映させることもできるだろう。また、コンポーネントの選択と配置で基本的なデザインができるようになるので、エンジニアがデザインできる範囲も広がるはずだ。
デザインシステムがデザインシステムであるために
システムの前に原則がなくてはいけない。システムを構築する上で判断軸が必要になるため、原則なしでデザインシステムはつくりにくい。
また、システムをつくったら知りたい情報に素早くたどり着けるようになっていなければいけない。そしてたどり着いた情報は正確でなければいけない（バージョンが古くてもダメ）。これを実現させるためには情報が一箇所で管理されていることが理想であり、この考えは Single source of truth と呼ばれている。
最後に、「デザインシステム」なのでガイドラインを文章にまとめただけではいけない（我々はすでにドキュメントだけでルールが守れないことを知っている）。ルールは可能な限り仕組み化し、自動的に保守・運用できるようにしていく必要がある。
デザインシステムをつくるには何が必要か
原則と仕組みが必要。今思いつくのは以下の通り。
- デザイン原則 ... システムをつくるにあたって指針となる考え
- 言葉のトンマナをまとめたドキュメント ... ブランド全体の印象をつくるもの
- 変数 ... 色、タイポグラフィなどブランドの印象をつくるもの
- コンポーネント ... ブランド全体、またはプロダクトごとに用意されたデザインパーツ
これらを用意してワークフローに取り入れることでシステム化したデザインが完成する。
じゃあ具体的に何を、どうするの？というのをこれから学んでいく。
