Skip to content

Latest commit

 

History

History
233 lines (176 loc) · 11.4 KB

design-patterns-page-forms.md

File metadata and controls

233 lines (176 loc) · 11.4 KB
Raw

Forms

Forms are the manner in which we gather and validate user input.

Context

Users enter information to manage Azure resources.

Problem

Users want to enter information to create, configure and manage resources. Users file support tickets and provide feedback by entering information in the portal.

Solution

The portal offers several variations of forms with consistent field layout and form validation to ensure users can easily enter information and understand whether that info is valid. The form variations are dialogs, context panes, full screen blades and wizards. Well designed forms enable users to increase the speed and accuracy of input and lead to successful form completion.

Also known as

Examples

Example images

Dialog

Context Pane (read only)

Context Pane (with input form)

Full screen blade

Full screen blade from resource menu

Wizard

Example uses

  • Dialog: Stopping a VM
  • Context pane: Tagging a VM
  • Full screen page: Moving a VM to a different resource group
  • Full screen page from resource menu: Editing VM diagnostic settings
  • Wizard: Creating a VM Free account virtual machine

Use when

Choose among these available options when designing experiences for the user to enter information.

  • Dialogs are used for very simple input/acknowledgment and appear next to the user click target
  • Context panes are used when more space is needed and the input form does not need to invoke any child blades. Context panes appear on the rightside of the screen, vary in width and float over other content.
  • Full screen blades are used when the input form needs the space or will invoke a child blade
  • Full screen blades from resource menu are used when the input form is invoked directly from the resource's resource menu and serves the purpose of showing the current information and the edit experience for that information
  • Wizard is a type of full screen blade with tabs across the top and is used to guide a user as they provide input when creating azure resources

Anatomy

A form can contain:

  1. Labels and corresponding input fields
  2. Buttons or another call to action
  3. Error messaging
  4. Field and Form validation

Behavior

As the user enters information, field content is validated. Upon form submission, the entire form is validated.

Validation

Placeholder text

Include placeholder text can be formatted in two ways:

  1. As an instruction
  1. As an example of valid input format

Field validation

Don’t make users guess field (TextBox) or password (PasswordBox) requirements. Instead, enable field validations for TextBox and PasswordBox in your experience. You can enable the showValidationsAsPopup option to give the user feedback as they type.

Error messaging

Provide highly visible and specific error messages.

Control recommendations

Visit the control guidance to help you in selecting the right control for your page

Button recommendations

The buttons for submitting and canceling a form should follow these recommendations. The sections for each type of form follow this list and call out any special casing for that form type. Sometimes a forms blade is invoked from multiple places. For example, the Tag resource blade is invoked from a resource menu on most Azure resource and also invoked in a context pane from the essentials control. In this case, the Tag resource blade is designed as a fullscreen blade form opened from a resource menu and does not follow the recommendations of a typical context blade form.

  • Buttons are at the bottom of the page in a non-scrollable docked area
  • Use a single Close button if experience is informational only
  • Use Yes and No buttons for destructive actions and include a confirmation question in the dialog - "Delete this VM?"
  • Use the "action name", like Move, Save, Attach, Add, for the submit button and Cancel as the button to close the dialog
  • Use Ok and Cancel as a last resort if a better action name is not apparent

Dialog - command buttons

Follow the button recommendations above

Context pane - command buttons

  • Use buttons at the bottom. Follow button recommendations above
  • Don't use a toolbar at the top
    • If context pane contains a grid, attach grid actions to the grid with a grid-level toolbar

Fullscreen blade form - command buttons

  • Use buttons at the bottom. Follow button recommendations above
  • Use a toolbar at the top only if page represents a more fully featured management experience like the Manage alert rules experience ( VM > Alerts > Manage alert rules )
    • All buttons go in the toolbar using the naming conventions above
    • No Close button, the blade has an X in the upper right corner to close it

Fullscreen blade from opened from a resource menu - command buttons

  • Use a toolbar at the top of the page when the form is opened from a resource menu like the Tags experience ( VM > Tags ) and the VM diagnostic settings experience ( VM > Diagnostics settings )
  • All actions go in the toolbar using the naming conventions above
  • No Close button, the blade has an X in the upper right corner to close it

Create wizard command buttons - see the resource create pattern for details

Do

  • Use inline labels and fields for full screen pages and stacked labels and fields for narrow blades. This behavior is controlled by the Section leftLabelPosition option

  • Mark required fields with a red asterisk * to distinguish them from optional fields

  • Include info balloons (InfoBalloon) if there are input fields that may not be immediately familiar

  • Left align the input fields on the page. Jagged edges are difficult to skim

  • Visually group related labels and fields. Labels should be close to the fields they describe (immediately above the field for context panes or next to the field for long forms). Avoid ambiguous spacing where labels are equidistant from multiple fields.

Don't

  • Don't phrase labels as questions. Keep labels short and sweet.

  • Don't include fields that stretch across the full width of the page.

  • Avoid buttons for clearing a form. The risk of accidental deletion outweighs the unlikely need to start over.

Related design guidelines

Research and usability

Telemetry

For developers

Developers can use the following information to get started implementing this pattern

Tips and tricks

  • To show the labels and input field on the same line - include your controls in a Section and set the leftLabelPosition option to true.

Related documentation