読者です 読者をやめる 読者になる 読者になる

I'm kubosho_

思想の固まり

Atomic Designの考え方と利点・欠点

Atomic Design

この記事はAtomic Designの概要やAtomic Designを実際に適用して気づいた利点・欠点について書きます。

Atomic Designとは

Atomic Designはデザインシステムを作る方法論となります。 デザインシステムというのはスタイルガイドやブランドのガイドラインなどを指すようです。

日本だとAbemaTV(アベマTV)で使われています。 (Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comより)

Atomic Designは今までのページ単位と違いコンポーネント単位でデザインカンプを作る考え方です。 作ったコンポーネント同士の組み合わせでページを作ります。

Atomic Designはコンポーネントの単位を5つに分けています。 その5つの単位はAtoms(原子)・Molecules(分子)・Organisms(有機体)・Templates(テンプレート)・Pages(ページ)です。 各コンポーネントの詳細は次のとおりです。

Atoms(原子)

Atoms(原子)は、UIを構成する基礎的な要素が該当します。

フォームでいうと、画像で示すようにラベル・入力部分・ボタンの各要素がAtomsとなります。 他の要素では、カラーパレットやフォント、アニメーションがAtomsに入ります。

f:id:kubosh0:20160707184103p:plain

Atomsに振り分ける基準としては、対象の要素が機能的にそれ以上分割できない 場合、Atomsへ振り分けます。 フォームで例えると、ラベルはそれ以上機能的に分割できません。 また入力フォームやボタンもそれ以上機能的に分割できません。

Atoms単体だと抽象的でどういう意味を持つかは分からないです。 入力フォームだけ見ても、それがアカウント登録フォームもしくはコメント入力フォームという情報は読み取れません。

Atomsはコンポーネントの基礎部分になります。 それは、Atomsを組み合わせてより大きなコンポーネントを構成するという点から言えることです。

またAtomsを俯瞰できるページを用意しておくことで、そのページがどのようにデザインされたかという雰囲気を感じ取ることができます。 それによりページデザインに一貫性を持たせることができます。

Molecules(分子)

Molecules(分子)は、Atomsを組み合わせて作る要素です。 このAtomsを組み合わせてMoleculesを作るというのは「単一責任の原則」やUNIX哲学の「1つのプログラムは1つのことをうまくやる」に基づいているようです。

Moleculesになることで意味を持つ要素となります。 たとえば、Atomsであるラベル・入力フォーム・登録ボタンという3つのコンポーネントがあってもそれら単体は意味をなしません。 しかし、これらの要素を組み合わせることにより「ラベルで示したことに応じて、入力フォームに何かを書いて、登録ボタンを押す」という意味が示せるようになります。

f:id:kubosh0:20160707184113p:plain

Moleculesはできるだけ単純にして、再利用性やUIの一貫性を高めます。

Organisms(有機体)

Organisms(有機体)は、AtomsやMolecules、また他のOrganismsを組み合わせて作る要素です。今までのAtomsやMoleculesとは違い複雑な要素になります。 ヘッダーやフッターと呼ばれる要素はこのOrganismsになります。

たとえば画像で示すようなヘッダーは「タイトル」というAtomsと、「ナビゲーション」「SNSのボタン群」というMoleculesが組み合わさって、ヘッダーというOrganismsになっています。

f:id:kubosh0:20160707184106p:plain

Organismsからそのページの特色が出やすくなります。

Templates(テンプレート)

ここからAtoms(原子)・Molecules(分子)・Organisms(有機体)といった化学的なものに例えることをしなくなります。 これは仕事の依頼元や上司・同僚に見せるものということを明確にするため、より一般的な言葉を使います。

Templates(テンプレート)の説明に移ると、Templatesはページ構造を説明するものです。 TemplatesはMoleculesやOrganismsを組み合わせて作ります。

Templatesの段階ではページ内容がまだ仮となります。Templatesを言い換えるなら「ワイヤーフレーム」になります。

Pages(ページ)

Pages(ページ)は、Template内へ実際の文章や画像などが入ったものとなります。

ここまで5つの要素について概要を書きました。 要素の振り分けかたについて、どのように考えたらいいかはAtomic design is for user interfaces内のInstagramで例えたものが分かりやすいと思います。

Atomic Designの利点

さて、Atomic Designを実際に適用した結果、次に挙げる3つの利点があると感じました。

名前がついている

Atomic Designはコンポーネントの大きさによって、それぞれAtoms・Molecules・Organisms・Templates・Pagesという名前がついています。 この名前がついていることで、Atomsは「それ以上分割できないコンポーネント」ということや、Moleculesの「Atomsを組み合わせた意味があるコンポーネント」という特徴が共有されやすくなると思います。

デザインの変更に対応しやすくなる

Atomic Designの考え方でコンポーネントを作ると、デザイン変更に対応しやすくなり再利用性も高くなります。 特にAtomsやMoleculesへ振り分けられるような細かいコンポーネントはデザイン変更にも強いです。

今回適用したページはそこまでデザイン変更が起こりませんでした。 それでもデザイン変更があったときはいつもと比べて他コンポーネントへの影響を考えずに対応できました。

セレクタの詳細度が平坦に近づく

Atomic Designを適用するとセレクタの詳細度が平坦になるようです。

次の画像は今回Atomic Designの考え方を使って作ったCSSの詳細度を示したグラフですが、割と平坦なグラフになっています。

f:id:kubosh0:20160707184110p:plain

また、Atomic Designを採用しているAbemaTVのCSSも、突然詳細度が上がることなく平坦なグラフです。

f:id:kubosh0:20160707184828p:plain

Atomic Designの欠点

利点ばかりではなく、Atomic Designの欠点も見えました。

デザイナーがどのようにデザインしていけばいいか分からない

Atomic Designは「小さい単位でコンポーネントを作り大きいコンポーネントにしていく」というデザイン手法です。そのため、フロントエンド実装では利点があります。

しかしデザイナーからすると、Atomic Designの考え方でデザインすることは難しいかもしれません。 実際、今回デザイナーへAtomic Designについて説明しました。 ただ、デザインしてもらうときはコンポーネント単位ではなくページ単位でデザインしてもらう従来の方法をとりました。

デザイナーによるページデザインの段階でAtomic Designを取り入れることに関しては、どうしたらいいのかまだ分かりません。

欠点に対しての対応

今回はコンポーネントリストを作りました。以下のjsfiddleではかなり簡略化したリストですが、以下のようにAtoms・Molecules・Organismsとコンポーネントを分けて見せるようにしました。

デザイナーには通常通りページ単位でデザインカンプを作ってもらいました。 そして、自分のほうでそのデザインカンプを見つつ、Atomic Designの各単位に要素を切り出し、コンポーネントを作りました。

作ったコンポーネントリストをプランナーやデザイナーに共有しておくことで、実機でどのように表示されるか分かりやすくなることと、開発者にも共有しておくことでコンポーネントを使うことを促し、結果としてコード量や実装の工数を減らすことを目論みました。 また、コンポーネントリストは作っておくと、どのようにコンポーネントを分割するか意識することができます。

まとめ

今回初めてAtomic Designの考え方でページを作ってみました。 結果としては、思ったより良い感じにハマった感があります。 今後もAtomic Designの考え方に照らし合わせてコンポーネントを作り、良い感じに変更に強く分割されたコンポーネントを作っていきたいと思います。

出典

Re:VIEW + RedPen + Travis CIの環境を構築できるboilerplateを作った

Re:VIEW

夏コミに向けての進捗どうですか。

ブーメランを投げたところで、「執筆環境を整えて自動校正やgh-pagesへのデプロイもしてくれる」Re:VIEW boilerplateを作ったので紹介します。

リポジトリ:https://github.com/kubosho/review-boilerplate

Re:VIEW boilerplateとは

以下の機能を提供します。

  • Re:VIEWフォーマットからWebページやPDFを出力する
  • RedPenでRe:VIEW文書を自動校正する
  • Travis CIを使った継続的インテグレーションをする
  • gh-pagesへの自動デプロイ(Travis CIでビルドが正常終了した場合)

ライセンスもMIT Licenseなので、ライセンスと著作権表示さえしていただければ、あとは好きなように使えます。

Re:VIEW boilerplateの使いかた

READMEにも書いていますが、簡単に使いかたを書いていきます。

とりあえずWebページとして出力する

Node.jsとRuby + Bundlerさえインストールされていれば、以下のコマンドを実行するだけでarticles/book/内にindex.htmlができます。

npm run setup
npm run web

PDFを出力する

PDFを出力するときは別途TeXのインストールが必要になります。 TeXのインストールについてはTechBooster/FirstStepReVIEWを参照してください。 TeXがインストールされていれば、以下のコマンドを実行することでPDFが出力されます。

npm run pdf

Re:VIEW boilerplateを作ったきっかけ

2015年の冬コミで初めてRe:VIEWを使って執筆をしました。 2014年の夏コミではAsciidoctorを使いましたがRe:VIEWを比較した場合、Re:VIEWは以下の利点がありました。

  • 独自記法がAsciiDocと比べるとRe:VIEWのほうが簡潔
  • WebページやPDFへ変換するのが簡単
  • 日本において、Re:VIEWは多く実績がある

そのため今回の夏コミにて再びRe:VIEWで執筆することにしました。

そしてこれからもRe:VIEWで執筆しようと思ったため、ここらで環境構築をしておいて後は楽したいと思い、Re:VIEW boilerplateを作りました。

Re:VIEW boilerplateの使用例

この夏頒布予定のSteins;Git 0という「Steins;Gateの世界観をGitで説明する薄い本」で使っています。

他には使われていないので、ぜひ使ってみてください。そして気づいたことがあれば、issueやPull Requestを送ってください。

ErgoDox EZを2週間使ってみた感想

ErgoDox EZ レビュー

最近夏コミに向けての執筆やTwitterクライアント作成に忙しいですが、それらを支える物として最近ErgoDox EZが加わりました。

ErgoDox EZが欲しすぎて買おうかどうかをErgoDox users meet upに行ってから決めようとしていたところを、行く前に購入してしまったくらいErgoDox EZが気になっていたのですが、そんなに気になっていたErgoDox EZが届くまでと実際に使ってみた感想を書いていきます。

届くまで

自分はIndiegogo経由で買い2週間ほどで届きましたが、どうやら公式ページ経由で買ったほうが早く届くようです(Twitterを見ていたら5日くらいで届いたという人がいた)。 Indiegogo経由と公式ページ経由を比較すると、Indiegogoを挟む分Indiegogo経由のほうが遅くなるのでしょうか?

また宅配業者はUPSでしたが、平日しか宅配してくれないのと、再配達が自動的に翌営業日に決められてしまうので、サポートへメールをしてヤマト運輸へ振り替えてもらいました。

なお、注文した後の流れははじめてのErgoDox EZ購入ガイド - Qiitaという記事が分かりやすく説明されています。

使ってみて

良い点

はじめに、セパレート式かつ高さも自由に変えられるので、タイピング時に肩がリラックスした姿勢でタイピングできるようになったことです。 このリラックス状態を知ってしまったらErgoDox EZから離れられそうにないです。 また逆チルト状態にすると自分の手に合って良い感じです。

次に、いろいろとカスタマイズができる点です。 キー配列に関しては、既定のキー配列は癖が結構ありますが、気に入らなければ自分の好きなキー配列にできる点が自由な感じでいいです。 ちなみに現状のキー配列はGitHubに上げています

カスタマイズ性というところでは、Cherry MX キースイッチと互換性があるキーキャップに変えられる点もiPhoneケース並の個性主張ができるという点でいいです。 カスタマイズ情報についてはErgoDox EZ カスタマイズ情報のまとめ - Okapies' Archiveにまとまっています。

あとは、タイプ時の音がここちよいです。Happy Hacking Keyboardと同じ押下圧(45g)の赤軸を選びましたが、その選択は間違っていなかったと思ってます。 タイプ時の音についてはHHKBと比べると高い音です。

また、ErgoDox EZは関係ないかもしれませんが、ErgoDox EZを使い始めてからタイピング時の運指を意識するようになりました。 今まで自分は左・右小指で押すべきキーを薬指で押していた癖があった(そして気づいてなかった)ために、使い始めて最初の日はタイプミスが多発しました。 今でも「z」や「0」が若干苦手ですが、使い始めた当初に比べればだいぶマシになりました。 タイピング時に運指を意識するようになった結果がどうなったかという参考に、現状のe-typingsのスコアを貼っておきます。 一番左は使い始めて3日目くらいの記録で、今は全国平均より上回っています。

f:id:kubosh0:20160702121622p:plain

最後に、ErgoDox EZはセパレート式という特徴があるので、空いた真ん中のスペースに何かおけるのは良いです。 自分はカーソルを絶対座標で指定できる点がいいと思ってIntuos Artを使っていますが、ペンタブは今までキーボードの右端に置くしかありませんでした。しかしErgoDox EZがセパレート式なおかげで写真のように真ん中に置けるようになり、より自然な形でペンタブが使えるようになりました。

悪い点

リストレストが臭いと他のErgoDox EZのレビュー記事にも書いてあったりしますが、本当に臭いです。 1週間くらいは臭いが消えなかったので、その間は他のリストレストを使うのがいいと思います。

また、タイピングする際に正しい運指をしていないとタイピング速度がガタ落ちします。 自分は使い始めて最初の日、通常の20%くらいしか速度がでませんでした。 とはいえ、これは自分の問題なので人によっては問題ないと思います。

まとめ

今もこの記事をErgoDox EZで書いています。ここまで記事を書いた感想としては、ErgoDox EZは高い買い物ですが、それに見合うだけの価値はあるということです。

Googleフォトで写真に付与される推定の位置情報についてのまとめ

雑記

Google、Googleフォトで位置情報の無い写真に推定の撮影場所を表示開始 | juggly.cnの件です。

写真や動画の撮影場所 - パソコン - Google フォト ヘルプを参考に、推測された位置情報がどのように扱われるか自分の解釈を書いていきます。

「他の人が上げた写真をGoogleフォトに上げたら都道府県レベルとはいえ位置情報が分かってしまうのでは?」と思いましたが、ロケーション履歴などを元に推測しているのでその心配はなさそうです。

追記

タイムライン(ロケーション履歴)の画面上では以下の画像のように「自分以外には表示されません」という表記があります。

f:id:kubosh0:20160607161735p:plain

GitHubでファイル差分を見るときに空白を自動的に無視するJavaScriptを書いた

GitHub

GitHubではファイル差分を見るときにクエリ文字列として「?w=」を付けると空白を無視することができます。 ですが、いちいち「?w=」を付けるのは面倒なので、自動的に「?w=」を付けるようにしてみました。

前提

Chrome拡張のScriptAutoRunnerが必要となります。ダウンロードページと解説記事は次のとおりです。

設定方法

次のソースコードをScriptAutoRunnerに貼り付けてください。

次の画像のようにScriptAutoRunner上で設定ができていれば動作すると思います。

f:id:kubosh0:20160531095138p:plain

動作するページ

Pull Requestのファイル一覧やコミットログページで動きます。動作しているかどうかは次のページが分かりやすいと思います。

fix indentation and else block by dardevelin · Pull Request #16 · sixthsense/sixthsense

注意事項

ページが読み込み終わった際にlocation.hrefでクエリ文字列を付けるため、読み込みがもう1度おこなわれてしまいます。そのためGitHub APIをより多く実行してしまうので、例えばOctotreeなどGitHub上で動作する拡張を使っている場合は、APIの実行回数制限に達した旨のメッセージがでてしまう可能性があります。

CSS in JSの資料やリポジトリまとめ

CSS in JS

CSS in JSについて調べる必要が出てきたため、せっかくなので見ていた資料やリポジトリを共有しておきます。

資料

CSS in JSの考え方を実装したライブラリ

MicheleBertoli/css-in-js: React: CSS in JS techniques comparison.のFeaturesにあるライブラリを一通り見てみて、organizationアカウント上にあるライブラリを抽出してみました。 organizationアカウント限定としているのは、個人が作ったライブラリよりは更新されていきそうという思いがあるためです。

抽出条件

  • organizationアカウント上にライブラリのリポジトリがある
  • 3ヶ月以内にコミットされている
  • contributorが複数いる
    • j2css/j2cはこれにより除外しています

一覧

バージョンは2016/5/17現在の情報です。

パッケージ (現在のバージョン >= 1.0.0)? バージョン
pluralsight/react-styleable true 2.2.4
jsstyles/react-jss true 2.0.6
kodyl/stilr true 1.2.4
webpack/css-loader false 0.23.1
FormidableLabs/radium false 0.17.1
inturn/classy false 0.4.7
Khan/aphrodite false 0.3.1

GitHubのissueから:+1:が含まれたコメントを消すブックマークレット

GitHub ブックマークレット

Dear Open Source Maintainers by bkeepers · Pull Request #115 · dear-github/dear-githubのような、意味もなくただ単に流れに乗りたくて :+1: をした人達がたくさんいるissueを見ると「なんだかなー」と思うことが多々あったので、:+1: が含まれているコメントを消せるブックマークレットをシュッと作りました。

:+1: eraser

コードは以下の通りです。