Author Archives: Manabu

僕は物理については全然詳しくないのですが、それでも生活の中で感じ取っている自然界の物理法則（によって生まれる一貫性のある現象）というものがあります。例えば物は下に落ちるとか、置いてある物は動かさない限りずっとそこにあるとか、重たい物ほど強く握らないと持ち上げられないとか、走ってて転ぶと歩いてて転ぶより痛いとか、そういうことです。このような「全ての物に共通した性質」を自然界における「スーパークラスのメソッド」と考えて、スクリーン上のユーザーインターフェースにも適用すれば、コンピュータはもっとモードレスになれると思います。 単にタンジブルにすればよいという意味ではなく、論理的な存在である情報オブジェクトに対しても 、物理法則を参考にしたインタラクションが有効だろうということです。 例えばデスクトップに置かれたファイルアイコンは、ファイル本体へのポインターと、メタ情報としてのアイコンを表示しているだけの論理的な存在ですが、我々はそれを作業対象である書類そのものの外観として認識しています。我々の認知は GUI の箱庭に自然に浸かっているわけです。そうであれば、アイコンが置かれた座標は自分が動かさない限り意地でも変わらないでほしいのです。 iPhone の Cocoa Touch が提供する独特なスクロール感などは、かなり緻密に物理的な反作用をシミュレートしていて、タッチ操作に「触感」を与えています。 また見た目だけの話ではなく、ユーザー設定の内容など、自分が変更したものは全て、自分が再度変更を加えない限りもとの状態である方が、自然で、学習効果も高いはずです。 このあたりの実装は、UIの中にモーダルなコンセプトが多くなるほど実現が難しくなります。よく言われることとして例えば、OS9 までの Mac の Finder では、フォルダとそれを開いたウィンドウは常に1対1の関係だったので、アイコンやウィンドウはほぼ完全に前回見たままの状態を再現していました。これが OS X になってブラウザ式のコンセプトに変わったために、Finder ウィンドウは「フォルダ」というオブジェクトではなく「ディレクトリのブラウズ」というタスクになってしまいました。もちろんこれはこれで便利であるという側面もありますが、その結果として、アイコンやウィンドウの視覚的な一意性が失われ、作業がより概念的な計画を要するようになった事実は否めません。 ただし Apple の面白いところは、この「タスクとしての Finder」を積極的に活用して、スマートフォルダやフォルダアクションなど、モードを肯定した上で、そのモードをオブジェクトのように見せるという方向で進化させたことです。これは OOUI を考える上で、モードが必要になってしまうインタラクションをどのように表現すべきか、という課題に大きなヒントを与えています。

対象選択のジェスチャが同時にモードの切り替えを意味する場合、モード切り替えの手続きは「目的語 → 動詞」のシンタックスの中に内包されるので、準備作業として意識する必要がありません。例えば現在フォーカスが当たっていないウィンドウでも、その中のコントロールに対してクリックなりのアクションを起こすと、即座にフォーカスがそのウィンドウに切り替わり、コントロールが反応するのです。 ただしこの振る舞いにはデメリットもあります。まず、オーバーラッピングウィンドウのイディオムにおいては、目的のウィンドウの一部もしくは大部分が手前のウィンドウの後ろに隠れてしまっていることが多く、その場合、まずそのウィンドウを手前に持ってくるという純粋なモード切り替えの手続きが必要になることです。後ろにあるウィンドウの中でクリックしたいコントロールが見えているかどうかは運しだいです。運によって操作の手順が変わってしまうというのは気持ち悪いです。 それから、いくつものウィンドウが開いていてデスクトップを埋め尽くしているような場合、不用意なクリックによっていずれかのウィンドウ内のコントロールが意図せず反応してしまうということもよくあります。 これらの問題は、言ってみればモードレスであることの弊害なので、根本的な解決は難しそうです（作業の対象物が書類の束に埋もれていたり、間違えて違う紙に書いてしまうといった失敗は、現実世界でもよく起きることですし）。ただし、フォーカスを変更せずにウィンドウを移動できるようにしたり、完全な多段階アンドゥ機能を実装することで、対症療法的にユーザーのリスクや心理的な負荷を減らすことはできます。実際 Mac ではこの方法がかなり実現されています。 ところで、前回、「オブジェクト指向UIにおいて、オブジェクト選択のジェスチャが同時にモードの切り替えである場合は、モードは問題にならない」と書きましたが、逆に、問題になるモードとはどのようなモードでしょうか。 これは簡単で、「モードから出るために特定の操作が必要である場合」です。いわゆるモーダルダイアログがその典型で、もとの作業に戻るためには、「OK」ボタンを押すといった決められた操作を行う必要があります。これによってユーザーはシステムに対する自由なコントロールを失うわけです。モードレスモード（オブジェクト選択とモード切り替えが一体化している場合）では、モードから出るには単に次の対象オブジェクトを選び直すだけであり、操作は限定されません。 では、なぜモードというものはこんなにも僕を不快にさせるのでしょうか。それは恐らく、「不自然」だからです。 自然の物理世界では、モードというものは存在しないと僕は思います。モードというものは、貨幣と同じで、常に人と人の間での共通認識の上にしか存在しない、誰かの都合で決められた約束事なのです。 自然界においては、各物体は複雑な相互作用の中で勝手に存在しているのであって、何か決まった目的を持っているわけではありません。例えばアレグザンダーのデザインパターンに出てくる「柱」のように、もとは人が屋根を支えるために作ったものだとしても、柱自体はそんなことおかまいなしです。設計が悪かったり風化したりすれば勝手に崩れます。人の方もまた柱の本来の目的には無頓着で、立ち話しながら寄りかかるかもしれないし、身長を記録するかもしれません。そのような行為は、施主にとっては目的外かもしれませんが、行為自体が柱の性質を決定するわけではないのです。単に、柱として役立ちそうな素材と加工方法を選択しているにすぎません。 こういう物理世界の「モードレスネス」が、ユーザーインターフェースの中にも再現されていれば、僕たちはもっと思い通りにコンピュータを使えるのではないかと思うのです。 そもそも GUI というのは、管理主義に対するそういったアンチテーゼを持ったコンセプトだと思います。機械が複雑化して、「コンピュータ＝オートメーション」という図式が一般化しつつあった時に、データオブジェクトを人が身体動作によってアナログ感覚で操作するという、一見コンピュータの処理効率を台無しにするような操作方法を編み出したのは、ものすごい革命だと思います。よく GUI の次はタンジブルだとか3Dだとか言う人がいますが、彼等は GUI のインパクトを正しく見ていないのです。この人間復興のパラダイムシフトを超える変革は、そう簡単には訪れないはずです。GUI は、ルネッサンスなのです。

モードレスUIを追及していくためには、モードとは何かということについて今一度考えてみる必要があります。 Modelessness というエキセントリックな標語を使っている Apple のガイドラインをおさらいしてみます。このガイドラインはOSのバージョンアップに合わせて頻繁に改訂されているのですが、最新版を見てみると、モードレスネスについて次のように書かれています。 まず、アプリケーションはできるだけモードを持たない方がよい。これはつまり、ある操作をいつでも好きな時にできるようにしておくということです。例えば Mac では、ドロワーはウィンドウ内の要素へのアクセスを可能にしたまま表示されるダイアログだし、シートはアプリケーションに対してではなくウィンドウに対するモーダルダイアログであるように、モードをできるだけ作らないようにするコントロールが用意されていると言います。 次に、ある程度許容されるモードとして、ユーザーが意識的に作る一時的なモードというものがあり、例えばマウスダウンをキープすることでスクロールを行ったり、シフトキーを押したままにすることで連続的な選択範囲を作ることなどがあると言います。 それから、アラートのためのモーダルダイアログ（処理を一時中断することに意味がある）や、インストーラー（ユーザーにガイダンスを示すことに意味がある）も、許容されます。 最後に、現実世界の作業を模すことで生まれるモードというのがあり、例えばグラフィック編集ソフトにおける描画ツールの選択などは、理にかなったものとして許容されます。 ただしモードを作る場合は、現在のどのようなモードにあるのかと、そこから抜け出す方法が明示されていなければならないと言います。 … ということで、確かにこの説明でだいたい分かったような気がするのですが、アプリケーションの振る舞いを細かく見ていくと、モードというのはもう少しいろいろな所に発生しているようです。 前にも書いたとおり、そもそもアプリケーションというものは一種のモードと言えます。またデスクトップにおいてタスクやオブジェクトの基本単位を体現するウィンドウというものも一種のモードでしょう。また、複数のコントロールが同時に見えている時に、現在そのうちのどれにフォーカスがあるのかというのもモードです。アプリケーションにしろウィンドウにしろコントロールにしろ、ユーザーの入力ジェスチャに対してどのオブジェクトが反応するのかは、その時にどれがフォーカスされているのか、つまりモードによって決まります。操作の対象を変更するには、アプリケーションの切り替えやコントロールのフォーカス変更などを、入力ジェスチャに先立って行っておかなければならないのです。 だからモードというものを「操作が限定された状態」と定義してしまうと、このように、コンピュータの中はモードだらけということになってしまいます。 ではここで、ユーザーインターフェースにおけるモードの問題について詳しく考察している、ジェフラスキンの「ヒューメイン・インターフェース」という本を見てみます。 ラスキンはまず懐中電灯を例にあげて、トグル式インターフェースの問題を指摘します。鞄の中にある懐中電灯は現在の状態が分からないので、ボタンを押したときの動作を予測できないと言います。つまりひとつのコントロールが状況によって複数の意味を持つ時、そこには常に潜在的な問題があるということです。あるボタンのラベルがはじめは「ON」で、それを押すと「OFF」に変わるような場合も同様で、そのラベルが現在の状態を表しているのか、押したあとの状態を表しているのか、どちらにもとれてしまうのです。このようなコントロールを、アランクーパーは「フリップフロップ」と呼んで問題視しています。 ラスキンは次に、グラフィック編集ソフトにおけるツール選択の問題を指摘しています。このようなソフトの使用に慣れたユーザーは、通常のオブジェクト選択のためのポインターから、特殊なツールに持ち替えて何かの操作を行った後、もとのポインターに持ち替えるのを忘れたまま次の選択操作を行ってしまい、選択できずに戸惑うということが頻繁に発生すると言います。これは、熟練ユーザーにおいてはオブジェクト選択という操作が無意識に行われるため、モードの切り替えという付加的な手続きを意識に割り込ませることが難しいからです。また初心者においては、そもそもモード切り替えの必要性を意識できないため、同じようなミスを起こします。ポインターの形状で現在のモードが示されていたとしても、ユーザーの注意は対象オブジェクトにあるので、なかなかモードを意識できないと言うのです。 ノーマンは、モードによる間違いを最小化する方法として次の三つをあげています。 モードを持たない モードの違いを区別できるように明示しておく モード毎にコマンドが重ならないようにしておく これに対してラスキンは、本当に有効なのはひとつめだけで、ふたつめはモードの提示がユーザーの注意の所在になければ意味がなく、みっつめはリスクを減らすことはできてもミスの数を減らすことはできない、と言っています。ただし、グラフィックソフトにおけるツール選択を、現在一般的になっている方法以外のやり方で行わせる良いアイデアは無いとして、これを許容しています。 ラスキンの結論はこうです。 「インターフェースデザインにモードを導入する場合、そのモードによって制御される状態がユーザーの注意の所在となっており、同時にそれがユーザーから可視となっているかユーザーの短期記憶に存在することを保証することによってのみ、ユーザーをモードに起因する間違いから解放できる。」 僕なりに解釈するとこれは、次のようになります。 「オブジェクト指向UIにおいて、オブジェクト選択のジェスチャが同時にモードの切り替えである場合は、モードは問題にならない」 操作対象のウィンドウやコントロールを選択するというジェスチャが「目的語 → 動詞」のシンタックスにおける目的語指定に該当する場合は、意識の所在が「今選ぼうとしているオブジェクト」にあるため、モードの切り替えは単に対象物の切り替えということ以上の意味を持たないからです。 目の前にスケッチブックと粘土があり、まずスケッチブックにモナリザを描いて、途中で作業対象を粘土に切り替えてダビデ像を作る。それはモードの切り替えでありながら、そこに混乱の余地はないのです。

僕の中では、かなりはっきりとした二元論が形成されていました。例えばそれは「タスク指向」対「オブジェクト指向」であり、「電車」対「自動車」です。「間接操作」対「直接操作」とも言えますし、「理論」対「実験」、「リンク」対「ノード」、「キーボード」対「マウス」、「セットアップウィザード」対「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に対する価値観が根本的に違うのですから、これを無理に説得するのはほとんど不可能です。

GUI とオブジェクト指向の間には強い繋がりがあると確信していた僕でしたが、その関係性をもっと直接説明した資料はないかと思って調べたところ、それほど多くはないものの、いくつかの文献に行き当たりました。 まず最も権威的なものとして、IBM が80年代に出版した「Object-Oriented Interface Design – IBM Common User Access Guidelines」というのがありました。これは IBM が OS/2 その他の GUI システム全般に適用するために策定したユーザーインターフェースデザインのための詳細なガイドラインなのですが、その前段部分で、「Object-Oriented User Interface（OOUI）」という言葉で GUI の思想を語っているのです。多少強引なところはあるものの、GUI はオブジェクト指向であるべきであるということを具体的な実装サンプルとともに説いているのです。ただ残念なことに、サンプルとして示されるデザインがあまりにもダサいので、Apple のガイドラインのような説得力がありません。理屈はよくても出来上がる画面がこれじゃなぁという感じなのです。OS/2 を思い出してください。あんな感じです。 IBM のこの OOUI メソッドは、後に「OVID（Object, View, and Interaction Design）」というメソッドに発展します。OVID については、「Designing for the User with OVID – … Continue reading →

「目的語 → 動詞」のシンタックスでインタラクションを設計することが GUI において重要であるということは、Apple のガイドラインをはじめ、多くの指南書で説かれていることです。目的語とは多くの場合、処理の対象物のことですから、「名詞 → 動詞」という書き方で同様のことを説明している場合もあります。 とはいえ、実際にパソコンを使っていると、基本的な操作の部分で、「動詞 → 目的語」のシンタックスが結構使われているのです。 まず前にも書いたとおり、アプリケーションの選択という操作はタスク指向です。アプリケーションを選ぶということは、これからやることを選ぶということです。例えばワープロソフトを起動するということは文書編集タスクを選ぶということですし、ウェブブラウザを起動するということはウェブ閲覧タスクを選ぶということです。これは別の言い方をすると、処理対象のデータ集合を選ぶということです。個々のデータオブジェクト（インスタンス）ではなく、データの種類（クラス）を選ぶところから作業を開始しているのです。例えばワープロであればワープロ書類、ウェブブラウザであればウェブページというクラスを選んだことになります。クラスの抽象度や扱える種類の数はアプリケーションによって違いますが、タスクは特定のデータクラスと紐づいていると言えるでしょう。 一方、オブジェクト指向のシンタックスにおけるオブジェクトとは、すなわちあるデータ集合におけるインスタンスとなります。 以前開発が進められていた「OpenDoc」は、パソコンにおける基本的なシンタックスを、タスク指向（アプリケーションにファイルが従属する）からオブジェクト指向（ファイルにアプリケーションが従属する）に転換しようとする試みだったわけですね。 ちなみに、データ集合に対する CRUD のうち、Create Read Update は特定のアプリケーションが行い、Delete（および複製やいくつかのメタデータ変更）はOSのファイルブラウザが行うというのがこれまでのパソコンにおける基本的な役割分担です。ただし iTunes などはファイル管理までもをアプリケーション内で完結させようとしています。 次に、多くのアプリケーションにはメニューに「開く…」という項目があります。これを選ぶと、対象のファイルを選択するダイアログが開きます。つまり「開くモード」に入ります。目的のファイルを選び、ボタンを押すと、ダイアログが閉じて（モードから出て）そのファイルが開かれます。 同様に検索機能も多くの場合タスク指向のシンタックスになっていて、メニューやボタンで「検索…」を選ぶと検索ボックスが現れ、キーワードを入力してボタンを押すと実行されます。 「開く…」も「検索…」も、実行前に気が変わった場合は何らかのキャンセル操作をしなければモードから出ることができません。検索の場合は更に、検索結果を表示するのに通常の一覧ビューを検索結果表示モードに切り替えることが多く、これもまた通常のビューに戻すために何らかのモード終了操作が必要になります。 ユーザーがまずタスクを選択し、何らかの入力操作（コマンド実行の引数となるパラメーター指定）を行い、最後にそれをサブミットすることで処理が実行されるという意味では、「印刷…」や「名前をつけて保存…」もタスク指向のコマンドです。ただしこれらの場合は対象物が現在見ているファイルということで自明なので、オブジェクト指定の操作はありません。 Windows のコントロールパネルやアプリケーションのユーザーオプションでは、このようにパラメーターの指定をメモリにためてサブミットでまとめて処理に投げるという実装がほとんどです。つまりモーダルな操作になっています。だから入力パネルには必ず「OK」と「キャンセル」のボタンがあります。 ところが、Mac の場合はずいぶん事情が違います。あまり語られることがないので Windows ユーザーは知らないのではないかと思いますが、最近の Mac では、そういったモードがほとんど絶滅しつつあります。 これについては、また後日書きます。

僕は、オブジェクトの選択がインタラクションの起点となっているようなデザインを「オブジェクト指向のユーザーインターフェース」、タスクの選択が起点となっているものを「タスク指向のユーザーインターフェース」と呼ぶことにしました。オブジェクト指向といっても、プログラミング様式のそれとは実現のための手段が全く違いますが、コトよりもモノを基準にして構造を作るということや、状況の変化に強い（というか文脈が不確定であることを前提にする）ことを重視するという意味で、根本的には同じ価値観を共有していると言えるでしょう。 GUI のポテンシャルを引き出すには、当然オブジェクト指向のユーザーインターフェースが望まれます。しかし、決められた業務を行うためのシステムにおいては、タスク指向にせざるを得ない場合が多いということも分かって来ました。 ぼくはこの「オブジェクト指向」と「タスク指向」の対比について、よく「自動車」と「電車」に例えて説明します。自動車は、目的地までの行程を自由に決定することができ、途中で道を変えるのも行き先を変えるのもドライバーの自由です。一度行った場所に二度目に行く時には、一度目よりももっと効率的なルートを思いつくかもしれません。ドライブという仕事の帰着点は、結局ドライバー自身が「ゴールに着いた」と自覚した場所ということになります。ただし、目的地までのルートをドライバーが全く知らない、もしくは予測しづらい場合には、あっちでもないこっちでもないと迷子になり、結局辿り着けない（ゴールにたどり着いたと自覚できない）かもしれません。一方電車は、最初に選択肢から目的地を選ぶ（電車に乗る）だけで、途中の地理について全くイメージを持っていなくても確実に辿り着くことができます。しかし途中で道を変更することはできませんし、自分なりの工夫で行程を効率化することもできません。どちらを好むかは人によりますが、ひとつ言えることは、GUI というのは本来自動車であるということです。自動車式の作業に向いたユーザーインターフェースなのです。 最近ではパソコン以外にも、携帯電話や複合機やテレビやゲームや券売機などあらゆるデバイスにグラフィカルなユーザーインターフェースが用いられています。けれど、「目的語 → 動詞」というオブジェクト指向のシンタックスが実現できているものは案外少ないのです。それだと、見た目はアイコンやフォルダといったグラフィック表現になっていたとしても、GUI とは言えないと思います。なんちゃって GUI です。 例えば携帯電話のインタラクションでこういうのがよくあります。メールの本文を表示していて、ある文字列をコピーしたいとします。そのためにはまずメニューを開いて「コピー」を選びます。すると「始点を指定してください」といったメッセージが現れ、十字キーでカーソルを移動して始点に持って行き、「確定」ボタンを押します。すると「終点を選択してください」といったメッセージが現れ、また十字キーでカーソルを動かして終点を指定します。これでやっと「コピータスク」が完了します。ペーストする時にも同様の手順を踏みます。これは相当まどろっこしくないですか？ 操作のステップごとに「始点選択モード」や「終点選択モード」が発生していて、途中でやめようと思ったら、いちいちモードから出るためのキャンセル操作が必要なのです。 つまりこういうことです。オブジェクト指向のシンタックスを実現するには、「対象選択」の操作をいつでも行えるようになっていないといけないのです。そしてそのためには、対象となるオブジェクトが最初から見えていて、それを指し示すためのポインターがシステムの状態に依存せずに常にフリーになっている必要があるのです。 余談ですが、iPhone には当初コピー＆ペーストの機能がありませんでした。これを後から実装するにあたって、いくつかの課題があったと予想します。 まずポインターの自由度についてですが、iPhone におけるポインターはユーザーの指ですから、かなりフリーな状態にあります。ただし指でのタッチ操作では、指し示す対象物を指自体が隠してしまうと同時に、選択範囲の指定という細かい座標移動がしづらいということがあります。また、任意の文字列範囲選択をモードレスに行うためにはドラッグ操作が必要になりますが、iPhone においてドラッグ操作はスクロールを意味しているので使えません。文字列の特定箇所でしばらくタップ＆ホールドしてからドラッグを開始するという操作も考えられますが、このジェスチャは「カーソル周辺の拡大表示」に使われてしまっています。 結果的に、完全にモードレスにすることはできず、タップ＆ホールド＆リリースからのメニュー表示と、ダブルタップでの選択開始という若干手続き的な操作になりました。それでもさすがに「対象選択 → コマンド選択」というオブジェクト指向なシンタックスは崩さないインタラクションを実現しています。また指が対象を隠してしまう問題に対しては、選択ハイライトの両端につまみをつけて、更にドラッグ中にはその周囲を拡大表示するという従来からの表現を再利用することで、なんとか解決しています。 ということで、GUI においては、オブジェクト指向のシンタックスが重要であり、そのためには対象物が最初から見えている必要があり、またポインターは常にフリーでいつでも選択ジェスチャを行えるようになっていなければならず、そうすることでモードを減らすことができる、という方程式が見えてくるのです。