I'm using the DevExpress suite. They recently released their ribbon control, which allows me to add the ribbon menu/toolbar thingy like the one that will appear in Office 2007.
I've watched the Office demos and the thing is very impressive. So much so that I began to play around with how I could use it for my application. But the one thing that I couldn't figure out is how to organize my menu into the ribbon paradigm.
Then I came across the statement in the DevExpress newsgroups by one of their team that the ribbon control is not meant for MDI applications. Suddenly, the reason for my struggles all made sense.
In Word, 90% of what would be on the ribbon control is functionality for manipulating the document currently displayed. In a typical MDI enterprise application, 90% of the menu and toolbar control is simply for navigating the application. The functional buttons for a particular crud form are really limited to the basic crud operations - add/delete/save/undo. So the paradigm of grouping the functionality relative to an edit form into groups in the ribbon control just breaks down.
Ok, so the ribbon control is out. But that got me really thinking about menus and toolbars in general. I've never been a big fan of merged menus and toolbars in an MDI application... I just can't see how that is as intuitive to the user as my current approach which is:
This seems like the most obvious and intuitive thing to me for the user... I person with no training whatsoever would understand the first time they opened a form that the "Save" button on that form is what you use to save the Customer you just edited.
I welcome your thoughts.
Hi, Dan.
Looks like 45 people have viewed this and no comments yet.
My take is that everyone agrees. It' heartening to feel that there is so much agreement in this community on the topic. But if your intent was to reallyl generate the discussion... well, a little disappointing, eh?
My own view? I agree, too. KISS.
my two cents ....
At my previous company I worked with a lot of web designers and Information Architects. Obviously most of their input regarding menus and actions are based on web sites, but I really like the reasons and easiness of it.
a web site has global navigation which takes you around the different sections (home, about, projects, client login, etc ...) each section then has its own set of actions/navigation. it is important to visually differentiate these types of navigation, by colour, positioning on the forms, buttons, fonts, you name it. actionable items (like uploading a file) has the button next to the place of relevance, and not on a menu.
They also stressed that a user should not be inundated with options. usually the max is around 7. more than that can become "information overload" and the user can forget why they are on a page, and what they have to do.
this has carried over into my win apps very much the way you suggest in the original post. the menu is basically just for navigation and each form has its own buttons specific to that form. we follow something similar to the XP style of explorer, where there's the "grouped" buttons on the left hand side with a caption for the group ("file tasks", etc ...).
most applications i'm involved with are workflow based and hence the user must know why they are on a form, have the info/tools on the form to do what they need to do and then leave when they are done.
i haven't been involved in writing a "workspace" type application where you basically work on one thing that's not MDI, like Word and Photoshop.
I've seen "the ribbon" and used it during training. For the purposes of Word, Excel, etc, it's totally amazing and very productive. especially the preview of some of the buttons.
It's always interesting to see how MS evolves their menus and user experience, and how that trickles down to the apps we build. also to see how it trickles down in their own applications. i wonder if "the ribbon" will work well with VS2005?
Daniel
Copyright (c) Marimer LLC