fladdict

Slashdot: HTML 5の仕様からオーディオ・ビデオコーデックに関する要件白紙に。ベンダーの意向の相違が原因。

HTML5にて、ビデオコーデックの仕様が定まらず、予想通りに迷走してるっぽい。

Flash Playerの対立軸（？）として、一部で持ち上げられているHTML5だけれども、課題というか大きな問題点が１つある。 それはHTML5が利害関係の一致しないプレイヤーの綱引きで、フットワークと合理性を失いつつある点だと思う。

ビデオのコーデックなんかは、事実上のディファクト状態になった .flv 以後の主導権を誰が手に入れるか？という綱引き状態で、宙ぶらりん状態な感じかと。iPhone導入を契機にYoutubeにH264対応を押し通したAppleとしては、TheoraよりH264を通したいのだろうし、他も色々考えがあってまったくまとまらない。

＜追記＞はてぶで指摘があったとおり、flvはコーデックではないのでその点を補足。大雑把に書きすぎました。flvが使ってるsorensonやON2　VP6が駄目な方向で策定してflv殺したとして、その後に誰に有利なコーデックを導入するかって感じかと。

一方でプロプライエタリであると批判を受けるFlash Playerではあるけれど、そのプロプライエタリさゆえに強い。x

HTML5は2012年に普及予定だったと思うけど、2012年にはFlash Playerは13とかなってて、益々出来ることに差がついてしまうことになる。ここら辺は某エバンジェリストの人もブログに書いてたかと。

2012年までにwebがどう進化するかしらないけど、ジオタグでもARでもマルチタッチでもFlashはその気になれば次の年には搭載できる。しかしHTML5は一度策定してしまえば、2015とか2018まではおそらく動けなくなる。

そもそもFlash vs HTML5みたいな近視眼的な対立軸を超えて、HTML5は各社の調整と普及のボトルネックが加速する技術発展の速度に対応できないのではないか？という感じなんじゃないかと。　ECMAスクリプトもそうなんだけど、複数の利益の異なる団体が協議して仕様を策定していくというスタイルは、もう現在の時代の変化スピードの前ではあんまり現実的じゃないのかもしれないなぁと思うのです。

タッチスクリーンのUIについて考えるとき、ロールオーバーの存在の有無ってあまり語られてない気がする。

ロールオーバーってのは、それがない環境でコンテンツ作ってから振り返って考えると、
無茶苦茶便利な概念だったのだなぁと思う。

よく「Flashで作ったサイトは、どこがボタンかわからない」という話を聞くけれど、実際問題としてはタッチスクリーンのUI全般では、さらにどこがボタンかわからなくなる傾向があるように思う。まだ問題が表面化していないだけで。

結局のところ タッチスクリーン環境 ではロールオーバーは、ビジュアル要素で慣習(conventions)を作って対処するしかなさそう。もう１つはボタンと入力テキスト部分のみの視覚的な立体表現を徹底することみたい。あるいは、Percieved Affordanceとして、ボタンを点滅させるとか。

将来的には静電気とかを感知して、非接触なロールオーバーもどきがデバイスにも実装されていくんだろうなぁと思うけど、とりあえず現状はこれを受け入れないとならないんだろうな、と。

昔のPCとかだと、データをセーブするときは、ガッチョンガッチョンと凄い音を立てていたので、いかにもセーブしてますよ感があった。

最近のSSDとかは、速いし静かなので、本当にセーブされてるかとかがよくわからない。
特にバックグラウンドでこっそり保存されている奴。

これは電気自動車が無音すぎて、交通事故が起きるみたいなのに近いのではないかと。　

電気自動車にわざわざ音をつけろ的議論と同じように、SSDとか速くて静かなセーブはわざと、プログレスバーとかに溜め時間を作ったりフィードバックを派手にして、いかにもセーブされてる感を演出する方がいいんじゃないかなぁと思う今日この頃。

iPhoneアプリなり, Airアプリなりを作ってて思ったんだけど、特にiPhoneのような画面の小さい環境では、機能要望の取捨選択がムズかしい。

本来、ウィジェットというのは単機能特化が一番いいんだ思う。 ところが、ユーザーからの機能要望というのは限度がなく、その全てに対応すると、アプリケーションがあっという間にファットになってしまう。

ファットになったアプリは、既存のヘビーユーザーには歓迎される一方で、新規ユーザーにとっては害として働くことが多い。

まず、あれもこれもという多すぎる機能は、「何をすべきなのか」という本来のコンセプトを消し去ってしまい、それそのものの持っていた「体験」を台無しにしてしまう。結果、「何をしたいのか」が明確なユーザー以外には、きわめて使いにくい一品になってしまう。

また学習コストの大幅な増加も問題となる。iPhoneのような設定画面と、ヘルプを並列に見せることが難しい環境ではなおさらだと思う。

ところがジレンマは、初心者ユーザーほど、表示スペック、カタログ上の機能の数を基準に購入する。 UIや機能の切り捨て、という意思決定に対し新規ユーザーがお金を払う可能性は少なく、結果的に販売段階ではアレもコレも全て詰め込んだアプリが売れることとなる。

そして長期的に見た場合、ファットなアプリは初心者を切り捨て、市場を小さくしつつヘビーユーザーだけが生き残る。そしてヘビーユーザーの機能要望に答えることで、さらにニッチなアプリへと破滅的な進化していく。 ここら辺はかつてシューティングや格闘ゲームなんかが通った道だと思う。

そういう先細りに対して、どういう対策を練っていくのか？　というのがモバイルアプリの今後の課題になるんじゃないかと。

ゲーム業界等の先人の工夫を見ていると、最も有効なアプローチの１つは、初期起動時にユーザーの機能と権限を制限することのように思える。

購入時、ユーザーのできることは、そのアプリの本質のみに制限する。そしてその後、ユーザーの指向、用途に応じて、複雑な機能を制限解除していく、というのがスマートなのではないかと思う。そういうRPGのレベルアップ的な仕組みが、アプリのUIについてもいいのではないかな？と思う。

メタセコイアとか触ってると、とてもそう思うのデス。