Highlighting active area (design task) #68830

New Issue

Campbell Barton · 2019-08-19T16:42:13+02:00

Campbell Barton commented

2019-08-19 16:42:13 +02:00

This design tasks was created in response to D5047: UI: Dim Text Editor Caret and Selections When Inactive.

Currently the active area isn't always as obvious as it could be, while the header changes color, little else changes.

Some possible solutions:

Increase the header contrast.

Some headers are transparent, so adjusting menu background or similar might be needed instead.
Highlight the border around the area.
Change the background color of the area.

In some cases this wont work well, for text-editor, Python-console or outliner it could work, for image or 3D view, we can't always do this.
Change the color of the content (highlight gizmos, cursor, change selection color... etc),

D5047 does this for the text editor.

Relies on there being a selection to see the change, may cause flicker effect since Blender users sloppy focus.

This design tasks was created in response to [D5047: UI: Dim Text Editor Caret and Selections When Inactive](https://archive.blender.org/developer/D5047). ---- Currently the active area isn't always as obvious as it could be, while the header changes color, little else changes. Some possible solutions: - Increase the header contrast. *Some headers are transparent, so adjusting menu background or similar might be needed instead.* - Highlight the border around the area. - Change the background color of the area. *In some cases this wont work well, for text-editor, Python-console or outliner it could work, for image or 3D view, we can't always do this.* - Change the color of the content (highlight gizmos, cursor, change selection color... etc), ``` D5047 does this for the text editor. ``` *Relies on there being a selection to see the change, may cause flicker effect since Blender users sloppy focus.*

William Reynish was assigned by Campbell Barton

2019-08-19 16:42:13 +02:00

Campbell Barton commented

2019-08-19 16:42:13 +02:00

Added subscriber: @ideasman42

Harley Acheson commented

2019-08-19 17:45:59 +02:00

Added subscriber: @Harley

Harley Acheson commented

2019-08-19 17:45:59 +02:00

As far as I have seen this would require a combination of things as there are two distinct parts to this.

First there is the need to indicate to the user that the active area has changed, and therefore the input focus has changed. The major problem when addressing this in particular is that the change of area focus is generally something directed by the user. If you are just moving your mouse from area to area then you are doing a deliberate action and don't need to highlight the change much, if at all. But if the change of focus happens accidentally, like moving the mouse out of an area while entering text then that highlight needs to be stronger because it then serves as warning.

For how to highlight change of focus we have limited options. A change of background color is possible for most areas but not 3D view for many cases. Similarly, changes to the header background doesn't work when we now have some with transparent backgrounds. This mostly leaves a change to the borders. But I have not been able to find an amount of change that is obvious enough when you need it but not annoying when you don't.

The second part is something we've always had missing: It is the indication of the currently active area. This seems the same as above, but is not. Even if we can indicate change in focus nicely, viewing the program at any instant in time you could not tell which area is currently active without moving your mouse about and noting the changes. This is because those changes have to be subtle, but subtle changes are hard to detect without seeing the transition.

My gut feeling is that this requires one big change and one subtle one. I think the Change Editor Menu needs to show an obvious change when in the active area. That menu is the closest we have to a Title. So the background of that button icon could gain our "active" color or the border of it could change, or perhaps the icon color. But something to indicate "this is now active" in an obvious and localized way.

And also have a very subtle change to the area border as well, but small enough to not be annoying. Since the border (obviously) encloses the area content it would serve to illustrate the extent of the change indicated by the Change Menu highlight.

However, even with both things done I personally would still deal with the text editors as a special case by dimming the text input caret. There really is only ever one place to input text at a time so that caret is disabled when the area is no longer active. It could be removed when the area does not have focus, but there is sometimes utility in knowing its position so dimming it should be enough to just indicate a disabled state.

As far as I have seen this would require a *combination* of things as there are two distinct parts to this. First there is the need to indicate to the user that the active area has *changed*, and therefore the input focus has changed. The major problem when addressing this in particular is that the change of area focus is generally something directed by the user. If you are just moving your mouse from area to area then you are doing a deliberate action and don't need to highlight the change much, if at all. But if the change of focus happens *accidentally*, like moving the mouse out of an area while entering text then that highlight needs to be stronger because it then serves as warning. For how to highlight change of focus we have limited options. A change of background color is possible for most areas but not 3D view for many cases. Similarly, changes to the header background doesn't work when we now have some with transparent backgrounds. This mostly leaves a change to the borders. But I have not been able to find an amount of change that is obvious enough when you need it but not annoying when you don't. The second part is something we've always had missing: It is the indication of the **currently** active area. This seems the same as above, but is not. Even if we can indicate change in focus nicely, viewing the program at any instant in time you could not tell which area is currently active without moving your mouse about and noting the changes. This is because those changes have to be subtle, but subtle changes are hard to detect without seeing the transition. My gut feeling is that this requires one big change and one subtle one. I think the Change Editor Menu needs to show an obvious change when in the active area. That menu is the closest we have to a Title. So the background of that button icon could gain our "active" color or the border of it could change, or perhaps the icon color. But something to indicate "this is now active" in an obvious and localized way. And also have a very subtle change to the area border as well, but small enough to not be annoying. Since the border (obviously) encloses the area content it would serve to illustrate the *extent* of the change indicated by the Change Menu highlight. However, even with both things done I personally would still deal with the text editors as a special case by dimming the text input caret. There really is only ever one place to input text at a time so that caret is disabled when the area is no longer active. It could be removed when the area does not have focus, but there is sometimes utility in knowing its position so dimming it should be enough to just indicate a disabled state.

Harley Acheson commented

2019-08-19 19:32:48 +02:00

One (very old) suggestion that might work for better showing the currently active area is to treat the "Editor Change" menu more like a Title when that area is not active. This is generally seen as just a pretty hover-activation effect of that element, but it would do a good job of indicating Active editor in a way that is both obvious and not annoying.

One (very old) suggestion that might work for better showing the currently active area is to treat the "Editor Change" menu more like a **Title** when that area is not active. This is generally seen as just a pretty hover-activation effect of that element, but it would do a good job of indicating Active editor in a way that is both obvious and not annoying. ![ActiveArea.png](https://archive.blender.org/developer/F7673566/ActiveArea.png)

Chris Kohl commented

2020-05-23 12:26:39 +02:00

Added subscriber: @ckohl_art

Vladislav Macíček commented

2021-08-20 20:24:55 +02:00

Added subscriber: @Aeraglyx

Vladislav Macíček commented

2021-08-22 00:01:12 +02:00

Hello, I made a RCS proposal for this - https://blender.community/c/rightclickselect/089X/
There could to be multiple pros about having an outline around the whole active area.

And since we already have area-joining, part of the job could already be done.

The current darkening of inactive headers complicates theming. Any thoughts?

Hello, I made a RCS proposal for this - https://blender.community/c/rightclickselect/089X/ There could to be multiple pros about having an outline around the whole active area. ![Untitled Project_Untitled Project_blender_XKyx3k_2021-08-20_17.29.49.png](https://archive.blender.org/developer/F10300889/Untitled_Project_Untitled_Project_blender_XKyx3k_2021-08-20_17.29.49.png) And since we already have area-joining, part of the job could already be done. ![blender_PxRj6dyWu3.png](https://archive.blender.org/developer/F10300891/blender_PxRj6dyWu3.png) The current darkening of inactive headers complicates theming. Any thoughts?

Harley Acheson commented

2021-08-22 20:03:30 +02:00

@Aeraglyx - And since we already have area-joining, part of the job could already be done.

It is pretty easy to highlight an area this way, so that isn't the core of this problem.

Instead it is more about how do we highlight the active area in a way that is as obvious as we need it to be, yet does not drive us crazy with things flashing as we move our mice around. I don't think we've (yet) seen a proposal or mockup that wasn't either very distracting or when not distracting it did not do anything noticeable.

The current darkening of inactive headers complicates theming. Any thoughts?

Yes, I have always disliked that the only header that draws in the color that we set in the theme is the active one, with all others darkened an arbitrary amount. At the very least I would prefer that we just lighten the active one, which is closer to what we do with other interface elements. This one is just a bit backwards.

> @Aeraglyx - And since we already have area-joining, part of the job could already be done. It is pretty easy to highlight an area this way, so that isn't the core of this problem. Instead it is more about how do we highlight the active area in a way that is as obvious as we need it to be, yet does not drive us crazy with things flashing as we move our mice around. I don't think we've (yet) seen a proposal or mockup that wasn't either very distracting or when not distracting it did not do anything noticeable. > The current darkening of inactive headers complicates theming. Any thoughts? Yes, I have always disliked that the only header that draws in the color that we set in the theme is the active one, with all others darkened an arbitrary amount. At the very least I would prefer that we just lighten the active one, which is closer to what we do with other interface elements. This one is just a bit backwards.

Gerard Taulats Braos commented

2021-08-23 12:11:25 +02:00

Added subscriber: @Tabra

Gerard Taulats Braos commented

2021-08-23 12:11:25 +02:00

Hello, I think another option could be to change the border thickness and roundness of the active area. This would make it stick out, while gaining a few extra pixels to work with, and also it would tackle a bit the annoyance of resizing panels:

What I did for to image was to set the line width to Thick, remove the active's padding and roundness, and add some color at the now square border.
As is, imo I would use a thickness of 4 pixels (in the image 7) and the radius corners to 6 (in the image 9) to make it less disturbing but thick enough to have contrast, and by having thicker borders by default we could resize the areas with less hassle.

To not have all the UI move around as it does currently when changing the line width between Thin and Thick, the borders would be drawn over, like the corners does now. This way, all the screen would be drawn by areas' interfaces, and ontop of it the borders (each area would have some UI padding to not make it crammed). By doing so, between the active area and another inactive, the separation would be of 3 pixels (1 colored and 2 default), and of 4 pixels between 2 inactive.

I made it quite specific, but of course feel free to do what you see fit/convinient.
Btw, all of this changes would ideally be customized by the user, even if it's currently hardcoded.

Hello, I think another option could be to change the border thickness and roundness of the active area. This would make it stick out, while gaining a few extra pixels to work with, and also it would tackle a bit the annoyance of resizing panels: ![Example active.png](https://archive.blender.org/developer/F10310510/Example_active.png) What I did for to image was to set the line width to Thick, remove the active's padding and roundness, and add some color at the now square border. As is, imo I would use a thickness of 4 pixels (in the image 7) and the radius corners to 6 (in the image 9) to make it less disturbing but thick enough to have contrast, and by having thicker borders by default we could resize the areas with less hassle. To not have all the UI move around as it does currently when changing the line width between Thin and Thick, the borders would be drawn over, like the corners does now. This way, all the screen would be drawn by areas' interfaces, and ontop of it the borders (each area would have some UI padding to not make it crammed). By doing so, between the active area and another inactive, the separation would be of 3 pixels (1 colored and 2 default), and of 4 pixels between 2 inactive. I made it quite specific, but of course feel free to do what you see fit/convinient. Btw, all of this changes would ideally be customized by the user, even if it's currently hardcoded.

Vladislav Macíček commented

2021-08-23 17:26:06 +02:00

@Harley I think it could be done tastefully by using some reasonable color + transition. But I see your point - thanks for the reply.
I tried to make an interactive mockup - https://codepen.io/Aeraglyx/pen/yLXLYjX
I put the border on the inside, it looked better.

Desktop 2021.08.23 - 17.20.34.02.mp4

@Harley I think it could be done tastefully by using some reasonable color + transition. But I see your point - thanks for the reply. I tried to make an interactive mockup - https://codepen.io/Aeraglyx/pen/yLXLYjX I put the border on the inside, it looked better. [Desktop 2021.08.23 - 17.20.34.02.mp4](https://archive.blender.org/developer/F10312808/Desktop_2021.08.23_-_17.20.34.02.mp4)

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Highlighting active area (design task) #68830