2008年9月26日金曜日

gemspec.infoのモック

gemspec.infoのフィーチャモデル からの続きで、Railsアプリケーションの設計を生でお伝えしようという企画(=思い付き)の第3回だか4回だかになります。(←適当)

今回はモックを作りました。

設計成果

例によって成果物から。

Ruby on Rails プラグイン まとめ wikiのGemSpec.infoのモック がそのページです。

モックは簡単に画像ファイルにできるので、画像ファイルをペタペタ張った感じでまとめてあります。一応生データもアップロードしてあります。

モックとER図は同時に進める

あー、まずモックモックと言ってますが、これはペーパープロトタイピングレベルの画面設計のことです。正しくはモックの定義から外れるかも知れません。(面倒なのでこのエントリではモックで統一します)

で、Ruby on Rails によるシステム開発をモデリングで効率的に行うにはモック(というか画面設計)の話は出てきてないのですが、なんでコレを必要としたかって話を少し説明します。

まずおいらは、ユーザのワークフロー(「カートに商品を入れてから決済画面に進む」などの作業の流れ)とかユーザインターフェイス(使いやすいかどうか)はモックで検討を行い、そのシステムで何が出来るか、どうやって処理するかはER図で検討を行っています。

具体的にモックで何をするかというと、「その画面でユーザに入力してもらうデータそのものの種類と数」と、「次の画面に移ったり特定の処理を行うために必要なデータがその時点で揃っているかどうかを、その画面に配置された要素と、既に入力されデータベースに格納されて居るであろうデータだけで行うことが可能かどうか」の2つを検討するために使っています。

エントリの都合上、ここではモックの話だけしますが、実際にはモックとERを同時に検討しなければなりません。理由は下記の通り。

「その画面でユーザに入力してもらうデータそのもの」の検討

これは単純で、比較的ユーザインターフェイスが貧弱なWebアプリの場合、画面に出てくる要素の構成が、そのままデータベースの構成(ER図)になることが多いと経験上思っているからです。

これは、たとえばJavaでクラス設計をキチッとした場合は、間に抽象的な構造が入る分、画面=ERにはなりにくいのかなぁと思っています。(や、クラス設計キチッとしたことないから脳内の話なんだけど)

WindowsネイティブのGUIアプリとか、FlashやAjaxアプリなんかも、間に1層入る形なので、画面=ERにはならない可能性が高くなります。特にFlashとかAjaxなんかは、機能毎にもう1画面作ってるのと同じようなもんだし。

上記で「経験上思っている」と言ったのは、そうした方が構造がシンプルで実害もなく、結果として工数が少なくなると思ったから、実務では画面=ERとしたケースが多かったという意味です。(もちろん例外もあります)

逆を返せば、処理の都合上データ構造(ER)が制限され、それが画面インターフェイスに影響する場合があると思いますが、その影響がさほど不便ではなかったり、ユーザインターフェイスを工夫することによって乗り切れる範囲であれば、システム側の都合を優先させる方がいろんな意味(システム構築やデータ入力作業やサーバ負荷解消のためのコスト)で楽になるので、意図的に画面=ERになるような設計をすることも多いです。(あまり良い方法論とは言えないですが、この辺が理想と現実でしょうか)

「次の画面に映ったり特定の処理を行うための必要なデータがその時点で揃っているかどうか」の検討

若干上記と被っていますが、処理の都合上、次の画面へ行くために必要な最低限のデータセットというものがあるとして、

  • その画面に辿り着くまでに入力されていることを期待するデータは何か(今までの必須項目)
  • 次の画面に行くために必須となるデータは何か(処理上の必須項目)
  • その画面で最低限入力しなければならないデータは何か(この画面での必須項目)
  • ワークフロー上、その流れは自然か

というあたり、ワークフロー上の時系列に沿って考えるためにモックを使います。

「どの画面で何を入力できて、どれが必須か」というのは頭の中で管理するのは無理で、ましてや使いやすいかどうかは可視化しなければわからないものだと思います。

おいら的に、その「流れが自然か」「使いやすいか」というところは拘るべきところで、処理の都合上必須なのは仕方ないとしても、その画面のユーザインターフェイスを工夫したり、一つ前の画面で入力できるようにしたり、そもそもワークフローを変えても問題ないのであれば、自然な流れになるように調整したりといった作業が必要になります。

問題点

FlashやAjaxの場合、画面=ERとならない事も多いけど、これをうまく整理する方法がわからない。まぁ、Mockupsを使う分には簡単にモックをコピーできるので、動きの要所要所でもう一枚モックを作ればいいのかもしれないけど、なんかしっくり来ない気もする。

まぁ、ActionScriptとかJavaScriptで無理矢理ER図に合わせた形に加工できれば良いんだろうけど、それもどうかと思うしねぇ。

一つ言えるのは、FlashやAjaxやその技術を使ったリッチアプリケーションが増えてくるのは自然なことで、これら業界的な要求を満たす設計手法が確立してないってことかな。

画面設計するためのツール

さて話変わるんだけど、モックアップを作るために使ったツールを紹介しておきます。

と言っても、RubyOnRailsの設計手法もレールに乗せよう で紹介しきっているので、おいら的選定基準など。

  1. 書きながら考えやすいモノが良い
  2. 発注者やプログラマ達などに気軽に確認してもらえるモノがよい
  3. 2の観点からWebアプリで設計出来た方が、常に最新版を提示できるので良さそうだけど、ネットワークがあることが前提となるので、出張先などで開けなかったり、喫茶店で仕事できないのが痛い
  4. 3の観点から、ネイティブアプリ(Windows用とかMac用とかJavaモノとか)か、ローカルで動作可能なWebアプリが現実的かな
  5. 2の観点から作ったモノを簡単に配布できること。画像にエクスポートかけるか、(一般的なアプリで、データをファイルに落とせるなら)生データで展開するのが現実的かな
  6. 5の観点から、モックアップを作るためのツールが無料であること。画像は簡単に確認できるけど、メタ情報が落ちてしまうし、微調整さえも面倒になるので
  7. 素人でも理解できる程度の表現力があること
  8. 1にも準ずるけど、大雑把なものが、簡単に作れること。モックは何度も書き換えることになるので、簡単に作れないと心理的抵抗が大きくなる
  9. 注目すべき点は、デザイン的要素ではなく本質的な要素なので、見た目がキレイなのはいいけど、あまり拘らないこと(特に作り替えるときの心理的抵抗が大きくならないように)
  10. ネイティブアプリを作れるぐらいの表現力があること。この先AjaxやFlashはその高みまで到達すると思う
  11. 可能なら動きも再現可能なこと(でも難しいよね)
  12. データがテキストファイルになっている方が、subversionやgitなどでバージョン管理しやすい(データ量が少なかったり差分が見れたりなど)
  13. データが構造化テキスト(XMLとかYAMLとか)になっていれば、プログラムで解釈させてジェネレータなどを作ることも出来る

まとめると、「見せやすくて」「大雑把に簡単に作れる」ことかな。

候補としては

があるんだけど、ExcelとPowerPointは表現力が乏しいのでダメ、DreamWeaverはどうしてもCSSとかDivなどのブロックを考えなきゃいけないので本質から反れてダメ、となったときbalsamiq mockups かPencil が有力になると思う。

おいら的にはbalsamiq mockups だったんだけど、これはbalsamiq mockups の方が知ったタイミングが早くて、あまりPencil に興味がわかなかったってのが大きい気がする。

Pencil って実際どうなんだろう?　ちゃんと使わないと比較はできない気はするモノの、できることはあまり大差がないように思えるので、どっちでもいい気がする。(mockupsは有料なのでPencil有利かな)

ただ、Pencilは気になるものの、balsamiq mockupsに満足しちゃってるので、乗り換えるかどうかは微妙だなぁ。

投稿者 時刻:
ラベル: , , , , , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)