GNOME Bugzilla – Bug 675098
Provide an app menu
Last modified: 2014-08-01 17:05:33 UTC
See https://live.gnome.org/GnomeGoals/PortToGMenu Utilising the app menu should make it possible to remove the menu bar. Suggested app menu format: New Window --- Find in Page... --- Bookmarks > --- Show All Documents --- Show Text Cursor --- About Help Quit And I'd recommend adding the following to the context menu: Print... --- Larger Text Smaller Text Notes: * Go back and forward are already in the UI as toolbar buttons. * Previous/next page are always insensitive for me, and I'm not sure what they're for. * Show Text Cursor seems non-standard (and it took me quite a while to figure out what it does). Is that needed?
1) Find in Page, Bookmarks, and Show All Document are all about the window. Do they belong in the app menu? 2) Would Bookmarks just be a submenu with the same contents at the current Bookmarks menu? 3) There's no about dialog in Yelp on purpose. 4) I'm concerned about the discoverability of Print, Larger Text, and Smaller Text. I'm already not fond of the functionality hidden behind right-click on links, but I think right-clicking on links is somewhat common. I don't think people will right-click the page to change the text size. 5) I'm also a bit concerned about the discoverability of the app menu itself. Though I guess since that's where we're putting Help menu items these days, people will have already figured it out. 6) Previous/Next Page are for DocBook, info, and certain types of Mallard pages. It's only sensitive for linear documents. I don't think anybody cares about the menu items. But people do care about the key bindings, and the menu items are how you learn the key bindings. I can think of other ways to present the key bindings, like tooltips on the Previous/Next links. 7) Show Text Cursor is an accessibility requirement. F7 works in Epiphany, Firefox, Evolution, and probably tons more applications. Yelp is the only one that has a menu item. Because you can't go through the help to find out about F7 in the help. Generally, whenever there's a trade-off between discoverability and anything else (long-term efficiency, consistency with other apps, prettiness), I always choose discoverability. I'd also need a sign-off from the accessibility team.
(In reply to comment #1) > 1) Find in Page, Bookmarks, and Show All Document are all about the window. Do > they belong in the app menu? I think so. They exist independently of the window's content - bookmarks and show all documents as 'other' places, find in page as an application level tool. > 2) Would Bookmarks just be a submenu with the same contents at the current > Bookmarks menu? Yup. > 3) There's no about dialog in Yelp on purpose. One less menu item. \o/ > 4) I'm concerned about the discoverability of Print, Larger Text, and Smaller > Text. I'm already not fond of the functionality hidden behind right-click on > links, but I think right-clicking on links is somewhat common. I don't think > people will right-click the page to change the text size. I think we should try and be consistent with Web on this one. cc'ing Jon and Jimmac for advice. > 5) I'm also a bit concerned about the discoverability of the app menu itself. > Though I guess since that's where we're putting Help menu items these days, > people will have already figured it out. Indeed. > 6) Previous/Next Page are for DocBook, info, and certain types of Mallard > pages. It's only sensitive for linear documents. I don't think anybody cares > about the menu items. But people do care about the key bindings, and the menu > items are how you learn the key bindings. I can think of other ways to present > the key bindings, like tooltips on the Previous/Next links. This has been mooted an alternative way of displaying keyboard shortcuts: https://live.gnome.org/GnomeOS/Design/Whiteboards/HelpOverlay > 7) Show Text Cursor is an accessibility requirement. F7 works in Epiphany, > Firefox, Evolution, and probably tons more applications. Yelp is the only one > that has a menu item. Because you can't go through the help to find out about > F7 in the help. ... Potentially silly question - but why can't you have help pages about the help browser?
> > 7) Show Text Cursor is an accessibility requirement. F7 works in Epiphany, > > Firefox, Evolution, and probably tons more applications. Yelp is the only one > > that has a menu item. Because you can't go through the help to find out about > > F7 in the help. > ... > > Potentially silly question - but why can't you have help pages about the help > browser? We've gone back and forth and back and forth on this one in the last nine years. I don't really mind pages that help you get more out of the help browser. But if you need F7, and you don't know about F7, then you're out of luck. The help is one of the ways you can learn about these sorts of things for other applications.
Also, I've worked pretty hard to make Yelp feel less like an application and more like a utility window. This sort of moves things in the opposite direction. My experience is that many people don't even realize that Yelp is an application. They just think it's the help window for the app they're getting help on. That's why there's no about dialog. It just resulted in me getting support emails for every app under the sun. If I could figure out a way to make Yelp not have an app menu at all, I'd probably go that route.
(In reply to comment #4) > Also, I've worked pretty hard to make Yelp feel less like an application and > more like a utility window. This sort of moves things in the opposite > direction. My experience is that many people don't even realize that Yelp is an > application. They just think it's the help window for the app they're getting > help on. That's why there's no about dialog. It just resulted in me getting > support emails for every app under the sun. > > If I could figure out a way to make Yelp not have an app menu at all, I'd > probably go that route. Users won't be aware that it is called an 'application menu', and I don't think it'll make Yelp any more application-like than it already is. It's important to be consistent with what our other applications are doing; inconsistent use of the application menu would be really disorientating.
I strongly suspect many users will not even think to click the app menu for Yelp, even if they're used to using it for other apps. My decade of experience in working with help systems in general and Yelp specifically tells me that people usually think a help window is a utility window of the app they called it from.
(In reply to comment #6) > I strongly suspect many users will not even think to click the app menu for > Yelp, even if they're used to using it for other apps. My decade of experience > in working with help systems in general and Yelp specifically tells me that > people usually think a help window is a utility window of the app they called > it from. Would it be hard to come up with a patch so we can test your suspicion?
It's fairly invasive, since GtkActionGroup is part of libyelp's API. Somebody who knows the new API well could probably have a prototype in a weekend.
Created attachment 228534 [details] [review] quick patch
Created attachment 228535 [details] how it looks
Created attachment 228536 [details] how it looks, 2
Created attachment 228538 [details] how it looks, 2
Created attachment 228554 [details] [review] more complete patch
Yelp has an app menu as of version 3.13.3.