Text input component: enhance/clarify guidance re placeholder and helper text both being optional

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 as placeholder 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:

@tomerton placeholder text AND helper text are optional, but I understand your point that we don’t explicitly say “Optional placeholder text” like with do with helper text. I think this could be cleared up with just, clearer guidance/visuals… so people know placeholder and helper text are both available AND optional and when to employ them.

Suggested resolution:

• make it clear that both placeholder text and helper text are optional.
• provide some different (valid) examples that demonstrate that designers should use their judgement to use or not use placeholder text and helper text, depending on the scenario.
  • Perhaps one example could be of a simple / common field such as “First name” where only the text input label is needed.
  • Perhaps one example could be for a “Date” field where placeholder text has also been used to indicate the date format (MM/DD/YYYY or similar) but no helper text has been used.
  • Perhaps one example where a field has a text input label, no placeholder text, but does have helper text. This could be an example where you want the info to always be visible to the user — even when they are typing into the input field.

Another suggestion (vai Slack) from @jeanservaas

One resolution I see is showing both type options (both helper and placeholder) in an anatomy image and flagging them as optional there. Our text input usage docs are very scant and it doesn’t look like they’ve even been updated to Jan’s new Usage doc template.

[aagonzales]

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.

[tomwaterton]

Hi @aagonzales

My thoughts, looking at the 3-part image example from your comment:

• 1st example: We recommend that people only use placeholder text where it adds value; we recommended they do not use placeholder text if it merely repeats the field label, so this first example (“Enter user name”) is not one we’d want to recommend.
• 2nd example: I think this is good.
• 3rd example: Again, we recommend that people do not use placeholder text if it merely repeats existing helper text, so I think this also is not one we’d want to recommend.

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.)

Are any of the following acceptable, or are these all don’ts?

• a) Instructions as a placeholder
• b) Example as a placeholder
• c) Formatting as a placeholder (if also included in helper text)

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:

If you have usefully used placeholder text in one form field, do not think that the other form fields now need to have placeholder text also. Placeholder text should only be used where it adds value. Do not use placeholder text to merely repeat the field label (or helper text).