-
Notifications
You must be signed in to change notification settings - Fork 361
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.
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
Interface guidelines for forms #261
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/primer/design/HB9nUYhJHRyZScuq3CRNy9UXr4BS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What a phenomenal amount of work, thank you for writing all this up! 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a general note, we should revisit the alternate text from the images — Instead of saying like "diagrams labeling the anatomy of a text field and a checkbox field", the alternate text should describe what's present in the diagrams or screenshots.
content/ui-patterns/forms.mdx
Outdated
|
||
If you're having trouble keeping label text short, consider using a [caption](#caption) to provide more context. | ||
|
||
In rare cases, a label may be hidden when the user has enough context to understand what the input does. When a label is visually hidden, label text must still be provided for assistive technology such as screen readers. For example: a search field with an icon that is placed in the spot a user would expect to find a search field may have a visually hidden label that says "Search". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In rare cases, a label may be hidden
For example: a search field with an icon that is placed in the spot a user would expect to find a search field may have a visually hidden label that says "Search".
Is a search field part of a forms pattern? Search fields appear throughout dotcom, and they're not rare =).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is a search field part of a forms pattern?
It could be, but usually it isn't. I was trying to think of the most common and obvious example.
Do you (or any other reviewers) have any better examples?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mperrotti I'm not sure. It's confusing to see an example about a search field while this page is specifically about [long-form] forms pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point about these guidelines being for long-form forms. I think it might be best to exclude this paragraph. Visually hidden labels can be addressed in form component guidelines.
</Dont> | ||
</DoDontContainer> | ||
|
||
### Validation message |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The examples using checkbox groups have some weird application of bold. Do we really want to use bold labels for every checkbox or radio button item? Are the validation messages also meant to be bold? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are all meant to be bold. That's how the components are currently designed.
I'd be happy to change the checkbox and radio labels from bold to regular weight in separate PCSS and PRC PRs. What do you think @vdepizzol?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the intent with the semibold label
is that the styles are consistent through all form elements (so input
, select
etc.) But I don't feel that the validation messages should also be semibold.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The semibold error messages are kind of new: primer/react#2013
@colebemis and I think it helps the text feel more balanced with the leading icon, but I'm open to changing it back to regular weight it if it's causing an issue.
Other reviewers - please chime in if you agree with @langermank that validation text should go back to regular weight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mperrotti I'd keep it at a regular weight. Validation messages can appear multiple times to the user in the same form. The bolded font feels too heavy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'll update the example images and submit a PR to PRC to change the weight back to normal.
content/ui-patterns/forms.mdx
Outdated
<img | ||
alt="Checkbox that progressively discloses a labeled text input" | ||
src="https://user-images.githubusercontent.com/2313998/164065217-7969283a-6dbb-43b6-8f62-e4ab995de246.png" | ||
/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right - this isn't a great example. I'll come up with a better way to show a labeled input that is "nested" and progressively disclosed.
content/ui-patterns/forms.mdx
Outdated
alt="screen recording of valid repo name input showing loading indicator after blur" | ||
src="https://user-images.githubusercontent.com/2313998/164065857-573ca6db-f2c7-49ac-a3cf-bf479a40973d.gif" | ||
/> | ||
<Box as="p" mt="0">If the form control’s validation is likely to take more than 1 second, show a loading indicator.</Box> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the form control’s validation is likely to take more than 1 second
Is this the right metric to decide whether to display a loading indicator? What if the process is known as a quick one but the user is on a slow connection?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if we're extending the height of the input control based on an async request that may take long to process, how do we avoid the content to reflow unexpectedly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the right metric to decide whether to display a loading indicator? What if the process is known as a quick one but the user is on a slow connection?
It shouldn't matter what connection the user is on. This is a detail that would be handled in the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, if we're extending the height of the input control based on an async request that may take long to process, how do we avoid the content to reflow unexpectedly?
That's a great question, and I have no idea how we'd avoid reflow in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the right metric to decide whether to display a loading indicator? What if the process is known as a quick one but the user is on a slow connection?
It shouldn't matter what connection the user is on. This is a detail that would be handled in the implementation.
@mperrotti if there's a server request, wouldn't it make more sense to show the loading spinner regardless? I don't understand how that'd be handled in the implementation 🤔 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if there's a server request, wouldn't it make more sense to show the loading spinner regardless?
@vdepizzol - I was trying to avoid showing too many loading indicators because they could make the app feel slower. If we wait 1 second, we're still giving the user feedback that something is happening, but only if it's something that's making the user wait a noticeable amount of time.
Does that make sense?
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Inayaili León <yaili@github.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
Co-authored-by: Cameron Dutro <camertron@gmail.com>
content/ui-patterns/forms.mdx
Outdated
<Box sx={{fontSize: 3}} class="lead" as="p"> | ||
Forms are used to complete tasks that require data input from the user. For example: creating a new repo, configuring settings, and logging in. | ||
</Box> | ||
|
||
<Box sx={{fontSize: 3}} class="lead" as="p"> | ||
Primer's form design guidelines aim to minimize the effort and cognitive load required to complete a task that involves a form. | ||
</Box> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mperrotti Can we simplify this leading description and make it into a single paragraph?
Forms are used to complete tasks that require data input from the user. For example: creating a new repo, configuring settings, and logging in.
Primer's form design guidelines aim to minimize the effort and cognitive load required to complete a task that involves a form.
</div> | ||
</Box> | ||
|
||
### Inline validation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mperrotti I'm finding it quite confusing to see these 3 gifs next to each other. There's a lot going on 😬 . I'm not sure I have any recommendations for now, but it's something we should pay more attention...
Screen.Recording.2022-05-23.at.10.49.45.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right - all this motion is overwhelming. I'm going to try converting these to <video>
elements that can be played or paused individually.
content/ui-patterns/forms.mdx
Outdated
|
||
<DoDontContainer> | ||
<Do> | ||
<img role="presentation" src="https://user-images.githubusercontent.com/2313998/166832266-c34634ec-2ade-4bf6-8401-df0bdc02b324.png" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mperrotti This "do" example feels quite redundant 🤔
@mperrotti I think we should have a rationale for form widths when in a form composition. It's hard to parse from the examples what the recommendation should be:
|
Co-authored-by: Vinicius Depizzol <vdepizzol@github.com>
@vdepizzol - I pushed a few commits to address your feedback. I used a browser-native |
</Box> | ||
<Box as="ul" pl="1rem"> | ||
<li> | ||
Single-line text inputs get a default width set by the browser, but their width can be changed to fit the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the default width? It might be helpful to mention that here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't define the default width - It's set by the browser.
All of the requested changes have been made and this has just been sitting here. I'm merging it. If there are additional changes needed, we can file issues and create new PRs. |
These changes introduce high-level interface guidelines for designing forms.
More specific guidelines for each form-related component will follow in separate PRs.