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... --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
See Also: MenusAreEvil

View edit of November 3, 2014 or FindPage with title or text search