Re: Navigating an application

>On Thu, 28 Sep 2000, Wendy A Chisholm wrote:
>
>  We say that "navigation mechanisms should be provided for a page or 
>  site".  I've added the word "application" to that.  In an application,
this 
>  is a menu bar, right?  However, do you "navigate" an application?  or do 
>  you just use it?

Just to be clear; in Web applications 'this' is not usually a menu bar.
The full screen is used to create a functional equivalent for what in a
Microsoft Windows 3.1 application would have been a menu bar.  The "Web
pages" which make up a Web application are a cross between menu bar and
dialog box.  But read on.

There is a plain English meaning for "navigating the application."  This
raises the image of a slalom run or maze.  People can and do have trouble
with this.

On the other hand, the recognition value as plain English breaks down if we
stretch the metaphor to the point of referring to what we do to fix these
problems as "navigation aids."  So, no; I don't think that just saying
"include navigation aids for your web applications" will communicate what
people designing web applications need to do.

I am afraid we need to drop back and look a little deeper for a) what
really needs to get done, and b) what would work for both authors and
users, including, if necessary or particularly helpful, mechanisms that
require changing the formats or protocol definitions a bit.

One of the messages that I have cached to bring back (in a round of HTML
reform discussions that is about to hit you) is the message where the
designer is saying "Of course we need onMouseOver actions; they are so
helpful, particularly in navigation."  My take on this is that she is onto
something valid in HCI and useful in web usability.  So we need to find out
what these onMouseOver scripts are doing, and why they add value when used.
 Of course my ultimate objective is to change the implementation of this
helpful function to something that is easier for everyone to use, not just
the 'blindless' as William would say.

My suspicion is that what these scripts may be doing is adding an extra
layer of explanation to 'where you will go if you follow this link' just in
time as the user is poised to follow that link.  This does not expend
scarce screen real estate for a static display of the full, potentially
boring explanation.  But it gets the extra level of understanding to those
who may not be following the cryptic iconography and language that is there
all the time on the button or navigation control when it is just sitting
there among many others in your peripheral vision.


The generic requirement that I am coming up with is that all objects
presented to the user (especially active objects a.k.a. controls) should
understand and be able to respond to a 'whazzat?' query.  [Spelled "What is
that?" in orthodox international English]  The response to this query is an
expanded explanation.  This idea of interactively controlled level of
detail in the explanation of elements in the user interface is what I guess
the onMouseOver scripts are an example of.  It is one of the ways of making
an interface more universally usable.

The point is that the pattern of current practice on the Web has already
learned that jumping into a wholly different context in a Help file, even
if the jump is context sensitive, is not as helpful to real users as an
expanded explanation that incorporates the particulars of this specific
widget instance.  We need to learn this, too.  There is a pattern of
practice in providing explanations which are accessible to those who need
them and not in the way of those who don't.  We need to figure out what
characterizes an effective version of this pattern of practice, and promote
that pattern of practice among Web application designers.  

Users need help understanding what controls do, immediately and in the
context of their overall objectives in using the application.  If this is
available, they will navigate web applications with sure feet.

To the extent that the application is organized in a spatial metaphor that
the user can comprehend and mentally keep their place in, the assistance
can be called 'navigation aids' without losing your audience.  On the other
hand, this is rarely the full gamut of interface functionality in the Web
Aps that need to be covered with comprehension assistance in order to have
real users navigate the Ap with no trouble.

To "eat my own dog food," as it were:  The instruction to "provide
navigation aids for your Web applications" is or is not be a correct
guideline depending on what  expanded explanation we give for the term
"navigation aids."  And, by the way, I think that this term is not
sufficiently mnemonic or suggestive of the correct expansion in this
context to be a good choice of terminology.

Al

PS:  Theory annex; more, rough

Charles did pretty well.

Yes, what you hear, if you listen, is "People aren't designing Web
documents, they're designing Web applications."

So what do they mean by that?  The fact that they contain scripts?  No.

Applications are distinguished from documents by the range of things that
they let you do.  Order pizza.  Send chocolates to your husband (expensive
chocolates) because you extended your business trip another day and won't
be home for your anniversary.  Stuff like that.

Within applications, navigation is required if controls are spread around
in some sort of a virtual space and to use the control you have to "go to
it."  This is not an absolute requirement, but a mechanism using a spatial
metaphor for intermediate methods that is common.  Given that that is how
most web-based applications are organized, the user has to be able to move
through each tableau in the process

Hypertext is a kind of application where there are two things you can do:
reading and moving around in a space where lots of stuff you might read is
spread around.  The latter we call navigating.  The desired outcome is
finding some information.  It takes some reading to get value out of this
process.  But controlling where you are reading by navigating through the
hyper-linked corpus of readable stuff on the Web increases the value you
get out per time put in.  At least that is the theory.  Until you get
addicted and the time is still going in long after the info you are looking
at is no longer interesting, or for that matter being retained...


So, as Charles said, navigation is a class of method.  

The spaces of other applications have other methods.

In control theory where I was schooled, there is always a space that you
are navigating.  This is what theory does, is adds spaces into which you
can paint views of a given situation.  

The spaces relate to where you might want to get.  The controls relate to
the incremental steps in how you can get there.  That is why control
theorists talk about the controls in the user interface as living in the
"tangent space" of the "carrier manifold" of all feasible tragectories.
The controls live locally in a neighborhood of "one step at a time."

In applications, however, to figure out what the requirements really are,
one has to drop back and notice a distinction that is brought out in the
EITAAC documents: not all paths through the application have to be
available without X or without Y; but for every "without X" condition there
has to be a path through the application that gets to any desirable outcome
that is reachable by using the application.  This is ar recognition that
usually applications take multiple steps to get you to the kind of outcome
that you wanted.  So in terms of basic requirements, the navigation that is
required is that there has to be a way to get anywhere that might be the
answer to 'where do you want to get today?'

For the controls in an application, there are requirements that you be able
to discover, comprehend, isolate/engage, and operate these controls.  In
fact you don't have to be able to do this with all of them.  Only enough of
them to render the state space of the actual application (where the
outcomes live) controllable.  Consider the combination boxes where there
are list-picks that pre-load a text answer in the text entry field, and the
opportunity to type directly into the line, as when picking a file in the
file system browse action in Windows.  Remember the File Manager?  Well it
lives on in methods used to select a file.  The outcome is selecting a
file.  Not filling in a file name or clicking on a name in a list.  Those
are means to the same end.

But unless the users of the web application are going to virtualize what
they are doing as moving through a space, it is highly risky to talk to the
experience designers in terms of 'navigation aids' when what you mean is
that the user needs access to a little help sometimes so they can
understand how to use the Ap. 


There is not necessarily a requirement that you be able to "navigate"
among the controls of an application unless there is some sort of a
friendly-to-you conceptual space that they can be viewed as arranged in.
And space is used as the control variable that governs which one you are
engaged with, when your command symbol space (a.k.a. keystrokes etc.) is
overloaded, and is not specific to actual verbs until some control is
isolated and engaged.  Now, for many user interfaces there is such; even if
it is just 'list.'  In fact, the menu bar is a folding and unfolding
version of a hierarchical list of verbs.  But the context menu offers
another way to reach the same verbs, using a different view or approach
path.  Consider a voice interface where you have multiple agents at your
command.  Before issuing a command, you name the agent you want to carry
out that command for you.  You don't think of this as navigating among your
agents, because you don't think of them as in particular places in your
virtual environment.  Their names distinguish them and you don't have to
imagine where they are hovering waiting to carry out your every wish.  "In
earshot" is localization enough, and they all share that description.  This
is not future stuff.  In unix you have these agents.  Their names are
'nice' and 'cron' and the like.  You can give the same job to either one.

We are very familiar with spatial metaphors being used to perform the
isolation of a particular control we wish to exercise.  But that is not
necessarily the case.
Navigation is a form of control that is useful when there is a
virtual-space metaphor that the user can remember, to eliminate some
otherwise repetitive communication. 

Do you consider auto-complete in tcsh to be a navigation aid?  It helps you
navigate the space of available commands.

Yes, in interactive web pages one needs to be able to navigate the "page"
because it is a compound control widget; and the response of the system
depends on the state of the focus.  So you need to be able to "move" the
focus as part of exercising the compound control widget.

Do I make myself unclear?

We had an interesting conversation on the UA list on Tuesday.  I started
running on about Kynn's five-box description of the W3C home page -- and a
lot of other pages.  "On the left you have a navbar leading to points in
the vicinity of the current page, and on the right you have a sidebar
containing a particularly featured bit of content.  Mickey Quenzer said
"but of course, in our eyes-free world, we don't have the information of
what is on the left and on the right.  It all comes through linearly."
What I didn't say was "I'm not really trying to make the left and right
available, because those are but a mechanism.  I want the markup to
identify the navbar and the sidebar.  The screen reader needs to be able to
isolate on and read the sidebar without having other text interposed.  But
for the purposes of selecting what to read, the fact that it is a sidebar
or perhaps its headline, if it has one, is probably more germane than the
fact that in the layout it was on the right.  In fact, it might be more
interesting for Mickey to know the z-axis of the layout, if the featured
items would have a high z-index, than the x and y coordinates.  And the
visual user gets by ignoring the z-axis.


At 01:03 PM 2000-09-28 -0400, Charles McCathieNevile wrote:
>What you do, in a page, a web site, an application, is move around a set of
>controls. For a web page they are a very small set (often "follow this
>link" is the only one. My WAP browser doesn't even guarantte a back button,
>although I find that very frustrating).
>
>For a typical application, there are a number of different types of control,
>(i.e. they do different things) but there may not be as many of each type.
>
>More or less any application could be structured as a website, but in the
>real world it may become very unwieldy, which is one reason why it doesn't
>always happen. Likewise more or less any website could be presented as an
>application - this is more or less what happens in the case of an interactive
>flash or director application for example.
>
>So whether you "use" or "navigate" something is largely a question of
>perspective and fine shades of meaning - fine enough that they will often get
>lost in common usage.
>
>My 2 cents worth anyway. I have borrowed some from Al Gilman, but I don't
>know if I said what he meant, so don't blame him if it doesn't make
>sense. <grin/>
>
>cheers
>
>Charles
>
>
>On Thu, 28 Sep 2000, Wendy A Chisholm wrote:
>
>  We say that "navigation mechanisms should be provided for a page or 
>  site".  I've added the word "application" to that.  In an application,
this 
>  is a menu bar, right?  However, do you "navigate" an application?  or do 
>  you just use it?
>  --
>  wendy a chisholm
>  world wide web consortium
>  web accessibility initiative
>  madison, wi usa
>  tel: +1 608 663 6346
>  /--
>  
>
>-- 
>Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
>W3C Web Accessibility Initiative                      http://www.w3.org/WAI
>Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
>September - November 2000: 
>W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
France
>

Received on Sunday, 1 October 2000 10:59:20 UTC