Is there any research to show that the primary/secondary menu style is more usable than application menus?

[bvz]

I won’t lie, I absolutely hate the “hamburger” menu use on desktops. But I am not here to cause a ruckus. Our organization is starting to code up a number of tools for internal use (we use Gnome on our Linux machines) and we have to decide whether to write these as GTK applications or switch to QT (there are many many different factors in making this decision - not just menus).

While looking into this it occurred to us that one consequence of making this decision is that we might have to decide whether we wanted to include application menus or use the Gnome style hamburger menu.

As part of making this decision, we are wondering if there is some research somewhere that shows what advantages this primary/secondary menu style has over a traditional application menu. At first blush, it appears to be much less discoverable and offers a much smaller target to hit and then navigate. But perhaps there is something we are missing.

If it turns out we want to use a regular application menu, is it still possible to code this within a standard GTK application? I am not really a developer so not completely familiar with the ins and outs of the different toolkits, but I am responsible for designing the functionality of the tools. (Also, are GTK apps portable to other operating systems? - specifically MacOS?)

Thanks for any and all help!

[andyholmes]

@bvz

As part of making this decision, we are wondering if there is some research somewhere that shows what advantages this primary/secondary menu style has over a traditional application menu.

I can’t speak to this question directly, but I think it should be said that this is part of a larger UX paradigm, rather than just “cram the existing menu bar into a hamburger menu”. Briefly, this means making commonly used actions more prominent, while putting uncommon functions in the “hamburger” menu (or elsewhere).

GEdit is a decent example of this done properly. It has open, new and save in the headerbar, while others have been moved to the “hamburger” menu. Other functions that could be in a menu bar dropdown but act more like context switchers, like the “currently open documents” list or file browser, are sidebar panes.

If it turns out we want to use a regular application menu, is it still possible to code this within a standard GTK application?

Of course.

(Also, are GTK apps portable to other operating systems? - specifically MacOS?)

Your mileage may vary, but that is the intention, and there are developers in the GNOME community who write such applications.

[bvz]

andyholmes:

Thanks for the feedback. While it still is not a paradigm I like at all, your explanation makes some sense.

It looks like menu styles and OS portability will not be an impediment for our projects using GTK then. I am not the final arbiter of which toolkit we use, but it is good to know that we still have options.

Thanks.

[j_arun_mani]

Hi
I think you got a better explanation for “why”. In my personal opinion, I find hamburger menu to be awesome compared to sticking menu to application, is that it gives control to the developers of application. Linux itself has a lot of desktop environments and as a developer, it will be really troublesome to test how how the menu is rendered in each of the environment.

Similarly, the idea is put the extra common functionalities into a menu and very frequent actions as widgets in top-bar (like in GEdit). This will prevent bloating the UI and give users a distraction-free working environment.

[bvz]

I don’t want to turn this into an X is better than Y discussion. So I will start by saying I respect your opinion on the subject, though I disagree.

I find the hamburger menu to be confusing, less discoverable, harder to hit (Fitt’s law), and doesn’t scale well past the simplest applications. Some research bears this out (https://www.nngroup.com/articles/hamburger-menus/).

The issue is especially galling when it comes to having some apps use traditional menus (think content creation applications) and some that don’t (glorified applets like music players or simple text editors). The former cannot have their functionality hidden in a hamburger menu because there simply is too much of this functionality to do so (and would really harm discoverability). The latter then no longer conform to the former, and you now have two disparate paradigms on how to interact with an application.

As an example, let’s think about two text editing applications that are popular on Linux systems: Libre Office and Gedit.

How do you copy text in Libre Office? You select the “Edit -> Copy” menu option. It is, of course, not the only way to copy, but it is the first discoverable way to do so, and consistent with nearly every other application up until now.

How do you copy text in Gedit? Unless you are versed in keyboard shortcuts or are familiar with the right mouse click, there is no discoverable way to do so. Essentially you have broken the laws of discoverability and consistency between applications (in addition to breaking Fitt’s law).

This is a trivial example, but it starts to highlight how we are moving away from established conventions and back to the days of every application designing its own UI (and some of the costs that entails).

What are the benefits of the hamburger menu? It does reduce clutter on the screen. It may reduce the overall UI height in some cases (though that falls away very quickly with app complexity).

In my estimation, these minor benefits are outweighed by the disadvantages.

But I want to be clear. I totally respect your preference for the hamburger menu. I’m not an expert in user interfaces. I am personally annoyed by hamburger menus, but can appreciate that not everyone has the same opinion. I just wished that more apps were like Firefox and allowed us to re-enable traditional menus.

[j_arun_mani]

I totally agree with you. Hamburger menus are not an easy thing for users who isn’t familiar with shortcuts. Well if that’s the case, we still have the popular header-menu. Since both the menu-models depend on the same Gio.MenuModel converting from one to another is not a big hassle.

The main motive of any application and also GNOME Human Interface Guidelines is to make an app that welcomes newbies, encourages amateurs, supports professionals. So no matter if we use hamburger menu or header-menu, as long as our users are happy, we are happy.