Since there is some debate already in some blog’s comments about where the menu button should be placed, I think this should be debated in a constructive way on this subforum.

Some people seem to be genuinely frustrated by its position on the right side of the screen.

Let’s kick the debate off with a small analysis – please understand that I’m not a usability expert, just a die-hard user:

Menu on the right side

Pro:

• concept familiarised through certain well known browsers (Chrome, Firefox)
• works well with flat menus (see Firefox 30 or above)
• works well also with menus with several degrees of hiarchy in right-to-left languages (e.g. arabic script)

Contra

• unnatural to use with hiearchy-based menus in left-to-right languages (see Rekonq)
• change is always harder to adapt to

Menu on the left side

Pro:

• concept familiar from pretty much the start of computer GUIs
• works well with flat menus (see Firefox 30 or above)
• works well also with menus with several degrees of hiarchy in left-to-right languages (e.g. latin, cyrilic script)

Contra:

• unnatural to use with hiearchy-based menus in right-to-left languages (?) (someone who uses RTL should comment on this)

"I'm against menus on the right"
I find the new firefox thing horrible, btw. It's so much harder to find the right button in a bunch of tiles than in a list. I should make a test application for that which proves it *g

The only pro point I see is that it's better for RTL languages. I don't use a RTL language and I think that making a change which is better for RTL, but worse for LTR doesn't make much sense. If it bothers the RTL people, there should be a framework which switches the side at which the menu appears based on the language.

Greetings!

scummos wrote:"I'm against menus on the right"
I find the new firefox thing horrible, btw. It's so much harder to find the right button in a bunch of tiles than in a list. I should make a test application for that which proves it *g

The only pro point I see is that it's better for RTL languages. I don't use a RTL language and I think that making a change which is better for RTL, but worse for LTR doesn't make much sense. If it bothers the RTL people, there should be a framework which switches the side at which the menu appears based on the language.

Personally I agree with you completely. Although I find the flat menu in Firefox less annoying than the hiearchical in Rekonq.

I tried to keep the first post as neutral as possible, so we actually have a ballanced debate here, instead of starting the thread with a personal position.

Left is the preferred place to start functions or to navigate the right-hand content (in LTR languages). The menu button (we should find a better name for this pattern, e.g 'options button') was rather designed to tweak something, to select an option, or to have configurations, as defined by the HIG for simple applications.

First of all, thank you hook for kicking off this interesting and long-overdue discussion!

Heiko Tietze wrote:Left is the preferred place to start functions or to navigate the right-hand content (in LTR languages). The menu button (we should find a better name for this pattern, e.g 'options button') was rather designed to tweak something, to select an option, or to have configurations, as defined by the HIG for simple applications.

I fully agree! The point is:
Placing the menu button on the right for LTR languages means that it is considered a secondary UI element. If designers places a menu button on the right-hand side, it is because they don't want users to noticed it right away, but only if they're actively looking for it.
I couldn't find the official rationale behind Google's placing the menu button on the right side in Chrome with a quick search, but I bet it goes along the lines of "We wanted to focus the user's attention on the important UI elements, so they only use the menu button if they cannot find what they are looking for in the toolbar."

If a designer thinks the menu button on their application should be placed on the left so users will easily find it because they need it often, then that indicates that toolbar + menu button is the wrong pattern for that application. That pattern only works if all frequently accessed functions can be placed elsewhere and the menu is only for rarely used functions like settings. If there are so many frequently used functions that some of them have to go into the button menu, a menu bar should be used instead, period.

The Firefox Australis UI solves this by letting users decide which functions they use frequently, infrequently or not at all, and put them in the right places accordingly. For users who use more functions regularly than fit into the toolbar, it gives the option to show the menu bar again. Mozilla does a lot of user testing and gathers a lot of feedback from the Aurora and Beta users and did so doubly for the Australis UI (see the Mozilla User Advocacy Blog for example), so what ended up in the release was not random.

scummos wrote:"I'm against menus on the right"
I find the new firefox thing horrible, btw. It's so much harder to find the right button in a bunch of tiles than in a list. I should make a test application for that which proves it *g

I'm pretty sure that finding an option whose name you know well in a list is indeed quicker than finding it in a grid (I'm certain there is a ton of research on that, but I haven't found the right keywords to bring it up yet). The fact that this is bothering you, however, shows that you are not using Firefox' menu button in the way it was intended by its designers: As stated above, it is intended for rarely used functions, whose name you therefore may not easily remember. For those, a big icon can help guide your search. That positive effect diminishes compared to the negative effect of the grid the more often you use a function. So, yes, for functions you use often enough to easily remember their name (but not often enough to remember their position on the grid), it takes you longer to find them in a grid than in a list.
If you use them so often that this added effort becomes noticeable, though, that means they should probably go in the toolbar, not in the menu. And again, if there are too many regularly used functions than fit on the toolbar, you're probably better served by a menu bar.

scummos wrote:The only pro point I see is that it's better for RTL languages. I don't use a RTL language and I think that making a change which is better for RTL, but worse for LTR doesn't make much sense. If it bothers the RTL people, there should be a framework which switches the side at which the menu appears based on the language.

Yes, I definitely agree with you here (although if we really wanted to optimize UIs for RTL languages, much more would have to be changed than just the position of the menu button).

hook wrote:[*] unnatural to use with hiearchy-based menus in left-to-right languages (see Rekonq)

If a menu is so complex that it needs a hierarchy (maybe even with more then two levels), then a menu button is most likely the wrong pattern. Mozilla has understood this and solved it in the Australis UI by letting users put only the functions they actually need in that menu. Chromium's menu is quite simple, but has a second level below some items, which isn't optimal.

Conclusion:
The negative connotation of menu buttons on the right comes from a mental model of menu buttons created by the first attempts at them from the likes of Google and Mozilla: Just taking the full application menu and cramming it into a button, which sadly was copied by many KDE applications like Dolphin or Rekonq.

Yes, those menu buttons were better placed on the left because they were a primary UI element. However, those menu buttons should not even have existed in the first place, as they make navigation more complex compared to a menu bar instead of simpler. That's what both Google and Mozilla have learned by now, and have now redefined the menu button as a secondary UI element which is supposed to only hold rarely used functions and therefore should not jump into the user's face when scanning the UI.

And this is how the menu (or options) button was meant in the music player. If it contains any frequently used functions, then we've done something wrong and those should be moved into the main UI.

I hope my reasoning has become clear and I could help people re-think he purpose of those menu buttons.

colomar wrote:I fully agree! The point is:
Placing the menu button on the right for LTR languages means that it is considered a secondary UI element. If designers places a menu button on the right-hand side, it is because they don't want users to noticed it right away, but only if they're actively looking for it.
I couldn't find the official rationale behind Google's placing the menu button on the right side in Chrome with a quick search, but I bet it goes along the lines of "We wanted to focus the user's attention on the important UI elements, so they only use the menu button if they cannot find what they are looking for in the toolbar."

If a designer thinks the menu button on their application should be placed on the left so users will easily find it because they need it often, then that indicates that toolbar + menu button is the wrong pattern for that application. That pattern only works if all frequently accessed functions can be placed elsewhere and the menu is only for rarely used functions like settings. If there are so many frequently used functions that some of them have to go into the button menu, a menu bar should be used instead, period.

The Firefox Australis UI solves this by letting users decide which functions they use frequently, infrequently or not at all, and put them in the right places accordingly. For users who use more functions regularly than fit into the toolbar, it gives the option to show the menu bar again. Mozilla does a lot of user testing and gathers a lot of feedback from the Aurora and Beta users and did so doubly for the Australis UI (see the Mozilla User Advocacy Blog for example), so what ended up in the release was not random.

I agree. It's about primary and secondary (and tertiary) functions.
Primary functions should be available directly on the primary interface - that is toolbar buttons, sidebars, etc. For browsers this is the navigation bar and associated buttons, the web page view and the tabs.
Secondary (and tertiary) functions should be accessible via menus. The distinction between secondary and tertiary being how accessible the given menu is, and is evident in Firefox's Australis UI: There is a menu button which allows you to access semi-frequently used Secondary functions; You also have access to bring up the menubar to access the full range of functionality - most of which are rarely-used Tertiary functions. For many applications, there isn't need to have a distinction and it is sufficient to just have a toolbar and/or sidebar for primary functionality and a menubar for secondary functionality.

colomar wrote:

scummos wrote:"I'm against menus on the right"
I find the new firefox thing horrible, btw. It's so much harder to find the right button in a bunch of tiles than in a list. I should make a test application for that which proves it *g

I'm pretty sure that finding an option whose name you know well in a list is indeed quicker than finding it in a grid (I'm certain there is a ton of research on that, but I haven't found the right keywords to bring it up yet). The fact that this is bothering you, however, shows that you are not using Firefox' menu button in the way it was intended by its designers: As stated above, it is intended for rarely used functions, whose name you therefore may not easily remember. For those, a big icon can help guide your search. That positive effect diminishes compared to the negative effect of the grid the more often you use a function. So, yes, for functions you use often enough to easily remember their name (but not often enough to remember their position on the grid), it takes you longer to find them in a grid than in a list.
If you use them so often that this added effort becomes noticeable, though, that means they should probably go in the toolbar, not in the menu. And again, if there are too many regularly used functions than fit on the toolbar, you're probably better served by a menu bar.

I'd suggest it depends on the person as to whether a list or a grid works better.
Some people remember and can identify things easier by name and prefer a list (possibly with a search feature).
Some people remember and can identify things easier by image or icon. They may have a slight preference for a compact grid that is easier to single out the icon they are looking for, but they can operate equally well given a list so long as there are icons they can use.
Some people (like myself) remember and can identify things easier by position, and may prefer a grid because it makes memorizing the positions easier.

One caveat to using a grid is that it requires (usually larger more distinguishable) icons, while a list can be used with just the names or when some of the items lack icons.

colomar wrote:
If a menu is so complex that it needs a hierarchy (maybe even with more then two levels), then a menu button is most likely the wrong pattern. Mozilla has understood this and solved it in the Australis UI by letting users put only the functions they actually need in that menu. Chromium's menu is quite simple, but has a second level below some items, which isn't optimal.

Conclusion:
The negative connotation of menu buttons on the right comes from a mental model of menu buttons created by the first attempts at them from the likes of Google and Mozilla: Just taking the full application menu and cramming it into a button, which sadly was copied by many KDE applications like Dolphin or Rekonq.

Yes, those menu buttons were better placed on the left because they were a primary UI element. However, those menu buttons should not even have existed in the first place, as they make navigation more complex compared to a menu bar instead of simpler. That's what both Google and Mozilla have learned by now, and have now redefined the menu button as a secondary UI element which is supposed to only hold rarely used functions and therefore should not jump into the user's face when scanning the UI.

And this is how the menu (or options) button was meant in the music player. If it contains any frequently used functions, then we've done something wrong and those should be moved into the main UI.

I hope my reasoning has become clear and I could help people re-think he purpose of those menu buttons.

I agree that we should re-think the purpose of the menu buttons. I would advocate that in general having a menu button should be avoided and just use the standard menu (with toolbar and/or sidebar; and if the user wants to reclaim that vertical screen real estate they can use the standard features for exporting the menu to the titlebar (button)), and that a menu button only ever be used for secondary functionality where there are sufficiently many functions to have a distinction between primary, secondary and tertiary functionality such that a quick-menu with secondary functionality can be justified. Even then it would primarily be a means of cleaning up the interface by exporting less-commonly used features from the direct interface, that we want to be easier to access than searching the exhaustive menubar menus; and it shall only be a relatively short list of items (which may be user-configurable). Otherwise just go with the standard menubar (with toolbar and/or sidebar). In this case, I would argue for putting such a quick-menu on the right side of the interface - out-of-the-way compared to the primary functionality, but still easy-to-find when its functions are desired.

Excellent, clear and detailed assessment and conclusion colomar. There are likely several elements of what you've shared that could be additionally helpful in the layout guidelines for command patterns.

It also coincides with the importance of understanding the complexity of the command structure of the application and choosing the most appropriate command pattern to expose those commands in the application layout design. There is no one size fits all.

airdrik wrote:I agree that we should re-think the purpose of the menu buttons. I would advocate that in general having a menu button should be avoided and just use the standard menu (with toolbar and/or sidebar...

We arrived at the decision to have a layout for simple applications with menu buttons (https://techbase.kde.org/Projects/Usabi ... ndPatterns and viewtopic.php?f=285&t=122173). Standard menus and toolbars are preserved for complex apps.