もしもボックスの操作インターフェースが従っている電話メタファーは、ダジャレ好きの開発者による気まぐれなデザインではけっしてない。ユーザーは、受話器を取り上げ、呼び出し音を聞きながら"相手"が電話に出るのをしばらく待ち、しかるのちに、途方もなく独善的な願望の実現を口頭で"依頼"しなくてはならない。また、そうして望み通りに作り変えられた状況が、思わぬ方向へ展開していってしまうことに恐れをなして依頼を取り消したくなった場合も同様である。この一連の操作プロセスは、ユーザーのゴールに対しては余計な、課税的なもののように見えるが、実は、道具の性質が要請する、インタラクションデザイン上のある重要な配慮の実装として採用されたものに違いない。電話メタファーを通じて、ユーザーの行為は、自らによる世界の操作ではなく、世界を操作できる何者かへの依頼に変換されてしまう。もしもの世界は、ゴールではなく、一種の贈与として実現される(もしもボックスは対価を求めない)。ユーザーは、新しい世界を、ある種の負い目とともに受け取らなくてはならない羽目に嵌められているのだ。この負い目は、ユーザーに次の依頼をためらわせるかも知れない(電話メタファーのインターフェースは操作の中断のチャンスにあふれている！)。あるいは、次の依頼の内容をやや控えめにさせるかも知れない(受話器の向こうで聞き返したりすれば、さらに効果はてきめんだろう)。つまりこれは、ユーザーの心理に働きかけて、この道具の濫用を防ごうとするデザインなのだ。ラー油が一度にドバッといかないように注ぎ口の形状を工夫することにも似た、一種のフールプルーフだが、ラー油の例やその他の普通の意味でのフールプルーフの仕掛けと異なるのは、インターフェースの形態や操作手順にではなく、操作を通じて期待されるユーザーの認知主体としての変容をプルーフとして活用しようとする点にある。いわば、クーパーのポスチュア論の水準で、ヒューマンエラーの制御になんらかの好ましい影響を与えようとする試みであるといえる。
このように、手の込んだ仕掛けが考えられなければならないのは、(私にはそのメカニズムを理解し説明する能力はないのだが、おそらく、)もしもボックスが、恐ろしく危険な道具であるからだろう。ユーザーの心身にとっても、この世界にとっても、濫用は禁物なのである。
そしてまた、それほどに、電話でものを頼むのは、じつに面倒なことなのである。
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、デジタルスープはじまり。と見ましたが、如何。
登録:
投稿 (Atom)