CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Hagan Rivers <[log in to unmask]>
Reply To:
Hagan Rivers <[log in to unmask]>
Date:
Fri, 4 Mar 2005 15:26:31 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (158 lines)
Cindy --

A great topic - one I've given a lot of thought to. Here's some things 
to consider:

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 
find commands.

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 
it.

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 
> applicable.

More to the point, as I said above, what users know about the menu bar 
disappears.

> -We do need menus for navigating in the system but not Files, Edit, 
> View.

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 
important.

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.

--
   Hagan Rivers
_____________________________________
   Two Rivers Consulting Corporation
   [log in to unmask]
   www.tworivers.com
   978.352.2585 voice
   815.301.6724 fax
_____________________________________

    --------------------------------------------------------------
    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
    --------------------------------------------------------------

ATOM RSS1 RSS2