特集DraftPad/短期集中連載
D箱のアシスト事件
第3夜. OAuth するアシスト
そもそものはじまりは、この記事をみつけたことにありました。
How-to: Secure OAuth in JavaScript
これまでにも、いろいろと DraftPad アシストを作ってみたけど、一貫して、静的なファイルに記述した Javascript + HTML + CSS だけで完結するものばかりでした。
というのも、仕事でフロントエンドエンジニアの真似事のようなことはやりますが、サーバーサイドの Web アプリの開発に自分で手を出したことはなかったし、とても難しくて、自分でやれるようなことだとは思っていなかったからです。
その一方で、簡単なスクリプトを書いて、Dropbox の Public フォルダに配置すればすぐに使える、そういうカジュアルなスタイルが気に入っていました。負け惜しみじゃなく、DraftPad のアシストとしてなら、それで相当のことができるのです。
できないことのほうを挙げると、次の3つになると思います。
1. 他の人や他の利用環境とデータをシェアするために、サーバーサイドにデータを保存すること
2. クライアントサイドのシステムのリソースにアクセスすること
そして、
3. アプリケーションのみが知りうる情報を、アプリケーションの内部に秘密裡に保持すること
1. と 2. は、はじめから期待していないようなものだからいいんですが、口惜しいのは 3. です。3. ができたら、たとえば、OAuth ありきの API を使ったアシストも考えられるのにって。でも、ソースコードが 100% 誰にでも読めてしまう Javascript だけでは絶対に無理。
ところが、前掲の記事は、「でも YQL を使えば隠せるね。」と、こういうわけです。
YQL とは何か？ 一言でいえば、クライアントサイドからよそのドメインのフィードやAPI を利用するための、
・マッシュアップフィルター + JSONPラッパー
ということになります。が、この記事はさらに付け加えて、
・フィルター処理で使用する変数の値を、サーバーサイドに保持できるサービス
でもあることを示し、そして、ここに OAuth の Consumer Key や Consumer Secret を入れておけば、クライアントサイドで動く Javascript で、ちゃんとセキュアに OAuth アプリが作れるよ、と、実際に作り方までていねいにガイドしてくれていたのです。
あ、これだ！と、飛びつきましたよ。
最初に作ったのは、Tumblr にテキストをポストするアシストでした。「Save to Tumblr」 。実は、iPhone 版の Tumblr アプリのテキスト入力がアレなので、前々からせび欲しかったのです。
Save to Tumblr
すぐにできました。興奮しましたね。実用上の念願を果たせたことももちろんですけど、自分で OAuth するアシストを作れたことに。でも、でもですね ... 。
つづく。
2012年2月7日火曜日
2012年2月6日月曜日
D箱のアシスト事件 第2夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第2夜. Dropbox にセーブするアシスト
DraftPad のアシストシステムはとても強力です。特に、オンラインから内蔵 UIWebView に Javascript コードを読み込み、それで DraftPad 上のテキストを取り扱うことができる機構は、はっきりいって最強です。これさえあればなんでもできる(ような気になれる)。きっと DraftPad を Dropbox クライアントにすることもできるはず。たとえば ...
DraftPad に書きつけたテキストをちぎってとっておきたくなったら、Dropbox の適当なフォルダに、適当な名前をつけて放り込んでおく。
そして手元に戻したくなったら iPhone の 「iPhoneを検索」みたいなかんじでフォルダ名やファイル名の一部を入力して、さっと検索して読み込む。
... こんなアシストはどうでしょう？ Dropbox ならデスクトップのテキストエディタと DraftPad の間で同じテキストを共有して編集するなんてこともできるしね！
たとえ万が一、意図しない上書きとかをやっちまったとしても、DraftPad、Dropbox の双方にくそ丁寧な履歴が残ってるから絶対なんとかなるし。具体的な使い勝手はこんなかんじで ...
セーブするとき。
最後の行に保存先となる Dropbox のパスを書いておく。「/memo/Dropbox にセーブするアシスト」とかね。この状態でセーブ用のアシストを起動すると、一発で Dropbox の狙った場所にテキストが飛んでいく。
一方、Dropbox 上のテキストを DraftPad に読み込むとき。
オープン用のアシストを起動すると検索フォームが表示される。ここにフォルダ名やファイル名(の一部)を入力すると、マッチするフォルダとファイルが表示される。
フォルダをタップすると、そのフォルダに含まれるフォルダとファイルが表示される。そして、ファイルをタップするとその内容が DraftPad に読み込まれる。
DraftPad に読み込まれる際には、自動的に最後の行にパスがついてくるようになっているので、テキストを編集した後、何も考えずそのままセーブ用のアシストを起動すれば、Dropbox 上の元のテキストが更新される。
... こ、これは便利だ！
って、実はコレ、すでにぼくの手元で動いているのです。ここに掲載しているキャプチャ画像も実際に動作している画面のものです。便利なのは本当ですよ。
でもわけあって、公開はできないことになってしまいました。なんということでしょう。ぼくはこの先、1人ぼっちでよがるしかないのでしょうか ... 。
( ここで紹介しているアシストは、公式アシストの「Save to Dropbox」とは別物です。念のため。)
つづく。
D箱のアシスト事件
第2夜. Dropbox にセーブするアシスト
DraftPad のアシストシステムはとても強力です。特に、オンラインから内蔵 UIWebView に Javascript コードを読み込み、それで DraftPad 上のテキストを取り扱うことができる機構は、はっきりいって最強です。これさえあればなんでもできる(ような気になれる)。きっと DraftPad を Dropbox クライアントにすることもできるはず。たとえば ...
DraftPad に書きつけたテキストをちぎってとっておきたくなったら、Dropbox の適当なフォルダに、適当な名前をつけて放り込んでおく。
そして手元に戻したくなったら iPhone の 「iPhoneを検索」みたいなかんじでフォルダ名やファイル名の一部を入力して、さっと検索して読み込む。
... こんなアシストはどうでしょう？ Dropbox ならデスクトップのテキストエディタと DraftPad の間で同じテキストを共有して編集するなんてこともできるしね！
たとえ万が一、意図しない上書きとかをやっちまったとしても、DraftPad、Dropbox の双方にくそ丁寧な履歴が残ってるから絶対なんとかなるし。具体的な使い勝手はこんなかんじで ...
セーブするとき。
最後の行に保存先となる Dropbox のパスを書いておく。「/memo/Dropbox にセーブするアシスト」とかね。この状態でセーブ用のアシストを起動すると、一発で Dropbox の狙った場所にテキストが飛んでいく。
一方、Dropbox 上のテキストを DraftPad に読み込むとき。
オープン用のアシストを起動すると検索フォームが表示される。ここにフォルダ名やファイル名(の一部)を入力すると、マッチするフォルダとファイルが表示される。
フォルダをタップすると、そのフォルダに含まれるフォルダとファイルが表示される。そして、ファイルをタップするとその内容が DraftPad に読み込まれる。
DraftPad に読み込まれる際には、自動的に最後の行にパスがついてくるようになっているので、テキストを編集した後、何も考えずそのままセーブ用のアシストを起動すれば、Dropbox 上の元のテキストが更新される。
... こ、これは便利だ！
って、実はコレ、すでにぼくの手元で動いているのです。ここに掲載しているキャプチャ画像も実際に動作している画面のものです。便利なのは本当ですよ。
でもわけあって、公開はできないことになってしまいました。なんということでしょう。ぼくはこの先、1人ぼっちでよがるしかないのでしょうか ... 。
( ここで紹介しているアシストは、公式アシストの「Save to Dropbox」とは別物です。念のため。)
つづく。
2012年2月5日日曜日
D箱のアシスト事件 第1夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第1夜. DraftPad とセーブ
ファイルでもアプリでもない、あえて言うなら、永久に不滅の作業バッファ？ いや、DraftPad と呼ぶほかはない、テキストのヘイヴン。一枚の紙だから、New も Open もない。一枚の紙だけど、一種のタイムマシンでもあって、過去の好きな時点の状態にいつでも戻ることができる。だから、Save だっていらない。
それが DraftPad の哲学で、ぼくはその哲学がとても好きだ。好きだ、好きだ、好きなんだ。どうしようもなく好きなんだ。
それにひきかえ、どうだ。ファイルシステムだって？ すべてを「新規作成」し、「保存」し、「開く」世界。
いや、まあ、それもいいだろう。しかし、なんでもかんでも、いちいちその調子で押し通す必要はなかったんだ。むしろ、ほとんどのことは DraftPad 的に済ますことができたはずだ。すっかり騙されていた。
特に、セーブだなんてひどいじゃないか。
それは本当に、救い出すという意味だった。気取ったメタファーなんかじゃない。いつ消えてもおかしくないまぼろしのような作業バッファから、大切な成果を、もっと安全な場所に小まめに救い出しておく必要があった。
句点を打ったり、段落を変えたりするたびに、指が勝手に動いて、ほとんど無意識のうちにセーブしてしまう。心身の延長としての道具ではなく、いつの間にかこちらが、道具の延長になっていた。
そんな悪夢を見せられていたぼくらの目を覚まし、そこから救い出してくれたのが DraftPad という発明だ。もはや作業バッファこそが安息の地、ここからどこかにセーブすることのほうが危ない橋を渡ることのように思えるくらいだから、もうそれをセーブと呼ぶのはおかしい。
ところが、セーブという言葉にはもうひとつ、いまあるものを手放さずにとっておく、というニュアンスも含まれていて、この安息の地に立ってみると、そちらのほうの意味がぐんと際立ってくる。
無限に拡がる一枚の紙に書かれた言葉は、けっして失われてしまうことはないけれど、ただ、書けば書くほど、それらは次第に遠ざかっていく。紙は無限だけど、ぼくには限りがある。ぼくの手が届く範囲なんて、たかが知れている。
すると、無限の一枚の紙の、いま書いたところだけをビリっとちぎって、ちょっとわきにとっておき、必要になったらいつでもさっと手元に戻すことができるような、そんなセーブをしてみたくなる。
それは、そう、いまならタギングとか、スナップショットをとるとか、そんなふうに呼んだほうがふさわしい行為かもしれない。でもいいだろう、あえてセーブと呼び続けようじゃないか。言葉はおなじだけど、意味するところはすっかり変わってしまった。そこに、DraftPad の凄みを感じていくことにしよう。
――― と、そんなわけで、ぼくは、そういう意味でのセーブを、 DraftPad に付け足してみたくなったのです。
つづく。
D箱のアシスト事件
第1夜. DraftPad とセーブ
ファイルでもアプリでもない、あえて言うなら、永久に不滅の作業バッファ？ いや、DraftPad と呼ぶほかはない、テキストのヘイヴン。一枚の紙だから、New も Open もない。一枚の紙だけど、一種のタイムマシンでもあって、過去の好きな時点の状態にいつでも戻ることができる。だから、Save だっていらない。
それが DraftPad の哲学で、ぼくはその哲学がとても好きだ。好きだ、好きだ、好きなんだ。どうしようもなく好きなんだ。
それにひきかえ、どうだ。ファイルシステムだって？ すべてを「新規作成」し、「保存」し、「開く」世界。
いや、まあ、それもいいだろう。しかし、なんでもかんでも、いちいちその調子で押し通す必要はなかったんだ。むしろ、ほとんどのことは DraftPad 的に済ますことができたはずだ。すっかり騙されていた。
特に、セーブだなんてひどいじゃないか。
それは本当に、救い出すという意味だった。気取ったメタファーなんかじゃない。いつ消えてもおかしくないまぼろしのような作業バッファから、大切な成果を、もっと安全な場所に小まめに救い出しておく必要があった。
句点を打ったり、段落を変えたりするたびに、指が勝手に動いて、ほとんど無意識のうちにセーブしてしまう。心身の延長としての道具ではなく、いつの間にかこちらが、道具の延長になっていた。
そんな悪夢を見せられていたぼくらの目を覚まし、そこから救い出してくれたのが DraftPad という発明だ。もはや作業バッファこそが安息の地、ここからどこかにセーブすることのほうが危ない橋を渡ることのように思えるくらいだから、もうそれをセーブと呼ぶのはおかしい。
ところが、セーブという言葉にはもうひとつ、いまあるものを手放さずにとっておく、というニュアンスも含まれていて、この安息の地に立ってみると、そちらのほうの意味がぐんと際立ってくる。
無限に拡がる一枚の紙に書かれた言葉は、けっして失われてしまうことはないけれど、ただ、書けば書くほど、それらは次第に遠ざかっていく。紙は無限だけど、ぼくには限りがある。ぼくの手が届く範囲なんて、たかが知れている。
すると、無限の一枚の紙の、いま書いたところだけをビリっとちぎって、ちょっとわきにとっておき、必要になったらいつでもさっと手元に戻すことができるような、そんなセーブをしてみたくなる。
それは、そう、いまならタギングとか、スナップショットをとるとか、そんなふうに呼んだほうがふさわしい行為かもしれない。でもいいだろう、あえてセーブと呼び続けようじゃないか。言葉はおなじだけど、意味するところはすっかり変わってしまった。そこに、DraftPad の凄みを感じていくことにしよう。
――― と、そんなわけで、ぼくは、そういう意味でのセーブを、 DraftPad に付け足してみたくなったのです。
つづく。
DraftPad 1.5.2 
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日金曜日
兌換電子通貨トークン
中央銀行は、一定の現金通貨をストックし、ストックした個々の紙幣、硬貨に一対一で対応する兌換電子通貨トークンを発行する。
中央銀行は、兌換電子通貨トークンを保持するためのおサイフアプリを無償で提供する。
人は、いくつでもおサイフアプリを持つことができる。
人は、自分のおサイフアプリに入っている兌換電子通貨トークンを、他の人の特定のおサイフアプリに移すことができる。
おサイフアプリは、新たに保持する兌換電子通貨トークンに自らに固有のシグネチャーを付与する。保持をやめるときはシグネチャーを削除する。
中央銀行は、ストックしている通貨に対応する兌換電子通貨トークンに付与されたシグネチャーを、つねに把握している。
人は、自分のおサイフアプリに保持している兌換電子通貨トークンを、対応する現金通貨と交換することができる。
さっくり、こんな仕組みがもしもあってくれたならば、電子マネーといえども、その使い勝手は、フィジカルなマネーとほとんど変わるところがなくなる。と、信ずる。
つまり、アカウントレスで、プライバシーともきれいに切れていて、大人も子供も関係なく自分の経済的境遇に応じて出し入れできて、支払いの手続きに特別な数字の入力も必要なくて、支払い方法で囲い込まれたり、売買がつねに三者間取引としてしかあり得ず、いつもなんだか釈然としない手数料が上乗せされるなんてことのない、それこそ、みんながずっと慣れ親しんできた、ごくふつうの、自由な市場経済。
この水準のプラットフォームを提供するのは、産業資本主義でやっていく国民国家の機能のうちでも、コアの部類でしょう。なんで放任なんだろう？
ん。いやいやいやいや、大丈夫、大丈夫。狂ってるのは僕のほうぢゃないよ。
中央銀行は、兌換電子通貨トークンを保持するためのおサイフアプリを無償で提供する。
人は、いくつでもおサイフアプリを持つことができる。
人は、自分のおサイフアプリに入っている兌換電子通貨トークンを、他の人の特定のおサイフアプリに移すことができる。
おサイフアプリは、新たに保持する兌換電子通貨トークンに自らに固有のシグネチャーを付与する。保持をやめるときはシグネチャーを削除する。
中央銀行は、ストックしている通貨に対応する兌換電子通貨トークンに付与されたシグネチャーを、つねに把握している。
人は、自分のおサイフアプリに保持している兌換電子通貨トークンを、対応する現金通貨と交換することができる。
さっくり、こんな仕組みがもしもあってくれたならば、電子マネーといえども、その使い勝手は、フィジカルなマネーとほとんど変わるところがなくなる。と、信ずる。
つまり、アカウントレスで、プライバシーともきれいに切れていて、大人も子供も関係なく自分の経済的境遇に応じて出し入れできて、支払いの手続きに特別な数字の入力も必要なくて、支払い方法で囲い込まれたり、売買がつねに三者間取引としてしかあり得ず、いつもなんだか釈然としない手数料が上乗せされるなんてことのない、それこそ、みんながずっと慣れ親しんできた、ごくふつうの、自由な市場経済。
この水準のプラットフォームを提供するのは、産業資本主義でやっていく国民国家の機能のうちでも、コアの部類でしょう。なんで放任なんだろう？
ん。いやいやいやいや、大丈夫、大丈夫。狂ってるのは僕のほうぢゃないよ。
登録:
投稿 (Atom)