Should main drop-down menu always be titled File

Question

First my question, and then the details below: Should the main drop-down menu in a windows application always be titled "File" or should it be titled something more appropriate to the options it contains?

We are finishing up development on a pretty slick data reporting application. Without getting into too much unnecessary depth, here are the details:

On the main user interface, we have three dropdown menus: File, Options, and Help. Under File are options to:

1. Configure a new report (not necessarily run the report, but just set one up to be run in the future, possibly over and over)

2. Add a schedule to an existing report (to run automatically at user-defined intervals)

3. Add or remove devices that can be reported on

4. Exit program

We chose the title "File" because that seems pretty standard across the board for a program's main drop down menu, but I'm questioning if that is an appropriate title since none of the options under it directly relate to a file or files in any way. I am wondering if "Setup" or "Configuration" or "Menu" would be more appropriate. Based on Wikipedia's definition of file menu (http://en.wikipedia.org/wiki/File_menu), I'm thinking we should rename it. But at the same time, with users so used to the main menu being titled "File", I don't want to confuse them or make it seem strange that there is not a file menu.

Answer 1

Microsoft provides some guidance in the Windows User Experience Interaction Guidelines. This guidance explicitly suggests avoiding File and other standard menu categories for applications not designed around files and documents. From page 228, section "Menu Categories":

Choose single word names for menu categories. Using multiple words makes the separation between categories confusing.

● For programs that create or view documents, use the standard menu categories such as File, Edit, View, Tools, and Help. Doing so makes common menu items predictable and easier to find.

● For other types of programs, consider organizing your commands and options into more useful, natural categories based on your program's purpose and the way users think about their tasks and goals. Don't feel obligated to use the standard menu organization if it isn't suitable for your program.

● If you choose to use non-standard menu categories, you must choose good category names. For more information, see the Labels section.

● Prefer task-oriented menu categories over generic categories. Task-oriented categories make menu items easier to find.

Then on page 237, section "Labels", subsection "Menu category names":

● Use menu category names that are single word verbs or nouns. A multiple-word label might be confused for two one-word labels.

● Prefer verb-based menu names. However, omit the verb if it is Create, Show, View, or Manage. For example, the following menu categories don't have verbs: Table, Tools, Window

● For non-standard category names, use a single, specific word that clearly and accurately describes the menu contents. While the names don't have to be so general that they describe everything in the menu, they should be predictable enough so that users aren't surprised by what they find in the menu.

In your case, the question comes down to whether reports are considered files/documents. Assuming your reports run many times on different data (rather than a "report" referring to one report result/output instance), I think reports are different enough from files that a File menu doesn't make sense. Use Reports instead. (I would have suggested Manage, but that's explicitly ruled out by the above guidelines.)

I think it's okay to leave Exit in the Reports menu. Most users will expect Exit to be in the 'primary' (leftmost) menu. The alternative, creating a File menu with only Exit in it, will confuse users looking for the actions related to reports, and may confuse some users simply because most menus contain more than one item.

Answer 2

There's no 'should' here, really. Its a matter of preference and user expectations.

I generally have a File menu in my applications for convention's sake. It just looks odd to users if there isn't one there. In your specific case, I'd recommend adding a 'Reports' top level menu, and moving the first three items from the File menu to that. The reason is they all seem to apply to reports, not file system or OS interaction. The users would look up and immediately know where to go in the menu. I would not worry if the File menu looks bare... if your program is like most, you'll probably find reasons to add to it as the program matures.