UX Essentials

Best Practices

1. Be consistent within the Visual Studio environment.

• Follow existing usage patterns within the shell.

• Design interface details to be consistent with the shell’s visual language.

• Understand the Visual Studio hierarchy and how it establishes context and drives the UI.

• Design for a minimum screen resolution of 1024x768 and a maximum dialog size of 900x700.

2. Use the environment service for fonts and colors.

• All UI should respect the current environment font setting.

• Use the Visual Studio color service with common controls or when custom-drawing UI elements.

3. Use shared commands, controls, and UI framework.

• Commands should be part of the Visual Studio ecosystem.

• Use shared dialogs and controls before creating your own (e.g. the search control in New Project dialog).

• Author all new UI using WPF (Windows Presentation Foundation).

4. Make all imagery consistent with the new Visual Studio style.

• Follow Visual Studio design principles for icons, glyphs, and other graphics.

• Create easily recognizable icons by using simple shapes, complementary angles, and balanced amounts of light and dark.

• Avoid placing text in graphic elements.

5. Design from a user-centric perspective.

• Create the task flow before the individual features within it.

• Be familiar with your users and make that knowledge explicit in your spec.

• Approach spec reviews from a user-centered perspective. What is the user doing now and what do they expect?

• When reviewing the UI, evaluate the complete experience as well as the details.

• Design your UI so that it remains functional and attractive regardless of locale or language.

6. Do not change control templates.

• Use existing controls instead of creating your own.

• Don’t alter the basic control appearance.

• Don’t explicitly set the style/template properties of controls.

• Don’t embed fixed font styles or hard code colors in your controls.

Essentials

Screen resolution

Visual Studio is optimized for a screen width of 1280 pixels and a minimum screen resolution of 1024x768 pixels. Initial dialog size should not exceed 900x700 pixels so as to fit within the frame of the integrated development environment (IDE) within this minimum resolution at 96 dpi.

Fonts

The use of Visual Studio’s environment font service is required in order to ensure a consistent font appearance throughout the IDE. All UI should respect the current environment font. The default interface font, which is mapped to a setting in the operating system, appears as Segoe UI 9pt on Vista and Windows 7. UX designers should specify “the Visual Studio Environment Font” when creating UI specifications, while mockups and visual specs will illustrate “Segoe UI 9pt”.

Using the font service is not required for UI whose fonts are exposed via Tools > Options > Environment > Fonts and Colors. This primarily applies to design surfaces and editors, which should allow for user-customization of fonts based on usage scenarios.

Icons

Icons from prior versions of Visual Studio reflected the illustrative style introduced in Windows XP. Those color-rich icons featured soft edges, gradients, and drop shadows to provide contrast and dimension.

Styling for iconography in the new Visual Studio aligns with modern design style, which is found in the Windows Phone and Windows 8. These icons share the principles of minimalism and distinctness.

Updated icons for bookmark, test project, mobile user control, and call browser settings.

Build an icon’s elements using simple shapes, complementary angles, and balanced amounts of negative and positive space; the result should be a flat shape without drop shadows or gradients. Reduce the icon to its core meaning by using the metaphor that best illustrates its distinctiveness. Don’t overload the icon with the technical details of its purpose.

Avoid using icons that visually represent elements of the UI; aim toward a more symbolic approach when the UI element is not a common icon. Do not use text in your images due to increased complexity for localization.

Colors

Visual Studio provides a VSColor service which must be used for all UI elements, including those that are custom-drawn. Do not tie directly into the operating system. Utilizing the service assures the client that all colors will change to reflect the current operating system, theme, and high contrast settings.

The VSColor service’s palette features a light theme and a dark theme. Utilizing the color service ensures that all themed parts of the UI behave appropriately when Visual Studio detects certain accessibility settings, such as high contrast, and removes the need to personally handle high-contrast mode, a common Accessibility setting in the operating system.

When possible, use the shared environment colors for UI elements that have the same characteristics as those colors. By doing so, all clients of the service are assured that their UI will be consistent with the shell. When the same theme is changed in future versions of Visual Studio all UI will update accordingly if the colors were correctly assigned.

Do not use opacity. Visual Studio makes use of opacity to focus the user’s attention on the current activity or active component. Inactive areas, or those not in the current context, partially fade into the background.

Author new UI using WPF

Visual Studio is now a full-fledged Windows Presentation Foundation (WPF) application. While existing UI aren’t required to be rewritten, all new UI should be authored using WPF.

To optimize your WPF UI:

1. Snap to device pixels. This reduces the blurriness and the artifacts that result from WPF's DPI-independent graphics system. Set this attribute for small, simple, or static imagery. Animated or large elements benefit from WPF's DPI-independent graphics systems.

2. Use layout controls to intelligently handle string growth. Account for variations in string size with correct use of layout controls. WPF provides a layout that enables automatic size adjustment of application controls. With controls auto-adjusting to accommodate string length, UI will display properly in any language.

3. Use border controls instead of rectangles. If you need a rectangle as an image element, use a border control and render all sides to make it appears as a rectangle.

4. Use 32-bit PNGs for small images like icons.

5. Remove user control width and height before deployment. If you don’t, neither the user nor the content will be able to resize the controls.

6. Apply layout transforms and render transforms appropriately. Use layout transforms when you want the other elements in that container to adjust, flow, and move according to that transform. Use render transforms when you don't want the UI to adjust.

7. Use automatic layout mechanisms for dialogs. Avoid absolute positions, fixed sizes, and maximum sizes to lay out content; instead, use relative or automatic sizing. Use SizeToContent and keep widths and heights set to Auto. Avoid using a Canvas to lay out UI. Use a Grid and its size-sharing feature.

8. Avoid transitions and animations unless those serve a specific purpose. Transitions and animations are part of the visual language that communicates functionality, such as system activity. Inconsistent transitions and animations may confuse the user and distract from the harmonious appearance of Visual Studio. Don’t use memory-intensive BMP effects such as dropshadows and glows.

Design user experiences, not just feature functionality

Maintain a user-centric perspective. Create a task flow before designing features. Be familiar with your users and real-world usage scenarios and make that knowledge explicit in your spec, which will provide a better experience as users move between features. When it comes time to do spec reviews, look at those from a user-centered point of view and evaluate the holistic experience along with the details. Be prepared to go back and forth with your users regarding what works and what doesn't. Always put yourself in the role of end-user.

Allow for user experimentation. Take into account common learning patterns; many users don't read documentation and prefer to jump right in, investigating elements as they see fit. Don't design features that rely on documentation. Make it easy to reverse an action without harm; support undo; ensure that the user can alter what they've done in the same place that they've done it.

Think of help as part of the UI system. Don't design a set of tasks and UI to support those tasks without thinking of the related Help topics. Your users will go to Help when they have questions, so ensure that the necessary information can be found and that it is both descriptive and conceptual. Ensure that F1 is hooked up to a relevant Help topic.

Provide progress during long operations. While time-intensive operations in the environment should be modeless, users need feedback on the progress of background tasks. The environment status bar allows you to easily provide modeless feedback during long operations.

Allocate time for fit-and-finish tuning before freezing your UI. Take time to find and fix bugs that would otherwise not meet your bug-fix criteria, and do this prior to visual freeze. Allowing for a fit-and-finish pass gives you a chance to discover any anomalies and prioritize bug fixes. This is the best way to ensure that your product achieves the requisite professional polish. The result is a more consistent and therefore more trustworthy product.

Globalization and localization

Globalization, which refers to designing your UI so that it looks and behaves properly on a global scale regardless of its being translated, is always a best practice.

Localization is the process by which your UI is translated into languages specific to other locales. If you create features for languages other than English then design with the localization process in mind.

In an instance where a class may not be localizable by default, expose the string to be localized in XAML by setting its Localization.Attributes to ‘Readable Modifiable’ and its Category to ‘Text’. XAML elements derived from a class that has been attributed as readable modifiable need a UID to be localized.

Separate all localizable elements of your component into a satellite DLL, even for English resources. Specify the neutral culture in the project file so that MSBuild can generate a main assembly and its corresponding ‘EN’ satellite assembly.

Add comments directly to XAML to help localizers with context. To extract comments from XAML during the build process, add the following property to the PropertyGroup of your .project file:

<LocalizationDirectivesToLocFile>CommentsOnly</LocalizationDirectivesToLocFile>

Support right-to-left (RTL) languages. When the IDE switches to bi-directional (bi-di), there is a new shell property VSSPROPID_LayoutIsRightToLeft to indicate the direction and features within Visual Studio, which should behave accordingly. In future versions of Visual Studio all UI will be required to support bi-di, but for Visual Studio 2012 only new UI are required to support it.

Interface overview

At a high level, the Visual Studio interface is composed of multiple windows, dialogs, commands and toolbars in a single integrated development environment (IDE). The Visual Studio hierarchy determines context and drives menus. The key integration points in the user interface of the IDE are document windows, tool windows, projects, the command structure, the text editor, the toolbox, the properties window, and Tools > Options.

Document windows and tool windows should have consistent patterns of behavior and appearance. Commands should appear in the appropriate place in the top-level menu structure. Selection and context feedback should be reinforced in a consistent manner while the user works, so functionality available to the user should apply to their current state in the IDE.

Developers use tool windows (e.g. Solution Explorer, Server Explorer) while working across the information hierarchies (e.g. projects, databases), editing different types of documents (form files, code files, database diagrams) in different types of document windows (Form Designer, Code Editor, Database Designer) using different types of tool windows (Toolbox, Task List, Properties Window).

Shared commands, controls, and dialogs

Use existing shared commands, command groups, and menus. If a new command needs to be defined, try to place it in an existing shared command group. If a new group needs to be defined, place it in an existing shared menu close to a related command group before creating a new top-level menu. This reduces command complexity while ensuring consistent command placement in the IDE.

When feasible, a package should use shared commands rather than creating its own. Examples of these shared commands include Cancel, Rename, and Refresh, which show up in multiple menus and contexts.

Commands are typically shown based on context, reducing the number of commands the user sees at any given time. Using existing shared menus and command groups ensures that the command structure remains relatively stable between changes in context.

Reusing shared commands and placing new commands close to related shared commands reduces IDE complexity and creates a more user-friendly experience.

Limit the addition of keyboard shortcuts. The vast majority of users employ a tiny fraction of all available shortcuts. When in doubt don't bind your feature to a keyboard shortcut. Work with your user experience team before adding new shortcuts.

Design your commands recognizing that they will be customized by others. There is no such thing as a hidden command. Commands appear in Tools > Customize, in the Command Window, auto complete, Tools > Options > Keyboard, and Development Tools Environment (DTE). Give your commands a name and tooltip in your .ctc file. Every command should have a default menu placement.

Reuse shared dialogs and controls whenever possible. For example, make use of the common search control (as seen in the New Project dialog and in Solution Explorer) instead of creating your own.

Dialogs

Your feature task flow should use as few modal dialogs as possible. When a modal operation is necessary, Visual Studio has a number of shared dialogs into which your features can be integrated. If a new dialog must be created, follow the interaction pattern of an existing, similar dialog.

Well-designed dialogs take into consideration the user task you are supporting, the dialog text style, language and terminology, control choice and UI conventions, visual layout specifications and control alignment, and 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 (roughly five or more minutes) then the activity might be better supported by a document window or a tool window.

Sometimes users perform 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.

Three of the commonest types of dialogs are:

1. Simple, which is a presentation of controls in a single modal window. The presentation may include variations of complex control patterns, including a field-picker or an icon bar.

2. Layered, which is used to make the most of screen real estate when multiple groups of controls are offered in a single piece of UI. The dialog’s groupings are layered so that the user can choose which grouping to see at any given moment.

3. Wizards, which are useful for directing the user through a logical order of steps toward the completion of a task. A series of choices are offered in sequential panels, each of which must be stepped through before proceeding to the next.

For resizable dialogs, define a minimum size that will optimize for the control set without clipping while adjusting to accommodate reasonable growth for localization. In addition, ensure that the user-scaled size and location persists from session to session.

Window interaction usage patterns

The two main window types utilized in Visual Studio are for tools and documents. Although tool windows and document windows are both modeless in the shell, take into consideration their fundamentally different usage patterns when choosing which to use.