Page MenuHome

Make enum menus nicer
Open, Needs Information from UserPublic

Description

Enum menus in Blender have a few issues:

  • Title is at the bottom
  • Selected item is redundantly duplicated both inside the menu and outside
  • It's not easy to see which item is the active one when the menu is open

We can solve this by changing the way we display enum menus.

  • Rather than popping up or down, they can pop outwards from the selected item
  • Add a checkmark to the currently selected item
  • Put title text always on top

Like so:

This only applies to enum menus, not popovers or regular dropdown menus.

Details

Type
To Do

Related Objects

Event Timeline

I still prefer the current universal standard way of opening this menus. I can open and close the menus just by clicking, without having to move the mouse away to dismiss the popup, unlike this new method (I can see this becoming very annoying when you're searching for something in those menus)..

I hope this can be made optional, otherwise most people may think this is a bug.

@Regnas (Regnas) I don't know if you've used enum menus like this in other apps. This is a standard way to do it.

With this design, you can indeed just open it and release, and it will fall back to the last selected item if you don't wish to change it.

I don't understand what you mean about it being a bug.

Here's a screen recording for reference, for users who have never seen standard enum menus:

@Regnas (Regnas) Just checked a few random apps. They all work this way. So I don't know what you mean re. 'standard universal way' considering that this seems to be quite standard.

I guess you're on a different operating system. This is not how it works on Windows, which is the most popular Operating System.

Few examples:

Substance Painter

Keyshot

Photoshop

Cinema 4D

After effects

Marmoset Toolbag

Opera Browser

This very own website 🙂

I personally don't think this task is an improvement, so please make it optional or platform specific if possible.

Here's what I see:

Anyway, this task solves the issue of the title being at the bottom, and has the other advantages mentioned too, even if Microsoft Windows does its own thing.

Luckily, we don't particularly follow UI standards of Microsoft Windows , which doesn't even have very well defined UI patterns to begin with. See for example the fact the Blender doesn't have a Start menu, nor does it use the Ribbon, or blue screens when it fails.

Instead, our UI is cross-platform, and we try to use the best ideas to make the nicest UI we can.

This is operating system specific, and that would be the best way to implement such feature, or at least an option in the preferences.

I used some apps with this behavior before and it always felt like a bug. The menu is all over the place, changing position to display the last selected etc...
Not efficient at all.

@Regnas (Regnas): There's nothing less efficient about this - on the contrary, it's faster to move up and down to the next item in the list. With the Windows method, you have to start from the top of the list every time it's opened.

Again, our UI is shared across OS's, and isn't designed to follow Windows UI guidelines specifically.

For muscle memory it can help to always have a particular item at the same distance, so that you can move there without reading the labels. If that distance is different every time it can be less efficient as you reorient yourself, even if the distance is shorter. Not sure how much difference this makes in practice.

Please don't.
Maybe as an option in the preferences to satisfy the Mac users.

Please, let's not forget which OS the majority of blender users use, before applying such radical change. 👍

I like my menus always in the same place and not covering the button, just like it is now.
So yeah, optional please.

The goal is obviously not to 'satisfy Mac users'. We don't use Mac-style menu bars and other things like that either.

Instead, the goal is to solve the issue of the title being at the bottom currently.
Also, this way of doing enum menus has a number of advantages: They are faster to navigate and clearer too.

Given that these type of menus also exist in some Windows apps, I think that Windows users can figure out how to use these menus too.

  • This wont work well for enums at top/bottom window bounds:


    This is an issue in the default layout for:
    • top-bar orientation w/ transform tool.
    • outliner display modes
    • render window view/slots/channels.

      Of course it can be worked around, it just adds a small penalty to doing something that currently has none.

      Most likely the workarounds involve clamping the menu or switching to different behavior - which will feel like workarounds (from a user perspective), making the UI more awkward by default.
  • Adding a check mark means we will need a check-mark and an icon? (for icon only buttons we want to be able to see the icons too).

    Having two columns for icons may look a bit odd too.
  • Assume this isn't expected to be used for multi-column enums, are there other cases this wont be used?

General note, this is more a design task than a paper-cut.

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Needs Information from User.Mar 12 2019, 1:14 AM

@Campbell Barton (campbellbarton) Just like we do for other menus, they should be offset when you reach the edge, so menus never exceed the edge of the window.

William Reynish (billreynish) raised the priority of this task from Needs Information from User to Normal.Mar 12 2019, 12:36 PM

@William Reynish (billreynish) OK but this will be a awkward for situations where it's always clamping to window bounds with enum buttons on headers.

Design proposals should not only describe the "happy path", they should also describe drawbacks and intended behavior in those cases:

For eg, with header enums is this what your suggesting?

BeforeAfter

Currently if you click twice, it opens then closes the enum. With this new behavior the outcome of clicking twice depends on the previously selected item and the location of the button relative to the window bounds. Is this intended too, or can a design be made which has a more predictable outcome?

@William Reynish (billreynish)

On all your screenshots shows native macOS pop-up menu, and it works well and is familiar to users. Although pull-down menu are also used depending on the context.

Since Blender has menus in each editor, popovers, data-block menus... (which opens down), it is likely that enum menus should open downwards as well.
Title is at the bottom. In the vast majority of cases, this title is not needed at all, since there is a label next to the button. The active item should be just grayed out.

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Needs Information from User.EditedApr 19 2019, 1:02 PM

Issues raised here T62309#638681 should be addressed by design, making as incomplete.

We could either:

  • A: Only do this if there is space
  • B: Simply offset the menu there isn't enough space
  • C: Accept that it can go off screen and show arrows inside the menus just like we do in the pulldown menus when they are out of bounds.

Personally I think you should separate the problems with the current design from the visual differences between Mac and PC.

You mentioned two specific things.

The title at the bottom does look dumb. I think it could be simply removed, no matter where it is. You click on this menu element to change a setting; you know what it is before you click on it.

They don’t show the already selected option. True, but I think we should indicate that with a colour change for the background of that item. Check marks for us are problematic since items can start with icons. But that is possible too if we just slide the content to the right to make room.

I just think we can address the major issues without having to change the direction and position of the menu.

Yes, it’s true, we can solve some of the issues without changing the direction in which the menu opens.

But if we want to keep the header text, the ‘open outwards’ concept works better.

It’s also, IMO, just nicer in general. Currently, if you have a long list of options, the way menus work now means you have to always start at the very top every time you open it. With this proposal you always start from the last selected item.

I might take back my earlier comment about using color or sliding the content to the right.

Enum menus don't have submenus, so we could just use the space on the right to indicate which is currently selected:

@Harley Acheson (harley): That could be a nice little improvement, although why put it on the right? Seems like it might be slightly easier to read on the left, next to the text.

...although why put it on the right? Seems like it might be slightly easier to read on the left, next to the text.

Could go on either side really. I'm not overly concerned either way, but do prefer it on the right in this case. Possibly because the indication of current selection is a little less important. It is good information to know but it is quite optional as it does not really inform the new choice. If anything the current selection is less important than the others, so needs indication but not extra weight.

Here are the two ideas side-by-side. Again, both work, but I find the left a bit neater, cleaner, quicker to read what is important. But I don't care too much.

@Harley Acheson (harley) it's funny because I find the one on the right clearly easier to see. With the left one, it's a bit hard to see at a glance which item was the selected one.

In any case, both of these would be a slight improvement I think.

I agree that having enum items jump positions depending on which one is currently active does not seem desireable (what Brecht says), but I have no experience using this, am only judging from the captures provided above. An indicator however would be most welcome, either in the form of a checkmark or a dot at the rightmost edge of selected enum item, or a different background color.