中央銀行は、一定の現金通貨をストックし、ストックした個々の紙幣、硬貨に一対一で対応する兌換電子通貨トークンを発行する。
中央銀行は、兌換電子通貨トークンを保持するためのおサイフアプリを無償で提供する。
人は、いくつでもおサイフアプリを持つことができる。
人は、自分のおサイフアプリに入っている兌換電子通貨トークンを、他の人の特定のおサイフアプリに移すことができる。
おサイフアプリは、新たに保持する兌換電子通貨トークンに自らに固有のシグネチャーを付与する。保持をやめるときはシグネチャーを削除する。
中央銀行は、ストックしている通貨に対応する兌換電子通貨トークンに付与されたシグネチャーを、つねに把握している。
人は、自分のおサイフアプリに保持している兌換電子通貨トークンを、対応する現金通貨と交換することができる。
さっくり、こんな仕組みがもしもあってくれたならば、電子マネーといえども、その使い勝手は、フィジカルなマネーとほとんど変わるところがなくなる。と、信ずる。
つまり、アカウントレスで、プライバシーともきれいに切れていて、大人も子供も関係なく自分の経済的境遇に応じて出し入れできて、支払いの手続きに特別な数字の入力も必要なくて、支払い方法で囲い込まれたり、売買がつねに三者間取引としてしかあり得ず、いつもなんだか釈然としない手数料が上乗せされるなんてことのない、それこそ、みんながずっと慣れ親しんできた、ごくふつうの、自由な市場経済。
この水準のプラットフォームを提供するのは、産業資本主義でやっていく国民国家の機能のうちでも、コアの部類でしょう。なんで放任なんだろう？
ん。いやいやいやいや、大丈夫、大丈夫。狂ってるのは僕のほうぢゃないよ。
2010年11月12日金曜日
2010年11月3日水曜日
DraftPadでTweetする前にURLを短縮するHack
iPhoneユーザー必携、アウェーでテキスト入力する不安から解放してくれる究極の下書きアプリ、DraftPad。先日のバージョンアップもすごかったですね。ユーザーとして淡く抱いていたマインドモデルに革命の嵐が吹きまくりましたね。これがシュトゥルム・ウント・ドラングってやつですかね。開発者が自らインタビューで述べているとおり、これはたしかに、「テキスト情報の活用フローにおけるハブ」ですね。ぼくなんて tweet すらほとんど DraftPad で書いてポンですから。
DraftPad のそのすてきなハブ性は、いうまでもなく、URL スキームによるアプリ間連携を積極的に活用しようという Assist 機構によるわけですけれども、このあたり、ほんとに美しいデザインですよね。シンプルなフレームワークで無限の未来=拡張性を切り拓く、みたいな。
だってこの機構のおかげで、たんに DraftPad でしたためたテキストをほうぼうに投げるとか、よそで漁ったテキストを手になじんだまな板と包丁としての DraftPad に乗せるとかだけじゃなくてね、調子に乗ればちょっとしたテキストフィルター機能みたいなのを自分でこしらえて、生の DraftPad をオレゴノミにカスタマイズしちゃう、なんてこともできるわけです。
たとえば、tweetする前にテキストに含まれる URL を、bit.ly の API を使って短縮するとか、どうでしょう。
下記のような javascript をちょこちょこっと書いて、ネット上の適当な(自分だけがこっそり知っているような)URLで公開してですね、これを DraftPad の Assist で呼べばいけます。
# 冒頭の "your uid" のところに bit.ly アカウントの ユーザーネームを、"your api key" のところに API Key を入力します。あと、jQuery1.4を使ってます。
DraftPad の Assist はこんなかんじですね。
かんたんですね。
最初はどっかにホストして、生意気にも bit.ly のサードパーティづらで、みんなで使えるようにしてみようかななんて思ったんですが、javascriptで自分の API Key 晒すのもナニですし、かといって、Assist に 利用者各自の API Key を埋め込んで投げてもらうのも、セッション ID 入りのクエリパラメータつきで Get リクエストするのとほぼ同等の脇の甘さになるんで、やめました。
でも、やっぱりこれ、ちょっと便利みたいなんで、かんたん導入キットを用意してみました。(クエリパラメータつきのURLを正しく短縮できない不具合を修正しました。2010年11月4日 13:31 追記。...すみません。)2KB の ZIP ファイルです。を解凍すると、shorten.html と assist.html という2つのファイルが展開されます。
shorten.html の "your uid" と "your API Key" のところを書き換えます。API Key は、bit.ly の 「Settings」のところに出てます。
assist.htmlのほうはいじる必要はありません。
で、この2ファイルをどっか適当なところにアップロードしてください。
assist.html のほうにアクセスすると、「Insert Assist」というボタンが表示されますからタップしてください。あなたの Draft Pad に 「Shorten Links for DraftPad」という Assist が導入されます。お気に召すかどうかわかりませんが、よろしければ Your Own Risk でどうぞ。
以下、2011年11月5日追記。
とかいってたら、あっという間に、DraftPadの公式Assistに"Shorten URLs"というのが登場しました！ これならみんなかんたんに使えます。すばらしい。ぼくもこっちに乗り換えます。
まあ、どうしても自分のアカウントで、というムキのために、上の野良アシストもそのままにしておきますか。
追記、ここまで。
いやあ、とにかく、DraftPad はすごいですよ。
DraftPad のそのすてきなハブ性は、いうまでもなく、URL スキームによるアプリ間連携を積極的に活用しようという Assist 機構によるわけですけれども、このあたり、ほんとに美しいデザインですよね。シンプルなフレームワークで無限の未来=拡張性を切り拓く、みたいな。
だってこの機構のおかげで、たんに DraftPad でしたためたテキストをほうぼうに投げるとか、よそで漁ったテキストを手になじんだまな板と包丁としての DraftPad に乗せるとかだけじゃなくてね、調子に乗ればちょっとしたテキストフィルター機能みたいなのを自分でこしらえて、生の DraftPad をオレゴノミにカスタマイズしちゃう、なんてこともできるわけです。
たとえば、tweetする前にテキストに含まれる URL を、bit.ly の API を使って短縮するとか、どうでしょう。
下記のような javascript をちょこちょこっと書いて、ネット上の適当な(自分だけがこっそり知っているような)URLで公開してですね、これを DraftPad の Assist で呼べばいけます。
var uid = "your uid";
var apikey = "your api key";
var bitly = "http://api.bit.ly/shorten?version=2.0.1&login=" + uid + "&apiKey=" + apikey;
var text = decodeURIComponent( window.location.search.substr( 1 ) );
$( function () {
if ( text ) {
var longurls = text.match( /https*:\/\/[^\s]*/g );
$.each( longurls, function () {
bitly = bitly + "&longUrl=" + encodeURIComponent( this );
});
$.getJSON( bitly + "&callback=?", function( data ) {
var keys = [];
for ( key in data.results ){
text = text.replace( key, data.results[ key ].shortUrl );
}
sendToDraftPad( text );
});
}
});
function sendToDraftPad ( text ) {
window.location.href = "draftpad://insert?text=" + encodeURIComponent( text );
window.close();
}
# 冒頭の "your uid" のところに bit.ly アカウントの ユーザーネームを、"your api key" のところに API Key を入力します。あと、jQuery1.4を使ってます。
DraftPad の Assist はこんなかんじですね。
ex) 上記のコードに、sample.com/foo.html としてアクセスできるようにした場合。
http://sample.com/foo.html?<@@>
かんたんですね。
最初はどっかにホストして、生意気にも bit.ly のサードパーティづらで、みんなで使えるようにしてみようかななんて思ったんですが、javascriptで自分の API Key 晒すのもナニですし、かといって、Assist に 利用者各自の API Key を埋め込んで投げてもらうのも、セッション ID 入りのクエリパラメータつきで Get リクエストするのとほぼ同等の脇の甘さになるんで、やめました。
でも、やっぱりこれ、ちょっと便利みたいなんで、かんたん導入キットを用意してみました。(クエリパラメータつきのURLを正しく短縮できない不具合を修正しました。2010年11月4日 13:31 追記。...すみません。)2KB の ZIP ファイルです。を解凍すると、shorten.html と assist.html という2つのファイルが展開されます。
shorten.html の "your uid" と "your API Key" のところを書き換えます。API Key は、bit.ly の 「Settings」のところに出てます。
assist.htmlのほうはいじる必要はありません。
で、この2ファイルをどっか適当なところにアップロードしてください。
assist.html のほうにアクセスすると、「Insert Assist」というボタンが表示されますからタップしてください。あなたの Draft Pad に 「Shorten Links for DraftPad」という Assist が導入されます。お気に召すかどうかわかりませんが、よろしければ Your Own Risk でどうぞ。
以下、2011年11月5日追記。
とかいってたら、あっという間に、DraftPadの公式Assistに"Shorten URLs"というのが登場しました！ これならみんなかんたんに使えます。すばらしい。ぼくもこっちに乗り換えます。
まあ、どうしても自分のアカウントで、というムキのために、上の野良アシストもそのままにしておきますか。
追記、ここまで。
いやあ、とにかく、DraftPad はすごいですよ。
2010年9月8日水曜日
魔法のページカール
なぜ綴じ製本が考案され、ひとつの道具としてこれほど強い支持を集めているのかといえば、なにはさて置いても、まず最初に、長大な文章へのランダムアクセスが簡単になるという点を挙げざるをえないでしょう。
どんなに長大な文章でも、裁断した紙に順番に印刷していったん綴じてしまえば、任意の箇所をページ数で指し示すことができます。その後で行数、文字数を示せば完璧です。
よく知りませんが、聖書なんてあんな寄せ集めの本、綴じ本がなきゃ企画もされなかったんじゃないですかね。
巻き物に、そんな真似はできませんね。やっぱりよく知りませんが、三蔵法師が持って帰ってきたありがたいお経というのは、一本一本別々のものだったでしょ？
しかし、これはいってみれば「図らずも」ってかんじなんだと思いますが、綴じ製本は、シーケンシャルアクセスに対しても、大きなメリットを発揮していたんだと思います。
それは、長文を読む際に、
・一度に読める範囲を移動していく度に行われる目と手の協応動作を簡単で安定的なものにした。
・ページをめくるときに一瞬本文から目を切ることが、一種の強制的な「瞬き」として脳が休む時間を作っており、かえって長時間本文に向かうことを可能にした。
前者のほうは、前の NehanTouch お披露目エントリーで述べたとおりです。前者のメリットがあるんで、紙の物性から離れても、ページネーションにはユーザービリティ上の一定の合理がありえる、というわけです。
で、後者のほうなんですけど、ぼくは、ページネーションでペロってページがめくれるようなものにしろなんにしろ、トランジションにはたいして意味を見出せなかったもんですから、その NehanTouch では、前後のページへの遷移はただあっけらかんと一瞬で全文を書き換えるだけにしておいたんです。
だってねえ。そもそもあれこそ、メディアの物理的性質上、避けることのできなかった情報量ゼロの視覚的ノイズでしょう。そういう制約からせっかく解放されたデジタルデバイスの上で、なぜわざわざ苦労して(むしろ喜んで)、忠実に再現しようとするんだろう？そこには、About Face 3 も揶揄していた、車に手綱を取り付ける類のアナクロニズムが潜んでいるんじゃないの？本のメタファーとかいって、なにもそこを真似ることはないだろう、ってね。
ただ ... ええっと、自分で作っておいてナニですけれども、結構ぼく、NehanTouch を愛用しているんですよ。かなりこれ使って、ガンガン読んでます。東浩紀の昔の論文とか見つけたりして。
そしたら、そういう、ほんとに長いものを読んでると、なんとなく息苦しくなってくることに気がついたんです。よくわかりませんが、たぶん、読むこと、ページをめくること、これらを繰り返すことが単調すぎるからじゃないか。なんかの栄養が足りないのかも知れませんが、だんだんキーッとなってくる。紙の本の場合は、疲れてきて文字を追えなくなったり、内容がさっぱり頭に入らなくなるということはあっても、そんなかんじになることはないのに。
で、そう思って、改めて本を手にとってみると、じつにこう、複雑な動きを求められていたのがわかるんですね。左右の手のそれぞれの動きと、そのコンビネーション、そこに視線移動が同期して、読むという行為が完成する。その複雑さは、あれ？さっきなんて書いてあったっけ？なんて、遠く離れたページの間を行きつ戻りつしているときに最高潮に達します。
そうやって読書というものをあらためて反省してみてですね、やっぱり「ページをめくる」っていうのは、「読む」に匹敵するほど大きな行為だったんだなってことに気がつきました。そして、ページをめくるたびに、文字の世界を少しだけ遠くに離して、そのぶん、ひらひらとページが舞っているサマにほんの一瞬だけど心を奪われるのは、なんというか、悪くない。
これが、まあ、読み方にもよりますけど、一定のタイミングで割り込んでくるわけで。それがひょっとすると、過度な神経の集中をうまく逃がしていることになっているのではないでしょうか？脳と神経の休憩、リフレッシュ。読むという行為には干渉しない視覚的なアソビ。一種のアース。つまり、瞬きの延長。ですね。
そうすると、こちらもまた、紙という物性から解放されてもなお、ユーザービリティにおいて一定の合理がある。といえます。ページネーションに紙のようなトランジションを導入することを笑ってはいけません。
ね。
しかし、ここまでの理屈だと、いわゆるスライドイン/アウトみたいなトランジションで事が足りるんで、あのペロっとめくれるページカールってやつまでは擁護できないんですよね。ページカールでも十分に上記の合理を満たすことはできるんだけど、逆にページカールじゃなくちゃダメってことにはならない。やっぱりアレはやりすぎだよ、ガハハってことでいいかな？
ただ、こういうことはいえる。その手のトランジションというものは、全部ひっくるめて、ユーザーの関心を誘うギミックなんだ、と。この点をけっして無視することはできないでしょう。それは、いわば物珍しい魔法として、実際に手にとってみたいという欲望を駆り立てます。道具にとって魔法のようであるという特徴は大事なことです。魅力的な道具は、たいした用事もないのに、なんとはなしに手にとってみたくなるものですよね。
だいたいタッチインターフェースそのものが、アップルの一番偉い人がそう叫んだように、そもそも魔法として広められているわけです。そして、ハリーポッターの映画とかを見ていてもわかりますが、たいていの魔法(われわれのファンタジックな想像力と欲望)は、まったく荒唐無稽なものではありえません。それは、基本的には現実に基づきつつ、しかし、どこかでわずかに現実を裏切って時空の原則を超えていくものとして構想されます。そうじゃないと、われわれの欲望をうまく掻き立てることはできないんですよね。
さて、そうだとすると、ですよ。ページネーションにおける魔法の王様は、やっぱりページカールということになるでしょう、諸君！ページをめくるんだから、現実に基づけばあれ以外には考えられない。しかし、よく考えたら、実際の本があんなにディズニーっぽくめくれ上がることはありえないわけで（忠実な再現なんてとんでもない！）、その点でほら、魔法の要件を完全に満たしているんですよ、あれは。それに比べたらスライドインなんてショボすぎるってなもんです。
えー、というわけでございまして、そんなことをつらつら考えてですね、結局、NehanTouch のページネーションにもトランジションをつけてみることにしました。といっても、ページカールなんて高級な魔法はとても無理なんで、とりあえず、スライドインでひとつご機嫌を伺ってみようと。えー、意味深なタイトルをつけて、わけのわからないことを書き連ねてしまいましたが、実はそれが言いたかっただけでした。
どんなに長大な文章でも、裁断した紙に順番に印刷していったん綴じてしまえば、任意の箇所をページ数で指し示すことができます。その後で行数、文字数を示せば完璧です。
よく知りませんが、聖書なんてあんな寄せ集めの本、綴じ本がなきゃ企画もされなかったんじゃないですかね。
巻き物に、そんな真似はできませんね。やっぱりよく知りませんが、三蔵法師が持って帰ってきたありがたいお経というのは、一本一本別々のものだったでしょ？
しかし、これはいってみれば「図らずも」ってかんじなんだと思いますが、綴じ製本は、シーケンシャルアクセスに対しても、大きなメリットを発揮していたんだと思います。
それは、長文を読む際に、
・一度に読める範囲を移動していく度に行われる目と手の協応動作を簡単で安定的なものにした。
・ページをめくるときに一瞬本文から目を切ることが、一種の強制的な「瞬き」として脳が休む時間を作っており、かえって長時間本文に向かうことを可能にした。
前者のほうは、前の NehanTouch お披露目エントリーで述べたとおりです。前者のメリットがあるんで、紙の物性から離れても、ページネーションにはユーザービリティ上の一定の合理がありえる、というわけです。
で、後者のほうなんですけど、ぼくは、ページネーションでペロってページがめくれるようなものにしろなんにしろ、トランジションにはたいして意味を見出せなかったもんですから、その NehanTouch では、前後のページへの遷移はただあっけらかんと一瞬で全文を書き換えるだけにしておいたんです。
だってねえ。そもそもあれこそ、メディアの物理的性質上、避けることのできなかった情報量ゼロの視覚的ノイズでしょう。そういう制約からせっかく解放されたデジタルデバイスの上で、なぜわざわざ苦労して(むしろ喜んで)、忠実に再現しようとするんだろう？そこには、About Face 3 も揶揄していた、車に手綱を取り付ける類のアナクロニズムが潜んでいるんじゃないの？本のメタファーとかいって、なにもそこを真似ることはないだろう、ってね。
ただ ... ええっと、自分で作っておいてナニですけれども、結構ぼく、NehanTouch を愛用しているんですよ。かなりこれ使って、ガンガン読んでます。東浩紀の昔の論文とか見つけたりして。
そしたら、そういう、ほんとに長いものを読んでると、なんとなく息苦しくなってくることに気がついたんです。よくわかりませんが、たぶん、読むこと、ページをめくること、これらを繰り返すことが単調すぎるからじゃないか。なんかの栄養が足りないのかも知れませんが、だんだんキーッとなってくる。紙の本の場合は、疲れてきて文字を追えなくなったり、内容がさっぱり頭に入らなくなるということはあっても、そんなかんじになることはないのに。
で、そう思って、改めて本を手にとってみると、じつにこう、複雑な動きを求められていたのがわかるんですね。左右の手のそれぞれの動きと、そのコンビネーション、そこに視線移動が同期して、読むという行為が完成する。その複雑さは、あれ？さっきなんて書いてあったっけ？なんて、遠く離れたページの間を行きつ戻りつしているときに最高潮に達します。
そうやって読書というものをあらためて反省してみてですね、やっぱり「ページをめくる」っていうのは、「読む」に匹敵するほど大きな行為だったんだなってことに気がつきました。そして、ページをめくるたびに、文字の世界を少しだけ遠くに離して、そのぶん、ひらひらとページが舞っているサマにほんの一瞬だけど心を奪われるのは、なんというか、悪くない。
これが、まあ、読み方にもよりますけど、一定のタイミングで割り込んでくるわけで。それがひょっとすると、過度な神経の集中をうまく逃がしていることになっているのではないでしょうか？脳と神経の休憩、リフレッシュ。読むという行為には干渉しない視覚的なアソビ。一種のアース。つまり、瞬きの延長。ですね。
そうすると、こちらもまた、紙という物性から解放されてもなお、ユーザービリティにおいて一定の合理がある。といえます。ページネーションに紙のようなトランジションを導入することを笑ってはいけません。
ね。
しかし、ここまでの理屈だと、いわゆるスライドイン/アウトみたいなトランジションで事が足りるんで、あのペロっとめくれるページカールってやつまでは擁護できないんですよね。ページカールでも十分に上記の合理を満たすことはできるんだけど、逆にページカールじゃなくちゃダメってことにはならない。やっぱりアレはやりすぎだよ、ガハハってことでいいかな？
ただ、こういうことはいえる。その手のトランジションというものは、全部ひっくるめて、ユーザーの関心を誘うギミックなんだ、と。この点をけっして無視することはできないでしょう。それは、いわば物珍しい魔法として、実際に手にとってみたいという欲望を駆り立てます。道具にとって魔法のようであるという特徴は大事なことです。魅力的な道具は、たいした用事もないのに、なんとはなしに手にとってみたくなるものですよね。
だいたいタッチインターフェースそのものが、アップルの一番偉い人がそう叫んだように、そもそも魔法として広められているわけです。そして、ハリーポッターの映画とかを見ていてもわかりますが、たいていの魔法(われわれのファンタジックな想像力と欲望)は、まったく荒唐無稽なものではありえません。それは、基本的には現実に基づきつつ、しかし、どこかでわずかに現実を裏切って時空の原則を超えていくものとして構想されます。そうじゃないと、われわれの欲望をうまく掻き立てることはできないんですよね。
さて、そうだとすると、ですよ。ページネーションにおける魔法の王様は、やっぱりページカールということになるでしょう、諸君！ページをめくるんだから、現実に基づけばあれ以外には考えられない。しかし、よく考えたら、実際の本があんなにディズニーっぽくめくれ上がることはありえないわけで（忠実な再現なんてとんでもない！）、その点でほら、魔法の要件を完全に満たしているんですよ、あれは。それに比べたらスライドインなんてショボすぎるってなもんです。
えー、というわけでございまして、そんなことをつらつら考えてですね、結局、NehanTouch のページネーションにもトランジションをつけてみることにしました。といっても、ページカールなんて高級な魔法はとても無理なんで、とりあえず、スライドインでひとつご機嫌を伺ってみようと。えー、意味深なタイトルをつけて、わけのわからないことを書き連ねてしまいましたが、実はそれが言いたかっただけでした。
2010年7月2日金曜日
iPhone で Web ページを電子書籍風にビューするブックマークレット
Webページ上でテキストを縦組みにする nehan と、Webページから本文らしきテキストを高精度で抽出できる extract-content-javascript という素晴らしい Javascriptモジュールに立て続けに出会ったので、これらを組み合わせて、iPhone で Web ページを電子書籍風にビューするブックマークレット NehanTouch ってのを作ってみました。
こういうページを、
うまくいけば、こんなかんじで読むことができます。
(中には、HTMLの構造上、どうしても本文が抽出できないページもあります。そんな場合のために、目下、姉妹ブックマークレット NehanPaste というのを準備中です。どういうものになるかは、名前から推して測るべしってかんじですね。)
ぼくも iPhone をはじめて手にしたとき、まず最初に、ああ、これならいろいろ読めそうだ、と思ったクチですが、今みんなが騒いでる、いわゆる「電子書籍」っていうやつよりは、むしろ、Webで公開されている長文テキストが読みたかったのです。
たとえば、37 signals の Getting Real とかね。
こんな素敵なテキストがパブリックに転がってるところがWebの凄味のひとつだと思うんですが、しかしこういうの、どうも PC では読む気がしなかったんですよね。
江戸時代の学者じゃないんだから、書見台に向かうような姿勢を強制されての読書なんてカンベンしてほしい。
でも、iPhoneで、あの解像度で、あのフォントで、あのインターフェースでならいけるだろう。電車のドアのところにだらしなくもたれたり、家ででーんとひっくり返ったりしながらでも、普通に読めるんじゃないか、と。
でもね、やっぱり Webブラウザで長文は読みにくかったです。なんでかっていうと、いまさら言うまでもないことですが、スクロールですよね。問題は。
スクロールはリストを上から舐めて、行きつ戻りつしながら、目的の何かを見つけ出すためには結構使えるインターフェースだと思いますが、一連の文章をじわじわ読み進めるのには、たぶん向いてない。
だって、巻物もそうだと思いますけど、オートスクロールのように一定の速度で流していくような読み方は、ふつうできないわけで。
どうしたって、だいたい一度で読める範囲ごとに少し動かしては止めて、で、読み進めて、まただいたいでガサっと動かして止めて、っていうことになる。
すると、毎度毎度、手で適当にスクロールした量と速度に合わせて、次の読み始めの位置まで視線をさっと動かさなきゃいけない。いつも決まった場所というわけにはいかない、ブレブレの反復動作。
これ、心理学方面では、目と手の協応動作とかっていうんですけど、結構な負荷なわけです。実は相当な集中力を要します。
その負荷の大きさをあらためて思い知ったのは、iPhoneを手に入れたばかりの興奮も覚めやらぬとあるラーメン店でのことでした。ああ、おれの目と手は全然協応しない！ ラーメン食いながらだと特に！って。
長文のテキストを読み進める場合は、内容に集中してフロー状態に入りたいわけですけど、目と手の協応動作の負荷が大きすぎて、いちいち干渉してくるわけです。
そこへいくと、青空文庫ビューアはどれもスグレモノでした。いわゆる「ページめくり」で、ほんとにスラスラ読めるんですよね、ラーメンすすりながらでも。
「ページめくり」というのは、要するに、ページ(表示領域)単位のスクロールです。これを最小のユーザーアクション(たとえば、ページの決まった位置を軽くタップ)で行えるようにして、だからつまり、インターフェースの透明度を最大化してですね、電子的なテキストメディアに没入できるようにする ... Web上のコンテンツにも、ものによってはそうしたビューの方法を適用できるようにすると、デバイスの進化/多様化と相俟って、Webの可能性はさらに広がり、いよいよ凄味を増していくんじゃないの？
というとこらへんをめぐって、本来、「電子書籍」は夢見られるべきなんじゃないの？
なんて思いも込めながら作ってみたんですが、出来上がりに対して、思いのほうがちょっと生意気すぎましたね。
こういうページを、
うまくいけば、こんなかんじで読むことができます。
(中には、HTMLの構造上、どうしても本文が抽出できないページもあります。そんな場合のために、目下、姉妹ブックマークレット NehanPaste というのを準備中です。どういうものになるかは、名前から推して測るべしってかんじですね。)
ぼくも iPhone をはじめて手にしたとき、まず最初に、ああ、これならいろいろ読めそうだ、と思ったクチですが、今みんなが騒いでる、いわゆる「電子書籍」っていうやつよりは、むしろ、Webで公開されている長文テキストが読みたかったのです。
たとえば、37 signals の Getting Real とかね。
こんな素敵なテキストがパブリックに転がってるところがWebの凄味のひとつだと思うんですが、しかしこういうの、どうも PC では読む気がしなかったんですよね。
江戸時代の学者じゃないんだから、書見台に向かうような姿勢を強制されての読書なんてカンベンしてほしい。
でも、iPhoneで、あの解像度で、あのフォントで、あのインターフェースでならいけるだろう。電車のドアのところにだらしなくもたれたり、家ででーんとひっくり返ったりしながらでも、普通に読めるんじゃないか、と。
でもね、やっぱり Webブラウザで長文は読みにくかったです。なんでかっていうと、いまさら言うまでもないことですが、スクロールですよね。問題は。
スクロールはリストを上から舐めて、行きつ戻りつしながら、目的の何かを見つけ出すためには結構使えるインターフェースだと思いますが、一連の文章をじわじわ読み進めるのには、たぶん向いてない。
だって、巻物もそうだと思いますけど、オートスクロールのように一定の速度で流していくような読み方は、ふつうできないわけで。
どうしたって、だいたい一度で読める範囲ごとに少し動かしては止めて、で、読み進めて、まただいたいでガサっと動かして止めて、っていうことになる。
すると、毎度毎度、手で適当にスクロールした量と速度に合わせて、次の読み始めの位置まで視線をさっと動かさなきゃいけない。いつも決まった場所というわけにはいかない、ブレブレの反復動作。
これ、心理学方面では、目と手の協応動作とかっていうんですけど、結構な負荷なわけです。実は相当な集中力を要します。
その負荷の大きさをあらためて思い知ったのは、iPhoneを手に入れたばかりの興奮も覚めやらぬとあるラーメン店でのことでした。ああ、おれの目と手は全然協応しない！ ラーメン食いながらだと特に！って。
長文のテキストを読み進める場合は、内容に集中してフロー状態に入りたいわけですけど、目と手の協応動作の負荷が大きすぎて、いちいち干渉してくるわけです。
そこへいくと、青空文庫ビューアはどれもスグレモノでした。いわゆる「ページめくり」で、ほんとにスラスラ読めるんですよね、ラーメンすすりながらでも。
「ページめくり」というのは、要するに、ページ(表示領域)単位のスクロールです。これを最小のユーザーアクション(たとえば、ページの決まった位置を軽くタップ)で行えるようにして、だからつまり、インターフェースの透明度を最大化してですね、電子的なテキストメディアに没入できるようにする ... Web上のコンテンツにも、ものによってはそうしたビューの方法を適用できるようにすると、デバイスの進化/多様化と相俟って、Webの可能性はさらに広がり、いよいよ凄味を増していくんじゃないの？
というとこらへんをめぐって、本来、「電子書籍」は夢見られるべきなんじゃないの？
なんて思いも込めながら作ってみたんですが、出来上がりに対して、思いのほうがちょっと生意気すぎましたね。
2010年4月8日木曜日
イディオマティックデザイン
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 に入るわけですけど、要するに具体的なイディオムの使い方指南なんですよね。検索、アンドゥ、保存、入力、選択、ウィンドウ、各種のコントロール部品、メニュー、ツールバー、ダイアログ、エラー、警告、確認 ... といったイディオムの数々。ここも言語アナロジーにのっていえば、"文章読本"みたいなかんじですね。そう思ってもうしばらく読み進めてみることにします。
ここにきて 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年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 追記)
登録:
投稿 (Atom)