[Sigia-l] More on Grayed Out Nav Elements vs. Changing Nav Menu

[Todd R.Warfel]

Context:
- A Web-based application that is open to the "public."
- The application enables users to keep track of species of birds that:
  a) they observe
  b) others observe.
- The application has two main components:
  a) submit your observations (data-in)
  b) view and explore data (allows users to view and explore their 
personal data, or the public data set)

User-base tested:
- 9 people
- age range 14-65
- education levels of middle school to PhD
- participants were novice to advanced birders
- none of the participants had used a Web-based application to keep 
track of their observations before, but some had used traditional 
applications to do this (note: no other Web-based application like this 
currently exists - it's the first of its kind).
- most participants use the Web between 10-25hrs a week (including 
email and Web surfing)
- mixture of Mac and Windows use

The main component I was speaking about earlier was the mapping tool. 
This tool is used for both data-in/out. The functionality of the tool 
as well as the interface are adapted appropriately based on the task at 
hand (e.g. data-in/out).

For data in, the mapping tool allows users to pinpoint their location 
with a 3 meter radius through the use of street maps, topo maps, and 
aerial photos. The current mapping tool is HTML/JSP/Java based (not an 
applet) and functions similarly to Yahoo!, Rand McNally, etc. Users can 
pan, zoom in/out, etc. The main exception is that we're providing three 
different types of maps and allowing the user to store this location 
based on a name they provide for future use.

We've tested several iterations of this map. And while we've got a 
little something up our sleeve for the next release that will improve 
usability and the overall mapping experience, the current version is 
strides ahead of previously existing models.

With regards to the "show/hide" vs. grayed out navigation rules - in 
the context of this application, we tried both for a setup something 
like:

street map | topo map | aerial photo
===========================
|									|
|									|
|									|
|			map image				|
|									|
|									|
|									|
===========================

 From here, we tested maintaining the three navigation elements at the 
top (which are text-based navigation elements) and graying out those 
which were not available. So, if there was no top map available, the 
"topo map" item would be grayed out. Even though it was grayed out, 
users till persisted to click on it. They didn't seem to be able to map 
this convention to a Web-based application - a convention that is 
widely used in typical software applications. This created a point of 
frustration from users. Several users even commented that if it wasn't 
there we simply shouldn't show it.

Conversely, when the item that was not available was simply hidden, 
then users expressed a lower frustration rate with the application. To 
our surprise, users neither commented nor showed through their actions 
that hiding options that became unavailable was confusing. Not only did 
they appear not to have problems with this model, but it appeared to be 
more intuitive to them. There wasn't any question as to whether 
something would work or not. If it wasn't there, it wasn't an option. 
Take the guess-work out.

This goes back to the belief that occasionally, we need to protect the 
user from themselves.

For something like Documentum, or an enterprise level application where 
users are expected to "learn" how the application works, or traditional 
software applications, I'm in favor of, and believe that the best 
solution is to keep the navigation menus consistent in length and 
appearance while using a grayed out model. This is mostly due to basing 
current functionality on users' previous knowledge - build on existing 
knowledge. Additionally, in the less-personalized office arena, this 
seems to be more acceptable and users tend to expect this.

However, from our experience, in something that's abstracted like the 
Web-based application described above, we've found that sometimes 
show/hide is more appropriate. There are other times this is 
appropriate, as David pointed out - business user vs. administrative 
user interfaces - show what's appropriate.


On Monday, April 21, 2003, at 03:48 PM, Dan Saffer wrote:

> Todd, I'd be interested to hear any more detail you can give us about
> your user testing on this.
>
> Aside from menu location, I think the other main argument for having
> items remain grayed out is that it shows affordance: i.e. If the 
> context
> was different (or you were in a different mode), you could do X.
>
> Dan

Cheers!

Todd R. Warfel

_//message first [method second]
-=========================-
User Experience Architect
Cornell University Lab of Ornithology
[P] (607) 254-2477
[F] (607) 254-2415
[E] todd.warfel at cornell.edu
-=========================-

In theory, theory and practice are the same,
but in practice, they're not.

The only thing necessary for evil to exist in the world is for good men 
to do nothing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2203 bytes
Desc: not available
Url : http://mail.asis.org/mailman/private/sigia-l/attachments/20030421/7648bc9c/attachment.bin