Joel on Software

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

 

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

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

その他の "Joel on Software" の記事(日本語)

その他の "Joel on Software" の記事(英語)

著者へのメール(英文のみ)

 

プログラマのためのユーザインタフェースデザイン
第4章: アフォーダンスとメタファー


Joel Spolsky ジョエル・スポルスキ
翻訳: Yasushi Aoki 青木靖
2000/4/18

プログラムモデルがユーザモデルと合っているユーザインタフェースを開発するのは簡単なことではない。そのプログラムがどう動き、何をするものなのかについて、ユーザが具体的なイメージを持っていないこと だってある。そのようなケースでは、何がどう動くかについての手がかりをユーザに与える方法を見つける必要がある。グラフィカルユーザインタフェースでこの問題を解くための一般的な方法は、メタファーを使うこと だ。しかしすべてのメタファーが平等に作られているわけではなく、良いメタファーを手に入れたときにそれと分かるためには、メタファーがなぜ機能するのか理解して おくことが重要である。

もっともよく知られたメタファーは「デスクトップ・メタファー」で、WindowsとMacintoshで使われている。小さなフォルダの中に、ドラッグして動かすことのできる小さなファイルが入っている。ファイルはドラッグして別なフォルダへ移動 させることができる。このメタファーが機能するのは、小さなフォルダの絵が書類フォルダのことを思い起こさせるからで、その中にドキュメントを入れられるのだと分からせる。

ここにKai's Photo Soapのスクリーンショットがある。どうやってズームインするのか分かるだろうか? 

 

そんなに難しくはない。虫眼鏡が現実世界のメタファーになっている。人々はそれが何をするものか知っている。ズーム操作で下にある画像のサイズが実際に変わる恐れはない。なぜならそれは、虫眼鏡のすることではないからだ。

メタファーは不完全なものであっても、メタファーが何もない場合よりはずっとよく機能するものだ。Microsoft Wordでズームインする方法が分かるだろうか?

Wordのインタフェースには二つの小さな虫眼鏡があるが、一つは(どういうわけか)プリントプレビューボタンであり、もう一つは(それが何であるかは置いておくとして)「ドキュメントマップ」ボタンである。拡大率を実際に変えるには、今は100%と表示されているドロップダウンボックスを使う。メタファーを使おうという努力がなされていないため、どうやってズームするのかユーザが推測するのはより難しくなる。これは必ずしも悪いことではない 。ワープロソフトのズーム機能は、Kaiのように広い画面領域を割り当てるのを正当化できるほど、重要ではない。しかしズームインできるKaiのユーザの割合は、ズームインできるWordユーザの割合より多いだろうことは確かだ。

まずく選択されたメタファーはメタファーがない場合よりも悪い。Windows95のブリーフケースを覚えているだろうか?この小さなかわいいアイコンは、すべてのユーザのデスクトップ上の平方インチほどの領域を、誰もそれを必要としていないことにMicrosoftが気づくまでの数年間占有していた。誰も必要としていなかったのは、それが破綻したメタファーだったからだ。それはユーザがファイルを入れて持ち帰るためのブリーフケースであると想定されていた。しかしユーザがファイルを家に持ち帰るとき、ユーザは相変わらずそれをフロッピーディスクに入れる必要があった。ではユーザはファイルをブリーフケースに入れるのだろうか、それともフロッピーディスクに入れるのだろうか?私には分からない。私はこのブリーフケースが理解できないし、それがうまく使えたことがない。

アフォーダンス

よくデザインされたオブジェクトは、見ただけでそれがどう機能するのかはっきりとわかるものだ。大きな金属製のプレートが腕の高さの位置にあるドアがある。この金属プレートに対してできる唯一のことは、それを押すことだ。ドナルド・ノーマンの言い方をすると、そのプレートは押すことをアフォードしている。ほかのドアには大きな丸い引き手があり、引きたいと思わせる。それらは引き手のどこに手をかけるべきかということさえ暗示している。引き手は引くことをアフォードしている。引き手はあなたにそれを引きたくさせる。

ほかのオブジェクトはそれほどよくデザインされておらず、どうすることが期待されているのかわからない。典型的な例はCDケースで、これはユーザが指をしかるべき場所に掛け、ある特定の方向に引っ張ることを要求している。箱のデザインはどうやって開けるのかについて何も示唆していない。もしその仕掛けを知らなければ、箱が開けられずにイライラすることだろう。

アフォーダンスを作るための最良の方法は「ネガの世界」における人の手の形をまねることだ。ここに前面と背面を示した(すばらしい)Kodak DC-290デジタルカメラをよく見てみよう:


前面には、右手にフィットしそうな大きなラバーグリップが見える。さらに気が利いているのは、背面の下左隅に指紋のように見えるくぼみだ。あなたが左親指をそこに置くと、左人差し指はカメラの前面、レンズとラバー片の間にぴったりと収まる。それはあなたが親指をしゃぶり、人差し指を鼻にかけていた時以来感じたことのないような、ある種心地よい感覚を与える。

コダックの技術者は、カメラがよく安定し、指が誤ってレンズを隠すことがないような位置で、両手でカメラ持つようにあなたをし向けている。このラバーに機能はなく、その唯一の目的は、あなたが正しい持ち方でカメラもを持つようにすることだ。

良いコンピュータのUIもアフォーダンスを使う。10年ほど前、ほとんどのボタンが「3D」になった。それはグレーの陰を使い、スクリーンから飛び出すように見える。これは単にかっこよく見えるというだけではない。それが重要なのは、3Dボタンは押すことをアフォードするからだ。それは突き出しているように見え、それを操作する方法はクリックすることであると見て取れる。残念ながら、最近のウェブサイトの多くは(アフォーダンスの重要さに気づくことなく)押せそうに見えるボタンよりはかっこよく見えるボタンを使っており、結果として、ユーザはしばしばどこをクリックするのか探し回る羽目になる。このウェブバナーを見てみよう:

"GO"と"LOG ON"は飛び出していてクリックできそうに見える。SITE MAPとHELPボタンはそれほどクリックできそうには見えず、実際クリックできないQUOTESラベルとまったく同じように見える。

 

4年ほど前、多くのウィンドウが右下隅に3本の小さな峰をつけるようになり、それはグリップのように見えた。これは引っかかりが良くなるようにスライド・スイッチの脇についている溝のようだ。これはドラッグすることをアフォードしている。これはウィンドウを広げるためにドラッグしてくれることをせがんでいる

最後に、アフォーダンスの最良の例のひとつである、有名な「タブダイアログ」を取り上げよう。以前のMacのコントロールパネルを覚えているだろうか?

これのアイディアはこうだ。左にある(スクロールする)一覧からアイコンを一つ選択する。アイコンをクリックすると右側のスクリーンが変わる。このような遠回りなやり方は、ある理由によりそれをデザインするプログラマにとってはとても理にかなっていたが、多くのユーザはこれを理解しなかった。何よりも人々は、最初の4つ以降のコントロールパネルを出すために一覧をスクロールする方法に気づくことが滅多にない。さらに致命的なのは、ほとんどの人々はアイコンとダイアログの間の関連を理解しないということだ。アイコンは実際のところ選択肢の一部にしか見えない。

1992頃から、こういったインターフェースは少なくなり、タブダイアログと呼ばれる新発明で置き換えられていった:

タブダイアログはすばらしいアフォーダンスだ。この絵から6つのタブがあることは明らかだ。どのタブを開いているのかも明らかである。そしてどうすれば別なタブに切り替えられるのかも明らかだ。Microsoftが最初にタブダイアログのユーザビリティテストを行ったとき、ユーザビリティが(旧Mac方式の)約30%から100%に上がった。文字通りすべての被験者がタブダイアログを理解できたのだ。このメタファーのめざましい成功や、タブダイアログのコードがWindowsに組み込まれていて実質ただで使えることを考えると、タブダイアログを利用しないアプリケーションをいまだ見かけることがあるのは不思議に思える。これらのアプリケーションはやるべきことをやるのを拒んでいるために、実際に計測可能な実世界のユーザビリティ上の問題を煩っている。



> 第5章

この記事の原文(英語)は User Interface Design for Programmers Chapter 4: Affordances and Metaphors です。 

ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。


このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky