UI: Placeholder in Text fields #111436

New Issue

Pablo Vazquez · 2023-08-23T15:58:14+02:00

Pablo Vazquez commented

2023-08-23 15:58:14 +02:00

Intro

The text field in Blender is currently missing a feature that's present natively in web browsers and it can help accessibility and a clearer UI: placeholders.

Placeholders are a (brief) hint added to text fields, that describe what the field does or give a possible example of the content that should be in that field.

Examples

A search field's icon is usually enough, but sometimes it's not enough context as to what can be search for.

A data-block picker where the label doesn't necessarily explains which type is compatible with (other than the data-block icon):

Data-block selectors could have, by default, a placeholder with the name of the data-block type they support.

Sometimes we have a long field that expects content written in a certain way, but at a glance there are no hints about it:

A brief hint could work as example of what type of content the field expects:

Theme

The hint text in placeholders should be subtle yet visible but not nearly as prominent as the field's content. There's no need to add a new color theme for this as we could simply use the text color but with a 15% opacity (I think Firefox uses 20% by default).

Usage

Setting a placeholder could be done via a new attribute similar to text, called placeholder. They contain text and can be translated. Placeholders can be added to fields of type text, password, or future more specific ones like URL, email, that require more specific validation.

layout.prop(profile, 'email', text="Email", placeholder="email@example.com")
layout.prop(file, 'filepath', text="", placeholder="Path to folder")

Placeholders are not a replacement for tooltips or labels. They are just an extra hint of information that can, in some cases, work as label when there's no room for one. For example inside nodes, narrow popovers or some modifier layouts.

## Intro The text field in Blender is currently missing a feature that's present natively in web browsers and it can help accessibility and a clearer UI: *placeholders*. Placeholders are a (brief) hint added to text fields, that describe what the field does or give a possible example of the content that should be in that field. ## Examples A search field's icon is usually enough, but sometimes it's not enough context as to what can be search for. ![image](/attachments/101154e6-9aa7-4d66-9ad4-521943c060a0) A data-block picker where the label doesn't necessarily explains which type is compatible with (other than the data-block icon): ![image](/attachments/06a961a5-c04f-49d6-975b-b7a48bd53c71) Data-block selectors could have, by default, a placeholder with the name of the data-block type they support. ![image](/attachments/381040e5-8a22-45b7-8edd-a7c3809bdb31) Sometimes we have a long field that expects content written in a certain way, but at a glance there are no hints about it: ![image](/attachments/b6a8bf72-0c2b-414e-b855-031c82be5272) A brief hint could work as example of what type of content the field expects: ![image](/attachments/c32e03aa-07f7-4db5-a18a-5a1cf69e8438) ![image](/attachments/4990346a-3f60-41af-9f5f-c21ce4608dd8) ### Theme The hint text in placeholders should be subtle yet visible but not nearly as prominent as the field's content. There's no need to add a new color theme for this as we could simply use the text color but with a 15% opacity (I think Firefox uses 20% by default). ### Usage Setting a placeholder could be done via a new attribute similar to `text`, called `placeholder`. They contain text and can be translated. Placeholders can be added to fields of type `text`, `password`, or future more specific ones like `URL`, `email`, that require more specific validation. ```python layout.prop(profile, 'email', text="Email", placeholder="email@example.com") layout.prop(file, 'filepath', text="", placeholder="Path to folder") ``` Placeholders are **not** a replacement for tooltips or labels. They are just an extra hint of information that can, in some cases, work as label when there's no room for one. For example inside nodes, narrow popovers or some modifier layouts.

image.png

9.0 KiB

image.png

16 KiB

image.png

14 KiB

image.png

12 KiB

image.png

16 KiB

image.png

86 KiB

image.png

87 KiB

image.png

9.4 KiB

image.png

4.1 KiB

image.png

10 KiB

❤️ 10

Pablo Vazquez added the

Type

Design

label 2023-08-23 15:58:14 +02:00

Pablo Vazquez added this to the User Interface project 2023-08-23 15:58:16 +02:00

Pablo Vazquez added the

Module

User Interface

label 2023-08-23 16:17:17 +02:00

Harley Acheson commented

2023-08-23 20:39:48 +02:00

I quite like this.

William also proposed this during the 2.8 work, but I can’t find it. It might be nice to dig it up in case there was any work toward it, or comments or concerns. This might seem like a no-brainer, but there are some gotchas.

Having these can create redundancy when the label and placeholder match, which can lead to the temptation to remove labels. Removing labels can cause strain on short-term memory. Basically the one thing that they are actively interacting with does not show the text unless they move away from it or empty it.

Placeholders also fill up the content more in a way that makes it harder to notice empty fields. Conversely it also makes it harder to notice non-empty fields. Although we would have control over which inputs have placeholders, I think once we started there would be a pull to have them on everything.

They can give extra visual weight to items that are meant to be optional and used infrequently. An example is how prominent “Search Properties” looks in the example above. When shown within a larger blender window that text could look like a title because of the placement and our current design. Note that your tabs proposal would eliminate this problem since it adds a titled area above.

The placeholder text cannot be super dim, as that would cause issues with users with eyesight impairment. But it also can’t have such contrast that the placeholder can be confused with content text. This is a delicate balance. I’d need to see samples with both dark and light themes. It is possible that a simple opacity change might not be enough in all cases because of our different perception of light highlights verses dark. We’d also want to consider these versus disabled text fields which might look similar.

The biggest question for me is what happens when a user tabs into, or clicks on, an empty field. Many implementations, including css ::placeholder, continue to show the placeholder text while actively editing (showing the text caret) if there are no characters entered. And will show the placeholder again if you delete the last character. When the contrast is sufficient for eyesight-impaired users it can lead to the situation where some users can be confused about whether they need to manually remove the text. This issue is usually more associated with users with some cognitive impairment. Although this applies to us less, I still like having a good accessibility score.

If the placeholder text is not ever shown during active editing (even when blank), then that can lead to a situation that bothers some users: The text pops in and out while tabbing through them.

But overall I do like this idea. I mostly just want your thoughts on when it is shown and then we’d need to do some more mockups in different situations. Note that one way to remove some problems is to add more visual cues to help differentiate. There could be a change of color, not just opacity. They could be drawn with a different width, weight, stroke width, or even slant.

I quite like this. William also proposed this during the 2.8 work, but I can’t find it. It might be nice to dig it up in case there was any work toward it, or comments or concerns. This might seem like a no-brainer, but there are some gotchas. Having these can create redundancy when the label and placeholder match, which can lead to the temptation to remove labels. Removing labels can cause strain on short-term memory. Basically the one thing that they are actively interacting with does not show the text unless they move away from it or empty it. Placeholders also fill up the content more in a way that makes it harder to notice empty fields. Conversely it also makes it harder to notice non-empty fields. Although we would have control over which inputs have placeholders, I think once we started there would be a pull to have them on everything. They can give extra visual weight to items that are meant to be optional and used infrequently. An example is how prominent “Search Properties” looks in the example above. When shown within a larger blender window that text could look like a title because of the placement and our current design. Note that your tabs proposal would eliminate this problem since it adds a titled area above. The placeholder text cannot be super dim, as that would cause issues with users with eyesight impairment. But it also can’t have such contrast that the placeholder can be confused with content text. This is a delicate balance. I’d need to see samples with both dark and light themes. It is possible that a simple opacity change might not be enough in all cases because of our different perception of light highlights verses dark. We’d also want to consider these versus disabled text fields which might look similar. The biggest question for me is what happens when a user tabs into, or clicks on, an empty field. Many implementations, including css ::placeholder, continue to show the placeholder text while actively editing (showing the text caret) if there are no characters entered. And will show the placeholder again if you delete the last character. When the contrast is sufficient for eyesight-impaired users it can lead to the situation where some users can be confused about whether they need to manually remove the text. This issue is usually more associated with users with some cognitive impairment. Although this applies to us less, I still like having a good accessibility score. If the placeholder text is not ever shown during active editing (even when blank), then that can lead to a situation that bothers some users: The text pops in and out while tabbing through them. But overall I do like this idea. I mostly just want your thoughts on when it is shown and then we’d need to do some more mockups in different situations. Note that one way to remove some problems is to add more visual cues to help differentiate. There could be a change of color, not just opacity. They could be drawn with a different width, weight, stroke width, or even slant.

👍 5

Greg Zaal commented

2023-08-24 09:39:14 +02:00

One convention I've seen around is italicized placeholders. This helps differentiate between placeholders and real text in a disabled/greyed-out field.

👍 5

Harley Acheson was assigned by Pablo Vazquez

2023-08-29 19:17:02 +02:00

Matt commented

2023-08-30 17:29:42 +02:00

Yeah, this is great

Harley Acheson referenced this issue

2023-09-07 21:12:31 +02:00

UI: Input Placeholders #112104

Harley Acheson commented

2023-11-10 18:34:26 +01:00

Closing. Implemented with #112104