Googlify Deep Menus

The menus on some desktop apps are just too damned deep and involved. I've seen some real doozies on Microsoft Outlook that were about 8 menus deep. It's clearly a case of LimitsOfHierarchies. I suggest vendors look to "googlify" menus and features; that is put a search engine of some sort on them, resembling Google-like search services. (Google wasn't the first, but it has become a common verb of sorts.) -t

Manifesto: Users should be able to...

create short-cut icons for options and/or put them into a "favorites" menu, like web browsers allow
enter command and address macros with parameters into a small dedicated CLI and create new ones at need, like (some) web browsers allow.
create new macro-commands and manage them (e.g. through a special folder in the 'favorites' menu) via use of short scripts, like (some) web browsers allow.
browse all commands, along with detailed descriptions of what they do and examples of how one might use them
receive ProgressiveDisclosure when it comes to commands - short descriptions + full manuals - after performing any search, much as Google provides short descriptions and titles in response to a search
modify context menus (e.g. right-click popup menus) both with commands that require context and common commands that apply universally
Type in short sub-strings, such as "fi" or "fil" to find "filing", "files", etc. in feature titles (and synonyms if provided). This is something that Google does not do well, perhaps because it does not scale to the web. But, for a few hundreds entries, substring searching is not a performance problem.

--AnonymousDonor

Here's a TableOrientedProgramming view of how one might set them up internally:

table: actions --------------- actionID // unique action word, ideally somewhat descriptive actionDescript // short English description of purpose actionManual // long description, all parameters, examples of // use (for progressive disclosure) actionScript // either a command-script or equal to actionID for 'primitives' // (allows commands to be constructed of other commands) // primary key is actionID

table: keywords // (controversial vs. a "keywords" field in "actions" table, see discussion) --------------- actionRef // foreign key to actions keyword // synonym or related word; could be any related actionID weight // weight for search index, informal guesstimate of relationship // low precision OK - could be a simple enum (e.g. LOW,MED,HIGH) // candidate key is (actionID,keyword) // indexed on keyword for searches // table is for hand-entered keywords, not for stuff that can be automatically // derived from a full-text index over the actions table

table: organization ------------------- actionRef // foreign key to actions dialogURI // a location for appearance (might use anchors for function or index) // candidate key is (actionID,dialogURI) // table might be copied (virgin) to each user and modified from there. // note: dialogURI might be flexible enough to include gestures // and keyboard macros - e.g. ('save','keyboard:Ctrl+s').

Note: I couldn't readily handle the older 'keywords' attribute approach, seeing as it isn't even 1NF. The above are in 5NF (for actions) and 6NF (for everything else).

I've often found that "over-engineering" unless one has a heavy-duty search system. A simple "keywords" column with multiple potential words (like it was before your change [1]) is often plenty sufficient. But this is not the place to have the YagNi/SafetyGoldPlating argument again.

What's the point in having a 'keywords' column along with your 'feature-ref' table, like it was before my change? Sufficient, redundant, pointless, etc. I happen to believe that YagNi should eliminate tables, not columns, but I agree that arguing here is somewhat pointless.

Simple text searching can be done using multiple keywords in a single field. The same cannot be said about the other table. And it's easier for a user or configuration admin to key in and edit a list of words in a single text box rather than have a dedicated CRUD stack for handling each keyword (or parse back and forth). A dedicated per-word table both adds an extra table and added UI/CRUD complexity. I'm not saying one or the other is always the best, but for small-scale or nichey apps, "keywords" is often better KISS. The above may not even be implemented with a RDBMS, but rather RAM-centric structures and/or XML such that heavy normalization may not be well-supported. (It's presented in a RDBMS-like way for familiarity.) -t

The latest version of Delphi (RAD Studio 2010) has an incremental (as-you-type) search feature for any text in the IDE's menu system (with a nice keyboard shortcut, ctrl-.). You can put favorite components in their own section.

Mac OS X has had a search field in the standard help menu since (I think) Mac OS X Leopard (fall 2008). It is incredibly useful.

FWIW, the original Mac UI did not support hierarchal menus at all. They were a hack added on later in Freehand or Pagemaker.

This idea reminds me of old "orthodox" stuff, like MidnightCommander, which had a 'command bar' in the bottom, and a user-defined menu, in F2. Sure the command bar is a shell, but I think the idea could be extended like an Emacs M-x command or :vi stuff, it could be your search bar, or you could include small man pages for commands with a 'search the manuals' command. Also your favorites reminds me a lot of the F2 user-defined menu. I think this for powerusers plus a default menu-bar at top for regular users would be quite nice indeed.

[1] I don't appreciate you deleting the original. Add your version, don't replace somebody else's version with your preference. That's rude. -t