Library Overrides - UI & UX #53501

New Issue

Bastien Montagne · 2017-12-07T15:21:58+01:00

Bastien Montagne commented

2017-12-07 15:21:58 +01:00

This task is about how to present static override in our UI.

Current Situation

Creating overrides

So far, you can create an override from active object or group in 3DView, using the search menu.

UI: ID Template

You can also use the ID templates of the data-blocks.

Now we stick to a single button, when data is directly linked, clicking on it will make a local copy, while shift-clicking on it will make a static override.

When data is a static override, icon is the DATA_OVERRIDE one, and clicking on the button will make it a fully boring local data-block.

Editing overrides

{F1331522, layout=right, float, size=full}

In picture to the right: Location is overridden, Rotation and Scale are overridable but not overridden, everything else is not overridable.

Once you have created a local override of a linked data-block, that override data-block will show its properties either greyed-out (as when linked, meaning you cannot override them), normally shaded (meaning you can edit them, but currently they are not overridden), and in a new style-defined color (meaning that property is overridden from source linked data).

This is similar to the animated/driven coloring system. Note that animated/driven have priority over overridden status, since they effectively cancel any static override (animation and drivers can be seen as a specific case of dynamic override ;) ).

User can control overriding of properties from the RMB-menu, again in a similar way as animations/drivers are controlled.

TODOs

So far there is no feedback about overriding in Outliner, this we'll most likely want to add at some point. Not sure how high priority it is though.

Overrides creation

We'll want a replacement for the 'make proxy' button (that will take care of overriding sub-data as needed, and remapping pointers too).

Icon

Right now just added a dummy one inspired from the 'linked datablock' one, {F1441508, inline, size=full}, but it should be possible to find a better one (also, that one might be too close to the classical 'download' down-arrow icon?).

Open Questions

Mostly to the #user_interface team: do you think current system for user feedback (the coloring of whole prop) is good? Or do you see some crucial missing feature, or bad design, or…

E.g. maybe a single colored bar or frame would be better than full color of the widget, that would e.g. allow to display overridden and animated status at the same time - would this be really needed?

Also, do we want to convey somehow in UI the type of overriding (replacing, differential, etc.), or are we fine with having those info only in the RMB-menu?

This task is about how to present static override in our UI. Current Situation **** ## Creating overrides So far, you can create an override from active object or group in 3DView, using the search menu. ### UI: ID Template You can also use the ID templates of the data-blocks. Now we stick to a single button, when data is directly linked, clicking on it will make a local copy, while shift-clicking on it will make a static override. When data is a static override, icon is the DATA_OVERRIDE one, and clicking on the button will make it a fully boring local data-block. ## Editing overrides {[F1331522](https://archive.blender.org/developer/F1331522/Capture_d_écran_de_2017-12-07_15-05-56.png), layout=right, float, size=full} *In picture to the right: Location is overridden, Rotation and Scale are overridable but not overridden, everything else is not overridable.* Once you have created a local override of a linked data-block, that override data-block will show its properties either greyed-out (as when linked, meaning you cannot override them), normally shaded (meaning you can edit them, but currently they are not overridden), and in a new style-defined color (meaning that property is overridden from source linked data). This is similar to the animated/driven coloring system. Note that animated/driven have priority over overridden status, since they effectively cancel any static override (animation and drivers can be seen as a specific case of dynamic override ;) ). User can control overriding of properties from the RMB-menu, again in a similar way as animations/drivers are controlled. TODOs **** So far there is no feedback about overriding in Outliner, this we'll most likely want to add at some point. Not sure how high priority it is though. ## Overrides creation We'll want a replacement for the 'make proxy' button (that will take care of overriding sub-data as needed, and remapping pointers too). ## Icon Right now just added a dummy one inspired from the 'linked datablock' one, {[F1441508](https://archive.blender.org/developer/F1441508/image.png), inline, size=full}, but it should be possible to find a better one (also, that one might be too close to the classical 'download' down-arrow icon?). Open Questions **** Mostly to the #user_interface team: do you think current system for user feedback (the coloring of whole prop) is good? Or do you see some crucial missing feature, or bad design, or… E.g. maybe a single colored bar or frame would be better than full color of the widget, that would e.g. allow to display overridden and animated status at the same time - would this be really needed? Also, do we want to convey somehow in UI the type of overriding (replacing, differential, etc.), or are we fine with having those info only in the RMB-menu?

Bastien Montagne commented

2017-12-07 15:21:58 +01:00

Added subscriber: @mont29

Danrae Pray commented

2017-12-07 15:27:36 +01:00

Added subscriber: @spockTheGray-4

Julian Eisel commented

2017-12-07 18:01:19 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2017-12-07 18:01:19 +01:00

I'm not a fan of using colors to indicate overridden properties. It starts getting really hard to track which colors mean what: We have yellow for keyframed values, green for interpolated values, magenta for driven values, blue for multi-editing. And now we add cyan for overridden values.
We also shouldn't forget color-blind people. If we only use colors to communicate certain information, color-blind people may not be able to catch this info.
Maybe this topic should be addressed more broadly though.

Either case, if we can come up with a nice hint that doesn't depend on color as visual language, I'd prefer such.

I'm not a fan of using colors to indicate overridden properties. It starts getting really hard to track which colors mean what: We have yellow for keyframed values, green for interpolated values, magenta for driven values, blue for multi-editing. And now we add cyan for overridden values. We also shouldn't forget color-blind people. If we only use colors to communicate certain information, color-blind people may not be able to catch this info. Maybe this topic should be addressed more broadly though. Either case, if we can come up with a nice hint that doesn't depend on color as visual language, I'd prefer such.

Pablo Vazquez commented

2017-12-07 20:34:16 +01:00

Added subscriber: @pablovazquez

Pablo Vazquez commented

2017-12-07 20:34:16 +01:00

In #53501#474254, @JulianEisel wrote:
I'm not a fan of using colors to indicate overridden properties. It starts getting really hard to track which colors mean what: We have yellow for keyframed values, green for interpolated values, magenta for driven values, blue for multi-editing. And now we add cyan for overridden values.

Colors are easy to remember but can be hard to maintain indeed, conflict with themes, and some tints are even forbidden so eventually we'll run out.

An icon next to the label would be ideal but there are widgets that have no labels or are just too small.

Maybe a visual hint that can be applied to all kind of buttons, be it with or without text, maybe a line like Bastien suggested?
Quick hack of 2px border-bottom to visualize this example:

If multiple lines are needed, it could be split in two or three colors, etc. Or color the line 90% its width with the 'winning' status color, then at the end of the line a bit of color of the other statuses. Main problem being it's not ideal for small widgets such as checkboxes.

We also shouldn't forget color-blind people. If we only use colors to communicate certain information, color-blind people may not be able to catch this info.

Having it be a line it would make the widget stand out from others, even when not possible to see which color exactly. Also playing with contrast or patterns could solve this.

Still, I think we shouldn't try to put all info in there visually (like the type of override). It might be a bit too much. Just hinting that there's something going on in this widget should be enough, then in the tooltip and contextual menu we can say more.

Maybe this topic should be addressed more broadly though.

Yes, I didn't mean to go too much offtopic in this thread but it's related to add yet one more widget status so maybe it's a good place to talk about it.

> In #53501#474254, @JulianEisel wrote: > I'm not a fan of using colors to indicate overridden properties. It starts getting really hard to track which colors mean what: We have yellow for keyframed values, green for interpolated values, magenta for driven values, blue for multi-editing. And now we add cyan for overridden values. Colors are easy to remember but can be hard to maintain indeed, conflict with themes, and some tints are even forbidden so eventually we'll run out. An icon next to the label would be ideal but there are widgets that have no labels or are just too small. Maybe a visual hint that can be applied to all kind of buttons, be it with or without text, maybe a line like Bastien suggested? Quick hack of 2px border-bottom to visualize this example: ![Screenshot from 2017-12-07 20-05-53.png](https://archive.blender.org/developer/F1333717/Screenshot_from_2017-12-07_20-05-53.png) If multiple lines are needed, it could be split in two or three colors, etc. Or color the line 90% its width with the 'winning' status color, then at the end of the line a bit of color of the other statuses. Main problem being it's not ideal for small widgets such as checkboxes. > We also shouldn't forget color-blind people. If we only use colors to communicate certain information, color-blind people may not be able to catch this info. Having it be a line it would make the widget stand out from others, even when not possible to see which color exactly. Also playing with contrast or patterns could solve this. ![image.png](https://archive.blender.org/developer/F1333736/image.png) Still, I think we shouldn't try to put all info in there visually (like the type of override). It might be a bit too much. Just hinting that there's something going on in this widget should be enough, then in the tooltip and contextual menu we can say more. > Maybe this topic should be addressed more broadly though. Yes, I didn't mean to go too much offtopic in this thread but it's related to add yet one more widget status so maybe it's a good place to talk about it.

Dalai Felinto commented

2017-12-08 12:27:20 +01:00

Added subscriber: @dfelinto

Dalai Felinto commented

2017-12-08 12:27:20 +01:00

"Also, do we want to convey somehow in UI the type of overriding (replacing, differential, etc.), or are we fine with having those info only in the RMB-menu?

Can you elaborate on which type of overriding is (or will be) supported? And do you see editing or an override that is not a replace override?

Also, how does one have different "versions" of the same linked lib each one with a different static override? This is still possible, right?

> "Also, do we want to convey somehow in UI the type of overriding (replacing, differential, etc.), or are we fine with having those info only in the RMB-menu? Can you elaborate on which type of overriding is (or will be) supported? And do you see editing or an override that is not a replace override? Also, how does one have different "versions" of the same linked lib each one with a different static override? This is still possible, right?

Bastien Montagne commented

2017-12-08 12:38:20 +01:00

@venomgfx @JulianEisel oki, will switch to underline then… It also has the benefit that we could reuse it with another color in future e.g. if we add a more general dynamic override system, etc.

@dfelinto we already have differential static override (add/subtract, and multiply). And in the future, we could also have boolean operations on bool values, maybe also bitwise ones for enumflags, etc. Not to mention TODOs to add/move/remove items from collections (thinking especially about modifiers and constraints stacks here).

However, I do agree type of override operation is better kept in menu, user typically won't have to fiddle with it that much…

Also, how does one have different "versions" of the same linked lib each one with a different static override? This is still possible, right?

I do not understand that question really… each 'version' will be its own local data-block, with its own overrides of linked source, so it does not have anything to do with this task? And yes of course, this is still possible, this is a core benefit of this feature! ;)

@venomgfx @JulianEisel oki, will switch to underline then… It also has the benefit that we could reuse it with another color in future e.g. if we add a more general dynamic override system, etc. @dfelinto we already have differential static override (add/subtract, and multiply). And in the future, we could also have boolean operations on bool values, maybe also bitwise ones for enumflags, etc. Not to mention TODOs to add/move/remove items from collections (thinking especially about modifiers and constraints stacks here). However, I do agree type of override operation is better kept in menu, user typically won't have to fiddle with it that much… ------- > Also, how does one have different "versions" of the same linked lib each one with a different static override? This is still possible, right? I do not understand that question really… each 'version' will be its own local data-block, with its own overrides of linked source, so it does not have anything to do with this task? And yes of course, this is still possible, this is a core benefit of this feature! ;)

Dalai Felinto commented

2017-12-08 13:34:17 +01:00

Just to summarize what @mont29 and I talked over IRC:
(1) The thin lines over fill colors may be fantastic and all, but better to keep as a separate design task.
(2) It's important to show in the design proposal the process of creating the override in the datablock itself. Is it going to be a RMB option? An icon besides the 'make local' button in the datablock template?

Just to summarize what @mont29 and I talked over IRC: (1) The thin lines over fill colors may be fantastic and all, but better to keep as a separate design task. (2) It's important to show in the design proposal the process of creating the override in the datablock itself. Is it going to be a RMB option? An icon besides the 'make local' button in the datablock template?

Duarte Farrajota Ramos commented

2018-12-11 21:08:01 +01:00

Added subscriber: @DuarteRamos

Julian Eisel changed title from ~~Static Override - UI & UX~~ to Library Overrides - UI & UX

2020-06-26 19:16:49 +02:00

RedMser commented

2020-07-10 18:21:11 +02:00

Added subscriber: @RedMser

Bastien Montagne commented

2020-08-28 15:42:39 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Bastien Montagne closed this issue

2020-08-28 15:42:39 +02:00

Bastien Montagne self-assigned this 2020-08-28 15:42:39 +02:00

Bastien Montagne commented

2020-08-28 15:42:39 +02:00

Think this can be closed actually, nothing in discussion/being worked on currently here.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Library Overrides - UI & UX #53501

Creating overrides

UI: ID Template

Editing overrides

Overrides creation

Icon