Visual Studio のアプリケーションパターン

Window interactions

Visual Studio で使用される 2 つの主なウィンドウの種類は、ドキュメントエディターとツールウィンドウです。まれですが、可能な場合は、大きなモードレスダイアログです。これらはすべてシェルではモードレスですが、パターンは根本的に異なります。このセクションでは、ドキュメントウィンドウ、ツールウィンドウ、モードレスダイアログの違いについて説明します。 Modal dialog patterns are covered in Dialogs.

ウィンドウの使用パターンの比較

Document windows are almost always displayed within the document well. これにより、ドキュメントエディターに補助ツールウィンドウを配置するための "中央ステージ" が提供されます。

A tool window is most often displayed as a separate, smaller window collapsed against the edge of the IDE. これは、表示、非表示、または自動非表示にすることができます。 However, sometimes tool windows are presented within the document well, by unchecking the Window/Docking property on the window. これにより、より多くの不動産が得られますが、一般的な設計上の決定でもあります。Visual Studio に統合する場合は、機能でツールウィンドウとドキュメントウィンドウのどちらを表示するかを決定する必要があります。

Modeless dialogs are discouraged in Visual Studio. ほとんどのモードレスダイアログは、定義上、浮動ツールウィンドウであり、そのように実装する必要があります。モードレスダイアログは、シェルの側面にドッキングされた通常のツールウィンドウのサイズが制限されすぎる場合に使用できます。また、ユーザーがダイアログをセカンダリモニターに移動する可能性が高い場合にも使用できます。

必要なコンテナーの種類を慎重に検討してください。 UI デザインの一般的な使用パターンに関する考慮事項を次の表に示します。

	Document window	Tool window	Modeless dialog
Position	常にドキュメントウェル内に配置され、IDE の端をドッキングしません。メインシェルとは別に浮動するように "プルオフ" できます。	通常、IDE の端の周りにタブドッキングされますが、フローティング、自動非表示 (固定解除)、またはドキュメントウェル内にドッキングするようにカスタマイズできます。	IDE とは別の大きなフローティングウィンドウ。
Commit model	Delayed commit ドキュメントにデータを保存するには、[ファイル] > [名前を付けて保存]、[すべて保存] コマンドを発行する必要があります。ドキュメントウィンドウには、その中のデータが "汚れた" という概念があり、その後、保存コマンドのいずれかにコミットされます。ドキュメントウィンドウを閉じると、すべてのコンテンツがディスクに保存されるか、失われます。	Immediate commit 保存モデルはありません。ファイルの編集を支援するインスペクターツールウィンドウの場合、ファイルはアクティブなエディターまたはデザイナーで開く必要があり、エディターまたはデザイナーが保存を所有している必要があります。	遅延コミットまたは即時コミット多くの場合、大きなモードレスダイアログでは、変更をコミットするためのアクションが必要であり、ダイアログセッション内で行われた変更をロールバックする "キャンセル" 操作が可能になります。これにより、モードレスダイアログは、そのツールウィンドウ内のツールウィンドウと常に即時コミットモデルを備えています。
Visibility	開く/作成する (ファイル)、閉じるドキュメントウィンドウを開くには、既存のドキュメントを開くか、テンプレートを使用して新しいドキュメントを作成します。 "open <specific editor>" コマンドはありません。	非表示と表示単一インスタンスのツールウィンドウは非表示にすることも表示することもできます。ツールウィンドウ内の内容と状態は、表示中でも非表示でも保持されます。マルチインスタンスツールウィンドウは、非表示と同様に閉じることができます。マルチインスタンスツールウィンドウを閉じると、ツールウィンドウ内のコンテンツと状態は破棄されます。	コマンドから起動ダイアログは、タスクベースのコマンドから起動されます。
Instances	Multi-instance 複数のエディターを同時に開いて異なるファイルを編集できますが、一部のエディターでは複数のエディターで同じファイルを開くこともできます ( [ウィンドウ] > [新しいウィンドウ ] コマンドを使用)。 1 つのエディターで、1 つまたは複数のファイルを同時に編集できます (プロジェクトデザイナー)。	単一インスタンスまたは複数インスタンスコンテンツは、(プロパティブラウザーのように) コンテキストを反映するか、フォーカス/コンテキストを他のウィンドウ (タスクリスト、ソリューションエクスプローラー) にプッシュするように変更されます。説得力のある理由がない限り、単一インスタンスとマルチインスタンスの両方のツールウィンドウをアクティブなドキュメントウィンドウに関連付ける必要があります。	Single-instance
Examples	Text editors, like the code editor Design surfaces, like a form designer or a modeling surface マニフェストデザイナーなどのダイアログに似たコントロールレイアウト	The Solution Explorer provides a solution and projects contained within the solution The Server Explorer provides a hierarchical view of servers and data connections that the user chooses to open in the window. クエリなどのデータベース階層からオブジェクトを開くと、ドキュメントウィンドウが開き、ユーザーがクエリを編集できるようになります。 The Property Browser displays properties for the object selected either in a document window or another tool window. これらのプロパティは、階層グリッドビューまたは複雑なダイアログのようなコントロールで表示され、ユーザーはそれらのプロパティの値を設定できます。

Tool windows

ツールウィンドウは、ドキュメントウィンドウで発生するユーザーの作業をサポートします。これらは、Visual Studio が提供し、操作できる基本的なルートオブジェクトを表す階層を表示するために使用できます。

IDE で新しいツールウィンドウを検討する場合、作成者は次のことを行う必要があります。

タスクに適した既存のツールウィンドウを使用し、同様の機能を持つ新しいツールウィンドウを作成しないでください。新しいツールウィンドウは、類似のウィンドウに統合できない、または既存のウィンドウをピボットハブに変換することによって、大幅に異なる "ツール" または機能を提供する場合にのみ作成する必要があります。
必要に応じて、ツールウィンドウの上部にある標準のコマンドバーを使用します。
プレゼンテーションとキーボードナビゲーションを制御するために、他のツールウィンドウに既に存在するパターンと一貫性を保ちます。
他のツールウィンドウでのコントロールの表示と一貫性を保ちます。
ドキュメント固有のツールウィンドウを可能な限り自動的に表示し、親ドキュメントがアクティブになったときにのみ表示されるようにします。
ウィンドウの内容がキーボードでナビゲート可能であることを確認します (方向キーをサポートします)。

ツールウィンドウの状態

Visual Studio ツールウィンドウにはさまざまな状態があり、その一部はユーザーがアクティブ化されます (自動非表示機能など)。自動表示などのその他の状態では、ツールウィンドウを正しいコンテキストで表示し、不要なときに非表示にすることができます。合計で 5 つのツールウィンドウの状態があります。

Docked/pinned tool windows can be attached to any of the four sides of the document area. ツールウィンドウのタイトルバーにプッシュピンアイコンが表示されます。ツールウィンドウは、シェルや他のツールウィンドウの端に沿って水平方向または垂直方向にドッキングでき、タブリンクすることもできます。
Auto-hidden tool windows are unpinned. ウィンドウは、ドキュメント領域の端にタブ (ツールウィンドウの名前とそのアイコン) を残して、見えなくなることがあります。ユーザーがタブの上にマウスポインターを置くと、ツールウィンドウがスライドアウトします。
Auto-visible tool windows automatically appear when another piece of UI, like an editor, is launched or gains focus.
Floating tool windows hover outside the IDE. これは、マルチモニター構成に役立ちます。
Tabbed document tool windows can be docked within the document well. これは、オブジェクトブラウザーなどの大きなツールウィンドウで、フレームの端にドッキングするよりも多くの不動産を必要とする場合に便利です。

0702-01_ToolWindowStates Visual Studio の
Visual Studio のツールウィンドウの状態

単一インスタンスとマルチインスタンス

ツールウィンドウは、単一インスタンスまたは複数インスタンスのいずれかです。一部の単一インスタンスツールウィンドウは作業中のドキュメントウィンドウに関連付けられている場合もあれば、マルチインスタンスツールウィンドウには関連付けられていない場合があります。マルチインスタンスツールウィンドウは、 ウィンドウの新しいインスタンスを作成することで、ウィンドウ > 新しいウィンドウ コマンドに応答します。次の図は、ウィンドウのインスタンスがアクティブな場合に [新しいウィンドウ] コマンドを有効にするツールウィンドウを示しています。

ウィンドウのインスタンスがアクティブな場合に "新しいウィンドウ" コマンドを有効にするツールウィンドウ

単一インスタンスのツールウィンドウは非表示にすることも表示することもできますが、複数インスタンスのツールウィンドウは非表示にすることもできます。すべてのツールウィンドウは、ドッキング、タブリンク、フローティング、または Multiple-Document インターフェイス (MDI) 子ウィンドウ (ドキュメントウィンドウと同様) として設定できます。すべてのツールウィンドウは、[ウィンドウ] メニューの適切なウィンドウ管理コマンドに応答する必要があります。

Visual Studio ウィンドウメニューのウィンドウ管理コマンド
Visual Studio ウィンドウメニューのウィンドウ管理コマンド

ドキュメント固有のツールウィンドウ

一部のツールウィンドウは、特定の種類のドキュメントに基づいて変更するように設計されています。これらのウィンドウは、IDE のアクティブなドキュメントウィンドウに適用できる機能を反映するように継続的に更新されます。

選択したエディターを反映するように内容が変更されるツールウィンドウの例として、[ツールボックス] と [ドキュメントアウトライン] があります。これらのウィンドウは、エディターにウィンドウにコンテキストを提供しないフォーカスがある場合に透かしを表示します。

ナビゲーション可能なリストツールウィンドウ

一部のツールウィンドウには、ユーザーが操作できるナビゲーション可能な項目の一覧が表示されます。この種類のウィンドウでは、ウィンドウが非アクティブな場合でも、リスト内の現在のアイテムに対するフィードバックが常に存在する必要があります。 The list should respond to the GoToNextLocation and GoToPrevLocation commands by also changing the currently selected item in the window

ナビゲーション可能なリストツールウィンドウの例として、ソリューションエクスプローラーと [結果の検索] ウィンドウがあります。

ツールウィンドウの種類

一般的なツールウィンドウとその機能

階層型ツールウィンドウ

Tool window	Function
ソリューションエクスプローラ	プロジェクト、その他のファイル、およびソリューション項目に含まれるドキュメントの一覧を表示する階層ツリー。プロジェクト内の項目の表示は、プロジェクトの種類 (参照ベース、ディレクトリベース、混合モードの種類など) を所有するパッケージによって定義されます。
クラスビュー	ファイル自体に関係なく、ドキュメントのワーキングセット内のクラスとさまざまな要素の階層ツリー。
サーバーエクスプローラ	ソリューション内のすべてのサーバーとデータ接続を表示する階層ツリー。
Document Outline	作業中の文書の階層構造。

グリッドツールウィンドウ

Tool window	Function
プロパティ	選択したオブジェクトのプロパティの一覧と、それらのプロパティを編集するための値ピッカーを表示するグリッド。
タスク一覧	ユーザーがタスクとコメントを作成、編集、削除できるようにするグリッド。

コンテンツツールウィンドウ

Tool window	Function
Help	ユーザーが「方法」ビデオから MSDN フォーラムまで、さまざまな方法でヘルプを取得できるウィンドウ。
Dynamic Help	現在の選択範囲に適用できるヘルプトピックへのリンクを表示するツールウィンドウ。
Object Browser	左側のペインに階層オブジェクトコンポーネントの一覧が表示され、右側の列にオブジェクトのプロパティとメソッドが含まれる 2 列のフレームセット。

ダイアログツールウィンドウ

Tool window	Function
Find	ユーザーがソリューション内のさまざまなファイルを検索または検索して置き換えることができるダイアログ。
Advanced Find	ユーザーがソリューション内のさまざまなファイルを検索または検索して置き換えることができるダイアログ。

その他のツールウィンドウ

Tool window	Function
Toolbox	デザインサーフェイスにドロップされる要素を格納するために使用されるツールウィンドウは、すべてのデザイナーに一貫したドラッグソースを提供します。

デバッガーツールウィンドウ

Tool window	Function
Autos
Immediate
Output	出力ウィンドウは、宣言するテキストイベントまたは状態がある場合に常に使用できます。
Memory
Breakpoints
Running
Documents
Call Stack
Locals
Watches
Disassembly
Registers
Threads

ドキュメントエディターの規則

Document interactions

"ドキュメントウェル" は IDE 内で最大の領域であり、補助ツールウィンドウを使用してタスクを完了するためにユーザーが注意を集中している場所です。ドキュメントエディターは、ユーザーが Visual Studio 内で開いて保存する基本的な作業単位を表します。ソリューションエクスプローラーまたはその他のアクティブな階層ウィンドウに関連付けられた選択の強い感覚が保持されます。ユーザーは、これらの階層ウィンドウのいずれかをポイントし、ドキュメントが含まれている場所と、Visual Studio パッケージによって提供されるソリューション、プロジェクト、または別のルートオブジェクトとの関係を把握できる必要があります。

ドキュメントの編集には、一貫したユーザーエクスペリエンスが必要です。ユーザーがウィンドウ管理やコマンドの検索ではなく、手元のタスクに集中できるようにするには、そのドキュメントの種類を編集するためのユーザータスクに最適なドキュメントビュー戦略を選択します。

ドキュメントウェルの一般的な操作

Maintain a consistent interaction model in the common New File and Open File experiences.
ドキュメントウィンドウが開いたときに、関連するウィンドウとメニューの関連機能を更新します。
Menu commands are appropriately integrated into common menus like Edit, Format, and View menus. 大量の特殊なコマンドを使用できる場合は、新しいメニューを作成できます。この新しいメニューは、ドキュメントにフォーカスがある場合にのみ表示されます。
埋め込みツールバーは、エディターの上部に配置できます。これは、エディターの外部に表示される別のツールバーを使用する場合に適しています。
ソリューションエクスプローラーまたは同様のアクティブ階層ウィンドウで、常に選択を維持します。
Double-clicking a document in the Solution Explorer should perform the same action as Open.
If more than one editor can be used on a document type, the user should be able to override or reset the default action on a given document type using the Open With dialog box by right-clicking on the file and selecting Open With from the shortcut menu.
ドキュメントウェルにウィザードを作成しないでください。

特定のドキュメントの種類に対するユーザーの期待

ドキュメントエディターにはいくつかの種類の基本的な種類があり、それぞれに同じ種類の他のエディターと一致する一連の対話があります。

Text-based editor: code editor, log files
Design surface: WPF forms designer, Windows forms
Dialog-style editor: Manifest Designer, project properties
Model designer: workflow designer, codemap, architecture diagram, progression

ドキュメントウェルを使用するエディター以外の種類もあります。ドキュメント自体は編集しませんが、ドキュメントウィンドウの標準的な操作に従う必要があります。

Reports: IntelliTrace report, Hyper-V report, profiler report
Dashboard: Diagnostics Hub

Text-based editors

ドキュメントはプレビュータブモデルに参加し、開かずにドキュメントをプレビューできます。
ドキュメントの構造は、ドキュメントアウトラインなどのコンパニオンツールウィンドウ内で表される場合があります。
IntelliSense (必要に応じて) は、他のコードエディターと一貫して動作します。
ポップアップまたは支援 UI は、CodeLens などの既存の同様の UI に対して同様のスタイルとパターンに従います。
ドキュメントの状態に関するメッセージは、ドキュメントの上部またはステータスバーの情報バーコントロールに表示されます。
ユーザーは、[ ツール] > [オプション] ページ (共有の [フォントと色] ページ、またはエディター固有のページ) を使用して、フォントと色の外観をカスタマイズできる必要があります。

Design surfaces

空のデザイナーには、作業を開始する方法を示す透かしが表面に表示されている必要があります。
ビュー切り替えメカニズムは、ダブルクリックしてコードエディターを開くなどの既存のパターンに従います。また、ドキュメントウィンドウ内のタブを使用して両方のペインと対話できます。
高度に特定のツールウィンドウが必要な場合を除き、ツールボックスを使用してデザインサーフェイスに要素を追加する必要があります。
サーフェス上の項目は、一貫した選択モデルに従います。
Embedded toolbars contain document-specific commands only, not common commands such as Save.

Dialog-style editors

コントロールレイアウトは、通常のダイアログレイアウト規則に従う必要があります。
エディター内のタブは、ドキュメントタブの外観と一致しない必要があります。これらは、2 つの許可されている内部タブスタイルのいずれかと一致する必要があります。
ユーザーはキーボードのみを使用してコントロールを操作できる必要があります。エディターをアクティブ化し、コントロールを使ってタブ移動するか、標準ニーモニックを使用します。
デザイナーでは、一般的な保存モデルを使用する必要があります。他のボタンが適切な場合もありますが、全体的な保存ボタンやコミットボタンはサーフェス上に配置しないでください。

Model designers

空のデザイナーには、作業を開始する方法を示す透かしが表面に表示されている必要があります。
デザインサーフェイスに要素を追加するには、ツールボックスを使用する必要があります。
サーフェス上の項目は、一貫した選択モデルに従います。
Embedded toolbars contain document-specific commands only, not common commands such as Save.
凡例は、サーフェス上に表示される場合があります。これは、示す値または透かしです。
ユーザーは、[ ツール] > [オプション] ページ (共有の [フォントと色] ページ、またはエディター固有のページ) を使用して、フォント/色の外観をカスタマイズできる必要があります。

Reports

通常、レポートは情報のみであり、保存モデルには参加しません。ただし、他の関連情報へのリンクや、展開と折りたたみを行うセクションへのリンクなどの相互作用が含まれる場合があります。
サーフェス上のほとんどのコマンドは、ボタンではなくハイパーリンクにする必要があります。
レイアウトにはヘッダーを含め、標準のレポートレイアウトガイドラインに従う必要があります。

Dashboards

ダッシュボードには対話モデル自体はありませんが、他のさまざまなツールを提供する手段として機能します。
保存モデルには参加しません。
ユーザーは、エディターをアクティブ化し、コントロールを使ってタブ移動するか、標準ニーモニックを使用して、キーボードのみを使用してコントロールを操作できる必要があります。

Dialogs

Introduction

通常、Visual Studio のダイアログでは、ユーザーの作業の個別の単位が 1 つサポートされ、閉じる必要があります。

ダイアログが必要であると判断した場合は、優先順に次の 3 つの選択肢があります。

Visual Studio の共有ダイアログのいずれかに機能を統合します。
既存の同様のダイアログで見つかったパターンを使用して、独自のダイアログを作成します。
対話とレイアウトのガイドラインに従って、新しいダイアログを作成します。

このセクションでは、Visual Studio ワークフロー内で正しいダイアログパターンを選択する方法と、ダイアログデザインの一般的な規則について説明します。

Themes

Visual Studio のダイアログは、次の 2 つの基本的なスタイルのいずれかに従います。

Standard (unthemed)

ダイアログの大部分は標準のユーティリティダイアログであり、未設定にする必要があります。一般的なコントロールのテンプレートを再作成したり、スタイル化された "モダン" ボタンやコントロールの作成を試みたりしないでください。コントロールとクロムの外観は、ダイアログボックスの標準的な Windows デスクトップ操作ガイドラインに従います。

Themed

特殊な "署名" ダイアログをテーマにすることもできます。テーマ付きダイアログは、スタイルに関連付けられたいくつかの特別な相互作用パターンを持つ、個別の外観を持ちます。ダイアログにテーマを設定するのは、次の要件を満たしている場合のみです。

The dialog is a common experience that will be seen and used often or by many users (for example, the New Project dialog.
The dialog contains prominent product brand elements (for example, the Account Settings dialog).
ダイアログは、他のテーマ付きダイアログ ([接続済み サービスの追加 ] ダイアログなど) を含む、より大きなフローの不可欠な部分として表示されます。
このダイアログは、製品バージョンの昇格または差別化において戦略的な役割を果たすエクスペリエンスの重要な部分です。

テーマ付きダイアログを作成するときは、適切な環境の色を使用し、正しいレイアウトと相互作用パターンに従います。 ( Visual Studio のレイアウトを参照してください)。

Dialog design

適切に設計されたダイアログでは、次の要素が考慮されます。

サポートされているユーザータスク
ダイアログテキストのスタイル、言語、用語
コントロールの選択と UI の規則
ビジュアルレイアウトの仕様とコントロールの配置
Keyboard access

Content organization

これらの基本的な種類のダイアログの違いを考慮してください。

Simple dialogs present controls in a single modal window. プレゼンテーションには、フィールドピッカーやアイコンバーなど、複雑なコントロールパターンのバリエーションが含まれる場合があります。
Layered dialogs are used to make the most of screen real estate when a single piece of UI comprises multiple groups of controls. ダイアログのグループ化は、タブコントロール、ナビゲーションリストコントロール、またはボタンによって "階層化" されるため、ユーザーは任意の時点で表示するグループを選択できます。
Wizards are useful for directing the user through a logical sequence of steps toward the completion of a task. 一連の選択肢はシーケンシャルパネルで提供され、前のパネルで行われた選択に応じて異なるワークフロー ("分岐") が導入される場合があります。

Simple dialogs

単純なダイアログは、単一のモーダルウィンドウ内のコントロールのプレゼンテーションです。このプレゼンテーションには、フィールドピッカーなど、複雑なコントロールパターンのバリエーションが含まれる場合があります。単純なダイアログの場合は、標準の一般的なレイアウトと、複雑なコントロールのグループ化に必要な特定のレイアウトに従います。

>厳密な名前キーの作成は、Visual Studio の単純なダイアログの例です。
厳密な名前キーの作成は、Visual Studio の単純なダイアログの例です。

Layered dialogs

階層化されたダイアログには、タブ、ダッシュボード、埋め込みツリーが含まれます。これらは、1 つの UI で複数のコントロールグループが提供されている場合に、不動産を最大化するために使用されます。グループ化は階層化されるため、ユーザーは一度に表示するグループを選択できます。

最も簡単なケースでは、グループ化を切り替えるメカニズムはタブコントロールです。利用できる代替手段がいくつかあります。最も適切なスタイルを選択する方法については、「優先順位付けとレイヤー化」を参照してください。

[ ツール > オプション] ダイアログは、埋め込みツリーを使用した階層化ダイアログの例です。

ツール > オプションは、Visual Studio の階層化されたダイアログの例です。

Wizards

ウィザードは、タスクの完了時に論理的な一連の手順をユーザーに指示するのに役立ちます。シーケンシャルパネルには一連の選択肢が用意されており、ユーザーは次に進む前に各手順を続行する必要があります。 Once sufficient defaults are available, the Finish button is enabled.

モーダルウィザードは、次のタスクに使用されます。

ユーザーの選択に応じて異なるパスが提供される分岐を含む
ステップ間の依存関係が含まれています。後続のステップは、前の手順のユーザー入力に依存します
UI を使用して、提供される選択肢と各ステップで可能な結果を説明する必要がある、十分に複雑です
トランザクションであり、変更がコミットされる前に一連の手順を完全に完了する必要がある

Common conventions

ダイアログで最適なデザインと機能を実現するには、ダイアログのサイズ、位置、標準、コントロールの構成と配置、UI テキスト、タイトルバー、コントロールボタン、アクセスキーに関するこれらの規則に従います。

レイアウト固有のガイドラインについては、「 Visual Studio のレイアウト」を参照してください。

Size

ダイアログは最小 1024 x 768 画面解像度に収まる必要があり、初期ダイアログサイズは 900 x 700 ピクセルを超えないようにする必要があります。ダイアログはサイズ変更可能な場合がありますが、必須ではありません。

サイズ変更可能なダイアログには、次の 2 つの推奨事項があります。

最小サイズは、クリッピングなしでコントロールセット用に最適化し、適切なローカライズの増加に対応するように調整するダイアログに対して定義されます。
ユーザースケールサイズがセッション間で保持されます。たとえば、ユーザーがダイアログを 150%にスケーリングすると、ダイアログの後続の起動が 150%に表示されます。

Position

ダイアログは、最初の起動時に IDE 内の中央に表示される必要があります。サイズ変更できないダイアログの最後の位置は永続化する必要がないため、後続の起動時に中央に表示されます。

サイズ変更可能なダイアログの場合は、以降の起動時にサイズを保持する必要があります。サイズ変更可能なモーダルダイアログの場合、位置を永続化する必要はありません。 IDE 内の中央に表示すると、ユーザーの表示構成が変更されたときに、ダイアログが予期しない、または使用できない位置に表示される可能性を防ぐことができます。

位置を変更できるモードレスダイアログの場合、ダイアログは大きなワークフローの不可欠な部分として頻繁に使用される可能性があるため、後続の起動時にユーザーの位置を維持する必要があります。

ダイアログが他のダイアログを生成する必要がある場合、最上位のダイアログは親から右と下にカスケードして、新しい場所に移動したことをユーザーに明らかにします。

Modality

モーダルとは、続行する前にユーザーがダイアログを完了またはキャンセルする必要があることを意味します。モーダルダイアログはユーザーが環境の他の部分と対話するのをブロックするため、機能のタスクフローでは可能な限り控えめに使用する必要があります。モーダル操作が必要な場合、Visual Studio には、機能を統合できる共有ダイアログが多数用意されています。新しいダイアログを作成する必要がある場合は、同様の機能を持つ既存のダイアログの対話パターンに従います。

When users need to perform two activities at once, like Find and Replace while writing new code, the dialog should be modeless so that the user can easily switch between them. Visual Studio では、通常、この種のエディターをサポートするリンクされたタスクにツールウィンドウが使用されます。

Control configuration

Visual Studio で同じことを実行する既存のコントロール構成と一貫性を保つ。

Title bars

タイトルバーのテキストには、起動したコマンドの名前が反映されている必要があります。
ダイアログタイトルバーではアイコンを使用しないでください。システムに必要な場合は、Visual Studio ロゴを使用します。
ダイアログに最小化ボタンや最大化ボタンを含めないようにする必要があります。
タイトルバーのヘルプボタンは非推奨になりました。新しいダイアログには追加しないでください。存在する場合は、タスクに概念的に関連するヘルプトピックを起動する必要があります。

Visual Studio ダイアログのタイトルバーのガイドライン仕様

Control buttons

In general, OK, Cancel, and Help buttons should be arranged horizontally in the lower right corner of the dialog. ダイアログの下部に、コントロールボタンと視覚的な混乱を招く他のボタンがダイアログにある場合は、代替垂直スタックが許可されます。

0704-04_ControlButtonConfig Visual Studio ダイアログ
Visual Studio ダイアログのコントロールボタンに対して許容される構成

ダイアログには、既定のコントロールボタンが含まれている必要があります。 This is a button that is invoked by pressing the Enter key - see Button IsDefault .To determine the best command to use as the default, choose from the following options (listed in order of precedence):

既定として、最も安全で最も安全なコマンドを選択します。これは、データ損失を防ぎ、意図しないシステムアクセスを回避する可能性が最も高いコマンドを選択することを意味します。
データ損失とセキュリティが要因でない場合は、利便性に基づいて既定のコマンドを選択します。最も可能性の高いコマンドを既定値として含めると、ダイアログで頻繁または反復的なタスクがサポートされている場合に、ユーザーのワークフローが改善されます。

既定のコマンドに対して永続的に破壊的なアクションを選択しないでください。このようなコマンドが存在する場合は、代わりに既定として安全なコマンドを選択します。

Access keys

Do not use access keys for OK or Cancel. Enter and Escape shortcuts can be set with Button IsDefault and Button IsCancel respectively.

Imagery

ダイアログでイメージを控えめに使用します。スペースを使い切るためだけに、ダイアログで大きなアイコンを使用しないでください。警告アイコンやステータスアニメーションなど、メッセージをユーザーに伝える重要な部分である場合にのみ、画像を使用します。

優先順位付けと階層化

UI の優先順位付け

特定の UI 要素を最前線に配置し、より高度な動作とオプション (不明瞭なコマンドを含む) をダイアログに配置することが必要な場合があります。一般的に使用される機能を最前線に持ち込むには、その領域を用意し、ダイアログが表示されたときにテキストラベルを含む UI に既定で表示されるようにします。

UI のレイヤー化

ダイアログが必要であると判断したが、ユーザーに提示する関連機能が単純なダイアログに表示できる機能を超えている場合は、UI をレイヤー化する必要があります。 Visual Studio で使用される最も一般的なレイヤー方法は、タブと廊下またはダッシュボードです。場合によっては、展開および折りたたみ可能な領域が適切な場合があります。アダプティブ UI は通常、Visual Studio では推奨されません。

タブのようなコントロールを使用して UI を階層化するさまざまな方法には、長所と短所があります。次の一覧を確認して、状況に適した階層化手法を選択していることを確認します。

Tabbing

Switching mechanism	利点と適切な使用	欠点と不適切な使用
Tab control	ダイアログページを関連セットに論理的にグループ化するダイアログ内の関連コントロールのページが 5 ページ未満 (またはダイアログ全体の 1 行に収まるタブの数) に役立ちますタブラベルは短くする必要があります。コンテンツを簡単に識別できる 1 つまたは 2 つの単語共通のシステムダイアログスタイル例: エクスプローラー > 項目のプロパティ	説明的な短いラベルを作成するのは難しい場合があります一般に、1 つのダイアログで過去 5 つのタブをスケーリングしません 1 行のタブが多すぎる場合は不適切です (別の階層化手法を使用する) Not extensible
Sidebar navigation	タブよりも多くのカテゴリに対応できるシンプルな切り替えデバイスカテゴリのフラットリスト (階層なし) Extensible 例: カスタマイズ... > コマンドの追加	グループが 3 つ未満の場合は、水平方向のスペースを適切に使用できませんタスクはドロップダウンに適している場合があります
Tree control	無制限のカテゴリに対応カテゴリのグループ化や階層化が可能 Extensible 例: ツール > オプション	階層が入れ子になっていると、水平スクロールが過度に発生する可能性があります Visual Studio のツリービューが過剰に多い
Wizard	タスクベースのシーケンシャルステップをユーザーに指示することで、タスクの完了に役立ちます。ウィザードは高レベルのタスクを表し、個々のパネルはタスク全体を達成するために必要なサブタスクを表しますユーザーがタスクを完了するために複数のエディターとツールウィンドウを使用する必要がある場合と同様に、タスクが Ui の境界を越える場合に便利ですタスクに分岐が必要な場合に便利ですタスクにステップ間の依存関係が含まれている場合に便利です 1 つの決定フォークを持ついくつかの類似タスクを 1 つのダイアログに表示して、異なる類似ダイアログの数を減らすことができる場合に便利です。	シーケンシャルワークフローを必要としないタスクには不適切ですユーザーは、手順が多すぎるウィザードに圧倒され、混乱する可能性がありますウィザードには本質的に制限された画面の不動産があります

廊下またはダッシュボード

廊下とダッシュボードは、他のダイアログやウィンドウの開始点として機能するダイアログまたはパネルです。適切に設計された "廊下" では、最も一般的なオプション、コマンド、設定のみがすぐに表示され、ユーザーは一般的なタスクを簡単に実行できます。実際の廊下は、背後の部屋にアクセスするための出入り口を提供するのと同様に、ここではあまり一般的でない UI は、メインの廊下からアクセスできる関連機能の個別の "部屋" (多くの場合、他のダイアログ) に収集されます。

または、あまり一般的でない機能を別々の場所にリファクタリングするのではなく、1 つのコレクションで使用可能なすべての機能を提供する UI は、単なるダッシュボードです。

0704-08_Hallway Outlook
Outlook で追加の UI を公開するための廊下の概念

Adaptive UI

使用状況やユーザーの自己報告エクスペリエンスに基づいて UI を表示または非表示にすることも、他の部分を非表示にしながら必要な UI を表示するもう 1 つの方法です。これは Visual Studio では推奨されません。UI を表示または非表示にするタイミングを決定するためのアルゴリズムは難しい場合があり、一部のケースではルールが常に間違っている可能性があります。

Projects

ソリューションエクスプローラーのプロジェクト

ほとんどのプロジェクトは、参照ベース、ディレクトリベース、または混合として分類されます。ソリューションエクスプローラーでは、3 種類のプロジェクトすべてが同時にサポートされます。プロジェクトを操作するユーザーエクスペリエンスのルートは、このウィンドウ内で行われます。異なるプロジェクトノードは参照、ディレクトリ、または混合モードの種類のプロジェクトですが、プロジェクト固有のユーザーパターンに分岐する前に、開始点として適用する必要がある一般的な相互作用パターンがあります。

プロジェクトは常に次の必要があります。

プロジェクトフォルダーを追加してプロジェクトの内容を整理する機能をサポートする
プロジェクトの永続化のための一貫性のあるモデルを維持する

プロジェクトでは、次の場合に一貫した対話モデルを維持する必要もあります。

プロジェクト項目の削除
Saving documents
プロジェクトプロパティの編集
代替ビューでのプロジェクトの編集
Drag-and-drop operations

ドラッグアンドドロップ操作モデル

通常、プロジェクトは参照ベース (ストレージ内のプロジェクト項目への参照のみを保持できる)、ディレクトリベース (プロジェクトの階層内に物理的に格納されたプロジェクト項目のみを保持できる)、または混合 (参照または物理項目を保持できる) として分類されます。 The IDE accommodates all three types of projects simultaneously within the Solution Explorer.

From a drag-and-drop perspective, the following characteristics should apply to each type of project within the Solution Explorer:

Reference-based project: The key point is that the project is dragging around a reference to an item in storage. 参照ベースのプロジェクトが移動操作のソースとして機能する場合は、プロジェクトから項目への参照のみを削除する必要があります。アイテムは実際にはハードドライブから削除しないでください。参照ベースのプロジェクトが移動 (またはコピー) 操作のターゲットとして機能する場合は、アイテムのプライベートコピーを作成せずに、元のソースアイテムへの参照を追加する必要があります。
Directory-based project: From a drag-and-drop point of view, the project is dragging around the physical item rather than a reference. ディレクトリベースのプロジェクトが移動操作のソースとして機能する場合は、物理的な項目をハードドライブから削除し、プロジェクトから削除する必要があります。ディレクトリベースのプロジェクトが移動 (またはコピー) 操作のターゲットとして機能する場合は、ソースアイテムのコピーをターゲットの場所に作成する必要があります。
Mixed-target project: From a drag-and-drop point of view, the behavior of this type of project is based on the nature of the item being dragged (either a reference to an item in storage or the item itself). 参照と物理項目の正しい動作については、上記で説明します。

If there were only one type of project in the Solution Explorer, then drag-and-drop operations would be straightforward. 各プロジェクトシステムには独自のドラッグアンドドロップ動作を定義する機能があるため、予測可能なユーザーエクスペリエンスを確保するために、(Windows エクスプローラーのドラッグアンドドロップの動作に基づく) 特定のガイドラインに従う必要があります。

An unmodified drag operation in the Solution Explorer (when neither Ctrl nor Shift keys are held down) should result in a move operation.
Shift キーを押しながらドラッグすると、移動操作も行われます。
Ctrl キーを押しながらドラッグすると、コピー操作になります。
参照ベースおよび混合プロジェクトシステムでは、ソース項目にリンク (または参照) を追加する概念がサポートされています。これらのプロジェクトがドラッグアンドドロップ操作のターゲットである場合 ( Ctrl + Shift キー を押したままにすると)、プロジェクトに追加される項目への参照が生成されます

すべてのドラッグアンドドロップ操作が、参照ベース、ディレクトリベース、および混合プロジェクトの組み合わせで適切であるわけではありません。特に、ディレクトリベースのソースプロジェクトと参照ベースのターゲットプロジェクトの間で移動操作を許可するふりをするのは問題です。ソースディレクトリベースのプロジェクトは、移動の完了時にソース項目を削除する必要があるためです。ターゲット参照ベースのプロジェクトは、最終的に削除されたアイテムへの参照になります。

また、ターゲット参照ベースのプロジェクトはソース項目の独立したコピーを作成してはならないため、これらの種類のプロジェクト間でコピー操作を許可するふりをすると誤解を招く可能性があります。同様に、ディレクトリベースのプロジェクトでは参照を保持できないため、Ctrl + Shift キーを押しながらディレクトリベースのターゲットプロジェクトにドラッグすることはできません。ドラッグアンドドロップ操作がサポートされていない場合、IDE はドロップを禁止し、ユーザーにドロップなしのカーソルを表示する必要があります (下のポインターテーブルを参照)。

ドラッグアンドドロップ動作を適切に実装するには、ドラッグのソースプロジェクトがその性質をターゲットプロジェクトに伝える必要があります。 (たとえば、参照ベースかディレクトリベースか)この情報は、ソースによって提供されるクリップボード形式で示されます。ドラッグ (またはクリップボードのコピー操作) のソースとして、プロジェクトは参照ベースかディレクトリベースかに応じて、それぞれ CF_VSREFPROJECTITEMS または CF_VSSTGPROJECTITEMS を提供する必要があります。どちらの形式も同じデータコンテンツを持ちます。これは Windows CF_HDROP 形式に似ていますが、文字列のリストがファイル名ではなく、Projref文字列の二重NULL終了リスト (必要に応じてIVsSolution::GetProjrefOfItemまたは::GetProjrefOfProjectから返される) である点が異なります。

ドロップ (またはクリップボードの貼り付け操作) のターゲットとして、プロジェクトは CF_VSREFPROJECTITEMS と CF_VSSTGPROJECTITEMSの両方を受け入れる必要がありますが、ドラッグアンドドロップ操作の正確な処理は、ターゲットプロジェクトとソースプロジェクトの性質によって異なります。ソースプロジェクトは、 CF_VSREFPROJECTITEMS と CF_VSSTGPROJECTITEMSのどちらを提供するかによって、その性質を宣言します。ドロップのターゲットは、独自の性質を理解しているため、移動、コピー、またはリンクを実行する必要があるかどうかに関する決定を行うのに十分な情報を持っています。また、Ctrl キー、Shift キー、または Ctrl キーと Shift キーの両方を押して、どのドラッグアンドドロップ操作を実行するかをユーザーが変更します。ドロップターゲットでは、 DragEnter および DragOver メソッドで事前に実行する操作を適切に指定することが重要です。 The Solution Explorer automatically knows whether the source project and the target project are the same project.

Visual Studio のインスタンス間でのプロジェクト項目のドラッグ (たとえば、devenv.exe のインスタンス間) は、特にサポートされていません。 The Solution Explorer also directly disables this.

ユーザーは、項目を選択し、ターゲットの場所にドラッグし、項目がドロップされる前に次のマウスポインターのうちどれが表示されるかを観察することで、ドラッグアンドドロップ操作の効果を常に判断できる必要があります。

Mouse pointer	Command	Description
	No drop	指定した場所にアイテムをドロップできません。
	Copy	アイテムはターゲットの場所にコピーされます。
	Move	アイテムはターゲットの場所に移動されます。
	Add reference	選択した項目への参照がターゲットの場所に追加されます。

Reference-based projects

次の表は、ソース項目の性質に基づいて実行するドラッグアンドドロップ (および切り取り/コピー/貼り付け) 操作と、参照先ベースのターゲットプロジェクトで押された修飾子キーをまとめたものです。

Modifier	Category	ソース項目: リファレンス/リンク	ソース項目: 物理項目またはファイルシステム (`CF_HDROP`)
No modifier	Action	Move	Link
No modifier	Target	元のアイテムへの参照を追加します	元のアイテムへの参照を追加します
No modifier	Source	元のアイテムへの参照を削除します	元のアイテムを保持します
No modifier	Result	`DROPEFFECT_MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_LINK` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります
Shift+Drag	Action	Move	No drop
Shift+Drag	Target	元のアイテムへの参照を追加します	No drop
Shift+Drag	Source	元のアイテムへの参照を削除します	No drop
Shift+Drag	Result	`DROPEFFECT_MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	No drop
Ctrl+Drag	Action	Copy	No drop
Ctrl+Drag	Target	元のアイテムへの参照を追加します	No drop
Ctrl+Drag	Source	元のアイテムへの参照を保持します	No drop
Ctrl+Drag	Result	`DROPEFFECT_COPY` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	No drop
Ctrl+Shift+Drag	Action	Link	Link
Ctrl+Shift+Drag	Target	元のアイテムへの参照を追加します	元のアイテムへの参照を追加します
Ctrl+Shift+Drag	Source	元のアイテムへの参照を保持します	元のアイテムを保持します
Ctrl+Shift+Drag	Result	`DROPEFFECT_LINK` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_LINK` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります
Ctrl+Shift+Drag	Note	Windows エクスプローラーのショートカットのドラッグアンドドロップ動作と同じです。
Cut/Paste	Action	Move	Link
Cut/Paste	Target	元のアイテムへの参照を追加します	元のアイテムへの参照を追加します
Cut/Paste	Source	元のアイテムへの参照を保持します	元のアイテムを保持します
Cut/Paste	Result	アイテムはストレージ内の元の場所に残ります	アイテムはストレージ内の元の場所に残ります
Copy/Paste	Action	Copy	Link
Copy/Paste	Source	元のアイテムへの参照を追加します	元のアイテムへの参照を追加します
Copy/Paste	Result	元のアイテムへの参照を保持します	元のアイテムを保持します
Copy/Paste	Action	アイテムはストレージ内の元の場所に残ります	アイテムはストレージ内の元の場所に残ります

Directory-based projects

次の表は、ソース項目の性質に基づいて実行するドラッグアンドドロップ (および切り取り/コピー/貼り付け) 操作と、ディレクトリベースのターゲットプロジェクトで押された修飾子キーをまとめたものです。

Modifier	Category	ソース項目: リファレンス/リンク	ソース項目: 物理項目またはファイルシステム (`CF_HDROP`)
No modifier	Action	Move	Move
No modifier	Target	ターゲットの場所にアイテムをコピーします	ターゲットの場所にアイテムをコピーします
No modifier	Source	元のアイテムへの参照を削除します	元のアイテムへの参照を削除します
Shift+Drag	Action	Move	Move
Shift+Drag	Target	ターゲットの場所にアイテムをコピーします	ターゲットの場所にアイテムをコピーします
Shift+Drag	Source	元のアイテムへの参照を削除します	元の場所からアイテムを削除します
Shift+Drag	Result	`DROPEFFECT_MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります
Ctrl+Drag	Action	Copy	Copy
Ctrl+Drag	Target	ターゲットの場所にアイテムをコピーします	ターゲットの場所にアイテムをコピーします
Ctrl+Drag	Source	元のアイテムへの参照を保持します	元のアイテムへの参照を保持します
Ctrl+Drag	Result	`DROPEFFECT_COPY` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_COPY` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります
Ctrl+Shift+Drag		No drop	No drop
Cut/Paste	Action	Move	Move
Cut/Paste	Target	ターゲットの場所にアイテムをコピーします	ターゲットの場所にアイテムをコピーします
Cut/Paste	Source	元のアイテムへの参照を削除します	元の場所からアイテムを削除します
Cut/Paste	Result	アイテムはストレージ内の元の場所に残ります	アイテムがストレージ内の元の場所から削除される
Copy/Paste	Action	Copy	Copy
Copy/Paste	Target	元のアイテムへの参照を追加します	ターゲットの場所にアイテムをコピーします
Copy/Paste	Source	元のアイテムを保持します	元のアイテムを保持します
Copy/Paste	Result	アイテムはストレージ内の元の場所に残ります	アイテムがストレージ内の元の場所に残る

Mixed-target projects

次の表は、ソース項目の性質に基づいて実行するドラッグアンドドロップ (および切り取り/コピー/貼り付け) 操作と、混合ターゲットプロジェクトで押された修飾子キーをまとめたものです。

Modifier	Category	ソース項目: リファレンス/リンク	ソース項目: 物理項目またはファイルシステム (`CF_HDROP`)
No modifier	Action	Move	Move
No modifier	Target	元のアイテムへの参照を追加します	ターゲットの場所にアイテムをコピーします
No modifier	Source	元のアイテムへの参照を削除します	元のアイテムへの参照を削除します
No modifier	Result	`DROPEFFECT_ MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_ MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所から削除されます
Shift+Drag	Action	Move	Move
Shift+Drag	Target	元のアイテムへの参照を追加します	ターゲットの場所にアイテムをコピーします
Shift+Drag	Source	元のアイテムへの参照を削除します	元の場所からアイテムを削除します
Shift+Drag	Result	`DROPEFFECT_ MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_ MOVE` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所から削除されます
Ctrl+Drag	Action	Copy	Copy
Ctrl+Drag	Target	元のアイテムへの参照を追加します	ターゲットの場所にアイテムをコピーします
Ctrl+Drag	Source	元のアイテムへの参照を保持します	元のアイテムを保持します
Ctrl+Drag	Result	`DROPEFFECT_ COPY` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_ COPY` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります
Ctrl+Shift+Drag	Action	Link	Link
Ctrl+Shift+Drag	Target	元のアイテムへの参照を追加します	元のソース項目への参照を追加します
Ctrl+Shift+Drag	Source	元のアイテムへの参照を保持します	元のアイテムを保持します
Ctrl+Shift+Drag	Result	`DROPEFFECT_ LINK` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります	`DROPEFFECT_ LINK` は `::Drop` からアクションとして返され、アイテムはストレージ内の元の場所に残ります
Cut/Paste	Action	Move	Move
Cut/Paste	Target	ターゲットの場所にアイテムをコピーします	ターゲットの場所にアイテムをコピーします
Cut/Paste	Source	元のアイテムへの参照を削除します	元の場所からアイテムを削除します
Cut/Paste	Result	アイテムはストレージ内の元の場所に残ります	アイテムがストレージ内の元の場所から削除される
Copy/Paste	Action	Copy	Copy
Copy/Paste	Target	元のアイテムへの参照を追加します	ターゲットの場所にアイテムをコピーします
Copy/Paste	Source	元のアイテムを保持します	元のアイテムを保持します
Copy/Paste	Result	アイテムはストレージ内の元の場所に残ります	アイテムはストレージ内の元の場所に残ります

These details should be taken into consideration when implementing dragging in the Solution Explorer:

複数の選択シナリオ向けの設計。
ファイル名 (完全パス) は、ターゲットプロジェクト全体で一意である必要があります。または、ドロップを許可しないでください。
フォルダー名は、削除されるレベルで一意である (大文字と小文字を区別しない) 必要があります。
ドラッグ時に開いているファイルまたは閉じているファイルには動作の違いがあります (上記のシナリオでは説明されていません)。
最上位レベルのファイルの動作は、フォルダー内のファイルとは若干異なります。

注意すべきもう 1 つの問題は、デザイナーまたはエディターが開いている項目に対する移動操作を処理する方法です。想定される動作は次のとおりです (これはすべてのプロジェクトの種類に適用されます)。

開いているエディター/デザイナーに未保存の変更がない場合は、エディター/デザイナーウィンドウをサイレントモードで閉じる必要があります。
開いているエディターまたはデザイナーに未保存の変更がある場合、ドラッグのソースはドロップが発生するのを待ってから、次のようなプロンプトでウィンドウを閉じる前に、開いているドキュメントにコミットされていない変更を保存するようにユーザーに求める必要があります。
```
==========================================================
     One or more open documents have unsaved changes.
Do you want to save uncommitted changes before proceeding?
                  [Yes]  [No]  [Cancel]
==========================================================
```

これにより、ユーザーは、ターゲットがコピーを作成する前に進行中の作業を保存できます。この処理を有効にするために、 IVsHierarchyDropDataSource2::OnBeforeDropNotify 新しいメソッドが追加されました。

The target will then copy the state of the item as it is in storage (not including the unsaved changes in the editor if the user chose No). ターゲットのコピーが完了すると ( IVsHierarchyDropDataSource::Drop)、ソースには移動操作の削除部分を完了する機会が与 IVsHierarchyDropDataSource::OnDropNotify。

変更が保存されていないエディターは、開いたままにする必要があります。変更が保存されていないドキュメントの場合、移動操作のコピー部分は実行されますが、削除部分は中止されます。 In a multiple selection scenario when the user chooses No, those documents with unsaved changes should not be closed or removed, but those without unsaved changes should be closed and removed.

Last updated on 2025-12-12