Monthly Archives: January 2020

モードとは何か。ある事象について、そこにモードがあるという人と、そこにモードはないという人がいる。だからモードは少なくとも「解釈」に関係している。物事の解釈の仕方がモードそのものであると言ってもいい。それはどういうことか。 例えば、四季はモードだという人がいる。昆虫の変態はモードだという人がいる。一方で、自然界にモードはないと私は言う。これは単純に言えば、自然をモーダルに見ているか、モードレスに見ているかという、世界の捉え方の違いによるものだろう。 辞書を見てみる。mode は、何かが起きたり、経験されたり、表現されたり、行われたりする上での方法、もしくはマナーである。 「モードとは？」と問われたら、「いつもとマナーが違っている状況のこと」と答えるのが一番簡単だろう。 ソフトウェアデザインにおいてモードが指摘されるのには、大きくふたつの状況がある。ひとつはモーダルダイアログのような「一時的に操作が制限された」状態。通常は許されている操作が、ある条件下では許されないというもの。これを仮に「制限型モード」と呼ぶ。 制限型モードの多くでは、UI全体へのランダムアクセスが制限される。またモードから出るために決まった手続きが必要になる。例えばダイアログの OK/Cancel ボタンを押すなど。これらは対象への直接操作性をスポイルし、UIの情報理論的な効率を下げる。 もうひとつは、単に「ジェスチャの解釈が違う」状態。例えばひとつのボタンが、ある時は「ON」で、ある時は「OFF」の働きをするなど。リターンキーは、改行文字の挿入、直前のコマンドラインの実行、デフォルトボタンの代替、など状況に応じて働きが変わる。これを仮に「転換型モード」と呼ぶ。 転換型モードはUIのいたるところにある。コンピューターというものがそもそも多態性をウリにしているので、転換型モードがなければ汎用性を保てない。だからといってこのモードが常に問題を引き起こしているわけではない。転換型モードが問題になるのは、意図しないかたちでモードが転換した時だ。 転換型モードについてジェフ・ラスキンは『ヒューメイン・インタフェース』の中で詳しく考察した。まずこれを考える上では「ジェスチャ」と「注意の所在」がキーワードになる。ジェスチャとは、一旦開始すると自動的に完了する一連の動作のことだという。 例えば、the というような良く使う単語を入力する場合、初心者のタイピストにとっては各文字のタイピングが個別のジェスチャになる。一方熟練者のタイピストにとっては、単語全体で一つのジェスチャになる。つまり同じ操作をしても、ジェスチャの単位はユーザーによって異なるのである。 次に、注意の所在とは、あなたが意図的かつ活発に考えている対象、つまり現在意識を向けているもの。人は一度にひとつのものにしか意識を向けられない。UIを操作している時、画面上には様々なものがありそれぞれが固有の状態を持っているが、ユーザーの注意の所在は、常にたったひとつのものにある。 リターンキーの例のように、UIではジェスチャに対して複数の解釈が用意されている。これはある人にとっては期待どおりの自然な振る舞いだが、ある人にとっては予想外の反応となる。UIがジェスチャに対してどのように反応しているかは、モードによって決定される。 しかしこれには解釈の余地がある。例えば a という文字をタイプした後でバックスペースを押すとその a が削除される。b という文字の後でバックスペースを押すとその b が削除される。起きたことだけを見ると、バックスペースは、時には a 削除し、時には b を削除するので、モードがあることになる。 しかしテキスト編集中にバックスペースにモード性を感じることはほとんどない。それは、バックスペースの働きについて「直前の文字を消す」という解釈をしているからだ。なぜそのような解釈ができるのかというと、バックスペースを押す時には現在のカーソル位置が注意の所在になっているからである。 操作対象の状態が注意の所在となっていれば操作の意味を解釈でき、その振る舞いを予測できる。注意の所在となっていない、あるいはなっていても状態が曖昧な場合、転換型モードは問題となる。例えばテキスト編集中にカーソルを見失った状態でバックスペースを押せば、予想外の結果になるだろう。 あるジェスチャの解釈が一定である間、そのUIは同じモードにある。ジェスチャの解釈が異なる時、そのUIは別のモードにある。同じ操作が人によって問題であったりなかったりするのは、ジェスチャの単位や注意の所在が、人と状況によって異なるからだ。 その意味で、あるジェスチャに対してシステムが問題的にモードを持つのは、UIの現在の状態がユーザーの注意の所在となっておらず、そのジェスチャに対して複数の異なった応答がUIによって実行される場合、なのである。 “インターフェースデザインにモードを導入する場合、そのモードによって制御される状態がユーザーの注意の所在となっており、同時にそれがユーザーから可視となっているかユーザーの短期記憶に存在することを保証することによってのみ、ユーザーをモードに起因する間違いから解放できる。” Jef Raskin さてここまで制限型モードと転換型モードについて見てきたが、ではなぜこのふたつが同じ「モード」として認識されるのだろうか。ラスキンは、UIの操作として意味を持つ最小の単位「ジェスチャ」のレベルからモードの問題を指摘した。ジェスチャは組み合わさって別のジェスチャになる。 例えばクリックをふたつ組み合わせるとダブルクリックになる。ドラッグとドロップを組み合わせて移動のジェスチャになり、さらにモディファイアキーを組み合わせて複製のジェスチャになったりする。それらがさらに組み合わさって、次第にUIの操作イディオム（慣用句）ができあがる。 制限型モードは、言ってみれば、イディオムレベルでの転換型モードなのである。モードは解釈の仕方なので、ある状況に属した解釈の仕方がある、というだけですでに操作の一貫性は損なわれる。モーダルダイアログが不自由に感じるのは、それまでと地続きでない別の場所に行ってしまうからだ。 モーダルダイアログの中で一生を過ごすのであれば問題にならない。しかしモーダルダイアログと普通のウインドウを行き来しなければならないとすると、そこにイディオムレベルの転換型モードが顕在化する。モーダルダイアログの問題は、モードに入ることではなく、モードが変わることにあるのだ。 例えば「書類を保存しますか？」というモーダルダイアログで「保存する」を押すことが習慣になっているユーザーにとっては、一連の振る舞いがイディオムとなっているので、モードの問題は起きない。逆にこの習慣は「保存する」の選択を自動化してしまうので、ダイアログの意味がなくなるのである。 モードとは解釈の仕方だが、その解釈とは、システム側ではなくユーザー側の解釈である。そしてモードの問題は、モードに入ることではなくモードが変わることにある。モードが無いことをモードレスというが、それは悪い解釈が無いというより、解釈が変わらないということなのである。 モーダルとはモードが変わることである。モードレスとはモードがひとつだけあることである。ソフトウェアは、ユーザーの入力を正規化してプロトコルに照らす。そこには常にプログラマーの計画がある。この計画＝解釈の仕方がなければコンピューターはただの箱だ。モダリティは計画を反映している。 モードは、物事のオブジェクティブな無為の在り方ではなく、サブジェクティブな作為の在り方だ。決められた解釈を強要し、あなたを駆り立てるもの。そのような徴用性が、モダリティなのである。 モダリティは、モードが変わることで現れる。モードがひとつであれば、モードは無いということ。a のキーを押して a が入力されるのはプログラマーの計画によるモードだが、もしそれが常に a の入力であれば、モードは顕在化せず、問題にならない。 例えばテキストボックスも、ウインドウも、アプリケーションも、コンピューター自体もモードだ。だから初心者は解釈しきれず混乱する。しかし慣れると、良くデザインされた部分については一定の解釈が可能になる。ダメな部分は、ダメなままなのである。 ソフトウェアのモードが混乱を呼びやすいのは、その計画がいくらでも恣意的にできてしまうからだ。ユーザーにはコントロール権がない。あるとすれば、プログラマーがそれを与えた時だけだ。しかしそれには高い技術がいる。UIをモードレスにする技術である。 モードレスネスには、一貫性、直接操作性、可視性、即時フィードバック性などが関係している。Macintosh は初期からOSレベルでアプリケーションの見た目と振る舞いを統一させた。Mac のモードレスネスが今も高いのはサードパーティにその思想が根付いているからなのである。 自然界に話を戻す。季節はモードと言えるだろうか。例えば夏の空気は暖かくて冬の空気は冷たい。これはバックスペースの話に似ている。もし現在の時期や場所が注意の所在にあるなら、それは同じ空気として一定に解釈されるだろう。何もわからず外気に突然さらされるなら、モーダルになるだろう。 […]