New modifier panel and list

[dimitar]

I understand the desire to have a consistent UI, but at what cost to the the user experience?

As far as I am aware, exposing an option without worrying about the UI and how it would handle itself is no different than laying out a website - it’s nearly automatic as long as there are good rules in place - margins, alignment, etc.

The only reason I keep bringing this up is because that current iteration of modifiers with a series of sub-tabs introduces additional clicks and significantly more vertical scrolling. Yes, allowing modifiers to be draggable is good, but for anyone that uses more than 5 or 6 modifiers, the current UI would be a significant hindrance.

One more point - in the default ui experience, the properties are below the outliner. With multiple sub-collections the outliner typically needs to be expanded wider. If the properties remains underneath, then there is significant amount of wasted real estate without grid flow.

Perhaps then what many are doing with showing suggestions of how the modifier layouts should look like with minimum extra vertical real esates and minimum number of subtabs may be useful to prevent extra scrolling and uniform ui fatigure (all options everywhere are continuing to look the same so it is becoming harder to find the right one).

Let’s also talk about the new hotkeys. One of the intentions behind 2.8 was to be able to work with less hotkeys so new users can adapt to using the app quicker. Now, the user interface is changing in a way, where the speed of doing something that could be done before without sub-tabs and without hotkeys would either require additional hotkeys (clicks), more vertical scrolling, and/or additional mouse clicks.

To continue with new users in mind. With everything sub-tabified and (in most cases) closed down (not only with modifiers but throughout properties), a new user would need to expand each individual tab, study it and figure out the necessary option. Case in point - in 2.79 i felt it was much easier to change an object’s viewport visibility from textured to wireframe. Now i need to scroll through a number of tabs, find the right one to expand, and select the option. I need to do that a lot and I am still not up to the speed of making this adjustment between 2.79 and current Blender versions.

Back to the modifiers, from a new user’s perspective, it may be more difficult to remember more closed sub-tabs that may contain the right option, than having a recognizable collective modifier UI layout (as in 2.83) and know where about in the interface is the right option.

This is starting to feel like a wider UI discussion, so veering slightly off-topic, but I feel that for a daily blender user that also teaches others, it is important to voice these UI paper-cuts, with the modifiers taking centre stage at the moment.

[RonanDucluzeau]

@dimitar

The only reason I keep bringing this up is because that current iteration of modifiers with a series of sub-tabs introduces additional clicks and significantly more vertical scrolling.

I think that is a misperception.
In 2.83, are exposed all settings of modifiers. In 2.90 alpha, are exposed only more used ones.
In 2.83, because of all settings exposed, number of displayed modifiers is generally 3 or 4.
in 2.90. because of hidden settings and removal of repeated Apply/Copy buttons line, you can display one more modifier.
So, in case of a use of 5 or 6 modifiers :
In 2.83, you are forced to close an entire modifier or to scroll distance of the entire length of a modifier to display hidden modifiers.
In 2.90, you can still close the entire modifier, or just a subpanel. Of course, scrolling an entirely opened modifier is not efficient, here. But scrolling one with closed panels or without panels at all, means less scrolling than in 2.83.

So, you have to take into account, that :

• because settings in sub-panels are not the most frequently used ; extra click to open a sub-panel is supposed to be rare.
• because most of modifiers are shorter than in 2.83 ; extra-click to close a modifier in order to display another one is less frequent.
• for same reason, scrolling is less important.

Of course, there are exceptions and counter-examples some modifiers that are longer with frequently settings in sub-panels. That is not the majority of modifiers. But some of them are very frequently used.

So, in terms of efficiency, I think that both solutions are equivalent.
What plays against 2.90 UI is that disadvantage of a long modifier is more obvious than advantage of display of more modifiers main settings.

I would like to see an Horizontal Scrolling of a Properties Editor that would organize list of properties as columns. I think that would be an improvement.
But I don’t think that 2 columns layout in panels is more efficient than what we have, now.

@dimitar

To continue with new users in mind. With everything sub-tabified and (in most cases) closed down (not only with modifiers but throughout properties), a new user would need to expand each individual tab, study it and figure out the necessary option. Case in point - in 2.79 i felt it was much easier to change an object’s viewport visibility from textured to wireframe. Now i need to scroll through a number of tabs, find the right one to expand, and select the option. I need to do that a lot and I am still not up to the speed of making this adjustment between 2.79 and current Blender versions.

A new user can now scan more easily UI made only of one column of settings.
There are more settings in 2.8. That is not a bad thing to hide options for a more advanced usage.

Anyways, new users will continue to read manual and follow tutorials and exercise.
They will not open sub-panels to test each option without understanding what they are looking for.
It does not seem to be a bad thing for me.

There are not more settings in 2.8 and 2.9 than in 2.7, just because there are sub-panels.

That is just the normal expansion of software, doing more things and needing to expose a bigger amount of properties in a cleaner way.

You remark about Viewport Display of object is not related to sub-panels but to single column layout.
There is no sub-panel in Viewport Display panel.
But clearly, its condition changed to opened by default in 2.79 to closed at bottom of list in 2.8.
People are doing movements with widgets in 3DView or tweaking f-curve Graph Editor and checking positions in Item tab of sidebar of 3D View : nobody cares about Transform panel in Properties editor.
And that sucks that is the one opened on top of list.
Clearly, people are using Object tab mainly for Viewport Display panel.
Then, for Instancing, Motion Paths and Custom Properties.
Sorry. This is off topic. But something like that would probably be a lot more popular.

But user can reorder the tab. Nobody forces you to keep defaults when they are bad.
And here, that is the case. A default UI less efficient because of a bad default.
But not really because of a bad overall design.

@dimitar

from a new user’s perspective, it may be more difficult to remember more closed sub-tabs that may contain the right option, than having a recognizable collective modifier UI layout

I repeat myself but labels of sub-panels are supposed to be meaningful.
You did not care to remember labels in 2.79 because you were remembering the position.
2.90 is just exchanging memory of position for memory of a word.
But that does not mean that you have more things to remember.
In fact, because of necessity to remember label of sub-panels, it should be easier to remember purpose of option.

[John1]

Is the Ctrl hotkey for isolating a modifier replaced with expanding all sub-panels?it doesn’t work anymore.

[HooglyBoogly]

It isolates a panel if it’s closed, toggles subpanels if it’s open. I didn’t want to make one behavior require the other.

[John1]

So is it possible to add a new hotkey to isolate not only the modifier but also a subpanel if others are opened? at least this would make it a little bit faster to work with a long list.

[HooglyBoogly]

I’d like to avoid adding a new shortcut but I’ll will if it turns about to be necessary.

One thing I thought of was checking to see if all other panels are closed first. So the first time you ctrl-clicked on an open panel it would collapse all others and then once all the others were all closed it would toggle subpanels. The downside is you can’t toggle subpanels without closing all the other panels. Hmm… maybe just using alt click for the subpanel toggling is simpler.

[ThatAsherGuy]

I’m not too keen on having both 2px and 5px row gutters in the same layout. There’s a fair chance this is partly caused by the layout rules in rna_userdef.c (I threw together a quick hack back in February that’ll let you change them on-the-fly), but it should be fixable without having to edit those application-wide rules.

[HooglyBoogly]

Right, the default spacing for items added to panels is the 5px you mentioned, but the spacing when you add a column is the 2px. I agree they don’t look great mixed together, and I think that Bevel layout is an especially unfortunate victim of that. I made a small change to remove the double 16px spacers in D8115. (Which you might be particularly interested in, it addresses some small concerns like the one you bought up).

Although I do think there are reasons to use both the 2px and the 5px spacing. The 5px is just a bit too much for a longer list of similar properties, and the 2px helps show that properties are related. However, the choice of whether to use an aligned column vs the 2px separated column in your picture is always a bit arbitrary.

[ThatAsherGuy]

I’d argue that the 5px gutter isn’t large enough to look deliberate. Having all horizontal gutters default to 2px, using explicit spacers (and, I dare say, horizontal rules) for the situations where a larger gap is needed, would help the layout feel more cohesive.

[slowk1d]

@HooglyBoogly Just tried the new branch with the shortcuts implemented, using them feels very smooth and fast, definitely a great addition! I’d like to ask if it would be possible to change the shortcut also for opening/closing the modifier, currently it happens with A but it’s not listed in the keymap.

[HooglyBoogly]

Unfortunately it’s currently hardcoded. The issue is that it’s a generic feature of panels everywhere, not just modifiers panels, so it’s wrapped up in the panel UI code. In the future that could possibly become part of the keymap somewhere, but that’s sort of a different project.

EDIT: Also, the modifier shortcuts are in master now, you shouldn’t have to use a branch.

[slowk1d]

Thanks for the info!
Yeah my bad, I meant the master.

[Bobo_The_Imp]

@HooglyBoogly Something I feel might be missing yet is some very small highlight around the modifiers when hovering over them, otherwise the hotkeys effect can feel like they come out of nowhere. Something like this:

Regardless the additions to the modifier panel make it feel very professional.

[HooglyBoogly]

Thanks. That’s interesting, good idea. I might even want something a little less prominent than that. It’s a good hint but it might feel like too much after a while if it’s too bright.

[Bobo_The_Imp]

Yes I would agree with that, I was worried that in the default theme on devtalk it might be too hard to see so I emphasized it. Nathan Craddock is working on the outliner in GSoC right now, and he has synced properties from the outliner with the properties panel. I’m hoping that in the future in the outliner you could open the modifier pulldown, select a modifier and the modifier panel will close all modifiers except the selected one, much like the ctrl+click behavior now. The highlight would just be the cherry on top for that interaction! I plan to bring it up with him, but I will wait as right now he has his hands full with the colored collection design.

[HooglyBoogly]

Agreed, that interaction would be really cool! That intersection between two projects is where it gets fun.

Although personally I think I’m a bit more interested in automatic (smooth) scrolling than collapsing all other panels. I thought it would be nice to make a function that scrolls to the panel for a particular modifier. I don’t think it would be too hard to develop as an operator. Although collapsing all the other panels would be helpful too

[Bobo_The_Imp]

Automatic Scrolling would be nice as well.

@HooglyBoogly

That intersection between two projects is where it gets fun

Absolutely, I’m not sure if this topic is something you, Nathan or both teams would handle. Regardless, if you are interested in this function, it might be a good idea to have a small chat with Nathan to see if it would fit into his GSoC project while the iron is still hot. I have a feeling it might fit in nicely.

[slowk1d]

Sorry to bother again, guess I got attached a lot to these layout changes, I hope this time it’s just a small papercut: the shortcut for applying is not shown in the header menu.

[HooglyBoogly]

I actually got a bug report about that too! Resolved now anyway.

[APEC]

Can we have some Up/Down arrow keymap to move modifier up and down in the list without drag’n’drop?
Like “Move to First/Last” have possibility to assign key (BUT I can’t assign it…Bug?).

But still I can’t understand how current active modifier is determined? Maybe it need some highlight by clicking on the name that’s why suggestion below

And please, rename by dbl click…like other objects in outliner.