はじめに

これは設計時の見落とし Advent Calendar 2018の23日目の記事となります。

業務アプリケーションの設計をするときに、見落としがちなところに焦点をあてて紹介します。
下流工程からの手戻りを少なくして双方の負担を減らしましょう。

画面系の考慮について書いてみます。ただ元記事が10年前なので今となっては古いところがあるかも知れません。

ユーザーのコンピューター操作の熟練度の考慮

マウス操作に重点をおくか、キーボード入力に重点をおくかなどにより、ユーザインターフェイスが違ってくるため、画面設計をする上で考慮が必要です。
画面設計に入る前に、ユーザーに確認しておく必要があります。

キーボード入力に重点をおいている場合、チェックボックスやオプションボタン(ラジオボタン)やコンボボックスなどの入力方法を工夫する、または使用しないなどの考慮が必要になります。
(全ての画面に対して行う必要はなく、個々の画面対応でもいいはずです。)

モーダル/モーダレス画面について

モーダル

一度開いた画面は閉じるまで、他の操作ができない。

メリット

表示中は状態が変更されないため、システム的に同期が取れる。
最前面に表示されることによりユーザーが認知しやすいだけでなく、ユーザーに参照や入力を確実に行わせられる。

デメリット

一旦画面を閉じないと他の操作が出来ない、操作性が不便になる。

モードレス

一度開いた画面を閉じなくても、他の操作ができる。

メリット

画面を閉じなくてもユーザーの操作を制限しないため、快適な操作性ができる。
表示中でも状態が変更できる。

デメリット

表示中でも状態が変更できてしまうため、システム的に同期が取るのが大変になる。
他の操作ができる反面、他の操作をすると画面が背後に隠れてしまう。
(※メモ帳の検索画面のように前面表示にすることは可能）

モーダル/モーダレス中間方式

モードレスにて最上位表示(TopMost)にしたり、アクティブイベントやタイマーなどを使い擬似的にモーダル化することで、両方のメリットを享受できたりします。

最上位表示はいいとして、アクティブイベントやタイマーなどで再表示するのは最近はやらない方がいいでしょうね。

メッセージ出力について

煩わしさ

「登録しました。」／「修正しました。」など、よく出るメッセージはダイアログで出すと煩わしい場合ある、ステータスバーにメッセージを出すだけですませるなど考慮も必要。

メッセージ文言の統一化

画面や機能ごとに文言が微妙に違うことにより混乱する場合がある、表現方法など統一させる。例えば、する/しないの混同など。

ユーザーにわかりやすいメッセージ文言にする

なぜ駄目なのか理由が分かるメッセージにすることで、問い合わせが少なくなる･･･かもしれません。

アクセス権限の使用度の確認点

業務システムでは管理、職務に応じたアクセス範囲と権限設定が必要となってくることがあります。

アクセス権限を使うかどうか
1人が複数のアクセス権限がある場合に権限の選択方法など
アクセス権限はどこまでを考慮するのか

ある画面は、メニューからアクセス権限者以外は、起動できなくする。
ある画面は、起動はするが、参照以外はできなくする。
ある画面は、承認は出来るが、承認解除は出来ないとか
自分で登録した情報を、その本人が承認を行えてしまうようだと業務管理者への牽制が利かないです。不正し放題になってしまう

入力チェックと登録確認メッセージの処理順

1.入力チェック→確認メッセージ→登録処理→完了メッセージ
2. 確認メッセージ→入力チェック→登録処理→完了メッセージ

以前に関わっていたプロジェクトにて、複数項目ある入力画面でDB更新する処理があったのですが入力チェックと登録確認メッセージの順番が気になりました。

「登録しますか？」のメッセージを表示
　　↓ Yesなら次処理 / Noなら処理中断
複数項目の入力チェック処理
　　↓ OKなら次処理 /　NGなら処理中断
DB登録処理
　　↓ OK ならコミットして次処理　/　NGならロールバックして処理中断
「登録しました」のメッセージを表示

上記の方法では複数箇所の項目で入力エラーがあるたびに確認メッセージが出ることになり、煩わしいです。
そんなわけで、次のプロジェクトでは下記のように処理を変更してしまいました。

複数項目の入力チェック処理
　　↓ OKなら次処理 /　NGなら処理中断
「登録しますか？」のメッセージを表示
　　↓ Yesなら次処理 / Noなら処理中断
DB登録処理
　　↓ OK ならコミットして次処理　/　NGならロールバックして処理中断
「登録しました」のメッセージを表示

登録時の整合性チェックと確認メッセージのタイミング

その他

画面項目の非表示とするか無効化とするのか

ユーザーが何かの操作をすれば操作可能になるボタンは無効化
ハードウェアがないなど、ユーザーの通常の操作範囲では操作可能にならないボタンは非表示
「何をすれば操作可能になるか」が十分に明確でない場合にはエラーメッセージ

画面項目の有効化／無効化のタイミング

処理完了後に項目を無効化するのか、処理完了前に項目を無効化するのか

カレンダーの始まりを統一する

通常は日曜からとなっているが業種により月曜日始まりとするか
特に工場と連動している会社では、月曜日始まりのところが多い。
ユーザーのところにお邪魔したときにはカレンダーを見るといいですね。

画面上に説明や手順などを掲載する

マークや色など区別している場合、処理が複雑な場合など

細々な点

必須項目や検索可能項目など背景色やマークなど付けて区別させるなど
コンボボックスを入力可能／不可とするのかどうか
テキストの入力不許可文字例半角カンマ等
ゼロ・パディング(0埋め)、ゼロ・サプレス、コードなど 0パディングさせるのかどうか
小数点の表示方法例 .5 → 0.5 や 0.2 → 0.20 とするかなど
確認メッセージボックスにて、はい/いいえの初期値の設定
明細ごとにチェックボックスがある画面の場合、明細が多くなるなら全選択/解除ボタンを付ける。
Enterキーによる次の項目への移動、項目によっては矢印とか
フォーカスがセットされた時に、ハイライト表示させるのか
マスタの名称管理正式名称と略称の取扱い
マスタの名称の履歴(担当者名など苗字が変わるとか)
明細項目で全桁入りきらない場合、どこまで表示させるのか
コードの書式英数字、英大文字、英小文字有りか、数字のみ全角、半角入力など
IMEの入力モードの切り替え ※人により切替える癖があり逆にじゃまな場合もある
画面の入力順（タブ遷移順）
関連している項目は近くに配置させる
オーバーフロー時の表示方法例「*」マークにするとか