May 10, 2006

汎用的かつ拡張可能な機能を持ち、かつ洗練されたユーザインターフェースって

「汎用的かつ拡張可能な機能を持ち、かつ洗練されたユーザインターフェース」とか言ってると、また自己反映計算の亡霊が…。亡霊じゃないか…。

subtechグループ - Bulknews::Subtech - Web API と MVC

LDR ハックが画期的なのは、デベロッパーがM+Cを利用してVを作るんじゃなく、Vを利用してCを実装することで、Mは自分の好きなものを使えるってこと。LDR のサービスが提供しているイカした View を利用させてもらうわけ。もちろん、Ajax (XMLHttpRequest) と GM があるからこれができる。Controller は LDR API を再実装、Model は Plagger でとってこれるものならなんでもいい。

ControllerがLDR APIを実装する必要があるということは、ViewがControllerを制約するということだ。別の言い方をすれば、LDRはピュアViewではなく、実はControllerの機能を一部包含していて、実(Remote)Controllerとの間のインタフェースがLDR APIなのだとも言える。Google Homepage APIも同様で、ユーザはControllerを記述できるが、それはAPIに束縛されると同時に、記述の解釈実行はView側Controllerの役割となる。

で、私が思うのは、結局のところ、こういう構造というのは柔軟なというか使いやすいアプリケーションの実現という点で優れていないのではないかということだ。例えばGoogle Homepage上でメールの読み書きはしにくいし、LDR上でブログの更新はしたくない。なぜなら、Google Homepageはサービスの入口としてのアクセシビリティにおいて、LDR UIはリストの集合のような構造データを閲覧したり簡易な操作を行ったりという操作性において、それぞれ優れているに過ぎないから。つまりは、ユーザインタフェースとアプリのドメインは不可分だから。

とは言うものの、アプリのドメインが制約されるとしても、適用可能なアプリは無数にあるだろうという観測には賛成したい。確かにPlaggerは重要なpracticesであった。Web版インタフェースビルダで汎用的かつ拡張可能なインタフェース部品をレイアウトできてそれぞれの操作的意味も定義できて何でもできるんだぜー、俺って宇宙一、という話よりはかなりゴールが近いところにあるし、おそらくは短期的にはgeek満足度も高いだろう。

でもそれがWebアプリケーションとして目指すべき方向性なのかどうかについては、断定を躊躇してしまう。GNU EmacsでメールもWebもコード・ドキュメント書きもデバッグも済ますという古くからの素朴なアプローチが、90年代までは割と(パイが圧倒的に小さかったこともあって)受け入れられていたものの、近年ではそれほどでもないことにもついつい思いを馳せてしまわないでもない。ああもちろん、GNU Emacsのようなポジションを狙うWeb UIというのはgeekのおもちゃ箱として面白いのは確かだね、Plagger同様。

yohei-y:weblog: 次の話

思うにこれからの Web サービスは三つに分離するのではないか。ひとつは Amazon S3 や Google Base や Flickr やはてなブックマークのようなデータストア提供サービス。二つ目は OpenID/Typekey 認証やはてブの件数取得 API や SimpleAPI のような機能提供サービス。そして三つ目が今回の LDR のような UI 提供サービス。

なんかしちめんどくさい分類だなと思った。機能提供サービスのうち、Authentication以外のサービスは、データストア提供サービスに分類してしまえると思った。例えば、ブックマークや天気などのstateを取り出すサービスは、「システムユーザ」がストアした情報をある形式で参照できるサービスであると言える。また、データを変換するサービスは、「ユーザ」がデータをストアすることができ、そのデータを変換された形式で参照するためのビューを提供するサービスであると言える。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com