Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update to include required labeling guidance #2531

Merged
merged 3 commits into from
Sep 28, 2021
Merged

Update to include required labeling guidance #2531

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
70ed28c
Update to include required labeling guidance
jjennings7 Aug 31, 2021
8a0af50
Merge branch 'main' into patch-2
kingtraceyj Sep 27, 2021
c16abfa
Merge branch 'main' into patch-2
laurenmrice Sep 28, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 68 additions & 6 deletions src/pages/patterns/forms-pattern/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -120,21 +120,64 @@ Advantages:
entry errors, top-alignment is ideal.
- This arrangement is best when fewer form fields need to be presented.

#### Optional vs. mandatory
### Optional vs. mandatory

All fields in a form are assumed required, with optional fields being tagged as
so in the label. An excess of optional fields should be avoided. If it's
necessary to have a large number of optional fields, we recommend devoting an
entire section to optional fields to avoid excessive repetition.
Forms items can be labeled as either optional or required depending on several factors. A common distinction in IBM products for using required or optional is the forms complexity.
1. **Simple forms** - generally shorter and/or user- or consumer-oriented; such as sign-up and contact forms and checkout screens. Most of the fields will tend to be required.
2. **Complex forms** - generally longer and product-oriented; contain properties and settings that are used to configure Enterprise software.  Although they will usually contain at least one required field, the majority of the fields will tend to be optional. 


Note if the majority of the fields are **required** or **optional**, as the overall number of form fields for your entire product should inform your treatment. The pattern used should be consistent throughout your product, or at minimum, consistent between all of the same types of form within your product. 
- If the majority of the fields are required, mark **only** the optional field labels with *(optional)*. 
- If the majority of the fields are optional, mark **only** the required field labels with *(required)*. 


When designing your form, consider the purpose and the use case to reduce visual noise and clutter to allow your user to better complete their task. This will also ensure consistency through and across products. 


An excess of optional fields should be avoided. If it’s necessary to have a large number of optional fields, we recommend devoting an entire section to optional fields to avoid excessive repetition.
<Row>
<Column colLg={8}>

![Example of a short user sign-up form using the Optional pattern](https://user-images.githubusercontent.com/48838320/131423440-a369fc22-893b-4d9c-9950-adf837ea712a.png)

</Column>
</Row>
<Row>
<Column colLg={8}>

![Example of input field with optional label](/images/optional_v_mandatory.png)
![Example of product configuration properties using the Required pattern](https://user-images.githubusercontent.com/48838320/131423528-58fa9767-6640-4878-bf02-9561886fef9a.png)


</Column>
</Row>

#### When to use


<DoDontRow>
<DoDont
caption="DO mark fields (required) when the majority of the fields are optional.">

![DO mark fields (required) when the majority of the fields are optional.](https://user-images.githubusercontent.com/48838320/131426053-89fb3cf7-d9e1-497e-a41f-a1e6b5035666.png)

</DoDont>
<DoDont
type="dont"
caption="DON'T mark fields (optional) when the majority of the fields are optional.">

![DON'T mark fields (optional) when the majority of the fields are optional.](https://user-images.githubusercontent.com/48838320/131426096-8fbcde66-9f0e-48f4-8e40-20311d88ba8b.png)

</DoDont>
</DoDontRow>

#### Best practices

- Consider the overall number of required and optional fields in the forms for your entire product. The pattern used should be consistent throughout your product, or at minimum consistent between all of the same type of form within your product.
- For example, if you have 100 types of connections properties forms and the fields are optional in 85 of the 100 forms, all 100 should use the required pattern. 
- Use the techniques illustrated below in the [Default Values](#default-values) and [Designing for Longer Forms](#designing-for-longer-forms) sections in order to make your forms easier and more efficient to use. 


### Text inputs

Free-form text inputs are the most commonly used components in forms.
Expand Down Expand Up @@ -341,6 +384,17 @@ the user or formatting is in question, use placeholder text.
- Provide placeholder text when it isn’t necessary.
- Ever use placeholder text as a replacement for field labels.

#### Default values

Default values can be set for for all types of inputs. Ensure that if a default value is provided, it is something that would commonly be used anyway and would not cause disruption or errors if the user forgets or opts not to make any changes to it before submitting the form. Good default values reduce cognitive load.


For example:
- If you can detect or determine where your users are from, have their country pre-selected in a "Country" dropdown.
- If there is a common or minimum value (i.e., a quota or memory limit), pre-fill that value.
- If a text input can be detected or determined in advance (i.e.-company name), pre-fill that value.
- If a start date is required, use the current date as the default.

### Buttons

Use a primary button for the main action, a secondary button for secondary
Expand Down Expand Up @@ -828,6 +882,9 @@ in-depth accessibility guidance for each form element.

### Further reading

- Nick Babich,
[The Power of Defaults](https://uxplanet.org/the-power-of-defaults-992d50b73968)(UX Planet, 2017)
- Raluca Budiu, [Marking Required Fields in Forms](https://www.nngroup.com/articles/required-fields/) (Nielsen Norman Group, 2019)
- Andrew Coyle,
[Design Better Forms](https://uxdesign.cc/design-better-forms-96fadca0f49c),
(UX Collective, 2016)
Expand All @@ -837,6 +894,11 @@ in-depth accessibility guidance for each form element.
- Marieke McCloskey,
[Accordions Are Not Always the Answer for Complex Content on Desktops](https://www.nngroup.com/articles/accordions-complex-content/),
Nielsen Norman Group, 2014)
- Jakob Nielsen,
[The Power of Defaults](https://www.nngroup.com/articles/the-power-of-defaults/)(Nielsen Norman Group, 2015)
- Preibusch et al., [*The privacy economics of voluntary
over-disclosure in Web forms*](http://preibusch.de/publications/Preibusch-Krol-Beresford__voluntary_over-disclosure.pdf)(2013)


## Feedback

Expand Down