新しい入力機器をブラウザの入力として使う場合のパターンを整理

それぞれのパターン

同列に比較するのは微妙な物もあるが、とりあえず一覧にした。

• パターン1. 機器 --> ブラウザ --> コンテンツ
  • 説明: ブラウザの機能として機器からの入力をコンテンツで受け取る
  • 例: DeviceMotion Event, Geolocation API, Touch Event, Device APIなど
  • 利点: ブラウザが対応していれば、利用者側に特別なアプリが必要ない。
  • 利点: コンテンツからDOM Eventの形で見える。w3cの仕様に定義されている場合がある
  • 利点: ブラウザでコンテンツごとの利用の可否を設定できる場合がある
  • 欠点: 新しいデバイスの対応には時間が掛かる

• パターン2. 機器 --> (アプリ) --> ブラウザの拡張 --> コンテンツ
  • 説明: ブラウザの拡張として機器からの入力をコンテンツで受け取る
  • 例: DepthJS, WiiRemoCom
  • 利点: コンテンツからDOM Eventの形で見えるようにできる
  • 欠点: ブラウザごとに拡張を作る必要がある

• パターン3. 機器 --> (アプリ) --> Flash --> コンテンツ
  • 説明: Flashを使って機器からの入力をブラウザのコンテンツで受け取る
  • 例: FlashによるWebカメラの利用, WiiFlash
  • 例: BLITZ Kinects to Flash with Node.js | BLITZ | Blog
  • 例: sd-tech: [Kinectハック] OpenNI+Flashでマルチユーザー・マルチタッチ　OpenNI解析編
  • 利点: ブラウザ非依存
  • 利点: Flashが単体で対応している場合、利用者に特別なアプリが必要ない
  • 欠点: ブラウザがFlashに対応しており、実行を許可している必要がある

• パターン4. 機器 --> アプリ --> Node.jsなどのローカルサーバーアプリ --> コンテンツ
  • 説明: ローカルサーバーアプリを経由して機器からの入力をコンテンツで受け取る
  • 例: Kinectを使ってブラウザのWebGL内を動いてみた - 最高のコンピューティング環境とは？
  • 例: WiiリモコンをNode.jsを使ってWebGL内で動かしてみた - 最高のコンピューティング環境とは？
  • 利点: ブラウザ非依存

• パターン5. 機器 --> アプリ -[マウス・キーボード入力]-> ブラウザ --> コンテンツ
  • 説明: 機器からの入力をマウス・キーボード入力に変換してブラウザに渡す
  • 例: NIA
  • 利点: ブラウザ非依存
  • 欠点: マウス・キーボード入力に変換できる入力しか渡せない

• パターン6. 機器 --> アプリ --> ブラウザView --> コンテンツ
  • 説明: ブラウザをコントロールとして利用するアプリで、ブラウザコンテントロールに機器から得た情報を渡す
  • 例: GREEのスマートフォン用サイト(カメラ連携)
  • 欠点: アプリケーションの作成にコストがかかる
  • 欠点: ブラウザとプラットホームに依存する

• パターン7. 機器 --> 機器のブラウザ --> コンテンツサーバー --> メインのブラウザ
  • 説明: 機器のブラウザを経由して機器からの入力をコンテンツで受け取る
  • 例: iPhone / iPod touch OS4.2をPCブラウザの加速度コントローラーとして使ってみた - 最高のコンピューティング環境とは？
  • 利点: ブラウザ非依存
  • 利点: iPhone / Androidなどをネットワークを経由して繋ぐことができる
  • 欠点: 機器とメインのブラウザのマッピングが必要
  • 欠点: 機器側にブラウザが必要
  • 欠点: 機器の入力がインターネットを経由するので遅延が大きい

一般化の流れ

一般化して広まるには、利用者の準備がないことが必要であり、下記の流れをたどる。

• ステージ1
  • 何か新しいことを試してみたい人達が、パターン2,3,4にて、いろいろな実験をする

• ステージ2
  • パターン2,3,4のうち、インストールの手間のない物(FlashによるWebカメラ対応など)は、一般化する
  • 役立ち共通化しやすい機器の入力が、パターン1となる

Node.js / WebSocket / WebGLとの関係

Flashが意外(?)に多用されているのは、ブラウザごとの拡張を作りたくない場合に、他に選択肢がなかったため。
Node.jsとWebSocketの普及により、ブラウザ非依存の方法としてNode.jsとWebSocketを使った方法が利用できるようになったが、利用者の手間が大きいため、実験目的外では一般化しないと思われる。

むしろ、Node.jsの今後の役割は、その先の、デバイス入力ができるようになったユーザーとサーバー間、ユーザーとユーザー間のやり取りに関する部分で大きい。
例えば、Kinectをつなげたユーザー間でのチャンバラゲームを作った場合、ユーザーの入力が素早く他のユーザーに反映させるためWebSocketが使われ、それを低リソースで簡単に実装できるプラットホームとしてNode.jsが利用される。
このように、加速度センサー・Kinect・HMDなどの入力・出力機器が広まり、それらを利用したリアルタイム性の高いWebアプリケーションが普及するにつれ、Node.jsやWebSocketの重要性は高まると予想される。

また、3次元の座標を利用する入力・出力機器が普及するにつれ、それらを利用しWebGLで表現したアプリケーションも増えていく。