子供が Web のポケモン図鑑の各キャラクターの表示をデジタルカメラで撮影して、それを印刷して欲しいと言い出した。これはずいぶん tangible なアイディアだ。
元は mixi の日記に書いたものだったのだけれど、幾らか直して転載しとこう。
子供が Web のポケモン図鑑の各キャラクターの表示をデジタルカメラで撮影して、それを印刷して欲しいと言い出した。
90 キャラぶん、大量なんだけれど、まあどうやったら自分の欲しいポケモンカードが手に入るか、その経路を考えたのでヨシとして 9 up で A4 10 ページ出力した。
（我が家ではオモチャは滅多に買って貰えないので、欲しいものはとりあえず作れるかどうかを考える習性がある。）
まあそのうち自分でスクリーンショット撮って加工してプリントするんだろうなあ、と思ったのだけれど、、、、
しかしその操作は余りに非直接的で、非直感的だ。
子供（7歳坊主）が使っているデジタルカメラで画面を撮る、というのはその意味で非常に tangible なのだ。。。
やっぱりそうならなきゃいけない。
そうだ！コンピュータのスクリーンを撮影すると、そのとき表示されている画像が転送されてくる仕組みを作ればいいんだ！
だって被写体もかなりのものがもうデジタルなんだから。digital to digital でデータ交換で実現すればいいじゃない。
これをもう一歩進めると、いま動画が表示されていたら、それを動画のままデータ転送してクリップできる仕組みが作れる。
（ここで知人から光とか撮影位置とか環境条件が厳しそうだ、というコメントを貰う）
ああ、僕が書いた「コンピュータのスクリーンを撮影すると、そのとき表示されている画像が転送されてくる仕組み」は、ほんとに撮影した画面の画像情報から何かを取り出す、ということは考えていなくて、 1. コンピュータとカメラがネットワークでもともと連携しており、 2. コンピュータに対して、表示している「どのコンテンツ」を「いつ」切り出したいかを指示するために、 3. カメラを向けて、撮影範囲を決めて、シャッターを押す、 というインタフェイスを考えているのです。はい。
なので環境条件はかなり楽なはず。むしろ余りに逆光がきつすぎて写りが悪すぎる（何が写っているか全く判らない）場合は、ユーザーがカーテンするなり、手をかざすなりして対処すればいい。今でも普通にカメラを使うときは皆そうしてる。
逆にそういう実際的な対応を、従来通りの所作で実現できるところが tangible なアイディアの良いところだったりもするし。
いずれにしても最終的には「絵」などではなく、「データ（つまりビットの列）」として直接やりとりすべきだ、という事ね。
そして「データ」には付随的な情報（メタ情報）を付けられるのだから、それを活用すべきだ、というところに話はたどり着く。
これは being digital という何十年も前の本でニコラス・ネグロポンテが言ってた事で（bit の bit を活用しろ）、つまり僕らの世界はまだまだそこまで行ってない、という恐ろしい事実を示してるのね。。。
ところで web アクセスはメタ情報をたぐれる状態なので（構造化されたデータに直接アクセスできている）、ニコラスが描いた世界に近づいていることは間違いない。
しかし意外な事に今のパソコン自身は、自分たちが扱っているデータについて外部からのアクセスを閉ざしてしまっており、その点テレビ並みとも言える。
アプリの壁が高すぎるのだ。
（このアプリが独占的にデータを触る、というパラダイムに対するアンチテーゼとして、まずオープンなドキュメントがある、というコンパウンドドキュメントのアイディアは 80 年代から何度も提案されたのだけれど結局どれもうまくいかなかった。えーと何ていったっけ、HP に買収された NewWave、あと Apple のOpenDoc、TRON のデータフォーマット、などなど。）
つまりコンピュータは web サーバのように、いま自身がアプリを通して扱っているデータに対して、カメラのようなクライアントからの多様なリクエストに従ってデータ（とメタデータ）を渡していくようにならんとあかんのやろうなあ。。。
というわけで、誰かそういうカメラ作ってくれないかなあ。。。
（構造化データのスクラップブックインタフェイスと、Xanadu 的サーバ側データ構造、ということかな？なんか Xanadu って言うと一気にアヤシゲ度が増すけど、本人は至ってまっすぐ考えてるつもり。）
2011.09.20