Hey Greg, First of all, thanks a lot, one can tell about this email that you care passionately about GNOME, so thanks for reaching out! The design team can certainly use help :-) I will leave it up to them to route you to the right venue to have a conversation about your suggestions.
I was just wondering, given that you are from Manchester, are you aware that we are organising GUADEC in your home town this summer? It could be a lot easier to discuss these things in person and given that it's in your home town I'd really encourage you to register and attend! 2017-04-10 22:07 GMT+01:00 Greg K Nicholson <[email protected]>: > 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 > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Cheers, Alberto Ruiz
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
