「ボタンと、そのボタンが担う機能の対応関係」です。

ボタンと機能の対応関係パターン

僕の浅はかな経験と知識からだと、下の3つのパターンがあると思います。

ボタン：機能の対応が、

• 1:1　
• 1:多　
• 多：1

ひとつずつ、具体例を上げてみます。

1つのボタンが1つの機能しか持たない場合

ボタン：機能　＝　1 : 1 の場合ですね。

世の中の「ボタン」と呼ばれるものの大半がコレに当たると思います。
メールソフトで考えると、「送信ボタン」というのは、「メールを送信する」という機能のみを提供する、と行った具合です。

この対応関係は、そのボタンのアイコン（一般的にはビジュアルサインとでも言うんでしょうかね）と機能がよほどかけ離れていなければ、
ユーザーに取っては解りやすい、というか、間違用のないユーザーインターフェイスになるかと思います。

1つのボタンが、状況によって機能を切り替える場合

ボタン：機能　＝　1 : 多　の場合。

これも、かなり存在するパターンだと思います。

皆さんがいま、このブログを見ているブラウザ。　そのブラウザのスクロールバーの上向きボタンは、
1回クリックすれば、一回分ページが上方に移動します。

しかし、ボタンを押し下げっぱなしにすると、押し下げている間、上方にスクロールし続けますよね。

これは、1つのボタンで、2つの機能を提供していると言えるかと思います。

上記の例は、「ボタンの押し方」というパラメーターで、機能を切り替えているわけですが、
それ以外にも、「現在の状況」で切り替えるパターンもあります。

iPod等の音楽プレイヤーの「再生/一時停止」ボタンなんかがそれにあたりますね。

再生中に、「再生/一時停止」ボタンを1回押すと、一時停止します。
一時低中に「再生/一時停止」ボタンを1回押すと、再生を再開します。

同じ操作でも、今がどういう状況かによって機能が切り替わる例として身近なものなのではないでしょうか。

この「1:多」の場合、ユーザーに対して混乱を与えないようにするためにはいくつかの注意点があるかと思います。

1つのボタンが提供機能する機能を2つ以上にする場合の注意点

「再生/一時停止」ボタンが一般的であるのは、提供する機能が2つで、その各々が対になるペア的な機能である事が要因であると、個人的には考えています。

僕は日頃、「人間は、2つの事なら同時に理解できるような作りになっている」と感じてます。

高校の数学でも、2次元の事は一気に計算する方法を教わりましたけど、3次元に関しては一旦、1つの次元を無視した上で計算し、その後に無視した1つを復帰させて考えるという方法だったと思います。（ex : 二次関数と三次関数の解放手順とか・・・）

なので、2つまでは「できて当然」と思っていても、バチは当たらないのかな、と。

あとは、提供する機能が「真反対の機能」であれば、もう間違いなく理解してもらえるんじゃないでしょうか。
例えば、「再生/一時停止」ボタンではなく、「再生/次のチャプターへ」ボタンだったら、なんか直感に反して気持ち悪いボタンになってしまう気がします。

（あ、「なんか気持ち悪いボタン」っていうシリーズで作ってみるとオモロイかもしれないですね・・・）

複数のボタンが、同じ機能を提供する場合

ボタン：機能　＝　多：1　の場合ですね。

これは、具体例を探すのが結構大変なので、あまり一般的ではないようです。

僕が見つけたのは、

• 携帯の「十字キー」の代わりに、数字ボタンの2,4,6,8 で代替する
• キーボードのShift, Control Alt ボタン（Macは、、、殆ど使わないのでわかりません）

くらいですかね。

この場合に共通して言えるのは、
なんか、使いにくかったらもう一方のボタンを使ってねという作り手の心遣いだという気がします。

携帯の十字キーって、端末のデザインによってはスゴイ押しづらい場合があります。シューティングゲーとかをやってる日にゃあ、押しづらかったらクレームものでしょう。

そういう、物理的にそのボタンを押すのが困難な状況が考えられる場合に、押しやすい方で操作できるようにする。
これが、この「多：1」というパターンの使い時なわけですね。

それ以外に、この「多：1」を使う必要のある状況は・・・ちょっと僕は思いつきません。

むしろ、この「多：1」パターンは、やたらと使いまくるとただの解りにくいインターフェイスになってしまう危険性があると思います。

どこを押せばページが遷移するのか、不必要に選択肢が多い場合、使っている側で「ボタン：機能」の対応を理解していくのが困難になると予想しています。

例えば、
再生ボタンと停止ボタンと取り出しボタンが、各2個ずつ、見た目もそれぞれバラバラで、いろんな箇所に配置されてるDVDプレイヤー。

どこを押したらどうなるのかを理解するのがまず大変そうです・・・。

で、何が言いたいかというと

Webコンテンツのユーザーインターフェイスの使いやすさを考える時には、身近なもののインターフェイスがどういう思想で設計されているのか、
もしくは、定番のUIデザインの根底にある狙いや、なぜ定番となっているのかまでを考えてみないとイケナイなー、という事です。

実際の案件で、個人的な意見として「これは使いにくいでしょう・・・」というデザインのモノがあったのですが、
それがなぜ、使い辛いのかを説明することができず、議論にすら挙げられなかった事があります。

そういう時に、なぜ自分が使い辛いと感じたのかの理由が把握出来ていれば、解決策も提案できますし、
そうなれば皆で再度検討しなおす事もできますよね。

こういう、コミュニケーション能力を上げるための視点って、大事だなと痛感しました。

ようやく納品ラッシュが収束して、やっとブログ書ける精神的余裕が出てきた所のtak-tです。
いやー、大変だった。

そんな納品ラッシュの中でも、一応色々とニュースを拾い読みはしていたのですが、ボチボチ、次のネットの方向性を表すキーワードが出揃って来ているような気がしているので、個人的にまとめてみます。

HTML5

ま、これはもう何も言わなくてもいいと思いますが、HTML5の実験的サイトも色々と立ち上がってますし、策定も進んで来ては居るようですが、同時に不穏な情報も色々と出てきていますね。

Google のビデオフォーマットとか、
Web SQL の策定停止とか、

制作サイドとしては、HTML5でユーザーエクスペリエンスの向上が見込めるのは確かだと思うので、後はどれだけ制作スピードを稼げるのかが気になります。できるだけ、ブラウザ毎に挙動違うとか、止めて頂きたい・・・。

ビデオフォーマットに関しては、H264押しのappleに対する嫌がらせにも見えますが、利権周りがクリアなwebM規格に流れて行きそうな気がしています。圧縮的には、H264の方が優秀な気がするのですが、どうなるんでしょうか。

タブレットデバイス

日本では今週金曜日に発売のiPadをはじめ、DELLもHPも出すらしい、タブレット型デバイス。これがホントに一般層にも受け入れられるのかどうかはちょっと懐疑的なんですが、PC操作がキーボードとマウスで定着してから何十年、ようやくマウスから解放されるPC的なモノが出てきますね。

このデバイスだと、従来のマウスをウロつかせながら閲覧するスタイルのコンテンツが成り立たなくなるので、Flasherとしては今後もしこのデバイスが広まっていった時を考えて、今からどう作るべきか（ユーザーの操作をどう誘導するか）を想像して置かなければならないなー、と思っています。

Google TV

前の記事でも書きましたが、どうやら話は本格化しているらしいですね、Google TV。

しかも、メーカーとしてソニーとLogitechが協力関係にある、と。

紹介ビデオを見る限り、ユーザーが見ているコンテンツがテレビコンテンツなのか、ウェブコンテンツなのか、意識できないくらいにシームレスに視聴体験を提供できるシカケを作っているみたいですね。
既存の「ウェブも見れますテレビ」とは違う、と、自ら公言していますし。

もしこれが本当なら、ユーザー体験としては新しいものを提供できるのではないのかな、と思ってます。

リアルタイム

これも今更な感じですが、twitterに始まり、今ではwoopraというサービスが始まっています。

woopraは、簡単に言えば「リアルタイムのGoogle Analytics」で、テレビの視聴率の如く、今、そのサイトを見ているユーザーの数と地域と、その他情報がリアルタイムに観測できるというサービスです。

5年前くらいまでは、ウェブとテレビは全く違うメディアだ、という見解がほとんどだったと思うのですが、今やリアルタイムメディアとしてテレビに近づいていくという側面も無視できない状況なのかもしれませんね。。。

woopraに関しては、使い方や新たなサービスの形を自分が想像出来ていないのですが、「リアルタイムメディアとしてのウェブ」については、色々と思考を巡らせておく必要があると思っています。

クラウド特区

4月の日経新聞のトップに、総務省が日本に「クラウド特区」なるものを、北海道か青森に作るとありました。

海外では、データセンターを増築する時は貨物コンテナのようなものを新たに設置してその中にサーバを置くらしいのですが（温度調節設備アリで）、日本でこの手法を行うと、建築法的に色々と余計なお金が掛かるそうで、それを緩和した、特別区域を作りましょう、と。

「別に海外のデータサーバを使ったらいいじゃない」、とも思うのですが、例えば日本が今後クラウドコンピューティングを利用して国民のデータを管理するような事を考えると、大事なデータが外国任せになってしまうと、一体何をやられるのか解ったもんじゃないですよね。
実際、アメリカでは犯罪抑止のためなら個人データを見れるとか見れないとか（情報不確ですが）。

日本はクラウド技術に関しては出遅れているらしいんですが、一体どこまで巻き返しできるのか。　気になります。

まとまらないけど、まとめ

と、色々と気になってるキーワードを書き連ねてみました。

まだ上手く説明できないのですが、これらのキーワードは、どれも単独で存在しているものではなく、お互いがお互いを助長しあったり、抑制しあったりしながら、今後のウェブの方向性を決めて行くんではないのかな、と、勝手に妄想しています。

クラウド特区に関しては日本としては切羽詰った問題ですが、それ以外は、個人的には非常にワクワクしています。
あらたな体験を提供できる可能性があるということは、なんと楽しみな事でしょうか！

個人的には、AS3以外の言語をちゃんと勉強しようとしているので、何の言語を選ぼうか悩み中です。

HTML5でJSかなぁ、、、
それとも、Google App Engine でJavaかPythonかなぁ、、、
はたまた、iPadでObjective-Cか、もしくはAndroidでJavaかなぁ、、、

どれを選べば勝ち組に近づけるのやら。

少々大胆なタイトルを付け過ぎて、ちょっと後悔しておりますところのtak-tです。

僕は、日ごろの読書のほとんどが通勤電車内で、しかも専門書ばかりがほとんどなのですが、
そんな中、twitterで話題になっていた、非専門書を最近読みました。

クラウド時代と<クール革命>です。

一介のASerが何を壮大なテーマの本を読んでいるのだ！
だったら、日ごろのコードをもっとスマートにしろ！

等々、自問自答はしたものの、やはりこの5年くらいで何かが変わるのではないか、という空気を少しずつ感じては入るので、居ても立ってもおれず読みました。　

僕個人がこの本を批評したところで、なにもならないと思うので、本当に、思った事を羅列してみます。

コミケを生み育てた日本とその大衆は、やっぱりスゴイ

自分の知人には、大手出版社で働いているヤツがいるのですが、コイツがまた、どうしようもないくらいのオタクなのです。
家に遊びに行けばフィギュアが並び、滔々とその良さを語って聞かせてくれるのです。

その流れで、コミケについても聞いた事があります。
彼曰く、「あそこには、日本がある」、と。

最初、何を言っているんだコイツは、とバカにしていたのですが、この「コミケ」に関してもこの本は言及してありました。
要約すると、

日本は、コミケに対しては著作権的に寛容である。それなのに、You Tube に投稿されるMAD系動画を否定するのは如何なものだろう。

といった感じの内容。

なるほどなー、と感じました。

友人の話からも、そのコミケ内では「神」的な存在となってその才能を発揮している作家も多数いて、しかも彼ら・彼女らがプロとして活動する事もあるのだ、と聞きました。
著作権の保護は確かに大事なのですが、こういった流れを止めてしまうのも、日本としては非常に勿体ないというのは僕も感じます。

大衆から産まれたコンテンツは、やはり大衆のものとしておくべきですし、コミケが生まれる文化が日本の強みとなる可能性は充分にあるとも思いました。

海外クラウドに日本の全コンテンツを吸収されては困るよなー

この本には、クラウドを制した者が、「勝者総取り」で利益を受けるようになると書かれてます。（多分・・・）

現状、音楽の分野ではアップルがほぼ勝利を収めている気がします。ということは、日本で日本人アーティストの音楽をiTunesStoreで購入すると、日本の企業が儲かるはずだったお金の何割かがアップルに入るわけですよね。（短絡的ですかね・・・）

これは国としてはあまりよろしく無い流れというのは、経済に疎い僕でも、なんとなく分かります。

これから将来、音楽以外のコンテンツ（書籍内では映画が次のターゲットと書いてありました）が、海外クラウドで管理されていては、日本の文化的にも経済的にも良くないなー、と感じました。

特に、日本はコミケ文化があるわけで、そういったCGM的なコンテンツすらも海外クラウドに吸収されては元も子もないな、と。
なんとか、日本産のクラウド内に収めて置きたいという感情は、僕自身もこの本を読んで持ちました。

それが、日本の経済にどういう好影響を与えるのかは、イマイチ掴みとれてないのですが、クリエーター感情としては、いつまでも海外のサービスにお世話になってはいたくないな、というのは、ちょっと僕のナショナリズムの暴走でしょうかね・・・。

まとまらないけど、まとめ

僕には、この手の話題をまとめる力がまだ無いので、何か関連していそうで、気になる最近のニュースを貼りつけて、終りとさせて頂きます。

Google がテレビ端末を作る?!
NHK 放送記念日特集 <激震 マスメディア　～テレビ・新聞の未来～>
上記番組が利用した、twitterハッシュタグ
上記番組の”ウラ番組”としてストリーミング放送された番組の紹介記事

なんだか、NHK番組関係のリンクばかりですけど、結構タイムリーな話題だったので。

ちなみに、NHKの番組自体は再放送の予定があるそうです。
詳しくは、公式twitterアカウントをフォローしておくとよさそうですよ。　http://twitter.com/nhk_media

四の五の言わず、早速解説していきます。
Progression 4 の、WebConfig、および、BasicAppConfigを指定した場合として読んでください。

なお、この記事を読んだ後でも、そんなに幸せになれなかったとしても、当社では一切の責任を負いかねますのであしからず。

そもそも、ExecutorObjectってなによ？

Progression 3 でも、内部的には存在していた（と記憶してますが、曖昧です・・・）Executor系のインスタンスですが、バージョンが4になってから、表舞台に出てきました（アクセス制御子がpublicになった）。

で、ExecutorObjectが何者かというと、Cast系、Scene系のインスタンス内にプロパティとして存在していて、シーン遷移に同期した処理を上手いことやりくりしてくれているお方です。

シーン遷移と同期をとるために、Progressionではいろんなところで「addCommand()」というメソッドを使います。そのaddCommandメソッドが実行されると、実際のところ、ExecutorObjectインスタンス内にプロパティとして存在するSerialListコマンドに対してaddCommandが実行されています。

[Progression 4 CommandExecutorソースの該当部分]

public function addCommand( … commands:Array ):void {
//…
// 登録する
_current.addCommand.apply( null, commands );
}

_currentというのが、SerialListインスタンスです。
というこで、処理自体はSerialListが、諸々の管理をCommandExecutorインスタンスがやっている事になります。

さらに、ExecutorObjectインスタンスには target:IEventDispatcher というプロパティがあり、ここには、自身が管理しなければならない対象が保存されています。

targetが参照しているのは、ExecutorObjectインスタンス自身が保持されている、Cast系、Scene系のインスタンスです。

つまり、Cast系インスタンスと、ExecutorObjectインスタンスには、相互に参照しあっている状態です。

お互いがつながっている状態で、それぞれ処理を委譲しあって、上手いこと処理を同期させている、くらいの感じで理解しておけば大丈夫だと思います。

で、Do Executorコマンドでどう幸せになるのか？

シーン遷移と同期したアニメーションを実装していくと、色々なパターンに遭遇します。

• 子シーンに行く時は、メニュータブが隠れる。
• 子シーンから、自身シーンに戻ってきた時は、メニュータブがニョキッと現れる。
• 自身シーンの親シーンに行く時は、表示ツリーから削除するためのアニメーション後、実際に削除。

こういった場合に、Do Executorコマンドが真価を発揮します。

実際の使用方法を見る前に、ちょっとDoExecutorコマンドのコンストラクタを見てみましょう。

public function DoExecutor(executor:ExecutorObject,event:Event,initObject:Object = null ) {
// 引数を設定する
_executor = executor;
_event = event;
// スーパークラスを初期化する
super( _executeFunction, _interruptFunction, initObject );
}

第1引数にExecutorObjectインスタンス、第2引数にEventインスタンスがあります。

これは、Do Executorコマンドがexecuteされると、ExecutorObjectインスタンスのexecute()メソッドが実行されるのですが、その際に、Eventインスタンスが必要だからです。

[DoExecutorコマンド内　executeメソッド内]

// イベントを送出する
_target.dispatchEvent( _event );
// 状態を変更する
_dispatching = false;
// 処理を実行する
if ( _executeFunction != null ) {
_executeFunction();
}
else {
_executeComplete();
}

ここまでソースを追えばなんとなく解りますかね。

ExecutorObjectが管理しなきゃいけないターゲット（Cast系、Scene系）に対してイベントを発行して、ターゲット内でリスナが実行されたのち、ExecutorObjectの実行関数が実行される、という流れです。

ExecutorObjectの実行関数は、サブクラスで定義されます。
今回の場合のサブクラスはCommandExecutorインスタンスなので、その実行関数を見てみると、

private function _executeFunction():void {
if ( _current ) {
//…
// コマンドを実行する
_current.execute( super.extra );
}

となっています。　_currentは、SerialListです。

つまり、流れを追うと、

• DoExecutor実行
• targetにイベントが発行
• target内のリスナが実行される。
• リスナ内でaddCommandをすると、実質、executor.addCommandが実行される。（実質、_current.addCommand）
• ExecutorObjectインスタンスのexecuteが実行される（実質、_current.execute）

となっている、と。

で、実装してみる

ここまで仕組みがわかれば、後は簡単です。
Castインスタンスで、特定のイベントに対してリスナを登録して、あとは、そのイベントをつかってDoExecutorを実行すればいいだけです。

まず、Cast系インスタンスにリスナを登録します。イベント名は適宜わかりやすい感じで。
僕は、atCastAddedのタイミングで登録してます。

//CastHogeインスタンス(CastSprite継承)
override protected function atCastAdded():void {
	addEventListener("show", _onShow);
	addEventListener("hide", _onHide);
	addEventListener("defaultIn", _onDefaultIn);
	addEventListener("defaultOut", _onDefaultOut);
}
//リスナ実装。内部では、atCastAdded同様、addCommandが使えます！
private function _onShow(e:Event):void{
　　　addCommand(
            new DoTweener(this, {alpha:1, time:0.5})
      );
}

で、実行する時は、シーンオブジェクトにて、

override protected function atSceneLoad():void{
    new AddChild(container, _castHoge).execute();
    //自身のシーンへ到着する場合は、defaultIn
    if(manager.destinedSceneId.equals(sceneId)) {
        addCommand(
		new DoExecutor(_castHoge, new Event("defaultIn"))
        );
    )
   //子シーンへ行く時は、隠れるアニメーション
  if(sceneId.contains(manager.destinedSceneId)){
         addCommand(
                new DoExecutor(_castHoge, new Event("hide"))
        );
  }
}

的にやれば、動・・・・・きません！！

こ、ここまで読ませておいてなんなんだ！

となった方には、動くように僕が改変したDoExecutor2コマンドクラスを配布致します。
DoExecutor2.as

動かない理由は、Cast系のexecutorプロパティは、表示ツリーに追加されるまではnullだからです。
つまり、コマンド登録時にはnullなので、動かない、と。

なので、そこを改変して、実行時にexecutorの参照を取りに行くように変えてあります。
（といっても、既存のソースをコピーしてるだけなんですけどね・・・）

さて、長々と書きましたが、これでどなたかのProgressionライフが幸せになる事を願いつつ、
僕は再び仕事へ戻ります・・・。

負けない！

先日、Google から発表された新サービス、Google Buzzを、早速使ってみました。

色々なところで噂されてるのは、「Google 版 Twitter って事じゃん」という事なんですが、
自分のPCで使ってみても、Twitterと対して変わらないなー、という印象です。
しいて言えば、Gmail作業をしながらBuzzチェックができるのが多少良い点くらい・・・

でも、Google 周辺事情をちょっと調べてみると、このサービスの狙いは別のところにある気がしてきました。

Google Buzz は、モバイル分野に主眼を置いたサービスなんではないでしょうか。

Google自身が指揮をとって開発した携帯端末、Nexus One。
米国では既に発売されているようで、Googleサイトから購入して、SIMカードを挿して任意のキャリアで使う、という事ができるらしいです。

Google自身が端末を販売するという事は、モバイル環境に居るユーザーの情報を集約したい、という意図があるんでしょうかね。

Google voiceというサービスも米国では開始されていて、
個人がもってる複数の電話番号を1つに統合したり、音声の留守電がテキスト化されてメールで来りできるみたいです。

このサービスが日本でサービスインした場合に、日本人ユーザーに馴染むのかどうかは不明ですが、
電話が大好きだという国民性があるらしい米国では、ひょっとしたらニーズがあるのかもしれません。

このGoogle voice の、「音声のテキスト化」というのが、今回のGoogle Buzz と連携して、音声でBuzzを投稿できるようなんです。

つまり、海外のAndroid携帯ユーザーは、まさに、リアルに声でつぶやくと、Buzzれる事になります。
このお手軽感は、ひょっとしたら海外では前向きな評価を受けるんじゃないでしょうか。

PC環境ではイマイチな印象のGoogle Buzz ですが、Googleの目的としては
モバイルユーザー（というか、Google voice ユーザー）のリアルタイム情報を吸い上げたいんだと、勝手に予想しました。

現段階で、twitterのTLをBuzz内に取り込めるようにしてあるのも、その意図からなんだと思います。

Buzz自体が広まるためには、Androidが広まらないとダメだと思うので、twitter vs. Buzz という図式は、
やや的外れなのかなー、と。

個人的には、Androidには大きな期待を持っているので、これから発売開始まで、ワクワクが続きますね。

業務中にはFireFoxを使ってばかりだったんですが、最近挙動が重い気がして、
ここ数日はもっぱらChromeを使っております。

そこで、twitter経由で同業種仲間に教えてもらったのですが、
Chromeの次期バージョンのベータテスト版から、色々なプラグインを使えるという話を聞いたので、
早速インストールしてみました。

ダウンロードはこちら。

所感としては、挙動がサクサクと早いのはもちろん、プラグインも既にかなりの数が出揃っていて、
個人的にはかなり好感触です。

僕がインストールしているプラグインは、以下です。

• Chromed Bird — twitter プラグイン
• ChromeMilk — タスク管理のウェブサービス「Remember the Milk」と連動するプラグイン
• Firebug Lite — firefox版でおなじみのデバグツール、fireBugの簡易版
• Google Mail Checker — gMailにメールが来た時に教えてくれるプラグイン
• Hatena Bookmark — はてな公式のはてぶプラグイン

特に使い勝手がいいのは、Chrome Bird と Hatena Bookmark ですね。

情報源としてtwitterは常時見れるようにしてるんですが、Chrome Birdは業務を邪魔するような
挙動の重さもなく、また操作性も問題ないです。
唯一難点は、DMの送信履歴を見れない所ですかね。

はてブのプラグインは、現状文句なし。
そのページに対するブクマの数と、コメントがいつでも見れるので、
みんながそのページをどう評価しているかがすぐに分かります。

Firebug Lite は、Chrome自体に強力なデバッグ機能がついているので、
現状あまり使ってません。FireFoxからの移行のために入れてます。

今後、Chrome ベータ版から正式リリースされた際、もっと便利なプラグインが
出てくる事を期待しつつ、今後の主力ブラウザをFireFoxにするか、Chromeにするかを
見定めていこうと思います。

年も明けまして、2010年。
たいぶと近未来的な西暦になってきましたね。

ほんとなら、こういう事は年末にやらねばならないのでしょうけど、
ココで今更、去年公開されたコンテンツの中で、「あー、ヤラれたなー」と
思ったコンテンツをご紹介します。

「ナカノクエスト」
http://www.okudakenji.com/nq/

ある区議会議員さんのウェブサイトの1コンテンツ。
基本的には、その議員さんのつぶやいた場所と内容が見れる、というものですかね。
もう一つのコンテンツ内容としては、この議員さんに「クエスト」を与える事ができる、というもの。
各クエストは投票制になっていて、得票数が多いものが実行される事になるようです。

ウェブ上でのやり取り（クエスト）が現実に実行され、その状況がTwitterを利用してリアルタイムに見れる。

身の回りに政治家が居る方ってそうそう居ないと思うんですが、
そういう人間にとっては、ある程度の現実感をもって「政治家」という生業の人を感じれるのかな、と思いました。

あとは、個人的にツボだったのは、ドラクエ風のあしらいですね。

主人公がカニ歩きをしていた頃のドラクエをやった事がある世代（30代～40歳くらい？）と、
政治に一番影響力がある層が被る、という事で、この世界観を選ばれたんでしょうかね。
単純にコンテンツ内容とも合致しますし。

オープニングのタイトルが上からゆっくりティルトダウンしてくる所とか、
やたら難しめの漢字は使わない所とか、
カニ歩きしかしない所とか、

この層の人間にとってはタマラナイと思います。

Flash Developer 的に「おっ」と思ったのは、
swfが非アクティブになった時に、処理を止めているところですね。

こういう所、見てる人には気付かれにくいんでしょうけど、
他のページを閲覧中にCPUパワーを占有しすぎないようにするという配慮は、
同じ業界の人間にとっては非常に有り難い事といいますか、見習うべき所と言いますか。

今年は、これに負けないコンテンツを作らねばならないな、と、肝に命じておく事とします。

ドアズも行きますよーー！！！

その1つが、YouTubeに、リアルタイムに音声を認識して、字幕を乗せる、という機能！

http://www.youtube.com/user/Google#p/u/4/Hhgfz0zPmH4

上記アドレスに飛んで、右下ボタンにカーソルを持って行き、画像のTranscribe Audio を押すと、
今流れている音声を認識して字幕にしていく、という機能です。

いやー、これはなんだか未来的です。
（まだ現段階だと、間違いだらけですけどね・・・）

さらに、

その字幕を別の言語に翻訳もできてしまう！

もう、ほんとに凄いとしかいいようがないんですが。。。

これで、聴覚に障害がある方もウェブ上の映像コンテンツを楽しめる機会が広がるかもしれませんね。

[追記]

映像の内容も、実はかなり凄いです。
Google携帯（Android）の機能として、画像認識アプリが配布されているようです。
（Google Goggles : グーグル・ゴーグル）

橋の写真を取って、その橋を建てたのは誰か、なんて事をウェブで調べたりできるようですね。

iPhoneアプリのセカイカメラと似たような機能もあるようです。

みなさん、波に乗ってますか？
僕は乗りました。新型インフルエンザの波に・・・。
現在はすっかり完治しております。
社内規定でバッチリ隔離されましたので(汗、社内パンデミックも起きておりません。


さて、本題はそれではなくて、Google が新たに始めるサービス、Google Wave です。



limited preview　ということで、興味のある方は申請をすると使用できるようですね。
http://bit.ly/2o84ai
僕は、twitter経由で招待をして頂いたので、そこでちょこちょこと触ってみました。


数日、さらっと体験した感想としては、
リアルタイム・スレッド掲示板に、時間再生機能が付いた感じ、
でしょうか。

掲示板にスレッドを立てるような感じで、「New Wave」ボタンから「波」を作ることができます。
その「Wave」は、最初は自分だけしか参加（書きこみ）できないのですが、Waveアカウントを
知っていればだれでも招待ができます。そして、その「波」の参加者でさえあれば、
色々な人を勝手に誘う事ができ、波の規模は盛り上がり次第で自律的に大きくなっていくようです。
（おそらく、パーミッションも掛けれるのだと思いますが、未確認）

スレッドと書いたんですが、スレッドと大きく違う点は、すべてがリアルタイムであること。
相手が書き込んでいるタイピングの様が見て取れます。

また、そのWave内に様々なウィジェットを付ける事もでき、
多様なコミュニケーションを、時間共有しながらできるところでしょうか。


現状、「じゃあ、これがクライアントワークに使えるの？」と考えると、「んーー・・・」と唸ってしまうのですが、
開発者目線で考えると、遠隔地のデベロッパ同士でペア・プログラミングができるのかなー、と。
あ、別に遠隔地じゃなくても、お互い別のマシンを使いながらでもできそうですね。

Waveサーバーを立てることもできるようなので、我々が日頃パートナーとして
お世話になってる方々や、クライアントの担当者様と共用すると、作業効率アップにも
つながるのかなー、と思っています。


今後もその機能を調べたり、何か新たな使い方がないかどうかを探っていこうかと思います。
以上、新技術にはぶっ込みたくなるtak-tでございました。

インターネットを使っていて「あー、面白いなー」と思う瞬間は人それぞれあると思います。
Flashコンテンツで言えば、3Dでビュンビュン動くサイトだったり、カッコイイ音楽が流れるサイトだったり。

最近ではあまり取り上げられなくなりましたが、一昔前は「アーカイブとしてのインターネット」という側面は大きな魅力のひとつだった気がします。
ドアズ内では映像編集をする機会も多い僕としては、過去の偉人達が残した映像を見るのが趣味だったりもするので、映像アーカイブとしてインターネットを利用することは多々あり、未だにその魅力に憑かれています。

そんな、映像アーカイブジャンキーな僕を刺激する事件が、ようやく日本でも起こりました。

あのNHKが、その膨大な映像資料をネット上に公開し始めたんです！
その名も、ＮＨＫクリエイティブ・ライブラリー

ＮＨＫクリエイティブ・ライブラリー

利用規約を読んでみると、基本的に「営利目的ではないこと」「他人に迷惑（著作権侵害等）をかけないこと」をクリアすれば、この映像を素材を利用して作品を作り、個人作品として公開することはOKのようですね。
（詳しくは、「利用のルール」を参照してください）

営利目的がダメなので我々のお仕事では使えないようですが、アーカイブされている映像達は紛れもなく日本トップクラスの技術者達が撮影した映像で、クオリティは言わずもがな。
見ているだけでも、おもわず見入ってしまう映像がたくさんあります。

なかには、ハイスピードカメラで撮影された素材もあり、学術的にも価値の高い映像がたくさんあるんじゃないでしょうか。

NHKの真骨頂ともいえる、ポップサイエンス系の番組の撮影素材があるところを見ると、今後もいろいろな「蔵出し映像クリップ」がアップロードされて行くんではないでしょうか。

アーカイブをウェブ上で有効活用するには

ウェブ屋で働いている人間としては、とくにこういう意義のあるアーカイブを見ると、なんとか有効活用できないのか？と考えずにいられません。

個人的な願いとしては、NHKさんには是非とも、このアーカイブをAPI公開して頂きたいですねー。
ウェブコンテンツとして映像を利用できるようになれば、これらの映像がウェブ利用者に晒される確率は爆発的に増えるんじゃないでしょうか。
そうすれば、このアーカイブが本来持っている社会貢献力の何倍もの効果が世の中にフィードバックされないのではないか、と思います。

現状、APIの提供に関しては何も言及されてないようですね。
ただ、たとえAPIが提供されても営利目的がNGとなっているので、個人活動として作るしかないのですが。

この、「営利目的での利用は禁止」というのは結構色々なところで出くわすのですが、中々難しいですね。
映像を特定の商品やイメージと結び付けられてしまうと、確かにその映像の価値が変わってしまうので、禁止としている考えは解るのですが、その一方で、これだけ貴重な映像が、人の目に触れる機会を減らしているという事も凄く残念だと思うんです。

なので、例えば、APIの利用はコンテンツの趣旨を審査して、アーカイブの趣旨と合致するモノにのみAPIKeyを発行する形で許可をするような仕組みは駄目なんでしょうかね？

まあ、小さな会社の１クリエーターの妄想にすぎないのですが、とにかく、これらの映像技術者達の並々ならぬ努力と根性の結晶は、ウェブというメディアがリーチできる全ての人の目に触れておきたい気がします。

ウェブ上に折角公開しているのにAPIを提供しないというのは、富士山の上に大きな図書館を作っただけのような気が・・・というのは、少々大げさな例えですかね(笑。

まとめ　やっぱりアーカイブ最高！

なんやかんやと書きましたが、結局のところ、それでも人類の遺産を積み上げていける、インターネットのアーカイブとしての側面が単純に好きなわけです。

なので、最後に、僕が個人的に好きなものを紹介して終わります。
この映像が、みなさんを素敵なアーカイブ探索旅行のキッカケとなることを願いつつ。
（これは、Internet Archive からの引用になります。）

それではみなさま、月世界旅行へボンボヤージュ！