Microsoft ui text guidelines

For feature and technology names, be conservative in capitalizing. Typically, only major components should be capitalized using title-style capitalization. Analysis Services is a major component of SQL Server, so title-style capitalization is appropriate; cubes and dimensions are common elements of database analysis software, so it is unnecessary to capitalize them.

For feature and technology names, be consistent in capitalizing. If the name appears more than once on a UI screen, it should always appear the same way.

Likewise, across all UI screens in the program, the name should be consistently presented. Don't capitalize the names of generic user interface elements, such as toolbar, menu, scroll bar, button, and icon.

Don't use all capital letters for keyboard keys. Instead, follow the capitalization used by standard keyboards, or lowercase if the key is not labeled on the keyboard. Don't use all capital letters for emphasis. Studies have shown that this is hard to read, and users tend to regard it as "screaming. For more information, see the "Text" or "Labels" section in the specific UI component guidelines.

Don't hard-code the format of dates and times. Respect the user's choice of locale and customization options for the date and time formats. The user selects these in the Region and Language control panel item.

In these examples from Microsoft Outlook, both formats for the long date are correct. They reflect different choices users have made in the Region and Language control panel item. Use the long date format for scenarios that benefit from having additional information. Use the short date format for contexts that don't have sufficient space for the long format. While users choose what information they would like to include in the long and short formats, designers choose which format to display in their programs based on the scenario and the context.

Globalization means to create documents or products that are usable in any country, region, or culture. Consider globalization and localization when writing UI text.

Your program may be translated into other languages and used in cultures very different from your own. For controls with variable contents such as list views and tree views , choose a width appropriate for the longest valid data.

Include space enough in the UI surface for an additional 30 percent up to percent for shorter text for any text but not numbers that will be localized. Translation from one language to another often changes line length of text. Don't compose strings from substrings at run time. Instead, use complete sentences so that there is no ambiguity for the translator.

Don't use a subordinate control, the values it contains, or its units label to create a sentence or phrase. Such a design is not localizable because sentence structure varies with language.

Don't make only part of a sentence a link, because when translated, that text might not remain together. Link text should therefore form a complete sentence by itself. For more information, see the Go Global Developer Center. Use the main instruction to explain concisely what users should do in a given window or page. Good main instructions communicate the user's objective rather than focusing just on manipulating the UI.

Express the main instruction in the form of an imperative direction or specific question. In this example, the main instruction simply states the name of the program; it doesn't explicitly invite a course of action for the user to take.

Exceptions: Error messages, warning messages, and confirmations may use different sentence structures in their main instructions. Use specific verbs whenever possible. Specific verbs examples: connect, save, install are more meaningful to users than generic ones examples: configure, manage, set. For control panel pages and wizard pages, if you can't use a specific verb, you may prefer to omit the verb completely.

Don't feel obliged to use main instruction text if adding it would only be redundant or obvious from the context of the UI. In this example, the context of the UI is already very clear; there is no need to add main instruction text. Be concise use only a single, complete sentence. Pare the main instruction down to the essential information.

If you must explain anything more, consider using a supplemental instruction. Don't include final periods if the instruction is a statement. If the instruction is a question, include a final question mark. For progress dialogs, use a gerund phrase briefly explaining the operation in progress, ending with an ellipsis. Example: "Printing your pictures Tip: You can evaluate a main instruction by imagining what you would say to a friend when explaining what to do with the window or page.

If responding with the main instruction would be unnatural, unhelpful, or awkward, rework the instruction. For more information, see the "Main instruction" section in the specific UI component guidelines. Subordinate controls use the label of their associated control.

Inline text editor: An inline text editor allows the user to edit the selected text in situ without a fixed toolbar. You can create one using icons and a tooltip in Balsamiq. Text Editor Guidelines Text editors allow users to style their text to best convey their message.

Applies to: Toolbar. By Tess Gadd Got questions or feedback? Yes this is what I've been looking for. It is a little bit specific for Windows Vista, but verry good usable. If anybody has similar resources I would also like to have these. The content you requested has been removed. Ask a question. Use ellipses … to show that the page displays a portion of the output.

Depending on whether you describe CLI actions in the running text or in procedures, consider the following usage:. You can use the ping to verify the network connection between the two devices. You can use the ping command to verify the network connection between the two devices. You can use openstack server image create command to take a snapshot.