Why 'structure' is easy -- rough cut

1. Why is it easy?

1.1 Structure by exception

the parse tree gives us an overabundance of structure. Our
@role="layout" value is an example of how we can hide nodes in the
parse tree from the breadcrumb trail through the page that answer's
the user's "where am I" question.

1.2 the user agent can inject structure
For example, sort a long collection alphabetically and break into
groups as fine as needed and label each group by the start and stop
prefix strings that isolate this group. Note how screen readers
already coach (third of five) ordinal position in collections. This
is not necessarily marked in the
markup, but it is consistently computed from the content.

1.3 simple user-information agenda

Aside from having verbs to move to suitable staring points associated
with parts of the page, what we need is the information to tell the
user:

1.3.1 Where am I?
This is answered by a synopsis of the breadcrumb trail from the page
root to the current place in the contents tree. This converts into
"where am I offered to go" as user coaching for direct and relative
navigation.

1.3.2 What is there?
This can be answered by a name, a header, a label, or a description.
An example where a description would be used would be "a list of the
five shirt styles that match your selection criteria."

1.3.3 What can I do?
This is based on the navigation options (specific to the view
constructed by the adapted user agent) and label-equivalents for any
user actions proper to the current place or object. This is the
context menu done right.

1.4 we have metadata capabilities to make object properties explicit,
where it makes more sense to describe collections by the common
characteristics of their sub-elements than by a name, label or header.

2. Why is it hard to see that it is easy?

Because there are options in the user-agent algorithms to find the
necessary tree nodes and attendant properties and relationships.

We had an example of this in the HTML markup for using the LINK
element to mark navigation landmarks. The navigation destination may
be explained to the user based on a name/label/header that is at or
in the part of the page one is maybe going to go to, or it may be
added as an @title attribute in the link itself.

Likewise, one may characterize a thing by a name or label if it has
strong internal binding and is memorable as a single thing. But if it
has weak internal binding and is mostly a collection of smaller
things, the description in terms of the kind of things (or stuff) in
it will be more memorable for the user and is the option to be
chosen. So the user agent has to look for resources to describe a
part of the page from different aspects of the allowed markup.

3. Performance Requirements:

3.1 There should be a structure which breaks down the content into
small enough chunks. Roughly speaking, the groupings in this
structure should meet a requirement that for each compartment, you
can remember what was at the beginning when you reach the end.

This can be either a well-structured paragraph or a list of
recognizably labeled things. If a list, the five-to-nine rule is the
conventional wisdom as to chuncks that the user should have available
as bite size portions.

3.2 The elements (labels, icons, sonicons, etc.) used in briefing the
user should be mnemonic. They should be something that will lodge in
the short-term memory of the user so that for a while they can recall
them, and definitely recognize the match when the user gets back to
the same point. This is the usual request that a) the labeling
captures what the user will find interesting in what is labeled, and
b) that this labeling distinguishes this object from others in the
page.

Received on Sunday, 27 November 2005 23:02:42 UTC