| ▲ | marginalia_nu 4 days ago |
| I assume they're referring to Gnome. Despite primarily being aimed at desktop users, it's got hamburger menus everywhere[1], and a design that constantly makes trade-offs that benefit a touch-screen at the expense of keyboard-and-mouse users. [1] Hamburger menus are designed to make efficient use of a small vertical display where horizontal screen space is a limited commodity, which just is not the case at all for a large horizontal computer monitor. On a large horizontal display, they're a straight downgrade since you need to click the menu to see what's inside it, which makes action discovery harder. This click is also added to a lot of actions so they add more friction to almost all interactions. |
|
| ▲ | everdrive 4 days ago | parent | next [-] |
| >and a design that constantly makes trade-offs that benefit a touch-screen at the expense of keyboard-and-mouse users. And this is true despite the fact that a vanishingly small number of users actually use a touchscreen with gnome. |
|
| ▲ | foresto 4 days ago | parent | prev | next [-] |
| They also look like a gripper widget: a small square that can be dragged around in order to move the item on which it appears, commonly used for for positioning toolbars or re-ordering list items. Because of this, they have added a bit of confusion to user interface conventions. |
| |
| ▲ | marginalia_nu 4 days ago | parent | next [-] | | Modern monochrome line-art icons are an entirely separate trainwreck to be honest. They're incredibly difficult to parse and distinguish. It very much feels like we've fallen into the same trap medieval handwriting did
https://en.wikipedia.org/wiki/Minim_(palaeography)#/media/Fi... -- building designs around what looks aesthetically uniform and cool rather than what is easy to parse and use. | | |
| ▲ | hulitu 4 days ago | parent | next [-] | | > They're incredibly difficult to parse and distinguish And the fact that they are changed every couple of years, doesn't help either. | |
| ▲ | seec 3 days ago | parent | prev [-] | | Indeed. It's all fashion nowadays. It's a form of aestheticism which I believe is closely linked to religiousness.
There is a lot to develop but you can already observe than a lot of people have an approach to technology that isn't too far from the approach to "god" related things. |
| |
| ▲ | marginalia_nu 2 days ago | parent | prev [-] | | Just noticed Reddit uses an oddly placed hamburger menu icon to signify the action of clossing the navigation sidebar. https://imgur.com/ZjBZhE1 |
|
|
| ▲ | niam 4 days ago | parent | prev | next [-] |
| I must admit I don't understand this critique. I barely use a pointing device at all to navigate Gnome—mice included. Supposing I did, the only hamburger menus I can think of contain lesser-important functions of each app, like seeing the version/build number, or certain settings. I'm not sure I want something like a "See hidden files" ticker occupying screen real estate forever when I could just set it once in an accessory menu. I question whether these critiques would evaporate if, instead of the three horizontal bars, Gnome instead used a gear icon or something, and turned their contents into a pop-up window rather than a popover element. |
| |
| ▲ | marginalia_nu 4 days ago | parent | next [-] | | Traditionally you'd put that in a menu still, just a horizontal one that displays the top version of the hierarchy. This allows you to skip one click, and doesn't significantly eat into the ample screen space. Perhaps the biggest problem with the hamburger menu is that there is absolutely zero convention for what you put in there, or in which order. You don't know what you'll find in the menu unless you click it. With the old top menu, there were a set of conventions for this; roughly where specific options went, and in which order, and even which hotkeys you'd press to activate the menus. This means that even in an application you were completely unfamiliar with (even hideously complex ones such as an IDE or 3d modelling software), you could fairly easily navigate the application. | | |
| ▲ | tadfisher 4 days ago | parent [-] | | I like the hamburger menus, because they are usually one-level deep and contain very few items. I cannot tell you how many times I want to go into an app's settings, and it takes longer than 20 seconds; some have it in File, some in Edit, others in random menus like "Tools". Further still, the damned menu item itself could be named Settings, Preferences, Options, whatever. Even further, looking at Gimp here, Preferences is one of 25 menu items that I need to scan through. This is not good UX, this is Stockholm Syndrome. Contrast with Gnome apps: Hamburger -> Preferences, invariably, never takes longer than three seconds to find it. | | |
| ▲ | pndy 4 days ago | parent [-] | | Hamburger menu is a good solution for simple and small desktop apps but it's not a good choice to use it for anything complex. There's this Pinta image editor that since its initial release offered standard menus - for years it looked nearly identical to Paint.NET on which is partially based. In January devs switched to GTK4/libadwaita; new 3.0 release replaced menus with combined hamburger menu which of course cannot be decoupled in any way and which make advanced editing annoying. There's more clicking to do anything unless you decide to learn all shortcuts. And this "learn shortcuts" is quite common answer to hamburger menu complains. | | |
| ▲ | tadfisher 4 days ago | parent | next [-] | | I just installed Pinta to check it out. That implementation is just bad, you are not supposed to just migrate your menu bar into submenus under the hamburger menu. If I were to assist with their design, I would eliminate everything that already has a headerbar icon or an on-screen affordance; so most of Files, Edit, View, and Layers is taken care of. The stuff that remains: - Quit: superfluous, not present in Gnome apps - View: borrow the Ephiphany (gnome-web) zoom controls, move Grid, Show/Hide, and Ruler units into a preferences dialog - Add-ins: Move to a preferences dialog - Window is useless, they have tabs - Help can stay So no surprise that the laziest implementation of a hamburger menu is not good. | | |
| ▲ | pndy 4 days ago | parent [-] | | It's kinda funny how Pinta changed while Paint.NET remains same with just minor tweaks to the interface. Luckily devs there never considered utilizing ribbon interface... In the end I swapped from Pinta to Gimp and Krita because I couldn't stand that interface | | |
| ▲ | dminik 3 days ago | parent [-] | | Tbh, at this point I would pay for paint.NET on Linux. Pinta is interesting, but the UI is terrible. Did we really have to remove the resize handles? They're there when adding shapes, but not when manipulating pixels/selection? Half the options I need being hidden in a hamburger menu isn't great either. Gimp is gimp. I don't need Photoshop. And I don't want a Photoshop level of a learning curve. Krita is interesting, but it seems to be aimed at drawing. I struggled to copy the color code from an image. By default my eyes are drawn to the massive advanced color selector on the right, but it's a trap. You actually need the tiny color selector in the top bar. It shouldn't be this hard. I need a subset of image manipulation features in my work and each tool has a different one. |
|
| |
| ▲ | dismalaf 4 days ago | parent | prev [-] | | While Pinta uses (and abuses) GTK4, it has nothing to do with Gnome. Inkscape is also a GTK app that follows Gnome guidelines, and every menu and tool is out in the open. No "hamburger" menus anywhere. | | |
| ▲ | dminik 3 days ago | parent [-] | | I was under the impression that Inkscape explicitly doesn't follow the gnome guidelines. That's why every few months, there's a proposal to redesign it which trades usability for minimalism. Here's one I pulled from a random Google search: https://gitlab.com/inkscape/ux/-/issues/236 | | |
|
|
|
| |
| ▲ | Delk 4 days ago | parent | prev [-] | | > Supposing I did, the only hamburger menus I can think of contain lesser-important functions of each app gEdit places almost everything in the hamburger menu; opening and saving files have dedicated buttons but for example find/replace is behind the burger, as is "save as". It may not matter much if you use keyboard shortcuts (ctrl+f is pretty common for find and I never try to look for it in the menu) but one might still expect a GUI to allow its features to be easily accessed without the use of a keyboard. I don't think the mix of a few dedicated buttons and a single hamburger menu is necessarily good for discoverability either. The Image Viewer puts file management and image rotating in the hamburger menu. Oddly enough, other image editing options are available in a separate editing mode that's accessed via its own dedicated button. Also, although file management features are behind the hamburger menu, for some reason image properties are behind a dedicated button. In both cases the only reason the hamburger menus aren't more populated is because there just isn't that much functionality in either app to begin with. Evince (the document viewer) also puts almost everything in the hamburger menu -- although in that case, if a traditional menu bar were used instead of the hamburger, most of its functions would probably only be split between "file" and "view" menus or something along those lines. I'm not sure if those apps are still Gnome defaults but they're some of the examples of what I'd consider somewhat poorly considered use of the hamburger menu. Outside of Gnome, the new UI in JetBrains IDEs has switched to hiding typical menu bar menus behind a hamburger menu button. I honestly don't understand that decision at all: the menus are still the same, they just require an additional click to access, and since the selection of available menus is only revealed after clicking the button, you can only start scanning for the menu you're looking for after the reveal. While separate from free software desktop design, the new UI in those IDEs is another example of what I would also consider mobile-influenced degradation of desktop UIs -- and a particularly weird one at that. |
|
|
| ▲ | fluidcruft 4 days ago | parent | prev | next [-] |
| Hamburger menus are also useful for things that otherwise would be behind a right-click. I personally have not encountered a good replacement for right-click in touch UIs. |
| |
| ▲ | marginalia_nu 4 days ago | parent | next [-] | | That's rarely how they are used though, much more often they're used to replace the horizontal top menu bar. | | |
| ▲ | tadfisher 4 days ago | parent | next [-] | | They are for rarely-used actions. The corollary is that frequently-used actions are surfaced directly in the header bar instead of buried in menus. This is almost universally good. I say "almost" because content creation applications have so many actions that a menu bar sometimes makes sense; I'm thinking in particular of Inkscape with three sides of the window occupied by icons and a bizarre hamburger icon in the bottom of the right panel for some reason. | |
| ▲ | fluidcruft 4 days ago | parent | prev [-] | | I don't disagree, but I think that's another reason they exist beyond screen real estate on mobile. Context menus take no screen space, but they don't play nice with touch. | | |
| ▲ | marginalia_nu 4 days ago | parent [-] | | There are plenty of alternative paradigms on touch interfaces, both two finger tap (on capable devices) as well as side-swipe are used to bring up menus that are as contextful (or more) than the burger menu. | | |
| ▲ | blooalien 4 days ago | parent [-] | | "Long-tap" (tap and hold for a second) is another right-click alternative I've seen used to great effect on touch interfaces. | | |
| ▲ | fluidcruft 3 days ago | parent [-] | | It works sometimes but it seems like drag me and it's really awkward when something can/should be both dragged or right clicked. |
|
|
|
| |
| ▲ | naasking 4 days ago | parent | prev | next [-] | | Touch and hold is fine as a right click. | | |
| ▲ | ahartmetz 4 days ago | parent [-] | | But it barely exists anymore. It was common in early Android, not anymore. I think the reason was bad discoverability... which is true. But not having the functionality is worse. | | |
| |
| ▲ | 3 days ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | vitorgrs 3 days ago | parent | prev [-] |
| KDE changed their design to include hamburger menu. Even KDE's Terminal have a "hamburger" menu. |