リボンのデザイン プロセス
機能をリボンに移動すると、ボタンをタブに整理する以上のことが期待できます。
プログラムにはリボンのコマンド ユーザー インターフェイスが適切であると判断したら、次のステップは、変更のための論理的で順序立てられたプロセスを採用することです。メニュー バーとツール バーからリボンへの移行は、プログラム インターフェイスを大幅に変更することになります。各機能を吟味し、機能の意義と価値を伝えることができるリボンの最適な使用方法を決定する必要があります。
タブとグループの観点から検討を開始すると、機能の差が見えてきます。また、以前のバージョンではダイアログ ボックスにのみ存在していたコマンドを、リボンに追加する必要が出てきます。使用頻度が高いダイアログ ボックスでユーザーが何を実行しているかを確認し、それらのコマンドをリボンに移動します。可能な限り、ユーザーがダイアログ ボックスを開かなくてもタスクを完了できるようにします。
新しいコマンド ラベルだけでなく、すべてのコマンド ラベルをテストし、変更します。これには長時間かかることを見込んでおきます。通常の製品サイクルでは、元のコマンド名の変更を正当化することは簡単なことではありません。コマンドをリボンに移動する場合は、このような変更を行うことができます。
従来の機能を微調整し、リボン モデルへの適合性を高める作業も必要です。たとえば、メニューまたはツール バーに動的に表示されるコマンドがあるとします。リボンを使用する場合、この機能を変更する必要があります。そうしないと、コマンドの表示によってタブとグループのレイアウトが大きく変化することになります。リボンのガイドラインを適用し、コマンドを非表示にするのではなく無効にする必要があります。
ダイアログ ボックスのコマンドを表示する
プログラムのタブとグループに配置するものが大まかに把握できたら、その構成に注目し、不足しているものがないかどうかを確かめます。
たとえば Microsoft® Word では、利用状況データにより、[フォント] ダイアログ ボックスがプログラムで最も使用頻度の高いダイアログ ボックスの 1 つであることがわかっています。また別のデータでは、上付き、下付き、取り消し線の各機能が手動で書式設定ツール バーに追加されることが多いことが明らかになっています。Microsoft PowerPoint® では [フォントの拡大] および [フォントの縮小] ボタンがよく使用されるため、これらのコマンドは既定のツール バーに表示されています。
その結果、Word リボンの [フォント] グループには、Word の既定の書式設定ツール バーにある元のコマンドに加えて、新たに 8 つのコマンドがインポートされています。こうすると、[フォント] ダイアログ ボックスを開く必要性が低くなります。これは、以前のバージョンと比較してユーザーがカスタマイズする必要がある部分が大幅に減ったという意味でもあります。この場合の作業は、開発者にとって容易であることがわかっています。すべての機能が、ツール バーに追加可能なボタンとして既にデザインされているためです。
多くの場合、ツール バーに適したバージョンの機能がまだ存在していません。たとえば、Microsoft Excel 2003 では、条件付き書式の影響を受けるセルをすべて選択する場合、[ジャンプ] ダイアログ ボックスを開き、[セル選択] ボタンをクリックし、[条件付き書式] を選択して [OK] をクリックすることによって、結果を確認する必要があります。このダイアログ ボックスが、この機能の存在する唯一の場所であり、ユーザーがメニューまたはツール バーに追加できる同等のコマンドはありません。そのようなコマンドを Office 2007 リボンに追加するとなると、ツール バー ボタンに似たバージョンを作成する必要があります。
ダイアログ ボックスの機能をリボンに移動する方法がすぐにはわからないことがよくあります。典型的なダイアログ ボックスでは、ユーザーは [OK] をクリックするまでダイアログ ボックス内で作業する必要があります。[OK] をクリックした時点で選択項目がすべて反映され、ユーザーはプログラム ウィンドウに戻ります。リボン上のコントロールを操作する場合、変更内容はすぐに反映されます。
つまり、コントロールはすべて独立して動作する必要があり、他のコントロールに依存できません。たとえば、フォントの種類を選択してからフォント サイズを選択し、最後に [OK] をクリックすることによって、両方を同時に適用することはできません。リボンには [OK] や [キャンセル] ボタンはありません。これは、コントロールが互いに影響を与えないという意味ではありません。たとえば、[段落] グループでは、[右揃え] を選択すると、[左揃え] の選択が解除されます。
コマンドにラベルを付ける
適切なラベルがあるとコマンドの理解に大きく役立ちますが、ほとんどのツール バー コマンドにはラベルが付いていません。幅が 640 (または 800) ピクセルの画面にはスペースに余裕がないため、ツール バーにできるだけ多くのコマンドを配置しようとすれば、通常、ラベルを省略することになります。また、ラベルが翻訳され文字数が極端に多くなると、他のコマンドを画面外に押し出す可能性があります。
リボンの主なメリットの 1 つが、すべての項目にラベルを付けることができる十分なスペースを提供できることです。タブとグループのレイアウトを作成するとき、最も一般的な画面解像度では、リボン内のほとんどのコマンドをラベルではっきりと示す必要があるという目標を忘れないようにします。コマンドをもう 2、3 個タブに追加するために、ラベルを省略したくなることがありますが、多くのユーザーはアイコンをすべて記憶しているわけではないことや、ツール バーとは異なり、ラベルを確認できるメニュー バーが別に存在していないことを認識する必要があります。
よく知られているいくつかのコマンドに限って、既定でラベルを付けないでおくことができます。たとえば [太字] や [切り取り] のようなコマンドが挙げられます。これらは、ほとんど間違いなく [ホーム] タブに配置されています。
コマンドに追加の入力が必要であることを示すのに、省略記号 (...) は使用しません。リボン上では、テキストの切り詰めが行われていることを示す場合にのみ省略記号を使用します。ただし、ドロップダウン メニュー内の省略記号には依然として従来の意味があります。リボンでは、自動的にラベルの末尾から省略記号が取り除かれます。タブにもう 2、3 個のボタンを追加しようとするとき、そのスペースがすべて確保されていれば便利でしょう。
その他のガイドラインについては、「ラベル」を参照してください。
ユーザー インターフェイスに一貫性を持たせる
リボンの主なメリットの 1 つが、プログラムのすべてのコマンドに単一の固定された場所を提供できることです。この一貫性によってユーザーはプログラムを把握しやすくなります。一方、UI が動的に変化するとさまざまな混乱を引き起こします。計画の早い段階に、こうした問題を確認しておきます。
一貫性を維持するには、適用されないコマンドを非表示にするのではなく、無効にします。コマンドを非表示にすると、グループのレイアウトが変化してタブ全体に影響を及ぼし、場合によってはまったく違うものになることがあります。
ラベルは動的に変化させないようにします。繰り返しになりますが、実行中にコマンドのラベルを変えると、タブ全体のレイアウトに大きく影響します。既存の機能とラベルを微調整し、コマンドをリボンに適したものにする必要があります。
既存のコマンドのデザインを変更する必要が生じることもあります。たとえば、記録されていないテキストが選択された場合にのみ表示される [メモの挿入] コマンドと、記録済みのテキストが選択された場合にのみ表示される [メモの削除] コマンドがあるとします。リボンでは、両コマンドが常に表示され、1 度にどちらか一方だけが有効になるようにする必要があります。
使いやすいリボンにする
多くのユーザーは変化を好みません。その変化のために手間がかかったり、学習し直す必要がある場合はなおさらです。以前のプログラムでは簡単であったタスクが新たなプログラムでは難しくなったり発見しにくくなると、ユーザーを苛立たせることになります。
使いやすいリボンにするには、次のようにします。
- 以前と変わることなく、コマンドを発見しやすいようにします。リボンの統合性と明示的なラベル付けを利用すると、ほとんどのコマンドが以前よりも見つけやすくなると考えられます。
- 以前と変わることなく、タスクを実行しやすいようにします。リボンで結果指向のコマンドやその他の種類のプレビューを使用することによって、多くのタスクが以前よりも使いやすくなると考えられます。
- 元のプログラムで最も頻度に使用されたキーボード ショートカット キーとアクセス キーが引き続き同じように使用できるように、特に力を注ぎます。従来のメニュー カテゴリのアクセス キーに新たな意味を割り当てることは避けます。たとえば、従来のメニュー バーのバージョンのプログラムに [編集] メニューがあった場合、それに相当するタブにはアクセス キーとして "E" を使用するようにします。上級ユーザーの場合はキーボードを効率よく使用するという要望が強いので、こうして一貫性を保つと高い評価が得られます。逆に、一貫性が欠けていると、大きな欠点として捉えられます。
これで完了ではありません。デザイン プロセス全体にわたるユーザー テストを実施し、タスクが実行できるかどうかだけでなく、以前よりも明らかに操作性が向上していることを確かめます。
まとめ
以下に、機能コマンドをリボンに移動する際の手順を簡単に示します。実際には、製品サイクルの過程で実施される何回もの繰り返しのなかで、これらの手順を何度も実行することになります。
- **プログラム内のすべてのコマンドを集めて一覧表を作成します。**この一覧に基づいて一定期間作業するため、最初に一覧表を作成する時間を取ってください。
- この一覧表には、メニュー バー、ツール バー、コンテキスト メニュー、およびカスタム UI のコマンドをすべて収めておきます。
- コマンドごとに、以下のものが必要です。
- ツール バー コントロール ID (TCID) 情報
- ラベル
- 利用状況データ
- 以下の標準プログラム タブに属するコマンドを除外します。
- ホーム
- 挿入
- ページ レイアウト
- 校閲
- 表示
- 開発
- 標準コンテキスト タブ
- コンテキスト タブに属するコマンドを除外します。
- 以下の標準グループに属するコマンドを除外します。
- クリップボード
- フォント
- 段落
- 編集
- 表
- 図
- テーマ
- ページ設定
- 配置
- 文章校正
- コメント
- 文書の表示
- 表示/非表示
- ズーム
- ウィンドウ
- マクロ
- 残りのコマンドを、いくつかの関連する機能から成るグループに整理します。
- プログラム固有のコマンド群をグループにします。
- ユーザーを対象とする "分類" テストの実施について、ユーザビリティ分析担当者と検討します。
- グループを、5 ～ 10 個のタスクベースのタブに整理します。
- タブのひな形作りを開始し、試作した UI を使用してみます。
- ユーザー分析担当者と協力し、ユーザーを対象にコマンドのカード ソート テストを実施します。
- 不足がないかどうか調べます。ダイアログ ボックスから移動する必要があった機能が存在していることを確かめます。
- ある機能または機能セットの意義と目的を的確に表すための、ギャラリーを使用する場所を決めます。
- ユーザーがタブを見た際に、その用途がわかるようにします。それぞれのタブに明確な目的が存在するようにします。
- タブ セット全体について考えます。ユーザーがタブの並びを見たときに、プログラムの目的を把握できるようにします。
- プログラムの今後のバージョンについて考えます。選択したタブが、数世代先のバージョンにまで使用できるかどうかを考え、プログラムの全体的な方向性に適合していることを確認します。
- 新しい機能を作成し、タブに追加します。
- 新しい機能を作成するまでは、タブ デザインに大きな空間が空くことになります。
- さらに悪いことに、何かを除外すると、その場所が空いたままになります。最初にこのことを考えておきます。機能の除外は常に起こるため、まずこの問題に取り組む必要があります。
- 機能の構成をテストします。
- このテストは、ベータ版のリリースの際だけでなく、開発サイクル全体を通じて実行します。
- 試作品を自分で使ってみます。
- 他のユーザーにも使用してもらい、フィードバックを受けます。
- できる限り、キーボードのアクセス キーとショートカット キーに、以前のバージョンのプログラムと互換性があるようにデザインします。
- 最初の反応だけでなく、十分に使用された後にもフィードバックを受けるようにします。
- 上記の手順を何度も繰り返します。
- 開発者、テスト担当者、担当マネージャーなど、すべての担当者が、コマンドの構成を定期的に繰り返し実施するつもりでいるようにします。
- レイアウトはすべて単純な XML で記述されているため、簡単に変更することができます。
- ただし、現在の計画を検証することは簡単ではありません。開発者が先走り、テスト担当者を置き去りにすることのないようにします。