Ready for implementation
The standard form is used whenever only few data points are to be collected. It only provides limited ways to organize and group fields. Its main characteristic is its simplicity.
The standard form has a very simple structure. It offers no tabs to organize its set of fields like The single-page complex form does and it only shows a single form. That form may be organized using a number of built-in grouping features (see #Structure of the standard form below).
Every form contains a visually distinct outer frame (1) containing a close button (upper right corner) to close the form - it has the exact same behavior as ht "cancel" button of the form does. The frame also contains the main actions as buttons as well as the title of the form. Note that only the main actions use buttons. Secondary actions shown inside the inner form frame (3) use links only to visualize buttons (4). The frame thus provides the infrastructure of the form and focuses the attention of the user on the actual form elements while emphasizing the main buttons at the same time. Or, put differently, the inner frame focuses on content, the outer frame on control.
On opening a form, the first field automatically gets the focus. The focused field is visually highlighted using the focus color (light blue in the mockup). The same color is used to connect the field description at the bottom of the form element to the currently selected field. The currently focus or selected field is also colored if error messages appear - in general, there should always be at least one field having the focus.
Structure of the standard form
The image above shows the exploded view of the standard form; it visualizes all structural elements.
The outer-most layers, the outer frame (1) and the inner form frame (2), both have already been explained in detail in UX:the previous section. If the form is embedded on a page and not shown using a dialog, the outer frame does not need to have a (darker) background color. Leave out the frame, but arrange its elements around the inner form frame using a similar layout and maintain some visual distance to all surrounding elements on the page.
Fields may be grouped using field sets to form larger elements (4). Use this to bundle fields, which handle the same content block such as an image to upload or a contact address. Field sets and other, single fields are further assembled into a block (the gray element in layer (3)). Note that a block may not have an actual visual representation, but may be a logical unit only: in the first mockup on this page, there's no gray rectangle encompassing the single field set of the form. The block is part of the 3rd layer of the standard form and right above the form description area and below a possible error message - it's on layer 3 where all the messages reside.
Required fields may be marked using an asterisk after the field and their label is written using bold type. Do not use asterisks as part of the label as this corrupts the layout. Below is an example of a required field in a form.
Putting an asterisk actually diminishes the width of the input field in regard to other input fields. Ensure that the affected field plus its asterisks remain properly aligned with the other fields of the same length.
The following notes are important for making required fields accessible:
- make sure to set the "required" attribute of a required input field, which is available starting with HTML 5
- follow the solution described in this blog by Derek Featherstone to ensure that the asterisk is actually next to the label, but then rendered after the fields. This properly supports users
When not to use this form
Do not use such a form, if you're actually intend to collect sets of data using multiple steps. In such a case, use a multi-step process. If you need additional grouping elements beside blocks and field sets, use the single-page complex form.
Please refer to Showing validation messages in forms for a complete treatment of validation and other messages in forms.
Note that field descriptions are optional. The form may choose to only provide a help page (which is required, however).
Growing and shrinking dialogs
If the form is shown in a dialog, it will have to adjust its height to accommodate previously invisible form elements or messages - it does so by using a transition showing the dialog growing in size. Try to avoid scrollbars, if possible. If you must use a scrollbar, check out the remarks regarding UX:long forms below.
The dialog only reduces its height, if the reduced form occupies less than 2/3rds of its current height. This avoids too many movements in the interface. If a dialog chooses to not reduce its height, the superfluous whitespace is inserted right above any possibly showing field description, or else above the bottom edge of the form. E.g. in the first mockup on this page, this would be between the last field and the field description.
Note that the dialog must not change its size to fit the help page, but shall retain its current width and height. If the help text does not fit into the current dimensions, add a scroll bar.
If the form is shown using an overlay dialog or a dialog in a separate window, the user aborts editing by clicking the "close window" button in the upper right corner or by clicking the "cancel" button. If the form is shown on a page directly, the only option is the "cancel" button.
Standard forms should be small and quick to grasp. If form gets large nevertheless, consider splitting it up into the aspects of data sets you capture. If that is possible, you may revert to use a single-page complex form instead.
If this is not possible, add a scrollbar on the left hand side. Make sure that messages are not scrolled - an error message at the top and field descriptions at the bottom should not scroll.