Monthly Archives: November 2009

ユーザーフレンドリーとかユーザー中心といったスローガンは、我々に、製品はユーザーに合わせてデザインされるべきであるという価値観を強要しています。 もちろん出来上がった製品がユーザーにとって役立たなければ意味がないのですが、デザインの過程においてユーザーというものをどのように捉えるべきかということについては、再考の余地があると思います。 ひとりのユーザーの要求でもその分解には際限がないのと同様に、ユーザーグループを定義するというのも相当に困難です。 確かにユーザー間にはなんらかの共通属性があるかもしれませんが、コンテクストというものがゲシュタルトである以上、採用されたセグメンテーションの基準は常に設計者にとって都合のよいものにしかなりません。これは、製品のコンセプトをプロジェクト内で共有したり、マーケティングなどで特定の観点から統計を取得するためには役立つかもしれませんが、デザインという厳密な仕様を決める上では明確な手がかりになりません。だから普通は、セグメント毎の要求リストを好き勝手に作り、それに矛盾しない範囲で、誰かがえいやっと仕様を決めることになります。 人はそれぞれ皆違った状況下にあり、またその状況は変化し続けるので、ユーザーサイドの総合的な要求、つまりコンテクストを手がかりに仕様を決めようとすると、ターゲットユーザーの数に比例して仕様が膨らんでいきます。要件リストが長大であれば、システムにまとまりのある世界観を与えられなくなり、デザインは破綻します。しかしユーザーを限定し過ぎれば、汎用性が低下し、多くの場合、製造者の資本集約的なビジネスモデルが成り立たなくなります。 また、なんとかあるユーザーのコンテクストにぴったり合うデザインができたとしても、その分、他のユーザーのコンテクストには合わなくなっているかもしれません。出来上がったシステムについて言えば、仕様は常に厳密であるため、全てのユーザーのコンテクストにマッチするものを作るのはたぶん不可能です。 何が言いたいのかというと、使う人と作る人が分離している場合、ユーザーのコンテクストに合わせてデザインをするという発想は、そもそも無理があるということです。 うまく要件を定義するための取り組みとして、ペルソナを作るのが良いと言われることがあります。これは、ターゲットセグメントにおける個別要件の集積として要求事項を整理するのではなく、仮想の人物像を作ることで実際的なまとまりをもつ要求セットを導き出そうとするものです。そうすれば、コンフリクトを含んだ長大な要求リストではなく、ひとりのコンテクストに無理なくマッチしたシステム像が描けるだろうということです。 確かにこれならば、無秩序な要求の取り込みによって「誰にとっても使いにくい」ものが出来上がってしまうという状況は避けることができそうです。けれど、ユーザーのコンテクストから要求事項を抽出するという意味では、依然として不確定性の問題がありますし、そもそも仮想のキャラクターからリアリティのある要求事項を得られるのかという疑問があります。誰かがそれを代弁するなら、それはその人の「意見」になってしまいますし、何かの統計から「そのセグメントに一般的な要求」を持ってくるのなら、わざわざキャラクターを作る意味がありません。ペルソナのもとになった特定人物がいるのであれば、その人を直接観察なりインタビューなりするべきでしょう。 ペルソナのポイントはキャラクターのリアリティにあるのだと思いますが、キャラクターにリアリティを与えるのはそのキャラクター固有の状況です。けれどその固有の状況を強調すると、セグメントの代表者としての性質がぼやけます。セグメントの代表者でないのなら、そのペルソナの妥当性を説明できません。 ペルソナにしてしまった時点で、そのキャラクターは活動を止めてしまいます。ある人の服をオーダーメードするのに、その人を採寸するのではなく、その人の写真を見て採寸するようなものです。それなら、デザインの手掛かりとしてはターゲットユーザーの属性リストと変わりません。 ペルソナが有効であるとするならば、それは仮想敵国ならぬ仮想ユーザーとして、開発者のモチベーションを高めるプロパガンダになるからでしょう。少なくとも我々の仕事相手は、IDE のエディタ画面ではなく血の通った人間である、というイメージを共有することで、インタラクションデザインの重要性をプロジェクト内で確認するのです。 考えてみれば、なぜユーザーに合わせてデザインしなければならないのでしょうか。ユーザー毎に最適なデザインが異なるとするなら、その考えを突き詰めると、ユーザーの数だけ別々のデザインが必要であるということになります。ペルソナは何人作ればよいのかという質問に対して、「理想はユーザーの数だけです」と答えなくてはなりません。でもそれだとあまりに面倒だし、要件定義として風呂敷をたたむどころか、広げる一方になってしまい、収拾がつきません。道具には、本当にユーザーの数だけデザインが必要なのでしょうか？ ユーザーは人です。人というのは、自分自身では一貫した存在であると思っているかもしれませんが、客観的に見ると、非論理的で、支離滅裂で、気まぐれで、定義しにくい存在です。人という単位で要求をまとめても、仕様に落とし込めるほどの体系を見出すことは難しいでしょう。 道具を使うのは人ですが、その道具がある人の全生活をサポートするのでない限り、人という単位が道具のデザインに対して意味を持つわけではないのです。これは前に書いた、柱に対する行為（寄り掛かったり身長を記録したり）が柱の性質を決定するわけではないというのと同じです。むしろ逆で、柱の性質がそれに対する人の行為を決定するのです。 ユーザーのコンテクストが定義不可能なら、それをもとに要件を定義しようとするプロジェクトは全て失敗します。では、世の中にあるデザインが全て失敗なのかというと、そうでもありません。気に入って使っている道具はいくつもあるでしょう。そのような道具は、自分のニーズに合っていて、思い通りに目的を達成できます。これらを作ったデザイナーは、どうやって僕のコンテクストを定義したのでしょうか。 もう分かると思いますが、そのような道具を作ったデザイナーは、僕のコンテクストなど考えていません。僕自身がその道具に合わせて行動を変えたのです。はじめはうまく使えなかった物に、次第に慣れて、使いこなせるようになったのです。もし、使いこなせるようになるまでに習得しなければならない事柄が多すぎたり、デザインに一貫性が無くて学習不能であったり、そもそも自分の用途に合っていないようなものは、僕にとって役立たない道具ということになります。シンプルで一貫性があり、操作と結果の対応が自明であれば、短期間で使いこなせるようになります。そのような道具は、自分なりの工夫が効くので、多少期待と違う性能だったとしても、我々は自らの要求を変更して、その道具を使うことで得られる利便性を最大化することができます。そうすることで、当初イメージしていた成功体験を超えるような満足が得られるかもしれないのです。 つまるところ、ユーザビリティというのは、ある道具が定数的に持っている属性ではなく、その道具を使う者が、利用体験を通じて感じる認知上の変数なのです。 ということで、ペルソナの理想的な数はいくつか。その答えはゼロだと思います。デザインは、人という単位に対して行うべきではないからです。人という単位に着目してしまうと、デザインの落とし所が見つからなくなってしまいます。 では、我々は、いったい何を手掛かりにデザインをすればよいのでしょうか？

デザインには常に目的があります。というか、あるモノやコトの目的を外在化するための、外界とのインターフェースとなるのがデザインです。機能のデザインはもとより、装飾のデザインにも目的があり、そのモノの性格やメッセージを表現しています。だからデザインの作品というものは無くて、人は作品をデザインするのです。 目的を持ったモノやコトは、それに対峙する何かとの直接的あるいは間接的なインタラクトを期待されているはずです。その意味で、意図的に作られたモノやコトはすべてある種の道具であると言えるでしょう。それに対峙するのが人間である場合、その人はユーザーと呼ばれます。 道具というのは基本的にテクノロジーの産物であって、たとえ耳かきのような単純なものであっても、その形状や材質には何らかの工夫があり、その存在価値である利便性を創出しています。だからテクノロジーが優れているほど、高い利便性を提供できます。利便性を高めることができるテクノロジーほど優れているとも言えます。 道具に高度なテクノロジーが要求されると、それを作るのは専門家の仕事となります。職人とかデザイナーとかエンジニアと呼ばれる人がそれです。彼等は専門的なテクニックを用いて道具を作ることを生業とします。この段階で、道具を使う人と作る人が分離するわけです。 作る人は、その道具の利用価値を高めるために、使う人のニーズをさぐります。使う人の用途や好みにぴったりのものができれば、自分の仕事が高く評価されるからです。 19世紀初頭に家具職人であったミヒャエルトーネットは、画期的な曲木技術を発明し、また効率的な製造方法を確立したことで、その後発売した No.14（214）という椅子を大ヒットさせました。これがマスプロダクションの始まりと言われています。それまで家具というのは高度な工法を要する量産困難なもので、基本的に手作りの受注生産でした。それが、産業革命による工業化と独自の加工技術によって大量生産できるようになり、高品質の製品を安価に提供できるようになったというわけです。 それ以前にもちょっとした小物であればそれなりの量産ができたのでしょうが、家具のような複雑な道具についてまで大量生産されるようになったことで、道具のデザインは、個別のクライアントのニーズに対してではなく、不特定多数の「ユーザー層」のニーズに対して最適化される必要がでてきました。 ユーザーが限られていれば、道具の合目的性を高めるのは比較的簡単です。しかしユーザーが多くなれば難しくなっていきます。オーダーメイドであれば発注者の希望を細かく反映することができますが、不特定多数がターゲットである場合、人によって利用のコンテクストが異なるため、仕様について割り切らなければならない度合いが増します。つまり言ってみれば、デザインというのは、合目的性と汎用性のバランスのことなのです。どちらに寄せていくかは、製品の性質によって自然に決まります。 もし合目的性のみを最大化するなら、ユーザーを限定して、徹底的に要求を分析し、いつ何をどのようにしたいのかということを厳密に定義すればよいのです。そうすると、例えばあるひとつの業務を完全に定義し、それに特化した画面を作ったら、そこには、ボタンがひとつだけ見えているということになるでしょう。「業務実行」というボタンです。要求事項が完全に特定されているならすべての処理を自動化して内部に隠匿できるからです。ユーザーの操作はそのボタンを押すだけです。いや、それすら必要ないかもしれません。ジェフラスキンは、「ある状況でユーザーに許された操作がひとつだけであれば、その操作は省略できる。」と言っていますから、ボタンがひとつだけしかないのなら、それは無くすことができます。つまり、そのユーザーがシステムにログインした瞬間に処理が実行されればよいのです。もっと言えば、朝出社してタイムカードを押した瞬間でよいのです。というか、そうなったらもうその業務は存在しないのと一緒ですね。 このような極端なことに普通ならないのは、要件定義の段階において、ユーザーのコンテクストというものを完全には定義できないからです。人の活動には必ず恣意的な側面があり、あるいは、仕様化できない創造性が期待されているのです。コンテクストというのは、個々の要求事項から帰納的に構造化できるものではないのです。コンテクストの全体像を特定できないとすれば、要求分析の限界点を事前に予測することもできないということです。 要求の特定が必ずしもユーザビリティの向上に直結しないというのは、次のように考えると分かります。 あるシステムに対して1000通りの要求があったとします。それらひとつひとつを厳密に定義できたなら、それぞれの要求に対応した1000個のボタンを画面に並べればよいということになります。そうすればユーザーは何をするにもボタンを一回押せば済むので、合目的性と操作効率は最大になります。しかし実際には、そんなシステムは誰も使えないのです。それはデザインとは言えません。 1000通りの要求というのを、もっと汎化できるのではないかと思うかもしれません。しかしコンテクストは無際限に細分化できるので、どこまで分析しても最小粒度に行き着かないのです。最小粒度が曖昧であれば、構造化は不可能です。1000通りの要求を特定できたと思っても、その粒がユーザーの目的に照らして十分に細かいのかということを、短時間で評価する方法はないのです。なぜならユーザー自身ですら、自分のコンテクストの変化を正確には予測できないからです。 このように、ユーザーのコンテクストを分解することでシステムの要件を定義しようとする試みは、簡単に壁に突き当たってしまうのです。

我々は、道具の操作性について議論をする時、ユーザビリティという概念を用います。ユーザビリティという概念は、定量的な計測対象として厳密に定義されることもありますし、もっと感覚的な評価も含めて広く定義されることもあります。ただし教科書的な文脈においては、ISO 9241-11 の定義がよく引用されます。 定義の原文はこうです。 ISO 9241-11 のユーザビリティ定義： Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. また、ISO 9241-11 をもとにした JIS Z 8522 というものがあり、上の定義を和訳したものとして次の一文があります。 … Continue reading →

僕はゲーマーではありませんが、FPS は結構好きで、特に「Marathon」シリーズと「Call of Duty」シリーズにはかなりハマって、それぞれ数年間やり込みました。もちろんネットワーク対戦です。その反面、RPG やシミュレーションもの、シューティングでも第三者視点のものにはあまり面白さを感じませんでした。僕はガンダムに乗りたいのであって、ガンダムの背中を眺めたいのではないのです。 僕が FPS を好きなのは、それがモードレスでありリアルタイムだからです。スクリーンに映る世界は僕の視界そのものであり、僕がとったほんの小さな動きも、相手を含むその世界全体に何らかの影響を及ぼします。僕は、スコープの向こうでこちらに照準を合わせる敵と、というかその敵を操作する誰かと、目が合うのを感じることができます。不意に敵に遭遇した時、引き金を引くか逃げるかの判断は瞬間的になされなければいけません。敵は待ってくれませんし、僕も待ちません。ステージ上の全員が同じ時間と空間を共有しているのです。 もうひとつのポイントは、バーチャルな世界にいる自分のアバターのスキルは、そのまま僕自身のスキルだということです。何か特定の手続きを踏むことで勝手に能力が上がったりはしません。僕の射った弾が当たるかどうかは、純粋に僕の状況判断とマウス操作のスキルにかかっているのです。だからそのアバターは、感覚的には、僕の分身ではなく僕自身です。視覚と聴覚に限定されているとはいえ、僕の意識はほぼ100パーセント没入し、その世界と直接インタラクトしているのです。そうでないとやられてしまうし。 FPS では、戦況を読んで戦術を考えることはあっても、操作を計画することはありません。状況は無限にあり、操作を手続き的に計画することに意味がないからです。今何をするかは、その場その場の状況から逐次判断しなければならないのです。 なんだかこれと同じようなことを前にグラフィックソフトの話で書きましたね。まあそういうことです。 さて、ここに、ヨーロッパの包丁と日本の包丁を比較した興味深い記事があります。両者の比較から日本人の美意識を定義するのは少し乱暴な気がしますが、デザインというものが目指す大きなふたつの方向性を示唆しているのは確かでしょう。以下は引用。 一つはドイツのヘンケル製。人間工学的によく出来ていて大変使いやすい。これが西洋流のシンプル。握ると自然に親指の位置も決まる。しかし、超絶技術を持つ日本料理の板前はグリップに凹凸のない包丁を使う。平板な把手は貧しさや未成熟ではない。むしろその逆である。どこを持ってもよいという完全なプレーンさが、板前のあらゆる技術を受け入れる豊かさになる。 この日本の包丁のプレーンさが、僕には強烈にかっこよく感じられるのです。 T字型カミソリの宣伝では、首振り3枚刃でどんな顔にもフィットしてよく剃れるとか何とか言っていますが、プロの理髪師はそんなもの使わないのです。固定の一枚刃です。というか、T字型安全カミソリではなく、フリップ式で刃が剥き出しの危険カミソリを使いますね。T字型にしても剥き出し型にしても、勝手に刃の角度が変わってしまったら、力の加減ができないから思い通りに剃れないのです。最高の結果を出すカミソリは、切れ味だけを提供し、力や角度の調節については人が提供する余地を残しておくべきなのです。 このような道具は、ユーザーに相応のスキルを要求します。だからもしユーザーがそれをうまく使えずに目的を達成できないとしても、それは道具のせいでもユーザーのせいでもないのです。 前にオブジェクト指向のところでこう書きました。「僕が特に重要だと考えたのは、文脈をユーザーに解放するということでした。システムは自身の機能を体現するだけで、使い方をユーザーに指示するべきではないと思いました。ある道具が役に立たないとすれば、それはその道具が状況に適していないだけで、ユーザーの使い方が悪いのではないはずです。物それ自身がありのままの状態で状況とのマッチングを待っている、というのが、僕の解釈したオブジェクト指向の世界でした。」 これはそのまま、板前の和包丁の価値感に通じています。 たしかブラックジャックの本間先生がこんなことを言っていました。「人間が生き物の生き死にを自由にしようなんておこがましいとは思わんかね。」あるいは、どこかのお百姓さんの言葉、「わしらは水とちょっとの肥料をやってるに過ぎん。育つ力は種自体の中にあるんじゃ。」というのを思い出します。 デザインが人の仕事を決めるのではなく、人が自分の仕事に合うデザインを選ぶのです。そこで選ばれるためにデザインは、道具自体をモーダルなコンテクストから解放する必要があるのです。 以下は僕が一番気に入っているジェフラスキンの言葉です。 作業に対するニーズというものがユーザーごとに異なっているとしても、ユーザー集団は多くの一般的な心理属性を共有しているのです。つまりインターフェースデザイナーは、アプリケーションの調査や個人差を埋める作業を始める前に、全人類が共通して持っているインターフェースデザインに対する要求を活用して、自らの作業量を低減させることができるのです。

Apple が実践する「モードレス＆リアルタイム」のインタラクションデザインは、作業の中から課税的な手続きを減らして、現実世界で我々が直接的に物に接するのと同じような感覚でソフトウェアを扱えるようにするための、よい方法だと思います。アプリケーションウィンドウには「保存」という手続きが無く、ユーザーは、動的にファセット分類されたデータオブジェクトを、大工がハンマーで釘を打ち込むように直接操作することができるのです。 ただしこの動的なグルーピングは、これまでの GUI の肝であった「空間的な一意性」と両立できないため、大きなトレードオフとなっています。そこで Apple は、Finder における「スマートフォルダ」、iTunes における「（スマート）プレイリスト」、iPhoto における「イベント」や「人々」などのように、タスクをオブジェクトのように見せることで、GUI 要素についての再定義を行おうとしているように見えます。 そうは言っても、コンピュータからモードを完全に取り去るのはほとんど不可能だと思います。それはコンピュータの特徴である多態性と矛盾するからです。デジタルデータやそれを処理するプログラムが概念的なロジックの産物である以上、そこには非連続的に定義された「用途」が存在し、それはタスクとなってユーザーを教育し、「意味のある操作」と「意味のない操作」をはっきりと区別します。ボタンも何もない所をクリックしても、システムにとってそれは意味のない操作なので、対象オブジェクトへは何の影響も与えません。つまりコンピュータプログラムは、必要な処理だけを実行するのです。プログラムに書かれていないことは起こらないのです。 コンピュータが持つこの従順性は、ユーザーの行動をコントロールしたいという管理者の欲求を満たすためには都合がいいのですが、その反面、自然界で経験するような、複雑な因果関係の中で偶然（と感じられながら）生まれる創作結果、言ってみれば人と道具が無限の可能性の中から限定的な根拠に基づいて作り出すコピー不可能な質をクリエイトするには向かないものだと言えるでしょう。 そうだとしても、操作のイディオムが「自動車」式であり、入力した内容がリアルタイムに反映され、そのフィードバックが即座に示され、そして各オブジェクトがコンテクストに対して自律的であれば、コンピュータでの作業にも奥行きを持たせることができるだろうと思います。別な言い方をすれば、ソフトウェアにも味わいを持たせることができるということです。 道具の味わいというのは、それを使った結果に良い意外性があるとか、使い慣れる程に思い通りの成果をあげられるようになるといった状況で感じるものです。はじめは分からなかったデザイン上の工夫に後から気付いたり、不合理だと思っていた部品に合理性を見出すなど、使い手側がある程度の経験を積むことで道具の特徴を理解し、あるいは目的に対して不足している点を補えるようになることで、人と道具が互いにポテンシャルを高めるような状況です。こういう状況になると、人はその道具を手放すことができなくなります。それはもう自分の能力の一部になってしまうからです。 もう少し単純に言えば、自分なりの応用がきくかどうかということです。応用がきくということは、道具に柔軟性があるということと同時に、使う側も道具に合わせて使い方を変えることができるということでもあります。だから人間の気まぐれに対して道具が一貫した性能を出せるかということが問題なのです。これは、道具が常に同じ結果を出すという意味ではありません。むしろ逆で、結果がユーザーのスキルと一貫した対応を示すということです。下手に使えば下手な結果になり、上手く使えば上手い結果をもたらすということです。スキルとは、一定の手続きを正確になぞることではなく、自分で良いやり方を考え実践できるということです。そのようなスキルに応じる道具、打てば響くような道具というのは、シンプルで無駄が無く、操作と結果の対応が自明であるようなコンポーネントの組み合わせで構成されている必要があります。 Apple の1987年版「Human Interface Guidelines: The Apple Desktop Interface」には、巻頭の「Philosophy」の章に、次のような一節があります。前にも少し要約した部分ですが、改めて引用してみます。 ———— A view of the user （前略）このように人と仕事との関係に注目し、目的に合ったインターフェースを生み出すため、Apple Desktop Interface は、その対象となる人々のモデルを想定してきました。しかし、実際には人間の活動は複雑で変化に富み、人とコンピュータとの関係を完全に体系化できるような理論を構築するには至っていません。このような理論は極端に単純な形に置き換えて考えることができます。これは、人間の思考や行動様式はコンピュータ側からも影響を受けるからです。この意味で、コンピュータの設計と人間の活動は互いに影響し合いながら発展するものだと考える必要があります。Apple 社は、人間の行動の詳細の多くが理解されていなくとも、人間が示す反応に着目することが、わかりやすく効率的なコンピュータ環境の設計に役立つと考えています。 Apple Desktop Interface は、人間が生まれながらに好奇心を持った存在であるということを前提としています。好奇心は学習への欲求と言い換えることができますが、学習効果は自分の置かれている環境に自発的な探究心を持って接した場合に最も高くなると言えます。人間は自分を取り巻く環境をコントロールしたいという欲求を持っています。これには、自分の行為に対して掌握感を持とうとすること、そして、その結果を確認し、理解しようとする欲求が含まれます。また、意思の疎通には、言語をはじめ視覚や身振りによる伝達手段が用いられているように、人間は記号や抽象表現に慣れ親しんでいます。そして、条件が揃えば創造的で芸術的な存在ともなり得ます。作業や生活の場を楽しむことができ、やりがいに満ちたものであれば、生産性や効率は非常に高くなります。 ———— … Continue reading →

CRUD における Create、つまり新規作成の操作をテンプレート方式で行うことについて、Keynote などに見られるような、アプリケーション起動後にテンプレート選択を促されるインタラクションは成功していないと書きましたが、これは、「アプリケーション起動」と「テンプレート選択」が「動詞 → 目的語」のモーダルなシンタックスに感じられるからです。もしテンプレートがファイルとしてあらかじめデスクトップに見えていて、そこからすぐに新規作成ができ、編集内容が自動保存されるようになっているなら、逆に「目的語 → 動詞」のシンタックスになるでしょう。 ちなみに Keynote では、テンプレート方式という点でひとつ興味深いインタラクションが提案されています。PowerPoint や Illustrator などのベクターグラフィック編集ソフトでは、たいてい図形描画ツールというのがあって、例えば矩形描画ツールを選ぶとポインターが十字になり、キャンバス上でドラッグすると、その始点と終点を対角線とする矩形オブジェクトが生成されます。しかし Keynote では違う方法で矩形オブジェクトを作ります。まず図形メニューから矩形のアイコンを選びます。するとすぐにキャンバスの中央にデフォルトのスタイルを持つ矩形オブジェクトが生成されます。ユーザーはその矩形に対して大きさや塗りなどのスタイルを指定していくことになります。 PowerPoint と Keynote の違いは、PowerPoint がまず描画モードの選択から入るのに対して、Keynote ではテンプレートとしてのオブジェクト選択から入ることです。Keynote における矩形オブジェクト生成はモードレスなのです。これは小さな違いのように見えますが、Apple のインタラクションデザインの方法論が色濃く反映された特徴的な振る舞いだと思います。 その方法論とは、「モードレス＆リアルタイム」です。 昨今の Apple のソフトウェアでは、「モードレス」と「リアルタイム」ということがはっきりと意識されています。例えば、システム環境設定をはじめ、ユーザー設定系のダイアログには、ほとんど「キャンセル／OK」のサブミットボタンがありません。ダイアログボックスの体裁はとっていても、それらはモードレスダイアログであり、各入力項目は基本的に入力したそばから反映されます。ボタンを押して入力内容を確定させるという課税タスク的な手続きは不要になっています。Windows ユーザーが Mac にスイッチした場合、慣れるまでは OK ボタンを探して混乱してしまうかもしれません。しかし慣れると、これはとても自然な操作性であるように感じられるはずです。 現実世界にはモードは無い、と前に書きましたが、例えば目の前の紙に文字を書く時、書いた内容を確定するなどという手続きは不要であり、書いた瞬間からそこに書かれているのです。 このように、リアルタイムに入力が反映されると、ちょっとした入力ミスに対する修正タイミングや、入力内容に対する心理的な確認ステップが欠落しているように感じられるかもしれません。しかし多段階アンドゥが可能であれば、入力ミスを恐れずに、操作に対するシステムの状態変化を逐次的に確認できるので、むしろ心理的な負荷はずっと低いはずです。 それから、モードレスなイディオムが反映された特徴的なコントロールとして、「Done（完了）」ボタンがあります。最近の Apple のソフトウェアでは、この「Done」ボタンを頻繁に目にします。これは一時的に表示されるペインの中などに表示され、これを押すとペインが閉じたり元の画面に戻ったりするという意味でサブミットボタンのように見えます。しかし従来の「OK」ボタンとは違います。「OK」ボタンはそれが押された時に入力内容をシステムにサブミットしますが、「Done」ボタンは単にペインを閉じるという意味しか持ちません。つまり入力内容はすでにリアルタイムに反映されているのです。だから「Done」ボタンの隣に「キャンセル」ボタンはありません。入力した（反映された）内容を無効にしたい場合は、必要な回数だけアンドゥを行えばよいのです。 例えば iPhoto … Continue reading →

GUI においてモードを表す最も基本的なコントロールがウィンドウです。このウィンドウというものを、Apple がどのように定義付けているのか、ガイドラインを見てみます。 まずウィンドウというものは、アプリケーションやデータを見たり、それらとインタラクトするためのフレームであると言っています。そしてウィンドウには次の四種類があると言います。 ドキュメントウィンドウ アプリケーションウィンドウ パネル ダイアログ＆アラート ドキュメントウィンドウはファイルと対応していて、そのファイルの内容を表示します。ワープロソフトなどで用いられるものです。 アプリケーションウィンドウはアプリケーションと対応していて、そのアプリケーションで行う作業に必要なオブジェクトをひとつのウィンドウの中にまとめて表示します。Windows における MDI とは違い、複数のペインをタイル状に配置した表現になります。iTunes などがこのタイプです。アプリケーションウィンドウは、インスタンスとして、同時に複数開くことができます。 パネルはいわゆるフローティングパレットで、補助的なコントロールをモードレスに提示するのに用いられます。Keynote のインスペクタなどがこれに当たります。パネルも、インスタンスとして複数開けるようになっている場合があります。 ダイアログ＆アラートはユーザーからのレスポンスを要求するためのもので、いわゆるモーダルダイアログです。 ここで注目したいのが、アプリケーションウィンドウです。最近の Mac および Mac 用アプリケーションでは、このタイプのウィンドウが増えています。前回書いたとおり、Finder も、かつてはフォルダと対応したドキュメントウィンドウだったのが、Mac OS X になってアプリケーションウィンドウになりました。システム環境設定もこのタイプですし、iTunes、iPhoto、Mail、iCal、iMovie ’09、アドレスブックなどもこれです。 アプリケーション選択とは、すなわち作業対象のクラスを選択することであると前に書きました。アプリケーションウィンドウはこの考え方をビジュアルに体現していて、特定クラスのデータ集合を管理するダッシュボードとなっています。 アプリケーションウィンドウの中では、デスクトップメタファが提供してきた空間概念がありません。データはファイルとしてパッケージングされた存在ではなく、抽象的なオブジェクトとして表現されます。実際には iTunes で扱う音楽データも iPhoto で扱う画像データも個々のファイルとしてどこかのディレクトリ階層の中に保存されているのですが、アプリケーションウィンドウの中では、各オブジェクトが持つファセット属性によって動的にグルーピングされて見えています。 扱う対象のデータが増えると、デスクトップメタファにおける空間的な、排他的なフォルダ階層では管理が難しくなります。この問題に対する積極的な解決策として、ファセット分類をベースとしたダイナミックな一覧表現を全面的に採用しているわけです。 動的なグルーピングでは、ひとつのオブジェクトが同時に複数のビューに見えていてもメンタルモデルとして破綻しません。同じ曲が複数のプレイリストに入っていてもおかしくないのです。プレイリストやスマートフォルダは「保存された条件で検索する」というタスクを意味しているわけですが、これらをファイルやフォルダといった従来のオブジェクト表現で提示することで、モードをオブジェクトのように感じさせることができます。また、アプリケーションウィンドウはインスタンスとして複数存在できるので、アプリケーションというモード自体もオブジェクトのように扱うことができるわけです。 ところで、前に、一般的なアプリケーションでは「開く…」というメニュー項目において「動詞 → 目的語」のシンタックスが入り込んでいるということを書きました。とは言っても、ファイルを開くための操作としては、対象のファイルアイコンをまず選択してから「開く」コマンドを実行するとか、ダブルクリックするとか、アプリケーションアイコンにドロップするといった「目的語 → 動詞」の方法もあるので、大した問題にはなりません。 … Continue reading →

僕は物理については全然詳しくないのですが、それでも生活の中で感じ取っている自然界の物理法則（によって生まれる一貫性のある現象）というものがあります。例えば物は下に落ちるとか、置いてある物は動かさない限りずっとそこにあるとか、重たい物ほど強く握らないと持ち上げられないとか、走ってて転ぶと歩いてて転ぶより痛いとか、そういうことです。このような「全ての物に共通した性質」を自然界における「スーパークラスのメソッド」と考えて、スクリーン上のユーザーインターフェースにも適用すれば、コンピュータはもっとモードレスになれると思います。 単にタンジブルにすればよいという意味ではなく、論理的な存在である情報オブジェクトに対しても 、物理法則を参考にしたインタラクションが有効だろうということです。 例えばデスクトップに置かれたファイルアイコンは、ファイル本体へのポインターと、メタ情報としてのアイコンを表示しているだけの論理的な存在ですが、我々はそれを作業対象である書類そのものの外観として認識しています。我々の認知は 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において、オブジェクト選択のジェスチャが同時にモードの切り替えである場合は、モードは問題にならない」 操作対象のウィンドウやコントロールを選択するというジェスチャが「目的語 → 動詞」のシンタックスにおける目的語指定に該当する場合は、意識の所在が「今選ぼうとしているオブジェクト」にあるため、モードの切り替えは単に対象物の切り替えということ以上の意味を持たないからです。 目の前にスケッチブックと粘土があり、まずスケッチブックにモナリザを描いて、途中で作業対象を粘土に切り替えてダビデ像を作る。それはモードの切り替えでありながら、そこに混乱の余地はないのです。