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.)

Manifesto: Users should be able to...
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 versus a "keywords" field in "actions" table --------------- 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) 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 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 better KISS. -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.
See Also: MenusAreEvil
CategoryUserInterface

EditText of this page (last edited August 30, 2013) or FindPage with title or text search