Fwd: Proposal: revisiting menus in Gnome

From: Greg K Nicholson <greg gkn me uk>

To: desktop-devel-list gnome org

Subject: Fwd: Proposal: revisiting menus in Gnome

Date: Mon, 10 Apr 2017 22:07:11 +0100

Hi folks, This is going to be a long one. Check you have a cup of tea before you dive in. # Summary We should improve how Gnome apps organise their menus. We should move the contents of the panel menu into the headerbar menu, where Preferences and Quit should be styled like in the Shell's system menu. The panel menu should duplicate the contents of the focused app's dash menu. Because: - Users expect those options to be inside the application window. - Independent apps don't use the panel menu, which leads to an inconsistent experience in Gnome Shell. - Other desktop environments don't have a panel menu, so Gnome apps have to reorganise their menus when used outside Gnome Shell. # About me I'm Greg K Nicholson. I've used Gnome and followed its development for 10 years. I switched to Ubuntu (6.10) from Windows XP because I wanted Gnome. I now use Fedora for the same reason. I live in Manchester, Great Britain. My day job is doing quality assurance for a web development company, which involves testing for bugs and also testing user experience design from a user's point of view. I was part of the team that built the current iteration of london.gov.uk, which launched in 2015. # Intent behind the existing design (This is from my memory of the discussions around the time of Gnome 3.0. Corrections and clarifications are welcome!) - Users think in terms of “documents, which can be manipulated using various applications” rather than “applications, which allow manipulating their documents”. - Applications commonly have multiple windows. - Each app window represents 1 document. - Menus in the app window should be directly relevant to that document. - Application-level options are not relevant to any particular document, so they should be outside of any particular app window. # Why change now? - Users don't understand the distinction between application-level options and document-level options, so they don't understand what the panel menu is for. - The idea that each window represents 1 document hasn't materialised. Most apps are a single window. We use tabs liberally, and our tabs appear below the toolbar, which reinforces the idea that 1 window can contain multiple documents. - In some cases there's no way to make a clear distinction between application-level and document-level options, for example in Gnome Calendar. - After six years, there are still many third-party apps commonly used in Gnome Shell that we haven't persuaded to switch to our way of doing menus, for example Firefox and Chromium. - Other desktop environments are using our apps (hi Budgie and Pantheon!) and we want our apps to be at their best, even outside of Gnome Shell. - When we last redesigned menus in Gnome, we didn't yet have popovers. We now have more flexibility in how we display menus in app windows. - We'll soon have a major influx of new Gnome users thanks to Ubuntu. We should make sure our apps are easy for them to use. # Goals - Feel like Gnome - Avoid redesigning the Shell - Avoid changing the layout of existing apps' main windows - Be easy to switch to in a single 6-month cycle - Be simple and easy to understand for experienced Gnome users and developers - Be simple and familiar for people using Gnome for the first time (this is where I avoid using the buzzword “intuitive”) - Eliminate inconsistency in menu layouts among modern Gnome apps - Reduce the number of different menu layouts that users see day-to-day while using modern Gnome apps alongside other apps in Gnome Shell - Make third-party apps, unlikely to design specifically for Gnome, feel more at home inside Gnome Shell - Make Gnome apps' menus behave consistently, when the app is used inside Gnome Shell and when it's used outside (for example in Budgie or Windows) - Be better than what we have now, in the opinion of existing Gnome users, designers and developers # Nomenclature I'm going to discuss several different menus, so let's name them all clearly: - The “dash menu” appears when you right-click or long-press an application's icon in Gnome Shell's Activities overview. - The “panel menu” appears when you click the focused application's name in Gnome Shell's top bar, next to the Activities button. - The “headerbar menu” exists in many (but not all) Gnome apps. It appears when you click the three-line icon at the end of the app window's headerbar. - The “menu bar” exists in more traditional apps, and in many third-party apps, near the top of the app window. It typically contains all of the app's options. - The “system menu” appears when you click the system-wide status icons at the right end of Gnome Shell's top bar. # What we have now ## Modern Gnome apps Examples: Nautilus, gedit, Epiphany, Totem, Gnome Calendar, dconf Editor, Geary, Gnome Calculator, Gnome Clocks, Cheese These apps fully implement Gnome's ideal menu designs, and don't use a menu bar. The *dash menu* contains options for managing the application itself: open a new window; add or remove the app from your favourite apps; see the app's details in Gnome Software. These options apply to *all* apps, and need no input from the app itself. They're relevant when the app is open or closed. While the app is open, the dash menu also contains an option to switch to each open window of the app. This is also relevant to *all* apps, and needs no input from the app itself. Some apps choose to add extra options to the dash menu. I'll call these “jump list options”. These options are useful whether the app is open or closed, and don't change in response to the app's context. For example: some web browsers add an option to open a private window; Deja Dup adds an option to start a backup. Other desktop environments (Unity, Plasma, Windows) show equivalent options in the equivalent place, so app designers and users of other DEs understand what jump list options are. The *panel menu* contains application-level options that are relevant while the app is open, typically: New Window, Help, Preferences and Quit. Many apps also include Keyboard Shortcuts and About. These options are relevant to most apps, so the menu's contents are fairly consistent across all modern Gnome apps. Some apps add extra options to the panel menu. These options apply to all windows of the app, and are useful only when the app is open. For example, Nautilus adds an option to show or hide the sidebar. Epiphany adds options to view all bookmarks and history (arguably these are useful while the app is closed, so should be jump list options). The *headerbar menu* contains options that apply to the current window or document, only relevant while the app is open. It's a continuation of the toolbar. Gedit's option to show or hide the sidebar is in the headerbar menu, because it only affects the focused window. Nautilus's equivalent option is in the panel menu because it affects all windows. Users have to know whether an option affects other windows before they can guess which menu contains the option. ## Variations among modern Gnome apps Some apps have a headerbar but no headerbar menu, because they have no such options, for example: Gnome Calculator, Gnome Clocks, Cheese, Gnome Weather, Gnome Maps. In practice, some apps show the same options both in the panel menu, and in the toolbar + headerbar menu. Gnome Calendar shows all options in both places. In some apps, the headerbar menu is a popover. In others it's a traditional list menu; I believe these apps have no reason to avoid using a popover – they just haven't switched yet. ## Traditional Gnome apps Examples: Gnome Terminal, Evolution, LibreOffice, Quod Libet, Transmission These apps use a *menu bar*, which replaces a modern Gnome app's *headerbar menu*. They use a *panel menu* in the same way as modern Gnome apps. Items in the panel menu are usually duplicated in the traditional place within the menu bar. This means the panel menu is redundant. They have a *dash menu*, like modern Gnome apps. Some apps add jump list options to it; others just have the default options, provided by Gnome Shell. ## Independent apps Examples: Firefox, Chromium, GIMP These apps don't use the *panel menu*. They show all their options inside the app window. In Gnome Shell, they still have a panel menu. It shows the 1 default option, “Quit”, which closes all of the app's windows. Typically they use a proper Gnome *menu bar*, or their own non-Gnome UI that behaves very similarly. Some apps use a menu that behaves much like a headerbar menu, but isn't a proper Gnome headerbar menu. Some apps organise their menu options in other eccentric ways, but always inside the app window. They have a *dash menu*, like modern Gnome apps. Some apps add jump list options to it; others just have the default options, provided by Gnome Shell. These make up the vast majority of all apps in the Linux ecosystem: apps designed for Gnome 2; apps designed for any Linux desktop other than Gnome; desktop-agnostic Linux apps; apps ported from Windows and Mac OS. Because these apps are so common, Gnome Shell users learn that the panel menu often contains nothing useful. ## Gnome apps outside Gnome Shell The *panel menu* doesn't exist outside Gnome Shell, so Gnome apps have to adapt. Traditional Gnome apps already show all of their options inside the app window, so the panel menu doesn't need replacing. Some modern Gnome apps (for example, gedit) integrate the panel menu's contents into the headerbar menu. In this case, the documentation needs to describe different menu layouts, depending on whether the app is used in Gnome Shell. For the other modern Gnome apps, the panel menu becomes another separate menu in the app window. It appears at the start of the headerbar and looks like a traditional window control menu (as in Gnome 2 and Windows 7), where users expect to see options like Maximise and Minimise. It actually contains other options like Preferences, which are unexpected here for non-Gnome apps. # Proposal 1. Gnome apps should integrate their application-level options into their headerbar menus. They should use this menu layout irrespective of which desktop environment they're running in. - The app and the documentation don't need to cater for 2 different menu layouts. - If you use the same app in Gnome Shell and in other DEs, the app looks and works consistently in both cases. Headerbar menus should use a consistent layout for these newly-integrated items, so: 2. *Preferences* and *Quit* should become icon buttons at the end of the headerbar menu. - This imitates the equivalent options in Gnome Shell's *system menu*. To me this feels very distinctly Gnome. - We already use icons for these options in the system menu, so we can be sure the icons are already understood, and there's no work needed to design new icons. - Nautilus and gedit already use groups of icon buttons in their headerbar menus. There's little styling work needed for the buttons, and none at all if the existing styles can handle groups of 2 buttons rather than 3. - Quit becomes the last option in the headerbar menu, which is apt. 3. *Help* should become a sub-menu, immediately above the Preferences and Quit buttons. - Users expect Help to appear near the end of an app's menus. - This sub-menu should look and behave identically to gedit's View menu. There's no work needed to design or implement how this sub-menu should look or behave. - The sub-menu should contain 3 options: User Guide, About this app, Keyboard Shortcuts. - “User Guide” should not be called just “Help”, because this would match the sub-menu's heading (which closes the sub-menu). - The label for “About this app” should not include the app's name, because I've seen users misunderstand “Help > About Foo” as meaning “help me with Foo”. This also keeps the label consistent for all apps. - “Keyboard Shortcuts” is a separate menu item just because it's already separate from the main Help documentation. - If an app only has 1 of these options, that option should replace the Help sub-menu. There shouldn't be a sub-menu containing only 1 option. (Alternatively, Help could become an icon button, in between Preferences and Quit. This would imitate the system menu more closely. We would have to be happy with an icon button opening a sub-menu, or we'd have to relocate Keyboard Shortcuts and About. We'd also have to be very sure new users will understand the icon.) 4. There should be a separator immediately above Help, Preferences and Quit, so that these options form a clear unit, consistent in all Gnome apps. (This isn't needed if Help is an icon button.) 5. *New Window* should become an ordinary item in the headerbar menu. - This option exists in most apps, but isn't as common as Help, Preferences and Quit. It doesn't feel right to include it in that group. - It should appear near the top of the menu. Apps with “File” menus commonly include New Window, near the top. 6. Other items presently in the panel menu should become ordinary items in the headerbar menu. 7. The *panel menu* should continue to exist. It should show a duplicate of the focused application's *dash menu*. - Gnome Shell still looks the same. - The top bar still shows the focused application's name and icon. - The panel menu now includes genuinely-useful options for *all* apps, even independent apps that don't use jump list options. - We're now better at giving prominence to options that the app designer considered important, because independent apps use jump list options more often than they use our existing panel menu. - Jump list options are more discoverable, because they have a dedicated affordance, and can be reached without right-clicking or long-pressing. - It's quicker to get to jump list options for the focused app, without going into the Activities overview. - It's now possible to switch between windows of the focused app without going into the Activities overview. - The dash menus and panel menu are now a logical, discoverable place to put menu items from KStatusNotifierItem/AppIndicator, if we decide to support that protocol in future. # Impact in various cases ## Traditional Gnome apps These apps would have to ensure that all items in the panel menu are also included in the menu bar. The same is true for apps that do their own thing instead of a menu bar. This already seems to be the case for most of them. (The only former exception I can think of was Totem.) ## Apps that use a headerbar but have no headerbar menu These apps would have to gain a headerbar menu, containing only the basic options: Help, Preferences and Quit. This is the only case that involves a change to the layout of existing apps' main windows. I believe this is low impact. The lack of a headerbar menu means these apps are already exceptionally uncluttered, and I don't think adding a headerbar menu harms that. It makes them more consistent with other modern Gnome apps. There's comfortable space for a headerbar menu even in Gnome Calculator. ## Apps with a headerbar menu that isn't a popover I believe these apps have no reason to avoid using a popover – they just haven't switched yet. Preferably they would switch to using a popover. If they can't switch yet, they could simply add Help, Preferences and Quit at the end of their existing headerbar menu, after a separator. # Prior art Chrome originally had 2 distinct menus: one for application-level options, and one for document-level options. They dropped this distinction in version 6, and now all of the app's options are in a single menu much like a headerbar menu. Firefox has Help, Customise (faintly similar to Preferences) and Quit as icon buttons at the end of Firefox's main menu, which is very similar to a headerbar menu. All 4 major web browsers on Windows (Chrome, Edge, Firefox, IE) use a menu very similar to a headerbar menu, which contains all of the app's options. # Conclusion I think this meets the goals stated above (with the small exception of those apps gaining a menu in their headerbar). I think it's more familiar for new Gnome users, and better for long-time Gnome fans (like me). It's straightforward for developers to implement. It make our apps look better outside Gnome Shell, and it makes Gnome Shell look better when used with independent apps. It makes Gnome apps simpler and the Gnome experience more consistent. What do you think? Cheers, Greg -- Greg K Nicholson