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
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop- devel-list