Hi!
Regarding HIG recommendations, what's our take on hamburger menus?

Introduction to the topic: http://blog.manbolo.com/2014/06/30/appl ... rger-menus

I am looking in particular at https://techbase.kde.org/Projects/Usabi ... ndPatterns.
I hope the question is valid for desktop apps too. I trust over time our HIGs would provide hints for smaller form factor apps like for Plasma Active. A lot of concepts make sense universally already.

Lunch time, an you post such a question!
Seriously, the new Breeze layout makes extensively use of sidebars (context panel). What do you think we should write in the guideline? Some brainstorming: no scrollbars esp. horizontal, no hierarchy, LTR vs. RTL, don't use for navigation purpose.

Thanks, I meant more the menu button (command structure) than a panel: https://techbase.kde.org/Projects/Usabi ... _structure.

Desktop apps demonstrate at least these approaches (lame research showing different purposes or needs):
- menu with top-level, often accessed commands, usually traditionally seen in the File and Edit and View menus (includes some options too) - see Rekonq, Firefox, Chrome, IE.
- menu with entire content of in the hamburger menu:
1. in KDE it's called App Menu, and replaces menu bar entirely:


(it's KDE's global option though, see explanation and here for how to set up)
2. in Thunderbird mail client it contains entire menu with some twist: https://support.mozilla.org/en-US/kb/di ... nd-toolbar
3. In Kexi it contains entire File menu (any global commands that are usable on startup) but is placed under "Kexi" name replacing the real File menu, it's similar to MS Office 2007 in that it covers entire main window on drop down: https://www.calligra.org/wp-content/upl ... roject.png. Here, the reasoning was that "File" was no longer close, as Kexi often do not operate on Files, and we wanted to avoid putting two separate menu items: File and Session (KDevelop app does this).

I'd like to ask for more analysis and maybe more examples, brainstorming.

Completely anecdotally, but I have never been disappointed when an application has dropped the traditional File-Edit-Tools-Help menu in favour of a "hamburger" menu (Is that really the "official" name??). They make programs cleaner to look at, and seem to give developers a new push to actually think through the menu (and the rest of the interface) and which pieces fit where.

I like them, and want more of them.

Yep, explaining "do's and dont's" for the menu in the HIG would encourage app devs to consider it. I especially like richer widgets in the menu, such as zoom slider or grouped clipboard commands:

These rich widgets have different interaction property, unlike usual menu items, after clicking them, the menu does not hide itself.
Qt/KDE has all technical means to support that without hacks.

Mobile case is different story I think.

Personally, i'm not a huge fan of 'Hamburger menus' where all the menu items from the usual 'File, Edit etc' are rolled into one menu, i really don't like the ones like the Thunderbird one that you linked to where there's more than one column. I find them much slower to navigate through & find things in, than conventional menus but that's not the case with a menu like this one (where the conventional menu structure is maintained):



The only issue with that one is that one extra click is needed to show the menu in the first place. I would like a way of reinstating the conventional menu so that applications that require heavy menu use (like GIMP) aren't negatively affected.

One thing that i really do like is the way the 'Edit' & 'Zoom' buttons have got additional controls on them in this menu:

ken300 wrote:
The only issue with that one is that one extra click is needed to show the menu in the first place. I would like a way of reinstating the conventional menu so that applications that require heavy menu use (like GIMP) aren't negatively affected.

But there is no extra click. In the traditional bar you still have to click to open the menu. Here you click the hamburger menu, and then just move your mouse through the various entries. I really like this approach. Applications look cleaner, and, if the vertical layout is better for Activities, Alt-Tab, Widgets... I would assume that it would be easier to use in applications too.

In coming up with the HIG recommendations for the Menu Button pattern (and all the other command patterns), a pretty extensive application survey across multiple platforms was conducted.

The HIG has specific recommendations on when the Menu Button pattern would be acceptable and when it would not. It depends on the complexity application command structure. The definition of command structure complexities we use is in the Getting Started section under Organization: https://techbase.kde.org/Projects/Usabi ... ganization

I'll duplicate the definitions here:

• Simple - When there are relatively few globally applicable commands (~ less than 10) and command groups (~ less than 4). Use command patterns for a simple command structure. Plasmoids should use a simple command structure.
• Complex - When there are several globally applicable commands and command groups and relatively few frequently used commands (~ less than 8 ). Use command patterns for a complex command structure.
• Very complex - When there are many globally applicable commands and command groups and many frequently used commands. Use command patterns for a very complex command structure.

The Menu Button/Hamburger menu can be used for Simple and Complex command structures. However, for Very Complex command structures, a traditional menu bar is recommended. I think these recommendations are applicable for different form factors given that the command structure on smaller form factors are often relatively less complex. But it certainly makes sense for us to revisit this as new information becomes available.

Personally I have no objections to rich widgets in the menu. I quite like them too.

Hope this helps!

I don't understand the app menu as a hamburger. The pattern is rather known from the menu button in Firefox (called hamburger because of the three stacked slices). As Andrew said, our menu button opens as well a sidebar (aka context panel) which is a different way of interaction compared to menus. And those sidebars may contain advanced controls. Do we need to write a HIG for sidebars?

> Qt/KDE has all technical means to support that without hacks.

But these can not be exported via dbus menu protocol.

ivan wrote:> Qt/KDE has all technical means to support that without hacks.

But these can not be exported via dbus menu protocol.

Afaiu this is supposed to be a toolbutton in a toolbar rather than an (exported) menubar (where this would indeed not work as dbusmenu was not designed to be abused by canonical for this purpose)

As Andrew said, we have already researched and thought about this topic extensively and put the result in the Command Patterns HIG.
So there's our take.
Please, before discussing any further, read the aforementioned HIG. If you have objections against the decision criteria presented there, please go ahead and tell us, but restarting the discussion from scratch just duplicates effort that has already been invested in writing that HIG.