アプリケーションは、コンポーネントを論理的に、作業に基づいて整理された形でユーザに提示しなければなりません。ユーザがどのデスクトップでも同じ規則と操作を利用できるようえに、メニューは共通の構成と命名規則に従わなければなりません。この章では、共通デスクトップ環境のアプリケーションの設計とメニュー構造の要件について説明します。
アプリケーション内のコントロールの物理的な構成を設計するときは、デスクトップ内で一貫性のあるインタフェースがユーザに提示されるように、次のガイドラインを使用する必要があります。
必須 |
6-1: |
アプリケーションは、少なくとも 1 つのメイン・ウィンドウで構成されていなければならない。 メイン・ウィンドウには、クライアント領域と、オプションでメニュー・バー、コマンド領域、メッセージ領域、およびスクロール・バーがあります。クライアント領域には、アプリケーションのフレームワークがあります。メイン・ウィンドウを使用することにより、アプリケーション間での一貫性が保証されます。 |
必須 |
bd: |
アプリケーションのメイン・ウィンドウのデフォルト・サイズは、典型的なデータの量を扱えるだけの大きさでなければならないが、他のアプリケーションとの視覚的な衝突を最小限に抑えるために、物理的ディスプレイ・サイズ全体を占有してはならない。 |
必須 |
6-2: |
アプリケーションが、同じ主機能を備える複数のメイン・ウィンドウを持っている場合は、各ウィンドウが独立に閉じたりアイコン化される。 たとえば、テキスト・エディタでは、複数のドキュメントを、それぞれ独立したメイン・ウィンドウ内で編集できます。この場合、各ウィンドウは独立したアプリケーションとして扱われ、使用されていないときは閉じたりアイコン化したりできます。 |
必須 |
6-3: |
アプリケーションが、異なる主機能を備える複数のメイン・ウィンドウを持っている場合は、各ウィンドウが他のウィンドウとは独立にアイコン化できなければならない。 たとえば、デバッガは、ソースコードの編集、データ値の確認、および結果の表示のために別のメイン・ウィンドウを用意していることがあります。各ウィンドウは、使用していないときはアイコン化できますが、各ウィンドウが別々に閉じられるのか、1 つのウィンドウを閉じるとアプリケーション全体が閉じられるのかは、アプリケーションによって異なります。 |
必須 |
be: |
サイズ変更コーナーは、スクロールするデータ区画やリストを含んでいるすべてのメイン・ウィンドウに組み込まれていなければならない。 ウィンドウの全体的なサイズを変更したら、それに応じて、スクロール可能な部分のサイズも増減しなくてはなりません。さらに、アプリケーションは空間の増減に基づいて、ウィンドウ内の要素の配置を再構成することもできます (たとえば 1 行のボタンを 2 行に再構成します)。 |
これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、修正を加える必要があります。
必須 |
6-4: |
アプリケーションがメニュー・バーを持つ場合、メニュー・バーは、アプリケーションの上方、ウィンドウ枠のタイトル領域のすぐ下に置かれる。メニュー・バーは、アプリケーションで最もよく使われる機能をまとめたものである。メニュー・バーは階層式ボタンの形で、メニュー・トピックのリストを含んでいる。各ボタンは、機能によってグループ化されたコマンドを格納する独立したプルダウン・メニューに関連付けられている。メニュー・バーを使用することにより、アプリケーション間の一貫性が保たれる。 メニュー・バーは、アプリケーションの最もよく使われる機能をまとめたものです。メニュー・バーはボタンの形で、メニュー・トピックのリストを含んでいます。各ボタンは、機能によってグループ化されたコマンドを格納する独立したプルダウン・メニューに関連付けられています。メニュー・バーの使用は必須ではありませんが、強く推奨します。 |
必須 |
6-5: |
アプリケーションのメニュー・バーには、階層式ボタンだけを格納する。 バーの中で他のタイプのボタンを使用すると、メニュー構造をブラウズできなくなります。 |
推奨 |
bn: |
「標準」と見なされるいくつかの一般的なメニュー操作がある。標準のメニュー・バー項目は [ファイル]、[編集]、[表示]、[オプション]、および [ヘルプ] である。アプリケーションがこの種の機能をユーザに提供する場合、メニュー・バーの適切な名前の下に入れておく。これらのメニュー項目の内容については、後で詳細に説明する。 標準メニュー・バーのエントリは次の順序で表示しなければなりません。 [ファイル] [編集] [表示] [オプション] [ヘルプ] アプリケーションがこれらの項目に関連する機能をサポートしない場合は、メニュー・バーから削除してください。たとえば、アプリケーションがデータを異なった表示方法で表示する能力を持っていない場合は、[表示] メニューは削除しておくべきです。 |
推奨 |
bo: |
ファイル指向でないアプリケーション (つまり、ファイルを透過的に管理し、このアクションをユーザに見せないアプリケーション) は、[ファイル] メニューを 1 つ以上のアプリケーション固有のメニューに置き換える。 [ファイル] メニューの代わりとして使用するメニューの例 代替メニュー 1: <app-label> [選択] 代替メニュー 2: <app-label> <obj-type> 代替メニュー 3: <obj-type> アプリケーションが複数のオブジェクト型を持っている場合は、代替メニュー 1 を使用できます。<app-label> の項目は、オブジェクト型に依存しないグローバルなアクションに使用されます。[選択] の項目は、現在選択されているオブジェクトに関連するアクションで、現在選択されているオブジェクトに応じて変更できます。何も選択されていない場合、このメニューは「何も選択されていない」ということを示す単一の項目のみを持ちます。項目が選択されているが、そのオブジェクトに適用する項目が存在しない場合、このメニューは「なし」という単一の項目のみを持つことになります。 アプリケーションが、単一のオブジェクト型を持っている場合は、代替メニュー 2 を使用できます。アプリケーションに対してグローバルなアクションは <app-label> にあり、オブジェクト型に固有のアクションは <obj-type> にあります。 アプリケーションが、単一のオブジェクト型を持ち、<app-label> メニューを必要としない場合は、代替メニュー 3 を使用できます。たとえば、印刷マネージャは [プリンタ] メニューを格納できます。 これ以外の、ファイル指向のアプリケーションに適用されるメニューバーのガイドラインも、ファイル指向でないアプリケーションに適用されます。したがって、次のメニューバーは有効です。 |
|
|
<app-label> [選択] [編集] <カテゴリ 1> [表示] <カテゴリ 2> [ヘルプ] 複雑なアプリケーションや、ドメインに高度に依存するアプリケーション (たとえば、CAT スキャン・データの医学的なイメージ処理と診断のためのアプリケーションなど) では、メニュー・バーの設計に他のアプローチを採用しなければならないことがあります。次に例を示します。 <app-label> <カテゴリ 1> <カテゴリ 2> [選択] [編集] <obj-type> [オプション] [ヘルプ] |
推奨 |
bp: |
[終了] または [閉じる] は、メニュー・バーの先頭の (一番左の) メニューに置かれていなければならない。 |
ユーザ・アクションは、幅広いアプリケーションに共通するカテゴリに分類されます。アプリケーションは、ユーザが目的の機能を素早く見つけだせるように、可能な限り、次の標準メニューを使用するべきです。
これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。
必須 |
6-7: |
アプリケーションが [ファイル] メニューを使用する場合、該当するアクションが実際にアプリケーションによってサポートされているならば、次に示す機能の選択肢を格納していなければならない。 項目は、次に示す順序で、ユーザに提示されなければなりません。いずれの場合も、ユーザにダイアログを表示することが推奨されており、ダイアログが第 7 章「一般ダイアログ」に記されている機能を持っているならば、アプリケーションはダイアログ・ボックスを使用するべきです。
|
<obj-type> メニューは、ユーザがオブジェクト型のインスタンスを作成するためのコントロールを格納しています。<obj-type> メニューと [選択] メニューは、ユーザがオブジェクト・インスタンスを操作できるようにします。アプリケーションが管理するオブジェクトの操作だけに関連する操作 (アプリケーションが提供する、より一般的なサービスでないもの) があれば、<obj-type> または [選択] メニューに項目として追加します。
これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。
推奨 |
bt: |
アプリケーションに [表示] メニューがある場合、このメニューは現在のデータの表示方法に影響を与える機能だけを含む。データそのものを変更するオプションは含まない。 |
推奨 |
bu: |
アプリケーションが、アプリケーションの動作を制御するためのグローバルな設定を持っている場合は、これらの設定を行うための [オプション] メニューを用意する。 |
これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。
アタッチメントをサポートするアプリケーションで推奨されるメニューの詳細は、第 3 章「ドラッグ&ドロップ」を参照してください。
これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。
ポップアップ・メニューは、頻繁に使用される機能へのアクセスを提供し、共通デスクトップ環境のあらゆる場所で使われます。ポップアップ・メニューは、メニュー・バーで使用可能な複数のメニューのオプションを格納できます。たとえば、[ファイル] メニューと [編集] メニューの両方の項目を格納できます。
必須 |
6-12: |
ポップアップ・メニューが選択のコンテキストでポップアップされる場合、要素に作用するアクションは、選択全体に作用する。 選択のコンテキストでは、ポップアップ・メニュー・アクションは選択全体に影響を与えます。 |
アプリケーション固有のメニュー区画を設計するときは、使いやすさとアクセスのしやすさを最大限にするために、次の指針に従ってください。
推奨 |
ce: |
ファイル選択ダイアログが表示される場合のように、メニュー項目を選択することで、ユーザにさらに詳細な情報が求められる場合、メニュー項目の末尾には省略記号 (「...」) を付ける。この要件は、簡単な警告や確認ダイアログが表示されるだけのメニュー項目には適用されない。 省略記号を使用することにより、ユーザはインタフェースの動作を予測しやすくなります。省略記号のない項目を選択する場合は、ただちに結果が発生すると予想できます。 |
推奨 |
cf: |
アプリケーションの中からアクセスされるメニューは、少なくとも 2 つのメニュー項目を含んでいなければならない。 項目を 1 つしか含まないメニューがあってはなりません。アプリケーションに 1 項目しかないメニューがある場合は、その項目を別のメニューに移動するか、ウィンドウの中のボタンにすることを検討してください。メニューが長くなると、下の方にある選択肢にアクセスするのは、ユーザにとって面倒になります。メニューに大量の選択肢が格納されている場合は、複数のメニューに分割するか、いくつか項目をサブメニューにまとめます。 |
オプション |
cg: |
アプリケーションの中からアクセスされるサブメニューは、少なくとも 3 つのメニュー項目を含んでいなければならない。 サブメニューは、主階層メニューに全項目を入れるとメニューが長くなりすぎる場合に、似ている項目を 1 つの副階層メニューにまとめるために使用されます。しかし、サブメニューにオプションが 2 つしかない場合は、副階層メニューを削除して、オプションを主階層メニューに入れることを強く推奨します。これは、サブメニューに置かれているオプションにアクセスするには手間がかかるからです。 |
オプション |
ci: |
アプリケーションに、頻繁にアクセスすることが予想されるメニューがある場合は、そのメニューにティアオフ・メニュー・オプションを用意する。 アプリケーションの使用中にメニューを固定表示できるように、頻繁にアクセスするメニューはティアオフできるようにしておかなければなりません。 |
必須 |
6-14: |
アプリケーションがメニューの中でティアオフ・ボタンを使用する場合、ティアオフ・ボタンはメニューの最初の要素でなければならない。 |
オプション |
cj: |
適当と思われる場合は、キーボード・アクセラレータを用意する。 メニュー全体ではなく、メニューの特定のメニュー項目が頻繁に使用されると予想されるならば、アプリケーションはこれらの項目のキーボード・アクセラレータを用意し、そのキーボード・アクセラレータを、対応するメニューの、該当する項目の右側に表示します。すでにシステム機能に対して定義されているアクセラレータは使用してはいけません。定義済みのキー割り当てのリストについては、付録 A 「キーボードの機能」を参照してください。 |
推奨 |
ck: |
メニュー・バーの項目に使用されるラベルは、メニューそのもののオプションとして使用してはならない。 メニュー・バーの項目名は、メニューが格納するオプションのタイトルの役割を果たします。メニュー・バーの項目名は、すべてのメニュー項目に関連するカテゴリの概念を正確に記述するものでなければならず、メニューそのものの中の項目名として使わないようにします。 |
必須 |
cl: |
その時点で適切な選択ではないメニューの選択肢は、必ず選択不可になっていなければならない。 選択不可のコントロールは、ユーザが起動できないコントロールで、アクティブでない状態が短期間しか続かない場合にのみ使用します (つまり、アプリケーションまたはデスクトップ環境の中で、そのコントロールをアクティブにするための手段が存在する場合)。コントロールが、(現在のアプリケーションまたはシステムの構成のため、またはそのメニューを使用する特定のソフトウェアがインストールされていないために) 永続的にアクティブでない場合は、コントロールを選択不可にするのではなく、メニューそのものから削除します。 |
必須 |
6-15: |
すべてのメニューは、最も幅の広い要素が収まるだけの幅を持っていなければならない。 |
ツール・バーは、アプリケーションで、他の手段によってすでにユーザがアクセス可能なものへの素早いアクセスを提供する手段です。たとえば、アプリケーションは、ツール・バーのメニューで、頻繁に使用される機能へのアクセスを提供できます。ツール・バーの一般的な用途としては、ナビゲーション、データ表示の変更、頻繁に使用されるツールやエディタへのアクセス、一般的な操作を実行するためのステップ数の削減、頻繁に使用されるメニュー項目への高速な経路の提供などがあります。
必須 |
fd: |
ツールバーを使用する場合は、メニュー・バーのある主ウィンドウでのみ使用する。 |
必須 |
fe: |
ツールバーは、すでにアプリケーション・メニューから使用できる操作しか含んでいてはならない。ツール・バーのすべての項目は、その機能を十分に表していなければならない。 ツールバーの項目は、他の手段によってすでにアクセスが可能なものへの素早いアクセスを提供するものでなければなりません。 |
必須 |
ff: |
ツール・バーのアイコンが表すアクションが、ユーザからは使用できない場合、そのアイコンは網かけで表示され、選択不可になっていなければならない。メニュー項目が選択不可になったら、対応するツール・バー項目も選択不可にならなければならない。 |
推奨 |
fg: |
ユーザがツール・バーを隠すことができるオプションを用意する。 |
アプリケーションと、それに付属するツール・バーを設計するときには、次の点に注意してください。
これらの項目をツール・バーに配置することで、アプリケーションの有用性は向上するか
ツール・バーは、いくつもの巨大なメニューを持つアプリケーションの場合のように、一般的な操作へのユーザ・アクセスを改善したり、拡張する場合にのみ使用します。
ツール・バーには、どのような種類の操作が置かれるのか。どのようにグループ化するのか
ツール・バーでは、アクションが自然に分類されていなければなりません。互いに似ていない項目をグループ化すると、希望の項目が見つかりにくく、ユーザが混乱する可能性があります。
項目が多すぎないか
ツール・バーに多くの項目を配置すると、ユーザは希望の項目を捜さなければならず、素早く見つけて使用することができなくなります。アプリケーションのツール・バーを使うときの難易度が高くならないように、ボタンの数は最小限に抑えます。
アイコンは、対応するアクションをはっきりと表しているか
意味不明のアイコンは、ユーザにとって混乱の元です。ピックスマップはできるだけ単純なものにします。すべてのグラフィックが国際的に通用しなければならないことに注意します。[保存] のようなコマンドを表すグラフィックを設計するときは、そのアイコンが、ほとんどのアイコンが表す名詞ではなく、動詞を表さなければならないということに注意します。さもないと、アイコンがユーザにとってますますわかりづらくなります。
ツール・バーは、一般には、次の Motif コンポーネントを使って構築されます。
ツール・バーは、ツール・バーを構成する描画ボタンの配置機能であるコンテナ・コンポーネントを使用します。ツール・バーでは、指定された動作が可能でありさえすれば、ほぼあらゆるコンテナが使用できます。
必須 |
fh: |
ツール・バーのコンテナは、メニュー・バーのすぐ下に配置され、ウィンドウと同じ幅で、高さもメニュー・バーとほぼ同じでなければならない。 |
推奨 |
fi: |
アプリケーションでツール・バーを使用する場合は、ツール・バーと同じ主ウィンドウにステータス行を用意しなければならない。 このステータス行は、現在マウスがその上にある、あるいはキーボード・フォーカスを持っているボタンの目的に関して、フィードバックをユーザにただちに表示します。矢印がツール・バーのアイコンの上にある場合、ステータス行は、そのアイコンが表しているもの、あるいはユーザがそのアイコンをクリックしたときに起こることについて、簡単な定義を表示します。 |
推奨 |
fj: |
ツール・バーのアイコンの下にラベルを付けることができる。これらのラベルは、アイコンの目的を説明するという役割を持つ。 |
Motif の描画ボタンは、ツール・バーのグラフィック・ボタンに適した手段です。
推奨 |
fk: |
ツール・バーの描画ボタンは、幅と高さが同じでなければならない。互いに似ている、あるいは関連のある項目はグループ化し、各グループはツール・バー上で均等に配置されていなければならない。 |
描画ボタンのピックスマップは、そのボタンを押すことによって期待される機能を伝えるグラフィックです。
推奨 |
fl: |
ツール・バーのすべてのピックスマップは、同じサイズでなければならない。 これにより、すべてのボタンが同じサイズになることが保証されます。 |
推奨 |
fm: |
ピックスマップの推奨サイズは 24*24 である。描画ボタンのデフォルトの動作は、そのラベル・タイプのサイズに従って自らサイズ変更を行うことであるが、この場合はピックスマップのサイズに合わせる。 |
主ウィンドウと副ウィンドウのタイトルを定義するときは、次のガイドラインに従ってください。
推奨 |
gt: |
ユーザが選択したコマンドが完了するまでにかかる時間が 2 秒よりも長く、10 秒よりも短いと予想される場合、アプリケーションは、コマンドが実行中であることをフィードバックする標準のビジー・ポインタを表示する。 ユーザには、アプリケーションが要求を「聞き入れて」おり、その作業を実行しているという保証を与えなければなりません。要求の結果をただちに表示できない場合は、何らかのフィードバックを提供する必要があります。ビジー・カーソルは、コマンドの実行から 0.5 秒以内に表示されなければなりません。 |
推奨 |
gu: |
ユーザが選択したコマンドが完了するまでにかかる時間が 10 秒を超えると予想される場合、アプリケーションは、要求の処理を行なっていることを示す作業中ダイアログ・ボックスや、これに似た何らかのフィードバックを表示する。フィードバックは、そのアクションの完了に向けての経過状況を示すものでなければならない。 あるアクションが完了するまでに長い時間 (10 秒以上) がかかると予想される場合、アプリケーションはビジー・ポインタよりも強いフィードバックを表示しなくてはなりません。ビジー・ポインタの表示時間が長くなりすぎると、ユーザはアプリケーションがハングアップしたと思うかもしれません。このような場合には、アプリケーションが実行を続けており、ユーザの要求を処理していることを示す経過表示を行います。経過表示は、アクションのどれだけの部分が完了したのか、どれだけの部分が残っているのかを表示しなければなりません。 |
推奨 |
gv: |
アプリケーションが実行中の作業のフィードバックをユーザに表示しているときに、デスクトップ環境の他のアプリケーションやサービスに対するアクセスを中断しない。 マルチタスクは必ずサポートされなくてはならないので、アプリケーションは何らかのアクションを実行している間も、他のサービスへのアクセスを許可しなければなりません。可能ならば、ユーザは、アプリケーションが別の要求の処理を行なっている間も、同じアプリケーションの別の機能にアクセスできるべきです。これがサポートされている場合、アプリケーションは、ビジーではあるが、入力の受け付けは行なっていることを示す拡張ビジー・ポインタを表示します。 |
必須 |
ep: |
アプリケーションのウィンドウに入力フォーカスがある場合、そのウィンドウの内部に、入力フォーカスを持っているコントロールが常に 1 つだけ存在する。 アプリケーション内のいずれかのウィンドウにフォーカスがある場合、そのウィンドウ内のコントロールのどれかがフォーカスを持たなければなりません。ユーザがウィンドウ内の特定のコントロールにフォーカスを明示的に設定しなければならないようにしてはいけません。 |
オプション |
eq: |
アプリケーション内のテキスト・フィールドに入力フォーカスがない場合、そのフィールド内にテキスト・カーソルは表示されない。 Motif のスタイルでは、アクティブでないテキスト・カーソルの使用が許可されていますが、アクティブでないテキスト・カーソルを表示するよりも、フォーカスがないテキスト・カーソルを隠す方を推奨します。これにより、ユーザは画面またはウィンドウを見ただけで、どのテキスト・フィールドがフォーカスを持っているのかを簡単に捜し出せます。 |
オプション |
er: |
アプリケーションは、アプリケーション内で表示するすべてのボタン、メニュー、およびメニュー項目に対して、キーボードのニーモニックを用意する。 アプリケーションに精通したユーザにとって、キーボードのニーモニックは各種の機能に素早くアクセスするための手段となります。また、ニーモニックは、キーボード型のアプリケーションやウィンドウで、各種の機能へのアクセスを簡単にします。マウスの使用とキーボードの使用を頻繁に切り替える必要がなくなります。ニーモニックは、ユーザ・インタフェースのあらゆる場所に用意しておくべきです。 |
オプション |
es: |
アプリケーションは、ユーザが頻繁に使用すると予想される機能について、キーボード・アクセラレータを用意する。 キーボード・アクセラレータは、アプリケーションに熟練したユーザにとっては、メニューやダイアログ・ボックスを通らずにアプリケーションの機能を素早く使うための手段となります。 |
必須 |
ev: |
アプリケーションが、マルチクリックのタイムアウト間隔、ドラッグのしきい値、ウィンドウのカラー設定、マウスの左利きと右利きといったグローバルな環境設定の値を使用せず、これらの設定について独自の値を使用する場合、アプリケーションはこれらの設定の値を変更するための 1 つ以上の [オプション] ダイアログ・ボックスを用意しなければならない。 一般に、グローバルな環境設定として扱われる設定の値を無効にしてはなりません。これらの設定は、共通デスクトップ環境スタイル・マネージャを用いて、ユーザが制御します。これらの設定を無視して、独自の設定を指定した場合、アプリケーションは共通デスクトップ環境デスクトップ内の他のアプリケーションとの一貫性を失います。それにもかかわらず、独自の値を用意したい場合は、デスクトップの他の部分との一貫性を保つための手段を、ユーザに提供する必要があります。 |
必須 |
em: |
アプリケーションは、フロントパネルやサブパネルに直接インストールするのではなく、アプリケーション・マネージャのフォルダにインストールしなければならない。一貫性を保つために、フロントパネルやサブパネルには、共通デスクトップ環境のデスクトップ・コンポーネントだけがインストールされることになっている。ユーザはフロントパネルを再編成できるが、アプリケーションはユーザの同意なしに、これを行うべきではない。 |