中小W: 深夜、家に帰る途中のWebディレクター

D箱のアシスト事件第7夜 ( 最終回 )

noreply@blogger.com (takahashihideki) — Sat, 11 Feb 2012 11:11:00 +0000

特集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 ユーザー限定の永遠のプライベートベータ版としてやっていくことになりました。

もしこのアシストを使ってみたいという方がいたら、ご自身のリスクで以下からどうぞ。今のところ、あと3枠残っています。(すでに利用可能枠は埋まってしまいました...。2012/02/19 takahashihideki)

Away のインポート

Away 説明書

早いもの勝ちですよ。で、試してみたけど、こんなのやっぱりいらないや、という場合は、お手数ですが、Dropbox のアカウント管理画面の「マイアプリ」のページから、Away を削除してください。他の人が使えるようになりますので。

さて、これでぼくの話はおしまいです。なんだか情報量に乏しい、たんなる身の上話みたいになってしまいましたが、最後までお付き合いいただき、どうもありがとうございました。では、ちょっとせつないエンディングテーマを聞きながらお別れしましょう。

さようなら。

♪ D箱のアシスト事件 - エンディングテーマ: 誰も知らない / ラフィータフィー

おわり。

D箱のアシスト事件第6夜

noreply@blogger.com (takahashihideki) — Fri, 10 Feb 2012 10:50:00 +0000

特集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箱のアシスト事件第5夜

noreply@blogger.com (takahashihideki) — Thu, 09 Feb 2012 13:14:00 +0000

特集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 に入れて持ち歩いていました。そして、暇さえあればそれをとり出しては眺め、結局途方にくれて、ただ、ため息ばかりついていました。

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 ちゃん。いいよ、もういいよ、わかったよ。そっちがそうくるなら、こっちにも考えがある。はじめ腹の底のほうに生まれた黒い情念の塊のようなものが、みるみるうちに全身に満ちていくのを感じながら、ぼくは自分が今、はっきりと笑っていることを自覚していました ... 。

つづく。

D箱のアシスト事件第4夜

noreply@blogger.com (takahashihideki) — Wed, 08 Feb 2012 14:30:00 +0000

特集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箱のアシスト事件第3夜

noreply@blogger.com (takahashihideki) — Tue, 07 Feb 2012 11:50:00 +0000

特集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箱のアシスト事件第2夜

noreply@blogger.com (takahashihideki) — Mon, 06 Feb 2012 10:40:00 +0000

特集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箱のアシスト事件第1夜

noreply@blogger.com (takahashihideki) — Sun, 05 Feb 2012 13:44:00 +0000

特集DraftPad/短期集中連載
D箱のアシスト事件

第1夜. DraftPad とセーブ

ファイルでもアプリでもない、あえて言うなら、永久に不滅の作業バッファ？いや、DraftPad と呼ぶほかはない、テキストのヘイヴン。一枚の紙だから、New も Open もない。一枚の紙だけど、一種のタイムマシンでもあって、過去の好きな時点の状態にいつでも戻ることができる。だから、Save だっていらない。

それが DraftPad の哲学で、ぼくはその哲学がとても好きだ。好きだ、好きだ、好きなんだ。どうしようもなく好きなんだ。

それにひきかえ、どうだ。ファイルシステムだって？すべてを「新規作成」し、「保存」し、「開く」世界。

いや、まあ、それもいいだろう。しかし、なんでもかんでも、いちいちその調子で押し通す必要はなかったんだ。むしろ、ほとんどのことは DraftPad 的に済ますことができたはずだ。すっかり騙されていた。

特に、セーブだなんてひどいじゃないか。

それは本当に、救い出すという意味だった。気取ったメタファーなんかじゃない。いつ消えてもおかしくないまぼろしのような作業バッファから、大切な成果を、もっと安全な場所に小まめに救い出しておく必要があった。

句点を打ったり、段落を変えたりするたびに、指が勝手に動いて、ほとんど無意識のうちにセーブしてしまう。心身の延長としての道具ではなく、いつの間にかこちらが、道具の延長になっていた。

そんな悪夢を見せられていたぼくらの目を覚まし、そこから救い出してくれたのが DraftPad という発明だ。もはや作業バッファこそが安息の地、ここからどこかにセーブすることのほうが危ない橋を渡ることのように思えるくらいだから、もうそれをセーブと呼ぶのはおかしい。

ところが、セーブという言葉にはもうひとつ、いまあるものを手放さずにとっておく、というニュアンスも含まれていて、この安息の地に立ってみると、そちらのほうの意味がぐんと際立ってくる。

無限に拡がる一枚の紙に書かれた言葉は、けっして失われてしまうことはないけれど、ただ、書けば書くほど、それらは次第に遠ざかっていく。紙は無限だけど、ぼくには限りがある。ぼくの手が届く範囲なんて、たかが知れている。

すると、無限の一枚の紙の、いま書いたところだけをビリっとちぎって、ちょっとわきにとっておき、必要になったらいつでもさっと手元に戻すことができるような、そんなセーブをしてみたくなる。

それは、そう、いまならタギングとか、スナップショットをとるとか、そんなふうに呼んだほうがふさわしい行為かもしれない。でもいいだろう、あえてセーブと呼び続けようじゃないか。言葉はおなじだけど、意味するところはすっかり変わってしまった。そこに、DraftPad の凄みを感じていくことにしよう。

――― と、そんなわけで、ぼくは、そういう意味でのセーブを、 DraftPad に付け足してみたくなったのです。

つづく。

DraftPad 1.5.2
対象デバイス: all
カテゴリ: 仕事効率化価格: ￥0
販売業者: Manabu Ueno

もしもボックスのデザイン

noreply@blogger.com (takahashihideki) — Fri, 19 Aug 2011 07:44:00 +0000

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

このように、手の込んだ仕掛けが考えられなければならないのは、(私にはそのメカニズムを理解し説明する能力はないのだが、おそらく、)もしもボックスが、恐ろしく危険な道具であるからだろう。ユーザーの心身にとっても、この世界にとっても、濫用は禁物なのである。

そしてまた、それほどに、電話でものを頼むのは、じつに面倒なことなのである。

青葉台式 Multiple Toggle スイッチ

noreply@blogger.com (takahashihideki) — Tue, 05 Jul 2011 17:41:00 +0000

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 スイッチ」と呼ぶことにします。以後、画面仕様書では一本引き出し線を引っ張って、青葉台式、と断るだけです。

クーパーのデジタルスープ

noreply@blogger.com (takahashihideki) — Mon, 21 Feb 2011 19:56:00 +0000

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、デジタルスープはじまり。と見ましたが、如何。

兌換電子通貨トークン

noreply@blogger.com (takahashihideki) — Thu, 11 Nov 2010 18:09:00 +0000

中央銀行は、一定の現金通貨をストックし、ストックした個々の紙幣、硬貨に一対一で対応する兌換電子通貨トークンを発行する。

中央銀行は、兌換電子通貨トークンを保持するためのおサイフアプリを無償で提供する。

人は、いくつでもおサイフアプリを持つことができる。

人は、自分のおサイフアプリに入っている兌換電子通貨トークンを、他の人の特定のおサイフアプリに移すことができる。

おサイフアプリは、新たに保持する兌換電子通貨トークンに自らに固有のシグネチャーを付与する。保持をやめるときはシグネチャーを削除する。

中央銀行は、ストックしている通貨に対応する兌換電子通貨トークンに付与されたシグネチャーを、つねに把握している。

人は、自分のおサイフアプリに保持している兌換電子通貨トークンを、対応する現金通貨と交換することができる。

さっくり、こんな仕組みがもしもあってくれたならば、電子マネーといえども、その使い勝手は、フィジカルなマネーとほとんど変わるところがなくなる。と、信ずる。

つまり、アカウントレスで、プライバシーともきれいに切れていて、大人も子供も関係なく自分の経済的境遇に応じて出し入れできて、支払いの手続きに特別な数字の入力も必要なくて、支払い方法で囲い込まれたり、売買がつねに三者間取引としてしかあり得ず、いつもなんだか釈然としない手数料が上乗せされるなんてことのない、それこそ、みんながずっと慣れ親しんできた、ごくふつうの、自由な市場経済。

この水準のプラットフォームを提供するのは、産業資本主義でやっていく国民国家の機能のうちでも、コアの部類でしょう。なんで放任なんだろう？

ん。いやいやいやいや、大丈夫、大丈夫。狂ってるのは僕のほうぢゃないよ。

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

noreply@blogger.com (takahashihideki) — Wed, 03 Nov 2010 07:12:00 +0000

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

DraftPad のそのすてきなハブ性は、いうまでもなく、URL スキームによるアプリ間連携を積極的に活用しようという Assist 機構によるわけですけれども、このあたり、ほんとに美しいデザインですよね。シンプルなフレームワークで無限の未来=拡張性を切り拓く、みたいな。

だってこの機構のおかげで、たんに DraftPad でしたためたテキストをほうぼうに投げるとか、よそで漁ったテキストを手になじんだまな板と包丁としての DraftPad に乗せるとかだけじゃなくてね、調子に乗ればちょっとしたテキストフィルター機能みたいなのを自分でこしらえて、生の DraftPad をオレゴノミにカスタマイズしちゃう、なんてこともできるわけです。

たとえば、tweetする前にテキストに含まれる URL を、bit.ly の API を使って短縮するとか、どうでしょう。

下記のような javascript をちょこちょこっと書いて、ネット上の適当な(自分だけがこっそり知っているような)URLで公開してですね、これを DraftPad の Assist で呼べばいけます。

var uid    = "your uid";
var apikey = "your api key";
var bitly  = "http://api.bit.ly/shorten?version=2.0.1&login=" + uid + "&apiKey=" + apikey;
var text   = decodeURIComponent( window.location.search.substr( 1 ) );

$( function () { 

  if ( text ) {

    var longurls = text.match( /https*:\/\/[^\s]*/g );

    $.each( longurls, function () { 
    
      bitly = bitly + "&longUrl=" + encodeURIComponent( this );
    
    });

    $.getJSON( bitly + "&callback=?", function( data ) {
      var keys = [];
      for ( key in data.results ){
        text = text.replace( key, data.results[ key ].shortUrl );
      }
      sendToDraftPad( text );
    });

  }

});

function sendToDraftPad ( text ) {

  window.location.href = "draftpad://insert?text=" + encodeURIComponent( text );
  window.close();

}

# 冒頭の "your uid" のところに bit.ly アカウントのユーザーネームを、"your api key" のところに API Key を入力します。あと、jQuery1.4を使ってます。

DraftPad の Assist はこんなかんじですね。

ex) 上記のコードに、sample.com/foo.html としてアクセスできるようにした場合。

http://sample.com/foo.html?<@@>

かんたんですね。

最初はどっかにホストして、生意気にも bit.ly のサードパーティづらで、みんなで使えるようにしてみようかななんて思ったんですが、javascriptで自分の API Key 晒すのもナニですし、かといって、Assist に利用者各自の API Key を埋め込んで投げてもらうのも、セッション ID 入りのクエリパラメータつきで Get リクエストするのとほぼ同等の脇の甘さになるんで、やめました。

でも、やっぱりこれ、ちょっと便利みたいなんで、かんたん導入キットを用意してみました。(クエリパラメータつきのURLを正しく短縮できない不具合を修正しました。2010年11月4日 13:31 追記。...すみません。)2KB の ZIP ファイルです。を解凍すると、shorten.html と assist.html という2つのファイルが展開されます。

shorten.html の "your uid" と "your API Key" のところを書き換えます。API Key は、bit.ly の「Settings」のところに出てます。

assist.htmlのほうはいじる必要はありません。

で、この2ファイルをどっか適当なところにアップロードしてください。

assist.html のほうにアクセスすると、「Insert Assist」というボタンが表示されますからタップしてください。あなたの Draft Pad に「Shorten Links for DraftPad」という Assist が導入されます。お気に召すかどうかわかりませんが、よろしければ Your Own Risk でどうぞ。

以下、2011年11月5日追記。

とかいってたら、あっという間に、DraftPadの公式Assistに"Shorten URLs"というのが登場しました！これならみんなかんたんに使えます。すばらしい。ぼくもこっちに乗り換えます。

まあ、どうしても自分のアカウントで、というムキのために、上の野良アシストもそのままにしておきますか。

追記、ここまで。

いやあ、とにかく、DraftPad はすごいですよ。

魔法のページカール

noreply@blogger.com (takahashihideki) — Wed, 08 Sep 2010 12:35:00 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ね。

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

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

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

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

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

iPhone で Web ページを電子書籍風にビューするブックマークレット

noreply@blogger.com (takahashihideki) — Fri, 02 Jul 2010 12:16:00 +0000

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

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

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

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

noreply@blogger.com (takahashihideki) — Thu, 08 Apr 2010 14:34:00 +0000

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 に入るわけですけど、要するに具体的なイディオムの使い方指南なんですよね。検索、アンドゥ、保存、入力、選択、ウィンドウ、各種のコントロール部品、メニュー、ツールバー、ダイアログ、エラー、警告、確認 ... といったイディオムの数々。ここも言語アナロジーにのっていえば、"文章読本"みたいなかんじですね。そう思ってもうしばらく読み進めてみることにします。

アンデッドメタファー

noreply@blogger.com (takahashihideki) — Thu, 25 Feb 2010 18:53:00 +0000

About Face 3 読書ノートの 26 。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それが、次のやつで。

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

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

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

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

以上です。

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

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

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

BlogPressLite

noreply@blogger.com (takahashihideki) — Tue, 16 Feb 2010 13:47:00 +0000

ひとつ前のエントリーは、この間手に入れたばっかりの 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 追記)

不確かなメタファー

noreply@blogger.com (takahashihideki) — Tue, 16 Feb 2010 12:03:00 +0000

About Face 3 読書ノートの25。

いろいろと文句の多いアラン・クーパーと About Face 3 のみなさん、回を重ねるごとにますます意気軒昂ってわけで、今度の標的はメタファーかぶれのデザイナーなのです。

なんか、正しいメタファーを見つけることが仕事だなんて思ってるヒトたちっていますね。バカデスネ。なんて調子で、今回は、ちょっと冷笑的な態度で始まります。

そりゃ、ユーザーに内部の仕組みまで学ばせるような実装丸出しデザインよりはだいぶマシ。ただどうも、インタラクションデザインにおいてメタファーは過大評価されすぎているんじゃないかって。

うまいメタファーがあれば直感的に使えるようになるというけれども、冷静に考えてみて、インターフェースの学習を効率化する上でメタファーが果たす役割って案外ほんのちょっとじゃない？その割に、じつは弊害の方が結構多くって、あんまり利口なやり方じゃないと思うなあ、なんて言ってます。

たとえば、いまだによく見かけるフロッピーのアイコン。あれ、「保存する」ことを表現するメタファーってわけだけど、しかし今時フロッピーなんて、ねえ？若い子はもうそんなの見たことないだろうし、扱ってるファイルの容量からしても現実に見合わなかったり。下手したら保存先なんてネットワークの彼方かもしれないのに。

だから、作業結果を保存したい時はこれをクリックするんだってことを学ぶのに、もはやあの絵柄はまるで役に立ってないでしょ。たぶん、ツールチップかなんかで機能との対応を確認してみんな済ませてるんじゃない？

今でもあの絵柄の意味するところにへんに拘ると、考え込んだ挙句、なにか別のことを期待しちゃうかも知れなくて、かえってインタラクションデザイン上よろしくない。じゃあ、フロッピーよりももっとふさわしいメタファーを他に探せったって、これが案外難しい。

フロッピー的な発想はそのままで、もっとモダンなものをっていうと、ハードディスク？だけど、フロッピーと違って滅多に手にするものじゃないから、みんなが一発でそれとわかるような絵柄を決めるのは難しそうだし。

じゃあ、保存先のメディアじゃなくって、もっと概念的な、そうそう、ファイルとかフォルダってのは？って、そんなのもう「新規作成」とか「ファイルを開く」で使われちゃってるし、そんなら、デスクトップ・メタファーからも離れて、保存する、永続化するってことを表すみんなにお馴染みのイメージを探せって、えー、そんなのあります？なんてことになっちゃう。

まあ、しかし、なんだかんだで、あの絵柄と機能の対応を学んだ後では、とりあえず、その意味するところはあまり深く考えず、たんに他と区別するための記号として役立ってもらえればいいかと、そんな付き合い方になるんだろうけど、そういうのはメタファーじゃなくて、修辞学的にはシンボルって言ったほうがいいんじゃないの。

シンボルはその形状に頼ってシンボライズされる何かを表象するわけじゃない。形状と表象される内容の結びつきは恣意的なもので、その結びつきはそれとして学ぶしかない。って、あれ？メタファーを使うことの意味は、機能や目的を意識的に学ばずとも直感することじゃなかったっけ？

それに、フロッピーのメタファーなんて、それひとつだけとってみれば、非常にささやかなもんだから、シンボル的なものへの変わり身も早く済むだろうけど、こんなこと →
http://www.answers.com/topic/magic-cap になってたらどうする？シンボル的なものとして付き合うったって、あまりにも余りが多すぎるってなもんじゃない？

なんて、あのちっちゃいアイコンひとつつまみ上げて、軽くこんなかんじです。そういっぺんにいろいろ言われても、ぼくら、ただ圧倒されるだけでイヤハヤ、なんて心細くなってきますけれども ( だいぶ勝手に行間を読みまくった結果と言えばそれまでですが ) 、心配御無用、メタファーのなっとらんところを突き詰めると、だいたい次の四つのポイントにまとまるって話なんです。

クーパーは言います。( たぶん、両手を広げて肩をそびやかし、吐息まじりにノンノン言いいながら ... )

1) メタファーは足りない

いっとくけど、われわれの日常的な言葉づかいにメタファーは潤沢に溢れかえっているし、メタファーの効用はとてつもなく大きなものダヨ。About Face 3 に書いてあることなんてメタファーだらけだしネ。メタファーなしで同じ内容を人に伝えろって言われても困るヨ。

でも、インターフェースを学習するための方便としてはどうカナ？

アイテムの購入とか、リファレンスの検索、フォーマットの設定、写真解像度の変更、統計分析の実行 ... こういうアクションにぴったりのメタファーを探せって言われても、けっこうドンピシャのを見つけるのってムズカシくないデスカ？

あるいは、プロセスだとか、データやオブジェクト間の関係性だとか、なんらかの形式の変換だとか、いってみればコンピュータならではの物事って一体どんなメタファーで表現すればいいのカナ？

インタラクションデザインでいうメタファーって、たいてい、機能や目的を簡単な絵で表す、いわゆるビジュアルメタファーのことなのネ。

そうすると、当然、関係性だとか抽象的概念だとか、絵に書きにくいものは扱いにくいってことになるネ。で、わざわざコンピュータやらシステムやらを使って人間がやりたいことって、ケッコウそういうものが多いんダヨネ。

それにサ、そもそもワレワレがこれからデザインしようとしているモノは、三次元的な限界からも、機械化時代のパラダイムからも解き放たれた、人びとに力を与える全く新しいナニカなワケでショウ？

そういうモノを、そういうモノがなかった段階の物事で喩えようなんて、土台無理な話じゃナイ？

インターフェースデザインに使えるメタファーって、だからほんのチョットしかなくて当たり前なのヨ。

2) メタファーは通じないこともある

何が当たり前って、これこそホントに当たり前ッチャー当たり前の話ダケレドモ。同じ絵を見ても文化的背景が異なれば全く正反対の意味を読み取られてしまうこともないとはいえないよネ？

仮に文化的背景は共有していたとしてもダヨ、人それぞれの考え方、感じ方の違いってのはどうしても残るしネ。たとえば、デザイナーが飛行機の到着時刻をチェックするために用意したアイコンが、ユーザーには、飛行機のチケットを予約するためのアイコンに見えたりネ。

こんな不確かなものをインタラクションの基盤に据えようなんて、ネェ？やっぱりヤバイと思うヨ。

3) メタファーは変化についてこれない

フロッピーのことで言った最初の問題、そして最大の問題はこれだネ。みんながよく知ってる現実世界の何かとシステムの機能や目的の照応関係が、いったんは上手く馴染んでも、システムの成長や進化に、コレマタ当たり前だけどその現実世界の何かの方はついてきてくれないのヨ。

言い換えれば、メタファーにはスケーラビリティがないってことなんだけどネ。

喩えにも使えるほどみんながよく知ってる事柄ってことは間違いなくそこには不変性があるんだよネ。一方、システムのほうはその本性としてどんどん進化しちゃうのネ。

だから、システムとメタファーの恋ははじめから叶わないサダメなの。カナシイネ。

4) メタファーはすぐに邪魔になる

インタラクションデザインにおけるメタファーの役割はサ、意識的な学習なしで、直感的に、システムの目的や機能を把握できるようにするためにあるんだよネ。

じゃあサ、メタファーで伝えたかったことを把握しちゃった後はどうなのヨ。中級者にとっては、必ずしも必要のないお節介になりかねないよネ。

メタファーとしての役割を終えたら、ひっそりと、一種の識別子として生きていくのは、メタファーの処世術としてアリだと思うケド、インターフェース全体の隅々まで一貫して統一されたメタファーで説明しきるやり方、いわゆるグローバルメタファーみたいなヤツだとヤッカイダヨ。さっき出てきた MagicCap がそうだネ。下手すると、いつまでも消えない初心者向けウィーザード並のオーバーヘッドになってしまうヨ。

... と、とりあえず以上です。言われてみれば、たしかにごもっとも、イヤなるほどねぇーってかんじなんですが、じゃあ、一体なんだってそんなメタファーってやつがこんなに幅をきかせているんでしょうね？

そのことについて About Face 3 は、「インターフェースは直感的に使えるのがイチバン」という定言命法にいつの頃からかデザイナーが盲目的に従ってしまっているからだ、と言っています。「チョッカンテキってナンダヨ？」って。

インタラクションデザインにおいて「直感的」であるということは、そもそもどういうことか？About Face 3 による説明を勝手にまとめるとこんなかんじになります。

直感とは、意識的に行われる思考を伴わない判断や洞察のこと。意識的に行われる思考を伴わないという点では、直感と本能はよく似ている。しかし、本能がまさに生まれつきによってこの場での意識的な思考をキャンセルするのに対し、直感は、過去に別のところで行われた学習に基づいてそうする点が異なる。

つまり、ゴミ箱のアイコンがあれば、不要なデータはそこに放りこめばいいのだと「直感的」にわかる。ただし、それがわかるのは、現実世界において、ゴミはゴミ箱へ捨てるということをすでに学んでいる人だけだってことですね。

で、ここからがかっこいい。

インタラクションデザインにおいてメタファーを使うってことは、過去にどこか別の場所で行われた、人それぞれの学習の結果に頼ることではないのか？それは、あまりにもアンコントローラブルな状態であって、本質的なところで「デザイン」とは相反するアプローチなのではないか。

... って、そこまでは言ってないか。でも、まあ、そういう方向で意気込んでですね、できるだけ、もっと正々堂々と、インタラクションの現場、デザインの力がおよぶ範囲で決着をつけたらどうかとAbout Face 3 は言うんです。

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

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

ツールのエクスペリエンス

noreply@blogger.com (takahashihideki) — Wed, 20 Jan 2010 17:21:00 +0000

About Face 3 読書ノートの 24。

Chapter12 「よき振る舞いのデザイン」は、クーパーの関白宣言とでもいうべき内容です。おれより先に寝てはいけない式の戒めを一方的にまくし立ててます。一言で言えば、ソフトウェアは思慮深くあれってことなんですけど、例によって、一言で言い切ってすっきりしちゃうような人じゃないわけです。

こんなかんじなんですよ。

おれに感心を示せ、敬意を払え。

常に先を見て、常識と洞察力を働かせながら、おれのニーズを予測しろ。

おれに必要な情報はちゃんと示せ、でも、うるさく質問はしてくるな。

いたずらに不安がらず、トラブルは穏便に収めろ。自分の問題でおれに負担をかけるのはやめろ。

なんでも用意周到にこなせ。ときにはルールを曲げなきゃならないことがあることも知っておけ。

そして、責任は全部おまえがとれ。

って、ね。こう書いてみるとすごいですよね。つい、続けて、

おれに感心を示せ、敬意を払え。
おれに感心を示せ、敬意を払え。

なんて、勝手にサビをつくって歌いたくなってきます。

まあ、いろいろ好き勝手言っているようですけれども、言わんとするところをよく読んでみると、ここで要求してることの数々は、A.よく気がつく子の特徴と、B.気だてのいい子の特徴に二分できそうなんですよね。すなわち、

＜A.よく気がつく子だよ＞
先が見える
ニーズを予測する
用意周到である
洞察力を持つ

＜B.気だてのいい子だよ＞
ユーザーに対して関心を持つ
ユーザーに敬意を払う
ユーザーに必要な情報を提示する
あまり質問しない
常識を知っている
穏便にエラーを収めることができる
ルールを曲げるときを知っている
自分の問題で他人に負担をかけない
自信を持っている
責任をとる

これ、B.のほうは、ツールとして現場に出てくるときには、当然あらかじめ身につけておいてしかるべきビジネスマナーってかんじですよね。

ツールとしてどんな仕事をするのかはともかくとして、ツールである以上、人間様に対してとるべき態度は自ずと定められている。あるいは、特定のユーザーや状況に奉仕する星の下に生まれついたのであってみれば、身の処し方にもやっぱり一定の規範というものがある。

だから、デザイナーはペルソナやらシナリオやらでツールの境遇を追い込んで、目当てのユーザーに気だてのいい子だよとかわいがってもらえるような振る舞いのパターンを身につけさせようとするわけですよね。その子の器量、つまり、ツールの使用価値の大元のところとは別の水準の話としてね。（あれ、だんだん政治的に正しくないかんじの表現になってきちゃったかな。）

一方、A.のほうはちょっと違う。先、予測、用意、洞察って、これ、どれもまず相手の反応を見なきゃ始まらないですよね。コール＆レスポンスの反復の中から少しずつ確度を上げていくしかないようなもんじゃないですか。一体こんなことをあらかじめデザインすることなんてできるんでしょうか。

でも、about face 3 は言うわけです。コンピューターなんだから、もっとユーザーの操作をせっせと記憶したり推論したりしてもいいはずだろうと。それではじめてよく気がつく子にもなれる。で、そこのところに本気で取り組むとすれば、じゃあ一体何をどんなふうに記憶するのか、そしてどんな推論を働かせればいいのかってことが問題になるわけだけど、そこにひとつ、デザインのしどころがあるんじゃあるまいかって。つまり、あらかじめ拵えておけるのは、気がつく能力自体じゃなく、気がつける能力だってことですよね。

ユーザーにどんな体験をしてもらうかってのをユーザーエクスペリエンスデザインと呼ぶなら、これはいわば、ツールエクスペリエンスデザインですね。操作される体験のデザイン。

いい道具ってのは使い込んでいくうちに手に身体に馴染んでくるなんてよくいいますけれども、あれ、使うほうが道具に合わせて使い方を馴らしていく一方で、道具のほうも、使われ方によって微妙に変形したりしてくるもんなんでしょうね。

誰かが使い込んだギターには弾き癖のようなものが残っていて、ちょっと触るとすぐわかるなんて、このあいだテレビで char が言ってました。

そういう、よい道具の特徴みたいなのを、ソフトウェアやデジタル製品にも持ち込むことはできないかって、そういう話として理解してもいいんじゃないでしょうか。これ。

about face 3、それこそ周到なことに、コンフィギュレーションとはまたちょっと違うんだ、なんて注意まで促してるくらいで。

具体的には、まず、ユーザーが入力すべき価値のある情報は、すべて記憶すべき価値のある情報でもあるなんて前置きをしながら、次の3点に着目して記憶をデザインしなさいと言ってます。

・よく入力される値

・あるオブジェクトについて直前に行われた指示や選択

・ユーザーにとっては実質的にひとつの操作として見えているはずの作業手順

そして、推論を行う際に従うべき指針としては、「ほとんどのときにほとんど正しい」という蓋然性重視のスローガンを打ち出しています。

まあ実際、サジェスト機能だの、よく使うページ/ファイルだの、ファイルを開く・保存するっていったら、前に選択したフォルダが開くだの、そうした思慮深さの恩恵はすでに当たり前のものになりつつあるわけですけれども、いざ、そのあたりを自分でデザインすることになったらですね、ただそうした局所的なデザインパターンに従うだけじゃなく、ああ、これはこのツールが一体何を体験するかについてのデザインなんだよなあ、なんて頭で取り組んでみるといいかもしれないですよね。

ひょっとしたら、みんながびっくりするような、本当に気がつくよい子にしてあげられるかも知れません。
-----------------
sent from W-ZERO3

モーダルを選ぶキリコ

noreply@blogger.com (takahashihideki) — Wed, 06 Jan 2010 19:09:00 +0000

ぼくは今、総務部のおじさんたちのためのアプリケーションのことを考えている。彼らに与えられた仕事にかかる負荷を軽減しつつ、それでいてその効果を最大化することが求められている。そこで、ぼくはクーパーに習って、まず、彼らのゴールを探る。彼らのエンドゴールは、求められたことを、過不足なく、つつがなくやり遂げることである。エクスペリエンスゴールは、なるべくそれに煩わされることがなく、ほとんど機械的に済ませてしまえることである。ライフゴールは、だから、そんなつまらない仕事はさっさと終えて、もっと生き生きとした時間をより多く過ごすことである。つまり彼らは、これからぼくが考えるアプリケーションと共にする時間をなるべく短くしたいと考えていて、これ以上短くならないのなら、なるべく楽に、心を亡くしても無事にやり過ごせるようなものにしてほしいと願っている。

彼らはしかし、けっして馬鹿でも子羊でもコンドルの自由を知らない被抑圧階級の一員でもない。ただ、彼らの人生全般において、ぼくがこれから考えなければいけないアプリケーションのすべてが、クーパーのいう間接税にすぎないというだけのことだ。彼らの本当のライフゴールを支える道具は他にきっとある。

クーパーのゴールダイレクテッドデザインとは、反面から捉えていえば、間接税的操作の排除、もしくはその最小化だと言い換えていい。そのためのペルソナでありシナリオだ。しかし、自分がデザインしようとしている道具がまるごと間接税扱いされてしまう事態には触れていない("間接税的なポスチュア"というものもあるのではないか？)。ぼくはおそらく、総務部のおじさんたちのために、クーパーが忌み嫌う、徹頭徹尾モーダルな、ウィザード風のインターフェースを提案してしまうだろう。

この話の筋は、ひょっとすると、ドクターキリコの安楽死肯定論に似ているかもしれない。人の一生をもっと大きな何かの前で相対化することがキリコのニヒリズムだったろう。しかし皮肉なことに、キリコの最期はブラックジャックのヒューマニズム（人の一生の全体化）に感じ入りつつ、誰かの全体のために我が身を犠牲にすることで訪れる。(いや、ぎりぎりのところで、結局、ブラックジャックに助けられてしまうんだった！)

キリコのかたわらに、本間先生が姿を現してくれることはきっとなかったんだと思うよ。
-----------------
sent from W-ZERO3

単斜グループって何ですか？

noreply@blogger.com (takahashihideki) — Fri, 25 Dec 2009 13:44:00 +0000

About Face 3 読書ノートの23。

About Face 3 に、階層構造（特にフォルダの中にまたフォルダがあるような、同じ種類のオブジェクトの入れ子構造）はふつうの人には理解しにくく、取り扱いも難しい。それよりも「単斜グループ」を使ったほうがいい、みたいなことが書いてあるんです。

単斜グループ？何それ？

説明を読めば、それが、階層を持たない一列の並び、ということで、現実世界でいえば、本棚やファイルキャビネットのようなものだとわかります。

Webでは、下記のサイトで説明が読めます。

Monocline grouping (Global Constant)
http://globalconstant.wordpress.com/tag/monocline-grouping/

「A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy)」

ってね。

しかし、これがなぜ「単斜」なんでしょう？地学で「単斜構造」といえば、

weblio 石油/天然ガス用語辞典単斜構造
http://www.weblio.jp/content/%E5%8D%98%E6%96%9C%E6%A7%8B%E9%80%A0

「地層が、ある広がりにわたって、おおむね同一方向に傾斜している地質構造をいう。」

ってことで、

http://commons.wikimedia.org/wiki/File:Monocline01.gif (wikipedia commons) ← こういうことですね。

結晶の単位格子の種類にも「単斜晶」というのがあって、

http://commons.wikimedia.org/wiki/File:Monoclinic.svg (wikipedia commons) ← こういうことですよ。

これらに共通しているのは、まあ、一方向に傾斜してるってことですけど、About Face 3 がいう monocline grouping にナナメは関係あるの？

本棚がスカスカで本がナナメになっちゃってるって？

なんかぜんぜん腑に落ちないんですよ。ところが、前のエントリーを書いているとき、monocline 単斜と、mono な cline は違うのか？と、思いまして、cline を調べてみたところ、

Google 英語辞書
http://www.google.co.jp/dictionary?langpair=en|en&q=cline&hl=ja&aq=f

「a series of similar items in which each is almost the same as the ones next to it, but the last is very different from the first」

こう出ました。

つまり、先頭から後尾にかけて、要素の性質がだんだん変化していく配列みたいなことでしょう。生物学の用語として連続変異とも訳されるようですね。

こっちのほうが、About Face 3 と Global Constant が説明している monocline grouping にフィットしませんか？

もっとも似ている者同士が隣合うように並べておいて、類似度の差が大きくなっているところが、グルーピングの境目だと心得ておく。

階層なんてややこしいことは考えず、そうしたひと並びの列にモノをしまっておいたほうが、人にはやさしいというのが monocline grouping でしょ。

というわけで、どういうつもりでクーパーが monocline という言葉を選んだのか、英語ネイティブが monocline と聞いてどんなイメージをまず心に抱くのか知りませんが、とりあえず、monocline grouping を、「単斜グループ」と訳すのは、ちょっと不適切なんじゃないかと思うのですがどうでしょう。

じゃあ、何と呼べばいいか？もう、「クラインなかんじに並べとく」って言うしかないかな？でも、クラインとかいうと変な形の壺が目に浮かぶしな ... 。

ぼくらの純インタラクションを守れ

noreply@blogger.com (takahashihideki) — Thu, 24 Dec 2009 14:33:00 +0000

about face 3 読書ノートの22。

about face 3 に、まるで一大スクープのように、

「ナビゲーションは間接税的な操作だ」

なんて大きな見出しを打っている箇所があります。

そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。

そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、

(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)

1.移動。アプリケーションを構成する複数のウィンドウ間、あるいはウィンドウ内の複数のペーン間の。

2.探索。ツール、コマンド、メニュー、あるいはオブジェクト、コンテンツ、データの。

3.切替。オブジェクト、コンテンツ、データを表示する範囲または粒度の。

と、こう列挙されるわけですよ。

あらためてこれらのひとつひとつに思いを馳せてみてください。ユーザーエクスペリエンスなんつって、ほとんどナビゲーションがらみで埋め尽くされているようなもんじゃありませんか。

これが全部、ゴールに直接向かうわけではない、間接税的な操作だっていうんですから、たとえ400円になったとしてもタバコのほうがよっぽど良心的なかんじがします。

で、思うんですよ。じゃあ、ナビゲーションじゃない、無税の、つまり真にゴールダイレクテッドなインタラクションって逆に何？

上のナビゲーションの定義に習って思いっきり大きく出ると、オブジェクトとかコンテンツとか、とにかく何らかのデータの表現を確認して、これになにか手を加え、その結果、データがどんなふうに変化したのかをまた確認すること、この往復、循環、ってことになるでしょう。

ナビゲーションのタイプのうち、上記の2.も3.も抜いてですよ、ほんとにそこだけ純化して取り出したら、これ、非常に僅かな、希少なもんなんじゃないですか。これを純インタラクションとでも呼んで、どっかに含有率を書いといてほしいですね。

いや、しかし、だからといって、虐げられた民びとよ立ち上がれ、今こそこの圧政に反旗を翻せ、とかって話じゃないんですよ。だってこれは、いわば、その純インタラクションの本性がもたらしている宿命ですからね。逃れることはできません。

つまり、僅かとはいえ（いや、含有率とは関係なく）、純インタラクションの全体は、デバイスの表示領域に入りきらないほどデカいわけです。だから常に部分的にしか取り扱うことができず、そのために上記の移動、探索、切替が必要になっちゃって、結果、インタラクションのほとんどがナビゲーションになってしまうということですもんね。

ほんとにもう、インタラクションデザインって、この宿命をどう受け入れるかについてのデザインだと言い切っちゃいたくなるくらいのもんで。ですから、インタラクションデザインの戦術レベルでの指針は、ユーザーの視覚、認知、記憶、運動にかかる負荷を下げ、フロー状態を良好に保つってことだと思うんですが、そうする上で障害として立ちはだかってくるのは、大抵、ナビゲーションがらみということになるはずです。

そのために、--- つまりナビゲーションの氾濫から純インタラクションを守るために --- about face 3 が立てた作戦はこうです。

●永久オブジェクト

どんなにシステムの状態が変化しても、けっして消えてなくならないものを用意し、これを一番はじめに印象づけておこう。

永久オブジェクトこそ、すべてのナビゲーション起点であり、次にとりうる選択肢を常に示している道しるべであり、そして、いよいよというとき、最後に頼るべき縁でもあります。

たとえば、システムと同じ寿命を持つトップレベルのウィンドウ、グローバルナビゲーション、デバイスの物理的なボタンとかね。

●位置情報

全体像と現在位置をいつでも知ることができるようにしておこう。

その方法は、今、まさに部分的に取り扱っているオブジェクトの性質に合わせて、いろいろな手口を考えておく必要があるでしょう。

たとえば、Webサイトならブレッドクラム。画像編集ソフトなら、現在表示している範囲を縮小された全体像中に矩型で示すオーバービュー。ウィンドウシステムでは、現在表示している位置と範囲を、全体に対する相対的な長さで表現してもいるスクロールバーとかね。

●自然な対応関係と構造

純インタラクションにおいて、ゴール達成を容易にするための交換条件としてまあまあ見合う、ということならともかく、一介のナビゲーション風情が、自分のために新しいものの見方や習慣をユーザーに押しつけるなんてことがないようにしよう。

ありがちなのが、車のウィンドウを開閉するボタンが縦一列に四つ並べられている場合、右後部座席のウィンドウを開閉するには何番目のボタンを押したらいいでしょうか？ --- 的なレイアウトの対応関係にみられる鈍感さ。

あるいは、時系列のソーティングの方向を、「昇順」「降順」というデーターベース用語で選ばせるような、ラベルと機能の対応関係にみられる普通の人にとっては不自然な実装モデルの押しつけ。

それから GoF のコンポジットパターンのような、同型のオブジェクトが入れ子になるような階層構造なんかも、マトリョーシカ的な玩具以外に現実世界ではまずありえなくて不自然。そもそも、ほとんどの人は深い階層構造を辿るような移動、探索、切替を現実世界で体験したことがない、とかね。

●ペルソナへの適応

連れていくべき場所、ユーザーが見つけなくてはならないオブジェクト、ツール、データを減らす、というか、そのうちでも、普段から意識しておくべきものを極力減らしておこう。

簡単に言えば、いつもそばにあるものと、深いところに隠しておくものとに仕分けること。仕分けの基準は、

・使用頻度
・労力と報酬の見合い
・転位の度合い（その操作によってデザイン対象の状態がどれほど大きく変化するか？）
・危険度（失敗した場合の取り返しのつかなさ）

となるんですが、いずれも、ペルソナの性質、ニーズ、ペルソナが活動するコンテクストに深い関わりを持ちます。言い換えれば、ペルソナに合わせてインタラクションを整理してみようってことです。

よく使うものは当然、いつもそばに置いておきたいですよね。注意したいのは、深いところに隠しておくもの。これには、深いところに隠して"おいても"いいものと、隠して"おいたほうが"いいものと二種類ある。

労力と報酬の見合いがとれ、（かつ、それほど頻繁に使わないものなら、）深いところに隠して"おいても"いい。

転位の度合いや危険度が高いものについては、一般に、深いところに隠して"おいたほうが"いい。とかね。

こうして、実際にはその数を減らすことはできなくても、なるべく、なるべく、ナビゲーションのやつらにユーザーの心を奪われないように気をつけて、ユーザーの心に占める純インタラクションの割り合いをもっと上げていこうよ、ということですね。

純インタラクション --- そう、今夜は特別に、My Sweet Soul Interaction って呼ぼう。My Sweet Little Interaction のほうがいいかな？

ツールのニーズ

noreply@blogger.com (takahashihideki) — Fri, 11 Dec 2009 03:22:00 +0000

About Face 3 読書ノートの 21。

「ゴールの達成には直接的には貢献しないが、それをしなければゴールを達成できない」ような作業を About Face 3 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。

PCでいえば、まず、ソフトウェアをインストールしなくちゃいけない、ネットワークの設定をしなくちゃいけない、OSが拡張デバイスをうまく認識するように設定してあげなくちゃいけない、ファイルのバックアップのことを心配しなくちゃいけない、とっちらかったフォルダを漁って目的のファイルやアプリケーションを探し出さなくちゃいけない、ウィンドウの位置やサイズがしっくりくるようにいちいち調整しなくちゃいけない、初心者向けのおせっかいなヒントを一撃必殺の早業で消したり、いつまでもご親切なウィザードにつき合わされなくちゃいけない、煩雑な画面から必要な情報を、過剰な装飾の中から操作可能な領域を発見しなくちゃいけない、ナントカデスクだのナントカタウンだの、回りくどい喩えと機能の対応を推し量らなくちゃいけない、今、目の前に表示されている登録済みのメールアドレスを変更するために、わざわざ特別な画面に出向いて行かなくちゃいけない、理不尽であるか、あるいは取るに足りないささいな事柄に関する警告に悩まされ、挙げ句の果てに、さもこちらに落ち度があるかのように扱われる屈辱に耐えなくちゃいけない、って、いっきにまくし立ててみましたが、これみんな間接税的な作業の具体例として、About Face 3 が告発していることです。

そして言います。こういうの全部、いってみりゃアンチゴールダイレクテッドなインタラクションでしょ、できることなら根こそぎ取り除きたいよね。それが無理なら、せめてできるだけ目立たないように、できるだけの手を打ちたい。そのためにはまず、こういうことに意識的に、そして、敏感にならなきゃだめだよね、と。

なにかにつけ、そんなことがめんどくせえようなら死んじまえ、が口癖だった父に恐々としながら育ったぼくは、だから、生来、インタラクションデザインには実は不向きなのではないかとも思うのですが、ま、しかし、生まれつきや三つ子の魂だけでやっていける人生なんてないわけですから、ここはひとつがんばって、年齢不問で成長していきたいです。

さて、そう思って、間接税的な作業について取り上げているChapterを何度も繰り返し読んでいると、こうした間接税的な作業を生む温床には次のようなものがあることが自ずと腑に落ちてきます。

ひとつ、ユーザーの習熟度の多様性を無視すること
（中上級者をいつまでも初心者扱いするとか）

ひとつ、ポスチュアのあり方に無頓着であること
（本来、支配者的なポスチュアであるべきなのに、単発的なポスチュアをとってしまうとか）

ひとつ、蓋然性より可能性を重視すること
（ほとんど起こらないことに備えて、普段の作業をぎこちないものにしたり）

ひとつ、フェイルセーフではなく、フールプルーフで対応しようとすること
（やり直しがきくようにできないものだから、失敗ゼロを目指して作業をがんじがらめにしたり）

ひとつ、実装モデルを押しつけること
（入力と出力はつねに別系統とか）

ひとつ、単にさぼること
（機械でできるはずの推論と記憶を放棄してすましているとか）

しかしこれ、間接税的、と表現するのはどうなんでしょうね。About Face 3 が念頭に置いているのは消費税的なものみたいですけど。いや、わかりますよ。商品の対価に交換価値、使用価値以上の部分がふくまれているかんじ。でも、税メタファーじゃ、売り手（ツール）、買い手（ユーザー）とは別に、上前をはねてるやつが他にいそうな雰囲気じゃないですか。しかし、ここで悪いやつだとつるし上げたいのは、政府みたいなものじゃなくて、目の前でいけしゃあしゃあと不当に値をつり上げてる店のおやじのほうなんですよね。

一方で、このChapterに「ツールのニーズ」という言葉が出てくるんですけど、こっちのほうが、この問題を言い表すのにふさわしいような気がしました。ユーザーのニーズじゃなくて、ツールのニーズ。

ニーズって、あらためて言うまでもないことですけど、要するに、ゴールに達っするために何かを必要とすることですよね。ゴールに自足的に達することができないとき、不足分を補う何かを他に求めること。

何か思い定めたゴールがあるとして、しかし徒手空拳ではかなわないので、人は何か道具を探す。自足的にゴールを達成できないので、道具に対するニーズが生じる。一方で、道具のほうでも、実はそれ自体としてあるゴールを持っている。それは、つまり、ユーザーのゴール達成を支援することですね。だからこそ道具は道具としてありえるわけですけど、そのゴールを自足的に達成できないとき（間接税的な作業を生む温床）、道具にもニーズが生じてしまう。つまり、道具のほうが、今度はユーザーを道具として使おうとするわけです。これが間接税的な作業の正体。

しかも、それをうまいこと、ユーザー自身の発意による、ユーザー自身のゴールに向かうための仕事であるように見せかけるんですよね。質が悪い。案外、インタラクションデザインって、この倒錯を巧妙にカモフラージュするテクニックとして発達してきた部分も少なからずあるんじゃないでしょうか。

だから、冒頭でまくしたてたようなことに対する感性を研ぎ澄まして、目ざとく告発できるようになったあかつきには、「それって、ツールのニーズでしょ？」というセリフで決めてみたいです。ぼくは。

-----------------
sent from W-ZERO3

みんなのフロー状態を大切にしましょう

noreply@blogger.com (takahashihideki) — Tue, 17 Nov 2009 19:15:00 +0000

About Face 3 読書ノートの 20。

なんか作業にだーっと夢中になっちゃって、気がついたら、うわ、もうこんな時間かよ！？ハラヘッター、みたいなことがあるだろう。そういうのをフロー状態っていうんだよ。と娘に話したら、ああ、ウラシマ効果？と返されました。いや、そのフロウじゃねえよ、って。しかし、まあ、でも、うん。そうだったらどんなにいいだろうね。だけど時間ってやつは誰の身の上にもじつに公平に流れては去っていくものなんだよ。娘よ。

だからこそ、フロー状態ってのは実にかけがえのない大切なひとときなわけで、いろいろごちゃごちゃいっとりますが、インタラクションデザインの要諦はつまり、いかにして人をフロー状態に導くことができるか、そして、いったん始まったフロー状態を途切れることなく全うさせることができるかにかかっているといってもいいわけですね。

そうしたインタラクションデザインの到達点を、About Face 3 は、オーケストレーションと表現しています。

といっても、なにも美しいプレイで人々を魅了しろっていうんじゃない。そうじゃなくて、ユーザーとのコミュニケーションがオーケストレーションになってなきゃだめ、つまり、全体的に調和のとれたものになってなきゃだめだよ、ってことなんです。

例によってそうするための原則がずらっと並んでいるのですが、かいつまんでいうと、複雑なものをうまくバランスして調和をとっていくっていうより、要するに必要以上に出しゃばるな、そうすりゃ自然に調和もとれるさ、ってかんじです。

たぶんね、ロールモデルは高倉健ですよ。これ。いわく、

「いかに優れたものでも、インターフェイスは少ない方がよい」
「オーケストレーションされたユーザーインターフェースは透明である」

しぶいですね。しびれますね。不器用なのはまずいかも知れませんが、美しい魅惑のプレイなんてのは真逆の話ですね。

もうすこし具体的な水準で、16個、原則が挙げられているんですが、読み込んでいくと、言いたいことは結局、次の４つのポイントに収斂していくようです。

・なるべく直接操作で
・なるべくモードレスに
・なるべく蓋然性に合わせて
・なるべく固まらないように

そうすると、必要以上に出しゃばらずに済む。それぞれどんなかんじかというと　... 。

■ なるべく直接操作で

インタラクションというと、双方向の対話的インターフェースってかんじがしますけれども、けっしてそうじゃないよと。

「理想のインタラクションは対話のようなものではなく、むしろ道具を使うのに似ている。大工が釘を打つときに、釘についての議論をハンマーとしたりはしない。ハンマーで釘を打つのだ。」

やりたいことをいちいち問い質されながらフロー状態に入れる人なんてそうそういないでしょう。

だから、初心者でなくなった後でも強要されるウィザード形式には閉口しますし、いちいち開くのが面倒な設定画面でしか目の前のオブジェクトを操作できないようなインターフェースでは仕事になりません。メニューを辿るという行為も、やりたいことをいちいち問い質されているようなもんですからね。

煩わしいし、なにより腹が立つ。May I help you? は、低姿勢なようでも実は上から目線なんですよね。おれはお前を使うことはあっても、助けてもらうつもりは毛頭ないってなもんです。ちなみに、About Face　3　は全編を通じて特にこの点に手厳しいんです。一体何があったんだとそれこそ問い質したくなるくらい。相当ご立腹の様子です。

■ なるべくモードレスに

人のせっかくのフロー状態を阻害するものの親分が、かの悪名高い「モード」ってやつなのかも知れませんね。

モードってのは、ひらたくいうと、アプリケーションがあるひとまとまりのタスクの遂行だけに特化した状態に入ることです。それはインタラクションをシンプルに見せかけたり、一連のインタラクションを通じたシステムやデータの一貫性を保つために、まあ、よかれと思って仕組まれてるわけですが、でも、その副作用がなかなか見過ごせない。

というのも、モードの中でタスクを遂行すること自体は立派にゴールダイレクテッドでも、あるモードの中に入ること、そこから出ること、他のモードに入ること、目下のモードが何であるか確認すること、こういったことは、ゴールの達成に直接貢献するわけではないんですね。

いってみりゃ、モードに頼ってゴールを目指す以上は、どうしても支払わなければならないコスト。入場料、通行料、税金みたいなもの。しかし、これらがやけに目だってきちゃうと、そりゃもう、本来の目的からは逸れているわけですからバンバン意識を寸断しちゃって、とてもフローどころではない騒ぎになります。

ぼくの理解では、16個の原則のうち7個は、このモード関連ですね。これらを読み込んでいくと、About Face 3 は、モードが発生しそうな箇所として暗に次の3つを念頭に置いているようです。

・オブジェクトの状態やプロパティを確認するとき
・ツールを切り替えるとき
・タスクの遂行結果のフィードバックを受け取るとき

オブジェクトのプロパティや状態の確認については、とにかくできるだけその場で、つまりモードのない状態で確認できるようにしたい。その場で確認しきれずモードに頼る場合でも、やっぱりできるだけ手近なところで。つまり、そうするために何段階もメニューを辿らなければいけないようなハメにユーザーを陥れないようにとアドバイスしています。

ツールの切り替えについては、もうこれはモードに頼るのもやむなし。しかし、やっぱりこれもできるだけ手近なところで、ですね。「机から立って廊下に鉛筆を探しに行くような」ことがないようにしたい。それから、繰り返しになりますが、ツールはあくまでも直接操作をモットーに。ツールを使うことの実態が質問攻めであるようなことはあってはならない。あと、使い終わったツールをユーザーに片付けさせるような真似もしちゃいけない。

フィードバックについては、とにかくモーダルなダイアログボックスの使用を極力控えよと、これに尽きます。タスクってのは、ツールによってオブジェクトに何かしら働きかけるってことなんですから、その結果は、オブジェクトのプロパティや状態の確認として、モードレスに察知できるのが一番。

ところで、インタラクションにおけるモードとモードレスに関しては、こちらに深い考察があります。

Modeless and Modal
http://modelessandmodal.wordpress.com/

結構なペースで日々更新されているんですが、これはぜひ、ドアタマから一読されることをオススメします。ぼくは大変お世話になっています。これを読んでなかったら、About Face 3 のこの章、「オーケストレーションとフロー」のところなんて、ちゃんと読み込めなかったかも知れません。

■ なるべく蓋然性に合わせて

蓋然性と可能性の混同はよくいわれますけれども。可能性はありえるかありえないか、蓋然性はありえることが実際に起こる確率が高いか低いかですね。

About Face 3 は、UMLのユースケース図って、各ユースケースが発生しうる確率を無視して、すべて同格で記述してしまうので、開発領域を明示することには向いていても、ユーザーをゴールへダイレクトに導くためのインタラクションをデザインするためのツールとしては向いていないとかいってますね。

一方で、コンテクストシナリオなら、ごく自然に発生しうる確率が高いユースケースに重点を置いて検討することができると。インタラクションデザインにおいては、蓋然性と可能性の混同は致命的だといわんばかりです。

蓋然性がらみで About Face 3 によく出てくる例は、何時間もかけて書いたドキュメントについて「保存しますか」とか聞くな！ってやつ。この状況で「保存しない」を選ぶようなやつがいる可能性はそりゃあるよ、でも、蓋然性はほとんんどないだろ？毎回そういうことを馬鹿正直に尋ねるんじゃないお前は、という話です。

こうした、ほとんど蓋然性のない状況に関わる質問やメニューもまた、ユーザーのフロー状態の邪魔になるんですね。必要になったらこっちから相談するから、それまで黙っててよ、ってかんじです。

また、About Face 3 は、印刷することを指示すると、毎回毎回、プリンタの設定を尋ねてくるのもいかがなものか、なんてことも言っています。プリンタの設定なんて一回したらそうそう変更するもんじゃないでしょ。と。コマンドを使用する蓋然性は高くても、コマンドのコンフィギュレーションを行う蓋然性は低い。もしそうなら両者は分離しておくべきじゃないか、とかね。

あと、非常ボタンの類、パイロットの脱出ボタンとか。これを使うことなんてめったにないんだから、また、うかつに触ると危ないんだから、FMラジオのスイッチとキャビンライトのスイッチの間に配置するなんてことは絶対やめてくれ、なんてね。

実は、今、これ、マンガ喫茶で描いてるんですけど、キーボードにPCの本体の電源を落とすボタンがついてて、それが普段会社で使っているキーボードだとDeleteボタンの位置にあるんですよ。さっきから書き損じを削除するつもりでPCを2回も落としちゃいました。しかも、確認画面は一切なしで、あれよあれよと。そこは、ほんとに落とすのかどうか聞いてくれよ頼むから！

まあ、そういうことです。

逆に蓋然性の高い状況に関する配慮はウェルカム。たとえば、操作履歴に基づいて、よく使うツールをより目立つところに置くとかね。

■ なるべく固まらないように

最後のこれはもう、言うまでもありませんね。上述の原則をきっちり守っても、何かする度にいちいち待たされたんじゃあフローもへったくれもない。仮に待たせるようなことになったら、そういう状態にこれから入ることをユーザーに正直に打ち明けて、ちゃんとキャンセルもできるようにしておくこと。

待ってもらえるならどれくらい待たせるかを明らかにして、だいぶ待たせることになるなら、ユーザーがその間どうか他のことでフロー状態に入ってくれるように祈ること。

ま、そんなところです。

また間違ってPCの電源を落としちゃわないうちに、今日はこのへんにしときます。

無名の質

noreply@blogger.com (takahashihideki) — Thu, 22 Oct 2009 12:47:00 +0000

About Face 3 の読書ノートのつづきで、次はデザインパターンのところを書こうかな、と思ったんですが、この部分、結構あっさりしてまして。

デザインパターンといえば、GoFのやつが有名だけど、インタラクションデザイン方面では「デザイニング・インターフェース」なんてのがあるよ。そもそもデザインパターンって発想はアレグザンダーの建築論からはじまるわけだけど、インタラクションデザインの場合は、うまく作るため、というより、みんなに喜ばれるものを作るためにパターンを活用しようという点で、GoFのやつ（ソフトウェア工学）よりアレグザンダーのもの（建築学）により近いよね。とかなんとか。

どうもここは、なるほど、としか言えそうもないのでしれっとスルーの方向で、ということにしたんですけど、ただ、そういえば、アレグザンダーのデザインパターンって実際どんなものなのか、急に気になってきたんですね。なんとなく話には聞いているけど、実はちゃんと見たことがなかったんです。

それなら、素直にアレグザンダー本を読めばいいんですが、ちょっとお高いので、まずは入門編をってことで「パターン、Wiki、Xp」を手にとってみました。

この本、デザインパターン、Wiki、エクストリームプログラミングのそれぞれの発展史なんですけど、アレグザンダーの思想がそれらに与えた影響を丹念に追っていくといった趣向で書かれているですね。だから、アレグザンダー入門としても読める。

読んでみると、アレグザンダーのことだけじゃなく、デザインパターン、Wiki、エクストリームプログラミングについても、知らないことばっかり書いてあって、結構、びびりました。

それぞれいっとき夢中になったものばかりなんですが、実際上の功利ばかり追いかけて、それらがよって立つ由来や思想的な背景に思いを馳せるなんてことはまったくなかったもので。それにしても、デザインパターンだけじゃなく、エクトリームプログラミングやWikiも、アレグザンダーの影響下にあったとは。隣の席の北橋くんから聞いた話だったら、うそつけ、このやろうの一言で片付けてしまいそうです。

この本によれば、デザインパターンやアジャイルな開発手法にも影響を与えたアレグザンダーの思想のキーワードは、「無名の質（QWAN, Quality Without A Name）」ってやつなんですね。

入門書を読みたての生半可をはじめにお断りして言いますが、アレグザンダーが「無名の質」と呼ぶのは、要するに、古い街並みにみられるような、おそらく時間をかけて自然に出来上がったと思われる、なんとも言えない具合のよさ、みたいなことです。

それは、うまく定義することができないし、はっきり名指すこともできない。しかし、その場に居合わせれば、たしかに感じ取ることができるので、あるある話としては、ずらっと具体例を並べ立てることができる。でも、それ全部ひっくるめて何て言うの？とあらためて問われると、やっぱりうまく言い当てることができない。年甲斐もなくはしゃぎながら「イーンダヨ、イーンダヨ、ナンダカワカンナイケド、スッゴクイーンダヨ！」と言って回るしかない。

でも、結局、デザインとして一番いいのは、そういうものなんじゃないかと。

そこで、アレグザンダーは、そういう「無名の質」を、なんとか人工的な建物物にも持ち込むことができないかと考えるんですよね。

自然の成り行きにまかせて「無名の質」が出来上がるのをただ待つのではなく、どうにかして人為的に生産してしまおうというわけですよ。じつに大それてますね。しかし、そうして、ソフトウェアのデザインパターンやアジャイル開発プロセスにもつながるような、さまざまな原則や実践方法を編み出していったんですね。

だけど、「無名の質」って、やっぱりちょっと釈然としませんよね。

どうしても名付けられない何かなんていっちゃって、それって、「考えるな、感じよ。」式の神秘主義か、見えない何かに賭けるロマン主義かなんかじゃないの。真理や奥義のチラ見せで弟子を引っ張っていこうなんて古い手だなあ！とか言いたくなる向きも、実際少なくなかったようです。

この本もだいぶそこのところにひっかかっていて、最後、あとがきのところでは、「無名の質」はやっぱり難解すぎるとしながら、

「アレグザンダーはおそらく「読者に自分で考えてほしい」と思っていたのではないでしょうか」

なんて小学校の道徳のようなことをいってます。

まあでも、よし、それじゃあってことで、ぼくも自分で考えてみましたよ。

以下、アレグザンダーの著作に直接当たることもなしにこんなことを言う資格がないことは百も承知で言いますが、Quality Without A Nameを、「名付けられない質」じゃなくて、「名前を持たない質」と考えてみたらどうなんでしょうね。

もっとベタに言うと、「名前がないという属性を持つ何かについての質」。

名前っていうのは、コンテキストに依存しないで、つねに同じ対象を指示できるものだとしますよね。(哲学に可能世界と固有名の議論がありますね。)

すると、コンテクストに依存することによってしか存在することができない存在があるとしたら、それは名前を持たない、持つことができないといえるでしょう。

で、コンテクストに依存することによってしか存在することができない存在って、またややこしい、何だよそれ？ってことになりますけど、それは、もうコンテクストそのものですよね。

そう考えると、無名の質って、簡単に言えば、コンテクストそのものとしか言いようのないものの質ってことじゃないでしょうか。

それのいいやつを、アレグザンダーは自分たちの力で意志的に作りたいって言ってるんでしょう。

しかし、コンテクストってのはやっかいですよ。

それは関係性の無際限な広がりのことだし、いろんな観点から観察できるけど、ある一点からの観察では全体を把握することができないような全体性のことだし、さらに、つねに一回こっきりのものだし。

これは再現や再生産の対象には到底なりえませんよね。

設計図や雛形をもとにして計画的に作れるようなものではない。設計図や雛形をもとにコンテクストそのものを人為的に作ろうなんていったら、それは神をも恐れぬ悪魔の仕業ですよ。

当然、アレグザンダーは悪魔ではないので、直接「無名の質」を作ったりはしないわけです。

ただ、現に「無名の質」を作り出している自然生成のプロセスをよく観察して、シミュレートしてみたらどうかと。長い時間をかけて積み重なったたくさんの偶然の結果としてある自然生成を、リーズナブルにシミュレートする方法を考えてみようと。

アレグザンダーがデザイナーとして直接手を下したのは、そこのところですよね。シミュレートをうまくやるために必要な道具と作業のデザイン。それができたら、自分でも自然生成のシミュレーション環境に飛び込むだけ。

* * *

って、どうです。これで丸くおさまっているかんじじゃないですか。

でも、いろいろググってみたかんじでは、これは確実に「無名の質」の誤読なんですけどね。