DraftPadでTweetする前にURLを短縮するHack

iPhoneユーザー必携、アウェーでテキスト入力する不安から解放してくれる究極の下書きアプリ、DraftPad。先日のバージョンアップもすごかったですね。ユーザーとして淡く抱いていたマインドモデルに革命の嵐が吹きまくりましたね。これがシュトゥルム・ウント・ドラングってやつですかね。開発者が自らインタビューで述べているとおり、これはたしかに、「テキスト情報の活用フローにおけるハブ」ですね。ぼくなんて tweet すらほとんど 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 はすごいですよ。

魔法のページカール

なぜ綴じ製本が考案され、ひとつの道具としてこれほど強い支持を集めているのかといえば、なにはさて置いても、まず最初に、長大な文章へのランダムアクセスが簡単になるという点を挙げざるをえないでしょう。

どんなに長大な文章でも、裁断した紙に順番に印刷していったん綴じてしまえば、任意の箇所をページ数で指し示すことができます。その後で行数、文字数を示せば完璧です。

よく知りませんが、聖書なんてあんな寄せ集めの本、綴じ本がなきゃ企画もされなかったんじゃないですかね。

巻き物に、そんな真似はできませんね。やっぱりよく知りませんが、三蔵法師が持って帰ってきたありがたいお経というのは、一本一本別々のものだったでしょ？

しかし、これはいってみれば「図らずも」ってかんじなんだと思いますが、綴じ製本は、シーケンシャルアクセスに対しても、大きなメリットを発揮していたんだと思います。

それは、長文を読む際に、

・一度に読める範囲を移動していく度に行われる目と手の協応動作を簡単で安定的なものにした。

・ページをめくるときに一瞬本文から目を切ることが、一種の強制的な「瞬き」として脳が休む時間を作っており、かえって長時間本文に向かうことを可能にした。

前者のほうは、前の NehanTouch お披露目エントリーで述べたとおりです。前者のメリットがあるんで、紙の物性から離れても、ページネーションにはユーザービリティ上の一定の合理がありえる、というわけです。

で、後者のほうなんですけど、ぼくは、ページネーションでペロってページがめくれるようなものにしろなんにしろ、トランジションにはたいして意味を見出せなかったもんですから、その NehanTouch では、前後のページへの遷移はただあっけらかんと一瞬で全文を書き換えるだけにしておいたんです。

だってねえ。そもそもあれこそ、メディアの物理的性質上、避けることのできなかった情報量ゼロの視覚的ノイズでしょう。そういう制約からせっかく解放されたデジタルデバイスの上で、なぜわざわざ苦労して(むしろ喜んで)、忠実に再現しようとするんだろう？そこには、About Face 3 も揶揄していた、車に手綱を取り付ける類のアナクロニズムが潜んでいるんじゃないの？本のメタファーとかいって、なにもそこを真似ることはないだろう、ってね。

ただ ... ええっと、自分で作っておいてナニですけれども、結構ぼく、NehanTouch を愛用しているんですよ。かなりこれ使って、ガンガン読んでます。東浩紀の昔の論文とか見つけたりして。

そしたら、そういう、ほんとに長いものを読んでると、なんとなく息苦しくなってくることに気がついたんです。よくわかりませんが、たぶん、読むこと、ページをめくること、これらを繰り返すことが単調すぎるからじゃないか。なんかの栄養が足りないのかも知れませんが、だんだんキーッとなってくる。紙の本の場合は、疲れてきて文字を追えなくなったり、内容がさっぱり頭に入らなくなるということはあっても、そんなかんじになることはないのに。

で、そう思って、改めて本を手にとってみると、じつにこう、複雑な動きを求められていたのがわかるんですね。左右の手のそれぞれの動きと、そのコンビネーション、そこに視線移動が同期して、読むという行為が完成する。その複雑さは、あれ？さっきなんて書いてあったっけ？なんて、遠く離れたページの間を行きつ戻りつしているときに最高潮に達します。

そうやって読書というものをあらためて反省してみてですね、やっぱり「ページをめくる」っていうのは、「読む」に匹敵するほど大きな行為だったんだなってことに気がつきました。そして、ページをめくるたびに、文字の世界を少しだけ遠くに離して、そのぶん、ひらひらとページが舞っているサマにほんの一瞬だけど心を奪われるのは、なんというか、悪くない。

これが、まあ、読み方にもよりますけど、一定のタイミングで割り込んでくるわけで。それがひょっとすると、過度な神経の集中をうまく逃がしていることになっているのではないでしょうか？脳と神経の休憩、リフレッシュ。読むという行為には干渉しない視覚的なアソビ。一種のアース。つまり、瞬きの延長。ですね。

そうすると、こちらもまた、紙という物性から解放されてもなお、ユーザービリティにおいて一定の合理がある。といえます。ページネーションに紙のようなトランジションを導入することを笑ってはいけません。

ね。

しかし、ここまでの理屈だと、いわゆるスライドイン/アウトみたいなトランジションで事が足りるんで、あのペロっとめくれるページカールってやつまでは擁護できないんですよね。ページカールでも十分に上記の合理を満たすことはできるんだけど、逆にページカールじゃなくちゃダメってことにはならない。やっぱりアレはやりすぎだよ、ガハハってことでいいかな？

ただ、こういうことはいえる。その手のトランジションというものは、全部ひっくるめて、ユーザーの関心を誘うギミックなんだ、と。この点をけっして無視することはできないでしょう。それは、いわば物珍しい魔法として、実際に手にとってみたいという欲望を駆り立てます。道具にとって魔法のようであるという特徴は大事なことです。魅力的な道具は、たいした用事もないのに、なんとはなしに手にとってみたくなるものですよね。

だいたいタッチインターフェースそのものが、アップルの一番偉い人がそう叫んだように、そもそも魔法として広められているわけです。そして、ハリーポッターの映画とかを見ていてもわかりますが、たいていの魔法(われわれのファンタジックな想像力と欲望)は、まったく荒唐無稽なものではありえません。それは、基本的には現実に基づきつつ、しかし、どこかでわずかに現実を裏切って時空の原則を超えていくものとして構想されます。そうじゃないと、われわれの欲望をうまく掻き立てることはできないんですよね。

さて、そうだとすると、ですよ。ページネーションにおける魔法の王様は、やっぱりページカールということになるでしょう、諸君！ページをめくるんだから、現実に基づけばあれ以外には考えられない。しかし、よく考えたら、実際の本があんなにディズニーっぽくめくれ上がることはありえないわけで（忠実な再現なんてとんでもない！）、その点でほら、魔法の要件を完全に満たしているんですよ、あれは。それに比べたらスライドインなんてショボすぎるってなもんです。

えー、というわけでございまして、そんなことをつらつら考えてですね、結局、NehanTouch のページネーションにもトランジションをつけてみることにしました。といっても、ページカールなんて高級な魔法はとても無理なんで、とりあえず、スライドインでひとつご機嫌を伺ってみようと。えー、意味深なタイトルをつけて、わけのわからないことを書き連ねてしまいましたが、実はそれが言いたかっただけでした。

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の可能性はさらに広がり、いよいよ凄味を増していくんじゃないの？

というとこらへんをめぐって、本来、「電子書籍」は夢見られるべきなんじゃないの？

なんて思いも込めながら作ってみたんですが、出来上がりに対して、思いのほうがちょっと生意気すぎましたね。

イディオマティックデザイン

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 読書ノートの 26 。

イディオム中心デザインの話にいく前に、もう少しメタファーのことを。というのも、前のノートを書いてて、正直、クーパー言い過ぎじゃないかなと思わないでもなかったんですよね。そんなにメタファーって、だめだったっけって。

ちらちら頭をかすめるのは、eXtreme Programming のプラクティスのひとつ、「適切なメタファー」のことでした。これから作るものについてのイメージを、グッとくるようなメタファーを使ってチームのみんなで共有しておこうというやつですね。

About Face 3 では、実装中心デザインを推進する憐れむべき人々みたいなかんじでしか描かれませんが、プロジェクトの最初期、まだ何を作るのか雲をつかむような段階では、開発者だってまるで日の浅いユーザーとおなじようにシステムに関するメンタルモデルを作るのに苦労するもんなんですよね。そんなとき、メタファーが果たしてくれる役割ってなかなか馬鹿にしたもんじゃないと思うんです。

でも、メタファー中心デザインの功罪の罪のほうを明らかにしつつ、イディオム中心デザインの効用を説いていくアラン・クーパーと About Face 3 のみなさんのお手並みはやっぱり鮮かだなあとも思うんですよね。

で、悶々と考えてみたところ、インタラクションデザインにおけるメタファーの使いどころにはどうも３つくらいの水準があって、クーパーはその全てに否定的になっているわけじゃないんじゃないかなってだんだん思えてきたんです。

一口にメタファーなんつっても、これはちゃんと分けてかんがえないとって。なんでもそうだけど、悶々としちゃうのは、いろいろごっちゃにしちゃうからなんですよね。

というわけで、ばっさり分けてみました。

(1) 利用価値に関するメタファー

かんたんに言えば、一体これは何？何の役に立つの？という問いに答えるメタファーですね。

これは〜のようで、あるいは〜みたいで、そのくせ〜に似てて、そうかと思うと〜風なところもあって、いわば〜でって、一生懸命何かに喩えて理解しようとすること。

それは、仮に目に見えるインターフェースから一切のビジュアルメタファーを排除しても、その働きを捉えるイメージとしてユーザーの心に生まれるし、また、残っていくもんじゃないでしょうか。

eXtreme Programmingでいうメタファーもこれでしょう。

この水準のメタファーは、今ノートをつけている Part 2 Chapter 13 「メタファー、イディオム、アフォーダンス」で取り上げられているやつとはちょっと違いますよね。むしろ、Part 1 で説かれるゴールダイレクテッドデザインと密接に関わるもんでしょう。

今ノートをつけているのは、

(2) 操作手順に関するメタファー

こっちです。端的に言えば、どう使えばいいのか？という問に答えるメタファーですね。

ユーザーが直感的に操作できるようにするための便宜として考えられたなんらかの視覚的な表現を伴うメタファー。フロッピーで保存、ゴミ箱で削除ってね。

クーパーはこれを取り上げて、インタラクションの学習を効率化するための手口としては不確かだって言ってるんですよね。この水準では、誰がどう勘違いするかもわからないようなメタファーに頼るより、その気になれば誰でもかんたんに学習できるような、シンプルで一貫性のあるイディオムを中心にインタラクションを考えたほうがいいよって。

なぜなら ... それは、前のノートにさんざん書き散らかした通りです。

じゃあ、そのイディオムってのはいったいどんなもんなんだって話に自然になっていくわけですけれども、それはまた今度ってことで。ただ、先にひとつだけ言っておくと、イディオムがまたこれ、別の水準のメタファーに大きく依存するんですよね。

それが、次のやつで。

(3) 入力方法に関するメタファー

たとえばクリッカブル、ドラッガブルであることを示唆するために物理的な形状や運動モデルのメタファーが使われますね。あるいは、選択や移動のために方向、内外、重なりなどの空間認知的なメタファーが使われます。もう、ぼくらには当たり前過ぎてそれがメタファーだなんて考えづらいくらいですけどね。

でもこういうのみんな、物理的な世界で慣れ親しんでいるモノの扱い方、つかめそうだからつかみ、つまめそうだからつまむ、いわゆるノーマンのアフォーダンスの喩えなわけです。

クーパーは、こうしたデジタルメディア上のアフォーダンスの有用性を十分認めつつ(それらはイディオムの基礎にもなります)、しかし、それはあくまでも仮想的なものなので、現実のアフォーダンスと違ってかんたんにユーザーを裏切ることもできちゃうから、せいぜいみんな気をつけようぜ、なんて言ってます。

以上です。

と、まあ、やっとこれでね、自分的には心置きなくイディオムに進める準備が整いましたって感じです。

ところで、イディオムってつまり慣用句ってことですけど、慣用化した比喩のことを死喩っていうんですよね。デッドメタファーです。喩え喩えられる関係が持っていた豊かさはみんな擦り切れちゃって、もう本来の意味なんてどうでもよく、たとえば、いまや誰も知らない骨董的な記憶媒体のイメージがファイル保存の記号として生きのびていくような死喩の旅。

でもね、すべてのメタファーがそうしてイディオム化していくわけでもないのです。きっと。

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 追記)

不確かなメタファー

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 は言うんです。

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

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