普段よく使うやつをまとめて、
DraftPad PDA
というのを半分冗談で作ってみてたんですが、これ公開する前に DraftPad の開発ステータスが「discontinued」になってしまいました。
DraftPad Important Notice
... なんというんでしょう。終わり方まで完全にデザインされてますよね。かっこいいですね。
そして一週も休まずにもう次の新仮面ライダーが始まるみたいに、Textwell がやってきました。
ソシオメディア | オリジナル iOS アプ「Textwell」をリリース
DraftPad の作者 @manabuueno さんのツイート
そこで、なにはともあれ「DraftPad PDA」たちを Textwell で動くようにしてみました。
Schedule & Memo
インポート
Money
インポート
Calc
インポート
Transit(NAVITIME)
インポート
これらの元になった DraftPad アシストは、どれも、いわゆる WebDelegate という機構を使っています。
yrrez さんによる WebDelegate 解説記事
どうかなとも思ったんですけど、Textwell にも WebDelegate はあるんですね。よかったです。なので、移植作業は驚くほどスムーズでした。ほんの数行書き換えただけ。ちなみに公式アクション「Dropbox」のソースを追いかけて勘所を教わりました。
Textwell の WebDelegate については、きっとまた yrrez さんが調べて教えてくれるかも知れませんね。今頃、ソシオメディア社に潜入してたりして。
最後に。ぼくの大好きなDraftPad、ありがとう。さようなら。この記事は DraftPad で書きました。
2013年9月14日土曜日
2012年6月17日日曜日
DraftPad アシスト ”Away” が、ほかの Dropbox クライアントとは違うところ
Away はディレクトリツリーのビューをたどる逐次的なインタラクションを採用せず、パス表現にマッチしたすべてのアイテムをフラットにリスティングすることに専念しています。
Dropbox 上のリソースにアクセスするUIとして不十分に見えるかもしれませんが、これにより、図書分類法的にいえば、列挙型分類法と分析合成型分類法を必要に応じて自由に組み合わせて使える分類/検索インターフェースを実現しています。
列挙型分類とは、あらかじめカテゴリを定義しておき、オブジェクトをそれにふさわしいカテゴリに仕分けていく分類方法です。カテゴリを特定すれば、当該のカテゴリに所属するオブジェクトが得られます。ふつうファイルシステムといったときにイメージするディレクトリツリーは、列挙型分類法にしたがったUIだといえます。
一方、分析合成型分類とは、あらかじめオブジェクトの属性の種類を定義しておき、各対象の各属性にふさわしい値を与えていく分類方法です。属性の値（の組み合わせ）に関する条件を指定すると、条件にマッチするオブジェクトが得られます。ソーシャルブックマークのタギングは、分析合成型分類法の具体例のひとつだといえます。インフォメーションアーキテクチャの世界ではこれをファセット分類と呼ぶようです。
多くの Dropbox クライアントは、フォルダとファイルのツリー構造をビジュアル化したビューを持ち、いわば列挙型分類法のみにしたがっています。フォルダ名やファイル名でオブジェクトを検索する Away も、基本的に列挙型分類法にしたがっているといえますが、Dropbox の検索仕様と Away のパス記法ベースの UI に基づいて、列挙型分類法に分析合成型分類法を補完的に組み合わせて活用することも可能になっています。
Dropbox では、フォルダ名、ファイル名の部分一致で検索する際、検索範囲を特定のパス以下に限定することができます。
Away で ”/path/to/a” を検索すると、”/path/to/” の直下にあるフォルダやファイルの”/path/to/abc/” や ”/path/to/abc.txt” だけではなく "/path/to/foo/bar/abc" や ”/path/to/x/y/z/abc.txt” などもヒットします。
したがって、次のような規則を作って各種のテキストを保存すれば、ディレクトリ名と文書名とタグを組み合わせて、さまざまな角度から必要なテキストをすばやく取り出せるようになります。
< 規則 >
カテゴリをあらわすディレクトリ ( "/"区切り) + 時間をあらわすディレクトリ ( "/"区切り) + 文書名とタグ (スペース区切り)
< 例 >
/Aプロジェクト/2012/06/Aとはそもそも何なのか？ 社内 議事録
など。
すると、プロジェクト名や文書名を直接検索するだけではなく、たとえば、2012年6月に作ったAプロジェクトの社内資料を探したいときは、
/Aプロジェクト/2012/06/社内
と入力して検索することができるようになります。
また、2012年のAプロジェクトの議事録を探したいときは、
/Aプロジェクト/2012/議事録
と入力して検索することができます。
このように、Away でのファイル検索は、ディレクトリツリーベースのファイルシステムを操作しながら目的のファイルを格納した場所にたどり着くというよりも、検索範囲を狭めたり広げたりしながらタギングしたファイルを一挙に取り出すような操作感になります。
実は、Dropbox 社製の iPhone クライアントでも、同じような操作を行うことは可能です。特定のフォルダ以下に範囲を限定してフォルダ名やファイル名で検索することができます。しかし、ディレクトリをたどるUIが中心なので、こうした列挙型+ 分析合成型両分類法を総合した"超整理"の可能性は残念ながら影に隠れてしまっています。
PC向けOSのファイルシステムにも、特定のフォルダを指定し、サブフォルダを検索対象に含めて、部分一致でファイルやフォルダを検索できる機能が備わっているのがふつうです。しかし、やはりこれもある種のレスキュー的な機能として普段は隠されていることが多いようです。
こうしたファイルのファインダビリティに対する Away のアプローチに最も近いのは、コマンドラインでのファイルシステム操作でしょう。CUI のファイル操作では、列挙型と分類合成型の総合がごく自然に行われていました。GUI のディレクトリツリービューは、直感的な操作可能性をもたらした一方で、ユーザー自身がとりうる分類と検索に対する"情報戦略"上の選択肢を極端に限定してしまったともいえます。
そもそも検索とは、どんなものでも、しまった場所、名前、特徴の三次元の情報に着目して行うのが基本です。(分類法でみれば、しまった場所は列挙型、特徴は分析合成型となります。名前は分類項目ではなく個体識別子です。)
Away は、こうした三次元の情報を一行のコンパクトなテキストにまとめ、たとえうろ覚えでも、たいていの場合は一度か二度の部分一致検索で目的のファイルをうまく引き出せるようなインターフェースの実現を目指して設計されました。
あまり目立たない部分ですが、その一環としてたとえば、検索フォームのインタラクションをあえて標準的なマナーとは異なる仕様で実装してみました。クリアボタン(右端のx)をタップすると、つねに入力されているすべての文字列がクリアされるのではなく、パス表現が入力されている場合は、1階層分のパスだけが削除されるようになっています。
その結果、DraftPad + Away は、他の Dropbox クライアントアプリとは一線を画すものとなりました。というよりも、もともと Away は DraftPad を Dropbox クライアントにするためのアシストではありません。あくまでも、Dropbox をバックエンドに使って、DraftPad の"一枚の紙"の機能を、その哲学と美学を損なうことなく、ささやかに拡張するためのアシストなのです。
... 。
なんつって、うそ！
ほんとはディレクトリツリーの実装が面倒で日和った結果なんですけどね！
でも、それで使ってみたら、そういう可能性を感じてしまったわけです。それは、ほんと。
/memo/away/超整理
Dropbox 上のリソースにアクセスするUIとして不十分に見えるかもしれませんが、これにより、図書分類法的にいえば、列挙型分類法と分析合成型分類法を必要に応じて自由に組み合わせて使える分類/検索インターフェースを実現しています。
列挙型分類とは、あらかじめカテゴリを定義しておき、オブジェクトをそれにふさわしいカテゴリに仕分けていく分類方法です。カテゴリを特定すれば、当該のカテゴリに所属するオブジェクトが得られます。ふつうファイルシステムといったときにイメージするディレクトリツリーは、列挙型分類法にしたがったUIだといえます。
一方、分析合成型分類とは、あらかじめオブジェクトの属性の種類を定義しておき、各対象の各属性にふさわしい値を与えていく分類方法です。属性の値（の組み合わせ）に関する条件を指定すると、条件にマッチするオブジェクトが得られます。ソーシャルブックマークのタギングは、分析合成型分類法の具体例のひとつだといえます。インフォメーションアーキテクチャの世界ではこれをファセット分類と呼ぶようです。
多くの Dropbox クライアントは、フォルダとファイルのツリー構造をビジュアル化したビューを持ち、いわば列挙型分類法のみにしたがっています。フォルダ名やファイル名でオブジェクトを検索する Away も、基本的に列挙型分類法にしたがっているといえますが、Dropbox の検索仕様と Away のパス記法ベースの UI に基づいて、列挙型分類法に分析合成型分類法を補完的に組み合わせて活用することも可能になっています。
Dropbox では、フォルダ名、ファイル名の部分一致で検索する際、検索範囲を特定のパス以下に限定することができます。
Away で ”/path/to/a” を検索すると、”/path/to/” の直下にあるフォルダやファイルの”/path/to/abc/” や ”/path/to/abc.txt” だけではなく "/path/to/foo/bar/abc" や ”/path/to/x/y/z/abc.txt” などもヒットします。
したがって、次のような規則を作って各種のテキストを保存すれば、ディレクトリ名と文書名とタグを組み合わせて、さまざまな角度から必要なテキストをすばやく取り出せるようになります。
< 規則 >
カテゴリをあらわすディレクトリ ( "/"区切り) + 時間をあらわすディレクトリ ( "/"区切り) + 文書名とタグ (スペース区切り)
< 例 >
/Aプロジェクト/2012/06/Aとはそもそも何なのか？ 社内 議事録
など。
すると、プロジェクト名や文書名を直接検索するだけではなく、たとえば、2012年6月に作ったAプロジェクトの社内資料を探したいときは、
/Aプロジェクト/2012/06/社内
と入力して検索することができるようになります。
また、2012年のAプロジェクトの議事録を探したいときは、
/Aプロジェクト/2012/議事録
と入力して検索することができます。
このように、Away でのファイル検索は、ディレクトリツリーベースのファイルシステムを操作しながら目的のファイルを格納した場所にたどり着くというよりも、検索範囲を狭めたり広げたりしながらタギングしたファイルを一挙に取り出すような操作感になります。
実は、Dropbox 社製の iPhone クライアントでも、同じような操作を行うことは可能です。特定のフォルダ以下に範囲を限定してフォルダ名やファイル名で検索することができます。しかし、ディレクトリをたどるUIが中心なので、こうした列挙型+ 分析合成型両分類法を総合した"超整理"の可能性は残念ながら影に隠れてしまっています。
PC向けOSのファイルシステムにも、特定のフォルダを指定し、サブフォルダを検索対象に含めて、部分一致でファイルやフォルダを検索できる機能が備わっているのがふつうです。しかし、やはりこれもある種のレスキュー的な機能として普段は隠されていることが多いようです。
こうしたファイルのファインダビリティに対する Away のアプローチに最も近いのは、コマンドラインでのファイルシステム操作でしょう。CUI のファイル操作では、列挙型と分類合成型の総合がごく自然に行われていました。GUI のディレクトリツリービューは、直感的な操作可能性をもたらした一方で、ユーザー自身がとりうる分類と検索に対する"情報戦略"上の選択肢を極端に限定してしまったともいえます。
そもそも検索とは、どんなものでも、しまった場所、名前、特徴の三次元の情報に着目して行うのが基本です。(分類法でみれば、しまった場所は列挙型、特徴は分析合成型となります。名前は分類項目ではなく個体識別子です。)
Away は、こうした三次元の情報を一行のコンパクトなテキストにまとめ、たとえうろ覚えでも、たいていの場合は一度か二度の部分一致検索で目的のファイルをうまく引き出せるようなインターフェースの実現を目指して設計されました。
あまり目立たない部分ですが、その一環としてたとえば、検索フォームのインタラクションをあえて標準的なマナーとは異なる仕様で実装してみました。クリアボタン(右端のx)をタップすると、つねに入力されているすべての文字列がクリアされるのではなく、パス表現が入力されている場合は、1階層分のパスだけが削除されるようになっています。
その結果、DraftPad + Away は、他の Dropbox クライアントアプリとは一線を画すものとなりました。というよりも、もともと Away は DraftPad を Dropbox クライアントにするためのアシストではありません。あくまでも、Dropbox をバックエンドに使って、DraftPad の"一枚の紙"の機能を、その哲学と美学を損なうことなく、ささやかに拡張するためのアシストなのです。
... 。
なんつって、うそ！
ほんとはディレクトリツリーの実装が面倒で日和った結果なんですけどね！
でも、それで使ってみたら、そういう可能性を感じてしまったわけです。それは、ほんと。
/memo/away/超整理
2012年6月15日金曜日
D箱のアシスト事件 第8夜 ( おまけ )
特集DraftPad/短期集中連載
D箱のアシスト事件
第8夜. 今日からはパブリックベータ！
第7夜でお別れを告げてからはやいものでかれこれ4ヶ月。しょぼくれたぼくのところにも公平に春が来て、そして去っていきました。
その間、DraftPad + アシストまわりでは、iOS5.1 での LocalStorage に関するバグ騒動 (http://manabuueno.tumblr.com/post/20776637086/ios-5-1-localstorage) なんてのがありました。
Away (プライベートベータ版)も認証情報の保持に LocalStorage を使っていたので、 DraftPad を新しいバージョンに更新するたびに動かなくなっていました。しかし、どうせプライベートベータ、まともに使っているのはぼくだけだろうから、上記の URL にある「ウェブ開発者」向けの親切な勧告もどこ吹く風で、そのままほったらかしていました。
DraftPadの更新があったら、いったん削除して新規にインストールし直していました。そうすれば LocalStorage を使っているアシストも動きましたからね。そのたびに溜め込んだアシストやヒストリーが消えてしまうわけですけど、まあ、それも心機一転、ときどきこうしてこざっぱりするのも悪くないかな！なんて余裕をぶっこかせていただいておりましたよ。
ところがつい最近、さるお方(大物)から DraftPad をアップデートしたら Away が動かなくなって困っておる、どうにかならんのかね？アアン？というご連絡をいただきましてビーンとはね起きました。ここはひとつシャンと背筋を伸ばして誠心誠意対応せざるをえない状況というわけで、勧告に従い、localStorageの使用をやめて Cookieを使うように改造したわけです。
そうして4ヶ月ぶりに Away のコードをしみじみと眺め、また、あらためて一連の動作を確認しているうちに、ふと、ひょっとしてこうすれば Dropbox の審査をパスできるんじゃないかな？というアイディアが浮かびました。
いや、もうじつに簡単な話なのですが、あの第1～7夜ではヒートアップしておりましたからね、ああいうときはどうも、自分のやっていることに誇りを持ちたい一心で、つい必要以上に問題を複雑かつ大袈裟に捉えがちです。それに、作業の積み重ねで暗にもったいない精神にも取り付かれていますから視野狭窄になりがちですしね。
それにくらべたら4ヶ月後のシラけた自分は実に自由。そして柔軟。四の五の言わず、OAuth の アクセストークンをアシストの URL のクエリーに入れちゃえばそれでいいんじゃない？ で、ユーザー専用のアシストを Dropbox の認証のあとで動的に生成する Web サービスとして審査に出してみたらどうだ？ふつうに Web ブラウザで使うサービスとして。そうすればほら、第7夜で書いた問題なんていっぺんにみんな解決しちゃうわけだし。なんて、いやにカンタンに言い放つわけです。
で、もはやもったいないフリーな心と体でざくざくコードを削ったり書き直したりして、ゆうべ審査に出してみたんです。そうしたらあっさり通っちゃって、なんと数時間後には Dropbox から「おめでとうございます」なんてメールが届いていました。
というわけで、DraftPad に入力したテキストを Dropbox の任意のパスに保存できるアシスト「Away」 は、このたびめでたく年季が明けて、晴れて誰でも使えるようにあいなりました。今後はパブリックベータということでひとつよろしくお願いいたします。
Away アシストメーカー
こちらの URL にアクセスして「Make Assist」ボタンをタップすると DropBox につながります。そこで Away からのアクセスを許可していただければ、Dropbox 上のテキストファイルを開くための「Open」アシストと、Draftpad のテキストを Dropbox に保存するための「Save」アシストをインポートするためのリンクが表示されます。タップしてあなたの DraftPad にインポートしてください。
Away の使用方法は第二夜で画面キャプチャつきでご紹介しています。
D箱のアシスト事件 第2夜
より詳細な使用方法についてはこちらをご覧ください。
ところで、アシストの URL のクエリパラメータに OAuth のアクセストークンを直接書き込んじゃうなんてセキュリティ的に脆すぎないか？ってお思いの方もいらっしゃることでしょう。
アシストの本体はネットの向こうにあるんだから、実行のたびにアクセストークンが素っ裸のまま URL に含まれてネットワークを流れていくんじゃないかって。しかし、ここが DraftPad のアシスト機構のすごいところの1つでもあるんですけど、DraftPad はアシストを内蔵ブラウザに読み込んだ後で、クエリパラメータの値を直接注入してくれるんです。アシストのクエリパラメータはネットには流れないんですね。完全にローカルな、iPhone アプリの内部処理なんです。ついでにいうと、アシストメーカーからアシストをインポートするところもローカルですね。( 内蔵ブラウザに読み込まれた Javascript からサーバーに対してアクセストークンを含めた XMLHttpRequest を投げますが、これは SSL かつ POST でやっています。)
とはいえ、アシストの URL の取り扱いにはくれぐれも注意してください。間違ってお友達に教えてしまったら、お友達はあなたの Dropbox にアクセスし放題です。
D箱のアシスト事件
第8夜. 今日からはパブリックベータ！
第7夜でお別れを告げてからはやいものでかれこれ4ヶ月。しょぼくれたぼくのところにも公平に春が来て、そして去っていきました。
その間、DraftPad + アシストまわりでは、iOS5.1 での LocalStorage に関するバグ騒動 (http://manabuueno.tumblr.com/post/20776637086/ios-5-1-localstorage) なんてのがありました。
Away (プライベートベータ版)も認証情報の保持に LocalStorage を使っていたので、 DraftPad を新しいバージョンに更新するたびに動かなくなっていました。しかし、どうせプライベートベータ、まともに使っているのはぼくだけだろうから、上記の URL にある「ウェブ開発者」向けの親切な勧告もどこ吹く風で、そのままほったらかしていました。
DraftPadの更新があったら、いったん削除して新規にインストールし直していました。そうすれば LocalStorage を使っているアシストも動きましたからね。そのたびに溜め込んだアシストやヒストリーが消えてしまうわけですけど、まあ、それも心機一転、ときどきこうしてこざっぱりするのも悪くないかな！なんて余裕をぶっこかせていただいておりましたよ。
ところがつい最近、さるお方(大物)から DraftPad をアップデートしたら Away が動かなくなって困っておる、どうにかならんのかね？アアン？というご連絡をいただきましてビーンとはね起きました。ここはひとつシャンと背筋を伸ばして誠心誠意対応せざるをえない状況というわけで、勧告に従い、localStorageの使用をやめて Cookieを使うように改造したわけです。
そうして4ヶ月ぶりに Away のコードをしみじみと眺め、また、あらためて一連の動作を確認しているうちに、ふと、ひょっとしてこうすれば Dropbox の審査をパスできるんじゃないかな？というアイディアが浮かびました。
いや、もうじつに簡単な話なのですが、あの第1～7夜ではヒートアップしておりましたからね、ああいうときはどうも、自分のやっていることに誇りを持ちたい一心で、つい必要以上に問題を複雑かつ大袈裟に捉えがちです。それに、作業の積み重ねで暗にもったいない精神にも取り付かれていますから視野狭窄になりがちですしね。
それにくらべたら4ヶ月後のシラけた自分は実に自由。そして柔軟。四の五の言わず、OAuth の アクセストークンをアシストの URL のクエリーに入れちゃえばそれでいいんじゃない？ で、ユーザー専用のアシストを Dropbox の認証のあとで動的に生成する Web サービスとして審査に出してみたらどうだ？ふつうに Web ブラウザで使うサービスとして。そうすればほら、第7夜で書いた問題なんていっぺんにみんな解決しちゃうわけだし。なんて、いやにカンタンに言い放つわけです。
で、もはやもったいないフリーな心と体でざくざくコードを削ったり書き直したりして、ゆうべ審査に出してみたんです。そうしたらあっさり通っちゃって、なんと数時間後には Dropbox から「おめでとうございます」なんてメールが届いていました。
というわけで、DraftPad に入力したテキストを Dropbox の任意のパスに保存できるアシスト「Away」 は、このたびめでたく年季が明けて、晴れて誰でも使えるようにあいなりました。今後はパブリックベータということでひとつよろしくお願いいたします。
Away アシストメーカー
こちらの URL にアクセスして「Make Assist」ボタンをタップすると DropBox につながります。そこで Away からのアクセスを許可していただければ、Dropbox 上のテキストファイルを開くための「Open」アシストと、Draftpad のテキストを Dropbox に保存するための「Save」アシストをインポートするためのリンクが表示されます。タップしてあなたの DraftPad にインポートしてください。
Away の使用方法は第二夜で画面キャプチャつきでご紹介しています。
D箱のアシスト事件 第2夜
より詳細な使用方法についてはこちらをご覧ください。
ところで、アシストの URL のクエリパラメータに OAuth のアクセストークンを直接書き込んじゃうなんてセキュリティ的に脆すぎないか？ってお思いの方もいらっしゃることでしょう。
アシストの本体はネットの向こうにあるんだから、実行のたびにアクセストークンが素っ裸のまま URL に含まれてネットワークを流れていくんじゃないかって。しかし、ここが DraftPad のアシスト機構のすごいところの1つでもあるんですけど、DraftPad はアシストを内蔵ブラウザに読み込んだ後で、クエリパラメータの値を直接注入してくれるんです。アシストのクエリパラメータはネットには流れないんですね。完全にローカルな、iPhone アプリの内部処理なんです。ついでにいうと、アシストメーカーからアシストをインポートするところもローカルですね。( 内蔵ブラウザに読み込まれた Javascript からサーバーに対してアクセストークンを含めた XMLHttpRequest を投げますが、これは SSL かつ POST でやっています。)
とはいえ、アシストの URL の取り扱いにはくれぐれも注意してください。間違ってお友達に教えてしまったら、お友達はあなたの Dropbox にアクセスし放題です。
2012年2月11日土曜日
D箱のアシスト事件 第7夜 ( 最終回 )
特集DraftPad/短期集中連載
D箱のアシスト事件
第7夜. 永遠のプライベートベータ
実はそれ以前に、Dropbox に配置したファイルと YQL を使った最初のバージョンが出来上がった時点で、一度、公開申請を出していたのでした。おっちょこちょいなぼくは、Dropbox の説明をろくに確認もせず、どうせ形式的なものだろうとタカを括り、紹介文にはアプリのタイトルとキャッチフレーズのようなものをやはりインチキな英語で一文添えただけでした。アシストをインポートするための URL も書きませんでした。
ちなみにアプリの名前は「DraftPad Assist - Path to Dropbox」としました。素直に考えれば Save to Dropbox ですけど、それだと公式のアシストとかぶってしまうので、パスを指定してセーブする点を強調して、Dropbox へのパス ( 経路 ) としてみたわけです。
申請に対する返事はなかなか戻ってきませんでした。数日が経過して、ちょうど、開発者以外のアカウントで OAuth できずに弱り果てていた頃、そっけない不合格通知が届きました。
レビューしてやるから、実際にきみのアプリを使うために必要な URLかなにかを教えなさい。それからアプリ名に「Dropbox」って入れないように。( ナントカ with Dropbox ならよし ) ... とのこと。
そこで、今回はちゃんと DraftPad をインストールするための URL と、アシストをインポートするための URL を伝えました。
そして、名前のほうですが、Dropbox という単語を含めると面倒なことになるようなので、file away (文書などをファイリングすること) から「DraftPad Assist - Away」と名付けました。いろいろいっても結局はファイリングですからね。そして、Dropbox は DraftPad からみれば、やっぱりアウェーだろうと。
すると、今度はなんと一日と空けず、たちまち審査結果が返ってきました。件名は日本語で、「Dropbox アプリプロダクション鍵不許可のお知らせ」！
やあ、使ってみたよ。でも、きみ、アプリに内蔵したブラウザで OAuth するのはナシだよ。これじゃまるでフィッシングみたいじゃないか。はい、失格～。
... いや、さすがにフィッシングとは言ってこなかったんですけど、まあ、そんなようなことが書いてありました。たしかに言われてみれば、信用の元になるサイトを iframe に入れて見せるようなものですからね。URL は隠されてしまっているし、それが本物なのか偽物なのか、ユーザーは識別することができない。OAuth の根本原理を台無しにしているわけです。
Dropbox いわく、OAuth をやるには Dropbox 公式のサイトまたはアプリを経由しなくてはいけない。アドレス欄の見えない内蔵ブラウザで Dropbox サイトにアクセスしても、それをもって公式サイトを経由したとは認められない。Safari を起動せず、アプリの内部ですべてを済ませたいなら、要するに XAuth をやりたければ、公式の iOS 向け SDK を使うように。それなら公式の Dropbox アプリを経由したことになるから ...
まったくもってごもっとも。しかし、これが DraftPad のアシストである以上、仕組みとして、いずれも無理な相談です。
ああ、万事休す。これで一巻の終わりです。... いや、本当にそうか？ ほかになにか手だてはないのか？
考えてみました。考えてみたところ、一応、次の A, B 案がまとまりました。
A案 / コードネーム「みんなデベロッパー」
ユーザーに、自分で Dropbox API アプリを名前だけでいいので登録してもらう。そして、発行された OAuth の Consumer Key と Consumer Secret を DraftPad に入力した状態で、OAuth 用のアシストを実行すれば ...
B案 / コードネーム「おすそわけトークン」
Safari で OAuth を行い、取得した AccessToken を一時サーバーサイドにプールしておく。それに紐づけたセッション ID を DraftPad に Insert して、ユーザーにはその状態で認証用のアシストを実行してもらう。そこでプールしておいた AccessToken をローカルに保存すれば ...
うーん、どっちも、邪悪でクレイジーですね。
やめておきましょう。
というわけで、調子に乗って長々とお話させていただきましたが、結局、DraftPad に書きつけたテキストを Dropbox の好きなフォルダに好きな名前で保存するためのアシスト「Away」 は、5 ユーザー限定の永遠のプライベートベータ版としてやっていくことになりました。
......。
さて、これでぼくの話はおしまいです。なんだか情報量に乏しい、たんなる身の上話みたいになってしまいましたが、最後までお付き合いいただき、どうもありがとうございました。では 、ちょっとせつないエンディングテーマを聞きながらお別れしましょう。
さようなら。
♪ D箱のアシスト事件 - エンディングテーマ: 誰も知らない / ラフィータフィー
おわり。
と、書いたのが実は今から4ヶ月前のこと。ところがこの話、これで終わりではなかったのです...。
D箱のアシスト事件
第7夜. 永遠のプライベートベータ
実はそれ以前に、Dropbox に配置したファイルと YQL を使った最初のバージョンが出来上がった時点で、一度、公開申請を出していたのでした。おっちょこちょいなぼくは、Dropbox の説明をろくに確認もせず、どうせ形式的なものだろうとタカを括り、紹介文にはアプリのタイトルとキャッチフレーズのようなものをやはりインチキな英語で一文添えただけでした。アシストをインポートするための URL も書きませんでした。
ちなみにアプリの名前は「DraftPad Assist - Path to Dropbox」としました。素直に考えれば Save to Dropbox ですけど、それだと公式のアシストとかぶってしまうので、パスを指定してセーブする点を強調して、Dropbox へのパス ( 経路 ) としてみたわけです。
申請に対する返事はなかなか戻ってきませんでした。数日が経過して、ちょうど、開発者以外のアカウントで OAuth できずに弱り果てていた頃、そっけない不合格通知が届きました。
レビューしてやるから、実際にきみのアプリを使うために必要な URLかなにかを教えなさい。それからアプリ名に「Dropbox」って入れないように。( ナントカ with Dropbox ならよし ) ... とのこと。
そこで、今回はちゃんと DraftPad をインストールするための URL と、アシストをインポートするための URL を伝えました。
そして、名前のほうですが、Dropbox という単語を含めると面倒なことになるようなので、file away (文書などをファイリングすること) から「DraftPad Assist - Away」と名付けました。いろいろいっても結局はファイリングですからね。そして、Dropbox は DraftPad からみれば、やっぱりアウェーだろうと。
すると、今度はなんと一日と空けず、たちまち審査結果が返ってきました。件名は日本語で、「Dropbox アプリプロダクション鍵不許可のお知らせ」！
やあ、使ってみたよ。でも、きみ、アプリに内蔵したブラウザで OAuth するのはナシだよ。これじゃまるでフィッシングみたいじゃないか。はい、失格～。
... いや、さすがにフィッシングとは言ってこなかったんですけど、まあ、そんなようなことが書いてありました。たしかに言われてみれば、信用の元になるサイトを iframe に入れて見せるようなものですからね。URL は隠されてしまっているし、それが本物なのか偽物なのか、ユーザーは識別することができない。OAuth の根本原理を台無しにしているわけです。
Dropbox いわく、OAuth をやるには Dropbox 公式のサイトまたはアプリを経由しなくてはいけない。アドレス欄の見えない内蔵ブラウザで Dropbox サイトにアクセスしても、それをもって公式サイトを経由したとは認められない。Safari を起動せず、アプリの内部ですべてを済ませたいなら、要するに XAuth をやりたければ、公式の iOS 向け SDK を使うように。それなら公式の Dropbox アプリを経由したことになるから ...
まったくもってごもっとも。しかし、これが DraftPad のアシストである以上、仕組みとして、いずれも無理な相談です。
ああ、万事休す。これで一巻の終わりです。... いや、本当にそうか？ ほかになにか手だてはないのか？
考えてみました。考えてみたところ、一応、次の A, B 案がまとまりました。
A案 / コードネーム「みんなデベロッパー」
ユーザーに、自分で Dropbox API アプリを名前だけでいいので登録してもらう。そして、発行された OAuth の Consumer Key と Consumer Secret を DraftPad に入力した状態で、OAuth 用のアシストを実行すれば ...
B案 / コードネーム「おすそわけトークン」
Safari で OAuth を行い、取得した AccessToken を一時サーバーサイドにプールしておく。それに紐づけたセッション ID を DraftPad に Insert して、ユーザーにはその状態で認証用のアシストを実行してもらう。そこでプールしておいた AccessToken をローカルに保存すれば ...
うーん、どっちも、邪悪でクレイジーですね。
やめておきましょう。
というわけで、調子に乗って長々とお話させていただきましたが、結局、DraftPad に書きつけたテキストを Dropbox の好きなフォルダに好きな名前で保存するためのアシスト「Away」 は、5 ユーザー限定の永遠のプライベートベータ版としてやっていくことになりました。
......。
さて、これでぼくの話はおしまいです。なんだか情報量に乏しい、たんなる身の上話みたいになってしまいましたが、最後までお付き合いいただき、どうもありがとうございました。では 、ちょっとせつないエンディングテーマを聞きながらお別れしましょう。
さようなら。
♪ D箱のアシスト事件 - エンディングテーマ: 誰も知らない / ラフィータフィー
おわり。
と、書いたのが実は今から4ヶ月前のこと。ところがこの話、これで終わりではなかったのです...。
2012年2月10日金曜日
D箱のアシスト事件 第6夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第6夜. アシストのためのサーバーサイド
よーし、やっぱりまじめにアシストのためのサーバーサイドを自分で作ろう！
この際、小さくて、単純で、あまりたくさんのアクセスが発生しないようなものなら、自分でも Web アプリを作れるようになっておこう。ついにぼくはそう決心しました。でも、サーバーの設定とか開発環境の構築とかやりたくない、というか、人間のベーシックな部分がだいぶ迂闊に仕上がっているぼくには、そういうの、まともにできなくてきっとひどい目に合うにきまってるし ...
ところが最近はそのへん、本当にすごいことになってきてるんですね。PaaS とかいって。少し調べたら、DotCloud というのがよさそうでした。Windows + Cygwin 環境に、CLI という DotCloud クライアントをインストールして、サイトに掲載されている Quick Start Guide のとおりに設定してみたら、拍子抜けするほどあっさりと、静的なファイルをホストするサーバーができてしまいました。
そこで、まずはそれに、Dropbox のパブリックフォルダに配置していたアシストをコピーしてみました。すると案の定、開発者以外の Dropbox アカウントでも問題なく OAuth することができるようになりました。
友人にふたたび試してくれるようにお願いしてみると、友人の手元でも問題なく動きはじめたようです。友人は、ぼくのアシストを褒めてくれました。
理解者と勇気を得たぼくは、いよいよ、YQL に頼っていた部分を自前のサーバーサイドアプリに置き換える作業にとりかかりました。
サーバーサイドアプリといっても、クライアントサイドからの xmlHttpRequest を受けて、Dropbox の API へのリクエストとそのレスポンスを中継するだけの、いたってシンプルなものです。きっと node.js と express というWebアプリケーションフレームワークでなら、手っ取り早く必要十分なものが作れるだろうと踏みました。
クライアントもサーバーも、一貫して Javascript のシンタックスに適応しきった頭と手とエディタでやっていけるので、そのへんでもきっと楽ができるでしょう。
作業は非常にスムーズでした。ローカルでの開発サーバーを構築する際に、プロキシの設定の仕方ですこし戸惑ったくらいで、node-dbox なんていうすばらしいモジュールにも出会い、信じられないほど簡単に、ぼくは欲かったものを手に入れてしまいました。
YQL の概念を理解して、満足に設定を整えるまでのほうがよっぽど面倒で時間がかかったくらいです。
出来上がったものを動かしてみると、それはそれは、すばらしいパフォーマンスを見せてくれました。セーブもオープンもさくさく処理されていきます。エラーはちっとも発生しません。長いテキストでも大丈夫です。あの有名な「DraftPad 開発者への 16,820 文字インタビュー」も自由に出し入れできます。ぼくは、ソースコードからリトライの機構を外しました。
さあ、ぼくは有頂天でした。おもては凍えるような寒さでしたが、まさに、おらが世の春でした。たとえ帰り道で交通事故にあっても、生きてさえいれば、ま、そりゃそうだよね、うっふふ。魔でしょ？と、納得づくで笑っていられそうなくらい、それはぼくにとって好事でした。
さっそく公開して、みんなにも使ってもらおう。きっと他にもぼくと同じように喜んでくれる人がいるに違いない。ぼくは、拙い中学生なみの英語で、Dropbox のレビュアー向けに紹介文を一生懸命書きました。これは DraftPad という iPhone アプリの、アシストと呼ばれる拡張機能のひとつであり... インストールの仕方は ... 使い方は ... そもそも DraftPad というのは ... アシストというのはつまり ...。
公開申請ボタンをクリックしたぼくは、すっかり満ち足りた気持ちになって、深夜のD坂を踊るように下って帰りました。あ、団子坂じゃなくて、道玄坂なんですけどね ... 。
つづく。(次回はいよいよ最終回！)
D箱のアシスト事件
第6夜. アシストのためのサーバーサイド
よーし、やっぱりまじめにアシストのためのサーバーサイドを自分で作ろう！
この際、小さくて、単純で、あまりたくさんのアクセスが発生しないようなものなら、自分でも Web アプリを作れるようになっておこう。ついにぼくはそう決心しました。でも、サーバーの設定とか開発環境の構築とかやりたくない、というか、人間のベーシックな部分がだいぶ迂闊に仕上がっているぼくには、そういうの、まともにできなくてきっとひどい目に合うにきまってるし ...
ところが最近はそのへん、本当にすごいことになってきてるんですね。PaaS とかいって。少し調べたら、DotCloud というのがよさそうでした。Windows + Cygwin 環境に、CLI という DotCloud クライアントをインストールして、サイトに掲載されている Quick Start Guide のとおりに設定してみたら、拍子抜けするほどあっさりと、静的なファイルをホストするサーバーができてしまいました。
そこで、まずはそれに、Dropbox のパブリックフォルダに配置していたアシストをコピーしてみました。すると案の定、開発者以外の Dropbox アカウントでも問題なく OAuth することができるようになりました。
友人にふたたび試してくれるようにお願いしてみると、友人の手元でも問題なく動きはじめたようです。友人は、ぼくのアシストを褒めてくれました。
理解者と勇気を得たぼくは、いよいよ、YQL に頼っていた部分を自前のサーバーサイドアプリに置き換える作業にとりかかりました。
サーバーサイドアプリといっても、クライアントサイドからの xmlHttpRequest を受けて、Dropbox の API へのリクエストとそのレスポンスを中継するだけの、いたってシンプルなものです。きっと node.js と express というWebアプリケーションフレームワークでなら、手っ取り早く必要十分なものが作れるだろうと踏みました。
クライアントもサーバーも、一貫して Javascript のシンタックスに適応しきった頭と手とエディタでやっていけるので、そのへんでもきっと楽ができるでしょう。
作業は非常にスムーズでした。ローカルでの開発サーバーを構築する際に、プロキシの設定の仕方ですこし戸惑ったくらいで、node-dbox なんていうすばらしいモジュールにも出会い、信じられないほど簡単に、ぼくは欲かったものを手に入れてしまいました。
YQL の概念を理解して、満足に設定を整えるまでのほうがよっぽど面倒で時間がかかったくらいです。
出来上がったものを動かしてみると、それはそれは、すばらしいパフォーマンスを見せてくれました。セーブもオープンもさくさく処理されていきます。エラーはちっとも発生しません。長いテキストでも大丈夫です。あの有名な「DraftPad 開発者への 16,820 文字インタビュー」も自由に出し入れできます。ぼくは、ソースコードからリトライの機構を外しました。
さあ、ぼくは有頂天でした。おもては凍えるような寒さでしたが、まさに、おらが世の春でした。たとえ帰り道で交通事故にあっても、生きてさえいれば、ま、そりゃそうだよね、うっふふ。魔でしょ？と、納得づくで笑っていられそうなくらい、それはぼくにとって好事でした。
さっそく公開して、みんなにも使ってもらおう。きっと他にもぼくと同じように喜んでくれる人がいるに違いない。ぼくは、拙い中学生なみの英語で、Dropbox のレビュアー向けに紹介文を一生懸命書きました。これは DraftPad という iPhone アプリの、アシストと呼ばれる拡張機能のひとつであり... インストールの仕方は ... 使い方は ... そもそも DraftPad というのは ... アシストというのはつまり ...。
公開申請ボタンをクリックしたぼくは、すっかり満ち足りた気持ちになって、深夜のD坂を踊るように下って帰りました。あ、団子坂じゃなくて、道玄坂なんですけどね ... 。
つづく。(次回はいよいよ最終回！)
2012年2月9日木曜日
D箱のアシスト事件 第5夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第5夜. ひとり OAuth
Dropbox に API アプリを登録すると、当初はデベロッパー版として API へのアクセスが許可されます。デベロッパー版のアプリを利用できるのは、開発者自身の Dropbox アカウントとその他 5 人分のアカウントに限定されています。さらに多くのアカウントで利用できるようにするためには、アプリの公開を申請し、Drobbox の審査をパスする必要があります。
公開する前に、なんとか格好がついたこの時点で、ぼくは信頼できる友人に使ってみてもらうことにしました。
すると、友人の手元では OAuth が失敗するというのです。あわてて自分でも別の Dropbox アカウントを取得して試してみたところ、やはり失敗しました。Dropbox の画面でアシストからのアクセスに許可を与えるボタンをタップすると、Dropbox のエラーメッセージ「Error (404)」が表示されてしまうのです。 しかし、ふたたび自分の開発者アカウントに切り替えると、何事もなくうまくいくのです。
自分で作ったアプリに許可を与えられるのは自分だけって、それじゃいったいなんのための OAuth ですか！
DraftPad をいったん離れ、Safari で実行できるように改造して試してみましたが同じことでした。PC でやってみても同じ。他に同じような悩みを抱えている人がいないかググりまくってみても空振り。一度は不思議な呪文でぼくを救ってくれた Dropbox の Developer forum にすがってみてももう何も出てきません。
ぼくは今度こそ本当にサジを投げました。
いや、いいんだ。いいんだよ。自分でほしいと思ったものが、いまこうして自分の手元で使えている。それで十分じゃないか。そのための OAuth だよ。ひとり OAuth ! ぼくにはまったくお似合いだよ、は、は、は、は！
なんて、自分で自分に強がってみせつつも、ぼくは未練がましく Error (404) になった URL を DraftPad に入れて持ち歩いていました。そして、暇さえあればそれをとり出しては眺め、結局途方にくれて、ただ、ため息ばかりついていました。
ところが、そんなことを当てもなく何度も繰り返しているうち、ある日突然わかってしまったのです。（そんなことってあるのものなんですネ！）
――― あっ、Dropbox のパブリック URL に uid というクエリパラメータをつけて、これに、自分の ID とは異なる値をセットしてリクエストすると、Error (404) になるんだ！
試してみたら、本当にそうでした。
ぼくは、ぼくの流儀に従い、相変わらず Dropbox 上に配置した Javscript + HTML + CSS だけでアシストを作っていました。OAuth でユーザーの許可をもらったあとにリダイレクトで戻ってくるコールバック URL も Dropbox のパブリック URL です。
そして Dropbox は、コールバック URL に uid というクエリパラメータをつけて、これに許可を与えたユーザーの ID をセットしてリダイレクトしてくるのです。 そのために、開発者以外のアカウントでは OAuth に失敗していたというわけでした。
な、なかなかやってくれるじゃないか、Dropbox ちゃん。いいよ、もういいよ、わかったよ。そっちがそうくるなら、こっちにも考えがある。はじめ腹の底のほうに生まれた黒い情念の塊のようなものが、みるみるうちに全身に満ちていくのを感じながら、ぼくは自分が今、はっきりと笑っていることを自覚していました ... 。
つづく。
D箱のアシスト事件
第5夜. ひとり OAuth
Dropbox に API アプリを登録すると、当初はデベロッパー版として API へのアクセスが許可されます。デベロッパー版のアプリを利用できるのは、開発者自身の Dropbox アカウントとその他 5 人分のアカウントに限定されています。さらに多くのアカウントで利用できるようにするためには、アプリの公開を申請し、Drobbox の審査をパスする必要があります。
公開する前に、なんとか格好がついたこの時点で、ぼくは信頼できる友人に使ってみてもらうことにしました。
すると、友人の手元では OAuth が失敗するというのです。あわてて自分でも別の Dropbox アカウントを取得して試してみたところ、やはり失敗しました。Dropbox の画面でアシストからのアクセスに許可を与えるボタンをタップすると、Dropbox のエラーメッセージ「Error (404)」が表示されてしまうのです。 しかし、ふたたび自分の開発者アカウントに切り替えると、何事もなくうまくいくのです。
自分で作ったアプリに許可を与えられるのは自分だけって、それじゃいったいなんのための OAuth ですか！
DraftPad をいったん離れ、Safari で実行できるように改造して試してみましたが同じことでした。PC でやってみても同じ。他に同じような悩みを抱えている人がいないかググりまくってみても空振り。一度は不思議な呪文でぼくを救ってくれた Dropbox の Developer forum にすがってみてももう何も出てきません。
ぼくは今度こそ本当にサジを投げました。
いや、いいんだ。いいんだよ。自分でほしいと思ったものが、いまこうして自分の手元で使えている。それで十分じゃないか。そのための OAuth だよ。ひとり OAuth ! ぼくにはまったくお似合いだよ、は、は、は、は！
なんて、自分で自分に強がってみせつつも、ぼくは未練がましく Error (404) になった URL を DraftPad に入れて持ち歩いていました。そして、暇さえあればそれをとり出しては眺め、結局途方にくれて、ただ、ため息ばかりついていました。
http://dl.dropbox.com/u/223789/dev/dp2drpbx/sign.html?oauth_token=mh7an9dkrg59&uid=57873456( oauth_token の値は Dropbox のサイトに掲載されているサンプルです。uid はぼくのアカウントのものです。 )
ところが、そんなことを当てもなく何度も繰り返しているうち、ある日突然わかってしまったのです。（そんなことってあるのものなんですネ！）
――― あっ、Dropbox のパブリック URL に uid というクエリパラメータをつけて、これに、自分の ID とは異なる値をセットしてリクエストすると、Error (404) になるんだ！
試してみたら、本当にそうでした。
ぼくは、ぼくの流儀に従い、相変わらず Dropbox 上に配置した Javscript + HTML + CSS だけでアシストを作っていました。OAuth でユーザーの許可をもらったあとにリダイレクトで戻ってくるコールバック URL も Dropbox のパブリック URL です。
そして Dropbox は、コールバック URL に uid というクエリパラメータをつけて、これに許可を与えたユーザーの ID をセットしてリダイレクトしてくるのです。 そのために、開発者以外のアカウントでは OAuth に失敗していたというわけでした。
な、なかなかやってくれるじゃないか、Dropbox ちゃん。いいよ、もういいよ、わかったよ。そっちがそうくるなら、こっちにも考えがある。はじめ腹の底のほうに生まれた黒い情念の塊のようなものが、みるみるうちに全身に満ちていくのを感じながら、ぼくは自分が今、はっきりと笑っていることを自覚していました ... 。
つづく。
2012年2月8日水曜日
D箱のアシスト事件 第4夜
特集DraftPad/短期集中連載
D箱のアシスト事件
第4夜. トラブルぶくみ
この「Save to Tumblr」、ちょっと長めのテキストをポストするとエラーになるんですよね。しかも、毎回かならずというわけではなく、同じテキストでもエラーになったり、ならなかったりする。
クライアントサイド、YQL、Tumblr のどこでしくじっているのか調べてみると、どうも、YQL が怪しい。 怪しいのはわかるんですが、かといって YQL にそれ以上、手の出しようもない。
そんな状態でモンモンとした日々を過ごしていたところ、なにかの拍子に、Dropbox の API に HTTP で PUT するメソッドがあるのを知ったんです。
よく REST なんていいますけど、あんまり PUT ってお目にかかれないもんですから、すこし関心を持ちまして、 これを使えば、公式アシストの Save to Dropbox のように、(勝手な想像ですが、) アプリの内部にファイルを作成して、それをマルチパートでポストするというやり方じゃなく、DraftPad のテキストを Javascript 製のアシスト経由で直接送信できるんじゃないか？ しかも、任意のフォルダに、任意のファイル名で？ なんて考えました。
トラブルぶくみではありますが、YQL に頼れば、やれることはやれるはず。Dropbox の場合でも、やっぱり Tumblr と同じようなエラーが出るものか試してみたくもあり、今度は、Dropbox にテキストをセーブするためのアシストを作ってみることにしました。
どんなふうに動くものなのかは、前々回でご紹介したとおりです。途中、OAuth がどうしてもうまくいかずサジを投げかけました。でも本当に投げてしまう寸前で、Dropbox の Developer Forum に 「 signature_method を PLAINTEXT にしてみ？」なんて、まあ、ほとんど呪文のような書き込みを見つけて、なんとか乗り切ることができました。そんなかんじで、Tumblr のときよりもだいぶ苦労はしたのですが、なんとかひととおり、目標にしていた機能を実装することができました。
さて、実際に手にとってみると、最初の回に何やらクドクドと書き連ねたような意味で、これは、ぼくの DraftPad ライフにうまくフィットしていくものだということがすぐにわかりました。気がつくと、夢中になって無限の一枚の紙をちぎりまくってました。道具のほうじゃなく、自分のほうがグーンと延長していく実感がありました。
... しかし、やっぱり Tumblr と同じ問題が起きてしまうのです。
その上、Dropbox の API は https でつなげないと使えないんですけど、YQL と Dropbox の間で SSL 通信を確立する際のものと思しき通信エラーが頻発して、そのままでは、とても実用に耐えられない状態なのです。
長いテキストが扱えないというのはまだしも、何か操作するたびに、しょっちゅう通信エラーが発生してしまうのはいくらなんでもいただけないでしょう。
そこで、幸い、というべきかどうか、諸々のエラーは確率的にしか発生しないので、暗黙のリトライをしまくってごまかすことにしました。
もともとつくりがシンプルだったせいもあって、ソースコードの半分近くが、エラーの検知やリトライのための処理で埋めつくされてしまうことになってしまいましたが、裏で何があろうと、表面上は何事もなかったかのようにしれっと動くようになりました。
きっとこういうのは何かの縮図なんだろうなとか、とりとめのないことを考えそうになりましたが、そういうのは早めに切り上げて、とりあえずこれでいいや、中くらいの、おらが世の春だと思うことにしました。
ところが、そうして一息ついたところを狙いすましていたかのように、さらにもうひとつ、新たな問題が浮上してきたのです ... 。
つづく。
D箱のアシスト事件
第4夜. トラブルぶくみ
この「Save to Tumblr」、ちょっと長めのテキストをポストするとエラーになるんですよね。しかも、毎回かならずというわけではなく、同じテキストでもエラーになったり、ならなかったりする。
クライアントサイド、YQL、Tumblr のどこでしくじっているのか調べてみると、どうも、YQL が怪しい。 怪しいのはわかるんですが、かといって YQL にそれ以上、手の出しようもない。
そんな状態でモンモンとした日々を過ごしていたところ、なにかの拍子に、Dropbox の API に HTTP で PUT するメソッドがあるのを知ったんです。
よく REST なんていいますけど、あんまり PUT ってお目にかかれないもんですから、すこし関心を持ちまして、 これを使えば、公式アシストの Save to Dropbox のように、(勝手な想像ですが、) アプリの内部にファイルを作成して、それをマルチパートでポストするというやり方じゃなく、DraftPad のテキストを Javascript 製のアシスト経由で直接送信できるんじゃないか？ しかも、任意のフォルダに、任意のファイル名で？ なんて考えました。
トラブルぶくみではありますが、YQL に頼れば、やれることはやれるはず。Dropbox の場合でも、やっぱり Tumblr と同じようなエラーが出るものか試してみたくもあり、今度は、Dropbox にテキストをセーブするためのアシストを作ってみることにしました。
どんなふうに動くものなのかは、前々回でご紹介したとおりです。途中、OAuth がどうしてもうまくいかずサジを投げかけました。でも本当に投げてしまう寸前で、Dropbox の Developer Forum に 「 signature_method を PLAINTEXT にしてみ？」なんて、まあ、ほとんど呪文のような書き込みを見つけて、なんとか乗り切ることができました。そんなかんじで、Tumblr のときよりもだいぶ苦労はしたのですが、なんとかひととおり、目標にしていた機能を実装することができました。
さて、実際に手にとってみると、最初の回に何やらクドクドと書き連ねたような意味で、これは、ぼくの DraftPad ライフにうまくフィットしていくものだということがすぐにわかりました。気がつくと、夢中になって無限の一枚の紙をちぎりまくってました。道具のほうじゃなく、自分のほうがグーンと延長していく実感がありました。
... しかし、やっぱり Tumblr と同じ問題が起きてしまうのです。
その上、Dropbox の API は https でつなげないと使えないんですけど、YQL と Dropbox の間で SSL 通信を確立する際のものと思しき通信エラーが頻発して、そのままでは、とても実用に耐えられない状態なのです。
長いテキストが扱えないというのはまだしも、何か操作するたびに、しょっちゅう通信エラーが発生してしまうのはいくらなんでもいただけないでしょう。
そこで、幸い、というべきかどうか、諸々のエラーは確率的にしか発生しないので、暗黙のリトライをしまくってごまかすことにしました。
もともとつくりがシンプルだったせいもあって、ソースコードの半分近くが、エラーの検知やリトライのための処理で埋めつくされてしまうことになってしまいましたが、裏で何があろうと、表面上は何事もなかったかのようにしれっと動くようになりました。
きっとこういうのは何かの縮図なんだろうなとか、とりとめのないことを考えそうになりましたが、そういうのは早めに切り上げて、とりあえずこれでいいや、中くらいの、おらが世の春だと思うことにしました。
ところが、そうして一息ついたところを狙いすましていたかのように、さらにもうひとつ、新たな問題が浮上してきたのです ... 。
つづく。
2012年2月7日火曜日
D箱のアシスト事件 第3夜
特集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 するアシストを作れたことに。でも、でもですね ... 。
つづく。
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月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日金曜日
兌換電子通貨トークン
中央銀行は、一定の現金通貨をストックし、ストックした個々の紙幣、硬貨に一対一で対応する兌換電子通貨トークンを発行する。
中央銀行は、兌換電子通貨トークンを保持するためのおサイフアプリを無償で提供する。
人は、いくつでもおサイフアプリを持つことができる。
人は、自分のおサイフアプリに入っている兌換電子通貨トークンを、他の人の特定のおサイフアプリに移すことができる。
おサイフアプリは、新たに保持する兌換電子通貨トークンに自らに固有のシグネチャーを付与する。保持をやめるときはシグネチャーを削除する。
中央銀行は、ストックしている通貨に対応する兌換電子通貨トークンに付与されたシグネチャーを、つねに把握している。
人は、自分のおサイフアプリに保持している兌換電子通貨トークンを、対応する現金通貨と交換することができる。
さっくり、こんな仕組みがもしもあってくれたならば、電子マネーといえども、その使い勝手は、フィジカルなマネーとほとんど変わるところがなくなる。と、信ずる。
つまり、アカウントレスで、プライバシーともきれいに切れていて、大人も子供も関係なく自分の経済的境遇に応じて出し入れできて、支払いの手続きに特別な数字の入力も必要なくて、支払い方法で囲い込まれたり、売買がつねに三者間取引としてしかあり得ず、いつもなんだか釈然としない手数料が上乗せされるなんてことのない、それこそ、みんながずっと慣れ親しんできた、ごくふつうの、自由な市場経済。
この水準のプラットフォームを提供するのは、産業資本主義でやっていく国民国家の機能のうちでも、コアの部類でしょう。なんで放任なんだろう？
ん。いやいやいやいや、大丈夫、大丈夫。狂ってるのは僕のほうぢゃないよ。
中央銀行は、兌換電子通貨トークンを保持するためのおサイフアプリを無償で提供する。
人は、いくつでもおサイフアプリを持つことができる。
人は、自分のおサイフアプリに入っている兌換電子通貨トークンを、他の人の特定のおサイフアプリに移すことができる。
おサイフアプリは、新たに保持する兌換電子通貨トークンに自らに固有のシグネチャーを付与する。保持をやめるときはシグネチャーを削除する。
中央銀行は、ストックしている通貨に対応する兌換電子通貨トークンに付与されたシグネチャーを、つねに把握している。
人は、自分のおサイフアプリに保持している兌換電子通貨トークンを、対応する現金通貨と交換することができる。
さっくり、こんな仕組みがもしもあってくれたならば、電子マネーといえども、その使い勝手は、フィジカルなマネーとほとんど変わるところがなくなる。と、信ずる。
つまり、アカウントレスで、プライバシーともきれいに切れていて、大人も子供も関係なく自分の経済的境遇に応じて出し入れできて、支払いの手続きに特別な数字の入力も必要なくて、支払い方法で囲い込まれたり、売買がつねに三者間取引としてしかあり得ず、いつもなんだか釈然としない手数料が上乗せされるなんてことのない、それこそ、みんながずっと慣れ親しんできた、ごくふつうの、自由な市場経済。
この水準のプラットフォームを提供するのは、産業資本主義でやっていく国民国家の機能のうちでも、コアの部類でしょう。なんで放任なんだろう？
ん。いやいやいやいや、大丈夫、大丈夫。狂ってるのは僕のほうぢゃないよ。
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)