Joel on Software このページは"ジョエル・オン・ソフトウェア

プログラマのためのユーザインタフェースデザイン
第1章
第2章
第3章
第4章
第5章
第6章
第7章
第8章
第9章

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事（日本語）

その他の "Joel on Software" の記事（英語）

著者へのメール（英文のみ）

Macintoshがまだ新しかったころ、ブルース 「トグ」 トグナツィーニはAppleデベロッパーマガジンにUIについてのコラムを書いていた。人々は彼が議論した様々なUIデザイン上の問題について投書した。このコラムは今日でも彼のWebサイト上で続いている。それらは集められ、2冊のすばらしい本にまとめられている。Tog on Software Designはとても楽しい本で、UIデザインへの優れた入門書となっている。(Tog on Interfaceはさらに良かったのだが絶版となっている。)

いつもスクリーンの一番上にあるMacintoshのメニューバーが、アプリケーション ウィンドウの中にあるWindowsのメニューバーよりも使いやすい理由を説明するために、トグは高さ1マイルのメニューバー(mile high menu bar)と言う概念を考案した。Windowsでファイルメニューを指定したいとき、ターゲットとなるのは幅1/2インチ、高さ1/4インチほどの領域である。あなたは垂直および水平の両方向について非常に正確にマウスを動かす必要がある。

一方Macintoshでは、どれくらい動かすか考えずにマウスをスクリーンの一番上にドンと持って行けば、マウスはスクリーンの上端--メニューを使うための正しい位置--で止まる。ターゲットの幅は相変わらず1/2インチだが、高さは実質1マイルもある。あなたは水平方向の位置にのみ気を配ればよく、メニューアイテムのクリックは、はるかに簡単になる。

トグはこの原理に基づいたクイズを出した。マウスで最も指定しやすいスクリーン上の5つの点はどこか？答えは、スクリーンの四隅(マウスをポイントすることなく一挙に動かせる)と、マウスの現在位置(すでにそこにある)である。

高さ1マイルのメニューバーの原理は非常に有名であるが、まったく自明と言うわけではない。なぜならWindows 95チームはまったく要点が分かっておらず、スタートボタンを設定した位置はスクリーンのほぼ左下隅だったが、正確にではなかった。事実、スクリーンの下端より2ピクセル、左端より2ピクセル離れていた。この2ピクセルのために、Microsoftは文字通り「福を転じて災いとなし」(とトグは書いた)、スタートボタンをマウスで捕らえるのをずっと難しくしている。それは平方マイルの広さにし、マウスでクリックするのがまったく簡単なようにすることもできたのに。私の知らない何かの理由でそうなっていないのだ。神よ救いたまえ。

前の章で、ユーザがいかに読むのが嫌いで、そうしなければ絶対作業が終わらないと言うのでない限り読もうとはしない、という話をした。同様に：

ユーザはマウスをあまりうまく使えない。

これは文字通りの意味ではない。私が言いたいのは、正しく使用するために非常に機敏なマウス操作が必要となるようには、プログラムをデザインすべきでない、ということだ。最初の6つの理由はこうだ：

1. しばしば人々は最適ではないポインティングデバイス--トラックボール、トラックパッド、ThinkPadの赤い小さなやつといったもの--を使っており、それはマウスよりコントロールするのが難しい。
2. しはしばユーザはマウスを悪条件のもとで使っている：散らかった机、マウス飛びを起こす汚れたトラックボール、正確に機能しない安物のマウス。
3. ある人々はコンピュータを使い始めたばかりで、マウスを正確に使うスキルをまだ身につけてないかもしれない。
4. ある人々はマウスを正確に使えるための運動能力を持っておらず、これからも持つことがない。彼らは関節炎、震顫、手根管症候群かもしれない。彼らは幼いか、年老いているかもしれない。あるいはそのほかのたくさんの障害があるかもしれない。
5. 多くの人にとって、マウスを少しも動かさずにダブルクリックするのは非常に難しい。その結果として、彼らはアプリケーションを実行しようとしてスクリーン上でいろんなものを引きずりまわす。そういう人を見分けるのは簡単だ。それというのも、彼らが何かを起動しようとするとき、2回に1回はかわりにそれを移動させることになるので、彼らのデスクトップはめちゃくちゃになっているからだ。
6. もっとも良い状況であっても、マウスを多く使うことは人々には手間取っているように感じられる。人々にマウスを使った複数のステップの操作をさせると、彼らは何か立ち往生しているように感じ、それは彼らにUIの反応が悪いと感じさせ、おわかりの通り、それは彼らを不幸せにする。

その昔、私がExcelの仕事をしていた時分には、ラップトップは組み込みのポインティングデバイスを持たず、Microsoftはキーボードの脇に留めるようになっているクリップオン トラックボールを作っていた。今ではマウスが手首と全部の指を使ってコントロールされている。これは書くための動作に似ており、あなたはたぶん小学校で書くのに必要な精密な運動能力を身につけたことだろう。しかしトラックボールは親指だけでコントロールするようになっている。結果として、トラックボールはマウスと同じほどの正確さでコントロールするのが難しい。たいていの人はマウスを1ピクセルか2ピクセルの精度でコントロールできるが、トラックボールは3ピクセルか4ピクセルの精度でしかコントロールできない。Excelチームでは、私はいつも新しいUIを、マウスだけでなくトラックボールでも試してみるように促していた。マウスを思ったところに正確に持っていくことのできない人々がどう感じるかを知るためだ。

私がいちばんめんどうに感じるUI要素はドロップダウンコンボ リストボックスだ。それはこんな外観をしている：

下向きの矢印をクリックすると展開するようになっている：

たとえばTimes New Romanを選択するために、どれだけ多くの細かいマウスクリックが必要になるか考えてみよう。まず最初に、下向きの矢印をクリックする必要がある。それからスクロールバーを使い、Times New Romanが出てくるまで注意深くスクロールする。こういったドロップダウンの多くは不用意にデザインされており、一度に2、3項目しか表示されない。そのため、このスクロール作業はけっして簡単ではなく、多くのフォントがインストールされている場合には特にそうだ。これはスクロールボタンを注意深くドラッグするか(このように動かす幅が小さい場合にはうまく機能しそうにない)、もしくは2番目の下向き矢印を繰り返しクリックするか、スクロールボタンと下向き矢印の間の部分をクリックする必要がある(これはスクロールボタンがある程度下まで来ると機能しなくなり、いっそうユーザを困惑させる)。最後に、どうにかTimes New Romanを表示させることができたら、それをクリックしなければならない。もし失敗したならはじめからやり直しになる。もしあなたが各章の最初の文字を装飾フォントにしたければ、これに掛ける10をする。あなたは本当に不幸せだ。 

これにはとても簡単な解決策があるということが、コンボドロップダウン コントロールの煩わしさをよけいに増幅させる：すべてのオプションを含めるだけドロップダウンを長くすればよいのだ。90%のコンボボックスはドロップダウンで使えるスペースを全部は使っておらず、これは一種の罪悪だ。メインエディットボックスとスクリーンの下端の間に十分なスペースがないなら、ドロップダウンはすべての項目が入るまで、画面の上端から下端まででも拡がる。それでもなお入らない項目があるときには、哀れなユーザをちっぽけなスクロールバーで煩わせることなく、マウスが縁に近づいたとき、コンボは自動的にスクロールする。

さらに、コンボをポップアップさせる前に、エディットボックスの右の小さな矢印をクリックさせないでほしい。コンボボックスのどこでもクリックさせてほしい。これはクリックのターゲットを10倍にも広げ、マウスポインタでターゲットをとらえるのをずっと簡単にする。

マウス操作の別な問題を見てみよう：エディットボックスだ。醜くてグラフィックデザイナを嘆かせるChicagoと呼ばれる太く幅広のフォントが、Machintoshのほとんどすべてのエディットボックスで使われていることに、あなたは気づいているかもしれない。グラフィックデザイナは(UIデザイナと異なり)、細い可変幅のフォントが優雅で、見目よく、読みやすいと教わってきている。これは正しい。しかしグラフィックデザイナが学んだのは印刷物上での技術であって、スクリーン上の、ではない。テキストを編集する必要があるときには、固定幅フォントは可変幅フォントに対して大きな利点がある。"l"や"i"のような幅が狭い文字を見たり選択したりするのが簡単になるのだ。私はこのことを、60才の男性がユーザビリティテストでなにかFillmore Streetとかいう彼の住所を苦労して編集しようとしているのを見たときに学んだ。私たちは8ポイントのArialを使っていて、エディットボックスはこんな感じだった：

IとLが文字通り1ピクセル幅であるのに注意してほしい。小文字のIと小文字のLの違いは、文字通り1ピクセルである。(同様に、小文字の"RN"と小文字の"M"の違いを見分けるのは不可能に近く、このエディットボックスの中身は実際はFillrnoreかもしれない。)

Flilmore、Fiilmore、Fillrnoreといったミスタイプに気づく人はほとんどいないだろうし、気づいたとしても、マウスを使って間違った文字を選択し、修正するのにはとても時間がかかるだろう。実際には2ピクセル幅の点滅するカーソルが、一文字選択するのをさらに難しくするだろう。私たちが太ったフォントを使っていたならどんなに簡単になっていたか、見てみよう(ここではCourier Boldを使っている)。

結構、これはスペースを食うし、グラフィックデザイナたちにはクールに見えないだろうが、手を打とう！これはずっと使いやすい。使っていて快適にさえ感じられる。それはユーザがタイプすると、はっきりして明快なテキストが得られ、編集もずっと楽だからだ。

ここにプログラマに共通したひとつの思考パタンがある：数には3種類、0、1、nしかなく、nが可能なときには、どのnも同様に確からしい(equally likely)、というものだ。0と1以外のどんな数値定数もコードの中に入れるべきではないという(たぶん正しい)信念にこの思考パターンは由来している。(0と1以外の定数は｢マジックナンバー｣と呼ばれ ている。私はそのゲシュタルトには立ち入りたくもない。)

たとえば、あなたのプログラムが複数のドキュメントを開くことができるなら、(メモリが許す範囲で)限りなく多くの、少なくとも(プログラマが認める唯一のマジックナンバーであるところの)2^32個のドキュメントを開けるべきである、とプログラマは考える傾向がある。プログラマは開けるドキュメントの数を20に限定するようなプログラムを軽蔑しがちだ。20って何よ？なんで20なの？2の冪でさえないじゃない！

すべてのnは同様に確からしいことの、もう一つの暗黙の帰結は、ユーザがウィンドウをリサイズしたり移動したりできるなら、このウィンドウを動かせる場所については完全な自由度があるべきだ、とプログラマは考える傾向があるということだ。要するにスクリーンの上端から2ピクセルの場所にウィンドウを置くというのは、ウィンドウをスクリーンの上端ぴったりに置くのと同じようにありそうなことだということだ。

しかしこれは正しくない。ウィンドウをスクリーンのぴったり上端に置きたい理由はたんとあるが(それはスクリーン上の不動産を最大限にするから)、スクリーンの上端とウィンドウの上端を2ピクセルだけ空ける理由というのはないからだ。従って現実には0は2よりもありそうなことだといえる。

WinAmpの製造元であるNullsoftのプログラマたちは、私たちを10年間捕らえていたこのプログラマ的思考をなんとかして退けたようだ。WinAmpはすばらしい特徴を持っている。ユーザがウィンドウをスクリーンの縁近く数ピクセルまでドラッグすると、自動的にスクリーンの縁にくっつく。これはたぶんユーザが望むことだろう。0は2よりもありそうなことなのだから。(Junoのメインウィンドウは似たような特徴を持っていた。それは私の見た唯一のスクリーンに閉じこめられたアプリケーションで、縁を越えてドラッグすることができない。)

ユーザは少しばかりの自由度を失うかわりに、「マウスを正確にコントロールするのは難しいのに、なんで正確にコントロールしなきゃいけない んだ？」ということを分かってくれるユーザインタフェースを手に入れる。(すべてのプログラムで使うことのできる)この発明は、賢い方法でウィンドウ管理の負担を軽くしている。あなたのユーザインタフェースをよく見て、ちょっと勘弁してもらうことにしよう。私たちはゴリラか賢いオランウータンで、マウスを使うのに苦労しているようなふりをしよう。