Menu organization best practices | Tech Off

Soviut

This has always been one of those things that sticks in the back of my head when I'm designing menus for my winforms applications. How do I organize things that seem to belong to more than one menu.

For example, I have a layer manager in my application so I have several layer operations (Create, Move Up, Move Down, Delete, Properties) but I also have an "import layer" procedure that lets the user import a layer from a file. So theoretically its a File operation that should be under the File menu.

This is a fairly simple example that I can easily compromise on, but I've run into far deeper overlaps than this before and I'm wondering; Are there any good resources that explain the best practices for overlapping functionality and menu organization like this?

JParrish

I don't know of any best practices. The concept is fairly simple. The challenge is to make locating the operation intuitive for the user. In the example you gave I would argue that the importing of a layer is not a file operation in the sense that file -> import usually implies. Instead under layer I would create an "Import from File" option.

Use the subject of the task to determine which top level menu item the task menu item appears under. Try to use consise naming for the task that would make sense in the context of the top level menu item.

littleguru
<3 Seattle

I'm usually looking around in the Microsoft apps (VS, Word, Excel, Access, Explorer, etc.) to see how they did it... I'm looking for the same entry or a simliar entry in a menu and put it then in the same place.

Yggdrasil
Pour me a cab, 'cause I can't drink no more.

littleguru wrote:
I'm usually looking around in the Microsoft apps (VS, Word, Excel, Access, Explorer, etc.) to see how they did it... I'm looking for the same entry or a simliar entry in a menu and put it then in the same place.

While this is generally a good recommendation - both because we get to take advantage of the work Microsoft's UI designers did, and because "good UI" is, by definition, UI that the users are USED to.

However, one should take into account that the Ribbon in Office 2007 was designed specifically because the UI for Office proved problematic - too many things in unexpected places like the Tools menu and other inconsistencies. Everything with a grain of salt.

littleguru
<3 Seattle

Yggdrasil wrote:

littleguru wrote: I'm usually looking around in the Microsoft apps (VS, Word, Excel, Access, Explorer, etc.) to see how they did it... I'm looking for the same entry or a simliar entry in a menu and put it then in the same place.

While this is generally a good recommendation - both because we get to take advantage of the work Microsoft's UI designers did, and because "good UI" is, by definition, UI that the users are USED to.

However, one should take into account that the Ribbon in Office 2007 was designed specifically because the UI for Office proved problematic - too many things in unexpected places like the Tools menu and other inconsistencies. Everything with a grain of salt.

Yeah. The menus in Office were just overloaded. If you get menus with a 3+ level depth, you should search for an alternative.

Soviut

Yggdrasil wrote:

However, one should take into account that the Ribbon in Office 2007 was designed specifically because the UI for Office proved problematic - too many things in unexpected places like the Tools menu and other inconsistencies. Everything with a grain of salt.

One menu organization thing that's always irked me is the placement of "Options" or "Configuration" or "Settings". In some apps its under the View menu, in some rare cases in the File menu, others have dedicated Options menus, others have theirs under a Project menu.

Sven Groot
My name has 9 letters. Coincidence? I think not...

The Windows-standard behaviour is to have (application) options under the Tools menu.

AndyC

Sven Groot wrote:
The Windows-standard behaviour is to have (application) options under the Tools menu.

Yeah, but that doesn't necessarily make it a good idea. I tend to agree with Jensen Harris on this one, a Tools menu is a Junk Drawer and best avoided if at all possible.

Sven Groot
My name has 9 letters. Coincidence? I think not...

AndyC wrote:

Sven Groot wrote: The Windows-standard behaviour is to have (application) options under the Tools menu.

Yeah, but that doesn't necessarily make it a good idea. I tend to agree with Jensen Harris on this one, a Tools menu is a Junk Drawer and best avoided if at all possible.

Still, it's the first place I, and most people I know, will look for Options.

On the topic of Tools being a Junk Drawer, it's perhaps interesting that in Dutch versions of MS applications, "Tools" is always called "Extra". The main reason for that is because the literal translation of tools, "Gereedschappen", is much too long, but it does increase this junk drawer impression.

TommyCarlier
I want my scalps!

Many years ago, I designed a general menu layout that might be more logical than the default Windows menu layout. It was based on locations or categories. At the time, I was still studying and a few years had passed before I implemented it in an application.

The basic idea is that the top-level menu's represent hierarchical categories or locations. The first menu is the Application-menu that contains functions that are global for the application, like Options, Help, Info (= About...) and Close. The label of the menu is not Application but the name of the application.

The other menus depend on the type of application. A document-based application would have a Document-menu that represents the current document (Open, Save, Print, ...). Other top-level menus represented groups of functionality or locations.

The first application I applied this design to was Calctor, an advanced calculator (you can find the source code in the Playground). Its menus are structured like this:

Calctor (the Application menu)

Options...
Color scheme

Silver
Black
Blue

Info...
-
Close

Input (commands for the input-region)

New
New from template...
Open...
-
Save
Save as...
-
Insert snippet
Clear input region

Output (commands for the output-region)

Copy
Export

Web sites

(list of relevant web sites)

Show/Hide Help (single command)

Something I also did there that is non-standard was to give the top-level menus an icon. The Calctor-menu has the icon of the application, the Input-menu and Output-menu have icons that are also displayed above the Input-region and Output-region, etc...

littleguru
<3 Seattle

@Tommy: your idea looks a little bit like the one of the apple menu - with the application menu etc. I really like it... it's better organized then the current way to do menus. Like, for example, why is Exit or Quit application under File? Really nice ideas!

littleguru
<3 Seattle

@Dylan C: Here you go.

TommyCarlier
I want my scalps!

I used the free Krypton Toolkit ( http://www.componentfactory.com ). The link littleguru gave you is correct. On that page you can find 2 links: the one that says 'check out this page' leads you to the binaries (with the installer). The one that says '[Save]' (at the bottom) lets you download the source code (a Visual Studio solution).

TommyCarlier
I want my scalps!

Littleguru, the Application-menu was inspired by the Apple-menu. It just makes more sense that the 'File' menu. Commands like Options, Help and Info are global for the application, so I think they belong together. I've also been prototyping a simple web browser, based on the .NET WebBrowser control that implements a similar concept. Its first menu is the Application-menu, the second menu is the 'My Web'-menu (contains bookmarks and search) and the third is the 'This Page'-menu (contains Print, Properties, Open with (other browsers), ...). I might release it some day, if I got a working implementation that's not too buggy.

Soviut

My only beef with the "Application" menu the way Apple does it is that it makes the menus appear offet depending on how long the name of your application is "Macromedia Flash 8" is far longer than "iCalc". It seems trivial, but for UI design that can be considered a pretty jarring disconnect when, for example, your File menu isn't in the exact same place all the time.

I propose just calling the menu Application. While not as immediatly self-describing as the actual name of the app, at least it stays the same size in each window.

TommyCarlier
I want my scalps!

You are correct that it would look silly. Imagine 'Microsoft Office 2007 Word'. In these cases, a short name should be used, like 'Word'. If you add icons to (some or all) the top-level menus, it becomes even clearer. I think a name instead of just 'Application' adds some personality to the window.

JChung2006

littleguru wrote:
Like, for example, why is Exit or Quit application under File? Really nice ideas!

The rationale for this was that in SDI (single document interface) document-oriented applications, you would be closing the File with File / Close. And for simple applications, the command to close a document is often overloaded with the command to quit an application.

Notably, it isn't in MDI applications like Word or Visual Studio.

Personally, I never liked the File/Quit, File/Exit, or File/Close menu items. They seemed redundant when practically every window comes with a close button in its frame.

Soviut

JChung2006 wrote:

littleguru wrote:Like, for example, why is Exit or Quit application under File? Really nice ideas!

The rationale for this was that in SDI (single document interface) document-oriented applications, you would be closing the File with File / Close. And for simple applications, the command to close a document is often overloaded with the command to quit an application.

Notably, it isn't in MDI applications like Word or Visual Studio.

Personally, I never liked the File/Quit, File/Exit, or File/Close menu items. They seemed redundant when practically every window comes with a close button in its frame.

I would argue that the menus are there for accessibility. Admittedly, Ctrl+F4 closes a window, but there's no obvious explanation of that in any application, its mostly just understood by most people these days. But if that's the case, the close button is technically mouse-only button, while the file menu provides a formal keyboard-accessible method of closing the application that isn't a shortcut.

Soviut

TommyCarlier wrote:
You are correct that it would look silly. Imagine 'Microsoft Office 2007 Word'. In these cases, a short name should be used, like 'Word'. If you add icons to (some or all) the top-level menus, it becomes even clearer. I think a name instead of just 'Application' adds some personality to the window.

Perhaps some kind of semi-collapsible drag panel to hold the name, so the user chooses how much space is taken up by the app name. Heh. This would be a really cheap way of trying to solve the problem though, hehe.

Instead, maybe having the application menu at the far side of the menu bar, floating left-justified to the left side.

[File Edit View Help Microsoft Word 2007]

CannotResolveSymbol
{insert caption here}

Soviut wrote:

TommyCarlier wrote: You are correct that it would look silly. Imagine 'Microsoft Office 2007 Word'. In these cases, a short name should be used, like 'Word'. If you add icons to (some or all) the top-level menus, it becomes even clearer. I think a name instead of just 'Application' adds some personality to the window.

Perhaps some kind of semi-collapsible drag panel to hold the name, so the user chooses how much space is taken up by the app name. Heh. This would be a really cheap way of trying to solve the problem though, hehe.

Instead, maybe having the application menu at the far side of the menu bar, floating left-justified to the left side.

[File Edit View Help Microsoft Word 2007]

Deja vu all over again...

Soviut

CannotResolveSymbol wrote:

Soviut wrote:

TommyCarlier wrote: You are correct that it would look silly. Imagine 'Microsoft Office 2007 Word'. In these cases, a short name should be used, like 'Word'. If you add icons to (some or all) the top-level menus, it becomes even clearer. I think a name instead of just 'Application' adds some personality to the window.

Perhaps some kind of semi-collapsible drag panel to hold the name, so the user chooses how much space is taken up by the app name. Heh. This would be a really cheap way of trying to solve the problem though, hehe.

Instead, maybe having the application menu at the far side of the menu bar, floating left-justified to the left side.

[File Edit View Help Microsoft Word 2007]

Deja vu all over again...

Agreed for the most part. Its what I was kind of thinking about when I was writing about the issue i have with OSX's menus getting pushed around by long application names. I'm still not a fan of the universal menu though. While it seems like a "its always in the same place" good idea at first, it quickly reveals a major disconnect from the application it belongs to. Couple that with the fact that I can see all my apps but only one menu can really confuse some people.