Re: Retiring app menus - planning for 3.32.0



My main hesitation to having the app level menu items (preferences, keyboard shortcuts, help, about) always available is that it could make the menus unpredictable - there is a clarity in having a definite place for those items. Also, given that many of them are infrequently used, requiring the user to navigate up a level to access them doesn't seem all that terrible.
A visual separation would indicate the different meanings of the menus. Icons denoting primary/secondary menus would also work as the user would implicitely learn which icon-button hosts which menu. But to me the best solution is to place them in a consistent way. Right now when disabling the top bar application menu, it finds itself on an extreme end of the window bar (or header bar, if the app supports it). This properly indicate to the user, even though the menu button icon is that of the app itself, that there's an application menu there. With a visual separator the primary menu could be separated from the secondary menu.

We could definitely maintain clarity and consistency and still allow both menus shown regardless of application state.

Nathan Graule


Le ven. 21 sept. 2018 à 12:33, Allan Day <aday gnome org> a écrit :
Nathan Graule <solarliner gmail com> wrote: ...
I feel like having the primary menu hidden in an in-window navigation app would be a regression from current, as a primary menu may apply anywhere, and having the user modify (and especially here, undo) application state in order to access a particular menu item (that, again, by its definition can apply anywhere in the app) would lead to end-user frustration.
That's a fair point. For example, it's certainly possible that someone would want to change a setting in Videos while they're playing a video. My main hesitation to having the app level menu items (preferences, keyboard shortcuts, help, about) always available is that it could make the menus unpredictable - there is a clarity in having a definite place for those items. Also, given that many of them are infrequently used, requiring the user to navigate up a level to access them doesn't seem all that terrible. That said, what we could do - and this has been discussed a little - is expose some of those items in the secondary menus, as necessary. In the video playback example, you could have a "Video Playback Help" in the secondary menu, for instance. Allan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]