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:
Hal Shubin <[log in to unmask]>
Reply To:
Hal Shubin <[log in to unmask]>
Date:
Thu, 3 Oct 2002 11:39:21 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (248 lines)
I asked this question and promised to submit a summary of results:

>How easy is it to train people to use the right-mouse menu (aka MB2 menu or
>context menu)?
>
>I'm helping a client develop software for clerical people to use. They'll
>include training with the product because the users aren't all comfortable
>with computers. (They said it starts with "This is a mouse...", but perhaps
>not literally.)
>
>The application is a Web-enabled one that runs in a stripped-down browser
>(no browser menu bar, tool bar, etc).
>
>To save time, they want to put many features on the context menu. I
>suggested creating a menu bar or tool bar of some sort for these commands,
>but they don't want to do that because it will take an extra click or two,
>or involve moving the mouse across the screen. I always allow for a context
>menu, but only as a redundant way to get to some of the items on the main
>menu bar. They don't seems to want to have the menu bar at all.  ...


Here are the responses. Thanks to all for your good comments:


=====
From: Ethan McKinney <[log in to unmask]>

Interesting question. If people are complete novices, why should it be any
harder to teach them, "right-click the object you want to manipulate,
select an option" rather than "click the object you want to manipulate,
make you you successfully selected it, go up to the menu bar, pull down the
menu containing the command you want, select that command, lather, rinse,
repeat" (obviously a little shorter if you have a toolbar)?

The advantage of the context menu is that it makes the whole system more
object-oriented. The "controls" for a device are associated with that
device rather than with the system as a whole.
E
=====
From: Wade Armstrong <[log in to unmask]>

I have anecdotal evidence:

A few years ago I moved from a Mac-using company to a PC-using company with
a number of my co-workers. I had had IT responsibilities at the Mac company,
but not at the PC one; however, because I had earlier had these
responsibilities, I took the lead in training my co-workers in using PCs.
None had ever used anything besides a Mac, and all learned to right-click
within a few days. Training was quite simple, just spending a few minutes a
few times a day doing specific tasks. All users have become quite enamored
of right-clicking and use it consistently.

In addition I should note that, throughout Windows, certain functions are
only available from contextual menus.

I can't imagine why your client would want certain functions *only* in
contextual menus. I can see why contextual menus would be a good idea - from
your description, this application sounds like a perfect example of a time
when an interface designed for frequent users will earn a big payoff over an
interface with a comfortable learning curve.

Wade
=====
From: "Butler, Darrell L." <[log in to unmask]>

Given your circumstances, I would think people would have few problems
learning to use the right mouse button for the tasks you have in mind.  Mac
users may have too much experience with the Mac interface and they would
have some unlearning to do and that would slow them down.  Windows users
(the majority of experienced users) should have much less trouble.  I have
successful done similar things this university students.  However, if you
sample is really different from university students, then I am less sure.

Regardless of the sample, I recommend a way for people to check their
memory against your "help" system.  This is just a good policy and has
worked well in many situations.

Darrell Butler, prof
Ball State Univ.
=====
From: "Malecek, Patrick" <[log in to unmask]>

sounds to me like you have a great opportunity to employ this tool (the
right button) because the users are all going to receive training. In other
words, you don't have to count on them stumbling across this feature on
their own (or having the notion of reading the documentation or help file).

Sounds like you also have a standard platform so you don't have to worry
about Mac mice and other hardware differences.

The only things I can think of are A: what does this mean for left-handed
users? (Stupid question maybe, but is the experience the same for them?)
and B: you can't necessarily rely on hands-on training for FUTURE users of
the app.

good luck!
=====
From: Richard Gaskin <[log in to unmask]>

While I'm not aware of research on this issue, the Human Interface
Guidelines for both Windows and Mac OS are unambiguous in their support of
your position:

Win HIG
-------
Avoid using a shortcut menu as the only way for a user to access a
particular operation. At the same time, the items on a shortcut menu need
not be limited only to commands that are included in drop-down menus. For
example, you can include frequently used commands typically found in a
secondary window, such as a specific property setting.
<http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/dnwue/html/ch08b.asp>

Mac HIG
-------
Never provide a contextual menu command that is not also accessible through
the menu bar. Use submenus with caution and keep them to one level.
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A HIG
Menus/Contextual_Menus.html>


If the user has extensive experience with Windows you might be able to get
away with having commands in a contextual menu that are not available
elsewhere.  But if the ser is relatively new to computing, or has experience
only with Mac OS, I would suspect such features risk being overlooked
altogether.
=====

From: "Raz, Behrang" <[log in to unmask]>
We were faced with the same challenge as well.  I know of one web
application that uses context as the only way to perform certain functions
and the application is quite successful.  However, *all* of the users of
this application are trained Web/HTML developers.  Our customers, however,
are not net savvy and even though we train them, we've realized that the
context menu has to be a redundant source (even if means clicking on a tiny
arrow next to objects to open the context menu.)

We also found that we can minimize the wasted time by trapping keyboard keys
and allowing users to use key commands to activate commands and menus.  The
time it takes for the user's hand to trip between the keyboard and mouse in
my opinion is very costly and increases load on users.

Hope this helps,

Behr Raz,
Software Architect,
Canadian Bearings Ltd
=====
From: Cliff Anderson <[log in to unmask]>

I agree w/ you about context menus, but if you're forced to use them, I do
have some anecdotal (but pretty strong) evidence for you.  (And I'm also
making the assumption that the issue is the lefty/righty one, though I
might be wrong.)  I've tested 100 people in the last year.  I typically
just put the mouse pad and mouse on the right side.  In that time, I've
only had one person move it over to the left.  I've had a couple of lefties
comment on it, but they all pretty much said that they use their right hand
for mousing anyway - no big deal.  These were not totally unsophisticated
users like you seem to be dealing with, however.

Cliff Anderson | Usability Engineer | Wachovia Corp.
=====
From: "Breedvelt, Ilse" <[log in to unmask]>

You might consider even using the left-mouse to invoke the menu instead of
the right-mouse, especially for the users you describe. You can do that by
placing an icon in front or after the object and if the user hovers over the
icon, the icon highlights. This gives the user an indication they can click
on it. If they click on this icon, the contextual menu will appear. The icon
might be a dropdown arrow.

I hope this helps,


Ilse Breedvelt
Senior User Interface Designer
User Experience Team - Interaction Design
Cognos Incorporated
=====
From: "Jensen, Julie" <[log in to unmask]>

Yes, I have seen this. And, your client makes a very strong point. We
currently have keyboard shortcuts and/or right mouse clicks for browser
menus and clicks. But, they are redundant to visible options. People
typically rely upon the options until they get used to the system and then
they rely solely on the keyboard/right mouse clicks.

What is the turnover rate at your client's office? If it's high, I'd
recommend against restricting the functionality only to right mouse
clicking. If it's low, your users will likely demand shortcuts of one sort
or another eventually.

Your usability testing will be interesting. I suspect that initially the
right mouse button won't work very well. You'll need to follow up once the
users have climbed over (and beyond!) that learning curve. Could be
difficult to control your variables.

Good luck,

Julie
=====
From: "Chang, Roger" <[log in to unmask]>

         In my experience, users in web applications will resort to
right-click when there is confusion, especially when the toolbars and menus
have been turned off the browser.

         It could be that users retry the same learned strategies from
traditional client-server applications even in the context of a browser,
especially when the application is positioned visually as a client-server
application.

         One downside is that the users expectation of the feature, once
learned, is that they can invoke a context menu ubiquitously against all
objects in the application.

         The other downside, though one I have witnessed less frequently, is
that some users have gotten used to the right-click to perform
browser-specific functions and would rather still be able to access these,
especially if the browser toolbar and menus are turned off.

         However, should you be able to provide an alternate "Back" and
"Print" facility within the application, the benefits of taking over the
right-click menu may out-weigh the cost of lost browser functionality from
the context menu.

         Roger.

Roger Chang
Senior User Interaction Designer
User Experience Design Team
Internal URI:  http://ui/
Cognos Incorporated
(613) 738-1338 x3471

______
Hal Shubin
Interaction Design (www.user.com)
Design & strategy for the Web
617 489 6595

    --------------------------------------------------------------
    Tip of the Day: Quote only what you need from earlier postings
     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