-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Input Fields: Replace Placeholders with Labels #13900
Comments
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. |
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: |
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. |
This is interesting — it's the same font size! |
@melchoyce Maybe a strange optical illusion? Or maybe a side effect of the text color change? Very interesting indeed! |
😄 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. |
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? |
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? |
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. |
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. |
Great 👍
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. |
❤️❤️❤️ 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. |
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! |
@jasmussen Any background you can remember on why the focus styles are inconsistent? |
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: |
Related ticket for core focus style: https://core.trac.wordpress.org/ticket/34904 /Cc @MichaelArestad |
This came up in today's design triage.. To recap what was stated there: There are three issues I see here:
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:
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:
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 If we went this route, we need some hard rules around this as far as when and where to use the
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. |
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:
NN/g article, The Magnifying-Glass Icon in Search Design: Pros and Cons
|
Some recent, important, news regarding one of the major design systems around: The Evolution of Material Design’s Text Fields 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. |
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! |
I believe a lot of the focus styles have been resolved with #21141. As @MichaelArestad pointed out:
I'm in agreement here. Let's get a label on the search field in the Inserter similar to the Block Manager. |
Both the block manager (preference, visible blocks) and the block inserter now has placeholders and visually hidden labels. |
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? |
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.
The text was updated successfully, but these errors were encountered: