About Face 3 読書ノートの 27。
ここにきて About Face 3 の本当の構成がやっとつかめてきました。
まずなんだかんだ、インタラクションデザインの原則に関するほとんど宗教的と言ってもいいくらいの荘厳な教えと戒めがあってですね(語り口はじつに伝法なもんなんですが)、じゃあ、その教えにしたがってこの世の闇を払うには？ってことで、ふたつのありがたいメソッドを授けて下さる。福音ですね。その一方が、例のゴールダイレクテッドデザインで、もう一方が、イディオマティックデザインです。
Idiomatic Design イディオマティックデザイン。聞き慣れませんね。この一連の読書ノートでも始めて書きつける言葉です。ASCII版の About Face 3 では「イディオム的デザイン」という訳になってますけども、かたっぽをゴールダイレクテッドデザインで通すなら、こっちも対称性を重視して「イディオマティックデザイン」でいくべきでしょう。
実際にはそういう順番で本書が書かれているわけではないし、ボリューム的にも、そんなふうにきれいな二等辺三角形を描くようなバランスでもないんですが、しかし、論理的な構造としてはそうなってると思うんです。このイディオマティックデザインってやつの有り難味を見過ごしてるとですね、この分厚い本、割と尻つぼみな感じがすると思いますよ。じつはぼく、ずっとしてました。
で、そのイディオムってやつのすばらしさを際立たせるために About Face 3 がぶつけてきた噛ませ犬が、前とそのまた前のエントリーで取り上げたメタファーってわけですね。メタファーっていえば、なんとなく GUI の立役者みたいに思われているけれども、それは買い被りだって告発したわけです。それどころか、「皮肉にも、一般にメタファーと考えられているGUI要素の多くは、実際にはイディオムである。」なんてことも言ってます。
では、そのイディオムって一体どんなもんなんでしょう。イディオマティックにデザインするってことは、具体的にはどういうことなんでしょう？
イディオムって、まあ、普通に日本語に置き換えれば慣用句ってことですね。About Face 3 の中にも、いくつか英語の慣用句が紹介されています。
beat atound the bush 回りくどい
cool かっこいい
Uncle Joe kicked the bucket ジョーおじさんが死んだ
とかね。
でも、なにも歴史と伝統のある表現に従うのが一番、なんて、デザインの保守主義を説こうってわけじゃないんですよ。一瞬、そうなのかなって思いますけれども。About Face 3 が、イディオムという言葉を使うのは、すでに広く受け入れられた表現方法を積極的に使っていこうってことじゃなくて、慣用句というものの成り立ちと働き方に着目してのことなんです。そこに、インタラクションデザインが学ぶべき特性があるぞ、と。
まずは成り立ちの話。これは、イディオムっていうより、イディオムも含む言語全般の特性というべきものですけれども、注目したいのは、文字や音節が組み合わさって詞となり、その詞が組み合わさって句や文になり、さらにその文が組み合わさって自由な表現となる、といった構造。そう多くもない要素と、そう複雑でもない規則を使って、要素の総和以上の価値を無限に産み出すことができる階層的なモジュールシステムとしての側面ですね。
このアナロジーでインラクションを省みていくとですね、まず、文字や音節に当たるのは、クリック、ドラッグ、キー押下などの入力アクションということになりますね。あるいは、テキストだとかカーソルなどの表示要素。インタラクションにおいてはこれ以上分割できない最小単位ってことで、About Face 3 ではこのレベルの要素を「プリミティブ」と呼んでいます。
次に、文字や音節が連なってできる詞に当たるのが「複合要素」。クリックというアクションを立て続けに実行してダブルクリックとかね。ボタンをポイントしてクリックするとボタンクリック。表示のほうでも、カーソルとテキストを含むテキストボックスや複数の状態を持ちうるチェックボックスなんかはこのレベルの要素です。
そして詞が連なって句や文となるように、「複合要素」がさらに組み合わさって、ユーザーがゴールを達成するためのインターフェースになっていくわけです。これが About Face 3 の言う「イディオム」のレベルですね。たとえば、マウスでオブジェクトをポイントして、右クリックでコンテクストメニューを表示し、そこから削除コマンドを選択して実行する ... といった一連の操作なんかがそうです。
この構造、本の中ではわかりすい逆三角形の図で示されています。同じものが下記のURLに引用されていました。
YAHOO! USER INTERFACE BLOG
Developing a JavaScript Library for Yahoo!
http://www.yuiblog.com/blog/2006/02/17/developing-a-javascript-library-for-yahoo/
はい。こんなかんじでインタラクションのメカニズムを捉え直してですね、言語のような自由なコミュニケーションシステムとしてインタラクションをデザインしてみようって、まあ、そういう寸法です。
ただ、その伝でいくと、じゃあコマンドラインインターフェース/CUIのほうが言語的でいいんじゃない？ってことになりそうです。しかしそれはあまりにも性急な議論というもので、不用意に自然言語に近づいていったら、それこそ習得が難しくなるよ、と。だって、
「インタラクションの語彙に含まれる原子的要素が多いほど、学習プロセスも時間がかかり難しいものになる」のが道理ですから。
プリミティブは減っても、組み合わせ方の工夫次第で、ちっとも表現力が落ちないのが、こうした階層的なモジュールシステムの強みで、GUIはその性質を最大限に活用することをアテにして産み出されたもんだといってもいいくらいなんですね。
About Face 3 によれば、「初めて発明されたときのGUIは明らかに優れていたので、多くの業界ウォッチャーがインターフェースのグラフィカルな性質に成功の原因を求めていた。これは自然な考えだが間違っていた。オリジナルのMacのような最初のGUIが優れていたのは、インターフェースがグラフィカルなために、ユーザーがシステムとインタラクションするための語彙を非常に制限しなければならなかったことにある」そうです。
さて、あともうひとつ、慣用句の働き方に関する着目のほう。慣用句って、たいてい字義通りの意味を超えた意味を帯びて流通するんですよね。Uncle Joe kicked the bucket で「ジョーおじさんが死んだ」みたいに。どうしてそんなことになるのか？は、わかりません。About Face 3 はそこには関心を払わない。ただ、どうしてそんなことが可能なのか？ってところにひっかかる。
Uncle Joe kicked the bucket の例でもわかるように、慣用句の表現と意味の結びつきは、たんなる規則にすぎない。その結びつきに必然性なんかないわけです。だから、「直観ではわからないし、どうしてそうなったのか、理由を説明することもできない。前後のコンテキストから学ぶか、意識的に教えられることがなければ、意味はわからない。」
でも人間はそういう慣用句を苦もなく学んで、すぐに使いこなすことができる。
「人間の頭脳は大量のイディオムを早く簡単に学習してしまえる驚異的な能力を持っている。ほとんどのイディオムは比喩的な意味をまったく持たず、イディオムの元になった話は大昔に失われているので、この能力がなければイディオムは生き残れない。」
そういう人間たちにインタラクションを提供するのに、当てずっぽうの直観に頼るしかない隠喩的な表現を使う理由がどこにあるのでしょう？ もっと、人間の可能性を信じようじゃないか。って、ここが、About Face 3 の全編を貫く人間中心主義の面目躍如、一番の見せ場だったんですよね。人間の知性への絶対の信頼。「ホモ・サピエンスは本当は頭がいいんです！」と叫ぶアラン・クーパー。
いずれにしても、これがトドメ、ダメ押しですよね。規則さえあれば、字義も気にせずなんだってできるということですから。
そして About Face 3 のここから先、いよいよ最後の Part3 に入るわけですけど、要するに具体的なイディオムの使い方指南なんですよね。検索、アンドゥ、保存、入力、選択、ウィンドウ、各種のコントロール部品、メニュー、ツールバー、ダイアログ、エラー、警告、確認 ... といったイディオムの数々。ここも言語アナロジーにのっていえば、"文章読本"みたいなかんじですね。そう思ってもうしばらく読み進めてみることにします。
2010年4月8日木曜日
2010年2月26日金曜日
アンデッドメタファー
About Face 3 読書ノートの 26 。
イディオム中心デザインの話にいく前に、もう少しメタファーのことを。というのも、前のノートを書いてて、正直、クーパー言い過ぎじゃないかなと思わないでもなかったんですよね。そんなにメタファーって、だめだったっけって。
ちらちら頭をかすめるのは、eXtreme Programming のプラクティスのひとつ、「適切なメタファー」のことでした。これから作るものについてのイメージを、グッとくるようなメタファーを使ってチームのみんなで共有しておこうというやつですね。
About Face 3 では、実装中心デザインを推進する憐れむべき人々みたいなかんじでしか描かれませんが、プロジェクトの最初期、まだ何を作るのか雲をつかむような段階では、開発者だってまるで日の浅いユーザーとおなじようにシステムに関するメンタルモデルを作るのに苦労するもんなんですよね。そんなとき、メタファーが果たしてくれる役割ってなかなか馬鹿にしたもんじゃないと思うんです。
でも、メタファー中心デザインの功罪の罪のほうを明らかにしつつ、イディオム中心デザインの効用を説いていくアラン・クーパーと About Face 3 のみなさんのお手並みはやっぱり鮮かだなあとも思うんですよね。
で、悶々と考えてみたところ、インタラクションデザインにおけるメタファーの使いどころにはどうも３つくらいの水準があって、クーパーはその全てに否定的になっているわけじゃないんじゃないかなってだんだん思えてきたんです。
一口にメタファーなんつっても、これはちゃんと分けてかんがえないとって。なんでもそうだけど、悶々としちゃうのは、いろいろごっちゃにしちゃうからなんですよね。
というわけで、ばっさり分けてみました。
(1) 利用価値に関するメタファー
かんたんに言えば、一体これは何？何の役に立つの？という問いに答えるメタファーですね。
これは〜のようで、あるいは〜みたいで、そのくせ〜に似てて、そうかと思うと〜風なところもあって、いわば〜でって、一生懸命何かに喩えて理解しようとすること。
それは、仮に目に見えるインターフェースから一切のビジュアルメタファーを排除しても、その働きを捉えるイメージとしてユーザーの心に生まれるし、また、残っていくもんじゃないでしょうか。
eXtreme Programmingでいうメタファーもこれでしょう。
この水準のメタファーは、今ノートをつけている Part 2 Chapter 13 「メタファー、イディオム、アフォーダンス」で取り上げられているやつとはちょっと違いますよね。むしろ、Part 1 で説かれるゴールダイレクテッドデザインと密接に関わるもんでしょう。
今ノートをつけているのは、
(2) 操作手順に関するメタファー
こっちです。端的に言えば、どう使えばいいのか？という問に答えるメタファーですね。
ユーザーが直感的に操作できるようにするための便宜として考えられたなんらかの視覚的な表現を伴うメタファー。フロッピーで保存、ゴミ箱で削除ってね。
クーパーはこれを取り上げて、インタラクションの学習を効率化するための手口としては不確かだって言ってるんですよね。この水準では、誰がどう勘違いするかもわからないようなメタファーに頼るより、その気になれば誰でもかんたんに学習できるような、シンプルで一貫性のあるイディオムを中心にインタラクションを考えたほうがいいよって。
なぜなら ... それは、前のノートにさんざん書き散らかした通りです。
じゃあ、そのイディオムってのはいったいどんなもんなんだって話に自然になっていくわけですけれども、それはまた今度ってことで。ただ、先にひとつだけ言っておくと、イディオムがまたこれ、別の水準のメタファーに大きく依存するんですよね。
それが、次のやつで。
(3) 入力方法に関するメタファー
たとえばクリッカブル、ドラッガブルであることを示唆するために物理的な形状や運動モデルのメタファーが使われますね。あるいは、選択や移動のために方向、内外、重なりなどの空間認知的なメタファーが使われます。もう、ぼくらには当たり前過ぎてそれがメタファーだなんて考えづらいくらいですけどね。
でもこういうのみんな、物理的な世界で慣れ親しんでいるモノの扱い方、つかめそうだからつかみ、つまめそうだからつまむ、いわゆるノーマンのアフォーダンスの喩えなわけです。
クーパーは、こうしたデジタルメディア上のアフォーダンスの有用性を十分認めつつ(それらはイディオムの基礎にもなります)、しかし、それはあくまでも仮想的なものなので、現実のアフォーダンスと違ってかんたんにユーザーを裏切ることもできちゃうから、せいぜいみんな気をつけようぜ、なんて言ってます。
以上です。
と、まあ、やっとこれでね、自分的には心置きなくイディオムに進める準備が整いましたって感じです。
ところで、イディオムってつまり慣用句ってことですけど、慣用化した比喩のことを死喩っていうんですよね。デッドメタファーです。喩え喩えられる関係が持っていた豊かさはみんな擦り切れちゃって、もう本来の意味なんてどうでもよく、たとえば、いまや誰も知らない骨董的な記憶媒体のイメージがファイル保存の記号として生きのびていくような死喩の旅。
でもね、すべてのメタファーがそうしてイディオム化していくわけでもないのです。きっと。
イディオム中心デザインの話にいく前に、もう少しメタファーのことを。というのも、前のノートを書いてて、正直、クーパー言い過ぎじゃないかなと思わないでもなかったんですよね。そんなにメタファーって、だめだったっけって。
ちらちら頭をかすめるのは、eXtreme Programming のプラクティスのひとつ、「適切なメタファー」のことでした。これから作るものについてのイメージを、グッとくるようなメタファーを使ってチームのみんなで共有しておこうというやつですね。
About Face 3 では、実装中心デザインを推進する憐れむべき人々みたいなかんじでしか描かれませんが、プロジェクトの最初期、まだ何を作るのか雲をつかむような段階では、開発者だってまるで日の浅いユーザーとおなじようにシステムに関するメンタルモデルを作るのに苦労するもんなんですよね。そんなとき、メタファーが果たしてくれる役割ってなかなか馬鹿にしたもんじゃないと思うんです。
でも、メタファー中心デザインの功罪の罪のほうを明らかにしつつ、イディオム中心デザインの効用を説いていくアラン・クーパーと About Face 3 のみなさんのお手並みはやっぱり鮮かだなあとも思うんですよね。
で、悶々と考えてみたところ、インタラクションデザインにおけるメタファーの使いどころにはどうも３つくらいの水準があって、クーパーはその全てに否定的になっているわけじゃないんじゃないかなってだんだん思えてきたんです。
一口にメタファーなんつっても、これはちゃんと分けてかんがえないとって。なんでもそうだけど、悶々としちゃうのは、いろいろごっちゃにしちゃうからなんですよね。
というわけで、ばっさり分けてみました。
(1) 利用価値に関するメタファー
かんたんに言えば、一体これは何？何の役に立つの？という問いに答えるメタファーですね。
これは〜のようで、あるいは〜みたいで、そのくせ〜に似てて、そうかと思うと〜風なところもあって、いわば〜でって、一生懸命何かに喩えて理解しようとすること。
それは、仮に目に見えるインターフェースから一切のビジュアルメタファーを排除しても、その働きを捉えるイメージとしてユーザーの心に生まれるし、また、残っていくもんじゃないでしょうか。
eXtreme Programmingでいうメタファーもこれでしょう。
この水準のメタファーは、今ノートをつけている Part 2 Chapter 13 「メタファー、イディオム、アフォーダンス」で取り上げられているやつとはちょっと違いますよね。むしろ、Part 1 で説かれるゴールダイレクテッドデザインと密接に関わるもんでしょう。
今ノートをつけているのは、
(2) 操作手順に関するメタファー
こっちです。端的に言えば、どう使えばいいのか？という問に答えるメタファーですね。
ユーザーが直感的に操作できるようにするための便宜として考えられたなんらかの視覚的な表現を伴うメタファー。フロッピーで保存、ゴミ箱で削除ってね。
クーパーはこれを取り上げて、インタラクションの学習を効率化するための手口としては不確かだって言ってるんですよね。この水準では、誰がどう勘違いするかもわからないようなメタファーに頼るより、その気になれば誰でもかんたんに学習できるような、シンプルで一貫性のあるイディオムを中心にインタラクションを考えたほうがいいよって。
なぜなら ... それは、前のノートにさんざん書き散らかした通りです。
じゃあ、そのイディオムってのはいったいどんなもんなんだって話に自然になっていくわけですけれども、それはまた今度ってことで。ただ、先にひとつだけ言っておくと、イディオムがまたこれ、別の水準のメタファーに大きく依存するんですよね。
それが、次のやつで。
(3) 入力方法に関するメタファー
たとえばクリッカブル、ドラッガブルであることを示唆するために物理的な形状や運動モデルのメタファーが使われますね。あるいは、選択や移動のために方向、内外、重なりなどの空間認知的なメタファーが使われます。もう、ぼくらには当たり前過ぎてそれがメタファーだなんて考えづらいくらいですけどね。
でもこういうのみんな、物理的な世界で慣れ親しんでいるモノの扱い方、つかめそうだからつかみ、つまめそうだからつまむ、いわゆるノーマンのアフォーダンスの喩えなわけです。
クーパーは、こうしたデジタルメディア上のアフォーダンスの有用性を十分認めつつ(それらはイディオムの基礎にもなります)、しかし、それはあくまでも仮想的なものなので、現実のアフォーダンスと違ってかんたんにユーザーを裏切ることもできちゃうから、せいぜいみんな気をつけようぜ、なんて言ってます。
以上です。
と、まあ、やっとこれでね、自分的には心置きなくイディオムに進める準備が整いましたって感じです。
ところで、イディオムってつまり慣用句ってことですけど、慣用化した比喩のことを死喩っていうんですよね。デッドメタファーです。喩え喩えられる関係が持っていた豊かさはみんな擦り切れちゃって、もう本来の意味なんてどうでもよく、たとえば、いまや誰も知らない骨董的な記憶媒体のイメージがファイル保存の記号として生きのびていくような死喩の旅。
でもね、すべてのメタファーがそうしてイディオム化していくわけでもないのです。きっと。
2010年2月16日火曜日
BlogPressLite
ひとつ前のエントリーは、この間手に入れたばっかりの iPhone でほとんど書きました。ほとんどっていうのは、iPhone / Evernote でとりあえず一気に書いておいたのを、Evernote 経由でデータを融通しつつ、ヒマをみながら PC と iPhone の両方でちょこちょこ手を入れてたので。
さっき、食事で外に出たときにようやく出来上がったので、あとは Evernote のメール送信機能で更新用のメールアドレスに送るだけって思ったんですが、Evernote の送信画面の様子だと、どうもHTML でマークアップされちゃいそうなんですね。それじゃあって、メーラーにコピペして送ってみたんだけど、メーラー上ではそうは見えなかったのにやっぱり HTML データが送られちゃって、見た目がじつにへんてこなことに。
あわてて Safari を起動して Blogger にアクセスして編集しようと思ったんだけど、 なんだか知らないけど textarea にスクロールバーが表示されなくて編集できない。ちーっ！
いくらフリックでちょっと長めのテキストを打てるようになっても、これじゃあだめだ、どうしよう？ってところで、さっき、このアプリの存在を知りました。
BlogPressLite
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=329890643&mt=8
というわけで、テスト投稿です。
投稿後、誤字が見つかったのでアプリ経由で修正しました。
これはいい！！
だけど、自動保存がないのでこれに直に書くのはやめたほうがいいみたい。いま、二時間分くらいのテキストが煙のように消えた。バッテリーが切れそうになったので電源につないだとたんのことだった。(2010/2/19 追記)
そこで、安心便利で強力な下書き環境としての Draft Pad !
http://itunes.apple.com/app/draftpad/id358067114?mt=8
これで完璧。(2010/3/1 追記)
さっき、食事で外に出たときにようやく出来上がったので、あとは Evernote のメール送信機能で更新用のメールアドレスに送るだけって思ったんですが、Evernote の送信画面の様子だと、どうもHTML でマークアップされちゃいそうなんですね。それじゃあって、メーラーにコピペして送ってみたんだけど、メーラー上ではそうは見えなかったのにやっぱり HTML データが送られちゃって、見た目がじつにへんてこなことに。
あわてて Safari を起動して Blogger にアクセスして編集しようと思ったんだけど、 なんだか知らないけど textarea にスクロールバーが表示されなくて編集できない。ちーっ！
いくらフリックでちょっと長めのテキストを打てるようになっても、これじゃあだめだ、どうしよう？ってところで、さっき、このアプリの存在を知りました。
BlogPressLite
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=329890643&mt=8
というわけで、テスト投稿です。
投稿後、誤字が見つかったのでアプリ経由で修正しました。
これはいい！！
だけど、自動保存がないのでこれに直に書くのはやめたほうがいいみたい。いま、二時間分くらいのテキストが煙のように消えた。バッテリーが切れそうになったので電源につないだとたんのことだった。(2010/2/19 追記)
そこで、安心便利で強力な下書き環境としての Draft Pad !
http://itunes.apple.com/app/draftpad/id358067114?mt=8
これで完璧。(2010/3/1 追記)
不確かなメタファー
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 のみなさん、回を重ねるごとにますます意気軒昂ってわけで、今度の標的はメタファーかぶれのデザイナーなのです。
なんか、正しいメタファーを見つけることが仕事だなんて思ってるヒトたちっていますね。バカデスネ。なんて調子で、今回は、ちょっと冷笑的な態度で始まります。
そりゃ、ユーザーに内部の仕組みまで学ばせるような実装丸出しデザインよりはだいぶマシ。ただどうも、インタラクションデザインにおいてメタファーは過大評価されすぎているんじゃないかって。
うまいメタファーがあれば直感的に使えるようになるというけれども、冷静に考えてみて、インターフェースの学習を効率化する上でメタファーが果たす役割って案外ほんのちょっとじゃない？その割に、じつは弊害の方が結構多くって、あんまり利口なやり方じゃないと思うなあ、なんて言ってます。
たとえば、いまだによく見かけるフロッピーのアイコン。あれ、「保存する」ことを表現するメタファーってわけだけど、しかし今時フロッピーなんて、ねえ？若い子はもうそんなの見たことないだろうし、扱ってるファイルの容量からしても現実に見合わなかったり。下手したら保存先なんてネットワークの彼方かもしれないのに。
だから、作業結果を保存したい時はこれをクリックするんだってことを学ぶのに、もはやあの絵柄はまるで役に立ってないでしょ。たぶん、ツールチップかなんかで機能との対応を確認してみんな済ませてるんじゃない？
今でもあの絵柄の意味するところにへんに拘ると、考え込んだ挙句、なにか別のことを期待しちゃうかも知れなくて、かえってインタラクションデザイン上よろしくない。じゃあ、フロッピーよりももっとふさわしいメタファーを他に探せったって、これが案外難しい。
フロッピー的な発想はそのままで、もっとモダンなものをっていうと、ハードディスク？だけど、フロッピーと違って滅多に手にするものじゃないから、みんなが一発でそれとわかるような絵柄を決めるのは難しそうだし。
じゃあ、保存先のメディアじゃなくって、もっと概念的な、そうそう、ファイルとかフォルダってのは？って、そんなのもう「新規作成」とか「ファイルを開く」で使われちゃってるし、そんなら、デスクトップ・メタファーからも離れて、保存する、永続化するってことを表すみんなにお馴染みのイメージを探せって、えー、そんなのあります？なんてことになっちゃう。
まあ、しかし、なんだかんだで、あの絵柄と機能の対応を学んだ後では、とりあえず、その意味するところはあまり深く考えず、たんに他と区別するための記号として役立ってもらえればいいかと、そんな付き合い方になるんだろうけど、そういうのはメタファーじゃなくて、修辞学的にはシンボルって言ったほうがいいんじゃないの。
シンボルはその形状に頼ってシンボライズされる何かを表象するわけじゃない。形状と表象される内容の結びつきは恣意的なもので、その結びつきはそれとして学ぶしかない。って、あれ？ メタファーを使うことの意味は、機能や目的を意識的に学ばずとも直感することじゃなかったっけ？
それに、フロッピーのメタファーなんて、それひとつだけとってみれば、非常にささやかなもんだから、シンボル的なものへの変わり身も早く済むだろうけど、こんなこと →
http://www.answers.com/topic/magic-cap になってたらどうする？シンボル的なものとして付き合うったって、あまりにも余りが多すぎるってなもんじゃない？
なんて、あのちっちゃいアイコンひとつつまみ上げて、軽くこんなかんじです。そういっぺんにいろいろ言われても、ぼくら、ただ圧倒されるだけでイヤハヤ、なんて心細くなってきますけれども ( だいぶ勝手に行間を読みまくった結果と言えばそれまでですが ) 、心配御無用、メタファーのなっとらんところを突き詰めると、だいたい次の四つのポイントにまとまるって話なんです。
クーパーは言います。( たぶん、両手を広げて肩をそびやかし、吐息まじりにノンノン言いいながら ... )
1) メタファーは足りない
いっとくけど、われわれの日常的な言葉づかいにメタファーは潤沢に溢れかえっているし、メタファーの効用はとてつもなく大きなものダヨ。About Face 3 に書いてあることなんてメタファーだらけだしネ。メタファーなしで同じ内容を人に伝えろって言われても困るヨ。
でも、インターフェースを学習するための方便としてはどうカナ？
アイテムの購入とか、リファレンスの検索、フォーマットの設定、写真解像度の変更、統計分析の実行 ... こういうアクションにぴったりのメタファーを探せって言われても、けっこうドンピシャのを見つけるのってムズカシくないデスカ？
あるいは、プロセスだとか、データやオブジェクト間の関係性だとか、なんらかの形式の変換だとか、いってみればコンピュータならではの物事って一体どんなメタファーで表現すればいいのカナ？
インタラクションデザインでいうメタファーって、たいてい、機能や目的を簡単な絵で表す、いわゆるビジュアルメタファーのことなのネ。
そうすると、当然、関係性だとか抽象的概念だとか、絵に書きにくいものは扱いにくいってことになるネ。で、わざわざコンピュータやらシステムやらを使って人間がやりたいことって、ケッコウそういうものが多いんダヨネ。
それにサ、そもそもワレワレがこれからデザインしようとしているモノは、三次元的な限界からも、機械化時代のパラダイムからも解き放たれた、人びとに力を与える全く新しいナニカなワケでショウ？
そういうモノを、そういうモノがなかった段階の物事で喩えようなんて、土台無理な話じゃナイ？
インターフェースデザインに使えるメタファーって、だからほんのチョットしかなくて当たり前なのヨ。
2) メタファーは通じないこともある
何が当たり前って、これこそホントに当たり前ッチャー当たり前の話ダケレドモ。同じ絵を見ても文化的背景が異なれば全く正反対の意味を読み取られてしまうこともないとはいえないよネ？
仮に文化的背景は共有していたとしてもダヨ、人それぞれの考え方、感じ方の違いってのはどうしても残るしネ。たとえば、デザイナーが飛行機の到着時刻をチェックするために用意したアイコンが、ユーザーには、飛行機のチケットを予約するためのアイコンに見えたりネ。
こんな不確かなものをインタラクションの基盤に据えようなんて、ネェ？ やっぱりヤバイと思うヨ。
3) メタファーは変化についてこれない
フロッピーのことで言った最初の問題、そして最大の問題はこれだネ。みんながよく知ってる現実世界の何かとシステムの機能や目的の照応関係が、いったんは上手く馴染んでも、システムの成長や進化に、コレマタ当たり前だけどその現実世界の何かの方はついてきてくれないのヨ。
言い換えれば、メタファーにはスケーラビリティがないってことなんだけどネ。
喩えにも使えるほどみんながよく知ってる事柄ってことは間違いなくそこには不変性があるんだよネ。一方、システムのほうはその本性としてどんどん進化しちゃうのネ。
だから、システムとメタファーの恋ははじめから叶わないサダメなの。カナシイネ。
4) メタファーはすぐに邪魔になる
インタラクションデザインにおけるメタファーの役割はサ、意識的な学習なしで、直感的に、システムの目的や機能を把握できるようにするためにあるんだよネ。
じゃあサ、メタファーで伝えたかったことを把握しちゃった後はどうなのヨ。中級者にとっては、必ずしも必要のないお節介になりかねないよネ。
メタファーとしての役割を終えたら、ひっそりと、一種の識別子として生きていくのは、メタファーの処世術としてアリだと思うケド、インターフェース全体の隅々まで一貫して統一されたメタファーで説明しきるやり方、いわゆるグローバルメタファーみたいなヤツだとヤッカイダヨ。さっき出てきた MagicCap がそうだネ。下手すると、いつまでも消えない初心者向けウィーザード並のオーバーヘッドになってしまうヨ。
... と、とりあえず以上です。言われてみれば、たしかにごもっとも、イヤなるほどねぇーってかんじなんですが、じゃあ、一体なんだってそんなメタファーってやつがこんなに幅をきかせているんでしょうね？
そのことについて About Face 3 は、「インターフェースは直感的に使えるのがイチバン」という定言命法にいつの頃からかデザイナーが盲目的に従ってしまっているからだ、と 言っています。「チョッカンテキってナンダヨ？」って。
インタラクションデザインにおいて「直感的」であるということは、そもそもどういうことか？About Face 3 による説明を勝手にまとめるとこんなかんじになります。
直感とは、意識的に行われる思考を伴わない判断や洞察のこと。意識的に行われる思考を伴わないという点では、直感と本能はよく似ている。しかし、本能がまさに生まれつきによってこの場での意識的な思考をキャンセルするのに対し、直感は、過去に別のところで行われた学習に基づいてそうする点が異なる。
つまり、ゴミ箱のアイコンがあれば、不要なデータはそこに放りこめばいいのだと「直感的」にわかる。ただし、それがわかるのは、現実世界において、ゴミはゴミ箱へ捨てるということをすでに学んでいる人だけだってことですね。
で、ここからがかっこいい。
インタラクションデザインにおいてメタファーを使うってことは、過去にどこか別の場所で行われた、人それぞれの学習の結果に頼ることではないのか？それは、あまりにもアンコントローラブルな状態であって、本質的なところで「デザイン」とは相反するアプローチなのではないか。
... って、そこまでは言ってないか。でも、まあ、そういう方向で意気込んでですね、できるだけ、もっと正々堂々と、インタラクションの現場、デザインの力がおよぶ範囲で決着をつけたらどうかとAbout Face 3 は言うんです。
えー？でも、どうやって？
その答えがイディオム中心のデザインってやつで、じつはメタファーのシンボルへの転化ってとこにその萌芽が見られるなんてことも言えてですね、むしろ本題はここからなんですけど、ちょっと長くなるのでいったんここで切りますね。つづく。
2010年1月21日木曜日
ツールのエクスペリエンス
About Face 3 読書ノートの 24。
Chapter12 「よき振る舞いのデザイン」は、クーパーの関白宣言とでもいうべき内容です。おれより先に寝てはいけない式の戒めを一方的にまくし立ててます。一言で言えば、ソフトウェアは思慮深くあれってことなんですけど、例によって、一言で言い切ってすっきりしちゃうような人じゃないわけです。
こんなかんじなんですよ。
おれに関心を示せ、敬意を払え。
常に先を見て、常識と洞察力を働かせながら、おれのニーズを予測しろ。
おれに必要な情報はちゃんと示せ、でも、うるさく質問はしてくるな。
いたずらに不安がらず、トラブルは穏便に収めろ。自分の問題でおれに負担をかけるのはやめろ。
なんでも用意周到にこなせ。ときにはルールを曲げなきゃならないことがあることも知っておけ。
そして、責任は全部おまえがとれ。
って、ね。こう書いてみるとすごいですよね。つい、続けて、
おれに関心を示せ、敬意を払え。
おれに関心を示せ、敬意を払え。
なんて、勝手にサビをつくって歌いたくなってきます。
まあ、いろいろ好き勝手言っているようですけれども、言わんとするところをよく読んでみると、ここで要求してることの数々は、A.よく気がつく子の特徴と、B.気だてのいい子の特徴に二分できそうなんですよね。すなわち、
＜A.よく気がつく子だよ＞
先が見える
ニーズを予測する
用意周到である
洞察力を持つ
＜B.気だてのいい子だよ＞
ユーザーに対して関心を持つ
ユーザーに敬意を払う
ユーザーに必要な情報を提示する
あまり質問しない
常識を知っている
穏便にエラーを収めることができる
ルールを曲げるときを知っている
自分の問題で他人に負担をかけない
自信を持っている
責任をとる
これ、B.のほうは、ツールとして現場に出てくるときには、当然あらかじめ身につけておいてしかるべきビジネスマナーってかんじですよね。
ツールとしてどんな仕事をするのかはともかくとして、ツールである以上、人間様に対してとるべき態度は自ずと定められている。あるいは、特定のユーザーや状況に奉仕する星の下に生まれついたのであってみれば、身の処し方にもやっぱり一定の規範というものがある。
だから、デザイナーはペルソナやらシナリオやらでツールの境遇を追い込んで、目当てのユーザーに気だてのいい子だよとかわいがってもらえるような振る舞いのパターンを身につけさせようとするわけですよね。その子の器量、つまり、ツールの使用価値の大元のところとは別の水準の話としてね。（あれ、だんだん政治的に正しくないかんじの表現になってきちゃったかな。）
一方、A.のほうはちょっと違う。先、予測、用意、洞察って、これ、どれもまず相手の反応を見なきゃ始まらないですよね。コール＆レスポンスの反復の中から少しずつ確度を上げていくしかないようなもんじゃないですか。一体こんなことをあらかじめデザインすることなんてできるんでしょうか。
でも、about face 3 は言うわけです。コンピューターなんだから、もっとユーザーの操作をせっせと記憶したり推論したりしてもいいはずだろうと。それではじめてよく気がつく子にもなれる。で、そこのところに本気で取り組むとすれば、じゃあ一体何をどんなふうに記憶するのか、そしてどんな推論を働かせればいいのかってことが問題になるわけだけど、そこにひとつ、デザインのしどころがあるんじゃあるまいかって。つまり、あらかじめ拵えておけるのは、気がつく能力自体じゃなく、気がつける能力だってことですよね。
ユーザーにどんな体験をしてもらうかってのをユーザーエクスペリエンスデザインと呼ぶなら、これはいわば、ツールエクスペリエンスデザインですね。操作される体験のデザイン。
いい道具ってのは使い込んでいくうちに手に身体に馴染んでくるなんてよくいいますけれども、あれ、使うほうが道具に合わせて使い方を馴らしていく一方で、道具のほうも、使われ方によって微妙に変形したりしてくるもんなんでしょうね。
誰かが使い込んだギターには弾き癖のようなものが残っていて、ちょっと触るとすぐわかるなんて、このあいだテレビで char が言ってました。
そういう、よい道具の特徴みたいなのを、ソフトウェアやデジタル製品にも持ち込むことはできないかって、そういう話として理解してもいいんじゃないでしょうか。これ。
about face 3、それこそ周到なことに、コンフィギュレーションとはまたちょっと違うんだ、なんて注意まで促してるくらいで。
具体的には、まず、ユーザーが入力すべき価値のある情報は、すべて記憶すべき価値のある情報でもあるなんて前置きをしながら、次の3点に着目して記憶をデザインしなさいと言ってます。
・よく入力される値
・あるオブジェクトについて直前に行われた指示や選択
・ユーザーにとっては実質的にひとつの操作として見えているはずの作業手順
そして、推論を行う際に従うべき指針としては、「ほとんどのときにほとんど正しい」という蓋然性重視のスローガンを打ち出しています。
まあ実際、サジェスト機能だの、よく使うページ/ファイルだの、ファイルを開く・保存するっていったら、前に選択したフォルダが開くだの、そうした思慮深さの恩恵はすでに当たり前のものになりつつあるわけですけれども、いざ、そのあたりを自分でデザインすることになったらですね、ただそうした局所的なデザインパターンに従うだけじゃなく、ああ、これはこのツールが一体何を体験するかについてのデザインなんだよなあ、なんて頭で取り組んでみるといいかもしれないですよね。
ひょっとしたら、みんながびっくりするような、本当に気がつくよい子にしてあげられるかも知れません。
-----------------
sent from W-ZERO3
Chapter12 「よき振る舞いのデザイン」は、クーパーの関白宣言とでもいうべき内容です。おれより先に寝てはいけない式の戒めを一方的にまくし立ててます。一言で言えば、ソフトウェアは思慮深くあれってことなんですけど、例によって、一言で言い切ってすっきりしちゃうような人じゃないわけです。
こんなかんじなんですよ。
おれに関心を示せ、敬意を払え。
常に先を見て、常識と洞察力を働かせながら、おれのニーズを予測しろ。
おれに必要な情報はちゃんと示せ、でも、うるさく質問はしてくるな。
いたずらに不安がらず、トラブルは穏便に収めろ。自分の問題でおれに負担をかけるのはやめろ。
なんでも用意周到にこなせ。ときにはルールを曲げなきゃならないことがあることも知っておけ。
そして、責任は全部おまえがとれ。
って、ね。こう書いてみるとすごいですよね。つい、続けて、
おれに関心を示せ、敬意を払え。
おれに関心を示せ、敬意を払え。
なんて、勝手にサビをつくって歌いたくなってきます。
まあ、いろいろ好き勝手言っているようですけれども、言わんとするところをよく読んでみると、ここで要求してることの数々は、A.よく気がつく子の特徴と、B.気だてのいい子の特徴に二分できそうなんですよね。すなわち、
＜A.よく気がつく子だよ＞
先が見える
ニーズを予測する
用意周到である
洞察力を持つ
＜B.気だてのいい子だよ＞
ユーザーに対して関心を持つ
ユーザーに敬意を払う
ユーザーに必要な情報を提示する
あまり質問しない
常識を知っている
穏便にエラーを収めることができる
ルールを曲げるときを知っている
自分の問題で他人に負担をかけない
自信を持っている
責任をとる
これ、B.のほうは、ツールとして現場に出てくるときには、当然あらかじめ身につけておいてしかるべきビジネスマナーってかんじですよね。
ツールとしてどんな仕事をするのかはともかくとして、ツールである以上、人間様に対してとるべき態度は自ずと定められている。あるいは、特定のユーザーや状況に奉仕する星の下に生まれついたのであってみれば、身の処し方にもやっぱり一定の規範というものがある。
だから、デザイナーはペルソナやらシナリオやらでツールの境遇を追い込んで、目当てのユーザーに気だてのいい子だよとかわいがってもらえるような振る舞いのパターンを身につけさせようとするわけですよね。その子の器量、つまり、ツールの使用価値の大元のところとは別の水準の話としてね。（あれ、だんだん政治的に正しくないかんじの表現になってきちゃったかな。）
一方、A.のほうはちょっと違う。先、予測、用意、洞察って、これ、どれもまず相手の反応を見なきゃ始まらないですよね。コール＆レスポンスの反復の中から少しずつ確度を上げていくしかないようなもんじゃないですか。一体こんなことをあらかじめデザインすることなんてできるんでしょうか。
でも、about face 3 は言うわけです。コンピューターなんだから、もっとユーザーの操作をせっせと記憶したり推論したりしてもいいはずだろうと。それではじめてよく気がつく子にもなれる。で、そこのところに本気で取り組むとすれば、じゃあ一体何をどんなふうに記憶するのか、そしてどんな推論を働かせればいいのかってことが問題になるわけだけど、そこにひとつ、デザインのしどころがあるんじゃあるまいかって。つまり、あらかじめ拵えておけるのは、気がつく能力自体じゃなく、気がつける能力だってことですよね。
ユーザーにどんな体験をしてもらうかってのをユーザーエクスペリエンスデザインと呼ぶなら、これはいわば、ツールエクスペリエンスデザインですね。操作される体験のデザイン。
いい道具ってのは使い込んでいくうちに手に身体に馴染んでくるなんてよくいいますけれども、あれ、使うほうが道具に合わせて使い方を馴らしていく一方で、道具のほうも、使われ方によって微妙に変形したりしてくるもんなんでしょうね。
誰かが使い込んだギターには弾き癖のようなものが残っていて、ちょっと触るとすぐわかるなんて、このあいだテレビで char が言ってました。
そういう、よい道具の特徴みたいなのを、ソフトウェアやデジタル製品にも持ち込むことはできないかって、そういう話として理解してもいいんじゃないでしょうか。これ。
about face 3、それこそ周到なことに、コンフィギュレーションとはまたちょっと違うんだ、なんて注意まで促してるくらいで。
具体的には、まず、ユーザーが入力すべき価値のある情報は、すべて記憶すべき価値のある情報でもあるなんて前置きをしながら、次の3点に着目して記憶をデザインしなさいと言ってます。
・よく入力される値
・あるオブジェクトについて直前に行われた指示や選択
・ユーザーにとっては実質的にひとつの操作として見えているはずの作業手順
そして、推論を行う際に従うべき指針としては、「ほとんどのときにほとんど正しい」という蓋然性重視のスローガンを打ち出しています。
まあ実際、サジェスト機能だの、よく使うページ/ファイルだの、ファイルを開く・保存するっていったら、前に選択したフォルダが開くだの、そうした思慮深さの恩恵はすでに当たり前のものになりつつあるわけですけれども、いざ、そのあたりを自分でデザインすることになったらですね、ただそうした局所的なデザインパターンに従うだけじゃなく、ああ、これはこのツールが一体何を体験するかについてのデザインなんだよなあ、なんて頭で取り組んでみるといいかもしれないですよね。
ひょっとしたら、みんながびっくりするような、本当に気がつくよい子にしてあげられるかも知れません。
-----------------
sent from W-ZERO3
2010年1月7日木曜日
モーダルを選ぶキリコ
ぼくは今、総務部のおじさんたちのためのアプリケーションのことを考えている。彼らに与えられた仕事にかかる負荷を軽減しつつ、それでいてその効果を最大化することが求められている。そこで、ぼくはクーパーに習って、まず、彼らのゴールを探る。彼らのエンドゴールは、求められたことを、過不足なく、つつがなくやり遂げることである。エクスペリエンスゴールは、なるべくそれに煩わされることがなく、ほとんど機械的に済ませてしまえることである。ライフゴールは、だから、そんなつまらない仕事はさっさと終えて、もっと生き生きとした時間をより多く過ごすことである。つまり彼らは、これからぼくが考えるアプリケーションと共にする時間をなるべく短くしたいと考えていて、これ以上短くならないのなら、なるべく楽に、心を亡くしても無事にやり過ごせるようなものにしてほしいと願っている。
彼らはしかし、けっして馬鹿でも子羊でもコンドルの自由を知らない被抑圧階級の一員でもない。ただ、彼らの人生全般において、ぼくがこれから考えなければいけないアプリケーションのすべてが、クーパーのいう間接税にすぎないというだけのことだ。彼らの本当のライフゴールを支える道具は他にきっとある。
クーパーのゴールダイレクテッドデザインとは、反面から捉えていえば、間接税的操作の排除、もしくはその最小化だと言い換えていい。そのためのペルソナでありシナリオだ。しかし、自分がデザインしようとしている道具がまるごと間接税扱いされてしまう事態には触れていない("間接税的なポスチュア"というものもあるのではないか？)。ぼくはおそらく、総務部のおじさんたちのために、クーパーが忌み嫌う、徹頭徹尾モーダルな、ウィザード風のインターフェースを提案してしまうだろう。
この話の筋は、ひょっとすると、ドクターキリコの安楽死肯定論に似ているかもしれない。人の一生をもっと大きな何かの前で相対化することがキリコのニヒリズムだったろう。しかし皮肉なことに、キリコの最期はブラックジャックのヒューマニズム（人の一生の全体化）に感じ入りつつ、誰かの全体のために我が身を犠牲にすることで訪れる。(いや、ぎりぎりのところで、結局、ブラックジャックに助けられてしまうんだった！)
キリコのかたわらに、本間先生が姿を現してくれることはきっとなかったんだと思うよ。
-----------------
sent from W-ZERO3
2009年12月25日金曜日
単斜グループって何ですか？
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 に、階層構造（特にフォルダの中にまたフォルダがあるような、同じ種類のオブジェクトの入れ子構造）はふつうの人には理解しにくく、取り扱いも難しい。それよりも「単斜グループ」を使ったほうがいい、みたいなことが書いてあるんです。
単斜グループ？ 何それ？
説明を読めば、それが、階層を持たない一列の並び、ということで、現実世界でいえば、本棚やファイルキャビネットのようなものだとわかります。
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 を、「単斜グループ」と訳すのは、ちょっと不適切なんじゃないかと思うのですがどうでしょう。
じゃあ、何と呼べばいいか？ もう、「クラインなかんじに並べとく」って言うしかないかな？ でも、クラインとかいうと変な形の壺が目に浮かぶしな ... 。
登録:
投稿 (Atom)