もしもボックスの操作インターフェースが従っている電話メタファーは、ダジャレ好きの開発者による気まぐれなデザインではけっしてない。ユーザーは、受話器を取り上げ、呼び出し音を聞きながら"相手"が電話に出るのをしばらく待ち、しかるのちに、途方もなく独善的な願望の実現を口頭で"依頼"しなくてはならない。また、そうして望み通りに作り変えられた状況が、思わぬ方向へ展開していってしまうことに恐れをなして依頼を取り消したくなった場合も同様である。この一連の操作プロセスは、ユーザーのゴールに対しては余計な、課税的なもののように見えるが、実は、道具の性質が要請する、インタラクションデザイン上のある重要な配慮の実装として採用されたものに違いない。電話メタファーを通じて、ユーザーの行為は、自らによる世界の操作ではなく、世界を操作できる何者かへの依頼に変換されてしまう。もしもの世界は、ゴールではなく、一種の贈与として実現される(もしもボックスは対価を求めない)。ユーザーは、新しい世界を、ある種の負い目とともに受け取らなくてはならない羽目に嵌められているのだ。この負い目は、ユーザーに次の依頼をためらわせるかも知れない(電話メタファーのインターフェースは操作の中断のチャンスにあふれている！)。あるいは、次の依頼の内容をやや控えめにさせるかも知れない(受話器の向こうで聞き返したりすれば、さらに効果はてきめんだろう)。つまりこれは、ユーザーの心理に働きかけて、この道具の濫用を防ごうとするデザインなのだ。ラー油が一度にドバッといかないように注ぎ口の形状を工夫することにも似た、一種のフールプルーフだが、ラー油の例やその他の普通の意味でのフールプルーフの仕掛けと異なるのは、インターフェースの形態や操作手順にではなく、操作を通じて期待されるユーザーの認知主体としての変容をプルーフとして活用しようとする点にある。いわば、クーパーのポスチュア論の水準で、ヒューマンエラーの制御になんらかの好ましい影響を与えようとする試みであるといえる。
このように、手の込んだ仕掛けが考えられなければならないのは、(私にはそのメカニズムを理解し説明する能力はないのだが、おそらく、)もしもボックスが、恐ろしく危険な道具であるからだろう。ユーザーの心身にとっても、この世界にとっても、濫用は禁物なのである。
そしてまた、それほどに、電話でものを頼むのは、じつに面倒なことなのである。
2011年8月19日金曜日
2011年7月6日水曜日
青葉台式 Multiple Toggle スイッチ
ON/OFF を切り替えるスイッチを Toggle スイッチといいます。
Toggle スイッチの数が増えてくると、関連性の強いもの同士をグループにまとめ、グループを反映したレイアウトに整理してスイッチを並べたくなるでしょう。
いったんそうしてしまうと、グループのスイッチを一括して切り替えるためのスイッチがあってもいいはずだ、と、なかば直感的に、あたらしい大きなスイッチの存在が要請されるようになります。
このように、Toggle スイッチが複数個あって、いくつかのグループに別れているとき、グループに属するスイッチの ON/OFF を一括して切り替えるスイッチを、いまここで「Multiple Toggle スイッチ」と呼ぶことにします。
Multiple Toggle スイッチの存在は極めて自然にみえるのですが、いざ実装する段になると、その振る舞いのすべてを直感的に決定することが難しいことに気づきます。
グループのメンバーの状態がすべて OFF のとき、Multiple Toggle スイッチですべてを ON に切り替えることは直感的です。
その反対も然りです。グループのメンバーの状態がすべて ON のとき、Multiple Toggle スイッチですべてを OFF に切り替えることも直感的です。
問題は、個々のメンバーの状態がばらばらのときです。
Multiple Toggle スイッチで、
1. すべてを ON にすべきでしょうか？
2. それとも OFF にすべきでしょうか？
3. いや、すべてのスイッチについて一方から他方の状態に切り替えるべきでしょうか？
4. あるいは、Multiple Toggle スイッチも ON/OFF の状態を持ち、Multiple Toggle スイッチの新しい状態に合わせてメンバーの状態を切り替えるべきでしょうか？
思いつくままに、これくらいの選択肢を挙げられますが、よくみると、ひとつだけ異質なものが含まれています。3. です。
ほかの 3 つの選択肢はいずれも、すべてのメンバーを ON または OFF に揃えるためのスイッチです。3. だけがいわば、全体の状態を反転するためのスイッチです。
揃えるのか、反転させるのか。この違いは、メンバーのすべてが ON または OFF の場合の操作では明らかになりません。
個々のメンバーの状態がばらばらのとき、Multiple Toggle スイッチで次にどのような状態を求めるかという問いの下ではじめて明らかになります。
Toggle スイッチを目の前にした人が、実際にいくつかの Toggle スイッチを切り替えた後で、ふと、グループ全体に影響を及ぼしそうな 大きな Toggle スイッチに目を止めたとき、いったいどちらの機能を期待するかは、利用コンテクストによります。
そして、反転こそが自然であるようなケースなら、Multiple Toggle スイッチの振る舞いも、たんなる Toggle スイッチと同様に、直感的に決定することができます。
したがって問題になるのは、個々のメンバーの状態がばらばらで、なおかつ、Multiple Toggle スイッチに、グループのメンバーの状態を揃えるための機能が期待されるときです。
すなわち、グループを実体的に捉え、グループ自体の ON / OFF を切り替えるためのスイッチとして考えた場合です。
このとき、Multiple Toggle スイッチについてのユーザーの直感はきっと当たったり外れたりするようになります。Multiple Toggle スイッチの操作によってメンバーの状態は ON に揃うのか、OFFに揃うのか。
必ずしも直感に従うことを保証できない操作については、ルールの予測と学習によって判断を補うことができるように配慮していく必要があります。
ただ、いかなる配慮を加えるとしても、そのベースが 1. 2. ではいかにも乱暴で、4. こそが周到であるようにみえるかもしれません。
しかし、4. には、直感に従わないというよりも、直感に反するところがあります。
いったん Multiple Toggle ボタンを ON にした後、グループのすべてのメンバーを次々に OFF にしていきます。
すべてのメンバーを OFF に切り替えたにも関わらず、Multiple Toggle スイッチが ON のままであり続けるのは不自然です。この状態で Multiple Toggle スイッチを OFF に切り替えても実質的には何も起こったことになりません。
この問題を回避するためには、最後まで ON だったメンバーが OFF に切り替わるのを察知して、Multiple Toggle スイッチの状態もOFF に切り替えるといったルールを導入し、ユーザーにも充分に認知してもらう必要があります。
すると、1. 2. を合わせて次のようなルールを導入した場合と、ほとんど変わらなくなります。
Multiple Toggle スイッチで、
・すべてのメンバーが ON のとき、すべてのメンバーを OFF にする。
・すべてのメンバーが ON ではないとき、すべてのメンバーを ON にする。
この、1. + 2. + ルールと、4. + ルールを比較すると、メンバーの状態を OFF に揃えたいとき、4. + ルールのほうが有利です。
4. + ルールでは一手で済むケースがありえますが、1. + 2. + ルールでは、必ずいったん ON に揃えてから OFF に揃える必要があります。
しかし、一手で済むかどうかが確率的であるのは、充分なフィードバックがあるとしてもストレスです。一手の操作にかかる物理心理両面のコストが充分に小さければ、常に二手を要すると決まっていたほうが気持ちがいいでしょう。
1. + 2. + ルールは、一見、冗長な操作を強いるようですが、総合的にみて、4. + ルールよりも、はるかに"直感的"に映るはずです。
ところで、1. + 2. + ルールには、バリエーションが存在します。ルールとして挙げた 2 項目のうち、
・すべてのメンバーが ON ではないとき、すべてのメンバーを ON にする。
この項目を、
・すべてのメンバーが ON ではないとき、すべてのメンバーを OFF にする。
に入れ替えた場合です。
つまり、ばらばらのメンバーの状態をまず ON に揃えるか、あるいは OFF に揃えるかということです。
しかし、最初のスイッチで OFF に揃えると、グループのリセットボタンのように勘違いされる恐れがあります。利用コンテクストからみてどちらにも決めかねる場合は、ぜひ ON にすべきです。第一そのほうが景気がいいでしょう。
というわけで、この方式による Multiple Toggle スイッチのデザインを、日本の東京都目黒区青葉台でそう決めつけたことにちなんで「青葉台式 Multiple Toggle スイッチ」と呼ぶことにします。以後、画面仕様書では一本引き出し線を引っ張って、青葉台式、と断るだけです。
Toggle スイッチの数が増えてくると、関連性の強いもの同士をグループにまとめ、グループを反映したレイアウトに整理してスイッチを並べたくなるでしょう。
いったんそうしてしまうと、グループのスイッチを一括して切り替えるためのスイッチがあってもいいはずだ、と、なかば直感的に、あたらしい大きなスイッチの存在が要請されるようになります。
このように、Toggle スイッチが複数個あって、いくつかのグループに別れているとき、グループに属するスイッチの ON/OFF を一括して切り替えるスイッチを、いまここで「Multiple Toggle スイッチ」と呼ぶことにします。
Multiple Toggle スイッチの存在は極めて自然にみえるのですが、いざ実装する段になると、その振る舞いのすべてを直感的に決定することが難しいことに気づきます。
グループのメンバーの状態がすべて OFF のとき、Multiple Toggle スイッチですべてを ON に切り替えることは直感的です。
その反対も然りです。グループのメンバーの状態がすべて ON のとき、Multiple Toggle スイッチですべてを OFF に切り替えることも直感的です。
問題は、個々のメンバーの状態がばらばらのときです。
Multiple Toggle スイッチで、
1. すべてを ON にすべきでしょうか？
2. それとも OFF にすべきでしょうか？
3. いや、すべてのスイッチについて一方から他方の状態に切り替えるべきでしょうか？
4. あるいは、Multiple Toggle スイッチも ON/OFF の状態を持ち、Multiple Toggle スイッチの新しい状態に合わせてメンバーの状態を切り替えるべきでしょうか？
思いつくままに、これくらいの選択肢を挙げられますが、よくみると、ひとつだけ異質なものが含まれています。3. です。
ほかの 3 つの選択肢はいずれも、すべてのメンバーを ON または OFF に揃えるためのスイッチです。3. だけがいわば、全体の状態を反転するためのスイッチです。
揃えるのか、反転させるのか。この違いは、メンバーのすべてが ON または OFF の場合の操作では明らかになりません。
個々のメンバーの状態がばらばらのとき、Multiple Toggle スイッチで次にどのような状態を求めるかという問いの下ではじめて明らかになります。
Toggle スイッチを目の前にした人が、実際にいくつかの Toggle スイッチを切り替えた後で、ふと、グループ全体に影響を及ぼしそうな 大きな Toggle スイッチに目を止めたとき、いったいどちらの機能を期待するかは、利用コンテクストによります。
そして、反転こそが自然であるようなケースなら、Multiple Toggle スイッチの振る舞いも、たんなる Toggle スイッチと同様に、直感的に決定することができます。
したがって問題になるのは、個々のメンバーの状態がばらばらで、なおかつ、Multiple Toggle スイッチに、グループのメンバーの状態を揃えるための機能が期待されるときです。
すなわち、グループを実体的に捉え、グループ自体の ON / OFF を切り替えるためのスイッチとして考えた場合です。
このとき、Multiple Toggle スイッチについてのユーザーの直感はきっと当たったり外れたりするようになります。Multiple Toggle スイッチの操作によってメンバーの状態は ON に揃うのか、OFFに揃うのか。
必ずしも直感に従うことを保証できない操作については、ルールの予測と学習によって判断を補うことができるように配慮していく必要があります。
ただ、いかなる配慮を加えるとしても、そのベースが 1. 2. ではいかにも乱暴で、4. こそが周到であるようにみえるかもしれません。
しかし、4. には、直感に従わないというよりも、直感に反するところがあります。
いったん Multiple Toggle ボタンを ON にした後、グループのすべてのメンバーを次々に OFF にしていきます。
すべてのメンバーを OFF に切り替えたにも関わらず、Multiple Toggle スイッチが ON のままであり続けるのは不自然です。この状態で Multiple Toggle スイッチを OFF に切り替えても実質的には何も起こったことになりません。
この問題を回避するためには、最後まで ON だったメンバーが OFF に切り替わるのを察知して、Multiple Toggle スイッチの状態もOFF に切り替えるといったルールを導入し、ユーザーにも充分に認知してもらう必要があります。
すると、1. 2. を合わせて次のようなルールを導入した場合と、ほとんど変わらなくなります。
Multiple Toggle スイッチで、
・すべてのメンバーが ON のとき、すべてのメンバーを OFF にする。
・すべてのメンバーが ON ではないとき、すべてのメンバーを ON にする。
この、1. + 2. + ルールと、4. + ルールを比較すると、メンバーの状態を OFF に揃えたいとき、4. + ルールのほうが有利です。
4. + ルールでは一手で済むケースがありえますが、1. + 2. + ルールでは、必ずいったん ON に揃えてから OFF に揃える必要があります。
しかし、一手で済むかどうかが確率的であるのは、充分なフィードバックがあるとしてもストレスです。一手の操作にかかる物理心理両面のコストが充分に小さければ、常に二手を要すると決まっていたほうが気持ちがいいでしょう。
1. + 2. + ルールは、一見、冗長な操作を強いるようですが、総合的にみて、4. + ルールよりも、はるかに"直感的"に映るはずです。
ところで、1. + 2. + ルールには、バリエーションが存在します。ルールとして挙げた 2 項目のうち、
・すべてのメンバーが ON ではないとき、すべてのメンバーを ON にする。
この項目を、
・すべてのメンバーが ON ではないとき、すべてのメンバーを OFF にする。
に入れ替えた場合です。
つまり、ばらばらのメンバーの状態をまず ON に揃えるか、あるいは OFF に揃えるかということです。
しかし、最初のスイッチで OFF に揃えると、グループのリセットボタンのように勘違いされる恐れがあります。利用コンテクストからみてどちらにも決めかねる場合は、ぜひ ON にすべきです。第一そのほうが景気がいいでしょう。
というわけで、この方式による Multiple Toggle スイッチのデザインを、日本の東京都目黒区青葉台でそう決めつけたことにちなんで「青葉台式 Multiple Toggle スイッチ」と呼ぶことにします。以後、画面仕様書では一本引き出し線を引っ張って、青葉台式、と断るだけです。
2011年2月22日火曜日
クーパーのデジタルスープ
About Face 3 読書ノート。その28。
インタラクションデザインのイディオム読本ともいえそうな Part 3 の最初のテーマは、ファインダビリティについてです。
副題は、「データをもっと簡単に手に入れるために」。インタラクションデザインの要諦がユーザーのフロー状態をいち早く作って、以後、その邪魔をなるべくしないことだとすれば、このあいだのアレ、アレどこいったっけ？でいたずらに時間を潰すハメになるあの状況、人の心にせっかく芽生えつつあったなけなしの闘志をあれよあれよと吸い込んでいく、あの魔のファイトイーターが支配する暗黒の時間帯をこそ、まずはじめに打ち払うべきです。
しかし、なんだってわれわれはあんな悪魔にわりとちょくちょく魅入られてしまうのでしょう？ それは、情報を格納するためのシステムと検索するためのシステムが未分化であるためだ、とAbout Face 3 は喝破しています。
物理世界では、たいてい、整理整頓して上手に収納することが、高いファインダビリティを実現するためのコツ、ということになってますね。つまり、格納即検索システムというわけです。自分の部屋から図書館まで結局みんなこれです。
デジタルの世界でも、長い間、物理世界で学んだこのコツに忠実でした。実際、取り扱う情報量が小さいうちは、美しいフォルダ階層や合理的な命名規則を設けたりして、情報の格納をシステマティックに行うことが、情報の検索しやすさにつながっていました。しかし、それは、どこに何をしまったのか覚えていられる間だけの話です。
そりゃ、コンピュータはいつまでだって、いくらだって覚えていられるでしょう。しかし人間はそうはいきません。デジタル世界では、格納=検索システムという素朴なモデルだけではやってられない臨界点が人間の側にやってきます。
ところが、コンピュータのやつら、自分は大丈夫だからってあんまり熱心にこの問題に取り組もうとしてこなかったみたいなんだよね。いろいろ工夫するための条件はずっと以前から整っていたのにって、ここでいつもの About Face 節が炸裂するわけです。
About Face 3 によれば、格納システムから分離することによって見い出される"純"検索システムは、およそ次の三通りのアプローチのいずれかとります。
・しまった場所(path)で探す。
・名前(id)で探す。
・属性(attribute)で探す。
物理的な世界からの流れでずーっとやってきた、格納システムと表裏一体のメソッドが最初のやつですね。
これが悪いってわけではないです。むしろ、探したいものの量がそれほど多くはなく、深めの階層をたどるような真似をせずに各個にフラットにアクセスできるうちは、結局これがベストプラクティスだと思います。
なにしろ、あるべきものがあるはずのところに必ずあって、いつでもさっと手を伸ばせるっていうのが、こっちのフロー状態にとっては最高なんですから。
二番目は、デジタルならでは、ということになりますね。デジタルの世界では、ユーザーがつけた/つけない、意識する/しないに関わらず、たいがいのものに個体識別子がついてます。そしてどんなものでもたいていの場合、名前で呼び出すことができます。自分がつけた名前であればなんとなく覚えている可能性も大きいわけで、どこにしまったか忘れてしまったら、そいつの名前を呼んでみる。すると、どこからともなくはーい！って。おお、そこにいたか。なんて、こんなこと、物理的な世界ではあんまり期待できません。
しかし、人間にとっての、二大ド忘れ対象が、しまった場所と名前じゃないですか？
というわけで、一番、二番だけじゃすまなくて、三番目のアプローチがどうしても必要になってくるわけですね。ブタにしろヤギにしろ、だいたい三番目に出てくるやつがケリをつけてくれます。
三番目は、ほら、あれ、なんだっけ、えーとほら、あー、ここまででかかってんだけど、というときのあれです。思い出したいもののいろんな特徴を挙げて、あるいは、それと自分がどう関わってきたのかを断片的に物語って、自分の代わりにちゃっかり周りの人に思い出してもらおうという他力本願。これを、デジタルの世界でもやりたい。いや、物量的に手に負えなくなりがちなデジタルの世界だからこそやりたい。この場合の他力はおいおまえだコンピュータ、しっかりたのんだぞ。
だけど、と、ここで突然 About Face 3、リレーショナルデータベースじゃ人間の自由な魂のエートホラを十全に受け止めることは難しいよね、とかなんとか言い出すんです。なに、いきなり実装レベルの話？ってかんじなんですが、要するにすべてがあらかじめ行われた静的な定義に基づくようなRDB的発想では、属性ベースの検索に対しては窮屈になってくる場合があるよねってことです。
たとえば、
・将来の検索に備えた属性のセットを考えるのはとても難しいし。
・考えることができたとしても、それにユーザーの入力を従わせることはもっと難しいし。
じゃあどうすれば、ってしょぼくれたぼくらに、クーパーおじさんがそっとさし出してくれたのが、鍋から吹き出しそうな、あつあつのデジタルスープだったのです。
引用します。
レコードを具として入れられるデジタルスープのような格納システムを想像してみよう。このスープは、サイズ、長さ、タイプ、内容がなんであれ、放り込まれた任意のレコードを受け入れる。
引用終了。
こりゃスープというか、闇鍋ですね。あるいは、ジャイアンシチューか。うまいかおいしいかどっちだ？と聞かれて、間髪入れずスゴイ！と答えたスネ夫の一瞬の機転が見事だったあのシチュー。いや、あの漫画をもち出すなら、四次元ポケットって言ったほうがわかりやすいですね。なんでも入れられて、なんでも一発で取り出せちゃう。
で、でもですね、取り出せるのは取り出したいものがわかってるときだけなんですよ。これはあくまでも格納システムですからね。とにかくなんでも入れられるスゴイ格納システム。
引用つづき。
レコードが投入時されると、格納システムは、レコードを検索するときに使えるトークンを返す。ユーザーがしなければならないのは、そのトークンをスープに戻すことだ。すると、スープはたちどころにレコードを返してくる。
引用つづき終了。
という次第で。たとえば、引き出しとか棚のメタファーで説明できるシステムがあるとすると、それは、格納即検索システムということになりますね。うまくしまえば、うまく取り出せる。でも、入れられるもののカタチやなんかに制約が出てくるかもしれない。
スープにはなんでも放り込めるけど、でもスープをいくら覗き込んでも放り込んだものがどのへんに沈んでいるかはわからない。ただ、引換券を渡せばちゃんと取り出してくれるだけ。
で、それなら、この引換券を検索するシステムを別に考えたらどうだ、と、こう話は展開するわけです。そして重要なのが、まさにここ。別に考えるということは、つまり検索システムが格納システムのあり方に必ずしも縛られる必要はないということです。引換券だけでつながってればいい。そして思う存分、人間のエートホラにつきあうシステムを考えればいい。
たとえば、どんなアプリで作成されたデータか、作成日、最終更新日、最終閲覧日はいつだったか、名前はどんな文字列ではじまるか、誰に編集、閲覧、メール、印刷されたか、どれくらい編集、閲覧、メール、印刷されてきたか、なんてデータのアバウトネスや利用状況を、データの属性としてどんどん記録して、それらの属性で引換券を検索するわけですね。ヒットしたらその引換券をスープに渡してデータを引き出してもらう。あるいは、ユーザーの任意で、検索用の属性を好きなように加えられるようにしてもいいですよね。
って、こういう手口、すでにだいぶお馴染みになってきましたね。Mac OS の Spotlight とか。
だいたい、Web がそうですもんね。スープ=Web、トークン=URL、検索システム=サーチエンジン、SBM、フィードリーダー、URL短縮サービス、etc ...
あるいは、CouchDBみたいなドキュメント志向データベースとかもこの手合いじゃないでしょうか。Webは巨大なデータベースとか言いますけど、DODBって、あるドメインに特化したミニWebシステム、Domain Specific Web を構築する手法って考えられると思うんですよね。専用であるがゆえのメタ情報の詳細化とボディのセマンティックな構造化を進めてですね、言ってみれば、スクレイピング天国を作るわけでしょう。CouchDB のビューって、要は、スクレイピングですからね。
そして、スープって喩えはどうなのっていろいろ検索してみたら、この発想、どうやら、Apple の Newton 発みたいですね。ファイルシステムがもうまるっきりスープなんだそうで、その名も Soup ですよ。すごかったんですね、Newton。聞けば聞くほど。なんか当時、ぜんぜん知らなくって損しました。タイトル、「ニュートンのデジタルスープ」にしたほうがよかったかな。
とまあ、実装はいろいろあるわけですけれども、問題は、この話がいったいまたどうして、イディオム読本の冒頭を飾っているかってことですよ。いきなり、データベース方面に話を広げちゃって。
でも、ポイントは、一貫して、格納と検索の分離ってところにありましたね。
そもそも、プリミティブ -> コンパウンド -> イディオム -> システム というインタラクションの言語的な階層構造でいえば、データを格納する、格納したデータを取り出す、なんていうのは、まさにイディオム層にあたるわけですね。
そして、いったんイディオム的に見てしまえば、これらが、それぞれ独立した利用コンテクストとニーズに従うものであることはむしろ明白といっていいくらいです。格納はその場でポン。取り出しは最小限のエートホラでドンピシャ。それぞれそんなふうに最適化したいな。なんてね。
しかし、それが長い間、未分化であったのは、インタラクションのデザインが、物理的世界の習いや実装モデルの制約に無自覚に従っていたからなんじゃないかと。コンピュータの野郎がさぼってたっていうのは、まあ、冗談で。
こういうとき、意識してイディオマティックたらんとすることが、こうした蒙昧を啓くのに役立つわけです。そうしてむしろ、こちらから実装モデルの進化を促すくらいの、あるいは、こちらから物理的世界の習いにいくらか影響を与えるくらいの、そういう強い意気を持ってデザインに臨みたい。ね。ちょうど Newton がそうだったように。
といった含意があっての、Part3、デジタルスープはじまり。と見ましたが、如何。
インタラクションデザインのイディオム読本ともいえそうな Part 3 の最初のテーマは、ファインダビリティについてです。
副題は、「データをもっと簡単に手に入れるために」。インタラクションデザインの要諦がユーザーのフロー状態をいち早く作って、以後、その邪魔をなるべくしないことだとすれば、このあいだのアレ、アレどこいったっけ？でいたずらに時間を潰すハメになるあの状況、人の心にせっかく芽生えつつあったなけなしの闘志をあれよあれよと吸い込んでいく、あの魔のファイトイーターが支配する暗黒の時間帯をこそ、まずはじめに打ち払うべきです。
しかし、なんだってわれわれはあんな悪魔にわりとちょくちょく魅入られてしまうのでしょう？ それは、情報を格納するためのシステムと検索するためのシステムが未分化であるためだ、とAbout Face 3 は喝破しています。
物理世界では、たいてい、整理整頓して上手に収納することが、高いファインダビリティを実現するためのコツ、ということになってますね。つまり、格納即検索システムというわけです。自分の部屋から図書館まで結局みんなこれです。
デジタルの世界でも、長い間、物理世界で学んだこのコツに忠実でした。実際、取り扱う情報量が小さいうちは、美しいフォルダ階層や合理的な命名規則を設けたりして、情報の格納をシステマティックに行うことが、情報の検索しやすさにつながっていました。しかし、それは、どこに何をしまったのか覚えていられる間だけの話です。
そりゃ、コンピュータはいつまでだって、いくらだって覚えていられるでしょう。しかし人間はそうはいきません。デジタル世界では、格納=検索システムという素朴なモデルだけではやってられない臨界点が人間の側にやってきます。
ところが、コンピュータのやつら、自分は大丈夫だからってあんまり熱心にこの問題に取り組もうとしてこなかったみたいなんだよね。いろいろ工夫するための条件はずっと以前から整っていたのにって、ここでいつもの About Face 節が炸裂するわけです。
About Face 3 によれば、格納システムから分離することによって見い出される"純"検索システムは、およそ次の三通りのアプローチのいずれかとります。
・しまった場所(path)で探す。
・名前(id)で探す。
・属性(attribute)で探す。
物理的な世界からの流れでずーっとやってきた、格納システムと表裏一体のメソッドが最初のやつですね。
これが悪いってわけではないです。むしろ、探したいものの量がそれほど多くはなく、深めの階層をたどるような真似をせずに各個にフラットにアクセスできるうちは、結局これがベストプラクティスだと思います。
なにしろ、あるべきものがあるはずのところに必ずあって、いつでもさっと手を伸ばせるっていうのが、こっちのフロー状態にとっては最高なんですから。
二番目は、デジタルならでは、ということになりますね。デジタルの世界では、ユーザーがつけた/つけない、意識する/しないに関わらず、たいがいのものに個体識別子がついてます。そしてどんなものでもたいていの場合、名前で呼び出すことができます。自分がつけた名前であればなんとなく覚えている可能性も大きいわけで、どこにしまったか忘れてしまったら、そいつの名前を呼んでみる。すると、どこからともなくはーい！って。おお、そこにいたか。なんて、こんなこと、物理的な世界ではあんまり期待できません。
しかし、人間にとっての、二大ド忘れ対象が、しまった場所と名前じゃないですか？
というわけで、一番、二番だけじゃすまなくて、三番目のアプローチがどうしても必要になってくるわけですね。ブタにしろヤギにしろ、だいたい三番目に出てくるやつがケリをつけてくれます。
三番目は、ほら、あれ、なんだっけ、えーとほら、あー、ここまででかかってんだけど、というときのあれです。思い出したいもののいろんな特徴を挙げて、あるいは、それと自分がどう関わってきたのかを断片的に物語って、自分の代わりにちゃっかり周りの人に思い出してもらおうという他力本願。これを、デジタルの世界でもやりたい。いや、物量的に手に負えなくなりがちなデジタルの世界だからこそやりたい。この場合の他力はおいおまえだコンピュータ、しっかりたのんだぞ。
だけど、と、ここで突然 About Face 3、リレーショナルデータベースじゃ人間の自由な魂のエートホラを十全に受け止めることは難しいよね、とかなんとか言い出すんです。なに、いきなり実装レベルの話？ってかんじなんですが、要するにすべてがあらかじめ行われた静的な定義に基づくようなRDB的発想では、属性ベースの検索に対しては窮屈になってくる場合があるよねってことです。
たとえば、
・将来の検索に備えた属性のセットを考えるのはとても難しいし。
・考えることができたとしても、それにユーザーの入力を従わせることはもっと難しいし。
じゃあどうすれば、ってしょぼくれたぼくらに、クーパーおじさんがそっとさし出してくれたのが、鍋から吹き出しそうな、あつあつのデジタルスープだったのです。
引用します。
レコードを具として入れられるデジタルスープのような格納システムを想像してみよう。このスープは、サイズ、長さ、タイプ、内容がなんであれ、放り込まれた任意のレコードを受け入れる。
引用終了。
こりゃスープというか、闇鍋ですね。あるいは、ジャイアンシチューか。うまいかおいしいかどっちだ？と聞かれて、間髪入れずスゴイ！と答えたスネ夫の一瞬の機転が見事だったあのシチュー。いや、あの漫画をもち出すなら、四次元ポケットって言ったほうがわかりやすいですね。なんでも入れられて、なんでも一発で取り出せちゃう。
で、でもですね、取り出せるのは取り出したいものがわかってるときだけなんですよ。これはあくまでも格納システムですからね。とにかくなんでも入れられるスゴイ格納システム。
引用つづき。
レコードが投入時されると、格納システムは、レコードを検索するときに使えるトークンを返す。ユーザーがしなければならないのは、そのトークンをスープに戻すことだ。すると、スープはたちどころにレコードを返してくる。
引用つづき終了。
という次第で。たとえば、引き出しとか棚のメタファーで説明できるシステムがあるとすると、それは、格納即検索システムということになりますね。うまくしまえば、うまく取り出せる。でも、入れられるもののカタチやなんかに制約が出てくるかもしれない。
スープにはなんでも放り込めるけど、でもスープをいくら覗き込んでも放り込んだものがどのへんに沈んでいるかはわからない。ただ、引換券を渡せばちゃんと取り出してくれるだけ。
で、それなら、この引換券を検索するシステムを別に考えたらどうだ、と、こう話は展開するわけです。そして重要なのが、まさにここ。別に考えるということは、つまり検索システムが格納システムのあり方に必ずしも縛られる必要はないということです。引換券だけでつながってればいい。そして思う存分、人間のエートホラにつきあうシステムを考えればいい。
たとえば、どんなアプリで作成されたデータか、作成日、最終更新日、最終閲覧日はいつだったか、名前はどんな文字列ではじまるか、誰に編集、閲覧、メール、印刷されたか、どれくらい編集、閲覧、メール、印刷されてきたか、なんてデータのアバウトネスや利用状況を、データの属性としてどんどん記録して、それらの属性で引換券を検索するわけですね。ヒットしたらその引換券をスープに渡してデータを引き出してもらう。あるいは、ユーザーの任意で、検索用の属性を好きなように加えられるようにしてもいいですよね。
って、こういう手口、すでにだいぶお馴染みになってきましたね。Mac OS の Spotlight とか。
だいたい、Web がそうですもんね。スープ=Web、トークン=URL、検索システム=サーチエンジン、SBM、フィードリーダー、URL短縮サービス、etc ...
あるいは、CouchDBみたいなドキュメント志向データベースとかもこの手合いじゃないでしょうか。Webは巨大なデータベースとか言いますけど、DODBって、あるドメインに特化したミニWebシステム、Domain Specific Web を構築する手法って考えられると思うんですよね。専用であるがゆえのメタ情報の詳細化とボディのセマンティックな構造化を進めてですね、言ってみれば、スクレイピング天国を作るわけでしょう。CouchDB のビューって、要は、スクレイピングですからね。
そして、スープって喩えはどうなのっていろいろ検索してみたら、この発想、どうやら、Apple の Newton 発みたいですね。ファイルシステムがもうまるっきりスープなんだそうで、その名も Soup ですよ。すごかったんですね、Newton。聞けば聞くほど。なんか当時、ぜんぜん知らなくって損しました。タイトル、「ニュートンのデジタルスープ」にしたほうがよかったかな。
とまあ、実装はいろいろあるわけですけれども、問題は、この話がいったいまたどうして、イディオム読本の冒頭を飾っているかってことですよ。いきなり、データベース方面に話を広げちゃって。
でも、ポイントは、一貫して、格納と検索の分離ってところにありましたね。
そもそも、プリミティブ -> コンパウンド -> イディオム -> システム というインタラクションの言語的な階層構造でいえば、データを格納する、格納したデータを取り出す、なんていうのは、まさにイディオム層にあたるわけですね。
そして、いったんイディオム的に見てしまえば、これらが、それぞれ独立した利用コンテクストとニーズに従うものであることはむしろ明白といっていいくらいです。格納はその場でポン。取り出しは最小限のエートホラでドンピシャ。それぞれそんなふうに最適化したいな。なんてね。
しかし、それが長い間、未分化であったのは、インタラクションのデザインが、物理的世界の習いや実装モデルの制約に無自覚に従っていたからなんじゃないかと。コンピュータの野郎がさぼってたっていうのは、まあ、冗談で。
こういうとき、意識してイディオマティックたらんとすることが、こうした蒙昧を啓くのに役立つわけです。そうしてむしろ、こちらから実装モデルの進化を促すくらいの、あるいは、こちらから物理的世界の習いにいくらか影響を与えるくらいの、そういう強い意気を持ってデザインに臨みたい。ね。ちょうど Newton がそうだったように。
といった含意があっての、Part3、デジタルスープはじまり。と見ましたが、如何。
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の可能性はさらに広がり、いよいよ凄味を増していくんじゃないの？
というとこらへんをめぐって、本来、「電子書籍」は夢見られるべきなんじゃないの？
なんて思いも込めながら作ってみたんですが、出来上がりに対して、思いのほうがちょっと生意気すぎましたね。
登録:
投稿 (Atom)