SIGIA-L Mail Archives: RE: SIGIA-L: Global nav during a process?
RE: SIGIA-L: Global nav during a process?
From: Budzyn, Mark \(2051\) (Mark.Budzyn_at_esavio.com)
Date: Mon Jul 23 2001 - 14:33:58 EDT
I would love to hear the same thing (comments, experience, thoughts, etc).
We built a system that includes multiple processes, one of which is a long
process to register for a test (involving anywhere from 28-45 pages) and
came across the same issue. The additional issue we had to deal with is if
the user elects to 'leave' the process, all their options as well as the
temporary hold on the seat they selected would be lost.
We chose the option to include the global nav bar. It created some major
coding complications since the process includes integration with many
systems and business rules. I like the idea of keeping the 'web-iness' of
the page, in that a user can click on any link. I'l be honest, the site
been up almost a year and there have been no major issues... so, no news
good news, I guess.
But, on the 'anti-global nav bar' camp I recently was doing some research
Section 508 compliance (US gov't web accessability) and one requirement
'A method shall be provided that permits users to skip repetitive
links'. I read this as a statement against global nav bars. My guess is
this requirement is included for user's with speaking browsers. If you
include a global nav bar on each page, the speaking browser will 'speak'
entire nav bar before getting to the meat of the page. We have planned an
enhancement for the site where a user can set a preference to 'collapse'
nav bar to only two options: home, and 'reveal all'.
Sent: Monday, July 23, 2001 12:59 PM
Subject: SIGIA-L: Global nav during a process?
Hi all -
Here's a thorny problem I've run across many times and now face yet again.
I'd love to hear ideas, opinions, and data.
The question: Should global navigation (in this case, the top levels of
hierarchical nav) appear on the page when the user is within a process
(anything from email newsletter sign-up to search to checkout)?
On one side:
- Reducing "interruptability." If a user is within a transaction, don't
distract them with global nav that isn't relevant to the task. Let them
explicitly cancel the task to return to the non-process state.
- Real estate. Processes like checkout often require more screen real
estate, which global nav can sometimes hog.
On the other side:
- Escape hatch. On the Web, users leave a process not through canceling,
but by simply going somewhere else. Global nav should always be there so
that users have control.
- Consistency. If the global nav appears and disappears throughout the
experience, it's less reliable and learnable, and potentially disorienting
I'm trying to pose the question in a neutral way so as not to reveal my
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:47 EST