Proposed Changes to Tooltips #82115

New Issue

Harley Acheson · 2020-10-26T21:26:04+01:00

Harley Acheson commented

2020-10-26 21:26:04 +01:00

I am proposing a number of changes to our popup tooltips. Generally the thought is to make them less big and heavy, and reduce redundancy. This document is in progress.

Appearance

Reduced padding. The current tooltips include very large internal padding. I would like to reduce this to a minimal amount:

Reduced line-height. The spacing between lines can also be reduced to lower the total footprint:

Vertical offset. Currently the tooltips are shown just below the mouse position (by an amount that is not changed with interface scale), but too closely. Especially with gizmo tooltips the mouse cursor can be in the way.

Horizontal offset. The left corner is attempted to be moved to the left of the mouse position (by an amount that is not changed with interface scale). But this is a constant amount so looks odd with short tooltips. Instead that amount should be a maximum and we can center the tooltip when short.

Section gaps. Currently many types of information in the tooltip will cause a 1/3 line-height extra gap. This generally just looks like random line spacing since most tips like this are only three lines. In the following, the last line does not look separated from the rest, but instead each line just has different spacing:

No resizing with local zoom. Right now the tooltips increase in size with local zooming. But we don't otherwise make larger tips for larger content, so doing this just looks odd. All the tips should follow global scale, but not local zoom. Following shows the interface scale at 1.0 but with cartoon-sized tooltips because of the local zoom level:

Python separation. When Python tooltips are enabled we should separate that section out a bit more than we are doing now.

Reduce Colors. The tooltips currently use 5 different colors and shades of text. This doesn't help readability and I think this should be reduced greatly.

Base region enlargement on ShadowWidth, not UI_POPUP_MARGIN. It is possible to wreck the shadows of tooltips if they are made to be wider than UI_POPUP_MARGIN. Better to base this on the actual width of shadows.

Content

Font-width of calculation of text with suffix should include “: “. Right now the width calculation of the text does not include the ": " between text and a suffix, therefore giving a result that is too short.

Suffix with “: “, not “: “ - Text with suffix is separated with two spaces after a colon, but typographically should be a single space.

Don’t show “Value: ” unless the text is overflowing. There is no reason to show the value of a text input, since we can see exactly what we've entered. Unless the text is truncated, then it has value. So at point of truncations (and adding ellipsis) we could flag the but as truncated and only show value in this case. The following, at the top, shows display of the input's value despite being displayed. Bottom shows removing this line:

Don’t show label for button unless really not shown AND no but_tip. The first line of many tooltips looks like a funny duplication because some buttons will show both name and description. We can eliminate this redundancy by improving the test if the label is visible and only show if there isn't also a description. Following makes now changes except for this, so no "Scale. Scaling of the Object", or "Location. Location of the Object", etc:

At an extreme we could get to something like the following. The top shows the current tooltip, with three lines featuring two redundancies. The bottom shows it reduced to a single line:

I am proposing a number of changes to our popup tooltips. Generally the thought is to make them less big and heavy, and reduce redundancy. **This document is in progress**. **Appearance** Reduced padding. The current tooltips include very large internal padding. I would like to reduce this to a minimal amount: ![padding.png](https://archive.blender.org/developer/F9102287/padding.png) Reduced line-height. The spacing between lines can also be reduced to lower the total footprint: ![linespacing.png](https://archive.blender.org/developer/F9102292/linespacing.png) Vertical offset. Currently the tooltips are shown just below the mouse position (by an amount that is not changed with interface scale), but too closely. Especially with gizmo tooltips the mouse cursor can be in the way. Horizontal offset. The left corner is attempted to be moved to the left of the mouse position (by an amount that is not changed with interface scale). But this is a constant amount so looks odd with short tooltips. Instead that amount should be a maximum and we can center the tooltip when short. Section gaps. Currently many types of information in the tooltip will cause a 1/3 line-height extra gap. This generally just looks like random line spacing since most tips like this are only three lines. In the following, the last line does not look separated from the rest, but instead each line just has different spacing: ![gaps.png](https://archive.blender.org/developer/F9102326/gaps.png) No resizing with local zoom. Right now the tooltips increase in size with local zooming. But we don't otherwise make larger tips for larger content, so doing this just looks odd. All the tips should follow global scale, but not local zoom. Following shows the interface scale at 1.0 but with cartoon-sized tooltips because of the local zoom level: ![localzoom.png](https://archive.blender.org/developer/F9102390/localzoom.png) Python separation. When Python tooltips are enabled we should separate that section out a bit more than we are doing now. Reduce Colors. The tooltips currently use 5 different colors and shades of text. This doesn't help readability and I think this should be reduced greatly. Base region enlargement on ShadowWidth, not UI_POPUP_MARGIN. It is possible to wreck the shadows of tooltips if they are made to be wider than UI_POPUP_MARGIN. Better to base this on the actual width of shadows. **Content** Font-width of calculation of text with suffix should include “: “. Right now the width calculation of the text does not include the ": " between text and a suffix, therefore giving a result that is too short. Suffix with “: “, not “: “ - Text with suffix is separated with two spaces after a colon, but typographically should be a single space. Don’t show “Value: ” unless the text is overflowing. There is no reason to show the value of a text input, since we can see exactly what we've entered. Unless the text is truncated, then it has value. So at point of truncations (and adding ellipsis) we could flag the but as truncated and only show value in this case. The following, at the top, shows display of the input's value despite being displayed. Bottom shows removing this line: ![value.png](https://archive.blender.org/developer/F9103214/value.png) Don’t show label for button unless really not shown AND no but_tip. The first line of many tooltips looks like a funny duplication because some buttons will show both name and description. We can eliminate this redundancy by improving the test if the label is visible and only show if there isn't also a description. Following makes now changes except for this, so no "Scale. Scaling of the Object", or "Location. Location of the Object", etc: ![ExtraTitle.png](https://archive.blender.org/developer/F9103147/ExtraTitle.png) At an extreme we could get to something like the following. The top shows the current tooltip, with three lines featuring two redundancies. The bottom shows it reduced to a single line: ![Three2one.png](https://archive.blender.org/developer/F9103569/Three2one.png)

Harley Acheson self-assigned this 2020-10-26 21:26:04 +01:00

Harley Acheson commented

2020-10-26 21:26:04 +01:00

Added subscriber: @Harley

Torrent commented

2020-10-26 21:32:03 +01:00

Added subscriber: @torrent-1

Torrent commented

2020-10-26 21:32:04 +01:00

No resizing with local zoom

I can see people with vision problems actually needing it.
I wouldn't change that.

> No resizing with local zoom I can see people with vision problems actually needing it. I wouldn't change that.

Harley Acheson commented

2020-10-26 21:48:51 +01:00

@torrent-1 - I can see people with vision problems actually needing it. I wouldn't change that.

Those two things aren't related. The size of the Tool icons shouldn't control the size of tooltips. And consider that it doesn't change the size of tooltips in almost every other case. For example we don't allow local zoom on ANY header, menu, or popover, so the most-used tooltips cannot be enlarged this way. For the vision impaired we have two methods, increasing the interface scale will increase everything uniformly. And increasing Widget Point size increases the size of this type of text separately from interfaces scale and therefore are under the control of the user.

> @torrent-1 - I can see people with vision problems actually needing it. I wouldn't change that. Those two things aren't related. The size of the Tool icons shouldn't control the size of tooltips. And consider that it doesn't change the size of tooltips in almost every other case. For example we don't allow local zoom on ANY header, menu, or popover, so the most-used tooltips cannot be enlarged this way. For the vision impaired we have two methods, increasing the interface scale will increase everything uniformly. And increasing Widget Point size increases the size of this type of text separately from interfaces scale and therefore are under the control of the user.

Robert Guetzkow commented

2020-10-26 21:54:31 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-10-26 21:54:31 +01:00

In my humble opinion the reduced padding, line height and no section gaps are worse for readability and appearance, if the screenshots accurately represent the changes you're going for. The reduce padding and line height makes it the content look cramped into the box. The missing sections gaps make it harder to distinguish the different sections in the tooltip. While more of a point about aesthetics, I'm not sure why Python commands shouldn't be in a monospaced font. I don't see how the readability for commands is supposed to be worse than with a sans-serif font.

I'm not convinced that these visual changes are a good idea.

Edit: I'm referring to the following two concepts from the original post in this comment. Just adding them as reference in case the designs are changed/updated/refined and people are wondering what I'm talking about.

In my humble opinion the reduced padding, line height and no section gaps are worse for readability and appearance, if the screenshots accurately represent the changes you're going for. The reduce padding and line height makes it the content look cramped into the box. The missing sections gaps make it harder to distinguish the different sections in the tooltip. While more of a point about aesthetics, I'm not sure why Python commands shouldn't be in a monospaced font. I don't see how the readability for commands is supposed to be worse than with a sans-serif font. I'm not convinced that these visual changes are a good idea. Edit: I'm referring to the following two concepts from the original post in this comment. Just adding them as reference in case the designs are changed/updated/refined and people are wondering what I'm talking about. ![linespacing.png](https://archive.blender.org/developer/F9102292/linespacing.png) ![gaps.png](https://archive.blender.org/developer/F9102326/gaps.png)

Harley Acheson commented

2020-10-26 22:18:49 +01:00

@rjg - reduced padding, line height and no section gaps are worse for readability and appearance...

The model is generally the tooltip sizing, padding, etc that you would see in other applications, browsers, etc.

The missing sections gaps make it harder to distinguish the different sections in the tooltip.

This might be less of an issue when I reduce some of the redundancy of the data shown. For example, other changes here reduce this tooltip from three lines to two and therefore you don't need a section gap:

I'm not sure why Python commands shouldn't be in a monospaced font. I don't see how the readability for commands is supposed to be worse than a sans-serif font.

I have updated the original description above with some captures to compare.

> @rjg - reduced padding, line height and no section gaps are worse for readability and appearance... The model is generally the tooltip sizing, padding, etc that you would see in other applications, browsers, etc. > The missing sections gaps make it harder to distinguish the different sections in the tooltip. This might be less of an issue when I reduce some of the redundancy of the data shown. For example, other changes here reduce this tooltip from three lines to two and therefore you don't need a section gap: ![gaps2.png](https://archive.blender.org/developer/F9103331/gaps2.png) > I'm not sure why Python commands shouldn't be in a monospaced font. I don't see how the readability for commands is supposed to be worse than a sans-serif font. I have updated the original description above with some captures to compare.

Robert Guetzkow commented

2020-10-26 23:03:48 +01:00

The model is generally the tooltip sizing, padding, etc that you would see in other applications, browsers, etc.

I'm not aware of a design guideline that would be this universally applied. Perhaps you could link what you're basing this on? I got curious and tested different software, the tooltip design was far from uniform.

In my eyes there is far too little whitespace in the suggested redesign as shown in your original post. In case of a really short text, slightly reduce padding like in the "Snapping" example may work, but not when presenting multiple lines of text.

The example in your last comment starts to look more like a suitable choice. More padding, no reduced line height.

> The model is generally the tooltip sizing, padding, etc that you would see in other applications, browsers, etc. I'm not aware of a design guideline that would be this universally applied. Perhaps you could link what you're basing this on? I got curious and tested different software, the tooltip design was far from uniform. In my eyes there is far too little whitespace in the suggested redesign as shown in your original post. In case of a really short text, slightly reduce padding like in the "Snapping" example may work, but not when presenting multiple lines of text. The example in your last comment starts to look more like a suitable choice. More padding, no reduced line height.

Harley Acheson commented

2020-10-26 23:26:07 +01:00

@rjg - The example in your last comment starts to look more like a suitable choice. More padding, no reduced line height.

It is, of course, all up for debate. I started in there by correcting and improving things so that we can support paddings of any size down to zero. Once done with that I'm now seeing how we can reduce the lines, and the final padding and line spacing would change depending on how dense these things are when done. But a good exercise would be for you to take the following image and alter the bottom example to what you prefer:

> @rjg - The example in your last comment starts to look more like a suitable choice. More padding, no reduced line height. It is, of course, all up for debate. I started in there by correcting and improving things so that we can support paddings of any size down to zero. Once done with that I'm now seeing how we can reduce the lines, and the final padding and line spacing would change depending on how dense these things are when done. But a good exercise would be for you to take the following image and alter the bottom example to what you prefer: ![Three2one.png](https://archive.blender.org/developer/F9103707/Three2one.png)

Robert Guetzkow commented

2020-10-27 00:09:23 +01:00

@Harley I'm sure your code improvements are great, I was just giving my input on the visuals. If it helps and I have time next weekend, I can try to mock-up a design. It'll be fairly close to the current one though. I'd prefer vertically stacked information over longer horizontal lines. In my opinion it allows for quicker reading and provides better structure for the information. Everything on one line is indeed a bit extreme.

Harley Acheson commented

2020-10-27 02:35:14 +01:00

@rjg - I was just giving my input on the visuals

And I really appreciate it. Thanks!

> @rjg - I was just giving my input on the visuals And I really appreciate it. Thanks!

Ryan Inch commented

2020-10-28 01:33:43 +01:00

Added subscriber: @Imaginer

Ryan Inch commented

2020-10-28 01:33:43 +01:00

Sorry, but I prefer monospaced for the python code. With monospaced there is no chance of misinterpreting characters and it makes it easier to differentiate between the python and the description.

Harley Acheson commented

2020-10-28 02:13:32 +01:00

Sorry, but I prefer monospaced for the python code. With monospaced there is no chance of misinterpreting characters and it makes it easier to differentiate between the python and the description.

For sure. This is throwing everything I could find to stick to the wall. I doubt many of these ideas will gain acceptance, but hoping for enough agreement on at least a few. With the monospaced fonts they often differentiate the homoglyphs lowercase letter "O" from the number zero, normally with a dot or slash. We might be able to do that with the regular font using Unicode Variation Selector-1, but have never tried that.

> Sorry, but I prefer monospaced for the python code. With monospaced there is no chance of misinterpreting characters and it makes it easier to differentiate between the python and the description. For sure. This is throwing everything I could find to stick to the wall. I doubt many of these ideas will gain acceptance, but hoping for enough agreement on at least a few. With the monospaced fonts they often differentiate the homoglyphs lowercase letter "O" from the number zero, normally with a dot or slash. We might be able to do that with the regular font using Unicode Variation Selector-1, but have never tried that.

Ryan Inch commented

2020-10-28 02:20:09 +01:00

There's also the small "L" vs the capitol "I" thing. And I kinda like monospaced for code, plus I think everyone's used to it.

Robert Guetzkow commented

2020-11-01 23:01:30 +01:00

Let me preface this with the following: I think the current design of the tooltips is completely fine. There might be some things that could be changed, but whether or not this is considered an improvement is largely based on personal preferences.

Since @Harley has asked for some input, I've created a mock-up how the design could be changed. The biggest issue I see with the current design is the inconsistent padding and sometimes slightly odd structure. Please note that the "equal padding" is only roughly eyeballed and not accurately measured, but that can be done as well if the ideas are of interest.

With annotations

Without annotations

Let me preface this with the following: I think the current design of the tooltips is completely fine. There might be some things that could be changed, but whether or not this is considered an improvement is largely based on personal preferences. Since @Harley has asked for some input, I've created a mock-up how the design could be changed. The biggest issue I see with the current design is the inconsistent padding and sometimes slightly odd structure. Please note that the "equal padding" is only roughly eyeballed and not accurately measured, but that can be done as well if the ideas are of interest. **With annotations** ![2020-11-01-mockup_structure_8.png](https://archive.blender.org/developer/F9157423/2020-11-01-mockup_structure_8.png) **Without annotations** ![2020-11-01-mockup_structure_8_no_notes.png](https://archive.blender.org/developer/F9157432/2020-11-01-mockup_structure_8_no_notes.png)

Harley Acheson commented

2020-11-02 00:31:53 +01:00

Thanks @rjg! Your versions look much nicer than the current ones to my eye too. And good point about that "Python:" in there.

Ryan Inch commented

2020-11-02 03:11:37 +01:00

@rjg I like the padding and horizontal alignment changes. As for the structure change, I think having the blue mode underneath is slightly less clear as to what it refers to, and the smaller text may decrease accessibility, but the differentiation from the heading is nice, and so is the removal of the "Python:".

Campbell Barton commented

2020-11-02 05:50:24 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-11-02 05:50:24 +01:00

Some notes:

I'd like to keep Python using mono-spaced fonts, without this some such as . between words don't read so well, if the size is reduced it could avoid taking up so much room.

OTOH, I'd rather focus on design for the default tooltips first.

As for removing the label, this seems fine for buttons that include the label.

In other cases (icon-only buttons for example) the label should be kept as the tooltip isn't meant to repeat information already in the label.

I don't have a strong opinion on other changes in this patch, so leaving this to other members of the UI team

Some notes: - I'd like to keep Python using mono-spaced fonts, without this some such as `.` between words don't read so well, if the size is reduced it could avoid taking up so much room. ``` OTOH, I'd rather focus on design for the default tooltips first. ``` - As for removing the label, this seems fine for buttons that include the label. ``` In other cases (icon-only buttons for example) the label should be kept as the tooltip isn't meant to repeat information already in the label. ``` ----- *I don't have a strong opinion on other changes in this patch, so leaving this to other members of the UI team*

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Proposed Changes to Tooltips #82115