先日の新型UIに関してはほぼ完成し、現在管理人のUIを変更しようと色々画策しています。管理人UIのバージョンアップを以て、次のバージョンアップはβ3.x世代にする予定でした。
しかし、最近、とりあえずプレイヤのアップデートを先にかけようかなぁという迷いがあります。何故かと言うと、実験準備の方が忙しく、ちまちまやっていはいるものの、なかなか開発にまで手が回らないってのが現状だからです。
恐らくこのペースでやって7月半ばか後半にはリリース出来ますが・・・。ある程度バグがあっても最新のものが欲しい!という意見があれば、stableと切り離してlatestバージョンを公開するつもりです。
2009年6月4日木曜日
デモ発表で得られた議論についての雑感
この間、あるコンテストにNicolithの次世代版に関する発表を行ったのだけど、その時に
まず前者について、極限までの省操作を考えると、ブラウザで開いてFlashを起動再生しておくというのは余計な情報や手間が多いと考えています。デスクトップ上に空気のごとくマルチメディア情報があり、ユーザが欲しい時にシームレスですっと情報を提示してくれるようなインタラクションが理想です。その為にはウィンドウなどの「区切り」はなくしておくことは重要な要素になるので、ウィンドウレスのデスクトップシステムに行き着きました。
後者についてですが、私は24インチ(1920*1200)のワイドディスプレイを使っています。ちょうどA4サイズの書類が縦に二枚並べられるサイズです。確かにこのサイズであれば、ブラウザを2画面開く事は容易なことです。しかし、ブラウザ2画面開けて、更に邪魔にならないよう、快適にアクセス出来るような情報提示手法があれば、そちらを使った方がより有益なインタラクションができると考えます。
それと、ウェブブラウザは「できること」が多すぎて、リテラシの低い人には起動する事すら躊躇われるものになってしまいました(うちの母とか)。あえて機能を「マルチメディアを楽しむ為のシステム」と限定する事で、利用目的の明確化、簡単な操作の実現、そしてそれから生まれるリッチなエクスペリエンスを創出することができるのではないでしょうか。
と言った所です。確かに、ブラウザで全て解決出来ればインストールという非常にコストの高い作業を省略できたりと、利点が多い事も確かです。理想としては、ブラウザ版とデスクトップ版の両方を提供することで、相容れないユーザニーズの両方に対応していくことです。
実際に動いているシステムを見てもらい、その場でディスカッションするのはとても楽しく、勉強になりました。ご参加頂いた方々には、改めて御礼申し上げます。
- ブラウザを2画面開けば良いじゃん。その中にフラッシュで作っとけば解決じゃない?
- 画面の面積問題は、ハード的(モニタサイズと解像度)に解決されるんじゃない?
まず前者について、極限までの省操作を考えると、ブラウザで開いてFlashを起動再生しておくというのは余計な情報や手間が多いと考えています。デスクトップ上に空気のごとくマルチメディア情報があり、ユーザが欲しい時にシームレスですっと情報を提示してくれるようなインタラクションが理想です。その為にはウィンドウなどの「区切り」はなくしておくことは重要な要素になるので、ウィンドウレスのデスクトップシステムに行き着きました。
後者についてですが、私は24インチ(1920*1200)のワイドディスプレイを使っています。ちょうどA4サイズの書類が縦に二枚並べられるサイズです。確かにこのサイズであれば、ブラウザを2画面開く事は容易なことです。しかし、ブラウザ2画面開けて、更に邪魔にならないよう、快適にアクセス出来るような情報提示手法があれば、そちらを使った方がより有益なインタラクションができると考えます。
それと、ウェブブラウザは「できること」が多すぎて、リテラシの低い人には起動する事すら躊躇われるものになってしまいました(うちの母とか)。あえて機能を「マルチメディアを楽しむ為のシステム」と限定する事で、利用目的の明確化、簡単な操作の実現、そしてそれから生まれるリッチなエクスペリエンスを創出することができるのではないでしょうか。
と言った所です。確かに、ブラウザで全て解決出来ればインストールという非常にコストの高い作業を省略できたりと、利点が多い事も確かです。理想としては、ブラウザ版とデスクトップ版の両方を提供することで、相容れないユーザニーズの両方に対応していくことです。
実際に動いているシステムを見てもらい、その場でディスカッションするのはとても楽しく、勉強になりました。ご参加頂いた方々には、改めて御礼申し上げます。
2009年6月1日月曜日
開発記録 @ Adobe AIR
Nicolithシリーズの軽量化を図るべく色々調査していました。その結果判った事を幾つか書いていきます。
画面外にあるオブジェクトのリサイズや画面外→画面外への移動を行う場合、アニメーションをカットする等の処理をする必要とかもある。勝手に描画を省略するかと思いきや、普通にアニメーションしてました。
この辺をカットしていく事で、少しは軽いバージョンを公開出来ると思います。
- ベクター描画をしているコンポネントに対するDropShadowEffectはとても重くなる
- リサイズ自体は思ったより(あくまで思ったよりは)パワーを喰っていない
- 再配置にはパワーを喰われる
- setChildIndex処理は意外と重い
- setChildIndex処理は、インデックス位置に変更が無くても、無駄に処理される。(MOUSE_MOVEイベントで処理していたのでアホみたいに繰り返し処理されていた)→MOUSE_OVERイベントに修正+特にインデックスに変化が無い場合は処理しないように変更
- 描画領域外でのアニメーション処理はきっちりと処理されるので領域外ではアニメーションをオフする処理を明記する必要がある
- マウスに連動するアニメーションをするときはstartDelayをかけることによって、不用意なアニメーションを避ける事が出来る。
- 大量にアニメーションさせる場合、durationにばらつきを持たせると、負荷が分散されて若干体感速度が良くなる場合がある。
画面外にあるオブジェクトのリサイズや画面外→画面外への移動を行う場合、アニメーションをカットする等の処理をする必要とかもある。勝手に描画を省略するかと思いきや、普通にアニメーションしてました。
この辺をカットしていく事で、少しは軽いバージョンを公開出来ると思います。
登録:
投稿 (Atom)