不確かなメタファー

About Face 3 読書ノートの25。

いろいろと文句の多い アラン・クーパーと About Face 3 のみなさん、回を重ねるごとにますます意気軒昂ってわけで、今度の標的はメタファーかぶれのデザイナーなのです。

なんか、正しいメタファーを見つけることが仕事だなんて思ってるヒトたちっていますね。バカデスネ。なんて調子で、今回は、ちょっと冷笑的な態度で始まります。

そりゃ、ユーザーに内部の仕組みまで学ばせるような実装丸出しデザインよりはだいぶマシ。ただどうも、インタラクションデザインにおいてメタファーは過大評価されすぎているんじゃないかって。

うまいメタファーがあれば直感的に使えるようになるというけれども、冷静に考えてみて、インターフェースの学習を効率化する上でメタファーが果たす役割って案外ほんのちょっとじゃない？その割に、じつは弊害の方が結構多くって、あんまり利口なやり方じゃないと思うなあ、なんて言ってます。

たとえば、いまだによく見かけるフロッピーのアイコン。あれ、「保存する」ことを表現するメタファーってわけだけど、しかし今時フロッピーなんて、ねえ？若い子はもうそんなの見たことないだろうし、扱ってるファイルの容量からしても現実に見合わなかったり。下手したら保存先なんてネットワークの彼方かもしれないのに。

だから、作業結果を保存したい時はこれをクリックするんだってことを学ぶのに、もはやあの絵柄はまるで役に立ってないでしょ。たぶん、ツールチップかなんかで機能との対応を確認してみんな済ませてるんじゃない？

今でもあの絵柄の意味するところにへんに拘ると、考え込んだ挙句、なにか別のことを期待しちゃうかも知れなくて、かえってインタラクションデザイン上よろしくない。じゃあ、フロッピーよりももっとふさわしいメタファーを他に探せったって、これが案外難しい。

フロッピー的な発想はそのままで、もっとモダンなものをっていうと、ハードディスク？だけど、フロッピーと違って滅多に手にするものじゃないから、みんなが一発でそれとわかるような絵柄を決めるのは難しそうだし。

じゃあ、保存先のメディアじゃなくって、もっと概念的な、そうそう、ファイルとかフォルダってのは？って、そんなのもう「新規作成」とか「ファイルを開く」で使われちゃってるし、そんなら、デスクトップ・メタファーからも離れて、保存する、永続化するってことを表すみんなにお馴染みのイメージを探せって、えー、そんなのあります？なんてことになっちゃう。

まあ、しかし、なんだかんだで、あの絵柄と機能の対応を学んだ後では、とりあえず、その意味するところはあまり深く考えず、たんに他と区別するための記号として役立ってもらえればいいかと、そんな付き合い方になるんだろうけど、そういうのはメタファーじゃなくて、修辞学的にはシンボルって言ったほうがいいんじゃないの。

シンボルはその形状に頼ってシンボライズされる何かを表象するわけじゃない。形状と表象される内容の結びつきは恣意的なもので、その結びつきはそれとして学ぶしかない。って、あれ？ メタファーを使うことの意味は、機能や目的を意識的に学ばずとも直感することじゃなかったっけ？

それに、フロッピーのメタファーなんて、それひとつだけとってみれば、非常にささやかなもんだから、シンボル的なものへの変わり身も早く済むだろうけど、こんなこと →
http://www.answers.com/topic/magic-cap になってたらどうする？シンボル的なものとして付き合うったって、あまりにも余りが多すぎるってなもんじゃない？

なんて、あのちっちゃいアイコンひとつつまみ上げて、軽くこんなかんじです。そういっぺんにいろいろ言われても、ぼくら、ただ圧倒されるだけでイヤハヤ、なんて心細くなってきますけれども ( だいぶ勝手に行間を読みまくった結果と言えばそれまでですが ) 、心配御無用、メタファーのなっとらんところを突き詰めると、だいたい次の四つのポイントにまとまるって話なんです。

クーパーは言います。( たぶん、両手を広げて肩をそびやかし、吐息まじりにノンノン言いいながら ... )

1) メタファーは足りない

いっとくけど、われわれの日常的な言葉づかいにメタファーは潤沢に溢れかえっているし、メタファーの効用はとてつもなく大きなものダヨ。About Face 3 に書いてあることなんてメタファーだらけだしネ。メタファーなしで同じ内容を人に伝えろって言われても困るヨ。

でも、インターフェースを学習するための方便としてはどうカナ？

アイテムの購入とか、リファレンスの検索、フォーマットの設定、写真解像度の変更、統計分析の実行 ... こういうアクションにぴったりのメタファーを探せって言われても、けっこうドンピシャのを見つけるのってムズカシくないデスカ？

あるいは、プロセスだとか、データやオブジェクト間の関係性だとか、なんらかの形式の変換だとか、いってみればコンピュータならではの物事って一体どんなメタファーで表現すればいいのカナ？

インタラクションデザインでいうメタファーって、たいてい、機能や目的を簡単な絵で表す、いわゆるビジュアルメタファーのことなのネ。

そうすると、当然、関係性だとか抽象的概念だとか、絵に書きにくいものは扱いにくいってことになるネ。で、わざわざコンピュータやらシステムやらを使って人間がやりたいことって、ケッコウそういうものが多いんダヨネ。

それにサ、そもそもワレワレがこれからデザインしようとしているモノは、三次元的な限界からも、機械化時代のパラダイムからも解き放たれた、人びとに力を与える全く新しいナニカなワケでショウ？

そういうモノを、そういうモノがなかった段階の物事で喩えようなんて、土台無理な話じゃナイ？

インターフェースデザインに使えるメタファーって、だからほんのチョットしかなくて当たり前なのヨ。

2) メタファーは通じないこともある

何が当たり前って、これこそホントに当たり前ッチャー当たり前の話ダケレドモ。同じ絵を見ても文化的背景が異なれば全く正反対の意味を読み取られてしまうこともないとはいえないよネ？

仮に文化的背景は共有していたとしてもダヨ、人それぞれの考え方、感じ方の違いってのはどうしても残るしネ。たとえば、デザイナーが飛行機の到着時刻をチェックするために用意したアイコンが、ユーザーには、飛行機のチケットを予約するためのアイコンに見えたりネ。

こんな不確かなものをインタラクションの基盤に据えようなんて、ネェ？ やっぱりヤバイと思うヨ。

3) メタファーは変化についてこれない

フロッピーのことで言った最初の問題、そして最大の問題はこれだネ。みんながよく知ってる現実世界の何かとシステムの機能や目的の照応関係が、いったんは上手く馴染んでも、システムの成長や進化に、コレマタ当たり前だけどその現実世界の何かの方はついてきてくれないのヨ。

言い換えれば、メタファーにはスケーラビリティがないってことなんだけどネ。

喩えにも使えるほどみんながよく知ってる事柄ってことは間違いなくそこには不変性があるんだよネ。一方、システムのほうはその本性としてどんどん進化しちゃうのネ。

だから、システムとメタファーの恋ははじめから叶わないサダメなの。カナシイネ。

4) メタファーはすぐに邪魔になる

インタラクションデザインにおけるメタファーの役割はサ、意識的な学習なしで、直感的に、システムの目的や機能を把握できるようにするためにあるんだよネ。

じゃあサ、メタファーで伝えたかったことを把握しちゃった後はどうなのヨ。中級者にとっては、必ずしも必要のないお節介になりかねないよネ。

メタファーとしての役割を終えたら、ひっそりと、一種の識別子として生きていくのは、メタファーの処世術としてアリだと思うケド、インターフェース全体の隅々まで一貫して統一されたメタファーで説明しきるやり方、いわゆるグローバルメタファーみたいなヤツだとヤッカイダヨ。さっき出てきた MagicCap がそうだネ。下手すると、いつまでも消えない初心者向けウィーザード並のオーバーヘッドになってしまうヨ。

... と、とりあえず以上です。言われてみれば、たしかにごもっとも、イヤなるほどねぇーってかんじなんですが、じゃあ、一体なんだってそんなメタファーってやつがこんなに幅をきかせているんでしょうね？

そのことについて About Face 3 は、「インターフェースは直感的に使えるのがイチバン」という定言命法にいつの頃からかデザイナーが盲目的に従ってしまっているからだ、と 言っています。「チョッカンテキってナンダヨ？」って。

インタラクションデザインにおいて「直感的」であるということは、そもそもどういうことか？About Face 3 による説明を勝手にまとめるとこんなかんじになります。

直感とは、意識的に行われる思考を伴わない判断や洞察のこと。意識的に行われる思考を伴わないという点では、直感と本能はよく似ている。しかし、本能がまさに生まれつきによってこの場での意識的な思考をキャンセルするのに対し、直感は、過去に別のところで行われた学習に基づいてそうする点が異なる。

つまり、ゴミ箱のアイコンがあれば、不要なデータはそこに放りこめばいいのだと「直感的」にわかる。ただし、それがわかるのは、現実世界において、ゴミはゴミ箱へ捨てるということをすでに学んでいる人だけだってことですね。

で、ここからがかっこいい。

インタラクションデザインにおいてメタファーを使うってことは、過去にどこか別の場所で行われた、人それぞれの学習の結果に頼ることではないのか？それは、あまりにもアンコントローラブルな状態であって、本質的なところで「デザイン」とは相反するアプローチなのではないか。

... って、そこまでは言ってないか。でも、まあ、そういう方向で意気込んでですね、できるだけ、もっと正々堂々と、インタラクションの現場、デザインの力がおよぶ範囲で決着をつけたらどうかとAbout Face 3 は言うんです。

えー？でも、どうやって？

その答えがイディオム中心のデザインってやつで、じつはメタファーのシンボルへの転化ってとこにその萌芽が見られるなんてことも言えてですね、むしろ本題はここからなんですけど、ちょっと長くなるのでいったんここで切りますね。つづく。

ツールのエクスペリエンス

About Face 3 読書ノートの 24。

Chapter12 「よき振る舞いのデザイン」は、クーパーの関白宣言とでもいうべき内容です。おれより先に寝てはいけない式の戒めを一方的にまくし立ててます。一言で言えば、ソフトウェアは思慮深くあれってことなんですけど、例によって、一言で言い切ってすっきりしちゃうような人じゃないわけです。

こんなかんじなんですよ。

おれに関心を示せ、敬意を払え。

常に先を見て、常識と洞察力を働かせながら、おれのニーズを予測しろ。

おれに必要な情報はちゃんと示せ、でも、うるさく質問はしてくるな。

いたずらに不安がらず、トラブルは穏便に収めろ。自分の問題でおれに負担をかけるのはやめろ。

なんでも用意周到にこなせ。ときにはルールを曲げなきゃならないことがあることも知っておけ。

そして、責任は全部おまえがとれ。

って、ね。こう書いてみるとすごいですよね。つい、続けて、

おれに関心を示せ、敬意を払え。
おれに関心を示せ、敬意を払え。

なんて、勝手にサビをつくって歌いたくなってきます。
まあ、いろいろ好き勝手言っているようですけれども、言わんとするところをよく読んでみると、ここで要求してることの数々は、A.よく気がつく子の特徴と、B.気だてのいい子の特徴に二分できそうなんですよね。すなわち、

＜A.よく気がつく子だよ＞

先が見える
ニーズを予測する
用意周到である
洞察力を持つ

＜B.気だてのいい子だよ＞

ユーザーに対して関心を持つ
ユーザーに敬意を払う
ユーザーに必要な情報を提示する
あまり質問しない
常識を知っている
穏便にエラーを収めることができる
ルールを曲げるときを知っている
自分の問題で他人に負担をかけない
自信を持っている
責任をとる

これ、B.のほうは、ツールとして現場に出てくるときには、当然あらかじめ身につけておいてしかるべきビジネスマナーってかんじですよね。

ツールとしてどんな仕事をするのかはともかくとして、ツールである以上、人間様に対してとるべき態度は自ずと定められている。あるいは、特定のユーザーや状況に奉仕する星の下に生まれついたのであってみれば、身の処し方にもやっぱり一定の規範というものがある。

だから、デザイナーはペルソナやらシナリオやらでツールの境遇を追い込んで、目当てのユーザーに気だてのいい子だよとかわいがってもらえるような振る舞いのパターンを身につけさせようとするわけですよね。その子の器量、つまり、ツールの使用価値の大元のところとは別の水準の話としてね。（あれ、だんだん政治的に正しくないかんじの表現になってきちゃったかな。）

一方、A.のほうはちょっと違う。先、予測、用意、洞察って、これ、どれもまず相手の反応を見なきゃ始まらないですよね。コール＆レスポンスの反復の中から少しずつ確度を上げていくしかないようなもんじゃないですか。一体こんなことをあらかじめデザインすることなんてできるんでしょうか。

でも、about face 3 は言うわけです。コンピューターなんだから、もっとユーザーの操作をせっせと記憶したり推論したりしてもいいはずだろうと。それではじめてよく気がつく子にもなれる。で、そこのところに本気で取り組むとすれば、じゃあ一体何をどんなふうに記憶するのか、そしてどんな推論を働かせればいいのかってことが問題になるわけだけど、そこにひとつ、デザインのしどころがあるんじゃあるまいかって。つまり、あらかじめ拵えておけるのは、気がつく能力自体じゃなく、気がつける能力だってことですよね。

ユーザーにどんな体験をしてもらうかってのをユーザーエクスペリエンスデザインと呼ぶなら、これはいわば、ツールエクスペリエンスデザインですね。操作される体験のデザイン。

いい道具ってのは使い込んでいくうちに手に身体に馴染んでくるなんてよくいいますけれども、あれ、使うほうが道具に合わせて使い方を馴らしていく一方で、道具のほうも、使われ方によって微妙に変形したりしてくるもんなんでしょうね。

誰かが使い込んだギターには弾き癖のようなものが残っていて、ちょっと触るとすぐわかるなんて、このあいだテレビで char が言ってました。

そういう、よい道具の特徴みたいなのを、ソフトウェアやデジタル製品にも持ち込むことはできないかって、そういう話として理解してもいいんじゃないでしょうか。これ。

about face 3、それこそ周到なことに、コンフィギュレーションとはまたちょっと違うんだ、なんて注意まで促してるくらいで。

具体的には、まず、ユーザーが入力すべき価値のある情報は、すべて記憶すべき価値のある情報でもあるなんて前置きをしながら、次の3点に着目して記憶をデザインしなさいと言ってます。

・よく入力される値
・あるオブジェクトについて直前に行われた指示や選択
・ユーザーにとっては実質的にひとつの操作として見えているはずの作業手順

そして、推論を行う際に従うべき指針としては、「ほとんどのときにほとんど正しい」という蓋然性重視のスローガンを打ち出しています。

まあ実際、サジェスト機能だの、よく使うページ/ファイルだの、ファイルを開く・保存するっていったら、前に選択したフォルダが開くだの、そうした思慮深さの恩恵はすでに当たり前のものになりつつあるわけですけれども、いざ、そのあたりを自分でデザインすることになったらですね、ただそうした局所的なデザインパターンに従うだけじゃなく、ああ、これはこのツールが一体何を体験するかについてのデザインなんだよなあ、なんて頭で取り組んでみるといいかもしれないですよね。

ひょっとしたら、みんながびっくりするような、本当に気がつくよい子にしてあげられるかも知れません。

-----------------
sent from W-ZERO3

モーダルを選ぶキリコ

ぼくは今、総務部のおじさんたちのためのアプリケーションのことを考えている。彼らに与えられた仕事にかかる負荷を軽減しつつ、それでいてその効果を最大化することが求められている。そこで、ぼくはクーパーに習って、まず、彼らのゴールを探る。彼らのエンドゴールは、求められたことを、過不足なく、つつがなくやり遂げることである。エクスペリエンスゴールは、なるべくそれに煩わされることがなく、ほとんど機械的に済ませてしまえることである。ライフゴールは、だから、そんなつまらない仕事はさっさと終えて、もっと生き生きとした時間をより多く過ごすことである。つまり彼らは、これからぼくが考えるアプリケーションと共にする時間をなるべく短くしたいと考えていて、これ以上短くならないのなら、なるべく楽に、心を亡くしても無事にやり過ごせるようなものにしてほしいと願っている。

彼らはしかし、けっして馬鹿でも子羊でもコンドルの自由を知らない被抑圧階級の一員でもない。ただ、彼らの人生全般において、ぼくがこれから考えなければいけないアプリケーションのすべてが、クーパーのいう間接税にすぎないというだけのことだ。彼らの本当のライフゴールを支える道具は他にきっとある。

クーパーのゴールダイレクテッドデザインとは、反面から捉えていえば、間接税的操作の排除、もしくはその最小化だと言い換えていい。そのためのペルソナでありシナリオだ。しかし、自分がデザインしようとしている道具がまるごと間接税扱いされてしまう事態には触れていない("間接税的なポスチュア"というものもあるのではないか？)。ぼくはおそらく、総務部のおじさんたちのために、クーパーが忌み嫌う、徹頭徹尾モーダルな、ウィザード風のインターフェースを提案してしまうだろう。

この話の筋は、ひょっとすると、ドクターキリコの安楽死肯定論に似ているかもしれない。人の一生をもっと大きな何かの前で相対化することがキリコのニヒリズムだったろう。しかし皮肉なことに、キリコの最期はブラックジャックのヒューマニズム（人の一生の全体化）に感じ入りつつ、誰かの全体のために我が身を犠牲にすることで訪れる。(いや、ぎりぎりのところで、結局、ブラックジャックに助けられてしまうんだった！)

キリコのかたわらに、本間先生が姿を現してくれることはきっとなかったんだと思うよ。
-----------------
sent from W-ZERO3

単斜グループって何ですか？

About Face 3 読書ノートの23。

About Face 3 に、階層構造（特にフォルダの中にまたフォルダがあるような、同じ種類のオブジェクトの入れ子構造）はふつうの人には理解しにくく、取り扱いも難しい。それよりも「単斜グループ」を使ったほうがいい、みたいなことが書いてあるんです。

単斜グループ？ 何それ？

説明を読めば、それが、階層を持たない一列の並び、ということで、現実世界でいえば、本棚やファイルキャビネットのようなものだとわかります。

Webでは、下記のサイトで説明が読めます。

Monocline grouping (Global Constant)
http://globalconstant.scnay.com/2009/09/10/monocline-grouping/

「A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy)」

ってね。

しかし、これがなぜ「単斜」なんでしょう？ 地学で「単斜構造」といえば、

weblio 石油/天然ガス用語辞典 単斜構造
http://www.weblio.jp/content/%E5%8D%98%E6%96%9C%E6%A7%8B%E9%80%A0

「地層が、ある広がりにわたって、おおむね同一方向に傾斜している地質構造をいう。」

ってことで、

http://commons.wikimedia.org/wiki/File:Monocline01.gif (wikipedia commons) ← こういうことですね。

結晶の単位格子の種類にも「単斜晶」というのがあって、

http://commons.wikimedia.org/wiki/File:Monoclinic.svg (wikipedia commons) ← こういうことですよ。

これらに共通しているのは、まあ、一方向に傾斜してるってことですけど、About Face 3 がいう monocline grouping にナナメは関係あるの？

本棚がスカスカで本がナナメになっちゃってるって？

なんかぜんぜん腑に落ちないんですよ。ところが、前のエントリーを書いているとき、monocline 単斜 と、mono な cline は違うのか？と、思いまして、cline を調べてみたところ、

Google 英語辞書
http://www.google.co.jp/dictionary?langpair=en|en&q=cline&hl=ja&aq=f

「a series of similar items in which each is almost the same as the ones next to it, but the last is very different from the first」

こう出ました。

つまり、先頭から後尾にかけて、要素の性質がだんだん変化していく配列みたいなことでしょう。生物学の用語として連続変異とも訳されるようですね。

こっちのほうが、About Face 3 と Global Constant が説明している monocline grouping にフィットしませんか？

もっとも似ている者同士が隣合うように並べておいて、類似度の差が大きくなっているところが、グルーピングの境目だと心得ておく。

階層なんてややこしいことは考えず、そうしたひと並びの列にモノをしまっておいたほうが、人にはやさしいというのが monocline grouping でしょ。

というわけで、どういうつもりでクーパーが monocline という言葉を選んだのか、英語ネイティブが monocline と聞いてどんなイメージをまず心に抱くのか知りませんが、とりあえず、monocline grouping を、「単斜グループ」と訳すのは、ちょっと不適切なんじゃないかと思うのですがどうでしょう。

じゃあ、何と呼べばいいか？ もう、「クラインなかんじに並べとく」って言うしかないかな？ でも、クラインとかいうと変な形の壺が目に浮かぶしな ... 。

ぼくらの純インタラクションを守れ

about face 3 読書ノートの22。

about face 3 に、まるで一大スクープのように、

「ナビゲーションは間接税的な操作だ」

なんて大きな見出しを打っている箇所があります。

そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。

そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、

(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)

1.移動。アプリケーションを構成する複数のウィンドウ間、あるいはウィンドウ内の複数のペーン間の。

2.探索。ツール、コマンド、メニュー、あるいはオブジェクト、コンテンツ、データの。

3.切替。オブジェクト、コンテンツ、データを表示する範囲または粒度の。

と、こう列挙されるわけですよ。

あらためてこれらのひとつひとつに思いを馳せてみてください。ユーザーエクスペリエンスなんつって、ほとんどナビゲーションがらみで埋め尽くされているようなもんじゃありませんか。

これが全部、ゴールに直接向かうわけではない、間接税的な操作だっていうんですから、たとえ400円になったとしてもタバコのほうがよっぽど良心的なかんじがします。

で、思うんですよ。じゃあ、ナビゲーションじゃない、無税の、つまり真にゴールダイレクテッドなインタラクションって逆に何？

上のナビゲーションの定義に習って思いっきり大きく出ると、オブジェクトとかコンテンツとか、とにかく何らかのデータの表現を確認して、これになにか手を加え、その結果、データがどんなふうに変化したのかをまた確認すること、この往復、循環、ってことになるでしょう。

ナビゲーションのタイプのうち、上記の2.も3.も抜いてですよ、ほんとにそこだけ純化して取り出したら、これ、非常に僅かな、希少なもんなんじゃないですか。これを純インタラクションとでも呼んで、どっかに含有率を書いといてほしいですね。

いや、しかし、だからといって、虐げられた民びとよ立ち上がれ、今こそこの圧政に反旗を翻せ、とかって話じゃないんですよ。だってこれは、いわば、その純インタラクションの本性がもたらしている宿命ですからね。逃れることはできません。

つまり、僅かとはいえ（いや、含有率とは関係なく）、純インタラクションの全体は、デバイスの表示領域に入りきらないほどデカいわけです。だから常に部分的にしか取り扱うことができず、そのために上記の移動、探索、切替が必要になっちゃって、結果、インタラクションのほとんどがナビゲーションになってしまうということですもんね。

ほんとにもう、インタラクションデザインって、この宿命をどう受け入れるかについてのデザインだと言い切っちゃいたくなるくらいのもんで。ですから、インタラクションデザインの戦術レベルでの指針は、ユーザーの視覚、認知、記憶、運動にかかる負荷を下げ、フロー状態を良好に保つってことだと思うんですが、そうする上で障害として立ちはだかってくるのは、大抵、ナビゲーションがらみということになるはずです。

そのために、--- つまりナビゲーションの氾濫から純インタラクションを守るために --- about face 3 が立てた作戦はこうです。

●永久オブジェクト

どんなにシステムの状態が変化しても、けっして消えてなくならないものを用意し、これを一番はじめに印象づけておこう。

永久オブジェクトこそ、すべてのナビゲーション起点であり、次にとりうる選択肢を常に示している道しるべであり、そして、いよいよというとき、最後に頼るべき縁でもあります。

たとえば、システムと同じ寿命を持つトップレベルのウィンドウ、グローバルナビゲーション、デバイスの物理的なボタンとかね。

●位置情報

全体像と現在位置をいつでも知ることができるようにしておこう。

その方法は、今、まさに部分的に取り扱っているオブジェクトの性質に合わせて、いろいろな手口を考えておく必要があるでしょう。

たとえば、Webサイトならブレッドクラム。画像編集ソフトなら、現在表示している範囲を縮小された全体像中に矩型で示すオーバービュー。ウィンドウシステムでは、現在表示している位置と範囲を、全体に対する相対的な長さで表現してもいるスクロールバーとかね。

●自然な対応関係と構造

純インタラクションにおいて、ゴール達成を容易にするための交換条件としてまあまあ見合う、ということならともかく、一介のナビゲーション風情が、自分のために新しいものの見方や習慣をユーザーに押しつけるなんてことがないようにしよう。

ありがちなのが、車のウィンドウを開閉するボタンが縦一列に四つ並べられている場合、右後部座席のウィンドウを開閉するには何番目のボタンを押したらいいでしょうか？ --- 的なレイアウトの対応関係にみられる鈍感さ。

あるいは、時系列のソーティングの方向を、「昇順」「降順」というデーターベース用語で選ばせるような、ラベルと機能の対応関係にみられる普通の人にとっては不自然な実装モデルの押しつけ。

それから GoF のコンポジットパターンのような、同型のオブジェクトが入れ子になるような階層構造なんかも、マトリョーシカ的な玩具以外に現実世界ではまずありえなくて不自然。そもそも、ほとんどの人は深い階層構造を辿るような移動、探索、切替を現実世界で体験したことがない、とかね。

●ペルソナへの適応

連れていくべき場所、ユーザーが見つけなくてはならないオブジェクト、ツール、データを減らす、というか、そのうちでも、普段から意識しておくべきものを極力減らしておこう。

簡単に言えば、いつもそばにあるものと、深いところに隠しておくものとに仕分けること。仕分けの基準は、

・使用頻度
・労力と報酬の見合い
・転位の度合い（その操作によってデザイン対象の状態がどれほど大きく変化するか？）
・危険度（失敗した場合の取り返しのつかなさ）

となるんですが、いずれも、ペルソナの性質、ニーズ、ペルソナが活動するコンテクストに深い関わりを持ちます。言い換えれば、ペルソナに合わせてインタラクションを整理してみようってことです。

よく使うものは当然、いつもそばに置いておきたいですよね。注意したいのは、深いところに隠しておくもの。これには、深いところに隠して"おいても"いいものと、隠して"おいたほうが"いいものと二種類ある。

労力と報酬の見合いがとれ、（かつ、それほど頻繁に使わないものなら、）深いところに隠して"おいても"いい。

転位の度合いや危険度が高いものについては、一般に、深いところに隠して"おいたほうが"いい。とかね。

こうして、実際にはその数を減らすことはできなくても、なるべく、なるべく、ナビゲーションのやつらにユーザーの心を奪われないように気をつけて、ユーザーの心に占める純インタラクションの割り合いをもっと上げていこうよ、ということですね。

純インタラクション --- そう、今夜は特別に、My Sweet Soul Interaction って呼ぼう。My Sweet Little Interaction のほうがいいかな？

ツールのニーズ

About Face 3 読書ノートの 21。

「ゴールの達成には直接的には貢献しないが、それをしなければゴールを達成できない」ような作業を About Face 3 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。

PCでいえば、まず、ソフトウェアをインストールしなくちゃいけない、ネットワークの設定をしなくちゃいけない、OSが拡張デバイスをうまく認識するように設定してあげなくちゃいけない、ファイルのバックアップのことを心配しなくちゃいけない、とっちらかったフォルダを漁って目的のファイルやアプリケーションを探し出さなくちゃいけない、ウィンドウの位置やサイズがしっくりくるようにいちいち調整しなくちゃいけない、初心者向けのおせっかいなヒントを一撃必殺の早業で消したり、いつまでもご親切なウィザードにつき合わされなくちゃいけない、煩雑な画面から必要な情報を、過剰な装飾の中から操作可能な領域を発見しなくちゃいけない、ナントカデスクだのナントカタウンだの、回りくどい喩えと機能の対応を推し量らなくちゃいけない、今、目の前に表示されている登録済みのメールアドレスを変更するために、わざわざ特別な画面に出向いて行かなくちゃいけない、理不尽であるか、あるいは取るに足りないささいな事柄に関する警告に悩まされ、挙げ句の果てに、さもこちらに落ち度があるかのように扱われる屈辱に耐えなくちゃいけない、って、いっきにまくし立ててみましたが、これみんな間接税的な作業の具体例として、About Face 3 が告発していることです。

そして言います。こういうの全部、いってみりゃアンチゴールダイレクテッドなインタラクションでしょ、できることなら根こそぎ取り除きたいよね。それが無理なら、せめてできるだけ目立たないように、できるだけの手を打ちたい。そのためにはまず、こういうことに意識的に、そして、敏感にならなきゃだめだよね、と。

なにかにつけ、そんなことがめんどくせえようなら死んじまえ、が口癖だった父に恐々としながら育ったぼくは、だから、生来、インタラクションデザインには実は不向きなのではないかとも思うのですが、ま、しかし、生まれつきや三つ子の魂だけでやっていける人生なんてないわけですから、ここはひとつがんばって、年齢不問で成長していきたいです。

さて、そう思って、間接税的な作業について取り上げているChapterを何度も繰り返し読んでいると、こうした間接税的な作業を生む温床には次のようなものがあることが自ずと腑に落ちてきます。

ひとつ、ユーザーの習熟度の多様性を無視すること
（中上級者をいつまでも初心者扱いするとか）

ひとつ、ポスチュアのあり方に無頓着であること
（本来、支配者的なポスチュアであるべきなのに、単発的なポスチュアをとってしまうとか）

ひとつ、蓋然性より可能性を重視すること
（ほとんど起こらないことに備えて、普段の作業をぎこちないものにしたり）

ひとつ、フェイルセーフではなく、フールプルーフで対応しようとすること
（やり直しがきくようにできないものだから、失敗ゼロを目指して作業をがんじがらめにしたり）

ひとつ、実装モデルを押しつけること
（入力と出力はつねに別系統とか）

ひとつ、単にさぼること
（機械でできるはずの推論と記憶を放棄してすましているとか）

しかしこれ、間接税的、と表現するのはどうなんでしょうね。About Face 3 が念頭に置いているのは消費税的なものみたいですけど。いや、わかりますよ。商品の対価に交換価値、使用価値以上の部分がふくまれているかんじ。でも、税メタファーじゃ、売り手（ツール）、買い手（ユーザー）とは別に、上前をはねてるやつが他にいそうな雰囲気じゃないですか。しかし、ここで悪いやつだとつるし上げたいのは、政府みたいなものじゃなくて、目の前でいけしゃあしゃあと不当に値をつり上げてる店のおやじのほうなんですよね。

一方で、このChapterに「ツールのニーズ」という言葉が出てくるんですけど、こっちのほうが、この問題を言い表すのにふさわしいような気がしました。ユーザーのニーズじゃなくて、ツールのニーズ。

ニーズって、あらためて言うまでもないことですけど、要するに、ゴールに達っするために何かを必要とすることですよね。ゴールに自足的に達することができないとき、不足分を補う何かを他に求めること。

何か思い定めたゴールがあるとして、しかし徒手空拳ではかなわないので、人は何か道具を探す。自足的にゴールを達成できないので、道具に対するニーズが生じる。一方で、道具のほうでも、実はそれ自体としてあるゴールを持っている。それは、つまり、ユーザーのゴール達成を支援することですね。だからこそ道具は道具としてありえるわけですけど、そのゴールを自足的に達成できないとき（間接税的な作業を生む温床）、道具にもニーズが生じてしまう。つまり、道具のほうが、今度はユーザーを道具として使おうとするわけです。これが間接税的な作業の正体。

しかも、それをうまいこと、ユーザー自身の発意による、ユーザー自身のゴールに向かうための仕事であるように見せかけるんですよね。質が悪い。案外、インタラクションデザインって、この倒錯を巧妙にカモフラージュするテクニックとして発達してきた部分も少なからずあるんじゃないでしょうか。

だから、冒頭でまくしたてたようなことに対する感性を研ぎ澄まして、目ざとく告発できるようになったあかつきには、「それって、ツールのニーズでしょ？」というセリフで決めてみたいです。ぼくは。

-----------------
sent from W-ZERO3

みんなのフロー状態を大切にしましょう

About Face 3 読書ノートの 20。

なんか作業にだーっと夢中になっちゃって、気がついたら、うわ、もうこんな時間かよ！？ハラヘッター、みたいなことがあるだろう。そういうのをフロー状態っていうんだよ。と娘に話したら、ああ、ウラシマ効果？と返されました。いや、そのフロウじゃねえよ、って。しかし、まあ、でも、うん。そうだったらどんなにいいだろうね。だけど時間ってやつは誰の身の上にもじつに公平に流れては去っていくものなんだよ。娘よ。

だからこそ、フロー状態ってのは実にかけがえのない大切なひとときなわけで、いろいろごちゃごちゃいっとりますが、インタラクションデザインの要諦はつまり、いかにして人をフロー状態に導くことができるか、そして、いったん始まったフロー状態を途切れることなく全うさせることができるかにかかっているといってもいいわけですね。

そうしたインタラクションデザインの到達点を、About Face 3 は、オーケストレーションと表現しています。

といっても、なにも美しいプレイで人々を魅了しろっていうんじゃない。そうじゃなくて、ユーザーとのコミュニケーションがオーケストレーションになってなきゃだめ、つまり、全体的に調和のとれたものになってなきゃだめだよ、ってことなんです。

例によってそうするための原則がずらっと並んでいるのですが、かいつまんでいうと、複雑なものをうまくバランスして調和をとっていくっていうより、要するに必要以上に出しゃばるな、そうすりゃ自然に調和もとれるさ、ってかんじです。

たぶんね、ロールモデルは高倉健ですよ。これ。いわく、

「いかに優れたものでも、インターフェイスは少ない方がよい」
「オーケストレーションされたユーザーインターフェースは透明である」

しぶいですね。しびれますね。不器用なのはまずいかも知れませんが、美しい魅惑のプレイなんてのは真逆の話ですね。

もうすこし具体的な水準で、16個、原則が挙げられているんですが、読み込んでいくと、言いたいことは結局、次の４つのポイントに収斂していくようです。

・なるべく直接操作で
・なるべくモードレスに
・なるべく蓋然性に合わせて
・なるべく固まらないように

そうすると、必要以上に出しゃばらずに済む。それぞれどんなかんじかというと　... 。

■ なるべく直接操作で

インタラクションというと、双方向の対話的インターフェースってかんじがしますけれども、けっしてそうじゃないよと。

「理想のインタラクションは対話のようなものではなく、むしろ道具を使うのに似ている。大工が釘を打つときに、釘についての議論をハンマーとしたりはしない。ハンマーで釘を打つのだ。」

やりたいことをいちいち問い質されながらフロー状態に入れる人なんてそうそういないでしょう。

だから、初心者でなくなった後でも強要されるウィザード形式には閉口しますし、いちいち開くのが面倒な設定画面でしか目の前のオブジェクトを操作できないようなインターフェースでは仕事になりません。メニューを辿るという行為も、やりたいことをいちいち問い質されているようなもんですからね。

煩わしいし、なにより腹が立つ。May I help you? は、低姿勢なようでも実は上から目線なんですよね。おれはお前を使うことはあっても、助けてもらうつもりは毛頭ないってなもんです。ちなみに、About Face　3　は全編を通じて特にこの点に手厳しいんです。一体何があったんだとそれこそ問い質したくなるくらい。相当ご立腹の様子です。

■ なるべくモードレスに

人のせっかくのフロー状態を阻害するものの親分が、かの悪名高い「モード」ってやつなのかも知れませんね。

モードってのは、ひらたくいうと、アプリケーションがあるひとまとまりのタスクの遂行だけに特化した状態に入ることです。それはインタラクションをシンプルに見せかけたり、一連のインタラクションを通じたシステムやデータの一貫性を保つために、まあ、よかれと思って仕組まれてるわけですが、でも、その副作用がなかなか見過ごせない。

というのも、モードの中でタスクを遂行すること自体は立派にゴールダイレクテッドでも、あるモードの中に入ること、そこから出ること、他のモードに入ること、目下のモードが何であるか確認すること、こういったことは、ゴールの達成に直接貢献するわけではないんですね。

いってみりゃ、モードに頼ってゴールを目指す以上は、どうしても支払わなければならないコスト。入場料、通行料、税金みたいなもの。しかし、これらがやけに目だってきちゃうと、そりゃもう、本来の目的からは逸れているわけですからバンバン意識を寸断しちゃって、とてもフローどころではない騒ぎになります。

ぼくの理解では、16個の原則のうち7個は、このモード関連ですね。これらを読み込んでいくと、About Face 3 は、モードが発生しそうな箇所として暗に次の3つを念頭に置いているようです。

・オブジェクトの状態やプロパティを確認するとき
・ツールを切り替えるとき
・タスクの遂行結果のフィードバックを受け取るとき

オブジェクトのプロパティや状態の確認については、とにかくできるだけその場で、つまりモードのない状態で確認できるようにしたい。その場で確認しきれずモードに頼る場合でも、やっぱりできるだけ手近なところで。つまり、そうするために何段階もメニューを辿らなければいけないようなハメにユーザーを陥れないようにとアドバイスしています。

ツールの切り替えについては、もうこれはモードに頼るのもやむなし。しかし、やっぱりこれもできるだけ手近なところで、ですね。「机から立って廊下に鉛筆を探しに行くような」ことがないようにしたい。それから、繰り返しになりますが、ツールはあくまでも直接操作をモットーに。ツールを使うことの実態が質問攻めであるようなことはあってはならない。あと、使い終わったツールをユーザーに片付けさせるような真似もしちゃいけない。

フィードバックについては、とにかくモーダルなダイアログボックスの使用を極力控えよと、これに尽きます。タスクってのは、ツールによってオブジェクトに何かしら働きかけるってことなんですから、その結果は、オブジェクトのプロパティや状態の確認として、モードレスに察知できるのが一番。

ところで、インタラクションにおけるモードとモードレスに関しては、こちらに深い考察があります。

Modeless and Modal
http://modelessandmodal.wordpress.com/

結構なペースで日々更新されているんですが、これはぜひ、ドアタマから一読されることをオススメします。ぼくは大変お世話になっています。これを読んでなかったら、About Face 3 のこの章、「オーケストレーションとフロー」のところなんて、ちゃんと読み込めなかったかも知れません。

■ なるべく蓋然性に合わせて

蓋然性と可能性の混同はよくいわれますけれども。可能性はありえるかありえないか、蓋然性はありえることが実際に起こる確率が高いか低いかですね。

About Face 3 は、UMLのユースケース図って、各ユースケースが発生しうる確率を無視して、すべて同格で記述してしまうので、開発領域を明示することには向いていても、ユーザーをゴールへダイレクトに導くためのインタラクションをデザインするためのツールとしては向いていないとかいってますね。

一方で、コンテクストシナリオなら、ごく自然に発生しうる確率が高いユースケースに重点を置いて検討することができると。インタラクションデザインにおいては、蓋然性と可能性の混同は致命的だといわんばかりです。

蓋然性がらみで About Face 3 によく出てくる例は、何時間もかけて書いたドキュメントについて「保存しますか」とか聞くな！ってやつ。この状況で「保存しない」を選ぶようなやつがいる可能性はそりゃあるよ、でも、蓋然性はほとんんどないだろ？毎回そういうことを馬鹿正直に尋ねるんじゃないお前は、という話です。

こうした、ほとんど蓋然性のない状況に関わる質問やメニューもまた、ユーザーのフロー状態の邪魔になるんですね。必要になったらこっちから相談するから、それまで黙っててよ、ってかんじです。

また、About Face 3 は、印刷することを指示すると、毎回毎回、プリンタの設定を尋ねてくるのもいかがなものか、なんてことも言っています。プリンタの設定なんて一回したらそうそう変更するもんじゃないでしょ。と。コマンドを使用する蓋然性は高くても、コマンドのコンフィギュレーションを行う蓋然性は低い。もしそうなら両者は分離しておくべきじゃないか、とかね。

あと、非常ボタンの類、パイロットの脱出ボタンとか。これを使うことなんてめったにないんだから、また、うかつに触ると危ないんだから、FMラジオのスイッチとキャビンライトのスイッチの間に配置するなんてことは絶対やめてくれ、なんてね。

実は、今、これ、マンガ喫茶で描いてるんですけど、キーボードにPCの本体の電源を落とすボタンがついてて、それが普段会社で使っているキーボードだとDeleteボタンの位置にあるんですよ。さっきから書き損じを削除するつもりでPCを2回も落としちゃいました。しかも、確認画面は一切なしで、あれよあれよと。そこは、ほんとに落とすのかどうか聞いてくれよ頼むから！

まあ、そういうことです。

逆に蓋然性の高い状況に関する配慮はウェルカム。たとえば、操作履歴に基づいて、よく使うツールをより目立つところに置くとかね。

■ なるべく固まらないように

最後のこれはもう、言うまでもありませんね。上述の原則をきっちり守っても、何かする度にいちいち待たされたんじゃあフローもへったくれもない。仮に待たせるようなことになったら、そういう状態にこれから入ることをユーザーに正直に打ち明けて、ちゃんとキャンセルもできるようにしておくこと。

待ってもらえるならどれくらい待たせるかを明らかにして、だいぶ待たせることになるなら、ユーザーがその間どうか他のことでフロー状態に入ってくれるように祈ること。

ま、そんなところです。

また間違ってPCの電源を落としちゃわないうちに、今日はこのへんにしときます。