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:
Ted Weatherly <[log in to unmask]>
Reply To:
Ted Weatherly <[log in to unmask]>
Date:
Fri, 15 Oct 2004 10:16:17 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (256 lines)
Thanks for all those who responded to this topic.  Your feedback
definitely helped.  I did some user testing of my own for this study and
found some trends myself.

-=* SUMMARY *=-
--------------------
In summary, there is no definitive answer to which is better: task-based
navigation or topic-based navigation.  Choosing the best approach
depends on several factors:

* Do you expect your users to be experts?  If so, a topic-based
navigation is favored since you can expect experts to interpret the
topic names correctly.  If not, novice users will prefer a task-based
approach that walks them through navigation.
* Are the tasks simple to explain?  Is a topic name sufficient?  If so,
a topic-based approach is better.  Otherwise the task-based approach is
merely asking "manage your <topic>".
* Is the site fast in terms of round-trip response time?  If not,
topic-based navigation is preferred (fewer clicks to access data)
* Does the site address a wide-range of topics?  If so, there may be
real estate issues in trying to present all the necessary tabs and
sub-tabs with a topic-based approach.
* Do you expect users to jump between topics frequently?  If so, a tab
approach is better since a task-based flow assumes a linear progression.

The common consensus is:

* For a task-based icon approach, make sure the task descriptions can be
scanned easily.
* For a task-based icon approach, use simple icons that are easy to
understand
* For a task-based icon approach, limit the number of tasks shown per screen
* For a task-based icon approach, allow an expert user to bypass the
home page and jump directly to a useful page of their choice
* For a topic-based tab approach, anticipate how some topics may be
mis-interpreted and provide crosslinks to "related topics" that would
steer the user toward the appropriate tab
* If possible, allow the user to toggle between the two approaches:
novice-mode and expert-mode

Steve Schang mentioned he uses a combination of both approaches and this
advice was reinforced during my user testing.  I expect users of my web
application to have a range of experience.  Rather than provide a
"novice-mode" and "expert-mode," I plan to initially show the users a
"Home" tab with the tasks listed in the main content area.  Impatient,
expert users can immediately click on a different tab and proceed
according to the topic they deem appropriate.  Cautious and confused
novice users can click the appropriate task in the main content area and
take the longer but more descriptive path.  I plan to use cookies to
allow expert users to designate any page as the "default" (rather than
require them to see the Home page each time).

Thanks for all the feedback!

-Ted

-=* RESPONSES *=-

Mark Singletary
--------------------
If the site is fast I'd use the Icon based approach, it requires more
round-trips, but in my experience users pick it up faster.

One thing to watch for though, if you have a really complicated app the
number of icons and steps can get to be daunting.

Also USE SIMPLE ICONS. Simple outlines 2 or 3 colors. No 16 million
color gifs or artsy creations. Look at the international signage
standards for guidance.

If the application security design permits it, I would also give the
user a cookie containing their "ID-Badge" so they can create their own
saved links into the app past the home page.  This can eliminate extra
clicks for frequent users.  Although this requires some adaptation in
the applications solution to persisting user-state it's not difficult.

Robert Hanson
--------------------
My initial thoughts are: If you define a list of tasks a user might do,
then the user has to map their "name" for the task that they want to
accomplish into the name you've chosen  (quick - what is the name of the
task that is part of most email systems, which lets you recover your
password if you've forgotten it?).  Then the user has to scan the list
of available tasks, and decide if a particular task might mean the same
as what they want to do.

Compare that to a topic-based layout:  clearly, "Mail Filtering" has
nothing to do with password recovery, so I don't need any of the tasks
under that tab.  That might reduce my "possibles" down to a few (those
few that are under a particular tab, like "account information".

What you're really asking is, do I present an uncategoriezed list of
tasks, or a list of tasks broken into categories?

A novice user probably needs categorized lists.  An expert user might
not.  If you associate each "command" with a distinctive icon, then the
user can switch from novice-mode to expert-mode, and still locate the
desired command using an icon.

Robert Hanson
--------------------
One analogy I try to use when I can is that of a "workspace".  Consider
MS Word - you have a workspace (the document) with the controls
scattered around the edge of the page.  With this application, I can
immediately do what it is I want to do (type a document) and worry about
formatting, etc later.

Another example:  most mail clients don't ask first whether you want to
read mail, write mail, clean your inbox, etc.  Normally, they open up
the inbox and retrieve any new mail, so that you're ready to go.

Granted, the web is a little different beast than that, but I think the
concept still holds.  With this in mind, what you'd do is "guess" what
the user is most likely going to want to do when they hit the site
initially; present them with that workspace, and scatter controls to
change the workspace around the edge.  (You can do some tricks, like
bring up the last page the user was on when they return to your site, or
check the weblogs and see which activities are most common)

I guess you can see where I am going:
1) No, don't take up all the real estate with "what do you want to do"
buttons.
2) It's really a poor idea to make the user decide what they want to do
as the *first* thing they have to do on your site.  Let them start doing
something right away, and if it is the wrong thing, then they can switch
to another mode.

David Jacques
--------------------
To me [the two approaches] sound the same, and a question of labelling
and grouping, but you could still consider having the navigation with
shorter labels, like the common navigation, but in the content of the
page, more task-based descriptions.

But on another side I understand your questions. Do you put all
"Filters" in a "Filters" section, or do you put personal mail filters in
the personal setting function and domain filters in the domain settings
section? Good question. Depends on the user. Someone with no domain
admin rights won't see a domain setting anyway. But again maybe it's
possible to do both. Navigation has one thing, and the content can have
shortcuts (with different wording) to most frequent/common actions
depending on which page you're on.

Steve Schang
--------------------
My experience with topic versus task based is that it depends on the
domain experience and expectations of your audience. Generally I have
used a combination of both. The topic based was geared for more advanced
users who were familiar with the domain.

Task based was used to satisfy one of three requirements:
1. A shortcut to the most common tasks in the system.
2. Navigation for more novice users not familiar with the domain.
3. A way to combine multiple smaller tasks into one larger tasks. In
your example a task could be "set up a new account" - that task would
include sub tasks like adding a password, setting spam filters, and
adding mailing lists.

One aspect of using a pure task based navigation is you would have to
ensure that all potential tasks or groups of tasks are represented in
the main navigation. This might get complicated depending on what level
of detail you wanted to represent each task. There are probably dozens
of variations of tasks that users could do.

-=* ORIGINAL POST *=-

Ted Weatherly
--------------------
I am developing a new web application and I'm considering two different
navigation schemes.  The first scheme is topic-based using tabs.  The
second scheme is task-based similar to the control panel in Windows.

Let's suppose this is an email management application.  The layout using
the topic-based tab scheme would look like:


  +----------------------+ +-----------------+ +----------------+
  | >Account Information | |  Mail Filtering | |  Mailing Lists |
-+                      +-+-----------------+-+----------------+-
   Name | >Password |  Permissions
-----------------------------------------------------------------

(Main Content)


With this scheme, a user accomplishes a task by choosing the appropriate
topic tabs.  For example, to change his password the user would first
choose the "Account Information" tab, then the "Password" sub-tab.
While navigating to this page, the user sees the Account Information /
Name page, which is irrelevant to the task he needs to accomplish.

The second navigation scheme I'm considering is task-based, similar to
the Control Panel in Windows XP.  There would be a grid of icons labeled
with task descriptions:


->HOME

+------+            +------+            +------+
| icon |            | icon |            | icon |
|      |            |      |            |      |
+------+            +------+            +------+

Manage your Name,   Manage Mail         Manage
Password, or        Filters and         Mailing List
Permissions         Spam Handling       Subscriptions


Returning to the task above, the user would click the first icon then see:


   _HOME_
->Manage your Name, Password, or Permissions

+------+            +------+            +------+
| icon |            | icon |            | icon |
|      |            |      |            |      |
+------+            +------+            +------+

View/Update         Update your         View/Update your
your Name           Password            Permissions


The user would then click Update your Password and the resulting page
would display:


   _HOME_
   _Manage your Name, Password, or Permissions_
->Update your Password

(Main Content)


Has anyone explored these schemes before?  Here are the usability
advantages/disadvantages that I forsee:

Topic-based (tab) scheme
PRO: User sees sibling/parent content while navigating to the
      appropriate page for his task, allowing him to become
      familiar with the site layout
PRO: Links to sibling and "uncle" content are easily accessible
PRO: Conventional design
CON: Topic names may be vague and mislead the user
CON: Navigation always consumes real-estate on the page, taking
      away space for the main content

Task-based (control panel) scheme
PRO: Navigation is organized in a task-based flow
PRO: Descriptive link labels and icons suggest the appropriate
      route to take
PRO: The user is not presented with main content that's
      irrelevant to his task
CON: Accomplishing a task may take more clicks
CON: User cannot easily envision the "Site Map"

ATOM RSS1 RSS2