Static Override - UI & UX
Open, NormalPublic

Description

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

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,

, 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?

Details

Type
Design
Bastien Montagne (mont29) triaged this task as Normal priority.
Bastien Montagne (mont29) updated the task description. (Show Details)
Bastien Montagne (mont29) updated the task description. (Show Details)

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.

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.

"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?

@Pablo Vazquez (venomgfx) @Julian Eisel (Severin) 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.

@Dalai Felinto (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! ;)

Just to summarize what @Bastien Montagne (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?