For some reason, blogs.gnome.org doesn’t let me upload webm or ogv files. Go watch a video of searchable menus on Google+. Some notes on what’s going on:
- The initial menu items are not specified by Nautilus. The menu is populated with items based on tags in the Mallard help files.
- Start typing to search. This is searching on title and desc elements from the GNOME desktop help. The results are filtered to only include pages relevant to Nautilus. The scroll arrows showing momentarily as you type is an unfortunate glitch I hope to iron out.
- Click a topic and Yelp opens immediately to that topic.
- What’s more, Yelp knows that you arrived there from a menu item you got after searching in a menu, and offers a link at the top to perform a full text search on your search terms.
The thing that I felt was missing was trying to get the user to the answer without requiring him to open Yelp.
From your example, the “Rename a file or folder” label would have under it in a soft italic (or whatever out-of-the-way place to put secondary info) a “Edit > Rename” tip.
Brilliant. I’m always looking for ways to give the help faster without going to Yelp. I have some idea on quick help blurbs, all dynamically extracted from the help of course. I just don’t think I’ll be able to pull that much off for 3.4.
It’s great. I always wanted menu search in apps like GIMP.
IMO it would be good to have keyboard shortcut to move focus to this search.
Putting one item menu also seem unnecessary so i think that putting search directly on menu bar / panel would be better.
Thanks a lot for your work.
Yes! Imagine:
Menu bars as standard have a search field at the end. It returns all matching commands in any of the menus, plus help topics.
And toolbar items. And relevant files from Tracker and/or Zeitgeist.
Activating a result for a command performs the command. The relevant menu also expands showing the relevant command highlighted as if focused. And/or the relevant toolbar button appears depressed. The menu fades out slowly over about two seconds; the toolbar button pops up after about half a second.
This could become a catalogue of all possible commands—an auto-completing command-line. Like the Activities overlay search box, but for just one application.
In future, Gnome applications could have an abstract semantic register of all available commands. Applications can enable and disable commands on this register at any time. All menus and toolbar buttons are drawn from this register. We’d keep Zeitgeist-type data on each command’s usage.
This register would open up possibilities for UIs that could adapt to show most-frequently used commands, or adapt to suit their environment (window size; time of day; geographical location).
Or the Activities overlay could become capable of invoking any command from any installed program.
Hell, this could *replace* the menu bar.
PS: If you think adaptive UIs don’t work because they’re “trying to be too clever”, the failure isn’t in being too ambitious; it’s in not succeeding at being clever enough.
PPS: Besides, this is exactly how Windows’s Start menu works: a finite list of commands accessed by a combination of search and an automatically-generated list of frequently-used commands.