-
Notifications
You must be signed in to change notification settings - Fork 771
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
Text input component: enhance/clarify guidance re placeholder and helper text both being optional #2928
Comments
When we make this update, we should update the storybook to remove placeholder from relevant examples. |
I pointed out this along with a lot of other considerations in our review of the Input usage page . An anatomy section would really help clarify this as well. |
Note that that would be a date input, not a text input. And i strongly urge Carbon NOT to use this as a desirable example. As stated in our review of Date picker, using the placeholder for the input requirement is problematic. I also have an issue open specifically about date input masks carbon-design-system/carbon#11805 |
We have recently updated the text-input usage guidelines (updates are now live, PR for reference)
Remaining tasks:
|
@tomwaterton @mbgower If y'all could read through the new docs when you have time and see if we have addressed this problem (outside the remaining issue mentioned in the above comment. |
Hi @aagonzales Obviously, to make the guidance really clear, the remaining tasks you mention need to be done as well, but I understand that some of those require dev work and design work — and therefore will take more time to happen. |
I'll also just mention, in case it helps, that I had also raised a separate but related bug:
(Basically, requesting some improvements to the guidance relating to placeholder text and helper text within the Carbon form component.) |
Checking this morning... |
I feel like I already wrote much of the following as feedback. Maybe I failed to push the Comment button and it was lost...? Live demoAs per @tomwaterton's comment, I think a very easy change would be to make the Live Demo (shown below) say "Optional placeholder text" instead of just "Placeholder text" AnatomyI think the Anatomy is a welcome addition (shown below). It's good to go, but I did want to mention a couple of things that gave me pause...
Main elementsIn the Main elements section, I think there needs to be a bit of attention on this line from labels:
"Input requirement" is listed as optional in the anatomy, so this could be slightly confusing. I suggest two thing could help with this 1) use the same term in the anatomy (currently "Input requirement) and do some slight rewording 2) cross reference the Forms material on this. You'd end up with something like the following (and maybe this is enough you'd want to give it its own subsection?
For Helper text, I think I flagged that before, but I don't understand where Carbon says a tooltip can be used for help -- is it covered somewhere? If not, since you've already said this is optional, I'd just take the whole following line out?
I also found the following line a little confusing:
I think it might work better as:
For the Placeholder text, please state explicitly that it should not be used as a replacement for a label. I suggest modifying the second sentence from:
to:
It's nice you've added an Accessibility best practices section, but I feel like these are already covered on the Accessibility page. Maybe it could be as simple as something like this:
Universal behaviorsI wonder if this information could be offered once in Carbon and simply linked to from each component. Much is not unique to Text input. I found the Default values section a bit of a curve ball. It seems like it may be better covered in Forms? "Required vs. optional" Interactions"A separate click is required to activate any additional actions associated with the text input such as a tooltip..." Really? I wasn't aware of that! This is all great! |
Link to stub issue about accessibility concerns with text area features: |
@tomwaterton @mbgower can either of you think of another example of acceptable placeholder text for a text input? Are any of the following acceptable, or are these all don'ts?
|
Those seem to be the primary uses. I would remove "Example" from your second one. They don't tend to have that. My primary piece of advice would be the placeholder should be redundant with other information. The true test? The interaction should still be easy to complete if the placeholder text is removed. "Removal" is the same basic test I use for colour and several other things, to confirm that I wasn't relying on that information. |
Hi @aagonzales My thoughts, looking at the 3-part image example from your comment:
My thoughts regarding your other question:(I've added a, b, c to make it clear which one I'm referring to in the text that follows.)
a) No. Because placeholder text is hidden/becomes unavailable to users as soon as they start typing into the field, instructions should really be provided as helper text (which will remain visible/available to the user throughout). b) Some examples are fine. They shouldn't contain essential information (such as format) because that should always be available and so should be provided as helper text. But sometimes providing an example of the kind of thing the user might enter is useful. Here's an example: c) No. As mentioned above, we don't want people to be needlessly duplicating content — that just makes our UIs look overly busy. So if formatting information is given in the helper text below an input field, then there is no need to duplicate that same info as placeholder text. A final thought:I think some designers almost feel like they should use placeholder text, which often results in them just duplicating the field label (or helper text). To help prevent this, I think it would be great if we added an explicit statement addressing this. For example:
|
I just spotted this example of placeholder text in a product UI, so thought I'd share it as another possible example for you, @aagonzales (though if you do choose to use this, please first correct the capitalization to sentence case!) |
Tom's comments are all valid (although his 2nd example became username instead of email). With his comments in mind, Anna, if you were looking for what to actually provide as placeholders in those examples, I think you'd likely need to change at least the first example: Full name: Jane Smith I think the search example is useful, especially if you think of one where there IS no search label, since the magnifying glass serves as an after-the-fact label (and I'm not defending that) |
Side note, the example I showed wasn't supposed to be a form, just single examples of possible placeholder content (illustrating examples mentioned in the list). Search is a good example of placeholder but that is its own component and not a text-input. |
I believe most of the concerns and suggestions in this issue have been addressed. If anyone see's anything that is still incorrect, please comment but I am closing this as complete for now. |
@aagonzales I note the anatomy section entirely leaves off Placeholder text now, which I didn't think was anyone's intention? Finally, it looks like none of the substantial Sept 7 comments I made have been incorporated. I did a quick search on the first few (none changed), then noticed that it looks like no commits were pushed since August, so if so obviously my fairly numerous comments above may not have been seen? On the other hand, last time I ventured a conjecture like this, I think maybe they were picked up in some revised component, so happy to be corrected :) |
Ah just noticed the prior comment:
Okay, that's fine, so you can ignore "I note the anatomy section entirely leaves off Placeholder text now, which I didn't think was anyone's intention?" |
Website documentation has been updated (in Fluid branch that will be published soon) to address placeholder and helper text concerns. I will open a new issue to address adding additional clarity to the Figma kits. |
Closing as complete for now (updates won't be live yet but are in staging) but in the future you still notice problems, please feel free to comment |
The guidance for the text input component needs clarifying / enhancing
Detailed description
On the usage tab of the text input component (here: https://carbondesignsystem.com/components/text-input/usage/), currently the helper text is referred to as
Optional helper text
but placeholder text is simply referred to asplaceholder text
which could lead people to assume that placeholder text is always required, which is not actually the intention.Here is a screenshot of what is currently shown on the text input page:
Slack comment from @jeanservaas from earlier today:
Suggested resolution:
Another suggestion (vai Slack) from @jeanservaas
The text was updated successfully, but these errors were encountered: