Page MenuHome

Remove collapsible menu headers
Closed, ResolvedPublicDESIGN

Description

How do people feel about these collapsible menu elements. It seems like the main use for them is for people that have really small screens. Does anyone actually use this though? I have not seen this type of design pattern anywhere else, so I didn't know how it originated.

The info space seems to have the most information in it, so it really only becomes useful for people with screen sizes under 1280px width (I took a screenshot and measured the width of everything in the bar).

Is it necessary for specific tasks or layouts?

Can we remove these? I can do the changes if so.

Event Timeline

I wouldn'tmiss them and I don't see a good reason to keep them either.

I don't see any harm leaving it in the right click menu, but it probably shouldn't be always visible?

For times when you add e.g. a small 3D or image view in a corner somewhere it can be useful, I see it often used in .blends that way.

I would be ok with leaving it in the right menu. Just to clarify, this would potentially be removed from all spaces, not just the info space that I highlighted.

To me it's useful just in certain case, like in Composition Layout, in the 3D view window, to select a different layer in Visible Layers. But my main interaction in this kind of situation is do middle click and grab the bar until I can see the button I want... I'm not sure if it this works well for everyone.

I see. It is partially helpful for that situation (depending on what your monitor resolution is). I can see all of the layers on my screen, but I have a 1920x1080 monitor.

I don't use the composition layout, but I would probably split the properties view on the side and go to the "Render Layers" section if you are really using the layers that much with this layout. The 3D space is hard to use to use when it is that small.

With Brecht's suggestion, you could still right click and hide the menu if you wanted. You just wouldn't be able to do it with the +/- button that is currently there. I just don't think situations like this are common enough to need to show it at all times on all spaces.

Re: right click menu, it means if a newer user opens a file with this set - they may have no way to get the file menu back unless they know to right click to show it (theres no indication that you can get the menu back as there is with an arrow icon).

There is IMHO a drawback in having the button located where it is since its so close to the first menu item (which happens to be the file menu for info space).

When teaching blender to a colleague once, the first they did was try to open a file, pressed this button by accident, then ask where their file menu went - a minor hiccup but its not so great.

I would prefer to move this button to the right hand side of the menu so its in a less prominent position, (probably change the arrow icon direction too).

I think we should remove this too.
We also dont have a button to collapse other elements i the header.

Giving the menus special treatment is odd, and the + button makes it look like it's important functionality, plus it makes all the headers longer. It also adds extra complexity and potential for error as users may accidentally click it and see their menus disappear.

Two paths remain: either remove this feature completely or move it to right click menu.

I think the simplest solution is just to remove it altogether. That way old blends will work fine.

If we're concerned about users being unable to find their menus again, we could still show the (+) icon when the menus are collapsed. Or it could even be a button that opens a menu with submenus e.g. File, Render, Window, Help, and an entry to expand the menus again.

@Brecht Van Lommel (brecht) will people accidentally "lose" their menus if the "+/-" button is completely removed (save the context menu option)? This potential confusion seems very specific to Blender. I have not seen this functionality in any other program I have come across. It doesn't seem like an intuitive system to continue.

Is there another program that exists that uses this type of system for hiding menus?

The main goal of this feature seems to be "saving space". IMHO, I just think that the space it saves is not worth the clutter and confusion it generates.

@Brecht Van Lommel (brecht) - in regards to your screenshot, would this only be visible when the menu is hidden? It looks nice, but this would also create two different workflows for showing and hiding the menus.

Would it be confusing to use a context menu to hide the menus, then have to click a button and use a different menu to enable?

To me it seems like a useful feature still, especially with the idea that at some point we should add these menus to the spacebar menu. If we do that then a power user doesn't need the menus in headers (except the info header), you would access that functionality through spacebar.

The saving space argument seems reasonable to me even on large monitors, people will subdivide the screen into multiple editors and there often just isn't enough space to fit the entire header.

If consistency of how to show/hide the menus is an issue then that "Expand Menus" can be left out of the menu. Even if users can't figure out how to expand the menus they would still be able to access them, and in my opinion right click isn't that difficult to find, especially if we consistently put such UI editing operations in right click menus.

I think we need to still leave the functionality in for advanced users, but have the +/- button removed from the header. For advanced users who really want fine tuned controls, I think it would be ok to leave it in a context click menu.

http://www.nngroup.com/articles/progressive-disclosure/

I feel the cognitive load of the +/- icon is too much for most users. Leaving it in the context menu will satisfy advanced users that really want to fine tune their interface, while making it easier to use for everyone else that doesn't need such precise control.

I will pipe down until other people chime in. :)

@Brecht Van Lommel (brecht) Great proposal! To me it seems like a much better approach I suppose that if "Expand Menus" is enabled, the menu icon changes to a "collapse" icon.Changing icon to an 3 lines icon (usual for menus currently):

And the spacebar idea sounds nice! There are doc/wiki for this?

@Brecht Van Lommel (brecht). +1 for the proposal (note this is becoming common to have a menu in a single icon - chrome, skype, gnome3).

@Brecht Van Lommel (brecht):

With that proposal, how would you minimize the menus? Still with the '-' button?

The ironic thing about the current plus/minus icons is that they take up space to remove space. I think we should find a solution where we don't need a minus button on every header.

I think the minimizing could be done via a RMB menu, and the expansion via the proposed new menu.

@Campbell Barton (campbellbarton) - great point with other interfaces that are using that system.

The proposal looks nice. I don't like having two different ways to use the same menu though. If we put the menus behind an icon, I think it would be nicer to use that pattern all of the time - not just when minimized. That would allow the menus to get as sophisticated as needed and not have to worry about taking up too much space. It would also eliminate the problem of the a +/- icon.

Would globally doing this switch be too disruptive though? It would be a little cleaner overall to always hide the menu behind an icon. I am always a fan of removing things on the screen if we can.

The main backlash I could see is if some of the menu items are heavily used. This would mean an extra click for common operations.

@Scott Petrovic (scottpetrovic)
-1 for having this on always or by default. For chrome for example it makes some sense- since for browsing the web you're not accessing the file menu a lot. But you may access select menu fairly often for some workflows. - Its one extra click so - its not horrible, but Id not advocate for having it default. If users like they can always choose to fold their menus down and save defaults.

This is great @Brecht Van Lommel (brecht)!
Also I like icon that @Paulo José Oliveira Amaro (pauloup) made, this is standard trend for menus/settings icons by now.

ok. The current proposal is better than it currently is, so I would be ok with Brecht's suggestions. I guess I am stuck on the whole "collapsible menu" idea. I just don't like that concept since it isn't used anywhere else like that (to my knowledge). Other applications seem to find solutions to avoid needing something it. "Creative" UI solutions aren't usually the most user-friendly - but I guess the only people that will have to deal with it are advanced users for the their special cases.

With this new collapsed option, users won't know about it, but will have to learn about it. There is no "information scent" any more for hiding, so we need to make sure an online resource is available to tell people how to collapse menus (some people probably don't know about the context click option).

I can try to start coding this one. It looks like it will be just some python changes and a little bit of C (removing +/- from header). I haven't seen icons for menus before, so need to do some research on best approach. Icon menus usually have been for showing enums. Maybe there is an optional argument for icon with menus?

Sounds good to me. I think the menu icon is just a matter of using layout.menu("INFO_MT_collapsed", icon='SOMETHING', text="").

cool, that is what I was thinking. Icons were done elsewhere and has an icon argument in C, but didn't know how well it was implemented with menus since I couldn't find it. I will see what I can do! thanks.

This looks really good @Brecht Van Lommel (brecht) and I totally agree with the direction everyone seems to be leaning towards.

As for the the menu icon, I believe you can also use:

icon_only = True

@Jonathan Williamson (carter2422) - the icon_only works with RNA properties, but not menus (just tested it). I can't find icon-only menus anywhere else. I have to manually add empty spaces to the menu text parameter, otherwise the icons go outside of the button and look odd.

@Scott Petrovic (scottpetrovic) that seems a bit arbitrary... is icon_only support for menus something we can add?

I am sure it is possible to add it into the code base. This feature is almost done, so adding that might be better as a new task. For now @Brecht Van Lommel (brecht) suggested putting separator() instead of the empty space. That should be ok for now.

  • moved review to patch page ---

@Jonathan Williamson (carter2422) i'm using the win64 official 62a3fe2 build and the new button/icon for collapsing the 3d view's menus isn't always visible in my custom windows layouts, when the layers buttons etc are not visible, ie to the right of the window size, so i'm having to scroll the header to the left, each time i want to access those buttons, either that or go full screen.

i personally like the new menu icon, which i also noticed was similar to chromes, but i wish it was consistent. ie if any of the ui elements of the header are hidden, then please have blender display the collapsing icon rather than display the actual menu labels which take up a lot more horizontal room on the header.

sorry guys, i just found the right click header option to collapse menus. so please ignore my previous post.

Scott Petrovic (scottpetrovic) changed the task status from Unknown Status to Resolved.Mar 29 2014, 5:15 AM