トピック

ウィンドウの基礎: コンテキストの設定ページの先頭へ

この項では、ウィンドウベースのユーザー インターフェイスの構成の概要を説明します。この概説はこのガイドラインの以降の内容を理解するために必要です。

ウィンドウベースのユーザー インターフェイスはいくつかのウィンドウに分割されます。ウィンドウは画面上をあちこち移動させたり、ほかのウィンドウの上に重ねたり、アイコン化したりできます。システムには通常、1 つのプライマリ ウィンドウと複数のセカンダリ ウィンドウがあります。プライマリ ウィンドウはユーザーとの主要な対話を処理するためのものであり、その中に必要な数のオブジェクトが含まれます。セカンダリ ウィンドウはプライマリ ウィンドウとの対話を支援するためのものであり、オブジェクトとその操作に関する詳細な情報がその中に示されます。

プライマリ ウィンドウ

プライマリ ウィンドウには、しばしば、ユーザーが操作するオブジェクトが必要な数だけ含まれます。ユーザーがシステムと対話するには通常、まず 1 つ以上のオブジェクトをクリックするなどして選択し、それから選択したすべてのオブジェクトに対して実行する操作を (たとえば、メニューを通じて) 選択します。一般的な操作には、[切り取り]、[コピー]、[貼り付け]、[削除]、また [ プロパティ] があります。

プライマリ ウィンドウには通常メニュー バーがあり、ユーザーはそこから操作を選択できます。ユーザーはまた、ポップアップ メニュー (オブジェクト上でマウスの右ボタンを押すことにより表示) を通して、また直接操作する (オブジェクトをクリック アンド ドラッグする) ことによって、操作を選択できます。全オブジェクトがプライマリ ウィンドウに収まらない場合には、ユーザーはスクロール バーを使用してオブジェクトをスクロールしたりウィンドウの大きさを変えたりできます。さらに、プライマリ ウィンドウは、しばしばいくつかの区画に分けることができ (ウィンドウのサブエリアを定義する)、ユーザーは区画の大きさを変更できます。

文書を表示する Microsoft® Word® のプライマリ ウィンドウ。ここには、段落や文字のようなオブジェクトが含まれています。(ここに示した例は Microsoft® のプラットフォームから引用していますが、このガイドラインは特定のプラットフォームのみを対象としているわけではありません。)

メール ボックスを表示する Microsoft® Outlook® のプライマリ ウィンドウ。ここに、メール メッセージのようなオブジェクトが含まれています。

複合オブジェクト

ユーザー インターフェイス内の複合オブジェクトは視覚的にほかのオブジェクトから構成されるオブジェクトです。たとえば、段落文字から構成され、複雑な描画オブジェクトはもっと基本的な描画オブジェクトから構成されます。

セカンダリ ウィンドウ

セカンダリ ウィンドウは、プライマリ ウィンドウ中のオブジェクトとその操作の詳細 (たとえば、プロパティ) を提供することによって、プライマリ ウィンドウをサポートします。プライマリ ウィンドウ中では、オブジェクトのプロパティは通常ほんの少数しか示されません。オブジェクトの全属性が含まれている (セカンダリ ウィンドウである) プロパティ ウィンドウを開くことによって、オブジェクトのプロパティを見ることができます。ユーザーは、しばしば属性を変更できます。そのために、トグル ボタン、ラジオ ボタン、スケール、コンボボックス、テキスト フィールドなどのコントロールを使用します。

Microsoft® Word® のセカンダリ ウィンドウ。これは段落のプロパティを表示するプロパティ ウィンドウです。

メール メッセージのプロパティを表示する、Microsoft® Outlook® のプロパティ ウィンドウ。

プライマリ ウィンドウとセカンダリ ウィンドウの違いは微妙であり、ときにはまったく人為的に区分されることに注意してください。両方のウィンドウに表示される内容の複雑さのレベルは同等の場合もあります。たとえば、上に示した文書ウィンドウとメール ウィンドウを比較してみてください。文書ウィンドウはプライマリ ウィンドウです。他方、メール ウィンドウはセカンダリ ウィンドウとして扱われます。

しかし、プライマリ ウィンドウとセカンダリ ウィンドウとの間には、主な違いが 2 つあります。

  • プライマリ ウィンドウは、しばしばアプリケーションにとって重要性が高いとみなされています。その理由は、プライマリ ウィンドウの方が使いやすさが格段に優れている必要があるからです。したがって、プライマリ ウィンドウの方に開発の労力が集中される傾向があります。
  • セカンダリ ウィンドウは、しばしばプライマリ ウィンドウから移動することで表示されますが、その逆はありません。

プロパティ ウィンドウのほかに、ダイアログ ボックス、メッセージ ボックス、パレット、ポップアップ ウィンドウなど、別のタイプのセカンダリ ウィンドウがあります。

段落と文字の間で検索操作を行うための、Microsoft® Word® のダイアログ ボックス。

多くのアプリケーションは、ファイルベースになっています。ユーザーがアプリケーションを開始するには、ファイル オブジェクトに対して [開く] 操作を行います (たとえば、フォルダ内のファイル アイコンをダブルクリック)。プライマリ ウィンドウにそのファイル内に格納されているオブジェクトが表示されます。ファイルに対する一般的な操作には、[上書き保存]、[名前を付けて保存]、[開く]、[新規作成] があります。それらは通常、プライマリ ウィンドウのファイルメニューを通じて選択できます。プライマリ ウィンドウには通常、複数のファイルを表示でき (複数文書インターフェイス (MDI) と呼ぶこともある)、ユーザーはファイル間を切り替えることができます。

ファイルとフォルダを表示する、Microsoft® Windows® のファイル管理ウィンドウ。

視覚的な次元ページの先頭へ

プライマリ ウィンドウを実際に使いやすいものにする鍵は、中に含まれるオブジェクトとその属性を視覚化する際に、視覚的な次元を適用することです。識別に必要な以上の属性を提示することの利点は、下記のとおりです。

  • (ユーザーがプライマリ ウィンドウに表示されている属性を見る必要がある場合に) 表示すべきウィンドウの数が少なくなるため、ユーザーがウィンドウを移動する必要性が低下します。
  • ユーザーは同時に異なる様相 (または異なるオブジェクト) を見ることができます。それは多くの場合、比較とパターンの認識を開始するのに役立ちます。視覚的な次元を効果的に使用すると、ユーザーは自分の仕事に関してまったく新しい操作感が得られるようになります。

視覚的な次元には下記の要素があります。

これらの要素について以下に説明します。オブジェクトの視覚的な表現を設計するときは、利用可能な画面領域に注意してください。画面領域を利用するときのオーバーヘッドを可能な限り小さくするように努め、いくつかの視覚的な次元を使用して画面領域を余分に占める価値があるかどうかを考慮します。ユーザーが実際に必要としていることはできるだけ多くのオブジェクトを見ることであり、名前のリストを示すだけの方がユーザーにとって役立つことがあります。

オブジェクトを 1 つ 1 つ識別できるように、これらの視覚的な次元を使用または拡張することが重要であることに注意してください。この件についてはまた後で触れます (「識別」の項を参照)。

また、時間的な次元との相互関係で視覚的な次元を使用できることにも注目してください。たとえば、時間の経過につれてオブジェクトを移動させる (位置を変える) ことや、時間の経過につれてオブジェクトの形や色を変化させる (状態を変える) ことが挙げられます。後者については、「」を参照してください。

位置

位置によって表される最も直観的な様相は現実の世界に見られます。次のような例があります。

  • 地理情報システム (GIS)。表示された地図上で、オブジェクトが実際に位置している 緯度と経度で示される地点を表示します。
  • コンピュータを活用した設計 (CAD) プログラム。実際の座標に基づいて、オブジェクトとその環境を正確に表示します。
  • WYSIWYG (What You See Is What You Get) エディタ。紙の上に印刷されるのと同様に、ウィンドウ内の同じ位置にオブジェクト (文字) を表示します。

画面上での表示サイズが実際のサイズと等しい場合もあれば (CAD プログラムと WYSIWYG エディタの例)、そうでない場合もあります (たとえば、オブジェクトのサイズがオブジェクト間の距離に比べてはるかに小さい場合)。

たとえば、航空券予約システムがあって、そこにユーザーが目的地を入力すると想定します。その環境を表現する方法として、いくつかの空港が位置している地図を表示することが考えられます (この場合、空港がオブジェクト)。この場合、空港の実際の大きさは関係ありません (実際のサイズに比例して表示したら小さすぎて見えない)。したがって、空港はすべて同じ大きさのアイコンで表示されます。

この例はまた、ユーザーがオブジェクトを識別するのに役立つ限り、位置が現実どおりでなくとも空港のアイコンを使用できることを示しています。この例では、ユーザーは空港の実際の位置を知る必要はありません。しかし、ユーザーが地理に明るければ、リスト中よりも地図上で探す方が目的地を見つけやすいでしょう。

また、位置を利用して、「仮想的」な現実の世界を表現することもできます。たとえば、ホーム ショッピング システムがあって、ユーザーはいろいろな店から品物を買えると想定してみましょう。それを表現する 1 つの方法は、(仮想) 商店街を図式的に表示して、種々の店舗を配置することです (この場合は、店舗がオブジェクト)。この図式はそれらの店舗の実際の位置とは関係がありません。単に、ユーザーの空間的な記憶を利用しているだけです。リストまたは階層中の項目を記憶するよりも、X-Y 座標の位置で記憶する方が容易なのです。

位置の別の使い方に、オブジェクト間の関係を示すことがあります。同じ垂直の位置を占めるすべてのオブジェクトをある方向に関連づけます。同じ水平の位置を占めるすべてのオブジェクトを別の方向に関連づけます。スプレッドシートはその一例です。

類似した別の方法に、ある軸でなんらかの属性の値の範囲を表すことがあります。たとえば、航空便予約システムにおいて、予約された便 (この場合、便がオブジェクト) を水平の時間軸に沿って表示して、飛行時間やユーザーが目的地で過ごす時間のような、時間との関係を表すことができます。それらの事柄はすべて、ユーザーが知る必要はないことです。しかし、小ぎれいに表示されていれば、それらの図を眺めるのも楽しいでしょう。

値の範囲全体を示すために画面領域を使いすぎたくない場合には、オブジェクト間の距離を詰めることができます。航空便の予約システムの例では、このことは予約された便を間隔を空けずに水平に並べることを意味します。最初の便を左端に、次の便を最初の便のすぐ右横に、といった具合です。この場合、ユーザーは各目的地で過ごせる時間を見ることはできませんが、飛行時間は見ることができます。

大きさ

多くの場合、「大きさ」は位置と同様に表される必要があります。たとえば、CAD システムでは当然のことながら、大きさは実際の様相を表している必要があります。しかし、どんな大きさで表しても差し支えない場合もあります。たとえば、航空便の目的地の選択をサポートするための地図上の空港がその例に該当します。

そのような場合、大きさは該当オブジェクトが現実の世界において最も直感的に受け取られる要素を表すようにすべきです。ファイルの場合は、オブジェクトの大きさは占有されているディスク スペースを表すとよいでしょう。銀行口座の場合は、オブジェクトの大きさは残高を表すとよいでしょう。大きさの尺度としては、多くの場合、自然な尺度よりも対数尺度を使用した方がよいでしょう。その理由は、自然な尺度では通常、画面領域を消費しすぎるからです。

実際、大きさは非常に直感的にわかるものなので、関係ない場合にも大きさを示すことが考えられます。現実の世界においては、物事 (オブジェクト) が異なればその大きさも異なるので、画面を占有する割合も違ってきます。しかし、そのことは障害にはなりません。それは物事を区別するのに役立つだけです。同様に、ユーザー インターフェイス内で異なる大きさを使用することが、別のオブジェクトをユーザーが区別する助けとなることがよくあります。

大きさは通常、1 つの属性だけを表すようにすべきです。水平方向である属性を表し、垂直方向で別の属性を表すようにすることも可能ですが、そのようにすると直感的にわかりにくくなり、ユーザーを混乱させる恐れがあります。

表現する属性の大きさに水平または垂直のどちらかの方向に (対数的に) 大きさを比例させます。ほかの方向の大きさは固定します (または、名前の長さに依存させます)。同一の属性に関して水平と垂直の両方の方向に大きさを比例させても、値が高まることはほとんどありません。差が大きくなりすぎて、画面領域を消費しすぎるだけです。

形は通常はグラフィカル ユーザー インターフェイス内のアイコンで表されます。形はタイプを表すために使用するのが最善です。なぜならば、タイプの違いを表すよりも、見かけの違いを表す方が直感的にわかりやすいからです。実際には、オブジェクトは違っても同じタイプのもの同士は通常、類似しています。他方、タイプが異なるオブジェクト同士は違って見えます。たとえば、椅子というタイプの個々のオブジェクトは似ています (脚が 4 本と腰掛けと背もたれがある) が、車と椅子は見かけが非常に違っています。

それでは、別々のオブジェクトが異なるタイプのものであるとする基準は何でしょうか。クラスが異なれば当然、タイプが異なると見なしてよいでしょう。また、一部の属性には「タイプ的」なものがあります。そのような属性は通常、使用可能な値の範囲が限られており、その値によってそのオブジェクトに関して (操作とほかの属性の取り得る値の観点から) 何を行えるかが決まります。このことは実際の世界でも同じです。椅子と車の最も重要な違いはその用途にあります。椅子は休息するために使用されるのに対して、車は移動するために使用されます。

しかし、タイプを分ける基準は何かを分析する際に最も重要なことは、ユーザーはどの属性をタイプとして最も受け入れやすいかということです。

複数のクラスも「タイプ的」な属性も存在しない場合、値が限られているほかの属性のそれぞれの値を表すために、アイコンを使用できます。ただし、その属性がユーザーにとって関心の高いものである場合に限ります。

アイコンはまた、(タイプを示すのに加えて) オブジェクトのさまざまな状態を示すためにもよく使用されます。オブジェクトを選択したとき、表示方法には通常は 2 とおりあります。色が黒に変わるか、周囲に長方形が表示されるかです。その他の可能な状態として、オブジェクトのプロパティ ウィンドウが開かれていることがあります。さらに、電子メールを既に読んだかどうかのプロンプトなど、アプリケーションに固有の状態も表示できます。状態の表現がユーザーにとってタイプの表現と紛らわしくならないように、注意してください。その逆についても、同様です。

色は視覚に基づいて 3 つのコンポーネントに分解されます。それらは、色相 (赤、青、茶など)、彩度、明度です。複数の属性を表すために複数のコンポーネントを使用することは避けるべきです。ユーザーにとってわかりにくくなるからです。

色相は、取り得る値が限られているタイプまたは属性を表すために使用できます。しかし、この目的には、どの値を表すかをユーザーにわかりやすく設計できるアイコンを使用した方がよいでしょう。他方、具体的な色と (大部分のタイプの) 値との間には、そのような直感的にわかる対応関係はありません。したがって、直感的にわかりやすいアイコンが見あたらないときに、その代わりに色相を使用できます。アイコンに多くのタイプがある場合の補足的な手段として、アイコンのタイプを分類するために、色相を使用する方法があります (類似した意味を持つアイコンの色を赤にし、別の意味のアイコンの色を青にするなど)。

彩度は、値に範囲のある属性を表すために使用できますが、これによってユーザー インターフェイスが見にくくなる傾向があります。さまざまな彩度を使用すると目に違和感を感じ、彩度が高いとけばけばしい感じがします。

明度は色のコンポーネントの中で最も便利です。値に範囲のある属性を表すために使用できますが、あまり目立たないので、重要性がやや低い属性に適用するとよいでしょう。明度を過剰に使用しないために、最高の明度 (白) から最低の明度 (黒) までを全面的に使用することを避け、やや高めの明度 (明るい灰色) からやや低めの明度 (暗い灰色) の間で使用するようにします。オブジェクトの大部分をユーザーが作成するようなシステムの場合、オブジェクトの最新性 (最後の変更から経過した時間) を明度で表すと非常に便利です。これによってユーザーは処理したいオブジェクト (多くの場合、最後の変更から経過した時間) を識別しやすくなります。ユーザーに提示する必要のある値の範囲が存在しない場合、オブジェクトの経過時間を明度で表すことを検討するとよいでしょう。

アイコンの見栄えをよくし、ユーザーがアイコンを素早く区別できるように、しばしば色が使用されます。アイコンを多色にする場合、ほかの目的には色を使用しない方がよいでしょう。

世の中には色盲の人もいますし、すべての画面でカラーがサポートされているとは限りません。したがって、何か重要な情報を示す場合には、手段を色だけに限定しない方がよいでしょう。他方、色の使い方をよく設計して落ち着いた感じにすると、ユーザー インターフェイスの見栄えがよくなります。

識別

ユーザーは各オブジェクトをひとつひとつ識別できなければなりません。なんらかの視覚的な次元によって識別が可能ですが、多くの場合はそうではありません。アイコンの中または近くに名前を表示するのが、識別を助ける最も一般的な技法です。名前を使用することの利点は、非常に小さな画面領域上で多数の異なる名前を表示できることです。

属性値から名称を生成できることが理想的です (通常はテキスト表示)。代案としては、オブジェクトを作成するときに、ユーザーに名称を指定してもらうこ とです。しかし、それには少し時間がかかるため、使いやすさが低下します。

アイコンの中に名称を入れるようにすることもできます。それによって、画面領域が節約され、アイコンと名称の関係も強く認識できるように なります。ただし、この方法には下記の問題点があります。

  • アイコンの中央部 (名称が表示される部分) は空である必要があります。
  • 名称の長さは可変ですので、アイコンの幅を名称の長さに合わせるか、または名称の一部を切り捨てるかする必要があります。
  • 妥当な長さのテキストはすべて横長であるので、アイコンの高さよりも幅を広くする必要があります。

その結果、名称をアイコンの下または右に表示することが多くなります。それによって、消費する画面領域が少なくて済むという利点がありますが、オブジェクト (アイコン+名称) の幅の方が高さよりもずっと大きくなるという欠点が生じます。名称を表示するためのスペースが十分にない場合 (通常は名称がなくともアイコンを識別できるので、十分に考えられる)、名前の表示をポップアップ形式にできます。つまり、カーソルをアイコンの上に置いたときに、ポップアップ ウィンドウを表示するようにして、その中に名称を表示するようにします。

フォントと属性値の間に直観的にわかる対応関係があれば、限られた属性の選択を表すために、名称のフォントを利用できます (たとえば、太字やイタリック体を使用して、オブジェクトを区別したり重要性を強調したりできます)。しかし、ほとんどの場合、そのフォントを使用することは適切ではありません。どちらかというと見栄えが悪く、直感的にわかりやすくはないからです。

名称 (またはこの目的でユーザーが変更できるほかの任意のテキスト) を表示する場合、プライマリ ウィンドウ内で名称を直接変更できるようにすべきです。代案としては、ユーザーが名称変更操作を要求して新しい名称を入力するか、またはプロパティ ウィンドウを開いてそこで名称を編集します。プライマリ ウィンドウ内で名称を直接編集することは、早いだけでなく、「見ている場所で変更する」という原則をサポートすることにもなります。

検索と測定ページの先頭へ

変更または操作の対象となるオブジェクトのグループが作成され、ユーザーがそれらを識別する選択条件を指定できる場合、プライマリ ウィンドウの検索ツールが、条件に合致するすべてのオブジェクトを選択することで問題を解決できます。

検索の管理には下記の 2 とおりがあります。

  • 検索条件が当てはまるすべてのオブジェクトをプライマリ ウィンドウ内で選択します。見つかったすべてのオブジェクトをプライマリ ウィンドウ内に同時に表示することを保証できない場合 (たとえば、それらが遠くに分散しているなど)、検索ウィンドウ内に該当リストを表示することもできます。検索の後に、ユーザーは追加の検索条件を指定するか、または選択されたオブジェクトに操作を加えるかします。この方法の利点は、検索条件に合致する全オブジェクトに対して、ユーザーはなんらかの操作を指示できることです。
  • 検索ウィンドウ内に [検索] ボタンを用意して、そこから検索条件に合致する次のオブジェクトを選択し、プライマリ ウィンドウの内容をスクロールしてオブジェクトが見えるようにします。検索の後で、ユーザーは選択されたオブジェクトに対して操作を行い、検索条件に合致するオブジェクトを順に検索できます。この方法の利点は、ユーザーは検出された各オブジェクトをその環境 (独立したヒット リストではなく、プライマリ ウィンドウ内) において見ることができるということです。

多くの場合、2 つのケースを組み合わせるとよいでしょう。たとえば、順次検索ウィンドウ内に [すべて選択] ボタンを用意したり、並列検索ウィンドウ内に [次を表示] ボタンを用意したりします。

ソートページの先頭へ

ソートの例として、全オブジェクトを名称のアルファベット順または属性値に応じて、縦に順序を揃えて並べることが挙げられます。その後で、ユーザーはスクロールしながら、オブジェクトを順に見ていきます。実装とユーザーによる操作の両方の観点から、これが最も単純な参照機能のサポートでしょう。求めるオブジェクトの名称 (またはソートの条件となる属性) をユーザーが必ず知っている場合、ソートは最も効果的です。この方法で実装すべきシステムの例として、電話帳が挙げられます。プライマリ ウィンドウでは、しばしばソートの順序や条件を変更する操作ができます。

ユーザーが管理する継承ページの先頭へ

ユーザーが管理する継承の一例として、WYSIWYG 方式のエディタが挙げられます。そのようなエディタでは、各段落の「スタイル」を指定し、次いでそのスタイル (つまりそれに属する各文字) のレイアウトの仕方を定義します。

検索ツールと比べたユーザーが管理する継承の欠点は、複数のオブジェクトに関する属性 (またおそらくそれに関連するもの) の変更をサポートするだけであって、操作の遂行をサポートするものではありません。また、ユーザーがグループ (つまり、利用可能なスタイル) を明示的に定義して維持しなければならない点で、ユーザーが管理する継承にはオーバーヘッドがかかります。これはまた、より複雑な概念でもあります。

しかし、オブジェクトの検索条件を指定できない場合または属性値を相対的に変更する (たとえば、2 繰り上げる) 必要がある場合、ユーザーが管理する継承を用意することが解決策となるでしょう。

ユーザーが管理する継承を役立てるためには、クラスの性質上オブジェクトを (ユーザーにとってなんらかの論理的な意味のある) グループに分類でき、各グループ内では属性値の大部分が同じであるようにする必要があります。

検索ツールと比較した利点はユーザーが管理する継承では上書き (オブジェクト内で明示的に定義されていない場合にのみ、属性値を変更する) をサポートしていることです。また、ユーザーが管理する継承では、ユーザーがより一般的な (つまり強力な) 属性を定義 (たとえば、スタイルからフォントを継承して、2 ピクセル大きくする) できます。ユーザーが管理する継承は、指定しやすい検索条件がグループに備わっていない場合に特に便利です。

ユーザーによる継承の管理をサポートするクラスでは、クラスそのものを継承することも、継承元として使用するためのクラスを新規作成することもできます。クラスがそれ自体を継承できるようにすることは、もう少し強力です。継承元とオブジェクトのために当初から意図されていたもの (たとえば、請求書とする、口座とするなど) の両方に、同じオブジェクトを使用できるからです。それによって、ユーザー (およびシステム) が管理するクラスの数が少なくなります。一方、継承はクラスの通常の操作と明白に分離されるため、継承元の新しいクラスを作成することは有利です。多くの場合、新しいクラスを作成することが最善の解決策です。特に、コンピュータやオブジェクト指向モデルに関するユーザーの経験が浅い場合はそうです。複数レベルの継承をサポートするために、作成する新しいクラスはそれ自身を継承することが望ましいでしょう。

継承グループをどのように構成するかについて、ユーザーには事前に正確な知識がないため、システムに関して、ユーザーが特定のオブジェクトの継承グループを変更しなければならないことがよくあります。そのための操作を用意しておきます。

システムでユーザーが管理する継承をサポートすることを決定した場合、何 (属性、関連、クラス) を継承する必要があるかを分析して、それらの事項だけについて継承をサポートするようにします。そうすると、一般性は低下しますが (ユーザーと開発者の両方にとって)、機能の管理が容易になります。新しいクラスに継承されるべき事柄をモデル化します。継承先のクラスと継承元のクラスの両方において、多くの属性がモデル化されます。ユーザーが管理する継承は、管理者ではなくユーザーの時間を節約することを意図したものであることを覚えておいてください。クラスが自分自身を継承するならば、あらゆる物事が継承可能であることを暗示します。

継承されたクラスの新しいオブジェクトをユーザーが実際に作成する必要があるか、それともシステムで十分な数のオブジェクトを一度に生成できるかを判定します。ユーザーが新しいオブジェクトを作成することを禁止すれば、継承の柔軟性が大幅に低下します。一方、操作は容易になります。

また、継承されたオブジェクトにおける数値属性の変更は、継承された値に対して相対的なものと解釈するか、それとも固定的なものとして解釈するかを決定します。たとえば、オブジェクトはフォント サイズ 12 を継承したが、ユーザーがそれを 14 に変更したとします。相対的に解釈する場合、システムはオブジェクトのフォント サイズを継承した値 +2 として記憶します。つまり、継承元のオブジェクトのフォント サイズが変更されれば、継承先のフォント サイズも変更されます。相対的な解釈をサポートする場合、継承元の属性上にそのことを記録しておきます (継承関係を調べるときにチェックするのにこれを見る)。相対的な解釈はユーザーにも提示されることが重要です (たとえば、単に「フォント サイズ = 14」とするのではなく、「フォント サイズ = 12+2 = 14」とする)。相対的な解釈と固定的な解釈のどちらをどの状況で選ぶか、シナリオに沿って検討できます。両方をサポートする必要がある場合もあります。

ユーザーが管理する継承は上級と中級ユーザー向けのものであるため、通常の使い方 (たとえば、ユーザーが継承機能を使用しない場合) の妨げにならないように設計する必要があります。そうしないと、初心者のユーザーが気後れしてしまいます。

ユーザーが管理する継承は、ユーザーの作業を容易にするためのものであることを忘れないでください。汎用的または純粋なものにする必要はありません。使いやすいことが重要です。

階層の参照 ページの先頭へ

階層の参照によって、ユーザー (または場合によってはシステム) はオブジェクトをプライマリ ウィンドウまたはコンポーネントに分類して、階層的に編成することができます。階層の参照のおかげで、ユーザーは 1 つ (またはいくつか) の分類を検索するだけで済みます。それによって、一度に表示する必要のあるオブジェクトの数が少なくなります。欠点は (通常) ユーザーが分類を管理する必要があることです。この技法の一例として、ファイル ブラウザが挙げられます。そこでディレクトリやフォルダを使用するのは、ユーザーがファイルを見つけやすくするためです。

ウィンドウの管理ページの先頭へ

ウィンドウの大きさと位置の管理は、通常、完全にユーザーに任されています。しかし、ウィンドウの大きさと位置の管理の一部をシステムに委ねることによって、ウィンドウ操作の手間を減らすことを検討できます。

プライマリ ウィンドウが大きければ大きいほど、多くのオブジェクトを表示できますが、消費される画面領域も多くなります。プライマリ ウィンドウには通常、可能な限り多くのオブジェクトを表示すべきですが、必要以上に画面領域を消費すべきではありません。

  • すべてのオブジェクトを表示できるように各プライマリ ウィンドウを大きくしますが、画面からはみ出さないようにします。オブジェクト全体を表示できるように各プライマリ ウィンドウを大きくしますが、有用なものが何もない領域 (たとえば、デスクトップ パブリッシング ソフトウェアのマージン) は取らないようにします。空の領域を取れるほどスペースに余裕があっても、そのような部分があるとほかのアプリケーションを隠すことがあります。
  • セッションの間にユーザーがウィンドウの大きさを変える可能性があることに注意してください。オブジェクトの数が増えたら、ウィンドウのサイズを拡大して、全オブジェクトが見えるようにします。ただし、ウィンドウの大きさが既に画面一杯に達している場合、またはユーザーがデフォルトよりも小さなサイズを選択している場合は除きます。オブジェクトの数が減った場合は、ウィンドウのサイズを縮小します。ただし、ユーザーがデフォルトよりも大きなサイズを選択している場合は除きます。このルールに従えば、ユーザーがウィンドウの大きさを変更する意図に沿っていることが保証されます。

複数のアプリケーションを並行して実行する必要が多い場合、プライマリ ウィンドウの大きさにさらに制約が加わる可能性があります。その場合、デフォルトのウィンドウ サイズの最大値を (全画面ではなく)、画面の半分としてもよいでしょう。

ほかのアプリケーションのウィンドウを可能な限り覆い隠さないように、プライマリ ウィンドウのデフォルトの位置を決めます。いずれかのウィンドウを覆わざるを得ない場合、最も長い時間使用されていないウィンドウを選択します。その際、隠されるウィンドウの一部が見えていて、ユーザーがそれを容易にアクティブにできるようにしておきます。

上記のルールを適用することの欠点は、一部の管理をユーザーから奪うことにあります (ユーザーから要求されないのにシステムがウィンドウのサイズを変更し、しかもセッション間でユーザーがウィンドウの位置を変更したことは記憶されません)。したがって、上記のルールを適用する場合、ユーザーがそれを (コントロールを通じて) 停止できるようにしておく必要があります。

セカンダリ ウィンドウに関しては、呼び出し元のウィンドウを覆い隠すことのないように、大きさと位置を決めます。また、ほかにもセカンダリ ウィンドウがある場合には、それらも隠さないようにします。呼び出し元のウィンドウを覆わざるを得ない場合は、選択されているオブジェクトを覆い隠すことのないように努めます。選択されているオブジェクトのような重要なものを覆い隠すことは、セカンダリ ウィンドウではよく起こりがちですが、使いやすさの上ではマイナスです。

メインのプライマリ ウィンドウ以外のプライマリ ウィンドウに関しても、大きさのルールに関する最後の段落を適用します。

ダイアログ ボックスは例外で、アクティブなウィンドウを覆い隠すように配置します。ダイアログ ボックスは通常は一時的に使用する小さなものであるので、その処理を行っている間、ユーザーは通常アクティブなウィンドウを見る必要はありません。ダイアログ ボックスをアクティブなウィンドウの上に重ねることによって、ユーザ ーがそれを認識し、マウスの移動も少なくて済みますが、これは通常、アクティブなウィンドウ上にカーソルが既に位置しているからです。

プロパティ ウィンドウの大きさは、属性の数によって決まります。サイズが大きくなりすぎる (画面の約 4 分の 1) 場合、タブを増やすべきでしょう。

セッションの情報ページの先頭へ

セッションの間で、すべてのアプリケーション構成情報を (ユーザーからの要求がなくても) 保存してください。ウィンドウの大きさと位置、選択されているビュー、スクロール バーの位置も保存すべきです。ユーザーがアプリケーションを再開した際、前回終了したときとまったく同様に画面が見えるべきです。このようにする動機は、セッションを開始したときにユーザーが最初にすることは、通常前回終了したときの状態に戻ることだからです。

オンライン ヘルプページの先頭へ

オンライン ヘルプはシステムの非常に重要な部分です。ヘルプ システムの設計がよくできていると、ほとんどのシステムで、ユーザー マニュアルに取って代わることさえ可能です。大部分のユーザーがマニュアルを使用することはないとわかっているのに、ほとんどのプロジェクトでマニュアルを作成することに多大の労力が費やされています。それに代わって、この労力を優れたヘルプ システムの構築に投資することを検討すべきです。

検討すべきヘルプ ツールには下記のようなものがあります。

  • ヘルプ オン サブジェクトは最も重要なヘルプ ツールです。このツールでは、ユーザーにサブジェクトを入力してもらうか既存のサブジェクトの中から選択してもらうかして、そのサブジェクトに関するヘルプ情報を提供します。重要なことは、同義語も多数含む大量の索引を用意することです。留意: ヘルプが必要なときに、ユーザーは正しい用語を知らない可能性があることに注意してください。
  • ヘルプ オン オブジェクトは文脈依存ヘルプです。このヘルプ ツールでは、ユーザー インターフェイスの特定の部分 (オブジェクト) について説明するテキストを表示します。ユーザーは文脈依存ヘルプを要求し、それからヘルプ情報を求めるユーザー インターフェイスの部分を選択します。使用可能であれば、ユーザー インターフェイスのあらゆる部分に関して、このタイプのヘルプをサポートすべきです。代替案として、隠されているヘルプ テキストをポップアップ ウィンドウに表示する方法があります。これは文脈依存ヘルプを凝縮したもので、ユーザーがカーソルを数秒間動かさずにいると、その横にヘルプ テキストが表示されます。隠されているヘルプ テキストをポップアップ ウィンドウに表示する利点は、ユーザー インターフェイスを使用した通常の操作を妨げないことです。
  • メッセージ領域は、ユーザーの作業に対してシステムの側からの「コメント」が表示される領域です。この領域はオプションとして使用されるべきです。
  • ウィザードは、ユーザーが何かを行う方法についてヘルプを求めた際に頻繁に使用されるテクニックで、提供することを考慮すべきです。ウィザードは (かなり重要な) タスクをユーザーが遂行するのを「手を引いて」案内する働きをします。ウィザードは説明テキストと共に操作 (ボタン) を表示し、ユーザーはその説明に従って作業を進められます。別の方法として、ウィザードがユーザーに質問をし、それに対する回答に応じて、タスクを自動的に遂行する方法もあります。ウィザードは、かなり重要な作業で使用頻度が少ないタスクに最適です。

文脈依存ヘルプとウィザードの必要性は使用テストの際に識別されるでしょう。使用テスト中に、ユーザーがユーザー インターフェイスのさまざまな部分の機能を理解できない場合、それは文脈依存ヘルプの必要性を示唆しています。ユーザーがあるタスクを遂行することに苦労している場合、それはウィザードの必要性を示唆しています。

多くのヘルプ システムに見られる問題は、初心者用 (明白な事柄にも文章による多大な説明がなされている) か専門家用 (アプリケーションを開発したプログラマと同程度の知識をユーザーが持っていることを想定したリファレンス マニュアル) に分かれて書かれていることです。しかし、ほとんどのシステムでユーザーの多くは「上達中の中級者」です。それらのユーザー向けにヘルプ テキストを記述します。

元に戻すページの先頭へ

[元に戻す] 機能は非常に便利です。ただし、それを実現 (実装) するのは一般に困難です。この機能があると、ユーザーの学習速度が早まります。何かを破壊してしまうことを恐れずに済むからです。これはまた情報を失うリスクを軽減します。情報の損失を防止する代替策は、その可能性のあるすべての操作に関して、ユーザーに確認を求めることですが、これは一般によい解決策とは言えません。この方法では対話のオーバーヘッドが相当に増えると同時にユーザーは無意識に確認してしまうようになり、結局は不適切なものになってしまいます。

より積極的なオプションとして、[繰り返し] 機能も用意して、[元に戻す]/[繰り返し] を複数レベルわたって行えるようにできます。ただし、最初の元に戻す機能で使いやすさの向上の大部分を占めています。

マクロ エージェントページの先頭へ

マクロを用意すると、ユーザーの作業を絶えず監視して繰り返される一連の対話を検出するエージェントを取り入れるのに、非常に役立つ可能性があります。反復される一連の操作が検出されると、エージェントは (ユーザーに許可を求めた後で) それを実行するマクロを作成します。たとえば、ユーザーが 2 つのテキスト段落に「下線」を引き、どちらの場合もその直後にテキストの色を青に変更する操作を行ったとします。すると、エージェントは、選択されたテキスト段落に「下線を引く」と共に「色を青に設定する」マクロを設定したいかどうかをユーザーに尋ねます。ユーザーが希望すれば、エージェントはそのようなマクロやそれを実行するボタン (またはメニュー項目) を作成する必要があります。

記録中にユーザーがオブジェクトを選択すると、それは通常は「デルタ」仕様として解釈されます。つまり、前の選択と関連して、どんなオプションが選択されたか (「次を選択」、「最初の子を選択」といったように) を示します。

オブジェクトの属性の変更をデルタ仕様として解釈すべきかどうかは (たとえば、属性値が 12 から 14 に変更されたことを、14 に設定と解釈するのではなく、2 追加と解釈すること)、あまり明白ではありません。複数のオブジェクトの属性を固定値に変更することは、それらのオブジェクトを選択してから属性ウィンドウを開いて属性値を (14 に) 設定する、1 回の操作ですべてが可能になるため、これをデルタ仕様と解釈する方が、通常はより強力です。

動的な強調表示ページの先頭へ

クラス同士の関連性は両方向であることがよくあり、それは、現実のユーザー インターフェイスにおいては、関連性が両方のオブジェクトに示されることを意味します。オブジェクト A に注目しているユーザーが A はオブジェクト B に関連していることを見て取れるとすると、そのユーザーは通常その逆 (つまり、オブジェクト B に注目しているユーザーが B はオブジェクト A に関連していることを見て取れること) にも関心があるでしょう。関連性は通常、オブジェクトのプロパティ ウィンドウ内に、関連するオブジェクトの名前を割り出すことによって示されます。

一般に、オブジェクト間の関連をプライマリ ウィンドウにおいて視覚化するには注意が必要です。矢印や線で関連を視覚化することは、しばしば、魅力がなくでしゃばりで「てんやわんや」なものになりがちです。関連を視覚化する気の利いた方法は、関係元のオブジェクトにカーソルが重なったときに、関連先のすべてのオブジェクトを強調表示することです。たとえば、文書エディタ内の文字に脚注が関連している場合、対応する文字上にカーソルが来たときに、その脚注が強調表示されるなどです。



Rational Unified Process   2003.06.15