長谷川 裕行 （はせがわ ひろゆき）
有限会社 手國堂 代表取締役
http://www.hirop.com/
テクニカルライターとして活躍。プログラミングに関する著書多数、DB Magazineなどにも多くの記事を提供している。 |
メニューの構造や画面の見た目は、プログラムの本質とは無関係だと思う人もいるかもしれません。が、決してそうではありません。内部の処理がどれだけ高性能でも、使い勝手が悪ければ能力を十分に発揮できません。
ユーザーは、まず見た目と表面的な操作感で、ソフトウェアの良し悪しを判断します。「嫌だなあ」と思うとその時点で真剣に操作する気がなくなり、操作を間違える可能性も高くなります。ユーザーを落ち着かせ、メッセージや画面の意味を冷静に判断できる環境を作るのも、ソフトウェアの役割です。
前回(第18回)で、業務用アプリケーションはメニュー画面から始まることを説明しました。メニューはアプリケーションの入口であり、ユーザーをプログラムに導く重要な役割を果たします。
- メニューはアプリの顔 -
メニューはアプリケーションを起動して真っ先にユーザーの目に触れ、その後の操作を誘導していく役目を持っています。従って、メニューはアプリケーションの顔であり、受付係、案内係でもあります。
すべての業務用アプリケーションが、メニューから始まる訳ではありません。単一の処理だけで出来上がっているアプリケーションもあります。が、多くの業務アプリケーションは、目的となる業務自体が複数の小さな処理の集まりである場合が多いため、ほとんどの場合、処理選択のメニューが必要になります。
ユーザーを実際の処理画面へと導いていく方法には、大きく分けて以下の3つのアプローチがあります。
1.常にメニュー画面から始める
2.中心となる処理を起動する
3.処理ごとに別アプリケーションとする
1.の方法は、最も一般的で構成しやすい方法です。残る2つの方法は1の変型、あるいは発展型といえます。
- 中心となる処理を起動する -
業務によっては、頻繁に実行する処理が決まっているものもあります。例えば経理事務では、ほとんどの場合振替伝票の入力(入出金処理)が中心となり、それ以外の処理は補助的なものとなるでしょう。
販売管理では売上の入力、在庫管理では入出庫の入力が中心となり、残る処理が補助的なものとなります。このように、多くの業務処理では「最も頻繁に実行する処理」あるいは「中心となる処理」が決まっている場合がほとんどです。
そのような場合には、アプリケーションが起動したときに中心となる処理のフォームがオープンしていた方が便利です。
- 処理ごとに別アプリケーションとする -
「はじめにフォームありき」というスタイルのVBでは、とにかく処理ごとに最低1つのフォームが必要になります。そのため、自然と処理ごとに別モジュールとして構成できてしまうのですが、問題は1つの処理が複数の小さなフォームをたくさん使うような場合です。そうすると、どのフォームがどの処理から呼び出されているかがわかりづらくなってしまいます。
そのような、大規模でフォームをたくさん使うアプリケーションでは、思い切って「処理ごとに別アプリケーション」としてしまうことも考えられます。
どのような業務でも、常にすべての処理を実行することはありません。頻繁に起動する処理はごくわずかなはずです。すべての処理を1つのアプリケーションに収めてしまうと、「ほとんど使用しない処理のために、メモリ領域を消費する」ことになってしまいます。処理ごとに異なるアプリケーションとしておけば、メモリの消費を押さえることができます。
- WindowsScriptを利用する -
この場合
メニュー画面を表示するアプリケーションで処理を選択したら該当する処理を行なうアプリケーションを起動する
という形となります。
このような形を実現するには、すべてをVBから実行する他に、WindowsScriptを使う方法も考えられます。具体的な手法については、回を追って紹介していきましょう。
どのようなスタイルを採ったとしても、最終的にはメニュー画面が必要になります。これは、目的となる業務が複数の小さな処理で成り立っているという業務アプリケーションの性格上、どうしようもないことです。
ここで、メニュー画面のデザインについて考えてみましょう。
- 在庫管理業務で考える -
メニュー画面は、基本的にコマンドボタンの集合です。そのため、デザインについてあまり意識しないで済むように思う人もいるかもしれません。しかし、ただコマンドボタンを並べただけでは、使いやすい画面とはなりません。
ここでは、在庫管理業務を例にしてみましょう。在庫管理業務は、以下のような処理から構成されているとします。
入庫、出庫、日締め、月締め、年締め、在庫数検索、在庫一覧、棚卸、在庫調整、商品追加、商品削除、商品修正
在庫管理で最も頻繁に使用されるのは、入庫または出庫の処理です。これらの処理をひとまとめにし、常に入出庫処理の画面が表示されている――という形態が一般的でしょう。すると、残る関連業務はメニュー画面から実行することになります。
- 処理を分類する -
ここで、これらの処理が種類別に分類できることも考える必要があります。
| 日時処理 |
| |
入庫 出庫 日締め |
| 月次処理 |
| |
月次集計 在庫一覧 棚卸し |
| 年次処理 |
| |
次集計 在庫一覧 棚卸し |
| 随時処理 |
| |
在庫数検索 在庫一覧 棚卸し 在庫調整 |
| データ保守 |
| |
商品追加 商品削除 商品修正 |
このように処理は階層構造を成し、同じ処理、あるいは似たような処理が異なる業務分類に属する場合もあります。
- 階層化メニューと単一メニュー -
こういった階層構造の項目をメニューとする場合、2とおりのアプローチがあります。
1.メニュー構造自体を階層化する
2.1つのメニュー画面を分類ごとに区切る
1.メニュー構造自体を階層化する
メニュー構造を階層化するとは、処理の分類ごとに異なるメニュー画面を設け、最初に表示されるメニューからさらに子メニュー→孫メニュー…と、メニュー画面を切り替えていく方法です。
以下の例では、分かりやすいように日本語のフォーム名を用いています。サンプルでは、フォームfrmMainMenu1に登録されています。
例)
メインメニュー(frmMainMenu)
コマンドボタン:入出庫 月次処理 年次処理 随時処理
| 入出庫メニュー(frm入出庫) |
| |
入出庫処理用フォーム |
| 月次処理(frm月次処理) |
| |
コマンドボタン:月次集計 在庫一覧 棚卸 |
| 年次処理(frm年次処理) |
| |
コマンドボタン:年次集計 在庫一覧 棚卸 |
| 随時処理(frm随時処理) |
| |
コマンドボタン:在庫数検索 在庫一覧 棚卸 在庫調整 データ保守 |
| データ保守(frmデータ保守) |
| |
コマンドボタン:商品追加 商品削除 商品修正 |
図1:階層化されたメニュー構造
画面1:階層構造のメニュー(メインメニュー)
画面2:階層構造のメニュー(メインメニューから「随時処理」→「データ保守」と選択)
メニュー項目をすべて1つのフォーム上にコマンドボタンとして割り当て、処理の種類ごとにフレームなどを用いて視覚的に区切ります。
以下の例では、分かりやすいように日本語のフォーム名を用いています。サンプルでは、フォームfrmMainMenu2に登録されています。
例)
メインメニュー(frmMainMenu)
| 日常の処理(フレームで区切る) |
| |
コマンドボタン:入出庫 |
| 月次処理(フレームで区切る) |
| |
コマンドボタン:月次集計 在庫一覧 棚卸 |
| 年次処理(フレームで区切る) |
| |
コマンドボタン:年次集計 在庫一覧 棚卸 |
| 随時処理(フレームで区切る) |
| |
コマンドボタン:在庫数検索 在庫一覧 棚卸 在庫調整 |
| データ保守(frmデータ保守) |
| |
コマンドボタン:商品追加 商品削除 商品修正 |
| 入出庫メニュー(frm入出庫) |
| |
入出庫処理用フォーム |
画面3:処理を種類ごとにフレームで区切ったメニュー
上記2とおりの方法には、それぞれ長所と短所があります。処理の数や種類に応じて、使い分けるのがよいでしょう。
| ・ |
階層化したメニュー |
| |
長所 |
処理ごとに別メニューとなるため、処理の選択を間違えにくい |
| |
短所 |
他の処理に切り替えるための操作が繁雑になる |
|
|
| ・ |
1つの画面を区切ったメニュー |
| |
長所 |
画面が1つだけなので、処理の切り替えが簡単 |
| |
短所 |
異なる処理も同じ画面から実行できるため、選択を間違えやすい |
このように、2つの方式は長所と短所が互いに裏表の関係となっています。従って、以下のように使い分けるとよいでしょう。
| ・ |
処理項目が多く、異なる分類に似たような項目名がある場合 |
| |
→ |
階層化したメニュー |
| ・ |
処理項目が少なく、迅速な処理が必要な場合 |
| |
→ |
1つの画面を区切ったメニュー |
メニュー画面に次いで重要な画面は、当然のことながら実際の処理画面です。そこには、コマンドボタン、テキストボックス、チェックボックスなど、様々なコントロールが配置されます。
これらコントロールのプロパティ設定にも、扱いやすさを考慮する必要があります。VBでは、マウスのドラッグでコントロールの位置やサイズを簡単に設定できますが、簡便さゆえに適当に貼り付けてしまい、ユーザーに不便を強いることもあるのです。
- テキストボックスのサイズ -
テキストボックスは、「どのような文字列を入力したかがユーザー自身に分かる」だけのサイズとします。最低限、設定されたフォントが余裕を持って表示されるだけの高さが必要です。
テキストボックスの最低限の高さはフォントサイズに合わせて設定されるため、文字が隠れることはありませんが、ギリギリの高さだと窮屈に感じられます。また、高過ぎて余白が多くても間が抜けて見えます。
画面4:高さは高過ぎず低過ぎず…
・長すぎず短すぎず
また、入力される最大の文字数を表示できるだけの長さを確保することが基本です。データベースと連結されている場合は、連結先フィールドの最大文字数をカバーできるだけの幅を設定します。このとき幅が長すぎると、ユーザーは「まだ文字が入力できる」と勘違いします。
幅が文字数に足りないと、入力中に横スクロールします。「文字が読めればいいじゃないか」と思ってはいけません。先に入力した文字が隠れると、ユーザーは不安です。
幅と高さは、フォントの設定と関連します。プロポーショナルフォントでは、入力した文字によって幅が異なる場合もありますが、日本語を扱う場合には、これは大きな問題とはなりません。日本語は固定ピッチのフォントとするのがよいでしょう。
画面5:幅が最大文字数より狭いと、入力した文字が見えなくなってしまう
・複数行の入力
長い文字列を入力させる場合は、横長とする他にマルチラインとすることもできます。MultiLineプロパティをTrueとするだけです。このときも、幅と高さをフォントと文字数に合わせておきましょう。
- リストボックス、コンボボックスの幅と高さる -
リストボックスやコンボボックスでは、表示されるリストの最大文字数が予め分かります。その最大文字数をカバーできるだけの幅に設定しておきましょう。項目数が多いと垂直スクロールバーが表示されますが、この幅も考慮に入れておく必要があります。
画面6:スクロールバーが表示されると項目が隠れてしまう
リスト項目のほとんどが短い文字数で、一部長い文字列がある場合は、短い方に合せても構わないでしょう。
リストボックスの高さはフォントの高さに合わせて、その整数倍となるよう調整されるため、高さを微調整する必要はありません。
- コマンドボタンのサイズ -
コマンドボタンには、通常キャプションとして文字列を設定します。ボタンの高さが低いと、キャプションが切れてボタンの意味が読み取れなくなります。幅が狭い場合はキャプションが改行されてしまうため、これも見苦しくなります。
画面7:コマンドボタンはキャプションの幅に合せる
・キャプションは1行に
キャプションを1行に表示できるよう、幅と高さを調整しておきましょう。コマンドボタンの場合、他のコマンドボタンとの兼ね合いも重要です。
「入庫」と「出庫」、「日次処理」と「月次処理」のように項目自体が同程度の重要度を持っている場合、コマンドボタンのサイズも同じにしておく必要があります。ボタンのサイズは、それが示す処理の重要度や優先度に比例します。
問題となるのは「在庫数の調整」と「在庫一覧」のように、同じ重要度でありながらキャプションの文字数が異なる場合です。基本的に、長い方の文字数に合せます。「取消」と「コピーしてから追加」のように一方が長すぎる場合は、「コピー追加」のように長い方を短い言葉で表現します。「取消」「追加」のように他の処理でも用いられる表現を、「処理を取り消す」「データを追加します」などと言い換えてはいけません。
・フォーカス取得時の表示に注意
コマンドボタンの場合、フォーカスを受け取るとキャプションが破線で囲まれることも考慮しておきましょう。高さや幅がフォーカスを受け取っていない状態でぎりぎりに設定されていると、フォーカスを受け取った時にキャプションが読みにくくなります。
画面8:フォーカスを受け取るとキャプションが破線で囲まれることも考慮する
- チェックボックス、オプションボタンの -
- 感知範囲 -
意外とおろそかにされるのが、チェックボックスやオプションボタンのサイズです。これらは、プログラムの実行時にコントロールのサイズが明確に表示されません。しかし、これらのサイズは「マウスの感知範囲」を示しています。
ユーザーはチェックボックスの□やオプションボタンの○、およびそのキャプションをクリックして項目をON/OFFします。このときコントロールがキャプションのサイズより大きいと、「思いも寄らない場所をクリックしたら、勝手にON(またはOFF)になった」という事態を招くこともあります。
これらクリックで反応するコントロールでは、空白部分をクリックしてON/OFFを切り替えようとするユーザーは少ないので、キャプションの長さぴったりに設定しておいた方がよいでしょう。
画面9:チェックボックスやオプションボタンの領域は大きすぎないようにする
- グリッドコントロールのサイズ -
データベースを用いる場合、レコードセットの内容をそのままグリッドコントロールで表示させることも多いでしょう。その場合、グリッドの幅は全フィールドを表示できるようにするのが基本です。
但し、フィールド数が多い場合は横スクロールさせることも必要になります。その場合も、幅は最初に表示される1レコードの幅に合わせましょう。右端がフィールドの途中で切れていると、非常に見づらくなります。
画面10:横幅は最初に表示されるフィールドに合わせる
高さは1行の高さの整数倍とします。テキストボックスやリストボックスは、フォントサイズに合わせて高さ調整されますが、グリッドコントロールはサイズが自由に変更できます。表示されている最後のレコードが途切れると見苦しいものです。
グリッドにヘッダ(項目見出し)を設ける場合、そのフォントにも注意しましょう。また、フォントをボールド(太字)にすると、わずかに高さと幅が大きくなります。この点にも注意しておきましょう。
画面11:高さは1行の整数倍とする
フォーム上に同じ種類のコントロールが複数並ぶ場合、そのサイズと位置をうまく揃える必要があります。特にメニュー画面では、コマンドボタンが上下にでこぼこしていると非常に見苦しくなります。
- サイズを揃える -
複数のコントロールのサイズを揃えるには、揃えたいコントロールをまとめて選択し、メニューから「書式(O)」→「同じサイズに揃える(M)」のサブメニューから「幅(W)」「高さ(H)」「両方向(B)」の各項目を選択します。
画面12:コントロールを選択してサイズを揃える
- 位置を揃える -
表示位置を揃えたい場合は、同じく揃えたいコントロールを複数選択し、メニューから「書式(O)」→「グリッドに合わせる(D)」(または「整列(A)」→「グリッドに合わせる(G)」)を選択します。この項目は、コンテキストメニューからも選択できます。
但しこの場合、コントロールごとに最も近いグリッドに合わせられるため、必ずしも選択したコントロールがすべて同じ位置に揃うとは限りません。最後は手による微調整が必要です。
- グリッドを利用する -
グリッドは、メニューの「ツール(T)」→「オプション(O)」で「オプション」ダイアログボックスをオープンさせ、「全般」パネルの「グリッドの設定」でマス目のサイズを指定できます。
このとき「グリッドに合わせる(O)」をチェックしておけば、コントロールはグリッドに従って配置されるようになります。
最初はグリッド幅を広めにして大まかに配置し、あとからグリッド幅を小さくして微調整するとよいでしょう。
画面13:グリッドのサイズを変更できる
- 位置揃えは重要 -
処理画面でも、複数のコントロールの高さがまちまちだと、ユーザーはそれだけで操作する気が失せてしまいます。
意外とおろそかにされるのが、オプションボタンの位置です。左端をぴったりと揃えておきましょう。
テキストボックスとその意味を示すキャプションの隙間、テキストボックスの左端の位置なども、他のコントロールときれいに揃えておきましょう。わずかなばらつきで、ユーザーの冷静さを失わせることがあります。
雑然とした部屋や机では落ちついて仕事ができないのと同じで、いかにも適当に並べましたと言わんばかりの画面デザインでは、ユーザーの気持ちを緩ませ、間違いを誘発することもあり得ます。ユーザーの気持ちを落ち着かせ、なおかつ適度な緊張感を与えつつ操作を誘導することが、画面デザインの重要な役割です。
 VBプロジェクトファイルのダウンロード
(LZH形式 13.8KB) |
