OOUIへの批判を集めてみる

OOUI、GUI、もしくは名詞→動詞パラダイムへの批判というものはどのようなものがあるかなと思っていて、改めてまとめてみたくなりました。色々な昔の書籍にちょこちょこと書いてあったような気がしますが、読み返してみると意外に見つかりません。

GUIはすでに普及しきっていて一定の結果が出てしまっているとも言えます。現在においても、併用するアイデアはあっても代替となるUIは出てきていません。変化の激しいコンピュータの世界です。さっさと次のものが出てきても良さそうですが出てこないのです。なぜだろうと考えてみましたが、おそらくGUIはデザインの一つの流行ではなく、生物の視覚という普遍性のあるものと関係しているからだと思います。コンピュータの世界よりも人間の身体の変化はずっと緩やかです。

とはいえ、これまでいくつかの書籍を読んできて、名詞→動詞パラダイムの紹介とともに別の視点が記述されていることがありました。直接の批判ではなく周辺情報になってしまいますが、これを機におもしろそうなのでまとめて記録しておこうと思います。

Human Interface Guidelines

昔のAppleの『Human Interface Guidelines』を見てみましょう。

10個の基本的な設計原則のうちの一つ「見たものを指示する」の中には「オブジェクトを指し示し処理内容を選ぶ」という基本的なことや「操作は記憶ではなく認識に基づいて行われるようにする」などなど書かれています。この辺りに何か書かれていないかと探してみるとコマンドラインのインターフェースについても書かれていました。

• プログラマーであれば問題なく使用できるが、それは記憶と演算論理の知識に基づいていて平均的なユーザーはプログラマーではない
• コマンドが複雑で覚えにくいものであれば、ユーザの記憶に大きく依存する
• システムを初めて利用するユーザー、利用頻度が低いユーザーの場合は使いづらい
• コンピュータ側の要求に気を配らざるをえないため、どのようなユーザであっても仕事自体への注意力が散漫になってしまう

その上で以下のように書かれています。

しかし、この“覚えてタイプする” 操作方式にもいくつかの利点があります。処理内容を完全に把握していれば、短いキーストロークだけで操作が可能な場合があります。このため、デスクトップアプリケーションには、メニュー内の処理項目にキーボード代用操作機能（keyboard equivalent）を割り当てているものがあります。これは Apple Desktop Interface が持つ論理的な拡張機能の1つで、処理内容に合わせて細かい調整が可能な部分です。注意すべき点は、この機能は“見たものを指示する” 操作方式の代用ではないということです。どちらの操作方式を用いるかは、処理内容に合わせてユーザ側で決定できるようにしておく必要があります。ユーザが慣れないアプリケーションを使用する場合や、一時的に処理の流れを見失った場合を想定し、スクリーンを見て目的のオブジェクトや処理内容が把握できるような配慮をしておくことが必要です。

『Human Interface Guidelines:The Apple Desktop Interface（日本語版）』

処理内容を完全に把握した状態におけるキーボード操作の利点に触れつつも「“見たものを指示する” 操作方式の代用ではない」と書いてあります。つまり、代替するのではなく併用をすすめています。しかもプログラマでないユーザーを前提にすれば両者は同等ではなく、スクリーンを見てオブジェクトや処理内容が把握できることが大前提にあるようです。

About Face 3

コマンドラインとの比較という点であれば『About Face 3』でも似たような記述があります。間接税的作業について書かれている箇所です。GUIの間接税的作業について考察する際にコマンドラインとの比較が登場します。そこではコマンドラインユーザーがGUIを次のように非難するケースを紹介しています。

• GUIは何かを達成するためにウィンドウやメニューなど余分な操作が必要になる
• コマンドラインはコマンドを入力すればすぐに実行される

確かにさまざまなウィンドウを行き来したり、メニューを開いたりというのはよく行う操作です。

その後、このように続きます。

こういった不満には十分な根拠がある。このようなウィンドウ操作は、実際、間接税的操作にほかならない。ユーザーをゴールに近づけるものではないのだ。アプリケーションがユーザーを助ける前に、アプリケーションが要求してくるオーバーヘッドなのである。しかし、コマンドシステムより GUIの方が簡単に使えることは常識だ。正しいのは誰なのだろうか。

『About Face 3』

なかなか面白い書き方です。間接税的操作であると認めつつも、「GUIの方が簡単に使えることは常識である」と言っているのです。
そしてコマンドラインについても同様に間接税的視点から考察し、GUIと比較して以下のようにまとめています。

• コマンドラインはコマンドを記憶したり、画面をカスタマイズする際に「もっと高くつく」間接税的作業がある
• コマンドを記憶したり、学習のためにかなりの時間と労力をかけると間接税的作業が少なくなる
• GUIは視覚的に明確なので、初めて使う場合もしくは時々しか使わない場合に、いつ何をすべきかを理解したり学んだりする上で役に立つ
• GUIはステップバイステップという性質があり、慣れていないユーザーに役に立つ
• GUIは複数のアプリケーションを実行しなければならない場合も役に立つ

つまり、GUIには確かに間接税的操作はあるけれど、コマンドラインを使いこなせるようになるまでにはGUIよりも多くの間接税的操作があると言っているわけです。

ほかにも『About Face 3』では「選択」を扱った箇所で「目的語動詞順序」とあわせて「動詞目的語順序」が登場します。まずGUIにおける「動詞目的語順序」については次のように問題点を挙げています。

• 動詞を選択するとオブジェクト選択モードが発生する
• 単一のオブジェクトしか選択しない場合はオブジェクトを選択すればよいが、複数のオブジェクトを選択する場合は、選択が完了したことを示す完了コマンドが必要になる（ダイアログボックスのOKボタンなど）

そして目的語動詞順序になっている利点としては

• オブジェクトの選び方が複雑でも動詞を簡単に実行できる
• オブジェクトを選択した時に適切なコマンドだけを表示できる
• その結果コマンドを見つけるための負荷が減る

と挙げています。その上で次のような記述もありました。

目的語動詞順序の方が直接操作に適しているのは確かだが、動詞目的語順序の方が役に立つ場合もある。それは、コマンドのコンテキストと無関係にあらかじめオブジェクトを選択しようとしても、そんなことは不可能だとか無意味だという場合だ。たとえば、地図作成ソフトウェアでは、地図を作りたい住所をリストから選べるとは限らないだろう(アドレス帳からはこれをできるようにすべきだが）。それよりも、「地図を作りたい、以下の住所のものを」という表現方法の方が役に立つはずだ。

『About Face 3』

なんとなく言わんとしていることはわかりますが、まず地図作成ソフトウェアとはどういったものを指すのかがわからないためいまいち消化できません。アドレス帳の住所リストから地図を作ることはすべきであるとしているので、「住所」がオブジェクトで「地図を作る」という動詞があるとして話をしているのかもしれません。

ただ、住所を選べないことが前提にあるのであれば順序を入れ替えたところで何も変わらないようにも思えます。「地図を作りたい」とコマンドを指定しても「以下の住所のものを」から先に進まないからです。

理解ができていない前提でここから何かヒントを得られないか考えてみましょう。

少なくともなんらかの地図の新規作成をする機能についての話であることは間違いなさそうです。

新規作成というアクションの話であると仮定すると、確かに新規作成は特殊なアクションです。まだここにないオブジェクトを呪術師のようにキエーッ！っと天から降ろしてくるようなものだからです。

クラスとしてはあるかもしれないけど、そのクラスのインスタンスが存在していないのであればインスタンス化しなければいけないのと似ています。そして、新規作成アクションによって新規作成モードが用いられることがあるのは事実です。

とはいえ、初期値を持つオブジェクトとして常に表示しておいたり、テンプレートとしてオブジェクト化することで、できるだけモードレスに新規作成する方向もありますので、もしかするとそのあたりと併せて考えてみると楽しいのかもしれません。

ヒューメイン・インターフェース

次はジェフ・ラスキンの『ヒューメイン・インターフェース』です。この書籍に「名詞-動詞形式 VS. 動詞-名詞形式」という記述があります。

そこではこの異なる形式について次のように書いています。

大半のインタフェース・デザインにおいて、両者が対照的になることはなく、順序（名詞-動詞か動詞-名詞か）が使いやすさの大きな違いを生み出すことになるのです。
ほとんどのインタフェース・ガイドラインでは、正しく名詞-動詞形式のやり取りを推奨しています (Apple 1987, Hewlett Packard 1987, IBM 1988, Microsoft 1995)。

『ヒューメイン・インターフェース』

動詞-名詞形式に対する名詞-動詞形式の利点として、モードレスになることで間違いが削減され、簡潔になり可逆性が向上することや、操作対象からコマンドへの操作が迅速になることを挙げています。

その上で動詞-名詞形式が用いられる箇所としてグラフィックツールのパレットを紹介しています。これは今で言えば Illustrator や Photoshop のツールパネルや Figma のツールバーなどでツールを切り替える箇所に該当するものだと思います。選択したツールによって同じジェスチャーでも異なる結果になりモードが発生している箇所です。

ラスキンは名詞-動詞形式で考えるならばどうなるかを示しています。

一度描いた後に属性を変更することで任意の絵を得るという方法です。しかし、ユーザーが本当に欲しているのは属性を備えた状態だとも言っています。

一度描いたグラフィックオブジェクトを選択して色を変えるのか、それとも矩形ツールで色を備えた状態で描くのかといったところです。

ラスキンはこの悩ましいトピックについて以下のように捉えています。

• モードによる間違いが発生する可能性がある
• 幸い、描いているものが注意の所在なので、やりなおせるソフトウェアなら作業を続けることができる
• 名詞-動詞、非モーダルな手法を見つけるのが望ましいが、解決策はまだ見出されていない
• 名詞-動詞形式が望ましく動詞-名詞形式は当面パレットの選択に限る

つまり問題もあるが今のところこの方法を用いる、という感じでしょうか。

『About Face 3』や『デザイニング・インターフェース』でもグラフィックツールのツール選択はモードに関する例外として取り上げられています。

とはいえ「描いているもの」というオブジェクトが提示された上でモーダルな方法の併用を許容する、という話だとすれば「一切オブジェクトを見せないタスク指向UI」とは全く異なります。

アクション自体はモーダルなアクションとモードレスなアクションがあり、特性を把握しておくと様々なインスピレーションが得られることでしょう。

例:ゲームのアイテム

例えばゲームにおいても同様です。体力が回復するポーションは即時完了する「モードレスなアイテム」と位置づけることも可能でしょう。

対して装備すると攻撃できるようになる剣は「モーダルなアイテム」と位置づけることができます。

装備の変更がモードの変更になっているので、グラフィックアプリケーションのツール選択と同様であることがわかります。そしてモードによる問題も同じ要因から発生します。

何も装備をしていないと思っていたら、剣を装備していて意図せず村人を攻撃してしまった、というようなことはよくあるのではないでしょうか。これは攻撃するジェスチャーと話しかけるジェスチャーが同じなのに、モードによって異なる結果になることが原因です。

新しく手に入れた武器を使おうと思ったら、古い武器を装備したままだった、などなど似たような場面はほかにもいくらでもあります。

ラスキンは「やりなおせること」の重要性を挙げていますがゲームではどうでしょうか。

アクションゲームにおいてはゲームの特性としてアンドゥ機能をつけにくいですが、クラフト系の場合は取り入れることも可能かもしれません。

いずれにしても、ゲームも限られたジェスチャーをモードによって多機能化している以上、一定の割合で間違いが発生することは確かです。

ラスキンの言うような「オブジェクト選択後に属性を変更する名詞-動詞形式の操作」が導入されていないならば検討しても良いでしょう。

About Face 3 には目的語動詞順序では「選択」が必要になるとあります。仮にゲームに取り入れる場合は、常時選択できるようにするのか、それともオブジェクト選択ツールのようなアイテムを作るのか検討することになるはずです。また、属性変更のための編集可能なシングルの検討も必要になるでしょう。

ということで話が横道に逸れた気もしますが、引き続き、直接的な批判ではなくてもおもしろい周辺情報を見つけたらメモしてみたいと思います。