I'm building a desktop application that is a tool to mount some very domain-specific graphic structures that in the tool's context are called "sequences" (it's not important here I guess).

To help with answering this I must say that the target user of the application is familiar with any visual manipulation tool like Photoshop, Illustrator, Inkscape, Premiere, and mostly any Adobe application. Some of the target users are familiar with other mountage tools and 3D graphic tools.

Each instance of the application allow to edit one unique Project. Each Project contains an unlimited number of Sequences. Once a Project is open, you need to open a Sequence to start editing. You can open several Sequences but only one can be graphically edited at the same time and all the edition views displays informations only for the currently selected Sequence.

This tool is meant to be cross-platform : Windows, MacOS and Linux.

I'm trying to organize the application menu to show the possible actions and I'm having a hard time choosing between a conventional organisation like this one :

File                Edit           Project           Sequence          Views
    New                 Copy           Properties        Properties        ...
        Projet          Cut            ...               ...
        Sequence        Paste                                    
        ...             ...

... and this less conventional organization that I feel might be more natural for the task ("Designer" is name of the tool):

Designer            Project               Sequence           Edit       Views
    New Project         New Sequence          New Object        Copy       ...
    Open Project        Open Sequence         ....              Cut
    Close Project       Close Sequence        Properties        Paste
    ...                 ...                                     ...
    Quit                Properties

What do you think? I have doubts because I'm not sure if not using the convention will or will not makes the user lost.

  • great discussion point, as you have already mentioned this one is for advanced users who are familiar with photoshop .etc kind of application.. as you said going with second options makes it easy for users. Commented Jul 27, 2011 at 19:20

3 Answers 3


Does the 'domain-specific' organization actually match the way users naturally model their activities? Would a designer refer to 'projects' and 'sequences' when not using the application? Will they actually understand that a "designer" menu contains project controls (not account / author property data)? There are lots of questions, and I think the only reliable way to answer them is with a real-world A/B test.

That said, I like the idea of your 'domain specific' menu (especially making the first, primary menu deal with the first, primary object - the project, not the individual sequence). I also think it's a good idea to separate the add/remove/close controls for projects and sequences (though you can still do that in a single menu). Still, I really do think convention might mean users accept the 'normal' menu more readily.

  • As the tool is meant to allow the users to reach a new field in their domain, that they cannot reach easily at this time, making it uncommon, I guess I cannot answer your first questions without, as you said, real testing.
    – Klaim
    Commented Jul 27, 2011 at 21:06
  • I've decided to go with this : I develop each actions separately and make sure there is a single point in the code that tells where should be each action in the menus. Once done, I'll first organize the menus in the domain specific way. When I'll get feedbacks, it will be easy to tweak the menus organisations without having to change too much things. This answer suggesting to first check with real world tests, I'll consider it the best answer.
    – Klaim
    Commented Aug 21, 2011 at 10:22

The conventional menu seems somewhat forced and unnatural.

I like your unconventional menu much better. It seems much closer to what a user's mental model would be like. Personally I would put the Edit menu as the second after the Designer menu, as the Designer menu sort of maps to the conventional File menu and having Edit as the second menu is something people really expect.

In this case and for such a specific problem domain, I wouldn't worry about not sticking to a convention. Providing a menu that much maps more closely to the concepts they work with is a big plus.

And don't forget that MS is now "hiding" the file menu with its Ribbon interface (it now sits in the app button). In fact you could say that the Ribbon has overthrown the whole conventional menu thing.

  • I'm tempted to not have menus but I guess I should still have it at least for the first release.
    – Klaim
    Commented Jul 27, 2011 at 20:45
  • Don't just use menus because everyone else does. If you use menus, have a reason. I've found that sometimes a menu just doesn't fit with the flow of an application and toolbars or a ribbon-like interface can work better, or sometimes even something quite different from that (though I would recommend caution in doing something very different - convention is very strong and disappointingly often stronger than a distinctly better interface). Commented Jul 28, 2011 at 16:12
  • I agree with @Marjan, the conventional menu feels like it's there to be there. Something I've noticed increasingly is that, often, users (power- or otherwise) don't always know which top level menu item contains the sub-item their looking for. Typically it's a visual relationship and not a semantic one.
    – tksb
    Commented Jul 29, 2011 at 18:13

I would say stick with convention.

Without knowing what a Project/Sequence/Object is, I find the conventional one automatically familiar and I could have a good guess at what to do first - File > New > Project.

In your domain-specific version it seems strange that New Project is not under Project. If I wanted to create a project I would first click on Project, I wouldn't assume that its under Designer.

Also to me it looks ugly to have the 'New' word appended to everything, not that you have any other choice with the layout.

So if you want to stick with the domain-specific, I would:

  1. Remove the Designer menu
  2. Add an Object menu
  3. Put all the Project menu items in the Project menu etc.
  4. Put Preferences under the Edit menu

If you want to stick with the Conventional one, preferences should go under the Edit menu - that's a fairly standard linux convention.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.