A great topic - one I've given a lot of thought to. Here's some things
A menu bar is basically a way to group all the commands for an
application together under one umbrella. Finding commands under a menu
bar would ordinarily be hard, but there are conventions about where
commands can be found. File menu contains stuff related to the file,
Edit menu contains cut, copy, paste, and stuff like that, View menu
pertains to the view, etc. These conventions are an essential part of
what makes desktop applications work - it's how users know where to
And yet I'm sure you have heard of or used card sorting exercises where
we try to get users to tell us where in the menu bar a command should
live - the ugly truth is that there is a LOT of ambiguity for menus and
that users often have a lot of trouble finding commands in the menu
bar. The evidence I have seen is that users rely on the conventions for
the common commands, then just try to memorize where the uncommon
commands go... usually with a lot of errors, resulting in a lot of
opening and closing menus. Engineers, whose minds are highly organized,
usually have no trouble remembering most of the commands in a menu and
where they are located. Users are not so lucky.
The on the desktop we developed ways to cope with this - we have
keyboard accelerators, we have contextual (right mouse) menus that only
bring up commands specific to the selected object. These are all to
prop up this rather weak UI widget.
The bad thing about web application in general (and perhaps yours) is
that they don't really use the conventions; File and Edit just don't
apply to most web applications... So whatever conventions the user was
leaning on before are usually gone, which leaves the user having to
memorize the location of all the commands. With poor results.
I see a growing movement away from this kind of atomic command
interface to a more task based interfaces. This movement is being
driven by desktop applications. Web application UI design is so
different (task based, contextual) from the desktop that it's affecting
desktop application design. As evidence of this, bring up some of
Google Images pictures for "Longhorn", the next release of WIndows and
you will see context sensitive task based commands everywhere. But yes,
the menu bars are there too, although Microsoft has made it clear that
they don't expect most of the users to use them much. Microsoft has
even dubbed this task based design "Inductive User Interface" design,
and they have a number of documents about it on their web site (and
there has been some discussion about it here too).
> Robert's arguments:
> -We need the menus because the user can find all the functions in a
> structured way. Users are familiar with these menus in desktop
> applications. They should find the same thing in the web app.
IF (and it's a big IF) your web application has a command structure
that is largely similar to other desktop applications and to menu bars
your users have seen before, then it is true that a user can leverage
this knowledge. Otherwise, as I said, the user must memorize a
completely new menu bar structure in order to be able to make use of
Web applications are NOT "desktop applications in a browser". Their
designs are fundamentally different - most web applications look
nothing like desktop applications. Robert may find himself flying in
the face of convention for web applications by doing this.
One note: Depending on your users, the application, and the general
environment, your users may expect it to be "exactly like the desktop"
in how it looks AND how it feels, which can be difficult to achieve.
You may find that you need to implement a menu bar that shares VERY
similar interaction styles to the desktop; time to open the menu, the
submenus, the cascading of menus should be the same.
> -We can't just put icons/buttons here and there and rely on users to
> find them. If we have menus, users will find them in one place.
If your task flow is good, you should be able to provide the user with
the commands he needs WHEN he needs them, no more, no less. He'll find
them because all the other clutter is gone.
> -Redundant menus are good things. The desktop applications provide
> both shortcuts and menus.
Desktop apps and web apps aren't apples to apples.
> My points:
> -Users are not working with files on a desktop. They use the system
> to get information and solve problems. The file menus are no longer
More to the point, as I said above, what users know about the menu bar
> -We do need menus for navigating in the system but not Files, Edit,
Navigation menus are common and helpful in web applications. They do
not exist at all in desktop applications. More proof that the two
environments are not directly comparable.
> -Actions should be placed closer to the object the user is
> manipulating. The menu structure in the desktop application groups
> all the functions for all objects. The menu is too heavy. You don't
> know what function can be applied to what object.
This is a key usability weakness of desktop menu bars that seriously
affects their usability.
> -If you can clearly position the action buttons to the objects, users
> will find them. You don't need redundant menus for functions.
> Redundant menus make the screen clutter.
The only argument I don't buy is the clutter - menu bars are small, so
they're not much visual clutter. But they are significant cognitive
clutter. I'll give you an analogy that Robert might like: I've worked
with many people who feel that a command is too hidden, so they suggest
we add a button to it. And then they worry that users will miss the
button, so we add some help text and maybe a link to it. At the same
time he worries that the task flows we have aren't right - maybe if the
user is here he'll want to do this too! Soon, the page is littered with
commands, some redundant, some not, some very important, some not so
The analogy I give is this: When you overload the dishwasher, it's not
that the extra 3 things you added at the end don't get clean - NONE of
the dishes get clean. When a UI has extra commands, duplicate commands,
rarely used commands, etc. the user cannot discern the "extras" from
the "necessary" commands. The result for the user isn't just that the
extra commands are confusing - ALL the commands are confusing.
Finally, I am sympathetic with Robert. Engineering is about edge cases.
Their whole world is "what if 1% of the users do this" - they have to
worry about those issues all the time to write excellent code. UI
Design is about the 75% case. If you know 75% of the users want to do
something, design for that. The other 25% may be unhappy, but they'll
probably get by.
Hope this helps - that's my $0.02.
Two Rivers Consulting Corporation
[log in to unmask]
Tip of the Day: Use the archives to research common questions
CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html