![]() | |||||
|
Joel on Software このページは"ジョエル・オン・ソフトウェア
| |||||
|
プログラマのためのユーザインタフェースデザイン ※新しい翻訳はJoel on Software Translation Projectにあります。 その他の "Joel on Software" の記事(日本語) |
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2000/4/21 あなたがレストランに入って「犬お断り」という標識を見たとき、あなたはそれを単なる禁止の標識だと思うかもしれない。レストラン氏は犬に近寄ってほしくなかったので、レストランを建てるときにそんな標識をつけたのだと。 もしそういうことなら、「ヘビお断り」という標識もあってしかるべきだ。みんなヘビは嫌いなんだから。同様に「ゾウお断り」の標識も必要だろう。椅子を壊されないように。 あの標識がある本当の理由は歴史的なものだ。あの標識は人々が犬をレストランに連れ込もうとしていたことのしるしなのだ。 多くの禁止標識がそこにある理由は、人々が行為Xをするのにうんざりした施設の所有者が、どうかそれをしないようにと頼む標識を作ったためだ。もしあなたがニューヘブンのヤンキー・ドゥードゥルのような、創業50年になる家族経営の簡易食堂のひとつに入って、「ナップザックをカウンターに置かないでください」というような標識で壁が覆われていたのなら、それは人々がよくカウンターにナップザックを置いていたことの文化人類学的な証拠なのである。その標識の年代から、あなたはその地方の学生の間でナップザックが一般的になった時期を知ることができるだろう。 ときにはそういった理由が理解しがたいこともある。「公園にガラス瓶を持ち込まないでください」という標識は、誰かが裸足で草の上を歩いていたときに割れたガラスを踏んで足を切り、そしておそらくは市を訴えたのだということを意味している。 ソフトウェアにもまた、オプションダイアログという同様な考古学的記録がある。「ツール」-「オプション」メニューでオプションダイアログを開くと、ソフトウェアデザイナたちが製品のデザインについて議論した歴史を見て取ることができる。ユーザが前回作業していたファイルが自動的に開かれるようにすべきだろうか?そうだ!いや違う!2週間の議論があって、だれも他の人の感情を害したくはないと思い、プログラマは決着が付くまで自己防衛のために#ifdef入れる。ついにはそれをオプションにすることで決着する。 これはべつに二人の間の議論である必要はなく、心の中のジレンマであるかもしれない。データベースをサイズについて最適化すべきか、スピードについて最適化すべきかどうも決めかねる。結局Windowsオペレーティングシステム史上、紛れもなくもっとも馬鹿げたウィザードダイアログのようなものに落ち着くことになる。このダイアログはあんまり馬鹿げているので何かの賞を取るかもしれない。まったく新しいカテゴリの賞を。それはヘルプで何か探そうとしたときに出てくる、あのダイアログだ:
このダイアログの最初の問題点は、気を散らせるということだ。あなたはヘルプファイルの中のヘルプ項目を探している。その時点において、あなたは別にデータベースが小さかろうが大きかろうが、カスタマイズされていようが、チョコレートでコーティングされていようが、まったく気にしていない。一方でこの変なダイアログは、一覧(またはデータベース)を作成する必要があるという、ちょっとした学術的なレクチャーをあなたにしようとしている。3つくらいのパラグラフがあり、そのどれもがまったく混乱させるものだ。「あなたのヘルプファイル(たち)」というひどくぎこちないフレーズがある。あなたは一つないしは複数のファイルがある のかもしれないとわかる。あなたがヘルプファイルがいくつあるかについて気にしているとでもいうように。それがわずかでも違いをもたらすとでもいうように。このダイアログを作ったプログラマは、ヘルプファイルがひとつより多いかもしれないのに、「ヘルプファイル(単数)」と書くのは不正確 ではないか?ということで信じ難いほど悩んでいるのが明らかだ。 ヘルプを必要とする人々の多くはこのような奥義を理解する人々じゃない、というのは言うまでもないだろう。たとえ上級ユーザや、全文検索インデックスを熟知したコンピュータサイエンスの博士号を持つプログラマであっても、ここで何を選択しろと言われているのかわからないかもしれない。 さらに傷口を広げてやると、これはダイアログでさえない・・・ウィザードなのだ(次のページは、意訳すると「こんな不要で時間の無駄なことに付き合っていただきありがとうございます。」と言っているにすぎない)。しかもデザイナがどの選択肢が最良かについてある考えを持っていることは明らかで、わざわざその選択を推奨する労を取っている。 そこでユーザインタフェースデザインの法則の第2番に導かれる:
ユーザに決断を求めること自体は悪いことではない。選択の自由はすばらしいものだ。人々はエスプレッソベースの飲みものをスターバックスでオーダーするのが大好きだ。というのも、あんなにもたくさんの選択があるのだから。「カフェイン半分、スキムミルク・モカ・バレンシア、ホイップをつけてエキストラホットで!」 問題になるのは、彼らが全然気にかけていないことについて選択を求めるときだ。ヘルプファイルの場合、人々は何か本当にやりたいこと、誕生会の招待状を作るといったことをしようとしていて、問題があったためにヘルプファイルを見ているのだ。彼らの招待状を作る作業は、風船を上下逆さまにプリントする方法がわからないか何かのために不幸にも中断しており、それでヘルプファイルを見ているわけだ。物事のやり方について彼独自の優先度のアイディアに溢れたMicrosoftのうざったいヘルプインデックスエンジンのプログラマは、厚顔無礼にもユーザを再び中断させ、一覧ないしはデータベースを作ることについて教えを垂れ始めている。この二次的な中断は誕生会の招待状とはまったく無関係で、ユーザを困惑させ、いらだたせるだろうことは折り紙つきだ。 そしてあなたが私を信じるなら、ユーザというのはあなたが考えるよりもずっと、物事を気にかけていない。彼らは何かの作業をやり遂げるためにあなたのソフトウェアを使っている。彼らはその作業について気にかけている。それがグラフィックスプログラムなら、もっとも詳細なレベルですべてのピクセルをコントロールできることを、彼らはたぶん望んでいるだろう。それがウェブサイト構築ツールであれば、望んだルックスのウェブサイトを作ることに彼らが専心しているだろうことは間違いない。 しかし彼らは、そのプログラムのツールバーがウィンドウの上に付いていようが下にに付いていようが微塵ほども気にかけない。彼らはヘルプファイルがどうインデックス付けられているか気にしていない。彼らは多くのことを気にしておらず、これらの選択を彼らがしないで済むようにしてやるのはデザイナの仕事だ。本当に良いのがどちらの選択肢なのか十分に考えられないというだけの理由で、デザイナがこのような選択をユーザに迫るのは傲慢の極致と言っていい。(WinHelpの連中がやったように、ウィザードに変換することによって難しい選択をユーザにさせている事実を隠そうとしているのであれば、なお悪い。あたかもユーザが、彼らの提供するわずか2ステップのミニコースを履修しないと賢い選択のできない間抜けだとでもいうように。) デザインは選択の技術だと言われてきた。街角のゴミ箱をデザインするとき、矛盾する要求の間で選択をしなければならない。吹き飛ばされないように重く作る必要がある。ゴミ収集者がゴミを空けられるように軽く作る必要がある。たくさんのゴミが入るよう大きくしないといけない。歩道を塞がないよう小さくしないといけない。あなたがデザインをしていてユーザに何かを決定させることで責任を放棄するのなら、あなたはたぶんあなたの仕事をしていないのだ。同じ作業をあまり邪魔されることなく行える、もっと使いやすいプログラムを誰か別な人が作り、ほとんどのユーザはそちらの方を好むだろう。 Microsoft Excel 3.0が1990年に現れたとき、それはツールバーと呼ばれる新機能を誇る最初のアプリケーションだった。それは賢明な機能で、人々はそれが気に入ったし、みんなそれをまねたので、もはやそれを持たないアプリケーションを見るのが珍しいくらいになった。 ツールバーがそれほど成功したので、ExcelチームはExcelの特別バージョンを作って少数の人々に配布してフィールドリサーチを行った。このバージョンは、もっともよく使われるコマンドが何かの統計を取ってMicrosoftに報告するようになっていた。次期バージョンではツールバーがもう一行追加され、それにはもっともよく使われるコマンドが含まれていた。すばらしい。 問題は、どこまでやれば十分か分からないように見えるツールバーチームが解体されなかったことだ。彼らはユーザがツールバーをカスタマイズできるようにしたいと思った。彼らはユーザがツールバーをスクリーン上のどこにでもドラッグできるようにしたいと思った。それから彼らはメニューバーがアイコンのかわりに文字を使ったツールバーにすぎないと考えるようになり、メニューバーもスクリーン上どこにでもドラッグできるようにした。巨大なカスタマイズ性。問題:誰も気にしてないって!私はメニューバーをウィンドウの一番上以外の場所に置きたいと思う人に会ったことがない。逆にこれは悪ふざけみたいなことになる:ファイルメニューをプルダウンしようとして、誤ってほんの少し左をポイントしてメニューバー自体をつかんでしまうと、メニューバーを引きはがしてそれを置きたいはずのない唯一の場所にドラッグすることになる。あなたが作業しているドキュメントの上に。
こういう状況を何度見たことがあるだろう?そしていったんこうやってしまったなら、いったい何をしてしまったのか、どうすれば直るのか、明らかではない。そして私たちは(メニューバー移動という)誰もほしがらないオプションを手にしたが(そう、人類の0.1%くらいは欲しがるかもしれない)、しかしほとんどすべてのユーザにとってそれは邪魔なだけだ。 ある日、私の友達が電話してきた。彼女はemailをうまく送れないでいた。スクリーンの半分が灰色なの、と彼女は言った。 スクリーンの半分が灰色? 電話で話しながら何が起こったのか理解するのに5分ほどかかった。彼女はたまたまWindowsツールバーをスクリーンの右端にドラッグし、たまたまそれを広げてしまったのだ:
これは誰も意図的にはやらないたぐいのことだ。そしてこのたぐいの窮地から自分で抜け出すことのできないユーザがたくさんいるのだ。定義により、あなたがプログラムのオプションの一つを偶然変更してしまったとき、あなたはそれを再変更する方法を知らない。ほかにどうすれば良いのか分からないために、おかしな振る舞いをするようになったソフトウェアを再インストールしているユーザがいかに多いかということにはショッキングなものがある。(彼らは最初にアンインストールについて学んだのだ。そうしなければ破綻したカスタマイズが直らないので。) 「ちょっと待って!」あなたは言うかもしれない。「環境をいじりたい上級ユーザにはオプションは重要だろう!」現実にはあなたが考えるほど重要ではない。これは私がDvorak式キーボードに切り替えようとしたときのことを思い出させる。問題は私が使うコンピュータが一台じゃないと言うことだ。私はあらゆる種類のコンピュータを使う。他人のコンピュータも使う。家で3台、会社で3台のコンピュータをいつも使っている。仕事でテストラボのコンピュータを使う。環境のカスタマイズの問題は、それが伝搬しないということで、カスタマイズはそれが引き起こす問題に見合うものではない。 上級ユーザのほとんどは複数のコンピュータを常時使っている。彼らは2年おきにコンピュータをアップグレードしており、3年ごとにオペレーティングシステムを再インストールしている。Wordでキーボードを完全に再割り当てできることに最初に気づいたとき、彼らは周りのすべてを彼らの好みに合わせて変えたが、Windows 95にアップグレードするとすぐその設定は失われ、仕事用のと同じでなくなり、ついには設定を変えること自体やめてしまった。私は多くの「パワーユーザ」である友人に聞いてみたが、システムがまともに動くようにするための必要最小限のカスタマイズ以上のことは誰もしていなかった。 オプションを提供するときはいつも、ユーザに決断を求めている。これは彼らが何かについて考え、それについて決定しなければならないことを意味する。それは必ずしも悪いことではないが、一般的に、あなたはユーザがしなければならない決定の数を最小限にするよう心がけるべきだ。 これはすべての選択をなくすと言う意味ではない。どのみちユーザがしなければならない選択は十分たくさんある:彼らのドキュメントがどう見えるか、彼らのウェブサイトがどう振る舞うか、あるいは何であれ、ユーザがしている作業に不可欠なこと。これらの領域では思いっきりやろう:人々に選択肢を与えるのはすばらしいことだ:あらゆる手を尽くし、多ければ多いほどよい。そしてもう一つ、人々が好きな選択のカテゴリがある。実際の振る舞いを変えずにものごとの見かけを変えることだ。みんなWinAmpのスキンが好きだ。みんなデスクトップの背景に画像を設定している。この選択は見かけには影響するが機能に影響せず、ユーザには選択を無視する完全な自由があり、なんにせよ自分の作業ができる。これはオプションの良い使い方だ。 > 第4章 この記事の原文(英語)は User Interface Design for Programmers Chapter 3: Choices です。 | ||||
![]() ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社 Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。 | |||||
このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.