Re: Techniques for 2.1

see comment at MN below:

At 12:04 PM 4/20/00, Al Gilman wrote:
>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.

MN:  I don't understand the difference in the above two sentences
and/or scenarios ???




>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 Monday, 24 April 2000 16:05:24 UTC