Re: Retiring app menus - planning for 3.32.0

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

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.


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