UIEngine だ

HSDPA,, Docomo905 で何か見えてくるのだろうか？

　アプリの開発も進んでいない。それもこれも、結局iアプリじゃ「おっ」と思うようなインタフェースを実現できなかったからだと。905はHSDPAで高速通信できるので、もしかしたら結構快適なインタフェースも実現できるのかもしれない。

　試しに購入してみようかと思うが、使い慣れたDにするか、それとも他の機種にしてしまおうかと悩む。しばらく、買えそうに無い。

　HSDPAでDLが高速ならニコニコ動画もさくさく閲覧できるのだろうか？どちらかというとこっちの方が楽しみかもしれない。

UIEとしては、その辺のエンジニアなんて、もうどうでもいいと思っているかもわからんね

　先のエントリーについた、コメント（by うにら氏）が、万人に起こりうる現象なら、これはちょっともうだめかもわからんね。uieme!も動かないし。一般エンジニアが触って楽しい、そして興奮できるようなプラットフォームを目指すのをやめてしまったのだろうUIEngineは。企業として、その判断はありだろうが、そうならそうとSDKの公開をやめるとか、はっきりとさせた方が良い。恋愛もそうだが、不満を持ちながらもずるずると続けるのが一番悪い。

Googleからandroid SDKが出たことについて、、、Life is beautiful ではあんなことを言っているけど

http://satoshi.blogs.com/life/2007/11/googleandroid-s.html

　賞金は一部の開発者には魅力的だろうが、実際の端末がまだマーケットにないので、しばらくはビジネスにはなりにくいのが難点。私が個人的には iPhoneのSDKの方にずっとワクワクしているのは、やはり私自身、iPhoneを持っているからだろう。エミュレータだけでは、どうも盛り上がらな い。

とのこと（赤に下のは私）で、「エミュレータだけでは、どうも盛り上がらない。」と書かれているが、UIEのSDKも一般のエンジニアにしてみたら同じことではなかろうか？ブラウザ用Flash版とDocomo用iアプリ版のUIEPlayerはあるがDocomoユーザーじゃなかったらいきなり対応プラットフォームは1/2。もう少しなんとかならんのか？と思うのは以前から同じである。せっかくだからトラックバックしておこう。この際スクエニ社がウィルコムかKDDIを買収して、UIEngineを全端末に標準搭載、その端末を無償で配布してくれれば少しは問題が解決するのだが。

　さて、全然盛り上がっていないSecondlife、電通の「風説の流布」説が飛び交っている？感じもするのだが、Viewerのソースを見て、チャットプロトコルの実装ができそうなので、Secondlife on UIEngine（但しチャットのみ）もやれそうだ。と、そんなことをやっていたら、どこかの会社から携帯用SecondlifeViewerが出るそうで、このまま続けるかどうするか、とほほである。

[追記]　ブログのサイドバー→に貼り付けてあるuieme!が期待通り動作していない。とりあえずはずそう。

UIEngineの普及に思う。レガシーなマーケティング。

組み込みシステム向けGUIテクノロジー「UIEngine」
http://d.hatena.ne.jp/philo-sopher/20070925/1190705476

　最近「UIEngine」という単語を含むブログエントリーもめっきり少なくなっている。少し寂しい。が、今日、久しぶりに発見。それが↑のエントリー。

　今日、UIEngineのセミナーがあったようだ。私がUIEngineの普及について考えたとき、思うのはUIEngineがクローズな仕組である以上、レガシーマーケティングが合っているということだ。DMを打って、セミナーをやって、展示会に出て、地道に普及しつつ、大きな実績が出たらプレスリリースで発表。ついでに雑誌等に寄稿。これを続けるのが、UIEngine普及への近道だろう。

　ブログ等のバイラルを引っ張り出すには、開発環境がこなれていないし、「うぉぉ」とうなってしまうサービスがUIEngineでなければ作れないということもない（この辺はAUとSoftbankの問題でもあるが）。

　久しぶりにUIEngineという単語を含むエントリーを発見し、手元のDM送付先一覧を眺めながらそう思った次第である。

ステート変数

　久々の投稿ではあるが、UJML書いていて必ずやる「ステート変数の再設定忘れ。」のこと。大抵、画面に表示するヴィジュアル要素をリペイントするつもりが、他の処理に夢中になってステート変数の再設定

sBox = false;
sBox = true;

を忘れるのである。SDK上でのデバッグが遅いので余計に腹が立つ。「あれ、表示されない。」「あ、そうか」といった具合。プログラマーが上記コードを書きたいかどうかは、プログラマーしか知らないので、SDKの遅さだけは何とかして欲しいものだ。

＃最近、コンパイラーをいじっているので、その辺の話はまた今度。IUjmlIDECompiler...

いろんなデバイスに対応したアプリケーションを高速に開発するための方法

　本日は、UIE DesignerというUIEngine用のアプリケーションを開発するツールについてのエントリー。存在自体はなんとなく知られていて、最近の展示会でも展示されていたので知っている人は多いのだろうが、私は昨日初めて見たので書いておく。

　まだ公開されていないのだが、かなり作りこまれていた。ノンプログラマーでもアプリケーションを開発できるようにしている点は高く評価。例えば、プログラマーがパーツと言うか、「アセンブリー」を提供し、デザイナーがアセンブリーを使ってGUIベースで開発していくというスタイルをはっきり目指しているところが素敵だ。左の画像は、昨日見た画面を脳内キャプチャし吐き出したものだ。

　ここにあるFlickrとリストボックスという四角が「アセンブリー」で、三角が出力、丸が入力で、三角と丸をドラッグしてつないでアプリケーションを作成するというイメージ。バックグラウンドの処理（ここではFlickrから画像を取り込む処理）、とUIの処理（ここではリストボックスに画像を表示する処理）を分離して、わかりやすくしているのも良い。

　実際触っていないし、デモで見ただけなので褒めることしかできないのでつらいが、そんなものがもうじきリリースされるようである。まずは期待。

　デモの操作を見ていて、キーボードとマウスの手の移動が多すぎて大変に見えたが、たいしたことは無いのでリリース時には改善されているだろう。

タイトル未定 キャッシュ等の話

Life is beautiful: 「さおだけ」がミリオンセラーになった本当の理由
http://satoshi.blogs.com/life/2007/06/post_1.html

　さてはて、でかける前にエントリーを一つと思い、↑のエントリーを読んでしまい、タイトルが決まらない。今日は良い天気だ。

　<resource>要素の話。

　この要素、便利なのはご存知の通り。例えば画像をキャッシュするのに使う。バックグラウンドで画像をキャッシュすることで、うまくやれば、ダウンロードを意識させずに携帯電話でもスライドショー等ができる。携帯電話もまだまだ回線速度が遅いので、ダウンロード時間が苦痛なときがある。そんなときに使うわけだ。

　とはいっても、端末のメモリは有限で、いくらでもキャッシュできるわけではない。これが厄介。キャッシュが一杯になると、なんらかの法則で削除していく。あまり使われないものから優先的に削除するという仕組。

　例えば、スライドショーを考えよう。画像をA,B,C,D,,,といった具合に表示させるとき、A→B→C→Dとキャッシュするように実装する。こうするとさくさく画像が切り替わるようになる。

　しかしである。Dをキャッシュするときに一杯になると、Aから消される可能性が高い（あくまで可能性、細かい話は今度）。そうすると、

A：表示中
B：次に表示
C：Bの次に表示
D：Cの次に表示、一杯なのでどれか削除、、Aは表示中だからBかな？

といった具合で、Aの次の画像Bを表示させるときには、Bのキャッシュが削除されているのだ。そして、画像Bのダウンロードが始まってしまう。これは意図するところではない。

　そういったことにならないように、メモリサイズも考えつつ適宜実装する必要がある。（※あれ、前にも書いたかな？）

uieme! のインタフェースはスクロールバーふぇち

　UIEvolution社が提供しているuieme!を使っていて思ったことを書いてみる。

　今日は2つ

１．Windowsっぽい

　uieme!ではWidgetsを組み合わせて一つのサービスを作ることができる。作りこもうとすると、フォルダを設けて、そのなかにいくつかのWidgets（写真とかRSSリーダーとか、文章とか）を配置し見事なツリー構造にする必要がある。これが、作りこめば作りこむほど使いにくくしている。

　Windowsのエクスプローラもフォルダ内にファイルやフォルダがたくさんあると開くのが遅くなるし、目的のものを探すのが大変だ。uieme!も実際そんな感じ。携帯やブログパーツでは画面サイズが小さく、表示できる項目が限られるので、大きなものを作りこんだら負け。いかに小型でピリッときいたものを作るかが問われている。

　で、私の結論はツリー構造で無限にmeCast（Widgetsの集合の呼称）を構成できるようにしたのは失敗で（三階層以上は無意味というのが実感）、直感的に選択できるようにアイコンパネル式にした方が良いのでは？ということ。アイコンをたくさん用意し、オリジナルも作れるとなお良い。（但し、画像形式はダウンロードが遅くなってしまう問題があるので工夫が必要だ。boxとlabelを使って無理やりアイコンを構成するとか。アスキーアートっぽく。）

２．スクロールバーふぇちについて

　先の話にも通じるのだが、ツリー構造の無限構成を可能にした関係で何かのリストが画面に表示されるとスクロールバーが表示される。私はこのスクロールバーがすごく嫌だ。スクロールバーを使うためにWidgetsが作られているような気がするぐらい。（私がポインティングデバイスを使えないデバイス上で使っているからかもしれないが。。。）

　とりあえず、縦長の画像を表示するときにスクロールバーはいらないのでやめて欲しい。画面の縦におさまるように縮小した画像を表示すべき。これまでいくつかの修正希望を書いてきたが、スクロールバーありきのインタフェース設計は絶対におかしい。

UIE面白すぎ、毎晩豪華ホテルにご宿泊、一名様ごあんなーい

　UIE社のCEOのネタにつられて、UIE社（JAPANね）の社員の方々のエントリーを巡回。そして、そして、またもやつられてみる。

　ホテルの部屋に、ギリシャ風の柱があるが、、、何だっけこれ？真ん中が若干太くなっているあれかい？全然名前が思い出せない。それに、ベッドにカーテンが付いてるし。そして、もちろん風呂場にも柱が。

　なんか、もう、面白いので東京に戻らず、そのまま、豪華ホテル最上階の部屋のエントリーを続けて欲しいものだ。レビログさん、豪華なホテルに泊まっても「喜べない」そうだが、心から楽しめるようになるまで、レビューを続けてくださいな。

　それでは、またもやつられてみました。では。

[追記]真面目に見に来てくださった方、申し訳ない。

uimeが密かにアップデート、、ブログのサイドバーが変なことに

　次世代CGMの頭を狙うuieme!が密かにアップデートしたようだ。おかげで、このブログのサイドバーに貼り付けたアプリが変なことになった。

　サイドバーには2つのアプリを貼り付けていたのだが。えっと、アプリの1つはRSSリーダーで、もう一つはスライドショーだった。それぞれ、アプリ（meCastと呼ぶ）の開始ページを表示させていたはずが、何だか無理やり違うものに変更となった。これにより、サイドバーには同じものが二つ貼り付けられる結果に（左画像参照）。

　もちろん、UIE社CEOブログの

Life is beautiful: uieme beta、UI一新で使いやすく、そしてブログパーツも
http://satoshi.blogs.com/life/2007/03/uieme_betaui.html

のエントリーに貼り付けた、「GO マリナーズ」というアプリも同じ目にあっている。

　まぁ、仕方の無いことだが、uieme!のウェブアプリ側にも何か変更があったのだろうか？早速覗いてみてみることに。

uieme! - Home
http://www.uieme.com/

[追記]この問題はUIE社の迅速な対応により修正された（コメント参照）。あぁ、よかった。そして「あら、素敵。」。uieme!については、過去のエントリーでもつらつらと不満を書いていたが、それに対するUIE社の対応が紳士的であり、感動している今日この頃。uieme!プロジェクトメンバーはとても良いモチベーションをキープできているようだ。