＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
画面サイズを決定するときのポイント−「巨大な画面の何がそんなにダメなの？」
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2008-03-28 19:52
>項目の精査ができているか（必要かどうかわからないけどとりあえず入れとけ、みたいなのが無いか）
まさかドメイン設計の前に画面設計をしているなんてことないですよね？ >「１画面で全項目が見えたほうが便利という顧客は多い」 エンドユーザーの意見を聞くのは重要だと思うけど UIデザインのプロというわけではないので鵜呑みにするのはどうかと >「自社パッケージなんだから、便利さにはこだわりたい」 一概に便利といえるUIデザインなんて存在しない。 ユーザーに適したUIデザインが良い。 業務系の場合ある程度ユーザーの慣れに頼ることができます。 >「遅いって言っても、何分も待つわけじゃないだろう」 業務系パッケージでそんなに早い段階でパフォーマンスを 考慮する必要はないと思います。 アルゴリズムの選択さえ間違っていなければ後からチューニングできますし、後からにするべきです（実測できる状況になってから）。 設計段階で考慮すべきはレスポンス性だと思います。 たとえば処理中はプログレスバーを表示するとか。 >「巨大な画面の何がそんなにダメなのか」 多くの要素を無理に詰めようとすると 要素のグループ化と整列が難しくなる。 こうなると視点の移動が極端なデザインになってしまって ユーザーは慣れるのに苦労します。 入力された情報を確認したいなら確認画面を別に用意するのも手だと思います。 [ メッセージ編集済み 編集者: otf 編集日時 2008-03-28 19:53 ] | ||||
|
投稿日時: 2008-03-29 01:33
前方系の巨大なエントリー画面は、複数人で分担して開発することが困難で
仕様も複雑になりがち、それが原因で開発期間が当初の見積もりを大幅に 超過することが多いです。 さらに後方系とのスルーテストも遅れプロジェクト全体の遅延を招くため要注意です。 | ||||
|
投稿日時: 2008-03-31 10:49
皆さん、ご意見たくさんありがとうございます。
どの意見もうなづけるものばかりで、大変参考になりました。 週末にかけて社内で話を揉んだ結果、 1024の解像度に収めるサイズとすることは了承してもらえました。 スペースが足りない分はタブコントロールを増やして対応します。 ひとまずご報告まで。 ひとつ疑問に思ったことがあるのですが
今回の画面では、検索条件として３０個以上の項目があるものが少なくありません。 もちろん毎回全部指定されるわけではないのですが それらの項目の殆どが「あいまい検索」となっています。 たとえば、「取引区分」という検索項目があったとすると、 「取引区分名称でのあいまい検索」となります。 （取引区分はマスタ化されています） このような設計の場合は、将来チューニングしようと思っても、検索項目を減らす以外にチューニングのしようがあるものなのでしょうか？ | ||||
|
投稿日時: 2008-03-31 11:43
後からチューニングできるというのは
保障できるパフォーマンスの範囲での話です。 その範囲外のことを考慮するのであれば要求自体を変える必要もあるかもしれません。 例えば、検索を定数時間内に終わらせることを保障しろと言われたら当然、 要求のほうをそれに合わせる必要があります。（要求によっては不可能なので） しかしながら要求を変えるのは最終手段であるべきだと思います。 ただ私が思うのはよっぽど無理なパフォーマンス要求がない限り チューニングでなんとかなるんではないかということです。 そしてそのチューニングする上で重要なのは実測なので、実測できる段階でチューニングするのが好ましいということです。 検索がネックになってるんであれば恐らくSQLやデータベースの調整が主になるかもしれません。 パフォーマンスチューニングは専門ではないので詳しいことはわかりませんが 筋はこんな感じだと思います。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.