Table of Contents
インターフェイスのデザインにアフォーダンスを利用すると、ユーザはその扱い方を知らずとも、その時々物体の方が扱い方を教えてくれる。つまりユーザがその物体について知っていなくてはならない事の量を減らすことが出来る。
インターフェースの世界では、純粋なアフォーダンスだけではなく、後天的な学習によるものも含め、広く「アフォーダンス」という言葉を適用する傾向がある。また実際、その区別は困難であると思われる。
【例】
写真は中京大学情報科学部棟のトイレのドアである。
 | 
|
| 押す事をアフォードしている例 | 引く事をアフォードしている例 |
我々はドアの扱いについて明示的に教わった事はない（と思う）にも関らず、無意識にドアを扱うことが出来る。そうそう、アフォーダンスの受信(?)は無意識かつ瞬時に行われるものだと考えられる。
【例１】
写真は最近増えてきたレバー式のカランである。
 |
これがまた、上げると水が出るものと下げると水が出るものがあり、混乱を招いている。インターフェイスに明るい某教授のお宅では、台所と洗面所でこの作法が異なるらしい。クレイジーである。
このように、どちらがより自然かについて決定が難しい場合について、Normanは「どっちかを世界的に標準として決めちゃうしかなんじゃないの？」と述べている。このカランも標準化が望まれる例だろう（どうも最近は下げると水が出る方式に統一されつつあるような気がするが）。
【例２】
写真は典型的なテレビの電源スイッチである。
 |
ひとつのボタンであるにも関らず、ある時は電源を入れるスイッチであり、ある時は電源を切るスイッチであり、と正反対の動作をする。一貫性はない。しかし、このスイッチはよくデザインされており、ボタン自身が現在のモードを表す役割をも担っている。すなわち、ボタンが出っ張っている時は「電源入ボタンとして機能する」事を意味し、引っ込んでいれば「電源切ボタンとして機能する」事を表す。ユーザはひと目見てこのボタンを次に押した時の動作がわかるので、混乱はおきない。またこのような一回の操作毎に出っ張ったり引っ込んだりするボタンは、なんらかの機能のON/OFFを切り替えるのに使われる、というのも一種の標準化である。
ちなみにこの例では、ユーザはテレビの電源が今どういう状態にあるかについて、画面からもフィードバックを受けていると考えられる。
【例】
カセット・テープやビデオ・テープの爪。あの爪を折っておくと、誤って上から録音／画しようとしても機械が作動しないようにできている。
ユーザはフィードバックによって自分の意図が道具や機器に伝わったかどうか確認ができる。ユーザが安心して、また間違いを起こさずに道具を使えるようにするには、適切なフィードバックを返すインターフェイスをデザインすると良い。
ユーザは必ずしもデザイナーが意図したところからのみフィードバックを受け取っているわけではない。いつもの操作に付随して起こる現象であれば、それが正常を示すフィードバックだというメンタル・モデルを生成する。例えば完璧な消音システムにより、イグニッション・キーを回してもエンジンの音が聞こえない車が開発されたらどうだろう？その時には別のエンジンのスタートを示すフィードバックを考えなければならない。デザイナーは、ユーザが持っているメンタル・モデルを意識し、それに対し一貫性を持ったデザインを心掛けることが望ましい。
ちなみに古田のデスクには、先日アメリカに旅行した際に買ってきた写真の様な額が飾られている。
 |
古田はこれを座右の銘にしてインターフェイス研究に望みたいと考えている。もちろん、「バカというのはあまりにもバカだから、フールプルーフなんてものはできるワケがない！」と諦めるという意味ではない。「どんなに注意深くデザインされたインターフェイスでも、必ず誰かがミスをおかす。だから、デザイナーはその１歩も２歩も先を読んで対策を講じておかなければならない」、そうキャプテンはおっしゃっているのである。ところでキャプテンって誰だ？
【例】
写真は先日古田がアメリカに旅行に行った際に宿泊したホテルの照明スイッチである。
 |
このスイッチの右に洗面台があり、左がトイレ／バスのドアになっていたのですが、左のスイッチで洗面台の照明が、右のスイッチではトイレ／バスの照明を換気扇が動作するという、とんでもない設計になっていた。
メタファーはコンピュータのインターフェイスでアイコン（主に事物を象ったシンボルマーク）として使われる事が多い。
【例】
最も代表的なもののひとつは、Macintoshのゴミ箱アイコンであろう。不要になったファイルやフォルダ（これらもまたメタファーである）を捨てたいと思ったら、マウスでゴミ箱に移動すればいい。これは現実世界の知識をうまく流用しているので、ユーザにとってとても自然でわかりやすい。Macintoshは10年も前からこのメタファーを使っている。95年にようやく採用したのとは歴史の重みが違う。おっと、ついエヴァンジェリズム魂がウズいてしまった。
ちなみに、Macintoshでは、ゴミ箱にゴミ（不要なファイル）が入っていると、ゴミ箱アイコンが膨らんだ形になる。最近Apple社（Macintoshのメーカー）の偉い人になったNormanが、「ゴミを入れて膨らむゴミ箱があるかい」といったからかどうかは定かではないが、次期バージョンではこの仕様は止めになるらしい。
| ゴミ箱が空の時 | 中身がある時 | |
| 現バージョン |  |  |
| 次期バージョン |  |  |
メンタル・モデルとは、実際の機器の振る舞いとの整合性に関らず、ユーザが心的に持っている機器の動作に関するモデルである。ユーザが機器の振る舞いを元にして作り上げたモデルなので、見掛けはもっともに感じられ、普段はその理解でうまくいく（何故なら普段の振る舞いから作り上げられたものだから！）。しかし、このメンタル・モデルと実際の機器の振る舞いとの間に差異（=誤解）があると、ある時、たいていそれは些細なトラブルが起こった時だが、そのトラブルを大きくする役割を果たす。
デザイナーは、ユーザが機器の実際の振る舞い（システム・イメージ）に出来る限り近いメンタル・モデルを持てるようにデザインする事が望まれる。
【例】
以下の写真は古田の車の燃料計である。
 |
目盛りは等間隔にふられているので、針が真ん中に来たらタンクの半分が空になったという事だと理解していたが、どうもそうではない。後半になると急速に針が進むようになる。メンタル・モデル１は最初に古田が抱いたモデル、メンタル・モデル２は修正後のものである。
 |  |
| メンタル・モデル１ | メンタル・モデル２ |
メンタル・モデル２であればとりあえず針の振る舞いを説明しているようであるが、これもまた「普段」の振る舞いから作られたものに過ぎず、また針が奇想天外な振る舞いを見せた時には修正をしなければならない。
インターフェイスの世界でも同様に、デザイナーの側で、「この道具は、こういう事とこういう事が可能なので、その中から選んで下さい」という風に選択肢を提示してやるのが制約である。コンピュータという道具にはこれがなく、何ができるのかわからないので、目的無しに使おうとすると難しく見えるのかも知れない。
【例】
写真は公衆電話のコイン投入口である。
 |
御存じの通り、公衆電話で使えるコインは\10玉と\100玉だけである。このデザインには誤って\500玉を入れてしまわないような制約がある。物理的に大きさが合わず入れることが出来ないようになっているのである。しかし\1玉、\5玉、\50玉は入ってしまうかも知れない（試したことないからわからないが）。
インターフェーイスの世界では、「その道具に対して何ができるかがユーザに視える事が大切である」というのも大切な教えのひとつである。
我々はドアの操作は向こうに開けるか、こちらに開けるか、横に滑って開けるか、上に持ち上げて開けるか、などいくつかの候補がある事を知っている。しかしそれだけでは、実際に目の前のドアはどの方法で開けられるかわからない（ノブも何もついていないただの板状のドアを想像して欲しい）。しかしノブのアフォーダンスなどで押せる事や引ける事が「視える」事によって、行動の選択肢を特定する事ができる。ユーザは対象の動作の選択肢と操作の選択肢の両方があって、初めてその間の中から目的を達成できる対応付けを見出し、行動を起こせるのである。何かを試すには、まず何ができるかが視えない事には始まらないのである。
 |
ドアに対してできそうな事（赤い丸の部分）が「視える」事で、無限の選択肢を絞りこむ事ができる（制約）。その中でも有効な選択肢だけを、アフォーダンスなどを利用して強化すれば、更にわかりやすいインターフェイスにできる。
【例】
写真は古田のワークステーションが、ユーザからの指示を待って待機している状態の画面である。
 |
これに対して考えられる操作の選択肢は、ひとつのコマンドの長さが1〜255文字の可変で、アルファベットの他に数字と一部の記号とが使えるとすると、その種類はおよそ.....誰か計算して！....とまぁ、無限に近い。更にマウスでクリックするのが有効かも知れないし、電源を切るという選択肢もある。ユーザが予めどんなコマンドが有効であるかを知っていなければならない。もちろん、これは悪い例である。
対して、Macintoshに代表されるメニュー・インターフェイスは、システム側から選択肢を限定して提示してくれるので、ユーザは自分の目的にあっていると思われるものを選択すれば良い。
These pages is pruduced by Kazuyoshi Furuta.
Any Comments and suggestions are welcomed. Please send E-mail to me.