[Bf-committers] Patch [#36028] New 4-column layout for the editor-type-selector menu...

[David Jeske]

The current editor-type menu flipping is a byproduct of Blender trying to
solve a tricky problem in UI design, which is allowing header-menu-bars to
live on the top or the bottom. I think Blender's flipping menus work
acceptably for text-header-menus, because a particular menu type is
accessed from only one direction. (aka, the user probably buts all 3dview
headers on the bottom of 3dviews).

However, the window-editor-type-menu is often and repeatedly used from both
orientations. This flipping ruins consistency. It not only makes it harder
for new users to recognize it as the same thing (because it's upside-down),
but it hurts experienced users by ruining their ability to build muscle
memory for the menu.

The multi-column layout is objectively a better solution to the two
competing goals. Items can be kept in a consistent position, making the
menu easier to recognize, learn, and use. Frequently used operations can be
kept close to the start-point by keeping the menu vertically short, making
those operations fast to reach from either orientation. It is simply a
better solution to the problem.

it is dramatically easier to remember where things are in *larger* modifier
and constraint menus, because they have a non-flipping multi-column layout.

------

Which brings us back to "preferences" ....

There is no question there are many possible groupings, headers, and
motivations for those groupings. In fact, if the small amount of feedback
I've seen so far is any indication, 50 blender users designed multi-column
layouts, we would probably see 50 different solutions. I'd like to respond
to this with three main points.

1) *ANY* non-flipping multi-column layout is better than the current
solution as long as it keeps commonly used items close to the start-point.
Objectively, -mathematically- it achieves the two optimization goals
better. It works better for UI design. It works better for humans trying to
find things. It's just better.

2) Because different users have different preferences about where things
should be in this menu, user-preferences don't help us converge on a single
layout. My model for resolving this "abundance of preferences" is to try to
use a mix of utility and logical structure.

@Brecht - The proposed "WTAS" grouping does have logic behind it, but I'm
not at all saying it's the best. The main goal was trying to determine
which views in blender could be "standalone programs in their own right"
and put those into the workspaces section...Blender is useful for a heck of
alot more than the 3dview, but that functionality is dizzyingly hard to
find because those "top level program views" are mixed among views like
"properties" and "graph editor".

I'd love to hear some more detailed feedback about grouping structure and
headings, either here, or on the bf-funboard thread...

Here is an easier-to-view review of the better groupings I've tried so far..

   http://dj1.willowmail.com/~jeske/Projects/Blender/ETS.html