Techniques for 2.1

At 05:26 PM 2000-04-19 -0500, Jon Gunderson wrote:

>Time: 2:00 pm to 3:30 pm Eastern Standard Time, USA

AG::

Suspected typographical error -- I presume you do mean Eastern Daylight Time.
>
>    8.PR#207: Interpretation checkpoint 2.1
>      http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#207
>

The idea of a source view has clouded this discussion.

Let me introduce some ideas about other, better techniques (that are just
as easy).

Technique #1:

Anywhere one can issue a "where am I?" request, one can also ask "Whazzat?"
 This is a colloquial grunt for "what is this current item?"  This request
can be issued in case the description in response to "Where am I" was not
clear, or if the user just wants to have a description of what is before
them, as opposed to what is around them.

This would result in some combination of 
a) the TITLE attribute of the currently-at element
b) the role of this element (e.g. header, OPTGROUP label) for elements
whose function is dominated by such a role.
c) or [a derivative of] the element type and initial contents for vanilla
elements like paragraphs and list items.  I say "optionally a derivative
of" because the best current practice is to say "link" rather than "<a>
element" when one encounters an <a> element. 

This is a summary description of the currently-at object.

A second "Whazzat" without any motion in between, or an "Info" or "About"
request which may be issues regardless of a prior "Whazzat" or not, would
get a more pedantic presentation of the element type and properties of the
currently-at object.  This would be optionally in synonyms for the literal
text of the element type name and attribute name-value pairs, but would
cover them all and the basic requirement would be met by a structured
presentation of the element type name and the set of name-value pairs for
attribute nodes associated with this current DOM node.
Technique #2:

There is a user-electable option that the local-context menu such as is
accessed by a right mouse click in Windows show the current-node properties
listed along with the action opportunities.  

The shipping default could still be that the contents of the context menu
is only the actionable items.  But there is an option to have this
recapitulate the properties of the current context as well.  There could
even better be three levels of verbosity in the context menu, with the
summary description of the current object as described above as the
first-Whazzat response used in the intermediate model.

Discussion:

In the EZ package of interface techniques, model 2.0, there is help for all
functions and it is layered, with more verbose help available on
repetitions of the help command.  EZ is a reasonably mature package of
functions by now, so this is a pretty good general model for what the user
needs.

Reference:  See the implementation guide at

EZ Access Interface Techniques

http://trace.wisc.edu/world/ez/

The "What's that" request seems like a necessary orientation safety valve
when navigating structurally inside a space where the author assembling the
space did not comprehent the extreme locality of viewport of the audio
browser.  Having it expandable to cover all attributes is an easy way to
ensure coverage of all information, wherever it is lurking, without
drowning the user in syntax.


Another way to see how basic this capability is is to look at the VRML
browse model by comparison.

Inside an HTML page, hierarchical navigation is navigation in a virtual
jungle gym where the bars of gym are in the comfortingly regular pattern of
a tree.

In VRML there are two primary modes of interaction: roam and inspect.  What
we have talked about as structural navigation is the 'roam' mode for the
virtual-tree navigable space.  But for document browsing, we need an
'inspect' partner to go with the 'roam' functions of the hierarchical
navigation; both so the user does not get lost, and so they have access to
the content that is meted out through a localizing filter controlled by the
roaming results.

Just as some people want to read the footnotes and some do not, the
information in the markup language attributes is "normally hidden" content
that users should have elective access to.  This kind of "drill-down
inspection" method is the most primitive way to get to the leaves of the
information set (for which the nodes identified in the DOM1 Core are a
sufficient index).

On the other hand, only a human can tell if the attribute values are
human-usable or not.  The algorithms in the browser have no reliable formal
rules that tell what is human-understandable; only what is
machine-understandable.  The way markup languages are used, the attributes
are not just one or the other.  They may have utility in both uses.  The
author cannot be fully trusted to understand the needs and abilities of the
user.  So we stick to letting the author determine what is _normally_
hidden, but not what is accessible-on-request.  This kind of local
"Whazzat?" access will let the user gain measured access to the attributes.
 They can that way glean whatever mnemonic or heuristic value is in them
without being drowned in either syntax or data.

Relying on the user's stylesheet to present all information in a processed
form is the route that is too complex or cognitively-demanding to be
considered realistic.  Simply exposing the data that is in the document
that the styles, if available, will interpret, is going to be more
comprehensible to more people, and it is easy for the User Agent to do.

It is clearly advantageous to the population of partially-impaired people
(our large numbers group, including seniors) if this capability is carried
out into the User Interface without depending on the application of
assistive technologies to expose the full content.  But it is a policy
decision to figure out if this should be "required" through the built-in
UI.  I am trying to clarify the relevant techniques and their UA costs and
UI performance in this note, not the ultimate policy question.

Received on Thursday, 20 April 2000 12:00:44 UTC