Access points for context sensitive help

16 Apr 2004 - 9:12am
9 years ago
7 replies
670 reads
Navneet Nair
2004

With our next release of our web based software we are planning to incorporate
context sensitive help as part of the application. Currently the help is
accessed from a drop-down Help menu that has a link to the ‘Contents and
Index.’ This of course, opens the help with the TOC and the default welcome
page. As per the current implementation, the context sensitive help can be
accessed by using the F1 key which opens the help related to the page the user
is accessing in a window without the index and TOC. There is no other link to
the context sensetive help.

What would be the ideal access point for help? I’ve noticed Lotus Notes has two
links in the help menu. One takes you to the ‘Help Topics’ and the other
opens ‘Context Help,’ but I’ve not noticed this variation in a lot of other
applications. Usually the F1 key does the job of context sensitivity with no
link separate link in the Menu.

Are there any patterns or conventions in this respect?

TIA
Navneet

PS: Apologies for cross posting on CHI-WEB but I need to get the interactions
speced for this feature over the weekend :(

Navneet Nair
Interaction Architect
http://www.onclipevent.com
form follows function();
Blog: http://www.onclipevent.com/enterframe/

Comments

17 Apr 2004 - 7:13am
pabini
2004

Hi Navneet

Please see my responses below...

Pabini Gabriel-Petit
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

Navneet Nair wrote:
With our next release of our web based software we are planning to
incorporate
> context sensitive help as part of the application. Currently the help is
> accessed from a drop-down Help menu that has a link to the 'Contents and
> Index.' This of course, opens the help with the TOC and the default
welcome
> page. As per the current implementation, the context sensitive help can be
> accessed by using the F1 key which opens the help related to the page the
user
> is accessing in a window without the index and TOC. There is no other link
to
> the context sensetive help.

***[PGP] When you say "web based software", so you mean HTML based or native
binary? How context-sensitive is your help? Does it cover an entire page or
window or single options? Sounds like it may be the former. If so, why not
add an option to the Help menu?

Help for This Page

If not, use an option appropriate for a window. What else is in that menu?

> What would be the ideal access point for help? I've noticed Lotus Notes
has two
> links in the help menu. One takes you to the 'Help Topics' and the other
> opens 'Context Help,' but I've not noticed this variation in a lot of
other
> applications. Usually the F1 key does the job of context sensitivity with
no
> link separate link in the Menu.

***[PGP] That Lotus Notes implementation is a poor one. It's ungrammatical
and jargon, too. I'd personally never use the F1 key, so would never find
the context-sensitive help. There should always be a visible affordance that
tells users there is context-sensitive help for a Web page or window.

> Are there any patterns or conventions in this respect?

***[PGP] A ? button is a common approach for context-sensitive help.

18 Apr 2004 - 2:53am
alysander stanley
2004

Quick summary: use hyperlinks for "contextual help
access points".

For regular applications, I see a need for at least
two kinds of "help". Guides which walk through the
operation step by step and technical reference which
provides exact details.
How users access this information is very important
and ideally non-command\contextual. For example: if a
user performs a complex operation that involves a
dialog box which they haven't used before, the
appropriate guide could open itself.

"Weblications" are much harder to design as you have
less control of the enviroment (context) and browsers
are inherently inappropriate for applications.
I would concentrate on understanding users, then
design an interface that makes performing their tasks
as straightfoward and practical as possible.

The most obvious place for "help" is on the page, with
whatever features\functions they apply to. But this
can get in the way. The problem with a help menu
(especially in flash) is that it's too out of the way.
Users have to go out of *their* way to use them.
That's if they notice them in the first place.

If you need to include more information than you can
fit on a page, make a link instead. And not like
"Click here for information on this feature" but more
like "What's this?" or better yet "Using XYZ" where
XYZ is the name of your feature\widget.

I think amazon is a good example of this kind of
thing. For more information go to useit.com.

If you're really serious, I'd look at python or java
for a real GUI. Python's easy to learn.

- Alysander

--- Navneet Nair <nav at onclipevent.com> wrote: >
> With our next release of our web based software we
> are planning to incorporate
> context sensitive help as part of the application.
> Currently the help is
> accessed from a drop-down Help menu that has a link
> to the ‘Contents and
> Index.’ This of course, opens the help with the TOC
> and the default welcome
> page. As per the current implementation, the context
> sensitive help can be
> accessed by using the F1 key which opens the help
> related to the page the user
> is accessing in a window without the index and TOC.
> There is no other link to
> the context sensetive help.
>
> What would be the ideal access point for help? I’ve
> noticed Lotus Notes has two
> links in the help menu. One takes you to the ‘Help
> Topics’ and the other
> opens ‘Context Help,’ but I’ve not noticed this
> variation in a lot of other
> applications. Usually the F1 key does the job of
> context sensitivity with no
> link separate link in the Menu.
>
> Are there any patterns or conventions in this
> respect?
>
> TIA
> Navneet
>
> PS: Apologies for cross posting on CHI-WEB but I
> need to get the interactions
> speced for this feature over the weekend :(
>
> Navneet Nair
> Interaction Architect
> http://www.onclipevent.com
> form follows function();
> Blog: http://www.onclipevent.com/enterframe/
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

19 Apr 2004 - 6:03am
pabini
2004

Hello Alysander

You made a lot of good points, but I disagree with you about one thing. You
wrote:

> For example: if a user performs a complex operation that involves a
> dialog box which they haven't used before, the appropriate guide could
open itself.

In my view, a help system should never open itself. Remember how obnoxious
everyone thinks Clippie is. One should always avoid wresting control from
users or interrupting their tasks. I do think it's very helpful to provide a
Help button in a dialog box to display context-sensitive help. Often,
pedagogical information is actually necessary to comprehend the options in a
dialog box, but it's rarely provided. Nor is task-oriented help usually
provided in context. Typically, brief reference help is all that is offered.
For a highly technical operation, that's not enough. It's unbelievable the
level of knowledge help systems sometimes assume.

What exactly did you mean by "ideally non-command\contextual"?

> The most obvious place for "help" is on the page, with
> whatever features\functions they apply to. But this
> can get in the way. The problem with a help menu
> (especially in flash) is that it's too out of the way.
> Users have to go out of *their* way to use them.
> That's if they notice them in the first place.

A few other possibilities are placing any kind of help in a sidebar--either
permanently or displaying different information when a user points to
particular features on a Web page (a remote rollover)--or providing
reference help in large ToolTips. Of course, in the latter two cases, users
must learn how to use the context-sensitive help, so there must be some sort
of visible affordance for the help system.

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

19 Apr 2004 - 2:20pm
Susan Mercer
2004

Hi all -

In our web application, we've provided 3 types of "help". All with
slightly different access points. They've all been requested by our
users and received positive feedback in usability testing on our design
mockups. We'll see what the real customer response to the live
application is when it goes live later this year.

1) We provide a standard help system, accessed from a "(?) Help" option
from the top menu. The (?) is really a graphic of a ? In a circle.
This includes a Table of Contents and Searching capability, and is
arranged around business tasks.

2) For some trickier pages, we provide a "(?) Help on this page"
option. It appears at the bottom of the top navigation system, and to
the far right. It's geared toward the occasional user coming back to a
complex page 1-2 months after training or their last project. They just
need a quick refresher, and they're ready to go.

3) Context-sensitive help/definitions. On some of our pages, we have
some field names that are non-user friendly and a bit "techy". We have
quite a mix of audiences from novices to experts that have used similar
software for a long time. We made an attempt to use more user-friendly
language for several options, but on several others, we could not
without confusing our advanced users. So, we added a small graphic (?)
after the field label, and added a 1-2 sentence definition/explanation
on mouseover. This received the most positive user feedback in our
usability testing.

I hope this helps.

Regards,
Susan

Susan Mercer
Information Design Team Lead
FreeMarkets, Inc.
FreeMarkets Center
210 Sixth Avenue
Pittsburgh, PA 15222
Email: smercer at freemarkets.com

24 Apr 2004 - 12:40am
alysander stanley
2004

Hello Pabini,

To answer your question:

>What exactly did you mean by "ideally
non-command\contextual?

My definition of "non-command" is based on Jakob
Nielsen's essay:
http://www.useit.com/papers/noncommand.html

I mean that user interfaces can often be simplified if
the device makes use of contextual information. For
example, nearly every dos game has a configuration
program for the sound effects and music. More recent
games can get that information automatically, which
totaly avoids the need to explain DMA and IRQ
channels.
Similarly, webpages can use javascript to detect
screen sizes rather than requiring users to say what
resolution their screen is. If the browser doesn't
support javascript, you can show a simple version
without all those graphics. This means you don't have
to provide help for users that don't know what their
screen size is (most don't).

>"In my view, a help system should never open itself."
So what about those tooltips you were talking about?

But I know what you mean, you're talking about Clippy.
Clippys problem isn't that he magically appears, it's
that he's stupid. Clippy wants to know if you're
opening a document when you open word. Instead, word
should open the documents you were using last time
automatically.
And clippy tries to do too much. He wants to be a
menu, he wants to be a tooltip, he wants to be a
dialog box. But he's the odd one out and has to go.
Which leads us to his other big problem: he doesn't
want to go away.

My help system is different from that.
If you have a user that hasn't used the program much
before and they click on a command which they haven't
used before that involves a complicated dialog box
(like Levels in Photoshop) a help page window opens
next to the dialog box (they're tiled) which simply
describes what the command is for and how to use it.

I expect that most users will skim over it and close
down *both* windows. Except that now they have a fair
idea what the commands for, and maybe even how to use
it. Or that they don't need it.
And they know what to expect when they click on Help.

Dialog boxes can't show that on their own, even with
tooltips.

-Alysander

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

24 Apr 2004 - 1:18am
pabini
2004

Hi Alysander

Alysander Stanley wrote:
> My definition of "non-command" is based on Jakob
> Nielsen's essay:
> http://www.useit.com/papers/noncommand.html
>
> I mean that user interfaces can often be simplified if
> the device makes use of contextual information. ...
> Webpages can use javascript to detect
> screen sizes rather than requiring users to say what
> resolution their screen is. If the browser doesn't
> support javascript, you can show a simple version
> without all those graphics. ...

Thanks for the clarification. Good description. Of course, I'm familiar with
this principle, but I'd never heard that term before. It's not a very aptly
descriptive term.

> Clippys problem isn't that he magically appears, it's
> that he's stupid.

I agree with everything you said about the many ways in which Clippy is
stupid and obnoxious. However, I stand by my original statement that a
help-system window should not appear unless a user requests it, because:

* It distracts users from their work when the window appears. For example,
you may have just figured out exactly what you wanted to write after much
thought and were starting to type. The window opens. Poof! There goes your
mental work.
* The window may obscure part of the user's work.
* The window may require window management on the part of the user.

> My help system is different from that.
> If you have a user that hasn't used the program much
> before and they click on a command which they haven't
> used before that involves a complicated dialog box
> (like Levels in Photoshop) a help page window opens
> next to the dialog box (they're tiled) which simply
> describes what the command is for and how to use it.

Sorry, but I think this sort of assumes ignorance on the user's part. You
cannot know what varied levels of experience your users may bring to the
task of using your application. They may have used other similar
applications and have no difficulty figuring out your product's user
interface. The solution you describe does not have some of the problems that
I mentioned above though and not the most egregious one--the first one.

An alternative would be a Help button in the dialog box that displayed the
context-sensitive information you described in the help-system window.

> I expect that most users will skim over it and close
> down *both* windows.

You should close the help window automatically when the dialog box closes.
Otherwise, this engenders the kind of window-management excess that I
mentioned above.

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

25 Apr 2004 - 12:00am
alysander stanley
2004

I feel like this is getting a bit far from the
original post, but it's an interesting topic.
The real issue is that it's outside the scope of any
individual program.
As Frederick P. Brooks, Jr. wrote in The Mythical
Man-Month, chapter 4: "I will contend that conceptual
integrity is /the/ most important consideration in
system design. It is better to have a system omit
certain anomalous features and improvements, but to
reflect one set of design ideas, than to have one that
contains many good but independent ideas."

I still think it's a good idea, maybe for the next
generation of GUIs.

Hello Pabini,

You're right, non-command isn't an "aptly descriptive
term". Sorry.

>* It distracts users from their work when the window
>appears. For example, you may have just figured out
>exactly what you wanted to write after much thought
>and were starting to type.

This is another issue with clippy, not with my system.
Clippy appears and disappears at any time.
My help window only appears with an unfamiliar and
complicated command's dialog box. It is possible that
a users could click on a menu and a previously unused
option by accident while they were thinking deeply
about what to write, but there's not much you can do
about that.
Another example of badly timed dialog boxes is
Norton's anti-virus program's subscription renewal
reminder. Not funny if you're showing a powerpoint
presentation to an audience.

>* The window may obscure part of the user's work.
>* The window may require window management on the
> part of the user.
Any Help window could have these problems.

> Sorry, but I think this sort of assumes ignorance on
the user's part.
Well, the program could always ask the user if they
were already familiar with the program the first time
they use it.
And is assuming expertise really any better than
assuming ignorance?

> You should close the help window automatically when
> the dialog box closes.
This is just as serious as opening a window
automatically, what if they want to check out a
related command that is referenced in the document?
For example, subtracting from highlights and adding to
shadows in Levels is the same as increasing contrast.

>They may have used other similar applications
> and have no difficulty figuring out your product's
> user interface.

Let's say someone is used to Photoshop 5 and is
experimenting with Paint Shop Pro 5. Paint shop pro
has a similiar command to "Levels" called
"Highlights/Midtones/Shadows" but instead of a
histogram with sliders, it has 3 entry fields where
you type percentages of adjustment. Now, the person
from photoshop probably won't recognize this feature
without some Help.

In fact, even different versions of the same program
are likely to have different implementations of the
same features.

The only situation I can think of where two different
programs are likely to share some complicated features
which are exactly the same is in a suite. Like Adobe
CS.
Programs in a suite could check if you have already
seen the documentation before opening it up for you.

In any case, it's easy to close the window and it
won't happen again without an explicit command.

Thanks for your interest.
- Alysander

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Syndicate content Get the feed