Currently, there is no place for properly documenting Forms patterns int he current docs structure.
Create the content, and include it in the structure and TOC.
Forms Pattern Content – Outline:
Forms
- When to use a form
Inline form vs. modal form vs. dedicated form page — when each is appropriate
Reference to the Modals doc for modal-specific guidance
- Form layout
Single-column vs. two-column layouts
Field ordering — logical grouping, progressive disclosure
Required vs. optional fields — labelling conventions
- Validation
When to validate — on blur, on submit, or inline as-you-type; pros/cons of each
Inline field errors vs. summary errors at the top — when to use which
Cross-field validation (e.g. "password must match")
Reference to error-handling-loading-empty-states.md for error message wording
- Conditional and dependent fields
Showing/hiding fields based on other field values
Keeping hidden field state when fields reappear
- Submit and cancel actions
Button placement and order (primary action, cancel)
Disabling submit until valid — when this helps vs. hurts
Destructive submit actions — confirmation strategies
Reference to ux-writing-content-design.md for button labels
- Submission feedback
Success: what to show after a successful submit (in-page message, navigation, inline confirmation)
In-progress: busy/loading state on the submit button
Failure: server-side errors vs. validation errors — how to surface them
Reference to messages-and-notifications.md
Forms Pattern in the Current Structure of Our Docs
Add Forms (or find a better, more descriptive title) as a second level item under UX Patterns/iv. Forms, effectivley shifting Wizard Pattern to v.
Currently, there is no place for properly documenting Forms patterns int he current docs structure.
Create the content, and include it in the structure and TOC.
Forms Pattern Content – Outline:
Forms
Inline form vs. modal form vs. dedicated form page — when each is appropriate
Reference to the Modals doc for modal-specific guidance
Single-column vs. two-column layouts
Field ordering — logical grouping, progressive disclosure
Required vs. optional fields — labelling conventions
When to validate — on blur, on submit, or inline as-you-type; pros/cons of each
Inline field errors vs. summary errors at the top — when to use which
Cross-field validation (e.g. "password must match")
Reference to error-handling-loading-empty-states.md for error message wording
Showing/hiding fields based on other field values
Keeping hidden field state when fields reappear
Button placement and order (primary action, cancel)
Disabling submit until valid — when this helps vs. hurts
Destructive submit actions — confirmation strategies
Reference to ux-writing-content-design.md for button labels
Success: what to show after a successful submit (in-page message, navigation, inline confirmation)
In-progress: busy/loading state on the submit button
Failure: server-side errors vs. validation errors — how to surface them
Reference to messages-and-notifications.md
Forms Pattern in the Current Structure of Our Docs
Add
Forms(or find a better, more descriptive title) as a second level item under UX Patterns/iv. Forms, effectivley shifting Wizard Pattern to v.