Dialog Types

How to design a Visual Studio dialog

As dialog design is a key component of the Visual Studio user experience, first ensure that your feature task flow uses as few modal dialogs as possible. When a dialog is needed for modal operation, Visual Studio has a number of shared dialogs into which your features may be integrated. Follow the interaction patterns of an existing similar dialog if a new dialog must be created.

Well-designed dialogs take into consideration the following elements:

• The user task being supported

• The dialog text style, language, and terminology

• Control choice and UI conventions

• Visual layout specifications and control alignment

• Keyboard access

At the fundamental level, dialogs should support one discrete unit of the user's work and then be dismissed. If the user spends significant time in the dialog--five minutes or more, perhaps--then the activity might be better supported by a document window or a tool window.

Sometimes users do two activities at once, such as finding and replacing while they are writing new code. In this case, the dialog (such as Edit/Find and Replace) should be non-modal so that the user can switch easily between the code editor and the find/replace options. Tool windows also do a good job of supporting these linked tasks.

Once you have decided that a dialog is the best way to support a user's task, consider the differences between these basic types of dialogs:

Simple dialogs

A simple dialog is a presentation of controls in a single modal window. This presentation may include variations of complex control patterns, such as a field-picker, icon bar, or (rarely) a menu. A small tab control--less than half of the overall dialog size--may be included on a simple dialog, but if it fills the entire dialog then refer to the layered dialog type below. For simple dialogs, follow the standard general layout as well as any specific layout required for complex control groupings.

Layered dialogs: tabs, dashboards, and embedded trees

Layered dialogs are used to maximize real estate when there are multiple groups of controls offered in a single piece of UI. The groupings are layered so that the user can choose which grouping to see at any one time.

In the most straightforward case, the mechanism for switching between groupings is a tab control. There are several alternatives available; see the Prioritizing and Layering section that appears later in this page on how to choose the most appropriate style.

The Tools/Options dialog is an example of a dialog layered using an embedded tree:

Wizards

Wizards are useful for directing the user through a logical order of steps in the completion of a task. A series of choices are offered in sequential panels, and the user must continue through each step before proceeding to the next. Once sufficient defaults are available the Finish button is enabled.

Modal wizards are used for tasks which:

• Contain branching; different paths are offered depending on user choices.

• Contain dependencies between steps; subsequent steps depend on user input from the preceding step(s).

• Are sufficiently complex that the UI should be utilized to explain the choices offered and the possible outcomes in each step.

The Data Source Configuration Wizard, an example of a modal wizard:

For more information about choosing a dialog style, see the Dialog decision tree that appears later in this page.

Common conventions

To achieve optimal design and functionality with your dialogs, follow these conventions on dialog size, position, standards, control configuration and alignment, UI text, title bars, control buttons, and access keys.

Size

Dialogs should fit within a minimum 1024x768 screen resolution, and initial dialog size should not exceed 900x700 pixels. Dialogs may be resizable, but it is not a requirement. There are two recommendations for resizable dialogs:

1. That a minimum size is a defined for the dialog that will optimize for the control set without clipping, and adjust to accommodate reasonable localization growth.

2. That the user-scaled size persists from session to session; e.g., if the user scales a dialog to 150% then upon a subsequent launch of the dialog will display at 150%.

Position

Dialogs must appear centered within the integrated development environment (IDE) on first launch. For non-resizable dialogs, it is not required that the last position of the dialog be persisted; it may appear centered on subsequent launches as well. For resizable dialogs, on subsequent launches the size and position must be persisted.

When dialogs must spawn other dialogs, the topmost dialog should cascade to the right and down from the parent so that it is obvious to the user that they have navigated to a new place.

Standards

Follow existing standards before inventing a new one. Look for similar features in Office, Windows Client, Windows Server, or other products, especially ones that carry the Windows or Office family logo.

Control configuration

Be consistent with existing control configurations that accomplish the same thing in Visual Studio, such as a field-picker layout with mover and sort buttons. Logo requirements state that dialogs must always have a default button, which should be indicated in the layout/spec.

Control alignment

All dialogs should start from a common top/left coordinate and flow downward. Never center controls on a dialog to fill a large area. All controls are left-aligned.

UI text

All text in dialogs should use the environment font. When writing a visual spec, never select a particular font and size; specify it as the environment font.

Title bars

The text in the title bar should reflect the name of the command that launched it. No icon should be used in dialog title bars, though if necessary use the Visual Studio infinity logo. Dialogs should not have minimize or maximize buttons. Each title bar should contain a ? (Help) button configured to launch the F1 help topic associated with the dialog.

Dialog control buttons

In general, OK/Cancel/Help buttons should be arranged horizontally in the lower right corner of the dialog, or stacked vertically in the top right corner. Alignment of buttons should be tailored for the specific dialog; while there is no requirement for use of one or the other alignment styles, the lower horizontal alignment is preferred. Use of the vertical stack is recommended if a dialog has several other buttons at the bottom of the dialog that would present visual confusion with the control buttons.

Access keys

Access keys should not be used for OK/Cancel/Help buttons. These buttons are mapped to shortcut keys by default, which suffice for quick keyboard access:

Other buttons

For complex dialogs, use a horizontal alignment for rows of interior buttons when OK/Cancel are vertical, and a vertical alignment when OK/Cancel are horizontal.

Button size should match the size of OK/Cancel buttons.

Dialog decision tree

Follow this decision tree to help you decide which dialog style best suits your task.

Dialog types

There are advantages and disadvantages to different methods of layering UI through tab-like controls. Review this list to ensure that you are choosing a layering technique that is appropriate to your situation.

Type	Switching mechanism	Example	Appropriate use	Disadvantages and inappropriate use
Simple dialog	N/A		Presentation of one or more controls to capture user feedback. The most common dialog style. Should support one discrete task unit of the user's work.	Inappropriate design solution if the user spends five or more minutes in the dialog to accomplish their task. Size can become a problem if the task is sufficiently complex to require many controls. Maximum dialog size is 900x700. If size is a concern, consider using a document window, layering information in secondary dialogs (launched through an Advanced button), or layering information as in a tabbed dialog.
Tabbed dialog	Tab control		Logically groups dialog pages into related sets. Useful for fewer than five pages (or the number of tabs that fit in one row across the dialog) of related controls in dialog. Tab labels must be short; one or two words that can easily identify the content. A common system dialog style. Example: Control Panel/Display	Making descriptive short labels can be difficult. Generally doesn't scale past five tabs in one dialog. Do not use layered tabs if you have too many tabs for one row; use an alternative layering technique. Not extensible.
	Outlook bar, large icon		Useful for three to seven groupings. Visually appealing; icons are decorative and provide visual differentiation between tabbed groups. Used in common Office dialogs. Example: File/Open/Website	May be difficult to design a meaningful icon. Labels for groups must be kept short; no more than three lines, similar to desktop icons. Large icons and labels limit the number of categories that fit in standard dialog size. Not extensible.
	Outlook bar, small icon		Allows for more groupings than large icon version. Icons provide visual differentiation between tabbed groups. Example: Visual Web Developer CSS Style Builder	Not a good use of horizontal space if there are fewer than three groups.
	List box		Simple switching device that can accommodate more categories than tabs. Flat list of categories; no hierarchy. Extensible.	Not a good use of horizontal space if there are fewer than three groups.
	Tree control		Allows for unlimited categories. Allows for grouping and/or hierarchy of categories. Extensible. Example: Tools/Options	Heavily nested hierarchies can cause excessive horizontal scrolling. Visual Studio has an overabundance of tree views.
Wizard	Navigation buttons		Aids the user in task completion by leading them through task-based, sequential steps. The wizard represents a high-level task and the individual panels represent subtasks needed to accomplish the overall task. If the task crosses UI boundaries, the wizard relieves the user from wading through multiple editors and tool windows to complete the task. Completing the task requires branching. The task contains dependencies between steps. Several similar tasks with one decision fork can be presented in one dialog to reduce number of different similar dialogs. The Finish button must be enabled at the earliest possible opportunity when reasonable defaults exist on subsequent pages so that users can quickly complete the wizard in frequent-use scenarios.	Not appropriate if the task contains only one step. User is forced to walk through each step before they can proceed. Heavy use of wizards can be seen as a bandage on poorly designed UI (if the wizard does not accomplish a task crossing UI boundaries).
	Side tab		Useful for more than three groupings. Horizontal format allows for longer text labels. Horizontal format allows for single level of indentation to show some tab grouping. Friendly format allows for a headline to state the purpose of the dialog. Non-sequential. No dependencies between groupings. Example: Visual C++ New Project UI	Often confused with wizards because the presentation is more familiar and may be conversational. This dialog should never be termed a wizard as it is not sequential and does not allow branching. Not extensible. There is no good, usable design for scrolling the horizontal tabs when the number of tabs causes them to be clipped by the window size.

Prioritizing and layering

Prioritizing your UI

It may be necessary to bring certain UI elements to the forefront and place more advanced behavior and options (including obscure commands) into dialogs. Bring commonly used functionality to the forefront by making room for it, and by making it visible-by-default in the UI with a text label when the application starts. For left-to-right languages such as English, the upper left corner of the application is the most noticeable location. Conversely, the upper right corner is most noticeable for right-to-left languages.

Next to a visible-by-default screen position, the main menu structure is the most prominent place in the UI. If your goal is to make functionality more obscure, then place it in less apparent places such as context menus of certain objects--but not in the menu structure. If you prefer something to be completely hidden, use a key binding but no visible command. Always note intentionally hidden items so that you can remember their functionality.

Another powerful position in the UI is the point of attention which contains the user's focus. Smart tags are a great example of how the point of attention can be utilized; these present a visible control right at this point. If you need to lead the user to certain commands, smart tags and similar affordances may be a sensible choice to avoid or reduce the need for a dialog.

Layering your UI

If you have determined that a dialog is necessary but the related functionality you want to present to the user goes beyond what can be displayed in a simple dialog, then you need to layer your UI. There are several layering techniques from which to choose:

• Tabbed dialogs. The simplest and most common way to layer the UI is to use a tab control or other variant. See the Dialog decision tree to determine which kind of tabbing you should use.

• Hallways or dashboards. These are dialogs or panels that are launching points to other dialogs and windows. The well-designed hallway/dashboard has common options, commands, or settings so the user can accomplish common tasks while retaining access to additional functionality. If you don't provide common options, the hallway becomes a simple list of links without any real functionality. Review the Outlook File > Options dialog below, which uses the hallway technique well and rolls up some common options (in each of the tabs) to prevent the user from having to drill down into the linked dialogs. The most common settings are on the dialog itself while providing a relatively easy way of getting to advanced options.

  

• Expand/collapse buttons. Showing and hiding pieces of UI is an effective way of focusing a user's attention. Visual Studio has a strong sense of context based on the solution, the active project, and the active window, and commands are filtered accordingly. However, there are cases in dialogs, document windows, and tool windows where UI may also need to be hidden or shown based on context. For example, the Toolbox shows the appropriate set of controls depending on what designer is currently active. Additionally, the user should be able to control visibility of these elements depending on the current task. This functionality can be provided with expand/collapse buttons.

  Expand and collapse buttons should be used only when the section being revealed is on the same dialog, window, page, or layer. Buttons that simply say 'More' or 'Advanced' should be used only when the options revealed by the button are solely intended for advanced users; the purpose of advanced options is to fold away options that are not commonly set. Note the below figure in which the 'Custom Forms...' button on Outlook > File > Options > Advanced > Developers provides explicit text indicating further options, as opposed to a vague 'Advanced...' or 'More...' which would leave the user guessing what options are to be revealed.

  The Outlook Options > Advanced > Developers options with the Custom Forms button, as opposed to an 'Advanced' or 'More' button:

  

  Carefully group controls when using expand and collapse buttons. Careless grouping causes the user to repeatedly expand and collapse sections or show all the functionality, which defeats the purpose of the expandable/collapsible sections.

  Although different products use different symbols on these buttons, Visual Studio has standardized the use of the plus and minus symbols for expand/collapse functionality. For rollup-type behavior of a container or element, use the chevron.

• Use adaptive UI. Showing or hiding UI based on usage or a user's self-reported experience is another way of presenting necessary UI while hiding other portions. There are major caveats with this approach; if you expose UI based on usage, the algorithms for deciding when to show or hide UI can be tricky, and the rules will always be wrong for some set of cases.

Using images in dialogs

Use images sparingly in dialogs. Do not use large icons in dialogs merely to use up space; use them only if they are an important part of conveying the message to the user, such as warning icons or status animations.