作業:
|
目的
|
|
手順
これらのステップは論理的な順序で示してあります。ただし、ステップを入れ替えたり、いくつかのステップを並行して実行しなければならない場合もあります。また、ステップの中には検討中の特定ユーザー インターフェイスの複雑さによって、オプションとなるものもあります。 |
|
入力とする成果物: | 結果となる成果物: |
頻度:
実際には、ユーザー インターフェイスの設計は、たいていユーザー インターフェイスのプロトタイプ化と共に行われます (「作業: ユーザー インターフェイスのプロトタイプ化」を参照)。ユーザー インターフェイスを設計する際、継続的に設計をプロトタイプ化し、プロジェクト固有のすべてのガイドラインを考慮して、プロトタイプを公開しなければなりません。ところで、「完全」なユーザー インターフェイス設計は通常、その設計のプロトタイプ化の前には成り立ちません。多くの場合、ユーザー インターフェイス プロトタイプの数度の反復の構築とレビューが終わるまで、詳細なユーザー インターフェイス設計を据え置くのが適切です。 |
|
役割: ユーザー インターフェイス設計者 | |
ツール メンター: | |
詳細情報:
設計の作成を完全にカバーし、特に使いやすさに焦点をあてている [CON99] を参照してください。 |
ワークフローの詳細: |
ユーザー インターフェイスを設計する際、要求の顕在化時に作成した絵コンテ、プロジェクト固有のガイドライン中のユーザー インターフェイス ガイドライン、既存のユーザー インターフェイス プロトタイプを念頭に置きます。この作業の結果、絵コンテの詳細化が必要と判断される場合、こうした更新はシステム分析者により実行されます (「作業: 利害関係者の要望の顕在化」を参照)。
現在の反復中で考慮される要求を実行するためにシステムと相互作用する (人間の) ユーザーの特性を記述します。主要なユーザーの記述に重点を置きます。なぜなら、相互作用の主な部分はこれらのユーザーを含むからです。この情報は次のステップにおいて重要です。
システム分析者と協力し合い、特性の記述を反映するために、アクターの記述に関する変更が必要かどうかを識別します。詳しくは「ガイドライン: アクターの特性」を参照してください。
現在の反復中で考慮される要求 (特にユース ケースおよび絵コンテ) を確認し、システムのユーザー インターフェイスのプライマリ ウィンドウを識別します。「プライマリ」ウィンドウとは、ユーザーがもっともよく相互作用するウィンドウを意味します (ユーザーにとってシステムのメンタル モデルの中心となるユーザー インターフェイス要素)。プライマリ ウィンドウはメニューを含み、サブ ウィンドウまたはフォームを含むことがあります。プライマリ ウィンドウはユーザーが行き来するウィンドウです。非プライマリ ウィンドウはプライマリ ウィンドウの一部になる場合があります。
メインとなるプライマリ ウィンドウは、ユーザーがアプリケーションを立ち上げるときに開くウィンドウであるべきです。このウィンドウはアプリケーションが動作しているときは常にオープン状態にあり、ユーザーは「使用時間」中の多くの時間をここで過ごします。ここは常にオープンしていて、ユーザーが最初にシステムと接触する場所でもあるため、ユーザーにシステム モデルを印象づける最初の手段となります。メインのプライマリ ウィンドウを一般に「ホーム ページ」といいます。
共に表示する必要がある、または他のユーザー インターフェイス要素と空間的な関連のあるユーザー インターフェイス要素を同じプライマリ ウィンドウにグループ化するように試みます。ただし、画面領域の制限で常に可能とは限りません。場合によっては一度に表示する必要があるオブジェクトの数がわかるため、平均的なオブジェクトの数がこのステップへの重要な入力であることに注意してください。オブジェクトの数が多すぎると、同じウィンドウにすべて表示できないことになります。その代わりに、プライマリ ウィンドウはオブジェクトのコンパクトな表現を含み、各オブジェクト (オブジェクトのセット) について別個のプライマリ ウィンドウを定義することができます。
以下は、プライマリ ウィンドウに関する推奨事項です。
目標はプライマリ ウィンドウの数とそれらの間のナビゲーション パスの数を最小化することである点に注意してください。
識別されたプライマリ ウィンドウのセットと絵コンテに基づき、システムのナビゲーション マップを定義します。
ナビゲーション マップは、プライマリ ユーザー インターフェイス要素とそれらのナビゲーション パスを含まなければなりません。ユーザー インターフェイス要素間で有効なすべてのパスを含む必要はなく、主なパスだけでかまいません。目標は、ナビゲーション マップがシステムのユーザー インターフェイスのロード マップとして機能することです。
ナビゲーション マップ中の「最上位」のユーザー インターフェイス要素として最も明白な候補は、メインとなるプライマリ ウィンドウ (ユーザーが使用時間の大部分を費やすウィンドウ) です。
ナビゲーション マップは、特定の画面または機能に到達するために、ユーザーが「何回クリック」する必要があるかを明確にしなければなりません。一般に、アプリケーションの最も重要な領域は、プライマリ ウィンドウから「1 度だけクリック」して移動可能にするとよいでしょう。ウィンドウ間のナビゲーション パスが長すぎると、不必要な対話のオーバーヘッドが加わるばかりでなく、ユーザーがシステム内で「迷子」になってしまうかもしれません。理想的には、全ウィンドウが 1 つのメインとなるプライマリ ウィンドウから開くことができ、ウィンドウ間のナビゲーション パスの最大長が 2 となることです。ナビゲーション パスが 4 以上にすることは避けるようにします。
プロジェクト固有のガイドラインに説明されているように、ナビゲーション マップは、システムのユーザ インターフェイスに対する使用法メタファを準拠および反映する必要もあります。
ナビゲーション マップにはさまざまな表現を用いることができます。以下に例を示します。
どの表現を用いるかについての選択はプロジェクト固有のガイドラインに指定されます。
この時点で、以下のような高レベルのユーザー インターフェイス設計が完了しています。
次に、ユーザー インターフェイス要素の詳細な設計が実行できます。ユーザー インターフェイス要素の設計作業には次のような側面があります。これらについてそれぞれを以下で説明します。
プライマリ ウィンドウ、特にメイン ウィンドウの視覚化は、システムの使いやすさに重大な影響を及ぼします。この視覚化の設計にあたっては、内包するユーザー インターフェイス要素のどの部分 (特性) を視覚化するべきかを検討する必要があります。絵コンテのイベント フローを利用すると、表示する特性に優先順位を付ける際に役立ちます。ユーザーが、ユーザー インターフェイス要素の多数の異なる特性を見る必要がある場合、プライマリ ウィンドウの複数のビュー、つまり異なる特性のセットを視覚化するビューを実装してもかまいません。この視覚化の設計には、視覚的なすべての次元を使って、内包ユーザー インターフェイス要素 (特性) がどのように視覚化されるべきかを検討する必要があるという意味もあります。詳しくは、「ガイドライン: ユーザー インターフェイス (一般) 」の「視覚的次元」を参照してください。
可能ならば、プライマリ ウィンドウ中に表示される要素間の「共通項」を識別します。ある種の次元をベースとして共通項を視覚化すると、ユーザーは要素を互いに関連付けることができ、パターンが見えてきます。これによりユーザー インターフェイスの「帯域幅」は大幅に増大します。
次のような側面を表示したい顧客サービス システムがあるとします。
ここでの共通項は「時間」です。このように同一水平時間軸上に不満または質問、購入と請求書送付を並べて示すと、これらの項目の関連パターン (もし存在すれば) を見て取れます。
ここでは、プライマリ ウィンドウに対して呼び出し可能なユーザー操作の「実装」方法を決定します。プライマリ ウィンドウのユーザー操作は、メニュー バーのメニュー項目として提供するのが普通です。また、ショートカット メニューやツールバーを使う代替起動法や補完手段も提供します。
各プライマリ ウィンドウについて、メニューとメニュー オプションを定義します。たとえば、文書エディタでは [切り取り] や [コピー] などの関連のある操作をまとめた [編集] メニューがあります。
ユーザーに複雑な対話を必要とする操作の場合は独自に 2 次ウィンドウを持つことが許されます。たとえば、文書エディタでは、文書の [印刷] 操作がありますが、複雑な対話があるため、独立したダイアログ ウィンドウを持つことが許されています。
1 つのウィンドウ中で多数のオブジェクトを視覚化する場合、こうしたオブジェクトを含むユーザー操作を設計する必要があるかもしれません。そうしたユーザー操作の例を以下に示します。
詳しくは、「ガイドライン: ユーザー インターフェイス (一般)」を参照してください。
ユーザー インターフェイスに必要な動的振る舞いを追加します。選択操作パラダイムのように、ダブル クリックでオープンし、マウスの右ボタンでポップアップ メニューを出す等、動きのほとんどはターゲット プラットホームによって得られますが、次のことは自分で決定する必要があります。
次のように使い勝手を向上させる共通の機能も評価します。
詳しくは、「ガイドライン: ユーザー インターフェイス (一般)」を参照してください。
Rational Unified Process
|