Design Pattern Library - Forms
Changes introduced
- Changed label font weight to bold (except radio and checkbox labels)
- Introducing predefined widths for input fields
- Introducing a standardised datepicker (input + dropdown)
- Email, date and time input field types are stylistically the same as a regular input field but they should be added to the design system as examples and code snippets because they improve the accessibility and their usage should be encouraged
- disabled input field background color changed from
#ffffff
to#f2f2f2
- disabled text style color changed from
#dfdfdf
to#707070
Changes to Design Library
- Changed labels to bold
- Added a validation error example to the Forms artboard (using existing symbols)
- Added examples of Placeholders to the Forms artboard (using existing symbols)
- Added state examples for Checkbox and Radio buttons to the Forms artboard and made sure the labels aren't bold (using existing symbols)
- Added a Checkbox/Radio + label + help text (new symbol + example on Forms artboard)
- disabled input field background color changed from
#ffffff
to#f2f2f2
(changed existing symbol) - disabled text style color changed from
#dfdfdf
to#707070
(changed existing styles) - Added notes for the Measure specs
Usage & guidelines
Label positioning
Above by default. It works with most cases. If the form is vertically distributed the labels must be above the input fields.
Left for single input fields (e.g. search, 'sort by' dropdowns) and when the form is distributed horizontally.
Placeholders
We're moving away from using placeholder text instead of labels. Ideally, the placeholders shouldn't be used at all, if they are, they should be short, contextual and helpful.
One-direction forms
We're moving away from distributing forms to multiple columns/rows. If the form progression is vertical it should only have input fields in one column, if its progression is horizontal, it should only be in one row.
Stacking input fields
Despite the 'one-direction forms' guideline it's ok to stack related input fields next to each other (example: Name and Surname).
Explanatory text for radio & checkboxes
We're standardising explanatory text that often comes with radio buttons and checkboxes. The labels for those are now regular so we'll be using the Help text style for explanations below the labels.
Disabled buttons
We default to active buttons in forms. Disabled buttons that become active by interacting with the interface can be used as an exception. (details: gitlab-org/gitlab-ce#40922)
Buttons should be disabled once clicked so that the possibility of submitting forms more than once is not possible.
Disabled input fields
We need to explain why an input field is disabled when it is. We'll use Help text below the disabled field to do this. We're moving away from using placeholders for such cases.
Input field width
The width of the input field should match the expected content, that's why we're introducing a range of predefined widths. It's ok to use a width outside that range but it should comply with our 8px spacing rule.
TODO When do we match the input field width to its content? How much control do we have over that (technically speaking)?
Dropdown usage
Using a dropdown can often be avoided by using a better-suited alternative. Segmented control is a good example. When there are only a few options to choose from (up to five), segmented control should be used.
Dos and dont's
(Use this table to add text and code samples describing what’s ok and not ok.)
|
|
---|---|
Related patterns
(List any related or similar solutions. If none, write: No related patterns)
Links / references
Pattern checklist
Make sure these are completed before closing the issue, with a link to the relevant commit, if applicable.
-
Ensure that you have broken things down into atoms, molecules, and organisms. -
Check that you have not created a duplicate of an existing pattern. -
Ensure that you have used the proper method for creating the pattern depending on the complexity. Atoms and molecules are symbols, organisms are groups. -
Make sure that typography is using text styles. When applicable used shared styles for colors. -
QA check by another UXer -
Add changes to the pattern library -
[ ] Add a merge request that includes any new or updated guidelines to the Design SystemSeparate issue (gitlab-org/design.gitlab.com#37) -
[ ] Add an agenda item to the next UX weekly call to inform everyone (if new pattern, not yet used in the application)Not a new pattern
/cc @cperessini @dimitrieh @hazelyang @jkarthik @pedroms @sarrahvesselov @sarahod @tauriedavis @katokpara @mlatin