test

共通デスクトップ環境 スタイル・ガイド

パート I スタイル・ガイド

第 1 章 共通デスクトップ環境の紹介

共通デスクトップ環境は、各種の UNIX (AIX、HP/UX、SolarisTM、UnixWare など) のためのグラフィカル・ユーザ・インタフェースです。UNIX は強力でポータブルなオペレーティング・システムです。デスクトップを使用することにより、UNIX はかつてないほど使いやすくなります。

デスクトップは Hewlett-Packard、IBM、Novell、および Sun Microsystems の各社が共同で開発したものです。デスクトップは、これらの企業や、UNIX ワークスペースを販売している他の多くの企業によって、標準操作環境として採用されています。

共通ユーザ・インタフェースの利点

デスクトップ・インタフェースは、UNIX の使いやすさを向上し、一貫性のあるインタフェースを実現します。これには、エンド・ユーザとアプリケーション開発者の双方にとって、数多くの利点があります。その一部を次に説明します。

The Open Group の Motif スタイル・ガイドとの関係

デスクトップ・ユーザ・インタフェースは Motif のガイドラインに従っています。しかし、Motif はデスクトップの定義は行なっておらず、アプリケーションとウィジェットの基本的な動作だけを定義しています。『共通デスクトップ環境 スタイル・ガイド』は、アプリケーションをデスクトップと統合できるようにするためのガイドラインを定義しています。したがって、デスクトップに適合するアプリケーションを作成するには、『CDE 2.1/Motif 2.1 スタイル・ガイドと用語集』と『共通デスクトップ環境　スタイル・ガイド』の両方に従ってください。

デスクトップ・インタフェース・ガイドラインに準拠するかどうかは、自発的に決められることです。公式な認定プロセスは存在しません。このスタイル・ガイドと『CDE 2.1/Motif スタイル・ガイドと用語集』のすべての必要なガイドラインを満たすアプリケーションは、デスクトップに準拠していると見なされます。

注 -

『CDE 2.1/Motif 2.1 スタイル・ガイドと用語集』は、The Open Group (www.opengroup.com) が規定する、Motif スタイル・ガイド・セットのひとつです。このガイドは『OSG/Motif スタイル・ガイド』を改訂していますが、ガイドライン上の違いはわずかです。

こマニュアルでは、各ガイドラインに、「必須」、「推奨」、または「オプション」という優先順位が付けられています。

第 2 章 入力、ナビゲーション、選択、および起動

入力デバイスは、ユーザが対話中のインタフェースの部分に応じて、さまざまなアクションを実行します。通常、マウス・ユーザは、マウス操作の本来の柔軟性によって、キーボード・ユーザよりも簡単にウィンドウやコントロールにアクセスできます。キーボード・ユーザは、アプリケーション内でカーソルを移動するために、特別なキーを使わなくてはなりません。

ユーザは、アクションを起こす場所を指定するために、インタフェースの内部でポインタやカーソルを移動する必要があります。このために、ユーザはナビゲーション方式を使用しますが、その変化はインタフェース内のカーソルの位置に依存します。つまり、ナビゲーションとは、ユーザがインタフェース内でポインタやカーソルを移動する方法という意味です。

ユーザは、インタフェース内の対話したい要素を示すことがしばしば必要になります。ユーザは選択を行なって、それ以降の操作の対象となる個々の要素、あるいは複数の要素を指定できます。

起動とは、コントロールを使ってアクションを実行することです。たとえば、ユーザがボタンを選択したり、メニューから項目を選択した場合、ユーザはそのコントロールを起動していることになります。

以下の節では、入力、ナビゲーション、選択、および起動のための共通デスクトップ環境の要件の概略を説明します。

入力のガイドライン

仮想キーとは、ユーザがインタフェースを介して実行できる一般的な操作の名前です。これらは 1 個以上の物理キーの組み合わせにマッピングされています。[ヘルプ]、[属性]、[元に戻す]、[カット]、[コピー]、および [ペースト] という仮想キーに対応する機能をアプリケーションが持つ場合には、アプリケーション開発者は、これらの仮想キーをサポートすることが強く望まれます。他の仮想キーは、必要に応じたサポートでよいでしょう。

必須 

a: 

Motif/共通デスクトップ環境の仮想キーに対応する機能を持っているコンポーネントやアプリケーションは、それらのキーをサポートしなければならない。 

仮想キーとそのマッピングのリストについては、チェックリスト項目を参照してください。 

ナビゲーション

デスクトップでは、メニューの表示に BSelect または BMenu を使用できます。この機能は、専用のマウス・メニュー・ボタンを提供する環境に慣れたユーザのために追加されたものです。

マウス・ベースのテキスト・フィールドのナビゲーションのために、デスクトップでは、テキスト・カーソルがテキスト・フィールドの先頭または末尾ではなく、マウス・カーソルの位置に置かれなくてはならないという要件が追加されています。

マウス・ベースのナビゲーション

オプション 

b: 

メニュー・バー項目の上で BMenu Press または BMenu Click を行うと、そのメニューが表示される。 

必須 

c: 

オプション・ボタンの上で BMenu Press か BMenu Click を行うと、オプション・メニューが表示される。 

必須 

d: 

テキスト・フィールドの上で BSelect Press を行うと、テキスト・カーソルがマウス・カーソル位置に挿入される。 

キーボード・ベースのナビゲーション

標準キーボードを使う上で困難があるユーザが、キーボード・ナビゲーションを簡単に利用できるように、プッシュ・ボタンのグループの中で [Tab] キーをナビゲーション・キーとしてサポートするという要件が追加されています。この変更は、ユーザが 1 つのダイアログ・ボックスの中でナビゲーションを行うために実行しなければならない、キーボード上の両端 ([Tab] キーと矢印キーの間) の移動回数を減らすことが目的です。

オプション 

e: 

新しいウィンドウが開かれると、キーボード・フォーカスは、そのウィンドウの性質に応じて、ウィンドウの中の最初のフィールドまたは最初の位置、あるいはデフォルトの位置に置かれる。 

必須 

f: 

[Tab] キーは、グループ内のプッシュ・ボタンの間で入力フォーカスを移動する。 

また、矢印キーでも指定のフォーカスを移動する。−『OSF/Motif スタイル・ガイド リリース 1.2』

必須 

g: 

[Control] キー、[Shift] キー、および [Alt] キーは、他のキーまたはキーの組み合わせの機能を変更するためだけに使用する。 

オプション 

h: 

[Alt] キーは、ニーモニックにアクセスするためだけに使用する。 

選択

デスクトップには、Motif における選択に関して、2 つの重要な変更点が組み込まれています。1 番目の変更点は、ユーザが中マウス・ボタンに「アジャスト」または「転送」機能を割り当てることができるということです。さらに、デスクトップでは 1 番目のマウス・ボタンにドラッグと選択の組み合わせを割り当てています。

3 ボタンのマウスでは、ボタン 2 は一般に BTransfer (または BSelect) 機能に使用されています。しかし、共通デスクトップ環境では、ユーザは環境設定を変更して、マウス・ボタン 2 を BAdjust 機能に使用できます。BAdjust は、複数選択モデルにおいて、要素の選択状態を切り替えるために使用できます。

以下のガイドラインでは、BAdjust の動作について説明します。

マウス・ベースの複数選択

必須 

i: 

アプリケーションが、複数選択モデルに従うコレクションを含んでいる場合、BTransfer ボタンが BAdjust として動作するように構成されていれば、BAdjust がサポートされ、BSelect と同じように動作する。 

必須 

j: 

複数選択を使用するコレクションでは、未選択の要素の上で BSelect または BAdjust をクリックすると、その要素が現在の選択に追加される。選択されている要素の上で BSelect または BAdjust をクリックすると、その要素が現在の選択から削除される。BSelect または BAdjust をクリックすると、位置カーソルがその要素に移動する。 

マウス・ベースの範囲選択

必須 

m: 

アプリケーションが、範囲選択モデルに従うコレクションを含んでいる場合、BTransfer ボタンが BAdjust として動作するように構成されていれば、BAdjust がサポートされ、[Shift] + BSelect と同じように動作する。 

必須 

n: 

範囲選択を使用するコレクションで、ユーザが [Shift] + BSelect または BAdjust を押したとき、アンカーは変更せれずに残り、拡張モデルの 1 つに基づいて選択の拡張範囲が決定される。 

 

 

再選択

拡張範囲は、最初に選択を行なったときと同じように、アンカーと現在のポインタ位置によって決定される。 

 

 

拡大のみ

選択は拡大することだけができる。拡張範囲は、アンカーと現在のポインタ位置によって決定されるが、その後、現在の選択を含むように拡大される。 

 

 

バランス・ビーム

現在の選択の中点にバランス・ポイントが定義される。ユーザがバランス・ポイントから見てアンカーの反対側で [Shift] + BSelect または BAdjust を押した場合、このモデルは再選択モデルと同じように動作する。ユーザがバランス・ポイントから見てアンカーと同じ側で [Shift] + BSelect または BAdjust を押したり、[Shift] によって修正されたナビゲーション・アクションを開始した場合、このモデルはアンカーを選択の反対側に移動した後に、再選択モデルと同じように動作する。 

 

 

ユーザが BSelect または BAdjust を離すと、アンカーは移動せず、拡張範囲の中のすべての要素が選択され、その外側のすべての要素の選択が解除される。 

マウス・ベースの不連続選択

必須 

o: 

不連続選択を使用するコレクションでは、BAdjust を使用して、不連続選択の範囲を拡張できる。拡張範囲は、BAdjust を範囲選択の拡張に使用するときとまったく同じように決定される。 

コンポーネントの起動

以下のガイドラインは、ダブルクリックのタイミングとニーモニックを明確に示し、特定のコンポーネントの起動に関する変更点を説明し、CDE Motif で新しく取り入れられたコンポーネントの動作を説明します。

基本的な起動

必須 

x: 

ダブルクリックの検出時間 (*doubleClickTime: 500) は 500 ミリ秒以上でなければならない。 

ニーモニック

必須 

y: 

ニーモニック文字は、ラベルのテキストの中で探しやすい位置を選ばなければならない。可能な限り、ラベルの先頭の文字を使用する。これが不可能な場合は、ラベルの最後の文字を、また複数の単語があるときは 2 番目の単語の先頭の文字を使用する。これも不可能な場合は、ラベルの 2 番目の文字から始めて、固有のニーモニックが見つかるまで順番に調べていく。 

チェックボタン

必須 

7-1: 

アプリケーションは、相互排他的でない設定を選択するために、チェックボタンを使用する。チェックボタンは、チェックマークの有無によって、その状態をグラフィカルに表示する。 

チェックボタンは、相互排他的でない設定を選択するために使用されます。ユーザはボタンが設定されているかどうかがわかる必要があります。 

オプションボタン

必須 

7-23: 

ユーザがオプションボタン内で BSelect または BMenu を押すと、関連するオプション・メニューが固定表示される。 

BSelect Press は、オプションボタンを起動するための一貫性のある手段として利用できます。 

必須 

7-24: 

ユーザが、押したオプションボタン内で BSelect または BMenu を離すと、押した時点でオプション・メニューが固定表示されていない場合は、そのボタンに関連するオプション・メニューが表示される。ユーザがオプションボタンの外側で BSelect または BMenu を離すと、オプション・メニューの固定表示は消去される。 

BSelect Release または BMenu Release は、ボタンを離したのがオプションボタンの中だったのかどうか、また、ボタンを押したときにオプション・メニューが固定表示されていたかどうかに応じて、オプション・メニューの固定表示または消去を行います。 

ゲージ

必須 

ib: 

ゲージは、ユーザとの相互作用がない表示専用のデバイスであるという点を除けば、スケールと似ている。ゲージの外観はスケールと似ているが、ゲージにはスケール・スライダはない。 

オプション 

ic: 

ゲージは表示専用のデバイスであるが、ユーザが [ヘルプ] または [設定] コントロールにアクセスできるように、キーボード・フォーカスを取得するようになっていなければならない。 

第 3 章 ドラッグ＆ドロップ

ドラッグ＆ドロップにより、コンピューティング環境の中のオブジェクトを直接操作できます。この章では、アプリケーションにドラッグ＆ドロップを組み込むためのガイドラインについて説明します。アプリケーションでドラッグ＆ドロップやアタッチメントを使用する場合は、この章を読んでください。

『OSF/Motif スタイル・ガイド リリース 1.2』で扱われている Motif 1.2 のドラッグ＆ドロップについて理解しておく必要があります。まだ読んでいない読者は、その 4.3.4 項の「ドラッグ転送」を読んでください。『OSF/Motif スタイル・ガイド リリース 1.2』と、この章に食い違いがある場合は、この章の方を優先します。

ドラッグ＆ドロップ・ユーザ・モデル

コンピューティング環境の中のオブジェクトを直接操作することは、コンピュータをコントロールしていると感じることができ、新しい操作を試みるのが楽になったり、コンピュータ一般に親しみが持てるようになるという効果があります。また、多くの操作を行う上で、これはより効率の高い操作方法でもあります。

ドラッグ＆ドロップ・ユーザ・モデルを理解するためには、次の用語を理解しておく必要があります。

ドロップ領域

ドロップされたアイコンを受け入れる、ワークスペースの中の領域。ドロップ領域は、ごみ箱コントロールや印刷マネージャ・コントロールなど、通常はコントロールまたはアイコン・グラフィックによって表現されます。

ドラッグ・アイコン

ドラッグ中に使用される複合カーソル。詳細は、「ドラッグ・アイコンの各部分」を参照してください。

共通デスクトップ環境でユーザは、ファイル・マネージャのアイコン、メール・プログラムのメール・メッセージとアタッチメント、カレンダのアポイント、テキスト・エディタやテキスト・フィールド内のテキストを選択し、ドラッグできます。これらの項目は、それを受け入れる任意のドロップ領域にドロップできます。たとえば、ファイル・マネージャのドキュメント・アイコンは、ファイル・マネージャの中のフォルダ・アイコン上や、フロントパネルの印刷マネージャ・アイコン上や、メール・プログラムのアタッチメント・リスト上にドロップできます。

項目がドロップされると、ドロップされた項目に対する何らかのアクションが実行されます。たとえば、ドキュメントが印刷、移動あるいは接続されます。実行されるアクションは、ドラッグされたオブジェクトと、ドロップ先の場所によって変わります。

推奨 

dq: 

アイコンで表現されるすべてのオブジェクトには、ドラッグ＆ドロップ (DND) 方式を用意しなければならない。ユーザが直接に操作できるすべての要素について、DND 方式を用意する。 

推奨 

dr: 

アプリケーションがドラッグ＆ドロップを通してサポートする基本機能は、すべてメニュー、ボタン、またはダイアログ・ボックスによってもサポートされる。 

ドラッグ＆ドロップは、アプリケーションの中でサポートされている他のユーザ・インタフェース・コントロールを通してアクセス可能な機能に対するアクセラレータと見なされます。ドラッグ＆ドロップだけでしかサポートされていない基本操作が存在してはなりません。 

ドラッグ＆ドロップ・フィードバック

ユーザに対する視覚的なフィードバックは、ドラッグ＆ドロップを機能させるための重要な要素の 1 つです。明快な視覚的フィードバックがないと、ドラッグ＆ドロップ操作の結果を予測することが困難になります。また、視覚的なフィードバックはタイミングよく提供されなければなりません。

ユーザは、ドラッグ＆ドロップ操作の際に、次の点を視覚的に識別できければなりません。

ドラッグされる項目のタイプ

ドラッグ＆ドロップのビジュアル・フィードバックは、ユーザに見えるものをドラッグするという概念に基づいています。たとえば、ユーザがファイル・マネージャ内でフォルダ・アイコンを選択しドラッグを開始した場合は、図 3-1 に示すようにドラッグ・アイコンの一部としてフォルダ・アイコンが表示されなければなりません。

図 3-1 ドラッグ中のオブジェクトを示すドラッグ・アイコン

Graphic

必須 

dt: 

ドラッグ操作中に、アプリケーションは現在のポインタをドラッグ・アイコンに変更する。 

推奨 

du: 

ドラッグ操作中に、アプリケーションは現在のドラッグ・カーソルを、ソース・インジケータを取り込んだ形に変更する。 

これはだれにでもわかる動作に思えるかもしれませんが、何をドラッグしているのかがユーザにわかるようなフィードバックを提供することは、きわめて重要です。この種の一貫性を保つことで、ユーザにとってドラッグ＆ドロップがより予期しやすいものになります。テキスト・ドラッグは、実際のテキストがドラッグされるわけではないという点で、この例外となります。図 3-2 にテキスト・ドラッグ・アイコンを示します。

図 3-2 テキスト・ドラッグ・アイコンの例

Graphic

アプリケーションは、ドラッグ・アイコンで使用されるグラフィックを用意する必要があります。このグラフィックは、通常は、ファイル・マネージャでドキュメントを表現するために使用される 32*32 アイコンのように、アプリケーションに付属するアイコンの 1 つです。使用されるグラフィックは、何がドラッグされているのかに依存します。

ユーザがドラッグを開始する前にアイコンを選択しなかった場合でも、特にドロップ時に出力先のアプリケーションが使用するグラフィックなど、関連性のあるグラフィックをドラッグ・アイコンに表示することをお勧めします。たとえば、カレンダの [アポイントエディタ] の中で、ユーザはスクロール・リストからアポイントを選択しますが、このスクロール・リストはアイコンを表示しません。この場合には、ドラッグ・アイコンの一部としてアポイント・アイコンが使用されます。アポイントがファイル・マネージャにドロップされると、ファイル・マネージャは同じグラフィックを使ってアポイントを表示します。

ドロップ領域

ユーザは、ドラッグ項目がいつ有効なドロップ領域の上にあるのかを知る必要があります。このフィードバックは、ドラッグ・アイコンとドロップ領域の 2 つが関連します。ドラッグ・アイコンは、ユーザがドラッグ・アイコンを有効なドロップ領域以外の場所に移動すると、矢印から無効ポインタに変わります。この動作はドラッグオーバ・フィードバックと呼ばれます。デスクトップ上では、無効なドロップ領域と、そもそもドロップ領域でない場所の間には区別がありません。図 3-3 にサンプルの無効ポインタ・ドラッグ・アイコンを示します。

図 3-3 無効ポインタ・ドラッグ・アイコンの例

Graphic

ドロップ領域フィードバック・オプション (ドラッグアンダ・フィードバックと呼ばれる) は、有効なドロップ領域を示すものです。このオプションには、サイトの周囲に実線を描く、ドロップ領域の周囲に射影の付いた縁を付けて、表面が出っ張ったり、へこんでいるように見せる、ドロップ領域の上にピックスマップを描画するという方法あります。射影の付いた縁には、ドロップ領域がへこんでいるように見せる効果があります。図 3-4 に、へこんでいる領域の例を示します。デスクトップ上では、ドラッグ・アイコンがドロップ領域の上にあり、それが有効なドロップ領域であることを示すのに、大部分のドロップ領域で、へこんでいる外観を使用します。

図 3-4 フロントパネルのドロップ領域フィードバックの例

Graphic

推奨 

dw: 

ドラッグ操作中に、アプリケーションは有効なドロップ領域であることを示すために、ドロップ領域フィードバックを変更する。 

推奨 

dv: 

ドラッグ操作中に、アプリケーションは無効なドロップ領域であることを示すために、現在のドラッグ・カーソルを変更する。アプリケーションは、共通デスクトップ環境の標準の無効ポインタを使用する。 

オプション 

dz: 

アプリケーションが使用するカーソル変更やドラッグオーバ効果は、マウス・ポインタがターゲット領域に達してから 0.2 秒以内に発生し、ドラッグ操作の対話形態には、表面上はまったく影響を与えない。 

結果として起こるアクション

共通デスクトップ環境では、ドラッグ・アイコンに関連付けられる操作が 3 つあります。これらの操作は、「ドラッグ・アイコンの各部分」で説明しています。ドラッグ・アイコンには、操作がコピーまたはリンクであるときに、それをユーザに通知するために使用される、デスクトップの一部として提供されている代替グラフィックがあります。デフォルトの操作である移動では、代替アイコン・グラフィックを使用する必要はありません。

成功または失敗

ユーザは、ドラッグ＆ドロップ操作が成功したのか、失敗したのかを知る必要があります。ドロップの成功または失敗を表示するには、遷移効果を使用します。

遷移効果にはメルト とスナップ・バックの 2 つの種類があります。メルト 効果は、ユーザがドラッグ・アイコンを有効なドロップ領域にドロップしたときに使用されます。この効果では、ドラッグ・アイコンがドロップ領域に溶けこむように見えます。ドラッグ・アイコンは消え、出力先のアプリケーションに応じた何らかの表示に置き換えられます。ドラッグ・アイコンをフロントパネル上の [印刷マネージャ] コントロールにドロップすると、メルト効果だけが表示されます。ドラッグ・アイコンを [ファイルマネージャ] コントロールにドロップすると、メルト効果が表示された後に、ファイル・マネージャにアイコンが表示されます。

スナップ・バック効果は、ドロップが失敗したときに使用されます。ドロップが失敗するのは、ドロップ領域が無効である場合と、データ転送が失敗した場合の 2 つです。ユーザがドラッグ・アイコンを、無効ポインタ・ドラッグ・アイコンを表示している無効なドロップ領域の上にドロップすると、ドラッグ・アイコンはソース・アプリケーションにスナップ・バックします。

ドロップが行われると、ソースと出力先のアプリケーションは、データを転送しなくてはなりません。データ転送が失敗した場合に、出力先アプリケーションは 2 つの処理を行わなくてはなりません。まず、ドロップ項目がソース・アプリケーションにスナップ・バックされるように、ドロップが失敗したことを API に通知する必要があります。次に、ドロップが失敗した理由と、ユーザがこの状況を修正するにはどうすればいいのかをはっきりと知らせるエラー通知をユーザに表示しなければなりません。

遷移効果は、即座には行われないことがあります。アイコンは、転送が終了するまで、ドロップされた場所に表示されます。この間に、アプリケーションはカーソルをビジー状態にしておかなければなりません。転送が完了するまで、ユーザはそのアイコンを移動したり、選択することはできません。ビジー・カーソルは、ユーザに、転送の実行中であることを知らせます。

推奨 

ea: 

ドラッグによって実行できるコピー、移動、またはリンク操作をサポートするコレクションでは、ドラッグ操作中にユーザに表示するフィードバックが、単一のオブジェクトが操作されているのか、複数のオブジェクトが操作されているのかを表示する。 

必須 

eb: 

転送に成功すると、データはドロップ領域に格納され、アプリケーションが使用した転送アイコンはすべて削除される。 

必須 

ec: 

アプリケーションがドラッグ＆ドロップの完了時にデータを削除する場合には、ドラッグ＆ドロップ転送が成功して完了した場合にのみ削除を行う。 

必須 

ed: 

転送が失敗した後、データはドラッグのソースに残り、ドロップ領域には格納されない。アプリケーションが使用した転送アイコンは、すべて削除される。 

推奨 

ee: 

ユーザがアプリケーションのウィンドウ内の不適当なドロップ領域にオブジェクトをドロップした場合、アプリケーションはスナップ・バック効果の表示処理に参加し、ドロップが実行できなかった理由を示すエラー・ダイアログ・ボックスを表示する。 

必須 

6-17: 

アプリケーションに、ドラッグ＆ドロップのヘルプ・ダイアログ・ボックスを用意する場合は、実行中のドラッグ＆ドロップ操作を取り消すための [取消し] ボタンを格納する。 

ドラッグ・アイコンの各部分

ドラッグ・アイコンは、図 3-5 に示すように、3 つの部分で構成されています。ドラッグ・アイコンは、左から順に、状態インジケータと、操作インジケータと、ソース・インジケータ (この例ではフォルダ・アイコンを表示) で構成されます。右のアイコンは、これらを合成したドラッグ・アイコンです。

図 3-5 ドラッグ・アイコンの 3 つの部分の例

Graphic

状態インジケータ

状態インジケータは、実際には、有効あるいは無効なドロップ領域インジケータと組み合わされた、配置のためのポインタです。有効状態インジケータは、ユーザがカーソルを予期通りの方法で配置できるように、ホット・スポットを持った矢印ポインタのようなものでなければなりません。無効状態インジケータ、つまり無効ポインタ (図 3-3 を参照) は、ユーザが無効なドロップ領域の上にいるときに表示されます。

操作インジケータ

ドラッグ・アイコンの 2 つ目の部分は、操作インジケータです。ドラッグ操作には、移動、コピー、およびリンクがあります。

移動

ドラッグされる項目が出力先に移動されます。

コピー

項目が出力先にコピーされます。

リンク

出力先とソースの間に接続が保持されます。この操作は、ある程度までアプリケーションによって定義され、一般的に使用されるものではありません。

移動、コピー、およびリンクがユーザ・アクションにどのようにマッピングされるかについては、「アクション」を参照してください。

操作インジケータは、ドラッグ中に、実行される操作に関するユーザ・フィードバックを与えます。図 3-6 にコピーおよびリンクのフィードバックを示します。ほとんどのドラッグは移動操作なので、操作インジケータがドラッグ・アイコンに追加されるのは、コピーまたはリンク操作の場合だけです。

図 3-6 コピー (左) およびリンク操作インジケータの例

Graphic

注 -

操作フィードバックは状態およびソース・フィードバックの上に描画されます。これは Motif の基本的な動作です。

ユーザは、ドラッグ中に特定のキーを押すことで、ドラッグを強制的に移動、コピー、またはリンクできます ([Shift] キー = 移動、[Control] キー = コピー、[Shift] + [Control] キー = リンク)。

ソース・アプリケーションも強制的にコピーさせることができます。ユーザが操作を強制するとき、ドロップが成功するためには、ドロップ領域がその操作に対応していなければなりません。そうでない場合、ドロップ領域は操作が無効であることを表示しなければなりません。

必須 

4-36: 

ユーザが要求した移動、コピーまたはリンク操作が使用不可能な場合、転送操作は失敗する。 

必須 

4-55: 

選択をサポートするコレクションで、[Shift] + BTransfer Release または [Shift] + BSelect Release は、強制的にドラッグ移動操作を実行する。移動が不可能な場合、操作は失敗する。 

必須 

4-56: 

選択をサポートするコレクションで、[Control] + BTransfer Release または [Shift] + BSelect Release は、強制的にドラッグ・コピー操作を実行する。コピーが不可能な場合、操作は失敗する。 

必須 

4-57: 

選択をサポートするコレクションで、[Control] + [Shift] + BTransfer Release または [Shift] + BSelect Release は、強制的にドラッグ・リンク操作を実行する。リンクが不可能な場合、操作は失敗する。 

推奨 

s: 

選択をサポートするコレクションで、BTransfer Motion (または BSelect Motion) の結果としてドラッグ操作が開始される場合は、コピー、移動、またはリンク操作が実行中であることを示すフィードバックが、ユーザに表示される。操作がコピー、移動、またはリンクのいずれになるのかは、ドロップ領域に作成されるオブジェクトの型と、ソース・オブジェクトが削除されるかどうかに依存する。 

推奨 

t: 

選択をサポートするコレクションで、[Control] + BTransfer Motion または [Control] + BSelect Motion の結果としてドラッグ操作が開始される場合は、コピー操作が実行中であることを示すフィードバックが、ユーザに表示される。 

推奨 

u: 

選択をサポートするコレクションで、[Control] + [Shift] + BTransfer Motion または [Control] + [Shift] + BSelect Motion の結果としてドラッグ操作が開始される場合は、リンク操作が実行中であることを示すフィードバックが、ユーザに表示される。 

ソース・インジケータ

ソース・インジケータは選択 (またはドラッグされているもの) を表すものです。これには、選択が表す項目が単一か複数かと、選択が表すものの種類に応じて、いくつかのバージョンがあります。表 3-1 にドラッグ・アイコンの例を示します。

注 -

ドラッグ・アイコンはカーソルとして動的に合成されるため、画面図を示すことはできません。このため、表 3-1 には画面上に見えるものの概略図を示します。

ホット・スポットは、テキスト・ドラッグ・アイコンの場合は左上隅 (1,1) にあります。単一および複数ドラッグ・アイコンのホット・スポットは、無効アイコンの左上ピクセルにあります (3,3)。個々のドラッグ・アイコンは、ユーザに対象を明示し、配置の精度を向上させるために調整されています。

表 3-1 一般ソース・インジケータ付き表示のありうるドラッグ・アイコン

操作 

テキスト選択 

単一選択 

複数選択 

有効な移動 

Graphic

Graphic

Graphic

有効なコピー 

Graphic

Graphic

Graphic

有効なリンク 

Graphic

Graphic

Graphic

無効な移動 

なし 

Graphic

Graphic

Graphic

無効なコピー 

Graphic

Graphic

Graphic

無効なリンク 

Graphic

Graphic

Graphic

ドラッグ＆ドロップの構造

基本のアプリケーション・アーキテクチャには、ドラッグ＆ドロップを設計する上で理解しておくべきことがいくつかあります。

型

共通デスクトップ環境では、ドラッグ可能なオブジェクトには、ファイル、バッファ、テキスト選択の 3 つの型があります。

個々のアプリケーションは、ドラッグ＆ドロップが可能なオブジェクトを独自に持っています。たとえば、カレンダはアポイントを、メール・プログラムはメール・メッセージを、ファイル・マネージャはフォルダやファイルを使用します。ファイル・マネージャのフォルダおよびファイル・アイコンは、基本ファイル・システムの中では独立して存在するため、ドラッグ＆ドロップの際にはファイルとして扱われます。しかし、カレンダのアポイントやメール・プログラムのメッセージは、ファイル・システムの中で独立した存在ではありません。これらのオブジェクトがドラッグされるときには、バッファとして扱われます。

この違いは、ユーザにとっては混乱の元になります。ユーザには、この両方の型のオブジェクトは同じものに見えます。どちらもアイコンで表示でき、どちらも他の似たようなオブジェクトから独立して操作できます。しかし、実装の都合上、ユーザは操作するオブジェクトの型によって、異なる結果を得ることになります。

テキストの一部の選択は、ユーザにとってアイコンの選択とはまったく異なる操作なので、テキスト選択は別のカテゴリに分類されます。ユーザはドキュメント・ウィンドウの中でテキストの範囲を選択します。テキストはドキュメント全体を表すのではなく、ドキュメントの一部を表すだけです。実際には、ユーザはテキストの一部を独立したオブジェクトと考えることはほとんどなく、テキストの一部をドロップしたときに、それがアイコンのように動作することを期待しません。このため、テキストのドラッグ＆ドロップ・モデルは、[編集] メニューから使用するカット、コピー、およびペースト操作を反映しています。

アクション

オブジェクトがドロップされたときに起こるアクションには、挿入と読み込みの 2 つがあります。

挿入アクションは、ドロップされたオブジェクトを出力先に挿入し、アプリケーションまたはドキュメントの現在のデータに追加します。オブジェクトは、ユーザがアポイントのスケジュールを設定したり、ドキュメントを印刷したり、ドキュメントを接続したり、テキストをペーストしたり、メール・メッセージを追加したときに挿入されます。このようなアクションは、出力先とユーザに応じた、移動またはコピー操作です。選択したテキストの一部を、移動するのではなくコピーしたい場合もあります。ドラッグ・アイコンは、操作がコピーと移動のどちらなのかを表示しなければなりません。

読み込みアクションは、ユーザが [ファイル] メニューから [開く] を選択し、ファイルを選択して [開く] ボタンをクリックしたときと同じ動作をします。ドロップされたオブジェクトはアプリケーションに読み込まれます。ユーザはオブジェクトを編集し、変更内容を元のファイルに保存できます。現時点で、読み込みが機能するのはファイルに対してのみで、バッファやテキストに対しては機能しません。ユーザがオブジェクトを、読み込みアクションをサポートしているドロップ領域上にドラッグする際には、コピー・ドラッグ・アイコンを表示しなければなりません。

バッファに対しても読み込みは機能します。ただし、バッファは読み込み専用で読み込まれます。詳細は、「アタッチメント・ユーザ・モデル」の節を参照してください。

マッチング操作

ドラッグ＆ドロップのアプリケーション内での動作を設計するときは、ドラッグ＆ドロップのソースと出力先がマッチしないときに、どのような操作を行うべきなのかを Motif が決定する方法を理解しなければなりません。

各ドラッグ・ソースについて、アプリケーションはどのドラッグ＆ドロップ操作が可能で、どの出力先にドロップできるのかを公示します。各ドラッグ出力先について、アプリケーションは許容されるソースと操作のタイプを公示します。ソースとその出力先で 2 つ以上の操作が共通している場合、Motif は特定の順序に従って、どの操作を使用するかを決定します。この順序は移動、コピー、リンクです。アプリケーションは、ドラッグされるものの型に応じて、受け入れられた操作を変更できません。

たとえば、アプリケーション A が、要素の移動またはコピーが可能であるということを公示しているとします。アプリケーション B は、出力先がコピーまたはリンクを受け入れることを公示しています。この例での共通操作はコピーです。アプリケーション B 内の出力先が移動またはコピーを受け入れる場合には、操作の順序で移動操作の方が先なので、ソースが移動されます。

この例で、ユーザは修飾キーを押すことによって移動操作を無効にできます。たとえば、[Control] キーを押すと、操作をコピーに変更できます。これができるのは、コピー操作が操作の共通セットに含まれている場合だけです。コピー操作が共通セットに含まれていない場合、ドラッグは無効なドラッグになります。

マッチング操作を考慮しなければならないのは、出力先が移動を受け入れることはできるが、コピーの方が望ましい場合だけです。この場合、出力先はコピーだけを受け入れた方がいいことになります。

コピーは常に受け入れる方がいいでしょう。コピーを受け入れると、受け入れ可能なドロップの範囲が広がります。移動が受け入れられるならば、ほとんどの場合にコピーも機能します。移動はコピーを行なった後に削除を実行するという方法で実装されていることに注意してください。

ドラッグ・ソースの決定

アプリケーション内でドラッグ＆ドロップを使用することを決めたら、どのコントロール要素をドラッグできるのか、その要素をどのように表現するのかを決定しなくてはなりません。一般に、ユーザはテキストまたはファイルのようなものをドラッグのために選択しますが、アプリケーションがメール・メッセージやアポイントなど、ドラッグ＆ドロップが意味を持つような他の要素を持っている場合があります。

この節では、ドラッグ・ソースを決定する上での一般的なガイドラインを示し、ドラッグ可能な具体的な要素について説明します。

注 -

ドラッグのソースには、選択可能なコンポーネントまたは項目を持っている、ヒューマン・インタフェース要素だけが使用できます。ボタン上やメニュー上のラベルなどの静的ラベルをドラッグのソースとすることはできません。

アプリケーションのドラッグ・ソースを決定する前に、アプリケーションの選択機能の中にドラッグを組み込む方法を検討しなければなりません。ユーザが、アクションの結果に迷いを抱くことなく、選択やドラッグができなければなりません。

必須 

4-58: 

ドラッグ移動操作が、セレクションを同じコンポーネントの中で移動するとき、セレクションは選択された要素とともに移動する。 

つまり、選択された要素がドラッグ操作で移動される場合、それらの要素は移動の後も選択されていなければなりません。 

必須 

4-59: 

テキスト単位のコレクションで、選択領域内でドラッグを開始すると、テキスト・セレクション全体がドラッグされる。 

必須 

4-60: 

リスト単位およびグラフィック単位のコレクションで、選択された要素上でドラッグを開始すると、セレクション全体がドラッグされる。 

必須 

4-61: 

リスト単位およびグラフィック単位のコレクションで、未選択の要素上で BTransfer または BSelect でドラッグを開始すると、その要素だけがドラッグされ、セレクションには影響しない。 

必須 

4-62: 

未選択の領域でドラッグが開始され、ポインタが 2 つのドラッグ可能な要素にまたがっている場合、ドラッグは重なりの一番上にあるドラッグ可能な要素を使用する。 

必須 

4-67: 

BTransfer (または BSelect) が離されると、ドロップ操作は通常ドラッグ・アイコン・ポインタのホット・スポットの位置で起こり、重なりの一番手前にあるドロップ領域にドロップされる。しかし、ドロップがセレクションの中で発生し、かつ保留されている選択の削除が有効になっている場合、転送データはセレクション全体の内容を置き換える。 

スクロール・リスト

共通デスクトップ環境では、スクロール・リストの中の項目は、デフォルトではテキスト・オブジェクトです。これはバッファ・オブジェクトであることもありますが、テキストとバッファの両方であることはできません。たとえば、カレンダの [アポイントエディタ] には、ユーザが選択してドラッグできる、アポイントのスクロール・リストがあります。ユーザがアポイントをドラッグすると、バッファが操作され、ドラッグ・アイコンには、図 3-7 に示すように、ソース・インジケータとしてアポイント・アイコンが表示されます。メール・プログラムのコンテナ・ウィンドウは、ウィンドウの上部にメール・メッセージのリストを持っています。ユーザは、このリストから 1 個以上のメッセージを選択してドラッグできます。これらのメッセージは実際にはバッファであり、ドラッグ・アイコンはソース・インジケータとしてメール・メッセージを表示します。複数のメール・メッセージがドラッグされる場合、ドラッグ・アイコンには複数ソース・インジケータが表示されます。

図 3-7 ドラッグする項目が選択されているスクロール・リストの例

Graphic

アプリケーションが、メール・メッセージのヘッダや、他の種類のオブジェクトのリストを表示するためにスクロール・リストを使用している場合は、ドラッグを拡張選択と統合する必要があります。この動作はメール・プログラム・アプリケーションで実現されています。

必須 

k: 

範囲選択を使用するコレクションで、未選択の要素の上で BSelect を押すと、その要素上または BSelect が押された位置にアンカーが設定され、コレクションの中のすべての要素の選択が解除される。ドラッグのしきい値に達する前に BSelect が離された場合は、ポインタの下の要素が選択される。BSelect Motion がドラッグのしきい値を超えると、新しい選択が開始される。アンカーとポインタの現在位置が現在の範囲を決定する。コレクションの中で BSelect がドラッグされると、現在の範囲が強調表示される。BSelect が離されると、アンカーは移動せず、現在の範囲の中のすべての要素が選択される。 

必須 

l: 

範囲選択を使用するコレクションで、現在の選択要素の上で BSelect を押したときに、選択セットの中の他の要素がすべて選択解除されてはならない。ドラッグのしきい値に達する前に BSelect が離された場合は、その時点で他のすべての要素の選択が解除され、ポインタの下の要素が選択されて残る。BSelect Motion がドラッグのしきい値を超えると、要素は 1 つも選択解除されず、ドラッグ操作が開始される。 

ダイアログ・ボックス

アプリケーションはダイアログ・ボックスの中からのドラッグをサポートしなければならないことがあります。たとえば、カレンダの [アポイントエディタ] では、左側にユーザがアポイントに関する情報を入力する一連のテキスト・フィールドがあります。この領域からのドラッグをサポートすれば、ユーザはアポイントの記述からテキストをドラッグできます。

図 3-8 カレンダの [アポイントエディタ] ダイアログ・ボックスの例

Graphic

何かがドラッグ可能であることを示すための方法としては、ダイアログ・ボックスの中にアイコン・グラフィックを入れておくという方法を推奨します。アイコン・グラフィックはドラッグ可能でなければなりません。このアイコン・グラフィックは、ファイル・マネージャの中でデータを表現するために使用されるのと同じアイコンでなければなりません。カレンダ内で、アポイント・アイコンはファイル・マネージャの中と同じ表示になっており (図 3-8 を参照)、その下にラベルが付けられています。これはドラッグ・アイコン・ソース・インジケータで使用するのと同じアイコンです。

アイコン・グラフィックは、ダイアログ・ボックスの中で、ドラッグされる情報のすぐ近くに配置します。ダイアログ・ボックスまたはウィンドウの右上隅がデフォルトの位置ですが、アプリケーションに応じて変更することもできます。カレンダの [アポイントエディタ] では、アイコンは、テキスト・フィールドがドラッグできることを示すために、メイン・テキスト・フィールドの近くに置かれています。

推奨 

ds: 

ダイアログ・ボックスまたはウィンドウ内のオブジェクトがドラッグできることを示すために、ダイアログ・ボックスまたはウィンドウ内でアイコン・グラフィックを使用する。そのドラッグ可能なオブジェクトをファイル・マネージャの中で表現するために使われるのと同じアイコン・グラフィックを使用する。アイコンは、オブジェクトの内容の表示が存在する場合は、その近くに配置する。このような表示が存在しない場合は、特に良い場所がなければ、ダイアログ・ボックスまたはウィンドウの右上隅に配置する。アイコンはサイズが 32*32 で、その下にラベルが付けられていなければならない。ラベルは、そのアイコン・グラフィックが表すオブジェクトの種類を示していなければならない。また、そのアイコン・グラフィックはドラッグ・アイコンのソース・インジケータとしても使用する。 

ウィンドウ

一部のアプリケーションでは、ドキュメントまたはファイル全体をドラッグできるようにしたいことがあります。たとえば、アイコン・エディタでは、現在エディタの中にあるアイコンのファイルをドラッグできてもいいはずです。アプリケーションは、アプリケーションのウィンドウ内にアイコン・グラフィックを組み込むことにより、ユーザにドキュメントまたはファイルがドラッグできることを知らせなければなりません。アイコン・グラフィックはドラッグ可能でなければなりません。アイコン・エディタの場合、アイコン・ファイルの内容の表示に使用されるアイコンの 1 つがドラッグに使用されます。アイコンは、ダイアログ・ボックス内で使用されるアイコンのガイドラインに従わなければなりません。つまり、ファイル・マネージャ内でドキュメントを表現するのに使われるのと同じアイコンで、32*32 ピクセルの大きさで、ラベルを持ち、ドラッグされるデータの近くに配置され、ドラッグ・アイコンのソース・インジケータとして使用されなければなりません。

複数選択のドラッグ＆ドロップ

ユーザがドラッグの対象として複数の項目を選択したとき、ドラッグ・アイコンは複数の項目が選択されていることを示すためにインジケータの変更をしなければなりません。

一部のドロップ領域は単一の項目しか受け付けないかもしれません。ドロップ領域は、ドロップされる項目が単数なのか、複数なのかを区別できません。ドロップ・アイコンは無効ポインタを表示しません。その代わりに、項目はメルトし、出力先アプリケーションによってスナップ・バックされなければなりません。スナップ・バックの後には、ユーザにドロップが失敗した理由を通知するエラー通知が表示されなければなりません。

推奨 

ef: 

単一の項目しか受け付けないアプリケーションは、すべての複数項目ドロップを拒否しなければならない。 

選択項目のうち、ユーザが本当にドロップしようとしたのはどれかを決定する一貫性のある方法はありません。 

標準でサポートされるドロップ領域

共通デスクトップ環境で標準でサポートされるドロップ領域は、フロントパネルのコントロール、開いたウィンドウ、およびファイル・マネージャ内のフォルダ、アクション、および一部の他のアイコンです。ドロップをサポートしていないアイコン化されたアイコンやファイル・マネージャ・アイコンへのドロップは、共通デスクトップ環境ではサポートされていません。

フロントパネル

フロントパネルは、ユーザにとってアクセスが簡単に、素早く行えるようにするためにまとめられた、コントロールやその他の機能を集めたものです。このため、そのドラッグ＆ドロップ動作は出力先のコンテキストに強く依存します。たとえば、出力先がプリンタの場合は印刷を行います。出力先がサブパネルの場合はインストールを行います。大部分のアプリケーションは、フロントパネルほど広い範囲の動作を持っていません。

ファイル・マネージャ

ユーザは、共通デスクトップ環境のファイル・マネージャを使用して、デスクトップにアイコンをドロップできます。デスクトップ上のアイコンはリファレンスになります。リファレンスの作成と、その結果の動作には、共通デスクトップ環境の将来のユーザ・モデルとの一貫性はありません。ユーザ・モデルとアーキテクチャの仕様がさらに定められるまで、開発者がデスクトップにドロップを行なったり、ファイル・マネージャの動作をコピーしたりすることは勧められません。

ファイル・マネージャのウィンドウ内では、共通デスクトップ環境 1.0 のフォルダとアクション・アイコン以外のアイコンへドロップできます。たとえば、メールのメッセージ・アイコンをメールのコンテナ・アイコンにドロップすると、メールのメッセージを追加します。

メールのメッセージやカレンダのアポイントや他のバッファがソースとなるアプリケーションからドラッグされ、ファイル・マネージャにドロップされるときには、名前を付ける必要があります。基本の API は、ドラッグされる項目の名前フィールドをサポートしています。この名前はバッファの名前として使用されます。この名前は、元のアプリケーションと一貫性がある方法で決定されなければなりません。ファイル・マネージャにテキスト選択をドロップする場合のように適切な名前がない場合は、ファイル・マネージャは結果として作られるファイルを「unnamed」という名前にします。名前の重複が起こる場合、ファイル・マネージャはダイアログ・ボックスを表示して、ドロップされるファイル名を変更するかどうかをユーザに問い合わせます。

ドロップ専用ターゲットは存在しない

共通デスクトップ環境では、ドロップ用にしか使用されない特定のコントロールあるいはグラフィカル・ターゲットという概念はサポートされていません。ヒューマン・インタフェースの中の、選択可能な項目を持つ任意のコントロールは、その上にドロップできなければならず、またドロップ領域フィードバックを提供しなければなりません。これには、データ区画、スクロール・リスト、およびテキスト入力フィールドが含まれます。ドロップの際に起こる操作には、そのアプリケーション・タイプに関してユーザが抱く期待との一貫性がなければなりません。

マウス・ボタンの使用

共通デスクトップ環境では、ユーザは各種の作業スタイルに応じて、マウス・マッピングを変更できます。BSelect は、Motif で以前から転送操作のために使用されてきた BTransfer に加えて、ドラッグ＆ドロップをサポートするように変更されています。

ユーザは、システムをセットアップして、BSelect と BTransfer を使用してドラッグ＆ドロップを実行するようにしたり、BSelect だけを使用したりするようにできます。アプリケーションを設計するときは、この点を考慮します。ユーザがマウス・ボタン・マッピングをどのように設定しているのかを確認し、そのマッピングを使用します。

必須 

p: 

アプリケーションは、マウス・ボタン 1 によるドラッグ＆ドロップ操作をサポートする。 

Motif 1.2 では、ドラッグ＆ドロップは一般に 3 ボタン・マウスのボタン 2 (BTransfer) を使用して実行されます。しかし、共通デスクトップ環境では、他のグラフィカル・ユーザ・インタフェース (GUI) 環境との互換性があるマウス操作をサポートするために、マウス・ボタン 1 (BSelect) によるドラッグ＆ドロップがサポートされなければなりません。つまり、共通デスクトップ環境では、BTransfer は BSelect と統合されています。ドラッグはマウス・ボタン 1 とマウス・ボタン 2 のどちらでも開始できます。 

必須 

q: 

3 ボタン・マウスのボタン 2 が BAdjust として動作するように構成されている場合、アプリケーションはマウス・ボタン 2 がクリックされたときに BTransfer (または BSelect) 操作を実行しない。 

3 ボタン・マウスでは、ボタン 2 は一般に BTransfer 機能に使用されます。しかし、共通デスクトップ環境では、ユーザは環境設定を変更して、マウス・ボタン 2 を BAdjust 機能に使用するように指示できます。BAdjust は、[Shift] + BSelect と同じように、選択セットを拡張するために使用できます。 

必須 

r: 

選択した項目上をドラッグした場合、BSelect でドラッグが開始されるべきである。ドラッグがしきい値に達するとドラッグが開始される。これは、テキスト領域、スクロールリスト、および他の同様の項目で起こる。 

ドロップの際の配置

ユーザから見ると、ドロップ項目の配置は、ユーザの作業と、その作業を行うアプリケーションまたはコンテキストに依存します。

ファイル・マネージャでは、デフォルトが [自由] に設定されている場合、アイコンはドロップされた場所に配置されます。デフォルトが [整列] に設定されている場合、ドロップされたアイコンは自動的にソートされてから配置されます。つまり、アイコンはユーザがドロップされた場所には配置されないことがあります。

ドロップされる項目がどこに配置されるかが問題にならない場合もあります。たとえば、フロントパネル・コントロールでは、ドラッグされた項目がコントロールの上にありさえすれば、ドロップ領域が起動されます。

メール・プログラムのメール作成ウィンドウでは、配置はドロップされるものに依存します。ユーザがテキストの一部をドラッグしている場合、テキストはドロップ・ポイントに挿入されます。ユーザ・テストの結果、これがユーザの期待する動作であることがわかっています。ユーザがファイルまたはバッファのアイコンをドロップすると、その内容が挿入ポイントに取り込まれます。これは、ユーザが [取り込みファイル選択ボックス] でファイルを選択したときの動作を反映しています。

ユーザの作業の種類に基づいて、アプリケーションに適した動作を決定する必要があります。

必須 

4-37: 

コレクションが固定挿入ポイントを持っていなかったり、要素を特定の順序で並べている場合、転送データの挿入ポイントは次のように決定される。 

  • BTransfer ベース (または BSelect) の一次操作とドラッグ転送操作の場合は、後述のテキスト・コレクションの場合を除いて、挿入位置は、ユーザが BTransfer (または BSelect) を離した位置である。

  • テキスト単位のコレクションの場合、ユーザが選択テキストをドロップすると、挿入位置はユーザが BTransfer (または BSelect) を離した位置になる。ユーザがアイコンをドロップすると、挿入位置はテキスト・カーソルの位置になり、データはその前にペーストされる。

  • リスト単位のコレクションの場合、他の転送操作の挿入位置は位置カーソルを持つ要素で、データはその前にペーストされる。

    挿入位置は、転送データが配置される出力先中の位置です。一部のマウス・ベースの転送操作は、可能ならばデータをポインタ位置に配置します。キーボード・ベースの転送を含む他の操作は、一般にデータを位置カーソルの位置に配置します。

ドラッグの終了

次の 2 つの項目により、ユーザはデータを失ったり、その他の不利な結果を招かずに、ドラッグ操作を中止できます。

必須 

dx: 

[取消し] を押すと、実行中のドラッグを取り消して、ドラッグ＆ドロップ操作を終了する。 

必須 

dy: 

ドロップ・ターゲット上以外の位置で BTransfer (または BSelect) を離すと、ドラッグ＆ドロップ操作を終了する。 

パフォーマンスのガイドライン

ドラッグ＆ドロップ操作中に、タイミングとユーザに対する応答が重要な瞬間がいくつかあります。最適なパフォーマンスを保証する責任は、ソースおよび出力先のアプリケーションと、Motif ドラッグ＆ドロップ API およびドラッグ＆ドロップ簡易 API にあります。

ドラッグ＆ドロップ操作におけるユーザの個々の手順とそれに対するシステム応答を、時間を追って次に示します。各手順の後に、対話のタイミングに関するガイドラインがあります。

  1. ユーザが選択します。ポインタは選択したオブジェクト上にあります。ユーザはマウス・ボタンを押し続けます。

  2. ユーザがポインタの移動を開始します。ユーザはドラッグを開始する前に、ポインタを 10 ピクセル移動できなければなりません。ユーザが BTransfer を押している場合は、ドラッグのしきい値はありません。

    -> ドラッグを開始すると、ポインタはドラッグ・アイコンに変化します。

    移動の遅延: 手の移動を認識してからドラッグ・アイコンの表示を開始するまでの遅延は 50 ミリ秒未満でなければなりません。手の移動からポインタがドラッグ・アイコンに変化し終えるまでの時間は、最大で 70 ミリ秒に制限されています。

  3. ユーザが、ドラッグ・アイコン上のホット・スポットに境界線を越えさせて、ドロップ領域の上にドラッグします。

    -> 有効なドロップ領域上にない場合は、ドラッグ・アイコンは無効ポインタに変化します。有効なドロップ領域の場合は、ドロップ領域が強調表示されます。

    移動の遅延: 手の移動を認識してからドラッグ・アイコンの表示を開始するまでの遅延は 50 ミリ秒未満でなければなりません。手の移動からポインタがドラッグ・アイコンに変化するまでの時間は、最大で 70 ミリ秒に制限されています。

  4. ユーザがドロップ領域にドラッグ・アイコンをドロップします。

    -> ドロップ領域が有効でない場合は、ドラッグ・アイコンはスナップ・バック遷移効果を使用してソースにスナップ・バックされます。

    -> ドロップ領域が有効な場合は、ドラッグ・アイコンはメルト・イン遷移効果を使用して出力先にメルトします。

    エコーの遅延: マウス・ボタンを離したことを認識してからフィードバック・エコーの表示を開始するまでの遅延は 50 ミリ秒未満でなければなりません。マウス・ボタンを離してからフィードバック・エコーを表示し終えるまでの時間は、最大で 120 ミリ秒に制限されています。

    スナッピー遷移: 遷移アニメーション自体は 200 〜 350 ミリ秒間実行されなければなりません。マウス・ボタンを離してから、遷移アニメーションが終了するまでの時間は、最大で 500 ミリ秒に制限されています。アニメーションはハードウェアの条件とは無関係に、同じ速度で実行されなければなりません。

  5. 出力先アプリケーションがデータ転送を開始します。

    -> ユーザに、データ転送が開始されたことを通知するメッセージが表示されます。

    -> 実行の経過状況を示すメッセージがさらに表示されます。

    -> データ転送の完了がユーザに通知されます。

    -> データ転送に失敗した場合、ユーザに失敗の理由を知らせるフィードバックを与えるかどうかは、出力先アプリケーションに依存します。

    コマンドの遅延: コマンドの起動、つまりドロップの発生を認識してから、コマンドを起動するまでの遅延は、0.3 〜 1 秒の範囲でなければなりません。ドロップの発生からコマンドの起動を完了するまでの時間は、最大で 2 秒です。

    ビジー・フィードバック: コマンドの実行に 2 秒以上かかる場合、カーソルがビジー・オブジェクト上にあるときは、必ずビジー・カーソルを表示します。可能ならば、部分的な結果を表示します。経過表示やビジー・カーソルの表示時間は 0.5 秒未満です。

    経過表示: データ転送が実行中であることを示す遷移アニメーションの完了時には、ステータス・メッセージまたは [経過] *メッセージボックス* が表示されなければなりません。例: Data transfer is 10% complete. このメッセージは転送が 100% 完了するまで、2 〜 3 秒おきに更新できます。

    通知: データ転送に失敗した場合、ドロップが失敗した理由と、ユーザが取りうる措置 (存在する場合) を示すメッセージが、ステータス領域か [経過] *メッセージボックス* に表示されなければなりません。

アプリケーションの中でのアタッチメントの使用

この節では、共通デスクトップ環境 1.0 のドキュメントにドキュメントを接続する方法に関するユーザ・モデルとガイドラインを説明します。この機能はメール・プログラムで実現されています。アプリケーションのインタフェースにアタッチメント・リストを取り込む場合は、この節を読んでください。

注 -

このガイドラインのセットは、埋め込みドキュメント・アーキテクチャの説明ではありません。

共通デスクトップ環境では、アタッチメントとアタッチメント・リストは次のように定義されています。

アタッチメント

A と B という名前の 2 つのドキュメントがあるとします。ドキュメント A が別のドキュメント B に接続されると、A は B によって「運ばれる」独立したドキュメントとして存在し続けます。A は B の内部でアイコンとして表示されます。A は独立に開いたり表示したりでき、後に B から分離して一度も接続されなかったかのようにできます。

アタッチメント・リスト

アタッチメントが表示される領域です。スクロール可能でなくてはならず、アイコン・ラベルを表示するための空間が必要です。

注 -

ユーザは、複数のドキュメントが接続されたドキュメントをコンテナとは見ません。コンテナは、アタッチメントのヒューマン・インタフェースに現われるべきではない実装上の概念です。このため、ユーザにアタッチメントを説明する際には、コンテナという用語は使うべきではありません (これ以外の状況では使用できることもあります)。

アタッチメント・ユーザ・モデル

アタッチメントは、接続先にアイコンで表示されます。これらのアイコンは、ファイル・マネージャや、共通デスクトップ環境の他の場所で使用されているのと同じアイコンです。基本的な動作規則は、アタッチメントと同じアイコンがファイル・マネージャで使用されているならば、あらゆる状況で、この 2 つが同じ動作をするように努力しなければならないというものです。

接続されたドキュメントの機能には、次の 3 つのレベルがあります。

  1. ドキュメントを接続および分離できる。

  2. 接続されたドキュメントを独立したウィンドウで開き、表示し、終了できる。

  3. アタッチメントを独立したウィンドウで編集し、変更内容を接続されたドキュメントに戻して保存できる。

目標は、可能な限りレベル 3 の機能を実現することです。アタッチメントがこのレベルを実現できない場合は、上記のように機能のレベルを下げていきます。この節ではレベル 3 の機能を前提として説明します。

ドキュメントがアタッチメントに関して提供している機能が、ファイル・マネージャのアイコンとして提供されている機能と大きく異なる場合は、ユーザが機能の違いをはっきりと認識できるように、アタッチメントには別のアイコンを用意してください。

アタッチメントの機能

アタッチメントをアプリケーションに組み込む際には、いくつかの点に注意する必要があります。

何がアタッチメントできるのか

各アプリケーションについて、接続できる項目を決定しなければなりません。たとえば、メール・プログラムはドキュメント、スクリプト、およびアプリケーションなどを接続できますが、フォルダは接続できません。

アタッチメントの方法は

アタッチメントの方法には、[アタッチメント] メニューの [ファイルの追加] を選択したときに表示されるファイル選択ダイアログ・ボックスを通して行う方法と、ファイル・マネージャまたは他のアプリケーションからのドラッグ＆ドロップによる方法の 2 つがあります。

推奨 

eh: 

ドラッグ＆ドロップがオブジェクトの接続を行う唯一の方法であってはならない。 

推奨 

el: 

ユーザが、接続可能な項目でない何かをファイル選択ダイアログ・ボックスから選択した場合に、ユーザは、選択された項目が接続できないことを説明するエラー・メッセージを受け取る。次に例を示す。 

The folder "My.Stuff" cannot be attached because it is a folder. Only documents, applications, and scripts can be attached.

「My.Stuff」はフォルダなので、アタッチできません。ドキュメント、アプリケーション、およびスクリプトだけがアタッチできます。

推奨 

ej: 

ユーザが、接続可能でない何かをアタッチメント・リストにドロップしようとすると、ドロップは失敗し、その項目はソースにスナップ・バックされる。 

アタッチメントされると何が起こるのか

ドキュメント A をドキュメント B に接続すると、ドキュメント A のビットがドキュメント B の中にコピーされます。元のファイルとのつながりは、これ以外にはありません。ユーザが接続されたドキュメントを開いて変更すると、変更内容は接続されたドキュメントにのみ保存され、ファイル・システムの中のファイルには保存されません。

アタッチメント内部のアタッチメント

ユーザは、アタッチメントを含んでいるメッセージやテキスト・ファイルを接続できます。これは「ネスティング」と呼ばれることがあります。テキスト・ファイルを読んでいるとメール・メッセージがあり、このメール・メッセージを開くと、さらにテキスト・メッセージとアタッチメントがあるというような状況があります。

アタッチメントの編集と保存

ユーザがアタッチメントを開き、編集し、変更内容をアタッチメントに保存できなくてはなりません。アタッチメントがこれを実行する能力を持っていない場合は、アタッチメントが選択されたときに、メニューの [アクション] の部分には [開く] のアクションが表示されてはならず、またダブルクリックを行なってもアタッチメントが開かないようになっていなければなりません。

推奨 

ei: 

ダブルクリックは、アタッチメントを選択して、アタッチメントを [開く] メニュー項目を選択するという操作のショートカットであり、アタッチメントにアクセスするための唯一の方法であってはならない。 

推奨 

ek: 

ユーザが編集するために 1 個以上のアタッチメントを開いており、ユーザの編集結果を失う可能性がある操作を試みた場合は、ユーザに明確な警告を発し、変更内容を保存する機会を与えなければならない。 

アタッチメントの実行

ユーザが実行可能なアタッチメントを開いたり、ダブルクリックを試みた場合、ユーザにこの操作の確認を求めた方がいいことがあります。この場合、アタッチメント名と、アタッチメントに対して実行されるアクション名の両方が変数になります。エラー・メッセージの例を次に示します。

   "Invitation" is an executable attachment. Do you want to Run it?
    Buttons: Run, Cancel, Help
   「Invitation」は実行可能なアタッチメントです。実行しますか?
   ボタン: [実行]、[取消し]、[ヘルプ]

読み取り専用アタッチメント

読み取り専用アタッチメントは、読み取り専用として開くことができます。この状態は、アタッチメント・アプリケーションのメニューを無効にしたり、選択カーソルを無効にしたり、その他のはっきりした方法を使ってユーザに通知したりしなければなりません。少なくとも、アタッチメント・アプリケーションの [保存] メニュー項目は選択不可になっていなければなりません。

ドラッグ読み込みとアタッチメント

ドラッグ読み込みを実行するには 2 つの方法があります。ドラッグ読み込みを直接にサポートするアプリケーションでは、ユーザがファイル・マネージャのアイコンを、そのアプリケーションの開かれたウィンドウにドラッグ＆ドロップすれば、そのアイコンが表すファイルが読み込まれます。同じ結果が、アイコンをアクション・アイコン上にドロップしても実現されます。アクションはエディタを起動し、そのアイコンが表すファイルがエディタに読み込まれます。ファイル・マネージャのアイコンをドラッグ読み込みするのは、[ファイル] メニューで [開く] を選択するのと同じです。開かれたファイルは編集、保存ができます。

アタッチメントの場合、ユーザはドラッグ読み込みをサポートするエディタ上やアクション上に、アタッチメントをドラッグ＆ドロップできますが、編集の結果はアタッチメントには保存されません。アタッチメントはバッファとして実装されており、読み取り専用のデータとして読み込まれます。

ユーザが読み込んだアタッチメントに変更内容を保存しようとすると、エディタはファイル選択ダイアログ・ボックスを表示し、ユーザに、名前を確認して、ファイル・システム内のファイルの保存場所を選択するように要求します。ファイル選択ダイアログ・ボックスで使用される名前は、アタッチメント名と同じです。エディタ (コマンド行アプリケーション) がファイル選択ダイアログ・ボックスを表示できない場合は、読み込んだファイルが読み込み専用であることを、はっきりと視覚的にユーザに通知しなければなりません。

ユーザがアタッチメントを直接に編集したい場合は、ユーザはアタッチメント・リストの中でアタッチメントを選択し、[アタッチメント] メニューから [開く] を選択するか、アタッチメントをダブルクリックします。これにより、編集し、変更内容を保存できるような形でアタッチメントを開くことができます。

もう 1 つのオプションとして、アタッチメントをドラッグ読み込みし、編集し、新しいファイル名で保存して、古いアタッチメントを新しいアタッチメントに手動で置き換えるという方法があります。

[アタッチメント] メニューの内容

推奨 

bw: 

アプリケーションでアタッチメント・メニューを使用する場合、該当するアクションが実際にサポートされているなら、次に示す選択肢にアプリケーションの機能を加えて格納します。 

推奨 

 

［ファイルの追加...］ 

接続するファイルや他の項目を選択する。ユーザが接続したいファイルを選択するためのファイル選択ボックスが表示される。ファイル選択ボックスのデフォルト・ボタンは [接続] である。 

推奨 

 

［別名保存...］ 

現在選択されているアタッチメントを保存する。ファイル・システムのどこにアタッチメントを保存するのかを指定するためのファイル選択ダイアログ・ボックスが、ユーザに表示される。複数のアタッチメントが選択されている場合、名前フィールドはアクティブでなく、アタッチメントの現在の名前が、新しいファイルの名前として使用される。このメニュー項目は、1 個以上のアタッチメントが選択されているときにのみアクティブである。 

推奨 

 

［名前の変更...］ 

アタッチメント・アイコンの名前を変更する。アプリケーションは、ファイル・マネージャのように、アタッチメント・アイコンの名前を変更したいときにはいつでも変更できるような手段を提供しなければならない。アプリケーションがインラインでの名前変更を提供できない場合、[名前の変更] はダイアログ・ボックスを表示して、ユーザに名前の入力を要求することによりアタッチメントの名前を変更する。このメニュー項目は、単一のアタッチメントが選択されているときにのみアクティブである。複数のアタッチメントが選択されているときはアクティブではない。  

推奨 

 

［削除］ 

アタッチメント・リストからアタッチメントを削除する。このメニュー項目は、アタッチメントが選択されている場合にのみアクティブである。 

推奨 

 

［すべてを選択］ 

アタッチメント・リストの中のすべてのアタッチメントを選択する。 

第 4 章 視覚的な設計

共通デスクトップ環境は視覚的なものが豊富な環境です。この章では、デスクトップ・スタイルと一致するアイコンやその他の視覚的な設計について説明します。デスクトップの背後にあるいくつかの設計思想を説明し、デスクトップのアイコンを作成するためのいくつかの有用なヒントを示します。

アイコンは、グラフィカル・ユーザ・インタフェース (GUI) の中に存在するオブジェクト (アプリケーション、ファイル、およびデバイス) を表現するグラフィックです。アプリケーションをデスクトップに適合させるということは、アプリケーションを表すアイコンと、そのアプリケーションが作成するデータ・ファイルを表すアイコンを設計するということです。これらのアイコンは、いくつかのサイズとカラーの濃さのものを作成しなければなりません。

この章では、アイコンが使用されるデスクトップ・コンポーネントと環境の要件について説明し、設計プロセスについて論じます。読者の実装の事情を考慮した一連の例が用意されています。

カラーの思想

他のほとんどの GUI では、カラーは、個々のアイコンや、ウィンドウ境界やタイトル・バーなどの特定のコントロール領域の中で、ローカルに、かつ特定の意味で使用されます。デスクトップでは、ほとんどすべてがカラーで描画され、黒い線が見あたらないほどカラーが使われています。

この環境でも、ほとんどのアイコンは、カラーをあまり使わず、主にグレーを使用します。このように、カラーの使用を制限することにより、デスクトップのパレットで使用する色数を最小限に抑えており、また視覚的にも優れた効果を得ています。アイコンは多くの場合カラーを持たず、つねにカラーの付いたバックグラウンドの上に表示されるため、より際立って見えます。

アイコンとは何か

アイコンは、通常は直接の操作によって、移動、コピー、削除、開くなどの操作ができる具体的なグラフィカルな要素と定義できます。

デスクトップ内の数多くのグラフィカル要素は操作不可能なので、技術的にいえばアイコンではありませんが、それでもアプリケーションの中では必要になります。このマニュアルでは、読者が用意しなければならない、あらゆる種類のグラフィカル要素を扱います。

図 4-1 デスクトップ環境の画面

Graphic

アイコンは次の役割を果たします。

ここに示したアイコンの目的は、いずれもアイコンを設計する上でのガイドラインとして使用できます。特には、視覚上の設計者は、これらの要件に関して大きな責任を負います。たとえば、オブジェクトの直接操作と、オブジェクトの状態と位置の表示はデスクトップ・システムによって処理されますが、製品の識別と伝達や、オブジェクト間の関係は、おもに視覚上の設計者の責任です。

推奨 

ey: 

アイコンはオブジェクトとアプリケーションを表すためにのみ使用する。 

アイコンはオブジェクトの視覚的な表現であり、直接操作を支援します。アイコンが、ユーザによるドラッグや選択などができない図などの他の目的に使用されると、一貫性がなくなって混乱が起こります。 

アイコンの設計の際には、上記のような設計ガイドラインのセットの適用を考慮する必要があります。ユーザのデスクトップに新しい製品を導入することは、すでに存在するアイコンに新しいアイコンのセットを追加するということです。これらのガイドラインに従うことにより、新しいアイコンがユーザの期待どおりになるでしょう。

アイコン中心のコンポーネント

ファイル・マネージャ

ファイル・マネージャは、ユーザのファイル構造の表示と構成を担当するツールです。ファイル・マネージャにアイコンで表示されるオブジェクトの基本型は、ファイル、ディレクトリ (フォルダ)、実行可能ファイル、およびアクションです。この章では、これらのオブジェクトをドキュメント、フォルダ、およびアプリケーションと呼びます。ファイル・マネージャはアイコンを 2 つのサイズで表示します。これらは [表示オプションの設定] ダイアログ・ボックスの中で [大型アイコン] と [小型アイコン] と呼ばれます。[大型アイコン] のサイズは 32*32 で、[小型アイコン] のサイズは 16*16 です。

図 4-2 ファイル・マネージャで使用されるサイズ 32*32 と 16*16 のアイコン

Graphic

ドキュメント、フォルダ、およびアプリケーションは、3 種類の形状で表現されます。ドキュメントは、紙のように見える縦型の長方形です。フォルダはファイル・フォルダのように見える、タブが付いた横型の長方形です。アプリケーションは任意の形状を取ることができ、アイコン・スクエア全体を使用します。ファイル・マネージャの中のすべてのオブジェクトは、ユーザに操作が可能であること、つまりドラッグ＆ドロップが可能であることを示さなければなりません。

アプリケーション・マネージャ

このウィンドウはファイル・マネージャに似ていますが、焦点はドキュメントではなく保持しているアプリケーションにあります。デスクトップ内のネットワーク・アクセス可能なすべてのアプリケーションは、フォルダではなくアプリケーション・グループと呼ばれるコンテナに格納されています。

アプリケーション・マネージャは「ネットワーク上の店」に似ています。これはユーザがシステム上で使用可能な最新のアプリケーションを探す場所です。

図 4-3 アプリケーション・マネージャのアプリケーション・グループ・アイコンの例

Graphic

図 4-3 のようなアプリケーション・グループ・アイコンは、オブジェクトのコレクション、この例では関連するオブジェクトのコレクションを表すという点で、フォルダに似ています。たとえば、アプリケーションがサポート・ファイルを必要としていたり、サンプル・ファイルを付属させたりする場合は、ユーザがアプリケーションの関連ファイルを探す場所を表す独自のアプリケーション・グループ・アイコンを設計できます。

フロントパネルとサブパネル

フロントパネルはデスクトップの「コントロール」パネルであり、通常は画面の一番下に表示されます。フロントパネルのアイコンを使って、ユーザが最もよく使用するアプリケーションに速やかにアクセスできます。

図 4-4 [個人アプリケーション] サブパネルを開いたフロントパネルの画面の一部

Graphic

フロントパネルは、フロントパネルの矢印ボタンでアクセスできるアイコンのサブパネルも持っています。サブパネルは概念上、フロントパネルのアイコンの拡張です。たとえば、図 4-4 は [個人アプリケーション] サブパネルを開いた様子を示しています。ユーザは [アイコンのインストール] ドロップ領域上にアプリケーションをドロップすることにより、このサブパネルにアプリケーションを追加できます。ユーザはポップアップ・メニューを介して、サブパネルのアイコンをフロントパネルに置くこともできます。

アイコン化されたウィンドウのアイコン

アイコン化されたウィンドウのアイコンは、ウィンドウがアイコン化されているときにデスクトップに表示されます。アイコンはアイコン化されたウィンドウを制御しているアプリケーションを表さなくてはなりません (図 4-5 を参照)。これらのアイコンは、フロントパネルで使用されているアイコンとサイズは同じですが、実行中のアプリケーションを表しているという点が異なります。

図 4-5 端末エミュレータ、テキスト・エディタ、カレンダ、ファイル・マネージャのアイコン化されたウィンドウ・アイコン

Graphic

その他のグラフィック

このカテゴリの主な要素には、ボタン・グラフィック、ツール・バー・グラフィック (図 4-6 を参照)、およびラベルとして使用されるグラフィックがあります。ペイント・プログラムのツール・パレットも、この一例です。プリンタ・ダイアログ・ボックスのドキュメントの方向ボタン (ランドスケープまたはポートレート) も、この一例です。これらはアプリケーションのために作成する、他の場所では使用されないグラフィックです。

図 4-6 カレンダ・アプリケーションで使用されるツール・バーの例

Graphic

アイコンでのカラーの使用

デスクトップ・アプリケーション用のアイコンを設計するときには、使用可能なカラー・パレットと、カラーの動的マッピングに注意する必要があります。

アイコン・カラー・パレット

デスクトップのアイコンは 22 色のパレットを使用します。

これらのカラーは、デスクトップ・アイコンを作成するための推奨ツールであるアイコン・エディタのデフォルトのカラーです (図 4-7 を参照)。このカラーのセットは、アイコンを作成するのに適切なパレットです。この限定されたパレットは、必要以上に多くのカラーを使わずに、アイコンの魅力とわかりやすさを最大限に高めるために選ばれました。

ここに示した以外のカラーを使用する場合、アイコンはカラー点滅効果を起こして、アイコンが読めなくなることがあります。アイコンの外観を確実に予想できるようにする最もいい方法は、デスクトップ・パレットの 22 色だけを使用することです。

推奨 

ez: 

アイコンは 22 色のカラーだけを使用する。 

図 4-7 アイコンに使用できる 22 種類の共通デスクトップ環境カラーを表示しているアイコン・エディタ

Graphic

ダイナミック・カラー

ダイナミック・カラーの限定された役割を理解することは重要です。これらは、表示されたアイコン上のユーザ・インタフェース要素を表示するのに使用されるカラーを表します。ファイル・マネージャ内でアイコンを表示する場合に、バックグラウンド・カラーはファイル・マネージャが決定します。ユーザがスタイル・マネージャでカラー・パレットを変更した場合は、ユーザ・インタフェースのカラーもそれに応じて変化し、そこにアイコンを表示するバックグラウンド・カラーが変化します。

一般に、これらのカラーは大部分のアイコンでほとんど使用されません。これらが使用される方法としては、次の 2 つがあります。

図 4-8 ダイナミック・カラー・シャドウの例

Graphic

設計思想と有用なヒント

視覚上の設計者は、アイコンの設計に際し、個別的と全体的の両方のアプローチをしなくてはなりません。各アイコンは、そのオブジェクトのメタファに従って個別に設計されなくてはなりません。アプリケーションのアイコンのセット全体によって作り出される視覚的効果に注意を払います。それらはアイコン・ファミリとして協調して動作しなければなりません。

アイコンの設計は反復プロセスです。紙を使うにせよ、コンピュータを使うにせよ、その反復の中で、できるだけ多く保存することをお勧めします。ユーザを対象にしてアイコンをテストするときには、いくつもの選択肢を用意しておくと便利です。

デスクトップのグラフィック言語の背景にある思想は、コンピュータの世界が実世界に近ければ、ユーザにとって便利だということです。これはプッシュ・ボタンやメニュー・バーなど、ウィンドウやコントロールの 3 次元的外観から、アイコンの一般的な外観にまで広がる問題です。

アプリケーション・アイコンには、ロゴから、図 4-12 に示したペンキ用のバケツのようなものまで、さまざまなものが考えられます。「リアル」に見えるアイコンは、ドラッグ＆ドロップなどの操作が実際に可能に思えるような外観をしています。

カラーを使った設計

アイコンは、主に 8 種類のグレーを使用し、8 色のカラーはたいていの場合アクセントとして使用します。8 色のカラーは非常に鮮明で、すぐに使いすぎる傾向があります。グレーを中心として使うことで、すでにカラフルなデスクトップ環境とうまく調和するようになります。カラーはグレーでディザリングをかけ、カラーの色調を抑えて、より広い領域をカバーすることもできます。また、グレーはアイコンの境界をスムーズにするためにも使えます。これは「平滑化」と呼ばれることがあります。

ユーザがカラー・パレットを変更するとアイコンの外観が変わるので、ファイル・マネージャ・アイコンにはダイナミック・カラーを使わないようにすることを推奨します。このような変化は不適切であり、また予期しない見苦しい配色になる可能性があります。

アイコン・スタイル

アイコンにはあらゆるグラフィカル・スタイルが使用されます。最も初期の GUI の時代においては、単純な黒のアウトラインのスタイルが好まれていました。カラーが追加されるにつれ、黒い線の中にカラーを入れて、色の付いた本のようになりました。これは、特に白のバックグラウンドの上に置かれるときは、自然な描画スタイルだといえます。アイコンには写実的なものが多いですが、抽象的なものもあります。

図 4-9 カレンダ・アイコン。白黒のアウトライン・スタイル (左) とデスクトップのグレー・スタイル (右)

Graphic

デスクトップは、カラーの付いた中間調のバックグラウンドを普遍的に使用し、明るいシャドウと暗いシャドウの両方を使って、かなり現実的なイメージを作り出しています。読者も、この表現スタイルを研究してみてください。

図 4-10 デスクトップの 3 次元アイコンの例

Graphic

スタイルのもう 1 つの要素が、オブジェクトを描くときの視点です。共通デスクトップ環境は、図 4-10 に示すように、対象となるオブジェクトがプリンタのように 3 次元の物体である場合には、少し上から見た視点を使用します。アイコンはドラッグ＆ドロップが可能であることがわかるように、3 次元的な感じが出るような処理を少しだけ加えるのが一番です。

図 4-11 共通デスクトップ環境スタイルに変換された XPM と XBM フォーマットのアウトライン・スタイル

Graphic

アプリケーション・アイコンの設計

アプリケーション・アイコンは、読者が設計する中でも最も重要なアイコンです。これは製品のアイデンティティが現われる場所であり、アプリケーションの行う作業をユーザに明確に知らせる機能も持っています。アプリケーション・アイコンは、ユーザがアプリケーションを実行するときに開くアイコンです。

アプリケーション・アイコンの形状に関して決まった規則はありません。アイコンの領域全体を占めることも、不規則な形を取ることもできます。アイコンには 3 次元的なスタイルを持たせることを推奨します。図 4-12 に示したアイコンは、デスクトップで使用されているアプリケーション・アイコンですが、独自のアイコンを設計するときにテンプレートとしても使用できます。

図 4-12 デスクトップで使用されるアプリケーション・アイコンの例

Graphic

アプリケーション・グループ・アイコンの設計

アプリケーション・グループ・アイコンは、ユーザがアプリケーションや、ReadMe ファイルやサンプル・ファイルなどの、開発者が添付した他のファイルを探すコンテナを表します。このアイコンは、ユーザがコンテナだとわかるように、フォルダやボックスなどの形にします。

図 4-13 アプリケーション・グループ・アイコンの例

Graphic

アプリケーション・マネージャで使用されている概念は、図 4-13 に示すように、アコーディオン・スタイルのフォルダに基づいたアイコンです。このアイコンは十分に大きく、ユーザがその中に何があるか判るようにイメージをフォルダの表面に表示しています。

ドキュメント・アイコンの設計

ドキュメント・アイコンは、そのドキュメント・アイコンに格納されているデータの種類と、そのドキュメントに関連付けられているアプリケーションを、ユーザが理解できるように作成していなければなりません。図 4-14 に、デスクトップで使用されているいくつかのドキュメント・アイコンを示します。これらは、独自のドキュメント・アイコンを設計する際のテンプレートとして使用できます。

図 4-14 デスクトップで使用されているドキュメント・アイコンの例

Graphic

複数のファイル・フォーマットをサポートするアプリケーションは、各種の出力形式に応じて、異なるドキュメント・アイコンを必要とします。各フォーマットでまったく異なるグラフィックを作成するのではなく、基本ファイルに使用するグラフィックに「タグ」を追加することで、各種のフォーマットのグラフィックを作成することもできます。

ドキュメント・アイコンの場合、ドキュメントの基本の長方形は、アイコンの正方形の領域の中で左に寄せられています。タグのアプローチを使う場合は、タグをアイコンの右側に、ちょうど半分が基本アイコンに重なるように、ただし内容を説明するグラフィックが隠れないように配置します。図 4-14 を参照してください。

国際的アイコン

プログラムを複数の国で使用する場合は、全世界で使用されるアイコンを設計するか、国ごとに別のアイコンを作成します。

全世界的なアイコンは、普遍的に理解されるものでなければなりません。たとえば、ドキュメント・アイコンは、世界のあらゆる場所で使用される紙を表しているので、世界のどこでも理解されます。メールボックスやごみ箱のようなもののアイコンは、国によって異なる外観をしているため、世界共通ではありません。

ユーモアは翻訳しにくいものです。テキストとシンボルも国ごとに違うので、アイコンでは使用するべきではありません。動物や体の部分 (頭、手など) は、さまざまな意味を持ち、一部の文化では不快な意味合いを持つこともあるので、避けるようにします。

推奨 

fa: 

アイコンは国際的に使用できるように設計しなければならない。 

他のプラットフォームとの違い

デスクトップは、読者が慣れているアプリケーションの世界と、次の点で異なっています。

表 4-1 共通デスクトップ環境アイコン・カラーの RGB 値

カラー 

RGB 値 

グレー 

RGB 値 

黒 

0, 0, 0 

Gray1 

225, 225,225 

白 

255,255, 255 

Gray2 

200, 200,200 

赤 

255, 0, 0 

Gray3 

175, 175,175 

緑 

0, 255, 0 

Gray4 

150, 150,150 

青 

0, 0, 255 

Gray5 

125, 125,125 

黄 

255, 255, 0 

Gray6 

100, 100, 100 

シアン 

0, 255, 255 

Gray7 

75, 75, 75 

マゼンタ 

255,0,255 

Gray8 

50, 50, 50 

必要なアイコンの実装

この節では、デスクトップ環境で正確に表示されるアイコンを作成するために知っておかなくてはならない、フォーマット、解像度、サイズ、名前の付け方などについて説明します。

フォーマット

デスクトップはカラー・モードとモノクロ・モードの両方で動作するので、アイコンはカラーの XPM とモノクロの XBM の 2 つのフォーマットで作成しなければなりません。アイコン・エディタはアイコン・ファイルを両方のフォーマットで保存します。

注 -

アイコン・エディタが作成するモノクロ・アイコンは、通常はさらに手を加える必要があります。たとえば、カラーとグレーを黒と白に変換する際に、アイコンの一部が消えてしまったり、黒く見えるようになったりすることがあります。

デスクトップでは、ボタンとパレットは XBM フォーマットと XPM フォーマットのどちらも使用できます。ボタン、パレット、およびツール・バー・グラフィックでは、可能な限り XPM フォーマットを使用することをお勧めします。

XBM ファイル・フォーマットは、フォアグラウンドとバックグラウンドの 2 つのカラーしか持ちません。デスクトップでは、フォアグラウンド・カラーは固定されておらず、バックグラウンド・カラーに応じて変化します。あるカラー・スキームでは、バックグラウンド・カラーは暗いグレーで、すべてのテキストとグラフィックは白で表示されます。しかし、明るいグレーのバックグラウンドを持つカラー・スキームでは、テキストとグラフィックは黒で表示されます。

このようなフォアグラウンド・カラーの反転は、一部のアイコンでは奇妙な効果を生み出します。矢印のような単純な形状では、悪影響はありません。しかし、他のイメージでは、フォアグラウンド・カラーの反転によって作成された「ネガ」が判別不可能になるため、使用不可能になることがあります。

たとえば、フォアグラウンドが白のアイスクリーム・コーンのグラフィックで、アウトラインで描かれたコーンの上に白いアイスクリームの固まりが盛られているものは、アイスクリーム・コーンが黒のアウトラインになり、アイスクリームも黒になると、かなり違った風に見えます。ユーザがアイスクリームの味を選択できるというようなアプリケーションでは、カラーが変化すると、ユーザに奇妙なメッセージが伝わってしまいます。

図 4-15 フォアグラウンドが反転されたモノクロ (XBM) ビットマップ

Graphic

解像度

デスクトップのディスプレイ解像度は、低解像度 (640*480)、中解像度 (800*600)、および高解像度 (メガピクセル) の 3 つです。フロントパネルや一部のアイコンのサイズは、ディスプレイの解像度に応じて自動的に変化します。このため、アプリケーションは複数のサイズのアイコンを用意しなければなりません。

推奨 

ew: 

アプリケーションが表示するすべてのアイコンやグラフィックは、低 (640*480)、中 (800*600)、および高 (メガピクセル) 解像度で判別できなければならない。言い換えれば、低、中、および高解像度のディスプレイのために、複数のサイズの視覚的要素を用意する。 

サイズ

デスクトップ・アイコンには、16*16、32*32、および 48*48 の 3 つのサイズがあります。これらは、それぞれ 16、32、48 と呼ばれます (拡張子はそれぞれ .t、.m、.l です)。PC ドメインに由来するアプリケーションの場合、デスクトップで使用されるサイズ 16 と 32 のアイコンはよく知っているサイズです。表 4-2 に、各サイズの使用場所の定義を示します。

表 4-2 アイコンのサイズと使用方法

コンポーネント 

低解像度 

中解像度 

高解像度 

ファイル・マネージャ 

32, 16 

32, 16 

32, 16 

アプリケーション・マネージャ 

32, 16 

32, 16 

32, 16 

フロントパネル 

32 

48 

48 

サブパネル 

16 

32 

32 

フロントパネル・コントロール 

16 

16 

16 

アイコン化されたウィンドウ 

32 

48 

48 

注 -

24*24 のアイコン (拡張子は .s) は、ツールバー・グラフィックなどの内部アプリケーション・グラフィックに使用され、デスクトップ・アイコンの標準セットには含まれていません。

表 4-3 に、アプリケーションの作成に必要なアイコンのリストを示します。各タイプとサイズについて、1 つずつと仮定すると、合計で 16 個のアイコン・ファイルが必要となります。図 4-16 に、アイコン・セットの例があります。

表 4-3 最小限必要なアイコン・セット

アイコンのタイプ 

カラー 

カラー 

カラー 

モノクロ 

モノクロ 

モノクロ 

 

16 

32 

48 

16  

32 

48 

アプリケーション・アイコン 

v 

v 

v 

v 

v 

v 

ドキュメントまたはファイル・アイコン 

v 

v 

 

v 

v 

 

アプリケーション・コンテナ・アイコン 

v 

v 

 

v 

v 

 

アイコン化されたウィンドウ 

 

 

v 

 

 

v 

推奨 

ex: 

アプリケーションが表示するアイコンやグラフィックは、白黒のモニタとグレースケール・モニタできれいに表示されるように設計されていなければならない。これらの視覚的要素は、色数の少ない (16 色) システムでもきれいに表示されなければならない。 

アイコンの命名規則

アイコンのベース名は 7 文字以下でなければなりません。表 4-4 に示すように、サイズおよびカラーの拡張子が名前に追加されます。

表 4-4 アイコン名の規則

サイズ 

カラー 

白黒 

白黒マスク 

48 

Iconame.l.pm

Iconame.l.bm

Iconame.l_m.bm

32 

Iconame.m.pm

Iconame.m.bm

Iconame.m_m.bm

24 

Iconame.s.pm

Iconame.s.bm

Iconame.s_m.bm

16 

Iconame.t.pm

Iconame.t.bm

Iconame.t_m.bm

拡張子.pm はカラー XPM フォーマットを表します。拡張子 .bm は XBM フォーマットを表します。拡張子 _m は、白黒アイコンのマスクを表します。

これらすべての構成のアイコンを用意する必要はないということに注意してください。表 4-3 に必要なアイコンのリストを示します。たとえば、.s アイコンは主にツールバーのようなオブジェクトに使用されますが、アプリケーションによってはツールバーがないこともあります。

図 4-16 メール・プログラムのために最小限必要なアイコン・セットの例

Graphic

揃え方

アイコンに使用するグラフィックによっては、ビットがアイコンに割り当てられたスペース全体を占有しないこともあります。空のスペースをデスクトップ・アイコンのどこに置くかを決めるための推奨規則を、図 4-17 に示します。これらの規則に従うことで、ファイル・マネージャやフロントパネルにアイコンを表示したときに、他のアイコンと視覚的に揃って表示されることが保証されます。

推奨 

fb: 

16*16 アイコンと 32*32 は左揃えである。空のビットは、アイコン領域の右側に置かれる。 

推奨 

fc: 

48*48 アイコンはアイコン領域内で中央に揃えられる。 

図 4-17 右側にタグを付けた、左揃えされた 32*32 アイコンの例

Graphic

アイコン・サイズのオプション

ドキュメント・アイコンやアプリケーション・グループ・アイコンは、アイコン化されたウィンドウ・アイコンに使用されることがなく (代わりにツールのアイコンが使用されます)、フロントパネルでも使用されないので、サイズ 48 のアイコンを作成する必要はありません。しかし、ユーザがこれらのアイコンをフロントパネルに配置する可能性はあります。

サイズ 48 のアイコンが使用できない場合には、フロントパネルは代わりにサイズ 32 のアイコンを使用します。アイコンがフロントパネルで使用される可能性がある場合は、サイズ 48 のアイコンを用意することもできます。

フロントパネルのアイコン・スタイルのオプション

フロントパネルにデフォルトで表示されるアイコンは、ファイル・マネージャのアイコンとは若干異なる外観をしています。これらのアイコンは表面にエッチングが施されたように見えます。これらのアイコンはドラッグ＆ドロップできないため、このように安定した外観になっています。

デスクトップのデフォルト・アイコンのようにエッチングが施された外観を持つ、サイズ 48 のアイコンを用意する必要はありません。アイコンがフロントパネルで使われるか、使われるとしたらどういうときなのかを判定するのは簡単なことではありません。このため、この使用法のために設計を行うのではなく、より一般的なファイル・マネージャでの使用のために設計を行うことを推奨します。

フロントパネルのアイコンを設計することを決めた場合は、次に示すエッチングが施された外観を作成するための指示を参考にしてください。このスタイルを実装する際には、視覚上の設計者の協力を得ることを強く推奨します。

エッチングの施された外観の実現

エッチングを適用するためには、ダイナミック・カラーのことを理解しておく必要があります。まず、48*48 のスペースを完全には使用していないサイズ 48 のアイコンから作業を始めます。アートワークは、エッチング用に、すべての辺に 2、3 ピクセルの余裕を持たせておく必要があります。

図 4-18 左上から照らされたアイコンの例

Graphic

アイコンは明るいカラーと暗いカラーの両方で、できればグレーで描かれなければなりません。アイコンは左上から照らされていなければなりません。上と左の辺には明るいカラーを、下と右の辺には暗いカラーを使用します。図 4-18 に、エッチングを適用する前のデスクトップのテキスト・エディタ・アイコンを示します。

図 4-19 ボトムシャドウ・カラーおよびトップシャドウ・カラーの適用

Graphic

エッチング効果は、アイコンのアートワークの上と左の辺のすぐ外に 1 ピクセルのボトムシャドウ・カラーの行を描き、アイコンのアートワークの下と右の辺のすぐ外に 1 ピクセルのトップシャドウ・カラーの行を描くことによって実現されます。

アイコンとエッチングの影の照明モデルに一貫性がないと効果が出ません。アイコンが黒い線で描かれている場合、上と左の辺に黒い線を重ねるとエッチングの外観はおかしくなります。

外観に適切なエッチング効果を与えて、アイコンをフロントパネルの他のアイコンと調和させるには、アイコンのスタイルが非常に重要です。デスクトップに付属するフロントパネルのアイコンを参考にして研究してください。遠近感のあるアイコン、黒いアウトラインを持つアイコン、および「板」が浮き出たようなアイコンは使用できません。

エッチングの外観の発展

エッチングは、アイコンをエッチングが施されている表面の一部に見せかける 1 つの手段です。アイコンのすべての部分が表面にエッチングされている必要はありません。選択的なエッチングを施して、オブジェクトのアンカーの一部をパネルの中に固定し、別の一部をパネルの上に置いたり、少しだけ飛び出しているように見せかけることもできます。

図 4-20 鉛筆を表面から突き出して、ページのアンカー処理を行う例

Graphic

たとえば、[ヘルプ] アイコンは、右側の本の下と横のトップシャドウ・カラーで作られたエッチングを取り除き、これを選択カラーのシャドウに置き換えています。これにより、1 冊の本が本棚から若干飛び出しているように見えます。プリンタ・アイコンでは用紙トレーが突き出しています。[スタイルマネージャ] アイコンでは、パレット、文字、およびマウスが、エッチングされたウィンドウ枠の上方にあります。[ファイルマネージャ] アイコンはさらに先に進んで、オープニングの端だけがエッチングされており、引き出しの前面と、そこから出ているフォルダは飛び出して、影さえも付いています。

原理としては、アートワークの中の何かをアンカー処理し、オブジェクトの 3 次元的な性質も強調することが重要です。アイコンの中の可変的な内容、たとえばプリンタ・ページや [メール・プログラム] アイコンのメール封筒などは、アンカー処理するべきではありません。

第 5 章 ウィンドウとセッションの管理

アプリケーションは、一連のウィンドウとしてユーザに提示されます。これらのウィンドウの一部は、アプリケーションの主要な部分を表します。その他にも、特定の作業を実行するときにのみ表示される動的ウィンドウがあります。これらのすべてのウィンドウは、その機能に適したメニュー、ボーダ装飾、および動作スタイルを持っていなければなりません。この章では、アプリケーションのウィンドウの設計に適用されるガイドラインについて説明します。

ウィンドウ管理のガイドライン

ウィンドウ境界と装飾に関する具体的な説明は 「ウィンドウ装飾」に、各種のウィンドウ管理の動作の説明は 「ウィンドウ管理アクション」にあります。

主ウィンドウのユーザに見える基本特性は、重なり、ワークスペースの配置、およびアイコン化を、他の主ウィンドウとは独立に実行できるということです。副ウィンドウの重なり、ワークスペースの配置、およびアイコン化は、それに関連付けられている主ウィンドウと連係します。

必須 

aa: 

アプリケーション・ウィンドウは、外観と動作に基づいて、主ウィンドウと副ウィンドウのどちらなのかが明確に区別できなければならない。 

ウィンドウ管理アクション

必須 

aq: 

ウィンドウは、表 10-2 に示す共通デスクトップ環境のウィンドウ管理機能の規則に従わなければならない。

主ウィンドウは、最小限の能力のセットとして、[閉じる]、[移動]、[奥へ]、および [アイコン化] を備えていなければなりません。また、必要に応じて [サイズ] と [最大表示] も実行できるべきです。副ウィンドウは、サイズと最大表示が不要であり、また不適切でもあるように設計されなければなりません。大部分の副ウィンドウは、[閉じる]、[移動]、および [奥へ] の能力だけを持つべきです。ただしまれに、副ウィンドウは [サイズ] と [最大表示] も提供することがあります。副ウィンドウは [アイコン化] の能力は持ちません。副ウィンドウは、関連する主ウィンドウと共にアイコン化されます。 

必須 

as: 

ウィンドウの形成要素に制約を持つウィンドウは、必要に応じて、最小サイズ、最大サイズ、アスペクト比、およびサイズ変更増分のウィンドウ・マネージャのヒントを設定する必要がある。 

必須 

at: 

必要ならば、ウィンドウを最大表示することにより、(オブジェクトやコントロールのサイズを拡大するのではなく) より多くの内容 (オブジェクトまたはコントロール) を表示できるようにすることができる。 

必須 

au: 

[閉じる] または [終了] の機能を持つウィンドウは、ウィンドウ・メニューが存在する場合は、[閉じる] のためのウィンドウ管理プロトコルをサポートする必要がある。ダイアログ・ボックスの場合、ウィンドウ・メニューの [閉じる] 項目は、[取消し] 機能や、ダイアログ・ボックスの消去のアクションだけを行うことに相当する。 

ウィンドウ装飾

ウィンドウ装飾は、アプリケーション・ウィンドウの枠にある、ユーザに見えるコントロールです。図 5-1 に、主ウィンドウに一般に含まれているサンプルの装飾をいくつか示します。

必須 

ab: 

特定のウィンドウ管理機能をサポートするウィンドウは、対応するウィンドウ装飾を要求しなければならない (たとえば、アイコン化できるウィンドウは、アイコン化ボタンを要求する)。 

図 5-1 主ウィンドウ装飾の例

Graphic

さらに、移動、サイズ、アイコン化、最大表示、閉じるなどのウィンドウ管理機能をサポートするウィンドウは、その機能に応じた項目を持つウィンドウ・メニューを持っていなければなりません。

必須 

ad: 

表 10-1 に示す共通デスクトップ環境のウィンドウ装飾規則に従う。

主ウィンドウは、境界、タイトル、メニュー、およびアイコン化のウィンドウ装飾を持っていなければなりません。また、必要に応じて、主ウィンドウは最大表示とサイズ変更の装飾を持つこともできます。

副ウィンドウは、サイズ変更と最大表示が不要であり、また不適切でもあるように設計されるべきです。大部分の副ウィンドウは、境界、タイトル、およびメニューの装飾しか持ちません。ただし、副ウィンドウでサイズ変更や最大表示ができる場合は、それに応じた装飾が必要です。図 5-2 に、典型的な副ウィンドウの装飾を示します。

図 5-2 副ウィンドウ装飾の例

Graphic

ウィンドウ・メニュー

ウィンドウは、ユーザがアプリケーション・ウィンドウのサイズや配置に影響を与える、さまざまな操作を実行するためのメニューを持っています。開発者は、アプリケーションの中で、次の標準ウィンドウ・メニュー項目を使用するべきです。

必須 

ae: 

共通デスクトップ環境のウィンドウ・メニューの規則に従う。ウィンドウまたはそのアイコン化されたウィンドウ・アイコンに適用される項目は、ウィンドウ・メニューに存在していなければならない。 

図 5-3 ウィンドウ・メニューのサンプル

Graphic

次に、ウィンドウ・メニューの選択肢として使用できる項目を示します (各選択肢のニーモニックをカッコ内に示します)。これらは、ここに表示されている順序でメニューに追加しなければなりません。特に指定していない限り、これらのメニュー項目の機能は、『OS/DMotif スタイル・ガイド リリース 1.2』に記されているものと同じです。

推奨 

af: 

アプリケーションは、ウィンドウ・メニューに項目を追加するべきではない。どうしてもアプリケーションのウィンドウ・メニューに項目を追加しなければならない場合は、[閉じる] とアプリケーション項目の間にセパレータを入れて、メニューの末尾に項目を追加する。 

オプション 

ag: 

ウィンドウ・メニューでは、アプリケーション・アクセラレータ、ローカリゼーションなどに対する [Alt] キーの他の用途との重複を最小限に抑えるため、[閉じる] のための [Alt] + [F4] キーを除いてアクセラレータを使用するべきではない。 

ウィンドウ・アイコン

アプリケーションは、デスクトップ上でアイコン化されたときには、アイコンを使って自分の存在を表現しなければなりません。

オプション 

ah: 

アプリケーションは、主ウィンドウのために、固有のウィンドウ・アイコンを用意しなければならない。ウィンドウ・アイコンのイメージは、関連するファイルまたはフロントパネルのアイコン・イメージと似た外観でなければならない。 

オプション 

ai: 

ウィンドウ・アイコンのラベルは、対応する主ウィンドウのタイトルと同じテキストか、その省略形を含まなければならない。ウィンドウ・タイトルのガイドラインについては、「配置」を参照すること。

オプション 

aj: 

ウィンドウ・アイコンのイメージは、関連するファイルまたはフロントパネルのアイコン・イメージと似た外見でなければならない。「設計思想と有用なヒント」を参照すること。

ウィンドウの配置

ウィンドウの配置は、ウィンドウ・マネージャかユーザの制御に任せます。

推奨 

ak: 

アプリケーションは、ウィンドウやウィンドウ・アイコンを画面上の特定の位置に配置されるのを、強制または要求してはならない。 

推奨 

al: 

副ウィンドウは、アプリケーションによって、それに関連する主ウィンドウの位置を基準に配置される。副ウィンドウは、それを表示したコンポーネントと、ダイアログ・ボックスとの対話に必要な情報を隠さない程度に近い位置に配置される。 

推奨 

an: 

関連する主ウィンドウの下に副ウィンドウを配置できる場合 (主ウィンドウの上に置くという制約がない場合)、主ウィンドウによって完全に隠されないように配置されなければならない。この推奨事項は、他の配置に関する推奨事項よりも優先される。 

推奨 

ao: 

メニューまたはダイアログ・ボックスがすでに表示されている場合、その表示を引き起こしたコマンドを再起動すると、そのウィンドウまたはメニューが、画面上の位置を変更せずに、ウィンドウの重なりの一番手前に自動的に表示される。 

ワークスペース管理のガイドライン

デスクトップ・アプリケーションは、ワークスペースと呼ばれるいくつかの作業領域の 1 つに表示されます。ユーザはデスクトップ上で複数のワークスペースをアクティブにすることができます。アプリケーションは、これらのワークスペースに対して、いくつかの点で限定された動作をしなければなりません。

推奨 

av: 

アプリケーションが新しいウィンドウを作成するとき、そのウィンドウはユーザの現在のワークスペースに表示され、そのワークスペースだけを使用しなければならない。 

推奨 

aw: 

特定の作業に関連するアプリケーション・ウィンドウは、ワークスペース間を一緒に移動しなければならない。 

たとえば、スプレッドシートのアプリケーションは、ユーザがメイン・ウィンドウのデータ・セルの特性を変更できるように、1 つ以上の副ウィンドウを開くことがあります。ユーザがメイン・ウィンドウを別のワークスペースに移動すると、特性ウィンドウも一緒に移動しなければなりません。

一方、ワード・プロセッサは複数のウィンドウを開いて、各ウィンドウで別のドキュメントを編集できるようにすることがあります。この場合、ユーザがウィンドウの 1 つを別のワークスペースに移動しても、残りのウィンドウは元の位置に残ります。

セッション管理サポート

デスクトップ・アプリケーションを設計するときは、セッション管理の点で次のガイドラインに注意する必要があります。

必須 

ax: 

アプリケーションは、主ウィンドウと主要な属性のセッション管理のため、ICCCM (Interclient Communication Conventions Manual) 機能をサポートしなければならない。 

ICCCM は、アプリケーション状態を複数の起動を通して保存し、復元するためのプロトコルを含む、アプリケーションとウィンドウ・マネージャの間の重要な関係や動作を定義しています。 

必須 

ay: 

アプリケーションは、すべての関連ウィンドウ (つまりヘルプ・ウィンドウを含む副ウィンドウ) のセッション管理のため、ICCCM 機能をサポートしなければならない。 

関連ウィンドウには、複数の主ウィンドウと、オンライン・ヘルプ・ウィンドウなどの副ウィンドウが含まれます。 

オプション 

az: 

アプリケーションは、ユーザがログアウトしようとしていることを通知する共通デスクトップ環境のセッション・マネージャからのメッセージを受け付けて、その時点でのアプリケーションの状態を保存しなければならない。 

オプション 

ba: 

ユーザがログアウトする時点で、単一の主ウィンドウが開いていたアプリケーションは、ユーザが再度ログインしたときに、最後に置かれていたワークスペースに主ウィンドウを復元しなければならない。 

オプション 

bb: 

可能な限りユーザ・コンテキストを保存する。たとえば、ファイルの編集をサポートするアプリケーションは、ログアウト時のファイルの状態を保存し、ユーザが再度ログインしたときに、アプリケーション・ウィンドウ内にファイルを復元しなければならない。 

オプション 

bc: 

ユーザがログアウトする時点で、複数の主ウィンドウが開いていたアプリケーションは、ユーザが再度ログインしたときに、最後に置かれていたそれぞれのワークスペースにすべての主ウィンドウを復元しなければならない。 

第 6 章 アプリケーション設計の原理

アプリケーションは、コンポーネントを論理的に、作業に基づいて整理された形でユーザに提示しなければなりません。ユーザがどのデスクトップでも同じ規則と操作を利用できるようえに、メニューは共通の構成と命名規則に従わなければなりません。この章では、共通デスクトップ環境のアプリケーションの設計とメニュー構造の要件について説明します。

コンポーネントの配置のガイドライン

アプリケーション内のコントロールの物理的な構成を設計するときは、デスクトップ内で一貫性のあるインタフェースがユーザに提示されるように、次のガイドラインを使用する必要があります。

メイン・ウィンドウの配置

必須 

6-1: 

アプリケーションは、少なくとも 1 つのメイン・ウィンドウで構成されていなければならない。 

メイン・ウィンドウには、クライアント領域と、オプションでメニュー・バー、コマンド領域、メッセージ領域、およびスクロール・バーがあります。クライアント領域には、アプリケーションのフレームワークがあります。メイン・ウィンドウを使用することにより、アプリケーション間での一貫性が保証されます。 

必須 

bd: 

アプリケーションのメイン・ウィンドウのデフォルト・サイズは、典型的なデータの量を扱えるだけの大きさでなければならないが、他のアプリケーションとの視覚的な衝突を最小限に抑えるために、物理的ディスプレイ・サイズ全体を占有してはならない。 

必須 

6-2: 

アプリケーションが、同じ主機能を備える複数のメイン・ウィンドウを持っている場合は、各ウィンドウが独立に閉じたりアイコン化される。 

たとえば、テキスト・エディタでは、複数のドキュメントを、それぞれ独立したメイン・ウィンドウ内で編集できます。この場合、各ウィンドウは独立したアプリケーションとして扱われ、使用されていないときは閉じたりアイコン化したりできます。 

必須 

6-3: 

アプリケーションが、異なる主機能を備える複数のメイン・ウィンドウを持っている場合は、各ウィンドウが他のウィンドウとは独立にアイコン化できなければならない。 

たとえば、デバッガは、ソースコードの編集、データ値の確認、および結果の表示のために別のメイン・ウィンドウを用意していることがあります。各ウィンドウは、使用していないときはアイコン化できますが、各ウィンドウが別々に閉じられるのか、1 つのウィンドウを閉じるとアプリケーション全体が閉じられるのかは、アプリケーションによって異なります。 

必須 

be: 

サイズ変更コーナーは、スクロールするデータ区画やリストを含んでいるすべてのメイン・ウィンドウに組み込まれていなければならない。 

ウィンドウの全体的なサイズを変更したら、それに応じて、スクロール可能な部分のサイズも増減しなくてはなりません。さらに、アプリケーションは空間の増減に基づいて、ウィンドウ内の要素の配置を再構成することもできます (たとえば 1 行のボタンを 2 行に再構成します)。 

メニュー・バーの配置

注 -

これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、修正を加える必要があります。

必須 

6-4: 

アプリケーションがメニュー・バーを持つ場合、メニュー・バーは、アプリケーションの上方、ウィンドウ枠のタイトル領域のすぐ下に置かれる。メニュー・バーは、アプリケーションで最もよく使われる機能をまとめたものである。メニュー・バーは階層式ボタンの形で、メニュー・トピックのリストを含んでいる。各ボタンは、機能によってグループ化されたコマンドを格納する独立したプルダウン・メニューに関連付けられている。メニュー・バーを使用することにより、アプリケーション間の一貫性が保たれる。 

メニュー・バーは、アプリケーションの最もよく使われる機能をまとめたものです。メニュー・バーはボタンの形で、メニュー・トピックのリストを含んでいます。各ボタンは、機能によってグループ化されたコマンドを格納する独立したプルダウン・メニューに関連付けられています。メニュー・バーの使用は必須ではありませんが、強く推奨します。 

必須 

6-5: 

アプリケーションのメニュー・バーには、階層式ボタンだけを格納する。 

バーの中で他のタイプのボタンを使用すると、メニュー構造をブラウズできなくなります。 

推奨 

bn: 

「標準」と見なされるいくつかの一般的なメニュー操作がある。標準のメニュー・バー項目は [ファイル]、[編集]、[表示]、[オプション]、および [ヘルプ] である。アプリケーションがこの種の機能をユーザに提供する場合、メニュー・バーの適切な名前の下に入れておく。これらのメニュー項目の内容については、後で詳細に説明する。 

標準メニュー・バーのエントリは次の順序で表示しなければなりません。 

[ファイル] [編集] [表示] [オプション] [ヘルプ] 

アプリケーションがこれらの項目に関連する機能をサポートしない場合は、メニュー・バーから削除してください。たとえば、アプリケーションがデータを異なった表示方法で表示する能力を持っていない場合は、[表示] メニューは削除しておくべきです。 

  

標準メニュー項目の間に、アプリケーション固有のメニューを追加できます。ただし、次の条件があります。 

  • [ファイル] メニューが存在する場合は、一番左のメニュー位置になければなりません。

  • [ヘルプ] メニューは、一番右の位置になければなりません。

  • [ファイル] と [編集] が存在する場合は、両者が隣接していなければなりません。

アプリケーションのメニューの例を次に示します。 

[ファイル] [編集] <カテゴリ 1> <カテゴリ 2> [表示] [オプション] <カテゴリ 3> [ヘルプ] 

推奨 

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 章「一般ダイアログ」に記されている機能を持っているならば、アプリケーションはダイアログ・ボックスを使用するべきです。

  • [新規 (N)] (必須)

    新規ファイルを作成します。現在のクライアント領域が新規ファイルの表示に使用されるならば、アプリケーションはクライアント領域から既存のデータを消去します。現在のファイルに加えられた変更内容が失われるならば、アプリケーションは変更内容を保存するかどうかをユーザに問い合わせるダイアログを表示します。ニーモニックは N です。

  • [開く (O)...] (必須)

    ユーザにダイアログ・ボックスでファイル名の入力を求め、既存のファイルを開きます。現在のファイルに加えられた変更内容が失われるならば、アプリケーションは変更内容を保存するかどうかをユーザに問い合わせるダイアログを表示します。ニーモニックは O です。

  • [保存 (S)] (必須)

    クライアント領域の既存の内容を削除せずに、現在開いているファイルを保存します。ファイルが名前を持たない場合、アプリケーションはユーザにファイル名の入力を求めるダイアログを表示します。ニーモニックは S です。

  • [別名保存... (A)] (必須)

    ユーザにダイアログ・ボックスでファイル名の入力を求め、現在開いているファイルを新しい名前で保存します。ユーザが既存の名前を使ってファイルの保存を試みた場合、アプリケーションは、データが失われる可能性があることを、ユーザに警告するダイアログを表示します。クライアント領域の既存の内容は削除しません。ニーモニックは A です。

  • [印刷 (P)] (推奨)

    ファイルの印刷をスケジュールします。アプリケーションが印刷のために特定の情報を必要とする場合は、ユーザに情報を要求するダイアログを表示します。この場合、メニュー・エントリの後には省略記号が付きます ([印刷...])。ニーモニックは P です。

 

 

  • [閉じる (C)] (推奨)

    現在の主ウィンドウと、関連する副ウィンドウを閉じます。このアクションではアプリケーションは終了しません。アプリケーションを終了するには [終了] を使用します。現在の主ウィンドウの変更内容が失われるならば、アプリケーションは変更内容を保存するかどうかをユーザに問い合わせるダイアログを表示します。アプリケーションが、単一の主ウィンドウだけを使用しているか、複数の互いに依存する主ウィンドウを使用している場合、このアクションは用意されません。ニーモニックは C です。
   

 

 

  • [終了 (x)] (必須)

    現在のアプリケーションと、それに関連するすべてのウィンドウを終了します。現在のファイルの変更内容が失われるならば、アプリケーションは変更内容を保存するかどうかをユーザに問い合わせるダイアログを表示します。ニーモニックは x です。

必須 

bq: 

ユーザが [終了] を選択したり、何らかの他の方法でアプリケーションの終了を指示したが、現在のファイルに保存されていない変更内容がある場合に、アプリケーションは終了する前に変更内容を保存するかどうかを問い合わせるダイアログ・ボックスを表示する。 

ユーザは、保存されていない変更内容を保存するのか、破棄するのかを明示的に指定する機会を必ず与えられなければなりません。現在のファイルの変更内容を保存しないまま、ユーザが [ファイル] メニューから [開く] を選択した場合も、上記のようなダイアログ・ボックスを表示する必要があります。 

<Object-type> と [選択] メニューの内容

<obj-type> メニューは、ユーザがオブジェクト型のインスタンスを作成するためのコントロールを格納しています。<obj-type> メニューと [選択] メニューは、ユーザがオブジェクト・インスタンスを操作できるようにします。アプリケーションが管理するオブジェクトの操作だけに関連する操作 (アプリケーションが提供する、より一般的なサービスでないもの) があれば、<obj-type> または [選択] メニューに項目として追加します。

推奨 

br: 

アプリケーションが <obj-type> メニューや [選択] メニューを使用し、該当するアクションが実際にアプリケーションによってサポートされている場合、次に示す機能を持つ選択肢を含む。項目は、次に示す順序で、ユーザに提示されなければならない。 

  • [新規 (N)...] (推奨)

    オブジェクト型の新規インスタンスを作成します。そのオブジェクトに関連する設定の値を指定するためのダイアログ・ボックスが表示されます。ニーモニックは N です。

  • [移動先 (M)...] (オプション)

    選択したオブジェクトをフォルダに移動できます。希望のフォルダを選択するためのファイル選択ダイアログ・ボックスが表示されます。ニーモニックは M です。

  • [コピー先 (C)...] (オプション)

    選択したオブジェクトをフォルダにコピーできます。希望のフォルダを選択するためのファイル選択ダイアログ・ボックスが表示されます。ニーモニックは C です。

  • [ワークスペースに置く (t)] (オプション)

    オブジェクトのリンクを、共通デスクトップ環境上の現在のワークスペースに置くことができます。

上の 3 つのメニュー選択肢は、アプリケーションが管理するオブジェクトが、アプリケーションのメイン・ウィンドウの外で独立した要素として存在できる場合にのみ用意します。たとえば、プリンタ管理アプリケーションが作成するプリンタ・オブジェクトなどは、フォルダ・ウィンドウの中で、それ自身がアプリケーションとして機能できます。また、アプリケーションはこれらのアクションを実行する手段として、ドラッグ＆ドロップもサポートしなければなりません。 

  • [削除 (D)] (オプション)

    選択されたオブジェクトを削除します。オブジェクトを実際に削除する前に、確認ダイアログ・ボックスをユーザに表示しなければなりません。ニーモニックは D です。

  • [属性 (P)] (推奨)

    選択されたオブジェクトに関連する設定の現在の値を表示する [属性] ウィンドウを表示します。ニーモニックは P です。

  • <デフォルトのアクション> (推奨)

    この選択肢は、選択されたオブジェクトのデフォルトのアクションを規定します。典型的なデフォルトのアクションは [開く] です。

[編集] メニューの内容

注 -

これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。

必須 

6-8: 

アプリケーションが [編集] メニューを使用し、該当するアクションが実際にアプリケーションによってサポートされている場合、次に示す機能を持つ選択肢を含む。 

  • [元に戻す (U)] (推奨)

    直前に実行されたアクションを元に戻します。ニーモニックは U です。

  • [カット (t)] (推奨)

    クライアント領域の選択された部分のデータを削除し、クリップボードに入れます。ニーモニックは t です。

  • [コピー (C)] (推奨)

    クライアント領域の選択された部分のデータをコピーし、クリップボードに入れます。ニーモニックは C です。

  • [リンクのコピー (k)] (オプション)

    クライアント領域の選択された部分のデータのリンクをコピーし、クリップボードに入れます。ニーモニックは K です。

  • [ペースト (P)] (推奨)

    クリップボードの内容をクライアント領域にペーストします。ニーモニックは P です。

  • [リンクのペースト (L)] (オプション)

    クリップボードの内容が表しているデータのリンクをクライアント領域にペーストします。ニーモニックは L です。

  • [消去 (e)] (推奨)

    クライアント領域の選択された部分のデータを、クリップボードにコピーせずに削除します。残ったデータは、[消去] 操作によって生じた隙間を埋めるように再配置されません。ニーモニックは e です。

 

 

  • [削除 (D)] (推奨)

    クライアント領域の選択された部分のデータを、クリップボードにコピーせずに削除します。ニーモニックは D です。

  • [すべてを選択 (S)] (推奨)

    クライアント領域のすべての選択可能な要素を一次セレクションとして設定します。ニーモニックは S です。

  • [選択をすべて解除 (l)] (推奨)

    一次セレクションから、クライアント領域のすべての選択可能な要素を取り除きます。ニーモニックは l です。

 

 

  • [ペーストされたものを選択 (a)] (オプション)

    クライアント領域のコンポーネントにペーストされた最後の要素を、一次セレクションとして設定します。ニーモニックは a です。

 

 

  • [再選択 (R)] (オプション)

    クライアント領域のコンポーネントで最後に選択された要素を、一次セレクションとして設定します。このアクションは、固定選択をサポートしないコンポーネントで、現在の選択が空である場合にのみ使用できます。ニーモニックは R です。

  • [プロモート (m)] (オプション)

    クライアント領域のコンポーネントの現在の選択を、一次セレクションにします。このアクションは、固定選択をサポートするコンポーネントでのみ使用できます。ニーモニックは m です。

推奨 

bs: 

アプリケーションが <obj-type> または [選択] メニューを持っていないが、ユーザがウィンドウ内でデータを選択でき、選択データの設定を管理できる場合は、[編集] メニューの最後の項目として [属性...] という選択肢を提供する。 

[表示] メニュー

推奨 

bt: 

アプリケーションに [表示] メニューがある場合、このメニューは現在のデータの表示方法に影響を与える機能だけを含む。データそのものを変更するオプションは含まない。 

[オプション] メニュー

推奨 

bu: 

アプリケーションが、アプリケーションの動作を制御するためのグローバルな設定を持っている場合は、これらの設定を行うための [オプション] メニューを用意する。 

[ヘルプ] メニューの内容

注 -

これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。

推奨 

bv: 

アプリケーションに [ヘルプ] メニューを付ける場合、該当するアクションが実際にアプリケーションによってサポートされているならば、次に示す機能の選択肢を格納しなければならない。ここに示した [ヘルプ] の選択肢は、Motif 1.2 のものよりも優先される。 

これは共通デスクトップ環境で推奨される [ヘルプ] メニューであり、Motif 1.2 の [ヘルプ] メニューの代わりに、こちらを使用しなければなりません。項目は、次に示す順序で、ユーザに提示されなければなりません。 

  • [概要 (v)] (必須)

    ヘルプにアクセスしたウィンドウや、アプリケーション全体に関する一般情報を提供します。ニーモニックは v です。この後にセパレータを置いてください。

  • [索引 (I)] (オプション)

    アプリケーションのすべてのヘルプ情報のトピックを並べた索引を表示します。ニーモニックは I です。

  • [目次 (C)] (推奨)

    アプリケーションのすべてのヘルプ情報のトピックを並べた目次を表示します。ニーモニックは C です。

  • [使い方 (T)] (推奨)

    アプリケーションの各種の使い方を示すヘルプ情報にアクセスできます。ニーモニックは T です。

  • [リファレンス (R)] (推奨)

    リファレンス情報へのアクセスを提供します。ニーモニックは R です。

  • [チュートリアル (l)] (オプション)

    アプリケーションのチュートリアルにアクセスできます。ニーモニックは l です。

  • [キーボード (K)] (オプション)

    アプリケーションでのファンクション・キー、ニーモニック、およびキーボード・アクセラレータに関する情報を表示します。また、共通デスクトップ環境での、これらのキーの一般的な使い方に関する情報を表示します。ニーモニックは K です。

  • [マウス (M)] (オプション)

    アプリケーションでのマウスの使い方に関する情報を表示します。ニーモニックは M です。

  • [マウスとキーボードの操作 (M)] (オプション)

    アプリケーションでのファンクション・キー、ニーモニック、キーボード・アクセラレータ、およびマウスの使い方に関する情報を表示します。また、共通デスクトップ環境での、これらのキーの一般的な使い方に関する情報を表示します。ニーモニックは M です。
   

 

 

 
   

 

 

  • [アイテムヘルプ (O)] (オプション)

    ポインタをクエスチョン・マーク型ポインタに変更して、コンテキスト・ヘルプを起動します。ユーザがポインタをコンポーネント上に移動して BSelect を押すと、そのコンポーネントのすべてのコンテキスト・ヘルプが表示されます。ニーモニックは O です。

  • [ヘルプの使い方 (U)] (必須)

    共通デスクトップ環境のヘルプ機能の使い方に関する情報を表示します。ニーモニックは U です。

  • [<アプリケーション名> について (A)] (必須)

    最小限、アプリケーションの名前とバージョンを示し、アイコンやその他のシグニチャー・グラフィックスを示すダイアログ・ボックスを表示します。ニーモニックは A です。

[概要]、[ヘルプの使い方]、および [... について] 項目は必須です。[目次]、[使い方]、および [リファレンス] 項目は推奨です。[マウス] と [キーボード] のトピックは、別に用意するか、1 つにまとめて [マウスとキーボードの操作] のトピックを用意できます。この 3 つの項目を同時に使ってはなりません。 

[アタッチメント] メニューの内容

アタッチメントをサポートするアプリケーションで推奨されるメニューの詳細は、第 3 章「ドラッグ＆ドロップ」を参照してください。

ポップアップ・メニュー

注 -

これらの要件は、英語ロケールの、左から右に書かれる言語環境にのみ適用されます。他のロケールについては、適当に修正を加える必要があります。

ポップアップ・メニューは、頻繁に使用される機能へのアクセスを提供し、共通デスクトップ環境のあらゆる場所で使われます。ポップアップ・メニューは、メニュー・バーで使用可能な複数のメニューのオプションを格納できます。たとえば、[ファイル] メニューと [編集] メニューの両方の項目を格納できます。

推奨 

by: 

アプリケーションは、データ区画内で選択可能なすべての要素について、ポップアップ・メニューを提供しなければならない。 

推奨 

bx: 

アプリケーションが、データ区画に適用される機能を提供し、その中に特定の要素がない場合は、頻繁に使用されるデータ区画機能を格納するポップアップ・メニューを用意する。このポップアップ・メニューには、マウス・ポインタが区画のバックグラウンドの上にあるか、区画の中の選択不可能な要素の上にあるときに BMenu を押すとアクセスできる。 

推奨 

cb: 

アプリケーションのポップアップ・メニューの中からアクセスできる機能は、ウィンドウ内に表示されるボタンや、メニュー・バーを介してアクセスされるメニューからもアクセスできる。 

推奨 

ca: 

アプリケーションのすべてのポップアップ・メニューは、そのメニューが実行する機能や、その対象となる要素を表すタイトルを持っている。 

オプション 

cd: 

ポップアップ・メニュー内の選択肢は、次のように並べられる。 

<[開く]、[保存]、および [属性] などのように、オブジェクトを管理する選択肢> 

----------- セパレータ ----------- 

<[カット]、[コピー]、および [ペースト] などのような標準編集選択肢> 

----------- セパレータ ----------- 

<その他の選択肢> 

オプション 

6-11: 

アプリケーションが一般的なポップアップ・メニュー・アクションを使用する場合、そのアクションは次の仕様に従って機能する。補足的なガイドラインについては cb: の項を参照すること。 

  • [属性 (P)]

    ユーザがコンポーネントの属性を設定するために使用できる属性ダイアログ・ボックスを表示します。

  • [元に戻す (U)]

    最後に実行したアクションを元に戻します。

  • [一次移動 (v)]

    一次セレクションの内容をコンポーネントに移動します。このアクションは編集可能なコンポーネントでのみ使用できます。

  • [一次コピー (y)]

    一次セレクションの内容をコンポーネントにコピーします。このアクションは編集可能なコンポーネントでのみ使用できます。

  • [一次リンク (n)]

    一次セレクションへのリンクをコンポーネントに作ります。このアクションは編集可能なコンポーネントでのみ使用できます。

  • [カット (t)]

    要素をカットしてクリップボードに入れます。選択でメニューがポップアップされている場合は、選択全体をカットしてクリップボードに入れます。

  • [コピー (C)]

    要素をコピーしてクリップボードに入れます。選択でメニューがポップアップされている場合は、選択全体をコピーしてクリップボードに入れます。

  • [リンクのコピー (k)]

    要素のリンクをクリップボードにコピーします。選択でメニューがポップアップされている場合は、選択全体へのリンクをコピーしてクリップボードに入れます。

  • [ペースト (P)]

    クリップボードの内容をコンポーネントにペーストします。このアクションは編集可能なコンポーネントでのみ使用できます。

  • [リンクのペースト (L)]

    クリップボードの内容のリンクをコンポーネントにペーストします。このアクションは編集可能なコンポーネントでのみ使用できます。

  • [消去 (e)]

    クライアント領域の選択された部分のデータを、クリップボードにコピーすることなく削除します。選択でメニューがポップアップされた場合は、選択を削除します。

  • [削除 (D)]

    クライアント領域の選択された部分のデータを、クリップボードにコピーすることなく削除します。選択でメニューがポップアップされた場合は、選択を削除します。

 

 

  • [すべてを選択 (S)]

    一次セレクションを、ポップアップ・メニューの属するコレクションのすべての要素として設定します。

  • [選択をすべて解除 (l)]

    ポップアップ・メニューの属するコレクションの現在の選択を解除します。

  • [ペーストされたものを選択 (a)]

    ポップアップ・メニューの属するコレクションにペーストされた最後の要素を一次セレクションとして設定します。

  • [再選択 (R)]

    ポップアップ・メニューの属するコレクションで最後に選択された要素を一次セレクションとして設定します。このアクションは、永続的な選択をサポートしないコンポーネントで、現在の選択が空である場合にのみ使用できます。

  • [プロモート (m)]

    現在の選択を一次セレクションにプロモートします。このアクションは、永続的な選択をサポートするコンポーネントでのみ使用できます。

推奨 

cc: 

選択可能なオブジェクトのポップアップ・メニューは、該当するアクションが実際にアプリケーションによってサポートされているならば、次に示す機能を持つ選択肢を格納しなければならない。このガイドラインは 6-11 項を補足するものである。 

  • [移動先 (M)...]

    ユーザは、選択したオブジェクトをフォルダに移動できます。希望のフォルダを選択するためのファイル選択ダイアログ・ボックスが表示されます。

  • [コピー先 (C)...]

    ユーザは、選択したオブジェクトをフォルダにコピーできます。希望のフォルダを選択するためのファイル選択ダイアログ・ボックスが表示されます。

  • [ワークスペースに置く (t)]

    ユーザは選択したオブジェクトのリンクを、現在のワークスペースの共通デスクトップ環境に置くことができます。

  • [削除 (D)]

    選択されたオブジェクトを削除します。オブジェクトを実際に削除する前に、確認ダイアログ・ボックスがユーザに表示されます。

  • [ヘルプ (H)...]

    選択されたオブジェクトの型に関連するヘルプ・ウィンドウが表示されます。

必須 

6-12: 

ポップアップ・メニューが選択のコンテキストでポップアップされる場合、要素に作用するアクションは、選択全体に作用する。 

選択のコンテキストでは、ポップアップ・メニュー・アクションは選択全体に影響を与えます。 

一般的なメニューの設計規則

アプリケーション固有のメニュー区画を設計するときは、使いやすさとアクセスのしやすさを最大限にするために、次の指針に従ってください。

推奨 

ce: 

ファイル選択ダイアログが表示される場合のように、メニュー項目を選択することで、ユーザにさらに詳細な情報が求められる場合、メニュー項目の末尾には省略記号 (「...」) を付ける。この要件は、簡単な警告や確認ダイアログが表示されるだけのメニュー項目には適用されない。 

省略記号を使用することにより、ユーザはインタフェースの動作を予測しやすくなります。省略記号のない項目を選択する場合は、ただちに結果が発生すると予想できます。 

推奨 

cf: 

アプリケーションの中からアクセスされるメニューは、少なくとも 2 つのメニュー項目を含んでいなければならない。 

項目を 1 つしか含まないメニューがあってはなりません。アプリケーションに 1 項目しかないメニューがある場合は、その項目を別のメニューに移動するか、ウィンドウの中のボタンにすることを検討してください。メニューが長くなると、下の方にある選択肢にアクセスするのは、ユーザにとって面倒になります。メニューに大量の選択肢が格納されている場合は、複数のメニューに分割するか、いくつか項目をサブメニューにまとめます。 

オプション 

cg: 

アプリケーションの中からアクセスされるサブメニューは、少なくとも 3 つのメニュー項目を含んでいなければならない。 

サブメニューは、主階層メニューに全項目を入れるとメニューが長くなりすぎる場合に、似ている項目を 1 つの副階層メニューにまとめるために使用されます。しかし、サブメニューにオプションが 2 つしかない場合は、副階層メニューを削除して、オプションを主階層メニューに入れることを強く推奨します。これは、サブメニューに置かれているオプションにアクセスするには手間がかかるからです。 

オプション 

ci: 

アプリケーションに、頻繁にアクセスすることが予想されるメニューがある場合は、そのメニューにティアオフ・メニュー・オプションを用意する。 

アプリケーションの使用中にメニューを固定表示できるように、頻繁にアクセスするメニューはティアオフできるようにしておかなければなりません。 

必須 

6-14: 

アプリケーションがメニューの中でティアオフ・ボタンを使用する場合、ティアオフ・ボタンはメニューの最初の要素でなければならない。 

オプション 

cj: 

適当と思われる場合は、キーボード・アクセラレータを用意する。 

メニュー全体ではなく、メニューの特定のメニュー項目が頻繁に使用されると予想されるならば、アプリケーションはこれらの項目のキーボード・アクセラレータを用意し、そのキーボード・アクセラレータを、対応するメニューの、該当する項目の右側に表示します。すでにシステム機能に対して定義されているアクセラレータは使用してはいけません。定義済みのキー割り当てのリストについては、付録 A 「キーボードの機能」を参照してください。

推奨 

ck: 

メニュー・バーの項目に使用されるラベルは、メニューそのもののオプションとして使用してはならない。 

メニュー・バーの項目名は、メニューが格納するオプションのタイトルの役割を果たします。メニュー・バーの項目名は、すべてのメニュー項目に関連するカテゴリの概念を正確に記述するものでなければならず、メニューそのものの中の項目名として使わないようにします。 

必須 

cl: 

その時点で適切な選択ではないメニューの選択肢は、必ず選択不可になっていなければならない。 

選択不可のコントロールは、ユーザが起動できないコントロールで、アクティブでない状態が短期間しか続かない場合にのみ使用します (つまり、アプリケーションまたはデスクトップ環境の中で、そのコントロールをアクティブにするための手段が存在する場合)。コントロールが、(現在のアプリケーションまたはシステムの構成のため、またはそのメニューを使用する特定のソフトウェアがインストールされていないために) 永続的にアクティブでない場合は、コントロールを選択不可にするのではなく、メニューそのものから削除します。 

必須 

6-15: 

すべてのメニューは、最も幅の広い要素が収まるだけの幅を持っていなければならない。 

ツール・バー

ツール・バーは、アプリケーションで、他の手段によってすでにユーザがアクセス可能なものへの素早いアクセスを提供する手段です。たとえば、アプリケーションは、ツール・バーのメニューで、頻繁に使用される機能へのアクセスを提供できます。ツール・バーの一般的な用途としては、ナビゲーション、データ表示の変更、頻繁に使用されるツールやエディタへのアクセス、一般的な操作を実行するためのステップ数の削減、頻繁に使用されるメニュー項目への高速な経路の提供などがあります。

図 6-1 共通デスクトップ環境のカレンダからの例

Graphic

ツール・バーのガイドライン

必須 

fd: 

ツールバーを使用する場合は、メニュー・バーのある主ウィンドウでのみ使用する。 

必須 

fe: 

ツールバーは、すでにアプリケーション・メニューから使用できる操作しか含んでいてはならない。ツール・バーのすべての項目は、その機能を十分に表していなければならない。 

ツールバーの項目は、他の手段によってすでにアクセスが可能なものへの素早いアクセスを提供するものでなければなりません。 

必須 

ff: 

ツール・バーのアイコンが表すアクションが、ユーザからは使用できない場合、そのアイコンは網かけで表示され、選択不可になっていなければならない。メニュー項目が選択不可になったら、対応するツール・バー項目も選択不可にならなければならない。 

推奨 

fg: 

ユーザがツール・バーを隠すことができるオプションを用意する。 

ツール・バーの設計上の問題

アプリケーションと、それに付属するツール・バーを設計するときには、次の点に注意してください。

ツール・バーのコンポーネント

ツール・バーは、一般には、次の Motif コンポーネントを使って構築されます。

ツール・バーのコンテナ

ツール・バーは、ツール・バーを構成する描画ボタンの配置機能であるコンテナ・コンポーネントを使用します。ツール・バーでは、指定された動作が可能でありさえすれば、ほぼあらゆるコンテナが使用できます。

必須 

fh: 

ツール・バーのコンテナは、メニュー・バーのすぐ下に配置され、ウィンドウと同じ幅で、高さもメニュー・バーとほぼ同じでなければならない。 

推奨 

fi: 

アプリケーションでツール・バーを使用する場合は、ツール・バーと同じ主ウィンドウにステータス行を用意しなければならない。 

このステータス行は、現在マウスがその上にある、あるいはキーボード・フォーカスを持っているボタンの目的に関して、フィードバックをユーザにただちに表示します。矢印がツール・バーのアイコンの上にある場合、ステータス行は、そのアイコンが表しているもの、あるいはユーザがそのアイコンをクリックしたときに起こることについて、簡単な定義を表示します。 

推奨 

fj: 

ツール・バーのアイコンの下にラベルを付けることができる。これらのラベルは、アイコンの目的を説明するという役割を持つ。 

ツール・バーのボタン

Motif の描画ボタンは、ツール・バーのグラフィック・ボタンに適した手段です。

推奨 

fk: 

ツール・バーの描画ボタンは、幅と高さが同じでなければならない。互いに似ている、あるいは関連のある項目はグループ化し、各グループはツール・バー上で均等に配置されていなければならない。 

ピックスマップ

描画ボタンのピックスマップは、そのボタンを押すことによって期待される機能を伝えるグラフィックです。

推奨 

fl: 

ツール・バーのすべてのピックスマップは、同じサイズでなければならない。 

これにより、すべてのボタンが同じサイズになることが保証されます。 

推奨 

fm: 

ピックスマップの推奨サイズは 24*24 である。描画ボタンのデフォルトの動作は、そのラベル・タイプのサイズに従って自らサイズ変更を行うことであるが、この場合はピックスマップのサイズに合わせる。 

ウィンドウ・タイトル

主ウィンドウと副ウィンドウのタイトルを定義するときは、次のガイドラインに従ってください。

オプション 

bf: 

主ウィンドウ (アプリケーションがユーザに表示するメインのウィンドウ) のタイトルは、アプリケーション名である。 

これは、ユーザが起動する実行可能ファイルの実際の名前である必要はありません。 

主ウィンドウのタイトルが、アイコンやポップアップ・ウィンドウで使われた場合にどのようになるかという点に注意します。ポップアップ・ウィンドウの名前が長すぎる場合は、アプリケーション・タイトルを削除することもできますが、タイトルがないと、どのポップアップ・ウィンドウが元の主ウィンドウに属しているのかがわかりにくくなるということにも注意します。 

オプション 

bg: 

タイトルの各単語の先頭では大文字を使用する (大文字をサポートする言語の場合)。 

オプション 

bh: 

各属性ウィンドウでは、アプリケーション名の後に、少なくとも [属性] というタイトルと、それが影響を与えるオブジェクト名を表示する。 

オプション 

bi: 

各ポップアップ・ウィンドウのタイトルは、アプリケーション・タイトルで始め、コロンを付けてから、ポップアップ・ウィンドウのタイトルを続ける。読みやすくするために、コロンの前後にはスペースを入れる。 

ポップアップ・ウィンドウは、必ず関連する主ウィンドウ (そのポップアップを起動した主ウィンドウ) を示さなければなりません。 

オプション 

bj: 

アプリケーションが、ファイルの読み込みまたは保存を行う場合は、現在のファイル名を表すためにハイフンを使用する。ハイフンの前後にはスペースを入れる。表示するのは、パス全体ではなく、ファイルのベース名だけである。 

ハイフンは、ウィンドウまたはデータの特定のインスタンスを表すために使用します。コロンは、一般的なカテゴリやコマンドを区切る役割を果たします。たとえば、ファイル・マネージャは、[属性] ダイアログ・ボックスに次のタイトルを付けることができます。 

  • ファイル・マネージャ : 属性 - myfile

推奨 

bk: 

各コマンド・ウィンドウのアプリケーション名の後に、ユーザがそのウィンドウに表示することを選択したウィンドウ・ボタンまたはウィンドウ項目の上にあるのと同じタイトルを続ける。 

オプション 

bl: 

複数の主ウィンドウがある場合は、各ウィンドウ・タイトルの先頭にアプリケーション名を付けて、その主ウィンドウを固有に識別する名前を追加する。これらの名前には、セパレータを入れない (たとえば、[カレンダ・マネージャ・マルチブラウズ]、[カタログ検索]、[管理ツール・データベース] など)。 

オプション 

bm: 

すべてのウィンドウで同じことが行われる場合に限り、他のウィンドウではアプリケーションの省略名を使用できる。 

実行中の作業のフィードバック

推奨 

gt: 

ユーザが選択したコマンドが完了するまでにかかる時間が 2 秒よりも長く、10 秒よりも短いと予想される場合、アプリケーションは、コマンドが実行中であることをフィードバックする標準のビジー・ポインタを表示する。 

ユーザには、アプリケーションが要求を「聞き入れて」おり、その作業を実行しているという保証を与えなければなりません。要求の結果をただちに表示できない場合は、何らかのフィードバックを提供する必要があります。ビジー・カーソルは、コマンドの実行から 0.5 秒以内に表示されなければなりません。 

推奨 

gu: 

ユーザが選択したコマンドが完了するまでにかかる時間が 10 秒を超えると予想される場合、アプリケーションは、要求の処理を行なっていることを示す作業中ダイアログ・ボックスや、これに似た何らかのフィードバックを表示する。フィードバックは、そのアクションの完了に向けての経過状況を示すものでなければならない。 

あるアクションが完了するまでに長い時間 (10 秒以上) がかかると予想される場合、アプリケーションはビジー・ポインタよりも強いフィードバックを表示しなくてはなりません。ビジー・ポインタの表示時間が長くなりすぎると、ユーザはアプリケーションがハングアップしたと思うかもしれません。このような場合には、アプリケーションが実行を続けており、ユーザの要求を処理していることを示す経過表示を行います。経過表示は、アクションのどれだけの部分が完了したのか、どれだけの部分が残っているのかを表示しなければなりません。 

推奨 

gv: 

アプリケーションが実行中の作業のフィードバックをユーザに表示しているときに、デスクトップ環境の他のアプリケーションやサービスに対するアクセスを中断しない。 

マルチタスクは必ずサポートされなくてはならないので、アプリケーションは何らかのアクションを実行している間も、他のサービスへのアクセスを許可しなければなりません。可能ならば、ユーザは、アプリケーションが別の要求の処理を行なっている間も、同じアプリケーションの別の機能にアクセスできるべきです。これがサポートされている場合、アプリケーションは、ビジーではあるが、入力の受け付けは行なっていることを示す拡張ビジー・ポインタを表示します。 

一般的なアプリケーションの設計規則

必須 

ep: 

アプリケーションのウィンドウに入力フォーカスがある場合、そのウィンドウの内部に、入力フォーカスを持っているコントロールが常に 1 つだけ存在する。 

アプリケーション内のいずれかのウィンドウにフォーカスがある場合、そのウィンドウ内のコントロールのどれかがフォーカスを持たなければなりません。ユーザがウィンドウ内の特定のコントロールにフォーカスを明示的に設定しなければならないようにしてはいけません。 

オプション 

eq: 

アプリケーション内のテキスト・フィールドに入力フォーカスがない場合、そのフィールド内にテキスト・カーソルは表示されない。 

Motif のスタイルでは、アクティブでないテキスト・カーソルの使用が許可されていますが、アクティブでないテキスト・カーソルを表示するよりも、フォーカスがないテキスト・カーソルを隠す方を推奨します。これにより、ユーザは画面またはウィンドウを見ただけで、どのテキスト・フィールドがフォーカスを持っているのかを簡単に捜し出せます。 

オプション 

er: 

アプリケーションは、アプリケーション内で表示するすべてのボタン、メニュー、およびメニュー項目に対して、キーボードのニーモニックを用意する。 

アプリケーションに精通したユーザにとって、キーボードのニーモニックは各種の機能に素早くアクセスするための手段となります。また、ニーモニックは、キーボード型のアプリケーションやウィンドウで、各種の機能へのアクセスを簡単にします。マウスの使用とキーボードの使用を頻繁に切り替える必要がなくなります。ニーモニックは、ユーザ・インタフェースのあらゆる場所に用意しておくべきです。 

オプション 

es: 

アプリケーションは、ユーザが頻繁に使用すると予想される機能について、キーボード・アクセラレータを用意する。 

キーボード・アクセラレータは、アプリケーションに熟練したユーザにとっては、メニューやダイアログ・ボックスを通らずにアプリケーションの機能を素早く使うための手段となります。 

必須 

ev: 

アプリケーションが、マルチクリックのタイムアウト間隔、ドラッグのしきい値、ウィンドウのカラー設定、マウスの左利きと右利きといったグローバルな環境設定の値を使用せず、これらの設定について独自の値を使用する場合、アプリケーションはこれらの設定の値を変更するための 1 つ以上の [オプション] ダイアログ・ボックスを用意しなければならない。 

一般に、グローバルな環境設定として扱われる設定の値を無効にしてはなりません。これらの設定は、共通デスクトップ環境スタイル・マネージャを用いて、ユーザが制御します。これらの設定を無視して、独自の設定を指定した場合、アプリケーションは共通デスクトップ環境デスクトップ内の他のアプリケーションとの一貫性を失います。それにもかかわらず、独自の値を用意したい場合は、デスクトップの他の部分との一貫性を保つための手段を、ユーザに提供する必要があります。 

アプリケーションのインストール

必須 

em: 

アプリケーションは、フロントパネルやサブパネルに直接インストールするのではなく、アプリケーション・マネージャのフォルダにインストールしなければならない。一貫性を保つために、フロントパネルやサブパネルには、共通デスクトップ環境のデスクトップ・コンポーネントだけがインストールされることになっている。ユーザはフロントパネルを再編成できるが、アプリケーションはユーザの同意なしに、これを行うべきではない。 

第 7 章 一般ダイアログ

ダイアログ・ボックス (副ウィンドウ) は、ユーザとの詳細な対話を必要とするが、メイン・ウィンドウでの直接操作には適さないような操作をサポートするために使用します。たとえば、マージンの設定という作業が、ルーラ上のマージン・ストップを直接に移動することで実行できる場合は、この作業をサポートするダイアログ・ボックスは不要です。一方、ドキュメントのフォーマットという作業で、ユーザがいくつかのフォーマット・オプションを指定しなければならないような場合は、この作業をサポートするダイアログ・ボックスが必要になります。

ダイアログ・ボックスの設計と配置

オプション 

ct: 

ダイアログ・ボックスのサイズはできるだけ小さく抑える。低解像度のディスプレイでは、ダイアログで画面がいっぱいになったり、適切に設計されていなければ画面の端を越える可能性もあることに注意する。 

オプション 

cu: 

ダイアログ・ボックスを複雑にしないようにする。ダイアログ・ボックスが多数の機能をサポートしなければならない場合は、拡張可能なダイアログ・ボックス (「拡張可能なウィンドウ」を参照) を使用するか、複数のダイアログをネストさせる。

オプション 

cv: 

ダイアログ・ボックスでは、サイズ変更ハンドルを使用しないようにする。ただし、ユーザがより多くの情報を見られるという点で有用な場合は、サイズ変更ハンドルを使用してもよい。たとえば、ダイアログに、かなり長くなる可能性のあるスクロール・リストが含まれており、ユーザがそのリストを頻繁に検索しなければならないような場合。 

推奨 

cp: 

アプリケーション内で使用されるダイアログ・ボックスのタイトルは、表 10-3 の規則に従う。

必須 

cq: 

アプリケーション内のすべてのダイアログ・ボックスは、ダイアログ・ボックスのアクションを実行してダイアログ・ボックスを消去するか、何のアクションも実行せずにダイアログ・ボックスを消去するボタンを、少なくとも 1 個は持っていなければならない。 

推奨 

cr: 

アプリケーションが一般ダイアログ・ボックスのアクションを使用する場合、アクションは次に示す機能とラベルを持っている。 

 

ラベル 

機能 

 

[はい] 

ダイアログ・ボックスに表示された質問に対する肯定的な応答を示します。 

 

[いいえ] 

ダイアログ・ボックスに表示された質問に対する否定的な応答を示します。 

 

[了解] 

ダイアログ・ボックスのコンポーネントに加えられた変更をすべて適用し、ダイアログ・ボックスを消去します。 

 

<コマンド> 

ダイアログ・ボックスのコンポーネントに加えられた変更をすべて適用して、<コマンド> に関連するアクションを実行し、オプションでダイアログ・ボックスを消去します。 

 

 

<コマンド> ボタンは、そのボタンをクリックしたときに実行されるアクションに関して、ユーザに与える情報量が多い場合に、[了解]、[はい]、または [いいえ] の代わりのボタン・ラベルとして使用します。 

 

[適用] 

ダイアログ・ボックスのコンポーネントに加えられた変更をすべて適用しますが、ダイアログ・ボックスを消去しません。 

 

[再実行] 

実行中の作業を再び試みます。 

 

[中止] 

実行中の作業を、次のブレーク・ポイントで終了させます。 

 

[一時停止] 

実行中の作業を一時停止させます。 

 

[再開] 

一時停止された作業を再開させます。 

 

[デフォルトとして保存] 

現在の設定を、このウィンドウが次に表示されたときに表示されるデフォルト設定として保存します。設定は選択されたオブジェクトには適用されず、ダイアログ・ボックスは消去されません。[デフォルトとして保存] ボタンは、ユーザが、ダイアログ・ボックスの中のコントロールのセットについて、出荷時の設定として用意するのとは別のデフォルト値を使用する可能性があると予想される場合に用意しておきます。たとえば、[新規 <オブジェクト型>] ウィンドウでは、そのオブジェクト型の新規インスタンスが作成されるたびに、アプリケーションが与える値の代わりに、現在の値をデフォルト設定として表示するように指定できるように、[デフォルトとして保存] ボタンを用意しておきます。 

 

[リセット] 

アプリケーションがまだ適用していない変更内容をすべて取り消します。ダイアログ・ボックス内のコントロールは、ダイアログ・ボックス・アクションが最後に適用された時点の状態にリセットされます。ダイアログ・ボックスの現在の起動中に変更内容がまったく適用されていない場合は、コントロールはダイアログ・ボックスが表示されたときの状態にリセットされます。 

 

[出荷時設定にリセット] 

まだ適用されていない変更内容をすべて取り消します。ダイアログ・ボックス内のコンポーネントは、アプリケーションを出荷したベンダによって指定されたデフォルトの状態と値にリセットされます (つまり、コントロールは元の出荷時設定に戻されます)。 

 

[取消し] 

まだ適用されていないアクションを実行しないまま、ダイアログ・ボックスを消去します。 

 

[ヘルプ] 

ダイアログ・ボックスのヘルプを表示します。 

推奨 

cs: 

現在アクティブになっていない、あるいはその設定が現在無効になっている目に見えるコントロールは、すべて選択不可にする。 

選択不可のコントロールは、ユーザが起動できないコントロールで、アクティブでない状態が短期間しか続かない場合にのみ使用します (つまり、アプリケーションまたはデスクトップ環境の中で、そのコントロールをアクティブにするための手段が存在する場合)。コントロールが、(現在のアプリケーションまたはシステムの構成のため、またはその機能を使用する特定のソフトウェアがインストールされていないために) 永続的にアクティブでない場合は、コントロールを選択不可にするのではなく、メニューそのものから削除します。 

オプション 

cw: 

アプリケーション内のすべてのダイアログ・ボックスは、[Return] キーが押されたときに起動されるデフォルト・ボタンを、必ず 1 個だけ持つ。 

デフォルト・ボタンは、ユーザからの最も可能性の高い応答に関連付けられなければならず、破壊的あるいは取り消しできないような効果を持っていてはなりません。アプリケーションによっては、特定のフィールドのセットへの入力あるいはその他の操作が行われるまで、デフォルト・ボタンが表示されないようなダイアログ・ボックスを持つこともあります。 

オプション 

cx: 

アプリケーションが表示するダイアログ・ボックスに、拡張機能と見なされるコントロールがある場合は、拡張可能なダイアログ・ボックスを使用するか、ユーザが各ページをナビゲートできるようなオプションで [カテゴリ] メニューを提供する複数ページ・ダイアログ・ボックスを使用する。 

拡張機能に関連するコントロールは、最初に表示されるオプションのセットと一緒に表示するべきではありません。一般のユーザには、アプリケーションの基本機能を使用する上で必要なオプションだけを表示するべきです。ダイアログ・ボックス内の拡張機能へのアクセス方法を探すユーザは、[カテゴリ] オプション・ボタン (図 7-1 を参照) を使用できます。拡張機能の数が少ない場合、あるいはこれらのコントロールの設定がダイアログ・ボックス内に表示される基本コントロールの設定と密接に関連している場合 (つまり、ユーザが基本コントロールの設定を変更すると、拡張コントロールの設定も変化する場合) には、拡張可能なダイアログ・ボックスを使用することもできます (「拡張可能なウィンドウとダイアログ・ボックス」を参照してください)。

図 7-1 ダイアログで [カテゴリ] オプションを使用する例

Graphic

オプション 

dl: 

ダイアログ・ボックス内のコントロールは、ユーザがダイアログ・ボックス内で入力を行なったり、オプションを選択したりする順序に基づいて、左から右、上から下に配置する。 

これは、左から右に書かれる言語環境のために設計されるアプリケーションを前提としています。その他のロケールでは、これとは別の設計アプローチが必要になることがあります。 

必須 

dm: 

ダイアログ・ボックスの内容や配置を変更したり、ダイアログ・ボックスのアクションを起動したり、ダイアログ・ボックスを閉じたりするなどのダイアログ・ボックス全体に影響を与えるプッシュ・ボタンは、ダイアログ・ボックスの下部に置かれる。 

一般に、ダイアログ・ボックスの下部にはボタンを 1 行だけ配置するべきです。アプリケーションに、複数のグローバル・ボタンを持つダイアログ・ボックスがある場合は、ダイアログ・ボックスの下部にボタンを 2 行以上配置しなければならないことがあります。最後の行には、標準のダイアログ・ボックスのボタン ([了解]、[リセット]、[取消し]、および [ヘルプ]) を格納しなければなりません。ダイアログ・ボックス全体には関連しないが、ダイアログ・ボックス内の特定のコントロールに関連するボタンが、ダイアログ・ボックスにある場合、それらのボタンは関連するコントロールの近くに配置します。 

必須 

dn: 

アプリケーションのダイアログ・ボックス内に [適用] ボタンを用意する場合は、そのダイアログ・ボックス・アクションを実行してからダイアログ・ボックスを閉じる [了解] ボタンまたはコマンド・ボタンも用意しなければならない。 

オプション 

do: 

アプリケーションは、ダイアログ・ボックスの配置に対する悪影響のない設計の代案がまったくない場合を除き、ダイアログ・ボックス内で階層式ボタンを使用してはならない。 

一般に、階層式ボタンはメニューとメニュー・バーでのみ使用します。どうしても必要な場合を除き、他の場所では使用を避けてください。 

ダイアログ・ボックスの配置

推奨 

al: 

副ウィンドウは、アプリケーションによって、それに関連する主ウィンドウの位置を基準に配置される。副ウィンドウは、それを表示したコンポーネントと、ダイアログ・ボックスとの対話に必要な情報を隠さない程度に近い位置に配置される。 

『OSF/Motif スタイル・ガイド リリース 1.2』の 6.2.4.3 項「ダイアログ・ボックスの位置とサイズを決める」にいくつかのヒントがある。これ以外の、またはこれを修正した推奨事項も含む。

オプション 

am: 

ダイアログ・ボックスが基本ウィンドウの特定の項目に関連しない場合は、メニュー・バーの下 (メニュー・バーが存在する場合) に、作業領域に水平方向で中央を揃えて配置される。 

推奨 

an: 

関連する主ウィンドウの下に副ウィンドウを配置できる場合 (主ウィンドウの上に置くという制約がない場合)、主ウィンドウによって完全に隠されないように配置されなければならない。この推奨事項は、他の配置に関する推奨事項よりも優先される。 

推奨 

ao: 

メニューまたはダイアログ・ボックスがすでに表示されている場合、その表示を引き起こしたコマンドを再起動すると、そのウィンドウまたはメニューが、画面上の位置を変更せずに、ウィンドウの重なりの一番手前に自動的に表示される。 

ダイアログ・ボックスでの対話

アプリケーション一般に適用されるすべてのナビゲーションと選択に関するガイドラインが、ダイアログにも適用されます。さらに、アプリケーション固有のダイアログ・ボックスを設計する際には、使いやすさとアクセスしやすさを最大限に高めるために、次の指針に従わなければなりません。

必須 

en: 

アプリケーションがダイアログ・ボックスを表示するとき、入力フォーカスは、ユーザがエントリを入力できる最初のテキスト・フィールドか、ユーザがそれを用いて対話するダイアログ・ボックス内の最初のコントロールに置かれる。 

入力フォーカスは、必ず予測しやすく、わかりやすい位置に置かれなくてはなりません。ウィンドウが表示されたときに、ユーザが特定の使われる頻度の高いコントロールにフォーカスを設定しなければならないようではなりません。 

推奨 

eo: 

ユーザがアプリケーションのダイアログ・ボックスの中で [Tab] キーを押すと、入力フォーカスは、ウィンドウ内の各種のコントロールを、左から右、上から下への順序で移動する。 

これは、左から右に書かれる言語環境のために設計されるアプリケーションを前提としています。その他のロケールでは、これとは別の設計アプローチが必要になることがあります。 

必須 

et: 

アプリケーションが表示するダイアログ・ボックスは、デスクトップ内の他のアプリケーションへの入力を妨げてはならない (つまりシステム・モード付きであってはならない)。ただし、ユーザがそのダイアログ・ボックスに応答するまで、ユーザがデスクトップ内の他のアクションを実行できないようにすることがどうしても必要な場合を除く。 

アプリケーションは、ユーザのデスクトップ環境内の情報やツールに対して、ユーザが自由にアクセスできることを保証しなければなりません。アプリケーションが環境内の他のアプリケーションやサービスへのアクセスを妨げてもよいのは、どうしても必要な場合に限られます。 

必須 

eu: 

アプリケーションが表示するダイアログ・ボックスは、アプリケーション内の他の機能へのアクセスを妨げてはならない (つまりアプリケーション・モード付きであってはならない)。ただし、ユーザがダイアログ・ボックスに応答するまで、アプリケーションの状態が変化しないことがどうしても重要な場合を除く。 

必須 

6-18: 

警告ダイアログ・ボックスの発している警告の原因である破壊的なアクションは、警告ダイアログでユーザが取り消すことができる。 

拡張可能なウィンドウとダイアログ・ボックス

この節では、共通デスクトップ環境で拡張可能なウィンドウまたはダイアログを提供するための標準的な方法について説明します。拡張可能なウィンドウにより、ユーザは、ウィンドウが最初に表示された時点では通常は表示されない、ウィンドウの独立した部分にある拡張機能、あるいはアプリケーション固有の機能を選択的に表示できます。ユーザは、自分のニーズと好みに応じて、ウィンドウ全体を表示したり、中核機能だけを表示したりできます。アプリケーションは、既存のツールキット・コンポーネントを使用して、拡張可能なウィンドウを簡単に実装できます。

拡張可能なウィンドウは、アプリケーションが限られた数の追加のダイアログ・ボックス・オプションを表示する必要がある場合にのみ使用します。ダイアログが、たとえば典型的な低解像度ディスプレイが表示できないほど大きくなる場合は、別の方法を考えてください。また、ダイアログが他の言語に翻訳されたときにサイズが大きくなることにも注意してください。拡張可能なダイアログの代案としては、複数ページ・ダイアログを使用して、ページの切り替えを行う [カテゴリ] ボタンを用意するという方法があります。

拡張可能なウィンドウとダイアログ・ボックスのガイドライン

推奨 

fn: 

ダイアログ・ボックスまたはウィンドウの主区画は、作業の完了に必要なすべてのコントロールを含んでいなければならない。これには、重要な機能と頻繁に使用される機能のすべてが含まれる。 

推奨 

fo: 

めったに使用されない機能は副区画に配置する。アプリケーションの中核機能は、副区画に置かれているコントロールに依存していてはならない。 

必須 

fp: 

コマンド・ボタンは、ダイアログ・ボックスの下部に配置される。ウィンドウが拡張されて、副区画が表示されたとき、ボタンは副区画の下部に移動される。ダイアログ・ボックスにおけるアクション・ボタンの配置については、第 6 章「アプリケーション設計の原理」を参照すること。

推奨 

fq: 

重要なコントロールを副区画に置かなければならない場合、アプリケーションは、対象のウィンドウがデフォルトで拡張された状態で表示されるかどうかを指定できる。この場合でも、ユーザは [縮小] ボタンを押してウィンドウを縮小できなければならない。 

拡張可能なウィンドウのコンポーネント

拡張可能なウィンドウまたはダイアログ・ボックスを作成するには、標準の Motif ウィジェットを、状態変数や、その動作を支配するいくつかの単純な規則と組み合わせて使用します。ウィンドウそのものの内容を構成するアプリケーション定義のコントロールと表示に加えて、次のように主区画と副区画を使用します。

主区画と副区画

主区画は、アプリケーションのほぼすべてのエンド・ユーザが必要とする中核機能、あるいは基本機能を含んでいなければなりません。主区画は、ウィンドウまたはダイアログのメイン・コンポーネントである標準の Motif コンテナです。拡張可能なウィンドウが最初に表示された時点では、主区画だけが表示されています。ユーザは、[拡張] ボタンを使用することで、ウィンドウまたはダイアログのすべての機能へのアクセスを提供する副区画を表示できます (図 7-2 を参照)。

図 7-2 [追加設定の表示] 拡張ボタン時のカレンダの [アポイントエディタ] の主区画

Graphic

副区画の拡張

副区画は、他のオプションや拡張機能のためのスペースを提供し、主区画の中核機能の難易度を高めないようにするという役割を果たします。副区画は縦または横に拡張されます。拡張の方向を決定する際には、次の点を検討してください。

推奨 

fr: 

副区画は、ユーザの予想、表示される言語における文字の読み方、および表示される情報の内容との一貫性が最も高い方向に拡張されなければならない。 

推奨 

fs: 

可能ならば、区画のデフォルトの幅は同一であるべきである。 

必須 

ft: 

主区画を副区画から区切るためのセパレータを使用する。 

どの要素が主区画に属しており、どの要素が拡張可能なウィンドウの副区画に属しているのかという点について、明確な視覚的フィードバックをユーザに与える必要があります。 

拡張されたウィンドウまたはダイアログのサイズの変更

必須 

fu: 

ウィンドウのサイズが変更可能な場合、サイズの変更は、表示されている長さが格納されている長さよりも小さいようなスクロール・リストまたはテキスト・フィールドを含んでいる区画に割り当てられなければならない。両方の区画がスクロール可能なコントロールを含んでいる場合、サイズの変更は 2 つの区画の間で均等に割り当てられる。どちらの区画もスクロール可能なコントロールを含んでいない場合、ウィンドウはサイズ変更が不可能であるべきである。 

図 7-3 [追加設定の非表示] 拡張ボタン時のカレンダの [アポイントエディタ] の主区画と副区画

Graphic

拡張ボタン

拡張ボタンは副区画の表示に使用されます。拡張ボタンは、ウィンドウの状態に応じて変化するラベルを持つ、Motif の標準の描画ボタンです。2 つの状態のボタン・ラベルは、ユーザに何が起こるのかを通知する内容でなければなりません。たとえば、ウィンドウを閉じているときは [オプション]、開いているときは [基本] というラベルを付けます。[オプション] をクリックすると下部の区画が表示されます。[基本] ボタンをクリックすると、下部の区画が隠されます。ラベルは [拡張] と [縮小]、[拡大] と [縮小]、[基本] と [オプション] のように、対照的な内容でなければなりません。

必須 

fv: 

拡張可能なウィンドウは、ウィンドウの状態に応じてラベルが変化するボタンを 1 個持っていなければならない。 

必須 

fw: 

拡張ボタンは、拡張可能なウィンドウの 2 つの状態を正確に反映する 2 つのラベルを持っていなければならない。現在のラベルは、ユーザがボタンをクリックしたときに何が起こるのかを、ユーザに通知するものでなければならない。 

ラベルの例としては、[基本] と [オプション]、[拡張] と [縮小]、[追加設定の表示] と [追加設定の非表示] などが考えられます。 

オプション 

fx: 

拡張ボタンは、ラベルに加えてグラフィックを含むことがある。このグラフィックは、ウィンドウが拡張または縮小する方向を示す。 

拡張ボタンの配置

推奨 

fy: 

ボタンは、縦方向の拡張の場合には、ウィンドウまたはダイアログ・ボックスの左下隅に、横方向の拡張の場合には右下隅に表れる。 

必須 

fz: 

ウィンドウまたはダイアログ・ボックスが、区画の右端に置かれたスクロール・リストを含んでいる場合は、描画ボタンをスクロール・バーと揃えて配置しないようにする。たとえば、ボタンはスクロール・バーではなく、リストに揃えて配置する。 

ウィンドウの状態

必須 

ga: 

アプリケーションは、個々のウィンドウまたはダイアログ・ボックスの状態 (拡張されているかどうか) を個別に (まとめてではなく) 記憶しておく必要がある。状態はユーザによってのみ変更され、ユーザが明示的に変更するまでは必ず保存されていなければならない。 

推奨 

gb: 

アプリケーションが実行されるたびに、ユーザが拡張可能なウィンドウを手動で構成しなくて済むように、アプリケーションは個々の拡張可能なウィンドウまたはダイアログ・ボックスの状態を、セッション間でも記憶しておくべきである。 

アプリケーションは、ユーザが拡張可能なウィンドウの状態を、アプリケーションに対してグローバルな形で設定できるような機能を提供することもできます。これはアプリケーションの [オプション] の一部として用意することになります。 

ファイル選択ダイアログ・ボックス

共通デスクトップ環境のファイル選択ダイアログ・ボックスは、有用性を向上するために改善された Motif のファイル選択ダイアログ・ボックスのサブクラスです。アプリケーションが標準の Motif のファイル選択ダイアログ・ボックス呼び出しを使用している限り、共通デスクトップ環境では共通デスクトップ環境の拡張バージョンが表示されます。ダイアログに一貫性を持たせ、使い勝手を向上させることを目的としたガイドラインが、これ以外にもあります。アプリケーションがファイルまたはディレクトリの選択に関連する作業をサポートしている場合は、ファイル選択ダイアログ・ボックスを使用するようにします。例としては [開く]、[取込み]、[別名保存]、[コピー先] などがあります。

内容

必須 

7-10: 

アプリケーションがファイル選択ダイアログ・ボックスを使用している場合は、次のコンポーネントが含まれる。 

  • 現在のディレクトリ・パスを示すディレクトリ・テキスト・コンポーネント。ユーザはディレクトリ・テキスト・コンポーネントを編集して [Return] キーまたは [Enter] キーを押すことにより、現在のディレクトリを変更できます。

  • コマンド・ボタン、[更新]、[取消し]、および [ヘルプ] ボタンを含むプッシュ・ボタンのグループ。コマンド・ボタンのラベルは一般に [開く] または [保存] ですが、結果として生じるアクションをより適切に記述するラベルがあれば (たとえば [取込み] など)、そのラベルを使用します。コマンド・ボタンを起動することにより、対応するアクションが実行され、ファイル選択ダイアログ・ボックスが消去されます。

  • 別のフォーマットでの保存ができるアプリケーションでは、ユーザがファイルの保存時にフォーマットを指定するためのオプション・ボタン。

  • ファイル名の表示と編集のためのファイル名テキスト・コンポーネント。このコンポーネントは、ファイル選択ダイアログ・ボックスが既存のファイルまたはディレクトリの選択に使用される場合はオプションです。

図 7-4 [開く] ファイル選択ダイアログ・ボックスの例

Graphic

必須 

7-17: 

ファイル選択ボックスは、初期化されたとき、ユーザがディレクトリ・テキスト・コンポーネントで [Enter] または [Return] キーを押したとき、およびユーザが内容リストの中でディレクトリを開いたときに、内容リストにディレクトリの内容を表示する。内容リストはディレクトリの内容が変化するたびに更新される。 

この仕様は、ファイル選択ダイアログ・ボックスにおけるディレクトリとファイルの検索操作に一貫性を持たせる役割を持っています。 

オプション 

ht: 

ディレクトリおよびファイル名のリストは、アルファベット順に、大文字と小文字を区別せずに表示する。ディレクトリ・リストの最初の項目は親ディレクトリで、「..」 というラベルになっていなければならない。 

推奨 

de: 

ファイル選択ダイアログ・ボックスは、ユーザにとって必要でない限り、隠し (ドット) ディレクトリやファイルを表示してはならない。アプリケーションが隠しファイルの表示をサポートしている場合は、隠しファイルの表示と非表示をユーザが切り替えるためのチェック・ボックスを用意するか、アプリケーション内のグローバルなレベルでファイルの表示と非表示を切り替えられるようにしなければならない。 

推奨 

df: 

ファイル選択ダイアログ・ボックスは、ディレクトリ・テキスト・フィールドを除いて、ファイルやディレクトリの完全パス名を表示するべきではなく、相対名だけを表示するべきである。 

グローバルな共通デスクトップ環境設定は、次のようになっているはずです。 

XmFileSelectionBox.fullPathMode: false

アプリケーションがこの動作を無効にしない限り、ファイル選択ダイアログ・ボックスはリスト・ボックスで完全パス名を表示するべきではありません。 

必須 

dg: 

一般に、ファイル選択ダイアログ・ボックスは、以前にユーザが設定したディレクトリ位置を記憶しておくべきである。 

たとえば、ユーザが [別名保存] を呼び出して、/users/jay/letters に移動してファイルを保存した場合、次にユーザが [別名保存] を呼び出したときには、ファイル選択ダイアログ・ボックスはディレクトリ /users/jay/letters にいるべきです。ただし、ユーザがいったん主ウィンドウを閉じたら、この情報は記憶していてはならず、デフォルト・ディレクトリに戻さなければなりません。

アプリケーションが複数の主ウィンドウをサポートしている場合は、各ウィンドウが、そのウィンドウに対して設定されたディレクトリ位置を記憶していなければなりません。 

ファイル選択ダイアログ・ボックスの動作

オプション 

hq: 

ファイル選択ダイアログ・ボックスは、その作業にとって意味のあるディレクトリで起動されなければならない。たとえば、新規ファイルをエディタから保存する場合、ファイル選択ダイアログ・ボックスはユーザのホーム・ディレクトリで起動されるべきである。ユーザがファイル選択ボックスの中で別のディレクトリにナビゲートした場合、アプリケーションは次に起動されたときに、そのディレクトリを記憶しておくべきである。 

オプション 

hr: 

ユーザがファイル選択ボックスを通して既存のファイルを上書きするときは、必ず警告ダイアログ・ボックスのプロンプトを表示する。 

オプション 

hs: 

キーボード・フォーカスは、ユーザがファイル選択ダイアログ・ボックスを呼び出すたびに、ファイル名フィールドに置かれるべきである。 

ラベル

オプション 

hu: 

ラベルは明確なものでなければならない。英語の場合、ファイル選択ダイアログ・ボックスのフィールドとリストについては、次のラベルを使用する。 

 

 

コンポーネント 

ラベル 

 

 

ディレクトリ・テキスト・フィールド 

パス名またはフォルダ名を入力してください : 

 

 

フィルタ・テキスト・フィールド 

フィルタ 

 

 

ディレクトリ・リスト 

フォルダ 

 

 

内容リスト 

ファイル 

 

 

ファイル・テキスト・フィールド 

ファイル名を入力してください :* 

オプション 

hv: 

オプションとして、アプリケーション開発者は、[開く] ダイアログ・ボックスの場合は [開くファイル名を入力してください] のように、このラベルをよりわかりやすくて具体的なものに変更することもできる。 (特有な推奨事項は、以下の節を参照してください。) 

これらのラベルはデフォルトのラベルでなくてはなりません。これらがデフォルトで設定されていない場合は、アプリケーションの app-defaults ファイルのリソースを使用して設定する必要があります。 

推奨 

he: 

ファイル選択ボックスが既存のファイルを指定するために使用されている場合 (たとえばドキュメントを開くため)、通常、コマンド・ボタンには [開く] というラベルが付けられ、これがデフォルトのアクションであるべきである。 

必須 

hj: 

ファイル選択ダイアログ・ボックスが新規ファイル名を指定するために使用されている場合 (たとえば [別名保存] ダイアログ・ボックス)、通常、コマンド・ボタンには [保存] というラベルが付けられ、これがデフォルトのアクションであるべきである。この仕様により、ファイル選択ボックスの外見が、どのアプリケーションでも同じになることが保証される。 

ボタンの起動

推奨 

hf: 

内容リストでディレクトリが選択されているときに、[更新] ボタンが起動された場合、ディレクトリが開かれ、その内容が内容リストに表示され、ディレクトリ・テキストが更新される。 

必須 

hg: 

内容リストの中で適切なファイルが選択されているときに、[開く] ボタンが起動された場合、ファイルはアプリケーションに利用され、ファイル選択ボックスは閉じる。 

選択とナビゲーション

必須 

7-12: 

内容リストの中の項目の上で BSelect をダブルクリックすると、その項目が選択され、デフォルトのアクションが起動される。いずれの場合も、内容リストの中のディレクトリの上で BSelect をダブルクリックすると、そのディレクトリが開かれ、その内容が内容リストに表示される (デフォルトのアクションは [開く] である)。 

  • ファイル選択ダイアログ・ボックスが既存のファイルの選択に使用される場合、内容リストの中の適切なファイルの上で BSelect をダブルクリックすると、そのファイルが選択され、ファイル選択ダイアログ・ボックスは終了します (デフォルトのアクションは [開く] です)。

  • ファイル選択ダイアログ・ボックスが、既存のディレクトリを選択するため、または新しいディレクトリやファイルを指定するために使用される場合、ファイル・リストは表示されるべきではありません。

必須 

7-13: 

テキスト・コンポーネントの中では、各テキスト・コンポーネントの中でカーソルを移動したり、テキストの内容を変更するための通常のテキスト・ナビゲーション機能と編集機能が使用できる。 

これらのアクションは、フォーカスがテキスト・コンポーネントにあるときに、対応するリストからディレクトリ名またはファイル名を選択するための便利な手段となります。 

オプション 

7-15: 

アプリケーションは、ファイル名のリストをスクロールさせて希望のファイルを選択するか、ファイル名をファイル選択テキスト・コンポーネントに直接入力することによって、ファイルが選択できるようにしなければならない。リストからファイルを選択すると、そのファイル名がファイル選択テキスト領域に表示される。 

このファイル選択の方法は、どのアプリケーションでも一貫性のあるものでなければなりません。 

必須 

7-16: 

アプリケーションは、次のいずれかが起こったときに、選択された項目を使用する。 

  • 内容リストで適切な項目が選択されているときに、ユーザがコマンド・プッシュ・ボタンを起動した。

  • ユーザが内容リストの適切なファイルの上で BSelect をダブルクリックした。

  • ファイル名テキスト・コンポーネントがキーボード・フォーカスを持っており、適切な項目を含んでいるときに、ユーザが [Return] または [Enter] キーを押した。

ファイル選択ダイアログ・ボックスの具体的な使用方法に関するガイドライン

次のガイドラインは、ファイル選択ボックスの具体的な使用方法に適用されます。これらのガイドラインには、より一般的なガイドラインとともに従わなければなりません。

[開く] ダイアログ

必須 

hm: 

ユーザがファイル名引き数を指定せずにアプリケーションを開いた場合、[開く] ダイアログ・ボックスはデフォルト・ディレクトリとしてユーザのホーム・ディレクトリを使用する。 

この規則の例外は、明らかにより有用なディレクトリがある場合です。たとえば、アイコン・エディタのデフォルト・ディレクトリは $HOME/.dt/icons になるでしょう。編集ができるアプリケーションでは、/usr/dt/bin のように、ユーザが読み取り権または書き込み権を持たないようなディレクトリをデフォルト・ディレクトリとしてはなりません。

必須 

hn: 

ユーザがファイル名引き数を指定してアプリケーションを開いた場合、[開く] ダイアログ・ボックスはデフォルト・ディレクトリとして、そのファイルが置かれているディレクトリを使用する。 

[別名保存] ダイアログ

オプション 

ho: 

ファイル選択ダイアログ・ボックスに [別名保存] の機能を持たせる場合は、「タイトルなし」というデフォルト名を与え、位置カーソルをファイル名フィールドに置いて、ファイル名テキストを強調表示し、「削除保留入力」モードにする。現在のディレクトリに、その名前のファイルがすでに存在する場合は、「タイトルなし 2」のような名前を作成する。 

オプション 

hp: 

ファイル選択ダイアログ・ボックスに [別名保存] の機能を持たせる場合は、アプリケーションが拡張子によるファイル・タイプの区別をサポートしているならばファイル名拡張子を追加し、この拡張子をファイル名フィールドに表示する。拡張子を強調表示して「削除保留入力」モードにすることはせず、ユーザが拡張子を変更するか、明示的に削除できるようにする。 

[別名保存] を使ってファイルを保存した後、アプリケーションは新しく保存されたファイルを現在のファイルとして使用します。それ以降の編集や保存は、すべて、この新しく作成されたファイルに適用されます。 

[別名保存] ダイアログは、現在のファイルが存在するのと同じディレクトリを使用します。 

[ディレクトリ選択] ダイアログ

推奨 

hh: 

ファイル選択ダイアログ・ボックスが既存のディレクトリの選択に使用される場合 (たとえば、ファイルのセットを選択されたディレクトリにインストールする場合など) や、新しいディレクトリを指定するのに使用される場合、コマンド・ボタンには [インストール]、[選択]、[作成]、[了解] などの適切なラベルを付けるべきである。内容リストで適切なディレクトリが選択されているときに、このボタンが起動された場合、ディレクトリはアプリケーションに利用されファイル選択ボックスは閉じる。 

必須 

hi: 

ファイル選択ダイアログ・ボックスが既存のディレクトリの選択に使用される場合は、内容リストでディレクトリが選択されると有効になり、そのディレクトリを開くという機能を持っている [更新] というラベルの付いたボタンがさらに存在していなければならない。[更新] ボタンはデフォルトのアクションである。 

オプション 

hk: 

ファイル選択ダイアログ・ボックスが既存のディレクトリの選択に使用される場合、ファイルは内容リストに表示されるが、すべて使用不可能になっている。使用不可能なファイル名の上で BSelect をダブルクリックしても、何の効果もない。 

[印刷] ダイアログ・ボックス

次に、印刷アクションが可能な場所で使用される印刷ダイアログ・ボックスの共通した外観と操作性を実現するためのガイドラインを示します。印刷ダイアログはウィジェットではありません。開発者は、これらのガイドラインを出発点として使用し、アプリケーションに応じて機能を追加していくことをお勧めします。ただし、ユーザが印刷ダイアログの間での一貫性を期待していることを忘れてはなりません。したがって、共通領域はできるだけ変更しないでおくべきです。ユーザがファイル、選択、あるいはその他のオブジェクトの印刷のためのオプションを選択する場面では、必ず印刷ダイアログ・ボックスを使用してください。アプリケーションが印刷をサポートする場合は、印刷ダイアログ・ボックスを使用するべきであり、オプションとして「暗黙」の印刷方法として、直接に印刷を行うための非ダイアログ的な手段を用意することもできます。

アプリケーションのための標準的な [印刷] メニューの項目

[印刷...]: ユーザが、選択されたオブジェクトを印刷する前に、使用可能なオプションから選択できるようにするための印刷ダイアログを表示します。

[印刷]: 事前にユーザが定義したデフォルトの印刷方法を使用して、選択されたオブジェクトを 1 部印刷します。ユーザにダイアログを通しての情報の入力は求めません。

一般的な [印刷] ダイアログの機能のためのガイドライン

アプリケーションは、さまざまなタイプの印刷機能や印刷能力を提供することが期待されています。この節では、各種の項目の概念と動作がアプリケーション間で一貫性のあるものになるように、最もよく使用されるタイプの印刷オプションのガイドラインを示します。これらの一般的な項目は、[印刷] ダイアログの上部にある共通領域にまとめられます。図 7-5 に、典型的な [印刷] ダイアログを示します。共通領域は、セパレータ線の上の領域です。

図 7-5 基本的な [印刷] ダイアログ・ボックス

Graphic

共通領域は次のコンポーネントを含んでいます。

印刷ダイアログは、次の標準ボタンを含みます。

アプリケーション固有の [印刷] ダイアログ・ボックス機能のガイドライン

標準の [印刷] ダイアログのアプリケーション固有領域は、図 7-6 に示す、ダイアログ・ボックスの下半分です。

アプリケーションまたは機能に応じて、開発者は共通の [印刷] ダイアログにフィールドを追加できます。ダイアログの中のコントロールは横向きに配置されます。フィールドを追加する必要がある場合は、図に示すようにセパレータ線を追加して、その下にコントロールを追加します。プッシュ・ボタンがさらに必要な場合は、[印刷] ボタンと [取消し] ボタンの間に置きます。

オプションのフィールド

オプションのフィールドとして、次のようなものが考えられます。

[ページ番号の印刷]

このチェックボックスは、テキスト・ファイルの印刷のみに適用されます。印刷対象として選択されたオブジェクトがテキストではない場合は、このコントロールは選択不可にします。オンになっていると、出力ページにページ番号が付けられます。

[印刷コマンドオプション]

ユーザが lp コマンドやスクリプト名を入力して、他のフィールドでの命令を無効にするためのテキスト・フィールド。lp 以外の印刷方法を使用する場合は、このフィールド名を変更します ([印刷方法]、[印刷コマンドの使用] など)。

[優先順位]

これは、[高]、[中]、および [低] という値を含んでいるオプション・メニューか、数値を含んでいるスピン・ボックスです。

[方向]

[ポートレート] と [ランドスケープ] という値を含んでいるオプション・メニュー (図 7-6 を参照)。

[解像度]

dpi 単位の数値を含んでいるオプション・メニューまたはスピン・ボックス (図 7-6 を参照)。

[印刷面]

[片面] と [両面] という値を含んでいるオプション・メニュー (図 7-6 を参照)。

[用紙サイズ]

[レター]、[リーガル] などの値を含んでいるオプション・メニュー (図 7-6 を参照)。

[用紙トレイ]

[上トレイ]、[下トレイ] などの値を含んでいるオプション・メニュー (図 7-6 を参照)。

ダイアログ・ボックスをアプリケーションで使用する場合は、次のフィールドを考慮に入れます。

[ページ範囲]

印刷する範囲を示す 2 つのテキスト・フィールド (図 7-7 を参照)。

[縮小/拡大]

比率の値を含むスピン・ボックス (図 7-7 を参照)。

[印刷プレビュー]

出力の WYSIWYG (見た目そのまま) 表示を呼び出すボタン。

いくつかの配置のサンプル

図 7-6 と、図 7-7 に、[印刷] ダイアログ・ボックスの配置の例を示します。

図 7-6 一般的な印刷のための [印刷] ダイアログ・ボックスの配置例

Graphic

図 7-7 アプリケーションからの印刷のための [印刷] ダイアログ・ボックスの配置例

Graphic

[属性] ダイアログ

アプリケーションに、アプリケーションの動作やオブジェクトの特性を制御する設定がある場合は、[属性] ダイアログを使用します。

ガイドライン

推奨 

cz: 

アプリケーションがオブジェクトを管理しており、ユーザがこれらのオブジェクトの設定の確認や変更ができるようになっている場合、これらの設定は、[編集]、<obj-type> あるいは [選択] メニューの [属性...] 項目や、そのオブジェクトに関連付けられているポップアップ・メニューからアクセスできるオブジェクト属性ウィンドウに表示される。 

推奨 

da: 

アプリケーションが属性ウィンドウやオプション・ウィンドウへのアクセスを提供している場合、このウィンドウには、アプリケーションがサポートしているならば、次に示す機能を持つボタンのセットが、この順序で含まれている。 

 

 

[了解] 

ダイアログ・ボックスでコンポーネントに対して加えられた変更を適用し、ダイアログ・ボックスを消去します。[了解] は、より適切なラベル (たとえば [追加] など) に置き換えてもかまいません。代わりのラベルは動詞句でなければなりません。 

 

 

[適用] 

ダイアログ・ボックスでコンポーネントに対して加えられた変更を適用しますが、ダイアログ・ボックスは消去しません。 

 

 

[リセット] 

アプリケーションがまだ適用されていない変更内容をすべて取り消します。ダイアログ・ボックス内のコントロールは、ダイアログ・ボックスのアクションが最後に適用された時点での状態にリセットされます。現在起動中のダイアログ・ボックスで変更内容がまったく適用されていない場合は、コントロールはダイアログ・ボックスが表示されたときの状態にリセットされます。 

 

 

[出荷時設定にリセット] 

まだ適用されていない変更内容をすべて取り消します。ダイアログ・ボックス内のコンポーネントは、アプリケーションを出荷したベンダによって指定されたデフォルトの状態と値にリセットされます (つまり、コントロールは元の出荷時設定に戻されます)。 

 

 

[取消し] 

まだ適用されていないアクションを実行しないまま、ダイアログ・ボックスを消去します。 

 

 

[ヘルプ] 

ダイアログ・ボックスのヘルプを表示します。 

推奨 

db: 

アプリケーションが、選択されたオブジェクトの設定を表示する属性ウィンドウを提供する場合、その属性ウィンドウは現在の選択を追跡し、現在選択されているオブジェクトの属性が正確に反映されるように、コントロールの状態を変更する。 

[...について] ダイアログ・ボックス

[...について] ダイアログ・ボックスは、アプリケーションの現行バージョンやその他の情報を表示するために使用されます。ユーザが [ヘルプ] メニューから [<アプリケーション名> について] を選択したときに表示されるダイアログとして使用します。

ガイドライン

[...について] ダイアログ・ボックスは、1 つのテキスト区画に表示されるアプリケーションに関して、最小限の情報のセットを含んでいなければなりません。

最小限のセットとは、次の内容です。

必須 

di: 

[...について] ダイアログ・ボックスは [閉じる] ボタンを含んでいなければならない。その他の [ヘルプ] や [続き] などのボタンはオプションである。 

[について] ボックスには次の情報も入れることができます。

推奨 

dj: 

アプリケーションの実行に必要なオペレーティング・システムやその他の条件に関する情報。共通デスクトップ環境 1.0 など。 

オプション 

dk: 

開発チームのクレジット、ライセンス、クライアント、または xhost 情報などの追加情報を表示する [詳細情報] ダイアログ・ボックス。 

図 7-8 [...について] ダイアログ・ボックスの例

Graphic

図 7-9 [続き] ボタンを持つ [...について] ダイアログ・ボックス

Graphic

第 8 章 アプリケーション・メッセージ

アプリケーションは、実行中のアクションの経過状況を通知したり、ユーザの介入が必要な状況について警告するために、ユーザにフィードバックを与えなければならないことがあります。共通デスクトップ環境の Motif インタフェースでは、このようなフィードバックをユーザに与えるための手段がいくつも用意されています。この章では、エラー・メッセージ、情報メッセージ、およびその他のメッセージ・ダイアログ・ボックスの使い方について説明します。

エラー・メッセージと情報メッセージ

エラー・メッセージと情報メッセージは、さまざまな状況で利用されます。目的とするアクションが、ユーザが介入しないと実行できないために、どうしてもユーザに情報を伝えなければならない場合は、エラー・メッセージを表示します。経過状況を説明したり、短期的なステータスを表示したり、有用なヒントを伝えたりする場合は、情報メッセージを表示します。情報メッセージは、親切で、作業の流れを妨げないものでなければなりません。このため、開発者は、ユーザが情報メッセージに気付かない可能性があることを想定しておく必要があります。ユーザに特定の情報を認識させることが重要な場合は、エラー・ダイアログ・ボックスや、その他のタイプのメッセージ・ダイアログ・ボックスに表示するようにします。

エラー・メッセージ

操作が完了するためにユーザの介入が必要な場合に、ユーザに重要なメッセージを表示するときはエラー・メッセージを使用します。エラー・メッセージは、問題に対するユーザの注意を引き、ユーザが問題を解決するのを助けるという目的を持っています。

エラー・メッセージのガイドライン

アプリケーションのエラー・メッセージの表示には、Motif エラー・ダイアログ・ボックスを使用します。図 8-1 に、典型的なエラー・ダイアログ・ボックスを示します。エラー・メッセージの基本的な 3 部構成を念頭に置いてください。各メッセージは、可能な限り、次の情報をユーザに伝えなければなりません。

図 8-1 エラー・ダイアログ・ボックス

Graphic

上記のテキストは、エラーの内容と、それが生じた理由を説明し、操作の再実行を勧めています。右下にある [ヘルプ] ボタンは、適切なオンライン・ドキュメントを表示します。

推奨 

gd: 

アプリケーションが表示するエラー・メッセージは、エラーの考えうる原因を示し、ユーザがそれに応じて取ることができるアクションを示す。 

エラー・ダイアログの情報は、明確で簡潔なものにしてください。目的は、問題についてユーザに警告を発し、ユーザが問題を迅速に理解し、そこからの回復方法を認識できるようにすることです。大量のテキストがあると、ユーザは重要な情報に注意を集中しづらくなります。 

推奨 

gc: 

アプリケーションが表示するメッセージは、ユーザがコンピュータ・システム一般や、UNIX システムに関する専門的な知識を持っていることを想定したものであってはならない。 

ユーザが、ファイルやプログラムなど、デスクトップ内で使用する標準的な用語に関する知識を持っていることは想定してもかまいません。ユーザは、このような知識を、チュートリアル、オンライン・ヘルプ、およびユーザ・マニュアルから得ていると考えられます。しかし、専門家や上級者のコンピュータ・ユーザしか理解できないような用語は、コンピュータの専門家をターゲットとしているアプリケーション以外では避けるべきです。同じように、基本のオペレーティング・システムによってアプリケーションに返されるメッセージは、そのままユーザに渡すのではなく、初心者のユーザでも理解できるような言葉に「翻訳」しなければなりません。

エラー・メッセージは、その場の状況に即した、できるだけ有用な内容にするようにします。たとえば、ユーザが無効な名前を入力した場合、エラー・メッセージは、単に無効な名前が入力されたということを述べるだけでは不十分です。その代わりに、どの文字が無効だったのかをユーザに知らせます。有効な名前かどうかを決める規則が単純な場合は、エラー・メッセージの中で説明してください。単純ではない場合は、規則をオンライン・ヘルプに記述し、[ヘルプ] ボタンからアクセスできるようにします。

多くの場合、エラー・ダイアログ・ボックスに対するユーザの反応は、[了解] ボタンをクリックして、ダイアログ・ボックスを消去するというものだけになります。ただし、ユーザのために問題を解決してあげることが可能な場合もあります。ユーザ・アクションのためのボタンを作成する場合は、[取消し] ボタンも用意することを忘れてはなりません。

オプション 

ge: 

アプリケーションは、エラーの条件やイベントを通知するために、表示されるメッセージに加えて、音声でのフィードバックも使用するべきである。 

オプション 

gh: 

ユーザがどのアプリケーションやデスクトップ・サービスにアクセスしていても、ユーザがただちに知らなければならない緊急事態が発生した場合は、聴覚的かつ視覚的な通知を使用してユーザの注意を引く。アプリケーションがどのワークスペースにあるかにかかわらず、警報は現在のワークスペースで通知されなければならない。 

ネットワーク・モニタや株式監視プログラムなど、一部のアプリケーションは、何らかのイベントに対して、ユーザの注意をただちに引き付けなければなりません。ユーザへの通知には、視覚的かつ聴覚的な警報を使用するべきです。ユーザはその警報を確認し、終了させることができなければなりません。 

ユーザが複数のアプリケーションを同時に実行しており、アプリケーションをバックグラウンドで動作させていて、別のアプリケーションに注意を払っている間にエラーが発生する可能性があることに注意しなければなりません。ユーザがエラー・メッセージの発生源を識別できるように、タイトル・バーにはアプリケーション名を入れておくべきです。

エラー・メッセージを読んだユーザは、問題を解決するために、システムの他の部分にアクセスしなければならないことがあります。エラー・ダイアログ・ボックスを表示することによって、アプリケーションとの対話が妨げられるようなことがあってはなりません。また、可能な限り、他のアプリケーションとの対話を妨げてもなりません。

オプション 

gq: 

アプリケーションは、エラー・メッセージがメッセージ・ダイアログ・ボックスに表示するのには適さないが、問題の診断に役立つ可能性がある場合には、共通デスクトップ環境のエラー・ログにエラー・メッセージを書き込む。 

また、ユーザや管理者にとって、メッセージを後から確認できると便利な場合は、ユーザに表示されたエラー・メッセージをエラー・ログに書き込むこともできます。エラー・ログに書き込まれたメッセージは、エラーに関する詳細な情報を提供し、エラーが発生したコンテキストを明示するべきです。 

オンライン・ヘルプへのアクセス

推奨 

gj: 

アプリケーションは、自己完結的な説明を含んでいるダイアログ・ボックスを除き、すべてのメッセージ・ダイアログ・ボックスに [ヘルプ] ボタンを用意する。 

アプリケーションは、専門家と初心者のユーザの両方を念頭に置いて設計しなければなりません。初心者のユーザは、メッセージの内容、それが表示される状況、およびメッセージに対してユーザが行うべきアクションを理解するための情報にアクセスできなければなりません。 

上級ユーザにとっては、エラー・ダイアログの中の簡単な説明で十分かもしれませんが、経験の浅いユーザにとっては、問題の解決には不十分な場合があります。文章を追加してダイアログを複雑にする代わりに、ユーザがエラーとその原因、および問題を解決するための手段に関する詳細な説明を記したオンライン・マニュアルにアクセスできる [ヘルプ] ボタンを使用します。さらに詳細なヘルプを必要とするユーザは、そこから一般的なオンライン・ヘルプ機能にアクセスできます。一部の通知では、メッセージのテキストで状況を十分に説明できるので、[ヘルプ] ボタンは不要な場合もあります。

エラー・ダイアログ・ボックスからオンライン・ヘルプへの直接アクセスの詳細は、『共通デスクトップ環境 プログラマーズ・ガイド (ヘルプ・システム編)』を参照してください。

有用なヒント

オプション 

gh: 

ユーザがどのアプリケーションやデスクトップ・サービスにアクセスしていても、ユーザがただちに知らなければならない緊急事態が発生した場合は、聴覚的かつ視覚的な通知を使用してユーザの注意を引く。アプリケーションがどのワークスペースにあるかにかかわらず、警報は現在のワークスペースで通知されなければならない。 

アプリケーションは、メッセージをコマンド入力ウィンドウや UNIX コンソールに送信してはなりません (つまり、アプリケーションはデフォルトの UNIX ファイル stdout や stderr に書き込んではなりません)。アプリケーションは、ファイル・マネージャ、フロントパネル、またはアプリケーション・マネージャのアイコンのダブルクリックによって起動されることが多いため、ユーザは stdout や stderr に書き込まれたメッセージを見ることができなくなります。アプリケーションが端末ウィンドウから起動された場合でも、ユーザは起動後に端末ウィンドウを閉じることがあり、この場合には端末ウィンドウに表示されたメッセージが読めなくなります。さらに悪い状況として、ユーザがコンソール・ウィンドウを実行しておらず (コンソール・ウィンドウは共通デスクトップ環境では起動するのが困難です)、コンソールに送られたメッセージが画面上に散乱して、画面が汚くなる場合があります。

情報メッセージ

経過状況、ステータス、または有用な情報をユーザに伝えるためには、ウィンドウのフッタに情報メッセージを表示します。情報メッセージは作業の妨げにならないように設計されるもので、多くのユーザは気付かない可能性があるため、重要な情報を表示するために情報メッセージを使用してはなりません。

情報メッセージのガイドライン

推奨 

gi: 

アプリケーションは、ステータス、経過状況または情報 (ヘルプ) メッセージを伝えるためにのみ、フッタ・メッセージを使用する。エラー・メッセージの表示のためにフッタは使用しない。 

Motif はメイン・ウィンドウの下部にメッセージ領域を用意していますが、これはかなり不自然で、汚くなることがあります。よりエレガントなアプローチは、図 8-2 に示すように、メイン・ウィンドウのデータ領域の下に、より広いマージンを用意して、そこにステータス情報をさりげなく表示するという方法です。情報メッセージの他の使用例については、共通デスクトップ環境のメール・プログラムのステータス・メッセージ領域を参考にしてください。

図 8-2 ウィンドウの下部の情報メッセージ

Graphic

読み込みの開始時には「earth.gif を読み込み中です...」というテキストが表示され、読み込みが完了したら「終了」というテキストが追加されます。メッセージ全体が 5 秒後に削除されます。

フッタ領域の情報メッセージは左に揃え、邪魔にならないように細いフォントで表示します。情報メッセージが表示されるマージンは、マウス・フォーカスを受け入れてはならないという点に注意します。フッタ領域の経過メッセージは、通常は操作の実行中にのみ表示します。情報が最新のものであるかどうかという点での混乱を避けるために、無効になった通知やその他の情報は、2、3 秒以内に削除されなければなりません。

その他のメッセージ・ダイアログ

推奨 

gk: 

アプリケーションは、メッセージの表示のために、適切な形式のダイアログ・ボックスを使用する。 

オプション 

gl: 

情報ダイアログ・ボックスは、ステータス、アクションの完了、あるいはユーザがそのメッセージを読んだということを確認する以外に特別な応答をしなくて済むような、他のタイプの情報メッセージを表示するために使用される。 

情報ダイアログ・ボックスは、少なくとも、ユーザがダイアログ・ボックスを消去できるように [了解] ボタンを持っていなければなりません。メッセージの表示を引き起こした状況に関して他の情報があったり、メッセージが関連するトピックについて他のリファレンスがある場合は、[ヘルプ] ボタンを用意します。 

オプション 

gn: 

ユーザに質問をするためには質問ダイアログ・ボックスが使用される。質問は、肯定応答と否定応答が何なのかがわかるように、明確に書かれていなければならない。表示されるボタンは [はい]、[いいえ]、および [ヘルプ] である。[ヘルプ] は、[はい] と [いいえ] の選択に対してアプリケーションが行う処理に関する情報を提供する。 

[はい] と [いいえ] のボタン・ラベルは、可能な限り、これらのオプションを選択することによって実行されるアクションを明確に示すラベルに置き換えてください。たとえば、ユーザがドキュメントに変更を加えており、保存を行わずにアプリケーションの [終了] オプションを選択した場合は、「変更内容は保存されていません。終了する前に保存しますか」と問い合わせる確認ダイアログ・ボックスを表示します。ボタンは [保存]、[破棄]、[取消し]、および [ヘルプ] になります。これらのラベルを使うと、上級ユーザは質問の内容を読まずにラベルだけから判断して、正しいボタンをクリックできます。 

オプション 

go: 

ユーザが要求したアクションの結果として、データやシステムまたはアプリケーションへのアクセスしやすさが失われたり、その他の望ましくないイベントが起こる可能性がある場合は、そのことを通知するために警告ダイアログ・ボックスが使用される。このダイアログ・ボックスは、アクションが実行される前に表示され、要求された操作を取り消す機会をユーザに与える。表示されるボタンは [はい]、[いいえ]、および [ヘルプ]、あるいは [継続]、[取消し]、および [ヘルプ] である。[ヘルプ] は、要求されたアクションを実行したときの結果に関する追加情報を提供する。 

[はい]、[いいえ] と [継続]、[取消し] のどちらを使用するかは、メッセージの言葉遣いに依存します。[はい] と [いいえ] のラベルは、前述のように、適当な言葉に置き換えるべきです。[継続] は、実行されるアクションに即したラベルに置き換えることもできます。 

オプション 

gp: 

実行中の作業に関する情報が、アプリケーションのウィンドウのフッタに表示されない場合は、この情報を作業中ダイアログ・ボックスに表示する。このダイアログ・ボックスは、ユーザが作業を終了させるための [中止] ボタンを含んでいる。操作は次の適当なブレークポイントで終了し、ユーザが本当に作業を中止したいのかどうかを問い合わせる確認を表示できる。確認メッセージは、アクションを中止したときの影響を記述することもできる。 

実行中の作業のフィードバック

推奨 

gt: 

ユーザが選択したコマンドが完了するまでにかかる時間が 2 秒よりも長く、10 秒よりも短いと予想される場合、アプリケーションは、コマンドが実行中であることをフィードバックする標準のビジー・ポインタを表示する。 

ユーザには、アプリケーションが要求を「聞き入れて」おり、その作業を実行しているという保証を与えなければなりません。要求の結果をただちに表示できない場合は、何らかのフィードバックを提供する必要があります。ビジー・カーソルは、コマンドの実行から 0.5 秒以内に表示されなければなりません。 

推奨 

gu: 

ユーザが選択したコマンドが完了するまでにかかる時間が 10 秒を超えると予想される場合、アプリケーションは、要求の処理を行なっていることを示す作業中ダイアログ・ボックスや、これに似た何らかのフィードバックを表示する。フィードバックは、そのアクションの完了に向けての経過状況を示すものでなければならない。 

あるアクションが完了するまでに長い時間 (10 秒以上) がかかると予想される場合、アプリケーションはビジー・ポインタよりも強いフィードバックを表示しなければなりません。ビジー・ポインタの表示時間が長くなりすぎると、ユーザはアプリケーションがハングアップしたと思うかもしれません。このような場合には、アプリケーションが実行を続けており、ユーザの要求を処理していることを示す経過表示を行います。経過表示は、アクションのどれだけの部分が完了したのか、どれだけの部分が残っているのかを表示しなければなりません。 

推奨 

gv: 

アプリケーションが実行中の作業のフィードバックをユーザに表示しているときに、デスクトップ環境の他のアプリケーションやサービスに対するアクセスを中断しない。 

マルチタスクは必ずサポートされなければならないので、アプリケーションは何らかのアクションを実行している間も、他のサービスへのアクセスを許可しなければなりません。可能ならば、ユーザは、アプリケーションが別の要求の処理を行なっている間も、同じアプリケーションの別の機能にアクセスできるべきです。これがサポートされている場合、アプリケーションはビジーではあるが、入力の受け付けは行なっていることを示す拡張ビジー・ポインタを表示します。 

第 9 章 アクセスしやすさを考慮した設計

この章では、ソフトウェア・アプリケーションが障害を持ったユーザからもアクセスできるようにするためのガイドラインを示します。

アクセスしやすさ

アクセスしやすさとは、障害を持つユーザが、サービス、製品、および情報の利用を含む重要な生活活動に参加するのを妨げている障壁を取り除くという意味です。

アクセスに対する障壁を除くことは、障害者だけでなく、幅広い人々に役立つことがあります。たとえば、舗道に斜面が付けられるまでは、車椅子の人々が道を渡るのは困難あるいは不可能でした。舗道の斜面は、車椅子の人々だけでなく、自転車に乗っている人々や、ショッピング・カートや乳母車を押している人々にも役立っています。

これと同じように、アクセスしやすいソフトウェアを設計することは、幅広いユーザにとっての利益になります。マウスの代わりにキーボードを使えるようにすることで、キーボード主体の作業を行なっているユーザは楽になります。ポータブル・コンピュータのユーザや、電話の音が響くオープン・オフィスで仕事をしているユーザは、音を聞くことができない場合があります。警告音を利用したり、それに置き代わる視覚的なヒントを用意すれば、聴覚障害者だけでなく、そのようなユーザにも役立ちます。

アクセスしやすいコンピュータ製品の市場は拡大しつつあります。約 4000 万人のアメリカ人が何らかの障害を持っており、年齢構成が高くなるにつれて、老齢による障害を持つ人は増えていきます (55 歳では 25% ですが、65 歳では 50% に上昇します)。

障害を持つユーザは、すべてのコンピュータ・ユーザと同じように、年齢、コンピュータの使用経験、関心の度合、教育程度などはさまざまです。障壁が除かれれば、コンピュータは他のユーザと同じ立場で競争するためのツールになりえます。障害を持つユーザには、エンジニア、芸術家、科学者、デザイナ、法律家、管理業務のアシスタント、ソフトウェア・エンジニアなど、さまざまな職業の人がいます。こうした多様なユーザに共通するのが、コンピュータが毎日の仕事の中で重要な役割を果たしているという点です。

容易なアクセスを提供することは、幅広いユーザにとって利益となるだけでなく、リハビリテーション連邦法の 508 条で定められているように、あらゆる連邦機関との契約条件における必須事項になっています。私企業においても、障害をもつアメリカ人法 (ADA) の下で、現在と将来の従業員のことを考慮すると、同じような配慮が必要となります。

アクセスとスタイル・ガイド

障害を持つユーザの多くは、補助的なソフトウェアやハードウェアなしでもアプリケーション・ソフトウェアを使用できますが、画面の読み上げ機能や音声認識といった技術を使う必要があるユーザも存在します。いずれの場合も、障害を持つユーザが、直接に、あるいは補助的なソフトウェアとハードウェアを通して間接にアプリケーションを使用できるようにするための標準的な方式を示しているスタイル・ガイドに従うことが重要です。

アクセスしやすいアプリケーションを実現する最も簡単な方法は、スタイル・ガイドに従い、この章に記されている助言を読んで、それに従うことです。

身体的な障害

身体的な障害は、病気、事故、または過度の筋肉の酷使が原因で発生します。例としては、脊髄の損傷、神経の退化性の病気、心臓発作、反復的な圧力による傷害などがあります。

身体的な能力は、上記の障害の例の中でも、大きな違いがありますが、アプリケーション・ソフトウェアのすべてのコントロール、機能、および情報に対して、キーボードによるアクセスが必要であるという条件は共通しています。マウスを使用できないユーザが、Motif アプリケーションを生産的に利用できるようにするためには、網羅的なキーボード・アクセスを提供することが非常に重要です。

アプリケーションをアクセスしやすくするために、アプリケーションに対する完全なキーボード・アクセスは必要条件ではありますが、十分条件ではありません。もう 1 つの重要な条件は、このスタイル・ガイドに記されているキー・マッピングのガイドラインに従うことです。これらのマッピングを一貫性のある形で使用して、複数のアプリケーションを使うために必要な学習の量を減らすことによって、より使いやすいアプリケーションを提供できるだけでなく、音声制御や画面読み上げソフトウェアなどの代替 I/O 技術の効果を高めることもできます。

ガイドライン

推奨 

id: 

すべてのアプリケーション機能がキーボードからアクセスできなければならない。 

視覚的な障害

視覚的な障害者が必要とするツールには、眼鏡、大きなサイズのディスプレイとフォントなどから、全盲のユーザがナビゲートしたり、画面に表示されているものを音声で確認できるようにするための画面読み上げソフトウェアまで、さまざまなものがあります。

小さなフォントを読むことは、視力の弱いユーザにとっては難しい場合があります。ユーザは、テキスト区画、メニュー、ラベル、および情報メッセージを含むすべてのフォントを簡単に構成できなければなりません。フォント・サイズと字体をハード・コードしてはなりません。

カラーに依存する情報の解釈 (たとえば赤は中止、緑は続行など) は、視覚障害を持つユーザにとっては困難である場合があります。色盲のために、一部のカラーを区別できない人は、かなりの数存在します。このため、カラーを唯一の情報源として使用することは避けます。

解釈だけでなく、バックグラウンド・カラーとテキスト・カラーの組み合わせによっては、視覚障害を持つユーザがテキストを読むのが難しくなることがあります。この例でも、ユーザによる選択を可能にすることが重要です。カラーの選択をハード・コードしてはなりません。ユーザは、自分にとって最適なカラーが選択できるように、デフォルト・カラーを無効にできなければなりません。

すべてのウィジェット・インスタンスに、意味のある名前を付けてください。意味のある名前は、画面読み上げソフトウェアを使用している視覚障害を持つユーザの役に立ちます。たとえば、消しゴムのグラフィックに widget5 というような名前を付けるのではなく、消しゴムという名前や、その他の説明的な名前を付けます。

このような説明的な情報がないと、全盲あるいは弱視のユーザは、ラベルの付いていないウィジェット、図のラベルが付いているウィジェット、あるいはカスタム・ウィジェットを解釈できなくなります。このような場合には、この情報を用意することがアクセスのための必要条件になります。また、意味のあるウィジェット名を付けることで、コードのデバッグがしやすくなるという恩恵もあります。

最後に、視覚障害を持つ多くのユーザが、キーボードによるナビゲーションと制御に頼っており、ポインティング・デバイスを使うことはないという点に注意してください。

ガイドライン

推奨 

ie: 

カラーをハード・コードしてはならない。 

推奨 

if: 

線、境界、シャドウといったグラフィック属性をハード・コードしてはならない。 

推奨 

ig: 

フォント・サイズとスタイルをハード・コードしてはならない。 

推奨 

ih: 

すべてのアプリケーション・コードは、ウィジェットに対して、説明的な名前を付けなければならない。テキストではなくグラフィックを使用しているウィジェット (たとえば、パレットの項目やアイコン) に、説明的な名前を付けることにより、視覚障害を持つユーザも画面読み上げソフトウェアを使って情報を得ることができる。 

聴覚的な障害

聴覚的な障害を持つユーザは、音を聴くことができなかったり、オーディオ出力を背景の雑音と区別できないことがあります。

ユーザが音による通知を聴くと想定してはなりません。飛行機の座席に座っているユーザ、騒音の大きいオフィス、あるいは音を消さなければならない公共の場にいるユーザは、聴覚障害を持つユーザと同じように、視覚的な通知を必要とすることに注意します。さらに、特定の周波数や音量の音しか聴けないユーザもいます。オーディオ・フィードバックの音量と周波数は、ユーザが簡単に構成できなければなりません。これらのパラメータをハード・コードしてはなりません。

視覚的な通知を伴わない音、たとえば印刷ジョブが完了したことを示すビープ音などは、聴覚障害を持つユーザや、音を使用していないユーザの役には立ちません。このような音は便利なこともありますが、音が聞こえることを前提にした設計は絶対に行わないようにします。

一方、ほとんどのユーザにとって、印刷が終了するたびに警告ウィンドウが表示されるのは、邪魔なことがあります。視覚的な通知は、アイコンの変更、情報領域内のメッセージ、メッセージ・ウィンドウの表示などの形で実行できます。システムを公共の場で使用しているユーザにとっては、このような通知を音として聴くのではなく、視覚的に見るというオプションの方が便利な場合があります。

重要な点は、ユーザに選択の余地を与えることです。必要な場合は、音による通知と視覚による通知の両方を用意します。デフォルトの動作として視覚的な通知が妥当でない場合は、必ずオプションとして用意するようにします。

ガイドライン

推奨 

ii: 

対話は、ユーザが音による通知を聴くという前提に立って行われてはならない。 

推奨 

ij: 

ユーザは、警告音による情報と視覚的情報のどちらで受け取るのかを選択できるようにするべきである。 

推奨 

ik: 

アプリケーションは、聴覚的な情報を過度に使用したり、聴覚的な情報だけを使用するようであってはならない。 

推奨 

il: 

ユーザは、警告音の周波数と音量を構成できなければならない。 

言語障害、認知障害、およびその他の障害

視覚的、聴覚的、および身体的な障害のためのアクセス・ガイドラインは、一般に、補助技術の使用も含めて、効果的な意思の伝達手段を選択できるという点で、言語障害、認知障害、およびその他の障害を持つユーザにも役立ちます。

ガイドライン

推奨 

im: 

言語障害や認知障害を持つユーザのために、ティアオフ・メニューや、重要なアプリケーション機能のためのユーザによる構成が可能なメニューを用意する。 

既存のキーボード・アクセス機能

CDE Motif アプリケーションを設計する際には、X Window System のサーバのアクセス機能が使用している、既存のシステム・レベルのキー・マッピングを意識するようにしてください。これらのサーバ機能は、AccessX と呼ばれ、動作障害を持つユーザによって一般に使用されている基本的なワークスペース・アクセス可能性を提供します。AccessX は、X Window System のサーバのバージョン X11R6 においてサポートされるようになりました。

内蔵の、サーバ・レベルのアクセス機能には、次のものがあります。

StickyKeys

修飾されるキーを同時に押さなくても利用できるように、修飾キー ([Shift] や [Control] キーなど) のロッキングまたはラッチングを処理します。StickyKeys を利用すると、複数のキーの組み合わせを 1 本の指で入力できます。

RepeatKeys

キー・リピートの開始を遅らせ、動作時間に問題のあるユーザが、複数の文字が送信される前にキーを離せるようにします。

SlowKeys

キーを指定の時間だけ押し続けないと、キーが押されたと受け入れられないようにします。これにより、動作時間に問題のあるユーザが誤ってキーを押してしまったときに、キーを押したというイベントが送信されるのを防ぐことができます。

MouseKeys

カーソル移動の明示的な制御や、すべてのマウス・ボタンを押して離すイベントを、キーボード・ベースで実行できるようにする、マウスの代わりとなる機能です。

ToggleKeys

キーのロック状態を、そのキーを押したときの音で通知します。[Caps Lock] キーなどが、その対象となります。

BounceKeys

指の震えるユーザが、キーを押したと誤って解釈されるのを防ぐために、次のキーを押したことを受け入れるまでのキーストロークの間隔を長くします。

ガイドライン

推奨 

in: 

アプリケーションのキーマッピングが、表 10-6 に示す X Window System のサーバのアクセス機能のために予約されている、既存のシステム・レベルのキーマッピングと重複しないようにする。

アクセスしやすさに関する情報源

ソフトウェアのアクセス可能性に関する詳細な情報については、次に示す団体、会議、および書籍を参照してください。

団体

Clearinghouse on Computer Accommodation (COCA)

18th & F Streets, NW

Room 1213

Washington, DC 20405

(202) 501-4906

技術とアクセスしやすさに関する情報のセンター。COCA のドキュメントは、製品、政府の資料、ユーザの要件、法的な要件などを扱っています。

Sensory Access Foundation

385 Sherman Avenue, Suite 2

Palo Alto, CA 94306

(415) 329-0430

「視覚障害や聴覚障害を持つ人々の選択肢を増やす」ための技術の応用に関する助言を行う非営利団体。補助技術に関するニューズレターを発行しています。

Special Needs Project

3463 State Street

Santa Barbara, CA 93105

(805) 683-9633

障害に関する幅広い問題を扱っている、専門家や家族向けの書籍の出版社。

Trace Research and Development Center

S-151 Waisman Center

1500 Highland Avenue

Madison, WI 53528

(608) 262-6966

補助技術に関する最新情報の中心的な情報源であり、重要な研究および評価センターでもあります。Trace は、補助技術と資料に関するデータベースと論文を配布しています。

会議

CSUN

Conference on Technology and Persons with Disabilities

Every spring in Los Angeles, California

(818) 885-2578

Closing the Gap

Conference on Microcomputer Technology in Special Education and Rehabilitation

Every fall in Minneapolis, Minnesota

(612) 248-3294

参考文献

Brown, Carl. Computer Access in Higher Education for Students with Disabilities, 2nd Edition. George Lithograph Company, San Francisco. 1989.

Cornsweet, T.N. Visual Perception. Academic Press, New York. 1970.

Edwards, A., Edwards, E., and Mynatt, E. Enabling Technology for Users with Special Needs (InterCHI '93 Tutorial). 1993.

Johnson, M, and Elkins, S. Reporting on Disability. Advocado Press, Lousville, KY, 1989.

Managing Information Resources for Accessibility, U.S. General Services Administration Information Resources Management Service, Clearinghouse on Computer Accommodation, 1991.

Vanderheiden, G.C., Thirty-Something Million: Should They Be Exceptions?, Human Factors, 32(4), 383-396. 1990

Vanderheiden, G.C. Making Software More Accessible for People with Disabilities, Release 1.2. Trace Research & Development Center, 1992.

Walker, W.D., Novak, M.E., Tumblin, H.R., Vanderheiden, G.C. Making the X Window System Accessible to People with Disabilities. Proceedings: 7th Annual X Technical Conference. O'Reilly & Associates, 1993.