Guidelines for form layouts (Windows Store apps)
Design forms that provide a great touch experience, optimize the use of screen real estate, and minimize panning/scrolling in your Windows Store app.
When you design a form and the control layout, think about how you want the user to fill out the form and the effects panning/scrolling might have on the experience. Make sure you also consider the impact of the touch keyboard (it can use up to 50% of the screen in landscape orientation) and inline error notifications, if used.
Here we describe guidelines and recommendations for single- and multi-column form layouts.
Use a single-column layout for your form when:
- You want to encourage users to fill out the form in a specific order.
- The form spans multiple pages.
- The app is resized to a tall, narrow layout.
- The app displays additional notes and info, instructions, or branding and advertising.
Here's an example of a short form that uses a single-column layout:
Here's an example of a longer form that uses a single-column layout:
Instead of trying to fit a lot of controls into one very long form, consider breaking up the task into groups or into a sequence of several forms. Here's an example of a longer form that is broken up into groups:
Here's an example of a longer form that's broken up into multiple pages:
Here's an example of a form that uses a single-column layout because the UI contains additional notes and info:
Use a two-column layout for short forms with limited vertical panning. The two-column layout makes the best use of screen real estate in landscape orientation. Remember to reserve ample gutter space between the two columns.
Here's an example of a form that uses two columns:
Don't use multiple columns when there is extensive vertical panning. To fill out the form, the user has to reach the bottom of the first column, move to the top of the second column, and then back down again. This experience becomes even more cumbersome if the touch keyboard is displayed.
Here's an example of a form that uses two columns improperly:
Use three or more columns to make the best use of visible screen real estate in landscape orientation. This layout works well in fixed or horizontally panning screens, but is awkward in vertically panning screens. Use this layout only when the input order is not important.
Most controls need a label.
- Place labels above controls or to the left of a control.
- Use the same style of label placement for all controls in a form.
In general, place labels above controls. When using a multi-column form layouts, always place labels above controls.
Placing labels above controls helps establish the relationship between a label and its control and helps create a clean layout, as all labels and controls can be left-aligned. Placing labels above controls makes it easier to present long strings and handle localization and accessibility issues.
Here are a two examples of upper label placement.
In single-column forms where vertical real estate must be conserved, place labels to the left of controls when:
- The label strings are short and approximately the same length.
- There is enough horizontal space for the longest label string (in any locale).
Here's an example of a form that uses left label placement.
Don't place labels to the left when there is a lot of variance in the length of the labels as some labels will be too far away from their controls.
Don't use left label placement in multi-column form layouts. The labels themselves might look like a separate column.
Sometimes you can simplify your layout by using inline placeholder text instead of labels. Use inline placeholder text when:
- The form pattern is commonly understood by a wide audience (for example, a user logon control or a password entry field).
- The label can easily be implied or construed after the data has been entered in the input field (since hint text disappears after data is entered).
- There are a limited number of input fields.
Here's an example of a form that uses inline placeholder text:
Align form buttons to the right, except when multiple buttons are embedded with other controls. To help a form appear more cohesive, buttons should match the alignment of those other controls. For example, in the PC Settings screen, the embedded buttons are left-aligned:
For more info about button placement, see the Guidelines for buttons.
The control that a user is interacting with on the form has focus. A user may use the Tab key on the keyboard to navigate through the controls on the form, including controls that are not currently in view. Ensure the panning region that contains the focused control auto-pans so that entire control is in view. There should be a minimum of 30 pixels between the control in focus and the edge of the screen or the top of the touch keyboard (if visible) to account for various edge gestures/UI and the text selection gripper.
In some cases, there are UI elements that should stay on the screen the entire time. Design the UI so that the form controls are contained in a panning region and the important UI elements are static. For example:
When no physical keyboard is detected, the touch keyboard is displayed when the user taps an input text field. Don't make your app automatically launch the touch keyboard without this interaction.
The keyboard is dismissed in one of two ways:
- The user completes and submits the form, leaving the view.
- The user dismisses the keyboard via the dismiss key.
The touch keyboard does not automatically dismiss while the user navigates between controls in a form.
For more info, see the Guidelines for touch keyboard and handwriting panel.
Here's an example of a registration form that follows the guidelines in this document:
Here are recommended sizes for various elements, with spacing guidelines:
Build date: 11/16/2013