Documentation
Used for creating or modifying content, configuration or entities, form-based views provide the most common means of collecting user input to effect mutations.
Form views may be composed to appear:
The use of incidental forms throughout a software application is unavoidable, but with few exceptions, these uses are not views nor should they be implemented as such, but rather access a lower-level API as appropriate to the use case.
These two different operations typically use the same view, or parts of it, with the following key differences:
Note: The attached figures do not depict the first two points.
These annotated figures help describe the appearance and functionality of various aspects of the view.
A simple form presenting plenty of usability cues to help a user successfully understand and complete the task set before them.
Note the simple structure of the form, which avoids defining field-specific widths.
Forms can be made more beautiful and usable at the expense of greater complexity to describe the desired visual structure. A suitable rendering solution will allow us to create simple forms with as little complexity/code as possible, while leaving open the possibility to enhance rendering on a per-case basis.
select to activate
It is imperative to clearly indicate to users where any field input errors occur. This includes visual cues using color (red) and alternative means (icon) as well as a clear textual statement explaining the problem or corrective action.
Field errors must appear when validation errors are present and a user has touched the input, or submitted the form. Validation should not be shown/present if the user has not yet touched an input, regardless of the validity of its current value (if any).
select to activate
At a higher scope than field-specific errors are synchronous, whole form (view-level) errors, which are typically displayed after the user has attempted to submit information that could not be accepted for processing.
This scope of error differs from those at field-level in a couple key respects:
Important: Do not use to indicate successful operations. In most cases, the screen containing the form is removed from view immediately upon acceptance of the submitted values.
Successful operations should be displayed to the user in a Toast message.
For the same reason, information accepted for processing, but encounters an error later, cannot be represented using this form error, and must be conveyed to the user via Toast as well.
As stated earlier, modify views typically resemble their creation counterparts with a few exceptions, such as value pre-population and action button changes. This example also includes an action button to delete the record, as it might appear if editing the record in a modal window.
The term widgets encompasses the various types of user input that translate to a rendered presentation to a user. For each collected type of data, there are often multiple widgets available that will provide the same output.
Widgets therefore provide options for view designers for how best to represent the data to the user. The drawing below illustrates some options; more complete examples of the various flavours of form components have been omitted for time and space.
select to activate
Forms should be implemented in a way that sees them collapse responsively when the screen is collapsed.
Important: Responsive breakpoints operate based on screen dimensions, not view dimensions—the same column breakpoints may produce unexpected or undesirable results rendering in a full-screen view compared to a narrow drawer.
Care should be taken to ensure that forms are either designed for their intended target dimensions, or configurable to suit the need.
select to activate