Monthly Archives: November 2009

僕の中では、かなりはっきりとした二元論が形成されていました。例えばそれは「タスク指向」対「オブジェクト指向」であり、「電車」対「自動車」です。「間接操作」対「直接操作」とも言えますし、「理論」対「実験」、「リンク」対「ノード」、「キーボード」対「マウス」、「セットアップウィザード」対「Photoshop」と言ってもいいでしょう。これらは皆同じ構図を指しています。 ユーザーインターフェースの性格、もっと言えば道具の性格を決定する根源的な思想として、このような二大派閥がが存在するのです。東西の横綱です。 ユーザーインタフェースの一番基本的なデザインパターンとしてこの両者をうまく表現する言葉はないだろうかと僕は考えました。上に書いたような例を全部ひっくるめると、両者の本質は一体どこにあるのでしょうか。 僕はふと、何かの本でユーザーインタフェースのおおまかな体系をXY軸の散布図で表現していたのを思い出し、本棚を探しました。 それは、「GUI デザインガイドブック – 画面設計の実践的アプローチ（日本人間工学会・アーゴデザイン部会 スクリーンデザイン研究会 編）」という本でした。この本の最初の方に、「ユーザインタフェース・マップ」という図があって、縦軸が「論理的操作感＜操作感＞直感的操作感」、横軸が「目的指向＜思考パターン＞経験指向」となっていて、そこに ATM やパソコンや電話などいくつかの代表的なデバイスが散布されています。 マッピングの内容自体はいまいちよく分からない部分もあるのですが、僕は「思考パターン」軸の両端に書かれた文言を見て、おっと思いました。片方の「目的指向」方向には「モード領域」、もう片方の「経験指向」の方向には「モードレス領域」と書かれていたのです。 「モーダル」と「モードレス」というふたつの性質が、ユーザーの思考パターンの両極であるとする考え方に、僕は膝を打ったのでした。これはユーザーインターフェースの設計思想の両極でもあるはずだからです。僕の中の二元論は、全てこの言葉で言い表せます。「モーダル」と「モードレス」こそが、ユーザーインターフェースの世界をつかさどる両雄なのだと確信しました。 そして僕が「よいユーザーインターフェース」と感じていたものの正体は、要は「モードレス」ということだったのです。オブジェクト指向UIの本質は、モードレスであることなのです。多くのデザイン原則が共通して表そうとしている事柄とは、「直接操作」も「ユーザーコントロール」も「見たままを得る」も「即座のフィードバック」も「目的語 → 動詞」も、つまりは「モードレスであれ」ということなのです。 こうして僕は、はれてモードレス党員になったのでした。

GUI に現れる記号は、Apple が言うとおり、自然言語、視覚言語、身体言語のコンビネーションで構成されています。自然言語とはラベル類で、視覚言語はウィンドウ、アイコン、フォームコントロール、およびハイライトやスライドなどのフィードバック効果、そして身体言語はマウスの操作を中心とした入力ジェスチャです。 これらの記号が組み合わさって、イディオムとなります。ジェニファーティドウェルの「デザイニング・インターフェース」によれば、ユーザーインターフェースのイディオムには次のようなものがあります。 フォーム テキスト編集ツール グラフィック編集ツール スプレッドシート ブラウザ カレンダー メディアプレーヤー インフォメーショングラフィックス 没入型ゲーム ウェブページ ソーシャル空間 ECサイト よく分からないものもありますが、要するにこういう粒度の世界観をイディオムと言っているわけです。 例えばグラフィック編集ツールは、ビルアトキンソンの MacPaint によって基本的なイディオムが確率されたと言われています。Photoshop をはじめ、その後に登場した同種のアプリケーションは、だいたい似た操作性になっています。 ジェニファーティドウェルは同書で、僕の言っている「記号」と同じような意味でパーツという言葉を使い、次のように言っています。 「各パーツが十分に慣用的であり、パーツ同士の関係が明確になっていれば、ユーザーは初めて目にするインターフェースであっても経験的知識を駆使して理解できる。ここでパターンの出番がやってくる。」 デザインパターンとは、ある目的に対して慣用的になっている記号の組み合わせ方です。ひとつひとつの記号はレゴブロックのように高い汎用性を持っていて、その組み合わせ方は無限にありますが、先人の経験の中からうまくいっているやり方を抽出してくることで、設計効率と利便性を最大化しようとするものです。 ところで、デザインパターンを語る上では、アレグザンダーの「無名の質」を避けて通れません。アレグザンダーが建築におけるパターンランゲージを編纂しようとしたのは、生活空間の中でいつのまにか生まれてくる「いい感じ」を計画的に再現すべく、そこに現象として確認できるいくつかの共通要素を抽出してまとめようと考えたからです。 無名の質とはコンテクストそのものであり、自然界の事物が持つ、複雑で相対的な関係性の中で感じとられるものです。だから人がこれを直接作り出すことはできませんが、そのエッセンスを調べることには意味があるでしょう。 なぜなら、それがデザイナーにとって飛躍のコツとなるからです。 その意味で、デザインパターンというものを即物的なカタログとして捉えるべきではないと思います。単なるコンポーネントとしてではなく、発想の転換や視点の相対化のために役立てなければいけないのだと思います。 そんなようなことを、僕は「デザイニング・インターフェース」の監訳をしながら考えていたのでした。 それと同時に、僕はオリジナルのUIデザインパターンを作ろうと決めました。そこでは、単なるサンプル集ではなく、簡単にはコンポーネント化できないような、もっと感覚的あるいは思想的なパターンをあえて取り上げようと考えました。世の中にまだそういうものがないと思ったからです。 そこで僕はまず、ユーザーインターフェースにおける最も根源的なデザインパターンは何だろうと考えはじめたのです。

自動車式システムの操作性は実験的です。ひとつひとつの操作に対するフィードバックを手がかりに次の操作を決めながら、作業対象の状態をいい感じに持っていくことが求められます。作業の手順は無限にあるので、自分なりの工夫でより良い結果を導く努力をしなければいけません。 一方、電車式システムの操作性は理論的で、作業の初期段階ですでに結果が分かっています。というか結果の種類を選択することが操作の中心です。作業手順は限定的で、タスクを決めたら後は流れに身を任せるだけです。 どこか目的地に行く時に、自動車を運転していくのか電車に乗って行くのか、どちらを好むかは人によって違うでしょう。仮にどちらも同程度の時間とコストと労力で行けるとして、自分が運転免許と車を持っているならば、車で行くことを選ぶ人が多いのではないでしょうか。分かりませんが。 ここで問題になるのは、「運転免許」の存在です。つまり運転する技能です。目的地まで自動車で行くためには、ややこしい運転技能を体得していなければならないのです。電車で行くのにそんな特殊な技能は必要ありません。道を間違えずにちゃんと行けるかという心配も不要です。 自動車式のシステムを使いこなすには、ある種の技能が必要なのです。 この技能というのは、知識とは少し違います。知識も必要ではありますが、操作の各段階で状況を適切に把握し、次の妥当な一手を見極める判断力が問われるのです。これが実験的という意味です。作業の対象物が望むものと違う感じになってきてしまったら、途中で方針を変えたりして試行錯誤し、自らのアイデアで状況を好転させる才能が必要なのです。 GUI はコマンドラインに比べて初心者にも分かりやすいとか直感的に操作できるとか言われますが、上記の理由から、それを使いこなせるかどうかはユーザーの資質によって決まると思います。センスと言ってもいいかもしれません。 同時に、ユーザーインターフェースがユーザーの技能体得をうまく助けるようなデザインになっているかどうかも重要です。デザインが良ければ、ユーザーは短時間で技能を高め、思い通りに使えるようなります。ただしこの場合の良いデザインというのは、インタラクションにおける記号的表現の論理性や妥当性によって生まれるもので、そういう非自然言語的な表現を解釈することが苦手だったり、面白味を感じない人にとっては、苦痛でしかないのです。逆にそういうのが好きな人にとっては、ワクワクするような世界になります。 1987年版の「Human Interface Guidelines – The Apple Desktop Interface」には、一般的なユーザー像の定義として次のようなことが書かれています。 人は生まれながらにして好奇心に富む。学習効果は、自分のおかれた環境を自ら探求する時に最も高まる。 人は環境をコントロールしたがる。対するものを制御しているという感覚を持つことと、自分自身の行動の結果を理解することを好む。 人は記号や抽象表現に慣れ親しんでいる。そのため、言葉、視覚言語、身体言語によるコミュニケーションを好む。 人はよい環境が与えられると想像力豊かで芸術的になる。人が最も生産的になるのは、仕事や遊びの環境が楽しくやりがいがある時である。 僕はこのくだりがとても好きなのですが、どうも一般論としては理想的すぎるように思われるのです。これを前提にシステムを設計すると、要は Mac とか Newton とか iPod とか iPhone みたくなるわけですが、これらのユーザーインタフェースに接してもピンとこない人は結構いるでしょう。悪いとまでは思わなくても、Windows と Mac の違いはメニューバーの位置とフォントぐらいだと感じている人はかなりいそうです。 話を戻すと、自動車式のシステムである GUI を使いこなすには、グラフィックや「目的語 → 動詞」のシンタックスで構成された記号論を解釈しなければいけません。そのためには、記号自体がきちんと論理的に設計されていることと、それを無理なく理解できるユーザーのセンスが必要です。はじめて目にする記号であっても、その意味や振る舞いを推測する手がかりがあれば、ユーザーの理解は進みます。逆に既知の記号とコンフリクトするようなものはユーザーを混乱させます。 記号を読み解く難度を下げる第一の方法は、誤解の余地が無いほど記号を単純にすることですが、提供する機能が多くなればユーザーインターフェースに求められる表現力も高くなり、記号も増えて複雑化します。そこで必要になる第二の方法が、すでにある程度の有効性が確認されている既存の記号の再利用、つまりデザインパターンの活用なのです。

オブジェクト指向UIとタスク指向UIの主な違いはそのシンタックスにありますが、通常は、ひとつのシステムやアプリケーションの中に両方のシンタックスが混在していたり、あるいは目的と手段の関係のように、いま選ぼうとしているのがオブジェクトなのかタスクなのかは作業段階のどこから見るかで相対的に決まる場合が多くあります。例えばデスクトップにあるブラウザのアイコンをクリックするという行為は、ブラウザというアプリケーションオブジェクトの選択であるとも言えますし、そこから開始するウェブの閲覧というタスクの選択であるとも言えます。 そもそもパソコンという道具は、ひとつのシステムでいろいろな仕事をするためのものですから、その上で作業の合目的性を高めるためには、何かのタスクに特化したフレームワークやアプリケーションの存在が必須になってきます。何にでも使える道具というのは結局何にも役立たないわけですから。 そう考えると、オブジェクト指向UIとかタスク指向UIというのは、方式として機械的に設計できるようなものではなく、もっと感覚的なというか、思想的なものなのだと思います。ある機能をどちらのシンタックスで実現するかは、自由に選択できるわけではなく、そのシステムの基本的なコンセプトから必然的に決まってくるものです。だからどちらが優れているということはないのですが、コンセプトが曖昧だったりインタラクションの一貫性が意識されていなかったりすると、両者がコンフリクトを起こして、不合理でちぐはぐな操作性になってしまうのです。 コンセプトというのは、そのシステムが提供するサービスの世界観や、道具としての操作性を決定するイディオムのことです。「自動車」や「電車」はイディオムの例です。移動手段としてどちらの乗り物も存在意義があるように、ユーザーインターフェースのイディオムにもこうでなければいけないというものはありません。ただ何度も書いているとおり、GUI というのは基本的に「自動車」的なイディオムのアプリケーションにマッチした表現なのです。 さて、ここでひとつ気づいたことがあります。 Windows の普及によって大勢の人々が GUI を受け入れ、「自動車」式イディオムの分かりやすさや生産性を認識したかのように思われますが、実際には、そうでもないようなのです。というのも、いろいろなクライアントを相手にオブジェクト指向UIを意識したデザインを提案していると、タスクの内容にかかわらず、担当者によって気に入ってもらえる場合と、どうしても納得してもらえない場合があるのです。業務要件やフィージビリティとは関係ないレベルで、何か生理的に受け付けない人というのがいるようなのです。割合で言えばむしろそういう人の方が多いぐらいで、六割ぐらいの人が、実は「自動車」式のイディオムが嫌いみたいなのです。 どうも、ユーザーインターフェースというもの全般に対する価値観が違うようです。自動者式を気に入る人達は、ユーザーインターフェースを「料理の道具」のように見ているのに対し、そうでない人達は「料理のレシピ」のように見ているのです。料理のレシピというのは、つまり目的達成までの手続を示すもので、イディオムで言えば「電車」式に必要なものです。言ってみれば、世の中の半数以上の人は GUI を使いながらも電車式のイディオムを求めているようなのです。 例えば彼等は、複雑で操作方法が分かりにくい画面を改善するために、「説明書きを加えればよい」とか、「エラーメッセージにヘルプ的な指示を出せばいい」といったことを言います。画面をもっとシンプルにしようとする方向には消極的です。UI要素をもっと記号的かつ合理的にして、重複するアクションや対象オブジェクトの表現を一元化することにあまり価値を見出しません。料理道具の無駄を減らして取り回しを良くするよりも、レシピをもっと詳しくすることの方が有益であると考えるのです。PDF をダウンロードさせるためには、PDF のアイコンを見せるよりも、「PDF をダウンロードするにはこちらをクリックしてください」という指示文のリンクを置こうとするのです。不可逆的なコントロールを何とも思わず、あらゆる操作に確認ダイアログを出したがり、そしてサブミットが成功したことを告げるだけの完了画面に固執するのです。 UIに対する価値観が根本的に違うのですから、これを無理に説得するのはほとんど不可能です。