Entries

スポンサーサイト

カテゴリ:スポンサー広告
更新日:--------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ユーザーインタフェース指向で開発できる仕組みが欲しい

カテゴリ:コンピューター
更新日:2013-06-26
この図解を見ると、私が何でBackbone.jsを選んだのか、よく分かる。

> Angular.jsとBackbone.jsのDOM依存を図解する - ジンジャー研究室

JavaScript側にフレームワークを導入しようと調べた時、いくつか候補があった。そのひとつとしてAngular.jsの紹介を読むと、input要素とModelの連携が特徴らしかった。この図解を見ても、View側は、ほぼ自動化(破線)されているようだ。だけど、私は、それに抵抗があったのだよね。

システム開発をする時、画面設計というのは、かなり重要な要素になる。業務システムだと、一覧と詳細表示のようなパターンがあって、Webアプリほど画面デザインは意識されないけれど、それでも画面は重要だ。

うん。確かに、画面を中心に設計をするといろいろ問題がある。

> 画面設計とか外部設計とか、もうやめようよ - 今日も反省の色なし(masayangの日記

それでもね、やっぱり画面を中心に考えるしか無いんだよ。だって、ユーザーには、それしか見えないんだもの。(だからと言って設計者がユーザーの言葉に引っ張られてちゃいけないけど。)

確かに、内部の構造は重要だ。全体として整合性がとれていなければ、ちゃんと動かないから。でもそれは結局、エンジニアにとって、でしかない。それをユーザーに理解してもらおうというのは無理がある。だって、ユーザーは、自分がやりたいことができること、が重要なんだから。

アジャイル開発になれば、画面はさらに重要じゃないかな。「動く」というのは、「画面を見て、操作する」に等しいからだ。となれば、ユーザーインタフェースの開発の容易さがかなり重要になる。

で、Angular.jsのように、そのあたりが自動化されると・・・うん、最初は楽なんだよね。だけどそのうち、その自動化の仕組が枷になる・・・んじゃないかなぁ?

実際に使ってみたわけじゃないから、やりようはあるのかもしれない。けど、経験的には、フレームワークが縛りになることは多い。ある程度できあがった所で、フレームワークが制約になるのは辛い。フレームワークを迂回して造り直さなきゃいけないからだ。

Ajaxで開発するのならば、サーバーサイドがModelを、フロントエンドがViewを主に担当して、APIでつなぐ、という構造は、妥当に思えた。そうして、サーバーとフロントエンドで役割が分離できれば、ModelとViewの開発は、分離しやすくなる。

そこそこ経験があれば、Modelの設計というのは、そんなに難易度が高いわけじゃない。 よく、プログラムのサンプルでは、掲示板とかToDoなんかが多いけど、これのデータモデルなんて難しくないよね?経験があるって、そういうことだ。

確かに細かい所で悩むこともあるけど、それは、汎用性をどこまで追求するかとか、検索時の効率とか、SQLの複雑さとか、そういうことを考えるからじゃないかな。いずれリファクタリングが必要だとしても、最初の取っ掛かりを決めるのが難しいということはない。

対してView。使い勝手に一番影響される部分だけど、使い勝手というのは、実際に使ってみないと分からないことが多い。ユーザーに見える部分でもあるから、不満が集中しやすい。

いいユーザーインタフェースを作るには、再構築を繰り返すしかないと思う。作って、使って、直す。これを繰り返す。だから、それができる仕組み(アーキテクチャ)が、ずっと欲しいと思っていた。Backbone.jsで、ようやっと構造的には、できそうな気配がある。

それでもまぁ、やっぱりユーザーインタフェースってのは、作りこむのに時間がかかる。別のノウハウが必要なのかもしれないなぁ。まだまだ課題は多い。
スポンサーサイト

Appendix

プロフィール

いむら@fintopo いむら@fintopo

フリーのシステムエンジニア兼プログラマです。趣味はガーデニングとカメラ。2017年4月にα7IIを買いました。フルサイズ一眼初心者です。

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。