Text Input - Usage
Basic Guidelines
Content
- Only ask what is really required – consider why you are requesting certain information and how it will be used. Any extra form field will affect its conversion rate.
- Order form fields logically from the user’s perspective and group related information.
- Do not present information that cannot be changed as a form field. Information which has already been submitted via a form, should be displayed as regular copy instead.
Labels tell the user the purpose of the field and therefore make the UI more accessible.
In-line messaging is an optional text field that can be used for further information, clarifying the required input, for example intended formatting like dates (DD/MM/YYY) or Sort Codes (xx-xx-xx).
Validation messages inform the users about the correctness of the input. Error messages in particular need to be clear, precise and constructive. This field is optional for the Success state.
States Usage
Success & Error Variant
The Success variants are available for legacy reasons, but not implicitly necessary. Form fields are validated on submit, which means the form is either sent without issues, or updated showing an error. If errors are rectified, the form needs to be submitted again to trigger another validation. If everything is ok, the form is submitted and it’s not necessary to display a success state.
There are two ways an error can occur:
- The text input field is required but was left blank before submitting
- The input information did not reach validation.
The error message will be displayed directly beneath the input field.
Mandatory Fields
Any text field can be set to be mandatory. An asterisk will be displayed in front of the label. Please make sure that the meaning of the asterisk is explained to the user at the top of the form. It is not necessary to mark fields as optional.
Disabled and Read-only – What’s the difference?
Visually the Diasbled and Read-only input fields look exactly the same, but their properties in the final product will differ. Here is a quick comparison:
Disabled
Attributes:
- No tab stop - Not focusable
Use Case:
This is an intermediate state while the form is being submitted, and would only ever be used if that state is shown in the prototype. It is generally not recommended to use this state for designs.
Read-only
Attributes:
- Tab stop - Focusable
Use Case:
When presenting the selection in a previously submitted form. Users with screen readers can listen to this information.
Content Guidance
It is recommended to limit character lengths to avoid text being truncated. Labels should always be clear and to the point.
Do not write needlessly long labels to avoid them becoming truncated.
Alignment
Form fields should be stacked vertically in one column for an easy flow through the form. The 32px gap is space saving, while still providing enough space between the fields to display the labels.
The Text Input component must align with the grid system set out in Foundations. It sits in-line with the rest of the text.
In a 12-column grid layout, the text input fields sit left-aligned within the six centre columns of the grid, in-line with the rest of the text. Their width should be based on the content they’re expected to receive, but is generally recommended to be set to three columns wide.
Icon Usage
It is generally not recommended to use other icons within the text field (e.g. Email or Calendar, etc.), as they don’t provide any functionality, nor offer valuable information for the user.
