|
| ▲ | aidenn0 18 hours ago | parent | next [-] |
| Two of GNOME's recent updates have made searching menus for a rarely used item incredibly painful: 1. Replace the menubar with a hamburger menu; in some cases the hamburger menu then contains file/edit/&c. so it's just a spurious extra click 2. Require a click to see the contents of a submenu and a click to go back Fortunately my most-used GNOME application (Evolution) has an option to restore the old behavior for both of those, but I literally cannot think of the motivation for these two changes that clearly make things worse. The only halfway plausible idea I have heard for #2 is that the GNOME UX designers think that submenus are bad, so if you make them hard enough to use, developers will stop putting them in their applications. #1 is probably partly a looks thing, and partly a "too many people have fewer horizontal lines on their screens than I did in 2004[1]" thing. 1: That's when I got a 1600x1200 monitor; people today with 1080p screens have only 56 more lines than the 1280x1024 monitor I had been using since the previous millennium |
| |
| ▲ | cosmic_cheese 17 hours ago | parent [-] | | The GNOME project seems like it has a strong desire to converge all on-screen UI onto mobile-like patterns. There are some mobile conventions that can be brought over to desktop without impairing usage too much but I think that perhaps it’s starting to cross too far over to the mobile side of the line. It’s unfortunate because in other ways I find GNOME/GTK more agreeable than KDE/Qt (layout of controls within windows is consistently better in GTK environments/apps for example, Qt apps have a tendency to feel slapdash/haphazard/“engineery”) but I don’t like the increasingly strong mobile influence. |
|
|
| ▲ | mo_42 19 hours ago | parent | prev | next [-] |
| I agree. Hamburger menus aren't any better than menu bars. It seems like an example where design has more importance than function. My alternative to the menu bar would be a search bar that allowed me to search in a Google style everything related to that program: functions, features, shortcuts, and documentation. File | Edit | View | etc. is not the right choice for every program. |
| |
| ▲ | cosmic_cheese 19 hours ago | parent [-] | | This is where it’s useful for the menu bar to be system-owned rather than the responsibility of individual programs (whether that be a global bar as in macOS or attached to window decorations). That would make it easy to implement a toggle that hides menubars either globally or on a per-app basis and enable a Unity-type shortkey-summoned HUD to be used instead. |
|
|
| ▲ | mike_hearn 18 hours ago | parent | prev | next [-] |
| Hamburger menus work much better on mobile screens that are horizontally constrained, are less visually intrusive when not in use and don't require at least two levels of nesting like classical desktop menu bars do. |
| |
| ▲ | cosmic_cheese 18 hours ago | parent [-] | | Even on mobile, in most situations there are better UX choices than hamburger menus. Nearly every app using them I’ve encountered has put as little thought into navigation and UI hierarchy as possible and are awkward to get around in. They’re the ones where one has to go down a winding ever-changing maze to access the desired functionality. Most would be better served by surfacing the most commonly used screens as tabs and most commonly used functions within those tabs. Ideally 2-4 taps is all it should take to get anywhere, and there should only ever be a tiny handful of niche things that take 5+ taps to access. |
|
|
| ▲ | sombragris 18 hours ago | parent | prev [-] |
| Agreed. And the worst part is that you could use a (well designed) menubar with a keyboard by using the Alt-key combinations together with cursor key menu navigation and similar techniques. But you don't have that luxury in hamburger menus. You are forced to use a pointing device such as the mouse, or if you are lucky, a completely non-standard key combination to bring it down. Awful. |
