ブラウザとGUIクローム

ユーザーインタフェースデザインにおける「クローム」についてどう考えればいいだろうか。この質問は最近実施した「モバイルとタブレット向けのビジュアルデザイン」についてのコース中、出席者の1人から尋ねられたものである。基本的な質問をされたときは常に、それについての答えを知りたい人はずっとたくさんいるのだろうと私は考える。そこでこの記事ではクロームについて取り上げようと思う。

• 定義：　クロームとは、画面のコンテンツについての情報をユーザーに与えたり、その画面のコンテンツを操作する指示を出すためのビジュアルデザイン要素である（画面のコンテンツに属しているのではない）。こうしたデザイン要素は、オペレーティングシステムであれ、ウェブサイトやアプリケーションであれ、その基礎的なシステムによって提供されており、ユーザーのデータはそれによって取り囲まれている。
• 「Chrome」がGoogleのウェブブラウザの名前でもあるのは偶然の一致ではない。しかし、今回、私がその意味でこの用語を使うことはない。

誰が「クローム」という用語を思いついたのかは知らないが、それは1950年代の大きなアメ車に使われていた金属クロム（metal chrome）の見た目から来ているのではないだろうか。そうした車の車体（座る部分）はバンパーやテールフィンなどに付いていた光り輝くクロムによって取り囲まれていたからである。

同様に、現在のGUIではクロームは画面の周辺部に存在し、ユーザーのデータ用に充てられた中心部を取り囲んでいる。

様々なシステムレベルにおけるクローム

以下に示すのはいくつかのクロームの例である。クロームは「基礎的なシステム」によって異なっている：

• Windows PCの基礎的なシステムはWindowsオペレーティングシステムである。Windows 7ではそのクロームはスタートボタンとタスクバー、システムトレイ、ごみ箱から構成されている。また、ガジェットエリアもクロームであると考えてもいいかもしれない。もしユーザーがシステムに付いてきたからということでそうしたガジェットを使っているというなら、とりわけそうだろう。（惰性とデフォルトの力によって多くの人がそうするからである）。
• ワードプロセッサのようなアプリケーションソフトウェアの利用時、そのクロームはメニューバーやリボン、ツールバー、ルーラー、スクロールバー、また、Wordの類義語辞典バーやPhotoshopの色見本パレットのような様々な専用ペインで見つけられる。
• ウェブブラウザではそのクロームにはURL欄や、ブラウザのツールバー、ブラウザのボタン、タブ、スクロールバー、ステータス欄が含まれる。
• モバイルのアプリではそのクロームには画面の一番上を横切っているステータスバーや下部を横切っているコマンドアイコンの載ったタブバーが含まれていることが多い。また、ステータスバーの下にあるナビゲーションバーが当てはまることもある。
• ウェブサイトではそのクロームにはナビゲーションバーやフッター、ロゴ、ブランドマーク、検索ボックス等が含まれる。

クロームの肥大化： 私のピクセルを使わないでくれ

クロームによるデメリットはわかりやすい。クロームは画面スペースを塞ぐので、目的のコンテンツやデータのためのスペースが減るのである。これはモバイル機器では特にまずい。というのも、タブレットやPCと比べて、画面スペースの価値がずっと高いからだ。しかし、私の30インチデスクトップモニターですら、WindowsとExcelのクロームが組み合わされると、スプレッドシータのデータは67列しか見えなくなる。理論的には画面に80列入るはずなのに、である。つまり、クロームがなければ、見渡せるデータはおよそ19％増えるはずなのである。

このスプレッドシートの例からクロームのもう1つの欠点がわかる。それは、システムが別のシステムのレイヤーの中で入れ子になると、かさが増してしまうということである。例えば、Facebookを使っているとしよう。典型的なデスクトップブラウザのウィンドウではユーザーのFacebookのウォールはそのページの約48％しか表示されない。つまり、Facebookのクロームと無駄な画面スペースによって、残りの52％は食いつぶされているのである。（我々の定義では、広告は正確に言うとクロームではない。なぜならばそれは無駄なものだからである。しかし、それがオーバーヘッドであることには変わりはないので、ここでは数値に入れている）。さらにブラウザやOSのクロームを差し引くと、ユーザーのウォールに割り当てられる画面スペースは40％に満たない。

9年前、様々なウェブサイトのホームページを分析したとき、ユーザーの画面上で実際のコンテンツに割り当てられる配分はわずか20％だった。大きくなった現在のモニター上では、OSやブラウザのクロームによって消費される相対的オーバーヘッドの割合はそこまでにはならないので、Facebookでの40％という配分は主要ウェブサイトにおけるかなり典型的なものだろう。

積み重なったクロームは我々のピクセルの半分以上を使ってしまうことも多いため、 ガイドラインの1つがクロームの肥大化には気をつけようということであるのは間違いない。

2番目のガイドラインはクロームのパーツを一時的に非表示にして、必要なときだけ見せる方法を考えようというものである。しかしながら、そうすることは危険でもある。なぜならば、去るものは日々にうとしということで、視界から消えたものは頭からも消えてしまうことが多いからだ。そして、ユーザーインタフェースでは短期記憶は全く当てにできない。したがって、現れたり消えたりするクロームは以下のようなときにのみ機能する：

• クロームを見せるためにシンプルで信頼性の高い操作を利用するとき（反応が鈍かったり、予想外に起動しやすいジェスチャーを利用してはならない)。
• 絶対的な一貫性が提供されているとき。ユーザーの学習を台無しにする逸脱や例外がなく、何度も繰り返されることで、非表示のクロームの存在がユーザーの長期記憶に叩き込まれるようになる。

クロームのメリット

高いものにつくとはいえ、クロームには多数のメリットがある：

• クロームによって常に見える（あるいは、私のガイドラインに従っていれば、少なくともすぐに出てくる）コマンドやオプションの一定のセットが提供されることで、ユーザーに力を与える。また、クロームは常に同じ位置にあるので、ユーザーはそれがどこにあるかを探すことから解放される。さらには、ウェブページやコンテンツの個々のデザイナーの思いつきからも自由になれる。つまり、これこそが戻るボタンがウェブでもっとも人気の機能である理由の1つである。クロームは画面のピクセルという意味ではオーバーヘッドかもしれないが、不愉快な、あるいは役に立たないウェブページからの緊急非常口としての役目を果たすという意味ではユーザーがすぐに使える権限なのである。
• クロームによって、フレームワークの中に現れる様々なタイプのコンテンツやデータすべてで機能する一連の汎用コマンドが提供される。それは常に同じなので、ユーザーはあまり学習をしなくてもよくなり、コンピューターではなく、現実世界での自分たちのニーズに集中できるようになる。
• クロームによって、ユーザーインタフェースの一貫性と標準化の度合いが進み、それによって学習のしやすさが促進され、ユーザーはますます自分のエクスペリエンスをコントロールしているという気になれる。（もちろん、これが当てはまるのは標準規格に従った場合のみである。ユーザーを混乱させる自分たちによる奇妙なクロームを発明した場合はそうではない）。

結局のところ、クロームはユーザビリティにとって良いものである。ただ、使いすぎないようにしよう。

情報開示陳述

十分な注意を促すため、Mozillaが私がコンサルタントをしているクライアントのうちの1社であることについて言及しておくべきだろう。彼らの主要な製品（Firefox）はこの記事で私が触れているGoogleのChromeブラウザの競争相手である。その一方、Googleは私のユーザビリティウィークカンファレンスに最も多くの出席者を送り込んでいる企業の1つだ。（私はGoogleの創設期には彼らの相談役もしていた）。私はどちらの企業にも好意を持っている。いずれにしても、私はGoogleのブラウザには言及しているだけであり、それに対して勧めることも、勧めないこともしていない。したがって、そこにはどのみちバイアスはかかっていないと考える。今、あなたが目にしているものが、あなたが自分なりの判断をするために開示されたすべての情報である。