Input Fields: Replace Placeholders with Labels

[melchoyce]

The search field in the Block Inserter does not currently have a visible label. There's a hidden label for screen readers, but it could be worth exploring what a visible label could look like:

This inline label is the same font size as the current placeholder, but uses #555d66 for additional contrast. It only takes up a couple extra pixels of space, so it'll still fit comfortable within the block inserter.

Note: the focused state uses #0073AA for the text, since the focus outline blue doesn't pass color contrast for text.

Could also potentially work for situations like #10125.

[kjellr]

This is a promising exploration, and it does get us to apply a (much needed) label to the search field. It also feels modern, and a little less cookie-cutter compared to the standard method of label placement.👍

My main concern is just around its usage. I don't think it makes a lot of sense to adopt something like this only for the search box. Or even just for a few fields throughout the interface. Ideally, we'd actually swap out all of our text fields with this to keep things consistent.

But... if that's the direction we took, I wonder if it's actually necessary? I like it visually, but from a practical standpoint, this really only saves us 8-10px or so versus just displaying the label above the field as we'd normally do.

[melchoyce]

But... if that's the direction we took, I wonder if it's actually necessary? I like it visually, but from a practical standpoint, this really only saves us 8-10px or so versus just displaying the label above the field as we'd normally do.

I agree we should apply this consistently, but I think that this depends — an area in which we aren't using any visible label, where the search bar is flush against the top of a container or popover, would lose upwards of ~20px:

[chrisvanpatten]

To be honest, I actually like the label above the field 🙈

I think the version with the inline label is really pretty, but the slightly smaller font size on the label is getting into small enough that it's "hard to read" territory. I think the space lost on the label/field stacked layout is more than made up in simplicity and readability.

[melchoyce]

I think the version with the inline label is really pretty, but the slightly smaller font size on the label is getting into small enough that it's "hard to read" territory.

This is interesting — it's the same font size!

[chrisvanpatten]

@melchoyce Maybe a strange optical illusion? Or maybe a side effect of the text color change? Very interesting indeed!

[melchoyce]

Definitely an optical illusion — one I'm glad you raised. I think we can push the font size up a little bit without a problem:

[kjellr]

To be honest, I actually like the label above the field 🙈

😄 Yeah, I don't think it's a problem either. It's clear and consistent, though it does lose us a bit of vertical space. That inserter is pretty sparse, so I think it's fine.

That all said — I'm still up for exploring the overlapping title comps too. I'd be interested in seeing how it might look elsewhere in the UI.

[sarahmonster]

A big win here is that the label + input field are more closely tied, making the relationship between the two more clear. It's also a more elegant solution in cases like this where we want a more minimal input (and thus sometimes resort to using placeholders, which we should definitely avoid).

For areas that use a lot of inputs close together, it's also possible this could ease cognitive load by aiding the distinction between different elements. The lack of visual contrast sometimes means this can be a bit unclear:

Either way, having the label gain a highlight on focus would be a big improvement to the existing component.

My concern is that this is a non-standard presentation, and I'd wonder if it could present usability issues. It would be great to see this tested, or to see if there's data on this pattern somewhere.

If this were a change we'd want to make, it seems like it would be one worth implementing across the UI, for increased consistency. It could be a good opportunity to unify text input styles, which tend to vary quite a bit, especially in regards to padding:

A good way to evaluate this change would be to apply it across other parts of the UI, and see how it works. What does it look like with the input box filled with text? With autocomplete tags? How does it work on an autcomplete or a select input?

[melchoyce]

Here are dropdowns and a textarea:

More coming later.

[chrisvanpatten]

I'm concerned that it might feel a bit too crowded once there's text in the field. The text starts to blend together a bit. I'd be interested in experiencing it in context though; maybe it's not as noticeable when you're actually interacting with it?

[melchoyce]

Yeah, definitely starts to get busy. Other implementations solve this by decreasing the label size, but I don't really want to do that. As-is, I've increased the size of the dropdowns by 2px in those mocks.

[joedolson]

We discussed this today in the Accessibility meeting, and it sounds great. We don't see any specific accessibility issues with having the label intersect the visual border, as long as the label remains visible and isn't intersected by the border. We'd also be totally fine with having the label above (obviously!)

Our primary concern is that whatever implementation we go with should be used consistently, so that labeling can be standard across the UI.

We also observed that none of these examples take into consideration multiline labels, so those will need to be considered.

[melchoyce]

We don't see any specific accessibility issues with having the label intersect the visual border, as long as the label remains visible and isn't intersected by the border.

Great 👍

We also observed that none of these examples take into consideration multiline labels, so those will need to be considered.

Ah, really good point! I'll make sure to explore that.

PS, if this doesn't work out, that's fine — this is just an idea. We're not locked into anything. 🙂 Regardless of whether we do an inline label, or a label above the field, or something else, we should find a way to make it consistent across all of Gutenberg (and eventually all of WordPress).

Going to update the issue title to make it more generic.

[sarahmonster]

we should find a way to make it consistent across all of Gutenberg (and eventually all of WordPress).

❤️❤️❤️

Re: text getting blendy, have we tried bumping the padding on inputs a smidge? A lot of the existing inputs have pretty tight padding already, and this may be a good opportunity to relax them a bit.

[afercia]

have we tried bumping the padding on inputs

Was recently working on a patch for core and ardently desired the core inputs were taller. The default ones height is only 25 pixels. Which is very small on today's screens. Also, selects and buttons have different heights so they look ugly when horizontally aligned, e.g.:

The height also varies depending on the operating system because it's partly based on the line-height and system fonts render differently.

I'd be totally in favor of reviewing the inputs, selects, buttons, etc. sizes holistically across WordPress 🙂 @melchoyce @sarahmonster I'd encourage you to explore a proposal to submit in a Trac ticket, when you have a chance!

[afercia]

Just noticed an example on Google spreadsheet, when inserting a link (Cmd+k) a popup opens with a couple fields:

Multiline label:

Also: love that focus style. Why we can't use the same styling in core and G.? 😄

[melchoyce]

What do you like about it? Gutenberg's is pretty similar IMO, just lighter:

[afercia]

Yeah but G. doesn't do that everywhere. Buttons and custom components for example:

[melchoyce]

@jasmussen Any background you can remember on why the focus styles are inconsistent?

[jasmussen]

Yeah those focus styles aren't ideal. I believe we should ideally try and move towards the same focus style that exists for textfields, to buttons. But without a slight redesign/tweak to the button, you'll likely end up with too little contrast between the dark border surrounding the button, and the actual focus style itself. Sure it'll be thicker and technically check that box, but honestly we can do better.

It's one of those things that's on the todo list. I got this far, but it's hard to work on these in isolation, it has to be looked at holistically in the context of all of wp-admin:

[afercia]

Related ticket for core focus style: https://core.trac.wordpress.org/ticket/34904 /Cc @MichaelArestad

[afercia]

Worth noting (just realized it) in Gutenberg there's also some inconsistency. For example, the search field in the main inserter has a visually hidden <label> plus a placeholder attribute:

The search blocks field in the Block Manager modal has a visible <label> and no placeholder attribute:

[MichaelArestad]

This came up in today's design triage.. To recap what was stated there:

There are three issues I see here:

1. The location and presentation of the label
2. Consistency among inputs and form controls
3. Focus styles

While I agree focus styles are important and could be improved, I'm not going to get into that on this issue.

Text inputs in WordPress (and most application) tend to live in two contexts:

1. A regular old form (settings, block inspector)
2. Inline (Search, inline setting)

Number one is a bit straightforward. I believe the label should be applied above the input just like the rest of the form controls.

Number two is a little more problematic and part of the root of this issue. Here are two examples of what I mean by an "inline" text input:

1. The search box for the block inserter
2. A text input that is inline with some text for some reason like this:

The inline text input situations are problematic because space is limited so using a standard "above the input" label is visually disruptive and feels out of place in context.

I think this might be a good case where we can have two text input label options coexisting. One would be for compact (inline/search) use, while the other would just have the standard "above the input" label.

If we went this route, we need some hard rules around this as far as when and where to use the compact label style. Perhaps something like this:

default: Use in most form settings including in the block inspector and when presented with other form controls.
compact: Use sparingly in situations where the input has limited space or is inline with text. An appropriate use case is the search box for the block inserter. A text input inline with text isn't ideal, so avoid when possible.

If we don't go this route, it might make sense to implement this "inline" styling as Mel has design just for the block inserter to reduce confusion and prevent it from being misused in other places.

[davewhitley]

Commenting on the original concern of the issue — block inserter search:

If I remember correctly, I believe it would be ok to not have a visible label for the search block field. A search icon in the field itself should be sufficient. As Michael commented:

Use sparingly in situations where the input has limited space or is inline with text. An appropriate use case is the search box for the block inserter.

NN/g article, The Magnifying-Glass Icon in Search Design: Pros and Cons

Users understand the icon enough that, when styled appropriately, spelling out the word “Search” as a label is no longer required.

[afercia]

Some recent, important, news regarding one of the major design systems around:

The Evolution of Material Design’s Text Fields
November 1, 2019
https://medium.com/google-design/the-evolution-of-material-designs-text-fields-603688b3fe03

Despite the fact Material uses "floating labels" and other design details, the key point here is the research they made, the collected data, and user testing with 600 participants.
From an accessibility perspective, their research proved text inputs benefit from visible labels. Material design being updated to reflect that finding (and others).

[paaljoachim]

I just want to say that reading through this issue that it feels like it is heading in a very good direction! Thank you everyone!

[mapk]

I believe a lot of the focus styles have been resolved with #21141.

As @MichaelArestad pointed out:

Number one is a bit straightforward. I believe the label should be applied above the input just like the rest of the form controls.

I'm in agreement here. Let's get a label on the search field in the Inserter similar to the Block Manager.

[carolinan]

Both the block manager (preference, visible blocks) and the block inserter now has placeholders and visually hidden labels.
There are some inconsistencies, but do we still want to go forward with this change, or can the issue be closed?
@jameskoster @karmatosed

[jameskoster]

Reading through the comments it looks like the discussion gravitated towards the concept of having inputs labels intersect the input stroke.

The Design Tools project (#33447) seems to have moved in a slightly different visual direction, so perhaps we can close this?