次の方法で共有

実践的なユーザビリティ

  • [アーティクル]

画面デザインの道

Dr. Charlie Kreitzberg および Ambrose Little

認知的視点

Dr. Charles B. Kreitzberg古代中国の哲学では、タオ (道) は、世界を体系づける原理や道筋を指します。タオの起源はおよそ 2,500 年前までさかのぼりますが、その教えには対話のデザインと似ている点があります。タオの中核をなす概念では、すべての作用には反作用が伴います。この概念は、おなじみの陰陽シンボル (図 1) で具現化されます。このシンボルは、世界が、相互に作用し、相互に補完する対極に分かれていることを表しています。画面のデザインという観点からは、このシンボルが、ソフトウェアの 2 つの相補的なモデル (実装モデルとマニフェスト モデル) を表すものと考えることができます。これらのモデルは、Alan Cooper 氏の著書『About Face』で説明されています。Cooper 氏は、実装モデルを実際にソフトウェアが動作する方法、マニフェスト モデルをソフトウェアの機能をユーザーに示す方法と説明しています。効果的にデザインを行う秘訣は、ユーザーの問題のとらえ方に合わせてマニフェスト モデルを作成することです。


図 1 陰陽シンボル

開発者は、実装モデルには没頭してもかまいませんが、UI をデザインするときは視点を変え、ユーザーの視点でソフトウェアを見るよう切り替える必要があります。自分が知っていることを無視して他人の視点を取り入れるのは難しいことなので、これは容易ではありません。以前のコラムで説明した多くのデザイン技法は、このような頭の中での視点の切り替えに役立つよう意図されていました (たとえば、ペルソナを作成して一般的な対象ユーザーを表し、タスクのシナリオを構築してユーザーの利用方法を理解するなど)。対象とするユーザー、そのユーザーが実行しなければならないタスク、ユーザーの行動についての考え方を明確に理解する必要があります。また、対象とするユーザーに想定できる技術的知識レベルを認識しておくことも重要です。こうした知識があれば、適切なマニフェスト モデルを考案することができます。

最初にフレームワークを作成する

以前、概要デザインと詳細デザインの違いについてのコラムを執筆しました。画面をデザインする際は、必ず概要となるフレームワークのデザインから着手します。フレームワークを作成したら、それを詳細画面の基盤として使用します。このフレームワークには、次の 2 つの主要要素があります。

  • ナビゲーション手法: ユーザーはタスク フローを踏まえて画面から画面へと簡単に移動できるようにします。ナビゲーション手法については、2009 年 3 月号のコラム (msdn.microsoft.com/ja-jp/magazine/dd458810.aspx) で説明しました。
  • 見出しなどの固定要素: ユーザーを現在の位置に繋ぎとめる役割を果たし、現在位置に関する手がかりを提供します。

つまり、トップダウン方式のアプローチから始めて、すべての画面に共通する要素を定義し、ユーザーの移動方法の明確なモデルを作成します。  

フレームワークの準備ができたら、最も重要な画面を作成し、必要に応じてフレームワークを調整します。最後に、残りの画面とダイアログ ボックスを考案します。

ワイヤーフレーム テンプレートを作成する

フレームワークは、おそらくマスター ページとして実装することになり、画面の主要領域を示します。これらの主要領域の情報の中には、すべての画面に共通する情報 (製品名、ロゴ、メイン メニューなど) があります。また、各画面で同じ位置に表示されても、内容が変化する情報 (画面のタイトルや階層リンクなど) もあります。さらに、画面ごとにまったく異なる情報 (画面固有のコントロールなど) もあります。ただし、こうした要素をすべて一緒に使用して、一貫性のあるシームレスなデザインを作成する必要があります。

まず、機能に基づいて、画面を複数の領域に分割します。たとえば、図 2 のワイヤーフレームを見てみましょう。このワイヤーフレームは、基本的な画面領域の計画を立てるために使用します。ユーザーが各領域の目的を理解できるように、このワイヤーフレームのすべての領域にラベルを付けています。


図 2 画面領域の定義

ユーザーは、全体的なデザインを見た目で簡単に整理できます。各メイン タブのデザインはやや異なりますが、基本的なレイアウトが変わらない限り、ユーザーにとってはこのデザインに一貫性があります。この例として、図 3 をご覧ください。アプリケーションの別のタブで使用するもう 1 つのテンプレートを示しています。基本的な構成要素の一貫性が保たれているため、デザインの主な要素が異なっていたとしても、ユーザビリティは保持されます。


図 3 互換性のあるテンプレート

もちろん、画面ごとに選択するデザイン パターンは一貫しているべきです。たとえば、2 つのタブにそれぞれ検索機能があるとすると、どちらのタブでもその機能を同じように表現します。

ごくシンプルなシステムを除けば、ダイアログ ボックスなどの二次画面を処理する必要があります。従来は、ブラウザーに制限があるため、多くの Web ベース システムでは子ウィンドウや子階層の使用が避けられていました。そのため代替手段として、ユーザーを別のページに誘導する方法がよく使われていましたが、ユーザーは元のページに戻る方法を見つけなければなりませんでした。ほとんどの場合、これにより混乱が生じていました。

Microsoft .NET Framework のようなプラットフォーム、関連プログラミング言語、および AJAX を使用すれば、ポップアップの作成など、詳細を管理する洗練された方法がより現実的なものになります。フレームワークを作成しているときに、ダイアログ ボックスや詳細の処理方法について考慮します。たとえば、図 2 および 図 3 のテンプレートは、モーダルのポップアップ子ウィンドウとうまく連携します (図 4 参照)。

フレームワークの作成中に、ユーザー サポートとヘルプについても考慮します。ヘルプを後から補足部分として作成する方法がよく使われますが、画面に組み込めばいっそうすばらしく機能します。図 4 のポップアップでは、ユーザーを適切に誘導するメッセージに使用できる説明テキスト用の場所を確保しています。ユーザーは、[Learn More] リンクを使用して追加情報にアクセスできます (もちろん、このリンクの処理方法を示すためのテンプレートをデザインする必要があります)。


図 4 ポップアップ

また、フォームでのユーザー入力を補助するために、ツール ヒントを作成して、ユーザーが特定のフィールドに関する追加情報を取得できるようにします。このサンプル デザインを図 5 に示します。


図 5 ツール ヒント

当初からユーザー サポートのデザインについて検討しておくことで、実際に便利で一貫性のあるユーザー サポートを作成する大きな一歩を踏み出すことができます。入力を促すメッセージと同様、ツール ヒントにはユーザーが詳細を把握できるリンクを含めます。これは一般的な方法とは言えません (また、実装できないツール ヒント コントロールもあります) が、ユーザーが現在の操作コンテキスト内にとどまったまま、詳細を深く掘り下げることができるため、強力な手法と言えます。さらに別のレベルのポップアップ用テンプレートを作成してこうしたリンクをサポートし、余分な移動を避けることもできます。

私の経験では、基本テンプレートに 2 つのレベルのダイアログ ボックスを含めておけば、非常に大規模なシステムの UI にも少数の基本テンプレートで対応できます。フレームワークを前もって指定することにより、特定の画面をデザインするための基盤を作成します。

スタイル ガイドを作成する

フレームワークを作成するときは、フレームワークをスタイル ガイドの形式で文書化します。スタイル ガイドにすることで、作成時に行った選択を記録に残し、他のユーザーが画面を開発する場合でもデザインの一貫性を保つことができます。スタイル ガイドでは、意匠を凝らす必要はありません。通常は、画面のテンプレートをキャプチャして、注釈を付け、注釈付きの画面を Word、Visio、または Web サイトに貼り付けます。 図 6 に、ポップアップのワイヤーフレームに注釈を付けた例を示します。

図 6 スタイル ガイド用に注釈を付けたワイヤーフレーム

フォント、フォント サイズ、および色を指定する際も、画面ごとの一貫性を保つことが重要です。可能であれば、フォントや色をハードコーディングせずにスタイルを使用し、ユーザー (またはグラフィック アーティスト) がアプリケーション間で一貫性を保ったままビジュアル デザインを変更できるようにします。

スタイル ガイドでは、UI で使用する用語を指定することもできます。使用する用語の一貫性を保ち、対象ユーザーが理解できる用語を選択することが重要です。

機敏な対応

以前のコラムで説明したように、UI をリファクタリングすると混乱が生じる可能性があります。このため、通常は、最初に包括的で柔軟性のあるフレームワークを用意してから、開発サイクル全体を通じて入念に仕上げていくのが最も適切です。たとえば、追加のテンプレートが必要になったり、追加のデザイン規則を考え出す必要があるかもしれません。元のデザインさえ改良すれば、UI の開発を進めながらスタイル ガイドを確実に修正していくことができます。元のデザインを考え直さなければならないことがわかったら、一貫性を保つためにすべての画面を確認します。ソフトウェアが既に配置されている場合は、この変更によるユーザーへの影響も考慮します。

ユーザビリティ テスト

フレームワークを作成したら、可能な場合はそのユーザビリティをテストして、デザインが意図したとおりに機能しているかを確かめます。多くの画面をコーディングする前であれば、テンプレートやスタイル ガイドを簡単に変更することができます。

詳細画面を作成する

フレームワークとスタイル ガイドが完成したら、画面を作成します。優れたスタイル ガイドを考案すれば、作業を複数の開発者が分担しても、必要な一貫性を保つことができます。

個々の画面をデザインする作業は、芸術とエンジニアリングの組み合わせです。ユーザーにとって有用な画面デザインを作成するには、自分自身がユーザーの立場に立って、ユーザーの視点から UI を見る必要があります。これは簡単な作業ではありません。そのため、ユーザビリティ テストが非常に強力なツールになり得る理由の 1 つです。

認知モデル

まず、図 7 をご覧ください。これは、ユーザーが画面を処理する方法を簡素化した認知モデルを示しています。


図 7 画面処理の認知モデル

通常、ユーザーは主要な目標を念頭に置いてセッションを開始します。たとえば、"会社にとってのメリットを選択する" とか "この顧客の問題を解決する" などが目標です。次に、実際に画面を目の前にすると、もう少し小さな画面レベルの目標を設定します (たとえば、"ログオンする" とか "顧客の記録を見つける" など)。

こういった目標を念頭に置いて、ユーザーは画面を表示し、実行する操作を決定します。その後、操作を実行して、その結果を確認します。これらの結果に基づいて、ユーザーは新しい目標を設定し、作業を繰り返します。

この作業は、ユーザーが画面上で目標に見合ったコントロールを認識できないと、すぐにわからなくなってしまいます。こうした状況は、デザイン担当者が、ユーザーが移動すべき場所を "覚えている" と考え、目に見えるメッセージで移動先を示さない場合に発生することがあります。たとえば、ユーザーが F1 キーを押してヘルプを表示する製品で、そのことを示すメッセージが表示されない場合などです。他にも、ユーザーがある機能を見つけるには特定の画面に戻る必要があるのに、その機能をどこで見つけられるかを思い出せない場合などがあります。いずれの場合も、必死に探し回ったユーザーが最後には挫折するのが一般的です。

このようなことから、"ユーザーの記憶力に頼らずに、オプションはすべて表示する" という画面デザインの重要な規則が導き出されます。やがて、ユーザーはシステムに慣れていきますが、その結果、記憶をあてにすることになり認知的負荷が増すため、作業が増加します。認知に関して言えば、認識することは、思い出すことよりもはるかに簡単だということを覚えておいてください。膨大な数のオプションが存在する場合は、選択を複数のプロセスに分けることが必要な場合もあります。このような場合は、ユーザーが必要な要素をできる限り迅速かつ簡単に検索できるようにして、常に、認知的負荷を最小限に抑えるようにします。

開発者は効率性についての関心が高いため、既に他の場所で示した情報を繰り返すのは無駄でだらしないと感じるかもしれません。しかし、必ず思い出すことよりも認識することの方が勝るため、ユーザーがその情報を覚えていると考えるのではなく、何度も表示することをお勧めします。また、ユーザーがナビゲーション フローの正確なメンタル モデルを構築することは (少なくとも製品に十分触れるまでは) めったにないので、必要な機能が特定のタブの下にあることをユーザーが思い出すのをあてにすると、処理する認知的負担が大幅に増加します。

レイアウト

先月号のコラムでは、情報アーキテクチャについて紹介し、情報を簡単に理解できるように表示するデザイン方法について説明しました。個々の画面をレイアウトする際には、こうした考え方を念頭に置き、画面が整理、整頓されるようにします。ユーザーには、連携する項目のグループが見た目でわかるよう、いくつかの表示単位にまとめてもらいます。図 8 をご覧ください。項目を無秩序に配置すると、関連する項目のグループを見た目で判断する作業がどれだけ大変になるかがわかります。項目を 1 列に並べ、制御する要素の近くにボタンを配置すれば、見た目でグループであることが簡単にわかります。


図 8 グループ化してわかりやすくした画面

内部の一貫性

一貫性を確保しない相応の理由がある場合を除き、画面どうしの一貫性をできる限り保つようにします。たとえば、一般的なガイドラインを次にいくつか示します。

  • システム全体で同じ用語を使用する
  • 見出しと情報の表示形式を同じにして、一貫性を保った状態に情報を整理する
  • 検索クエリとその結果に同じ手法を使用する

流れ

ユーザーが画面に目を通す方法に順序があるときは、一般に、ユーザーの母国語の流れに従うのが最も適切です。英語やその他の多くの言語では、左から右、上から下に流れます。図 9 を見ると、言語の流れに従ってアルファベット順に並べると、文字が読みやすくなるのがわかります。


図 9 流れ

対象ユーザーの言語がヘブライ語、アラビア語、ペルシャ語、中国語、または日本語の場合は、この順序が右から左になる場合があるため、適宜画面を調整する必要があります。すべての画面でこの流れを考慮する必要はありません。また、必ずしもテキストに関連するとは限りません。そのため、たとえば、プロセスを複数の手順で表すときは、画面上のオブジェクトがグラフィックだとしても、流れに従って配置することが重要です。詳細については、「T シャツを洗濯する」例 (i18nguy.com/MiddleEastUI.html、英語) を参照してください。

魔法が起こる

私を含め多くのデザイン担当者は、優れた画面デザインには感情的な反応があることを知っています。デザインが適切だと感じるのは、いろいろな物が正しい場所に収まっているように思われるからです。このアプローチは、異なる視点から見たときに意味をなします。ここだけの話ですが、我々デザイン担当者は、そういった情動的感情のことを "魔法が起こる" と描写すると同時に、特定のデザインが適切である理由は顧客には説明できないものとあきらめています。

開発者は、特に複雑なデザインの技術的問題を解決したときに、似たような喜びの瞬間を体験したことがあるでしょう。画面デザインで同じような瞬間に到達できた場合は、デザインに関する自分の決定の正しさに自信を持てるだけでなく、ユーザビリティ テストでデザインが不適切とされることはめったにありません。

画面デザインの道を学び、製品の 2 つの相補的な視点 (技術的視点とユーザー中心の視点) を作成する必要があることを理解してください。1 つの視点からもう 1 つの視点にスムーズに切り替えられるようになったとき、難解かつ貴重なスキルをマスターしたことになります。

ソフトウェアの視点



Amborse Little

私が思うに、画面デザインは、我々のほとんどが辛うじて理解できるくらい非常に具体的で実践的なものの 1 つです。そのため、自己満足という残念な結果に終わっています。つまり、私たちは画面デザインについてきちんと考えていないか、自分は画面デザインの専門家だから画面デザインをよく知っていると思い込みます。

このコラムの他の記事で説明したように、ソフトウェアのインターフェイスの作成には、確かに、まったく異なる科学と芸術の両方が含まれます。優れたエクスペリエンスにつながるインターフェイスの作成は、持って生まれた才能と感情移入の能力に左右されるため、平均的開発者はある程度までしか到達できません。その一方で、このコラムでは、UI のデザインが専門分野でなくても、一般のユーザーが優れたエクスペリエンスにつながるインターフェイスを作成し、その分野の専門家を雇わなければならないタイミングをより適切に決定できることも示しています。

このように言うのは、UI テクノロジでデザイン フレームワークの必要性がずっと以前から認識されていたように思われるからではありません。こういったプラットフォームの存在が促進されてきたのは、私たちが愛着を込めてユーザーと呼んでいる人々のために一貫性を保つことが重要であると意識したからではなく、変化する要件に直面したときに、正気を保ち、現在の生産性を少しでも確保する必要があるという開発者の要件によるものだと、私はあえて言います。そのため、我々が現在使用している UI は偶然の産物だと言えます。

現在使用している UI とは何でしょう。それはもちろん、使用しているテクノロジによって異なりますが、ここでは、主要な .NET UI テクノロジに注目します。結局のところ、これは MSDN Magazine ですから。

すべてを含める

まず、すべての .NET テクノロジには、UI の再利用に不可欠な、共通の具体的概念があります。それがコントロール (とそこから派生するユーザー コントロール) です。ほとんどの開発者が理解していると思いますが、コントロールによって、再利用する表示要素と機能を UI の一部として 1 つにまとめることができます。私はテクノロジの歴史についての専門家ではありませんが、私の印象では、コントロールは本質的に、問題領域をまたぐソリューション (多くは外部プロジェクトや外部アセンブリという形で表されるか、サード パーティから提供されます) に向いていると思います。これらのソリューションでは、一般に、コントロールは非常に広範囲に適用できるパターンとして実装されます。一方、ユーザー コントロールは、たいてい、同じプロジェクト ソリューション内の特定の問題領域に対処するのが一般的です。

よく知られていることですが、コントロールとユーザー コントロールはどちらもコードと UI の再利用に適しています。しかし、デザイン フレームワークに関してはある程度までしか再利用できません。そのため、"マスター" や "テンプレート" と呼ばれるフレームワークに似た機能を使用して、全体的なレイアウトや階層的に共有される要素を処理します。同時に、一貫性のあるスタイル設定 (つまり、フォント、色、スペース、および芸術的デザインと情報デザインの両方で使用されるその他の視覚表現) を管理する方法も必要です。このような場合のソリューションはテクノロジによって異なります。

Windows フォーム

ずっと前に、フロリダ在住の勇敢な友人 Stan Schultes が、Visual Studio Magazine で「ビジュアル継承について理解する」(msdn.microsoft.com/ja-jp/library/aa288147(VS.71).aspx、英語) という記事を執筆しました。この記事で説明されているアプローチを使えば、全体的なレイアウトで共有する要件を広くサポートできます。つまり、基本フォームと基本ダイアログ ボックスを作成すれば、ほとんどの要件を満たすようにこのフォームとダイアログ ボックスから UI を構築できます。

独自のデバイスに任せると、デザイン フレームワークを実装するのに役立つのは、Windows フォームから得られる機能にとどまってしまうでしょう。とは言え、一貫したデザイン フレームワークの実装と管理のために、さらなる一貫性と敏捷性を提供し、Windows フォームにはない機能を補完するのに役立つサード パーティ製のソリューション (Infragistics の Application Styling Framework ( infragistics.com/learn/applicationstyling.aspx) とツールなど) もあります。

Composite UI Application Block (CAB) について考えるかもしれません。CAB の詳細については、msdn.microsoft.com/ja-jp/library/aa480450.aspx (英語) を参照してください。CAB は、一貫性のあるデザイン フレームワークの実装を目的としたものではなく、モジュール性と分離性を高めた UI の作成を目的に開発されていますが、(1 つまたは複数のワークスペースを使用して) シェル UI を定義し、ある種のマスター レイアウトを作成することで、求めるレベルのデザイン フレームワークを実装できます。ただし、特定のモジュールを使用して全体的な調和をとる必要がある場合、CAB のモジュール性から、モジュールの開発者がデザイン フレームワークのガイドラインに従う責任が増すことになります。CAB を使用してアプリケーションを実装する場合は、Smart Client Software Factory (SCSF) について調べることをお勧めします (これらの連携に関する優れたガイダンスについては、msdn.microsoft.com/en-us/library/bb266334.aspx (英語) を参照してください)。

ASP.NET

ASP.NET は Web テクノロジなので、デザイン フレームワークに役立つ標準の Web テクノロジを利用できます。中でも CSS が有効です。近年では、共有 CSS フレームワーク (bing.com/search?q=css+frameworks) が普及しています。注意深い CSS Zen Garden の導師であれば、ページ レイアウトをほぼ完璧に制御できますが、一般のユーザーは、HTML 構造と CSS の間でいくぶん相互作用できる程度でしょう。CSS は、デザインの詳細 (余白、パディング、行間隔などのスペーシング、フォント、色、罫線やさまざまな画像ベースの操作などのビジュアル表現) をきめ細かく設定するのに役立ちます。

組み込みのスタイル設定への補足 (たずねる相手によっては矛盾点) として、ASP.NET では、テーマとコントロールのスキンの設定がサポートされるため、アプリケーションからそのちょっとした構成と保守の可能性を引き出すのに役立ちます。また、Infragistics では、Application Styling for ASP.NET も提供されています。この製品を使用すると、特に Infragistics ASP.NET コントロールを使用している場合に、アプリケーションのスタイルを簡単に管理できます。CSS と HTML は非常に強力ですが、管理が難しくなることもあります。Infragistics 製品と組み込みの ASP.NET テーマとスキン設定はいずれも、他のフレームワークと同様、このような複雑さを管理して、開発者の正気を保つのに役立ちます。

全体的なレイアウトと要素の共有を目的として、ASP.NET にはマスター ページがあります (詳細については、msdn.microsoft.com/ja-jp/library/wtxbf3hh.aspx を参照してください)。マスター ページを使用すると、ビューによって異なる可能性があるレイアウト領域にコンテンツ プレースホルダーを使用することで、親やマスターと共通のレイアウトや要素を定義できます。マスター ページは入れ子にでき、複数のマスター ページを使用できます (たとえば、Corporate 用、MyApp 用、および MyAppDialog 用のマスター ページというように使用できます)。これは、デザイン フレームワークの実装と管理をサポートして簡素化するための、実にすばらしく巧妙なフレームワークです。もちろん、MVC がお好きな方は、MVC で同じようにマスター ページを使用できます (MVC の出発点として、 msdn.microsoft.com/en-us/library/dd381412.aspx (英語) をご覧ください)。

ASP.NET についてもう 1 つ付け加えておきます。ASP.NET AJAX (およびその他の AJAX テクノロジ) を使用して、外側の共通レイアウトを実質的に管理し、単純にコンテンツ領域を更新して置き換えることもできます。ASP.NET AJAX は、マスター ページと共に使用できるもう 1 つのツールです。このツールにより、CSS やマスター ページのメリットを活用しつつ、AJAX のメリットももたらされるため、一貫性のあるデザイン フレームワークを実現できます。

SharePoint などのコンテンツ管理システム

最後に、ほとんど ASP.NET に関係があることですが、SharePoint などのコンテンツ管理システムは、一般に、ASP.NET フレームワークから得られる基本機能をはるかに上回り、ページ テンプレート、コンテンツ タイプ、および一貫性のあるデザイン フレームワークの確立と管理にさらに役立つ同様の機能が提供されます。ある意味、開発に携わっていないユーザーでも、元のデザイン フレームワークを完全な状態に保ったまま、システムを拡張することができます。

WPF

WPF (Windows Presentation Foundation) には、スタイル設定に関して基本的にスタイルとテンプレートという 2 つのレイヤーがあります (詳細については、msdn.microsoft.com/ja-jp/library/ms745683.aspx を参照してください)。スタイルは、実質的には、共有プロパティ値のセットをグループ化する方法です。WPF では、データ テンプレートとコントロール テンプレートという、2 つの基本的な種類のテンプレートが用意されています。コントロール テンプレートは、コントロールのルックアンドフィール (これには、コントロールに不可欠な構造や動作も含みます) を完全にカスタマイズする手段です。たいていは、複数のコントロール テンプレートを併用して (コントロールのスタイルに Template プロパティを設定するなど)、以前の .NET UI テクノロジで実現できなかった程度までエクスペリエンスをカスタマイズできます。データ テンプレートは、データの形状に共通する UI 定義を共有するための、非常に優れた方法です。つまり、データ テンプレートでは、たとえばデータ ソースが特定の型であることよりも、一致するバインドを見つけることのみが重視されます。

WPF は本質的にはクライアント側のテクノロジなので、全体的レイアウトと共有要素に関しては、程度の差こそあれ、単にビュー (ウィンドウ) を作成し、そのビューのレイアウトを設定し、実行時にプレースホルダーにコンテンツを代入するだけです。WPF では Journal Navigation パターンの実装もサポートされています (このパターンの詳細については、quince.infragistics.com/#/Main/ViewPattern$pattern=Journal+Navigation を参照してください)。これにより、このパターンと共に Frame を使用して、さまざまなページに移動する Web エクスペリエンスを模倣することができます。これは、プレースホルダー手法を実装する効果的な方法になる可能性があります (詳細については、msdn.microsoft.com/ja-jp/library/ms750478.aspx を参照してください)。

また、WPF (および Silverlight) には、Composite Application Guidance (CAG: 旧称 Prism) という、CAB に似たフレームワークがあります (詳細については、msdn.microsoft.com/en-us/library/cc707819.aspx (英語) を参照してください)。このフレームワークは、先ほど Windows フォームで説明したのと同様の方法で使用できます。CAG では、Regions (領域) の概念がサポートされます。これは、大規模レイアウト内のコンテナーまたはプレースホルダーとして使用することができ、入れ子にすることもできます。Expression Blend で作業している場合は (現時点では必須)、Expression Blend と Prism をうまく連携させためのさまざまな項目の整理に関する優れたガイダンスを参考にできます (このガイダンスについては、johnpapa.net/silverlight/using-blend-with-prism-apps-in-silverlight-3/ (英語) を参照してください)。

スタイル、テンプレート、プレースホルダーを備えたメイン ビュー、およびユーザー コントロール (または複数のページから成る Frame コントロール) を組み合わせて使用すれば、WPF で非常に管理しやすいデザイン フレームワークを実装することができます。

Silverlight

Silverlight は事実上 WPF のサブセットであり、マイクロソフトから公式に発表されている Silverlight の目標は、Silverlight と WPF 間でソース (XAML) の互換性を 100% 確保することなので、WPF に関して説明したほとんどのことを Silverlight に当てはめることができます (もちろん、いくつか例外はあります)。

まず、コア Silverlight には、Page の正式な概念がなく、基本的に、すべて Control か UserControl になります。Silverlight 3 には、ナビゲーション フレームワークが追加されています。このフレームワークでは、ホストしている "ページ" の Frame クラス、UserControl から派生した Page クラス、およびブラウザーのタイトル バーを自動的に更新する Title プロパティが追加されます。これらは、Journal Navigation の実装なので、Web 手法を模倣できます (これは、WPF の場合と同じです。ただし、このコラムの執筆時点では、この実装ではソースの互換性は保たれません。詳細については、msdn.microsoft.com/ja-jp/library/cc838245(VS.95).aspx を参照してください)。ページに移動するのではなく、ページに偽装しているユーザー コントロールに移動します。しかし、プレースホルダーを使用して、共有の全体レイアウトと要素を定義するという概念は変わりません。WPF では、UI の特定領域 (プレースホルダー) の表示要素を、新しい表示要素 (一般的にユーザー コントロール) に置き換える作業を手動で管理できます。

スタイル設定とテンプレートに関しては、WPF と Silverlight はほぼ同じです。ただし、Silverlight には、VisualStateManager が用意されています。これを使用すると、コントロール (またはユーザー コントロール) の開発者は、セマンティックな状態と状態のグループを定義できます。このコラムの主旨からは、主に、VSM がコントロール テンプレートのカスタマイズ方法に影響することを意味しています。WPF の VisualStateManager は、現在ツールキットに含まれています (詳細については、windowsclient.net/wpf/wpf35/wpf-35sp1-toolkit-visual-state-manager-overview.aspx (英語) を参照してください)。

また、Silverlight はそれだけを使用するか、まったく使用しないかという絶対的な選択肢ではないため、ASP.NET と併用して、ASP.NET を包括的なデザイン フレームワークの実現手段として使用できます。この方法を使用する場合は、標準の Web テクノロジ (CSS と HTML) のスタイル設定と、Silverlight のスタイル設定の統合を管理することになることを念頭に置いておいてください。

WPF と Silverlight の違いの詳細については、msdn.microsoft.com/ja-jp/library/cc903925(VS.95).aspx を参照してください。

SketchFlow

このコラムの執筆時点では SketchFlow はリリースされたばかりです。SketchFlow は、(SketchFlow プロジェクトが 1 つのテクノロジを対象にするにもかかわらず) WPF と Silverlight をサポートします。ただし、デザイン フレームワークの管理に関して独自の考え方がいくつかあります。また、多くの開発者がこれらの .NET テクノロジのプロトタイプを作成するために SketchFlow を使用すると思われるため、説明しておく価値があると考えました。SketchFlow はこれらの 2 つのテクノロジ上で実行されますが、いくつか異なる用語 (主に Screens と Component Screens) を使用しています。

Screen は、基本的にユーザーが操作する画面のようなものです (SketchFlow マップでは、画面間の表示上のナビゲーション接続を作成できます)。これは通常、Screen にきちんと区別された UI が含まれていて、その有効期間とレイアウトが保証されることを意味します。Component Screens は、基本的にちょっとした画面を他の画面と共有する簡単な方法です。これは、ユーザー コントロールに非常によく似ています (実際、Component Screen は、コード内で UserControls を作成します)。

プロトタイプ作成 (特に初期のプロトタイプ作成) の特徴の 1 つは、デザイン フレームワークのようなものについて考えすぎないことですが、どこかの時点ではこうした検討を開始することをお勧めします。プロトタイプの作成が 1 ページや 2 ページといった枠を超え、反復処理や微調整を行う予定がある場合は、プロトタイプの管理を容易にするためにも、共通部分を共有する方法についての検討を開始する必要があります。ただし、SketchFlow のプロトタイプから最終実装までのストーリーがあったとしても、これは SketchFlow が目指すところではありません。

デザイン フレームワークの詳細実装については、おそらく構築の開始を決めるまで待機できるとお考えでしょう。この点では、ユーザーまたはデザイン担当者が労を惜しまず詳細を定義すれば、いくつかまたは多数の Component Screen と、いくつかのスタイル、(Visual State Manager における) 状態、および関連するストーリーボードを使用することができます。

コモン コントロールを使用する

アプリケーション内およびアプリケーション間で一貫性のあるデザイン フレームワークを実装するのに役立つフレームワークやツール以外にも、ソリューションを他のデザイン フレームワークにマップする際のデザイン フレームワークの一貫性についても考慮すべきです。このような場合に、UI パターンを使用します。UI パターンでは、関連する問題を解決する最適かつ一般的な方法を選択して実装できます。

繰り返しになりますが、開発者はずっと、エンド ユーザーが使い慣れた (Excel や Outlook のような) ソリューションを模倣することによって、(そして当然ながら) 組み込みで提供されているコントロールを使用することによって、こうした作業を無意識のうちに、または意図的に行ってきたように思われます。これまであまり考慮されていませんが、限られたコントロール セットによってもたらされる一貫性については言えることがあります。たとえば、Drop Down Chooser については、既に組み込まれているため、実装方法についてはあまり心配する必要はありません (Drop Down Chooser の詳細については、quince.infragistics.com/#/Main/ViewPattern$pattern=Drop+Down+Chooser を参照してください)。同様に、中核となるフレームワーク ライブラリに含まれていない、複雑でも使い慣れたインターフェイスでは、サード パーティ製機能による処理を利用して、OutlookBar や Ribbon などの項目の優れた実装を提供できます。

こうしたコモン コントロールは、ほとんどの (ビジネス) アプリケーションがその内部で作成される共有の汎用デザイン フレームワークと考えることができます。このような共有デザイン フレームワークを使用して、その親しみやすさを活用します。「人々が "直観的" と言うときは、概ね "親しみやすい" と言っているのと同じ」と言った人がいます (詳細については、portal.acm.org/citation.cfm?id=584629 (英語) を参照してください)。そのため、使い慣れた UI コントロールを使用すれば、多くの場合、インターフェイスが直感的に見えるようになります。

同時に、アプリケーションのニーズに基づいてコントロールを選択しなければならないことを念頭においてください。ただ使い慣れているから、あるいは Microsoft Office で使用されているからといった理由で、コントロールを軽率に選択しないようにしてください。

こういった判断をよりすばやく下すのに役立つのが、Quince のような、UI パターンと UX パターンの優れたライブラリです (詳細については、quince.infragistics.com を参照してください)。パターンの「問題」、「解決策」、「背景」、および「説明」の各セクションをお読みください。これらの文章は短く、特定のパターン (コントロールとして実装される場合がほとんどです) がコンテキストに適しているかどうかを識別するのにとても役立ちます。多くの代替策が提供されている「タグ」セクションを使用して他の使用可能な代替策を探すこともできます。

まとめ

このコラムでは、さまざまな .NET UI テクノロジで .NET 機能を実現する方法を簡単に紹介してきました。こうした機能を、読者自身またはデザイン担当者が行っている一貫性のあるフレームワークを定義する取り組みに当てはめて利用し、管理しやすいものにしていくことで、開発中にこのフレームワークを改良したり、運用中にアプリケーションをメンテナンスする際に継続的に繰り返し改良できるようになります。