RE: what type of document do we want?

Thanks Al,
Another term for the glossary?........................I think
so..........................Katie

[Jargon to capture: 'afford, affordance' -- from Human Factors and HCI
usage.
An affordance is an effective service delivery; one that makes it into user
space where the user can actually use it.  Or the effect of the service
delivery as observed within user space.]


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
Behalf Of Al Gilman
Sent: Thursday, April 12, 2001 10:25 AM
To: w3c-wai-gl@w3.org
Subject: Re: what type of document do we want?


At 06:48 AM 2001-04-10 -0400, Anne Pemberton wrote:
>As a start in the direction of providing illustrations for the guidelines,
>I took William's challenge, and made a web site (3 pages) that illustrate
>the points in Guideline 3 ...
>
> It is a rough estimate of what is needed (and it is NOT complete as it is
>now). Take a look at
>
><http://www.erols.com/stevepem/guidelines/G3>http://www.erols.com/stevepem
/guidelines/G3
>

AG::

One of the great virtues of these illustrations is that they expose flaws in
the verbal statement of what we are trying to convey.

For example, it is not a good idea to state 3.1 before 3.2.

In the rough draft illustrations, the illustrations of 3.1 and 3.2 leave the
reader free to believe that they are not easy to do at the same time.
Unnecessary differences between the layout designs in the 3.1 illustration
and
3.2 illustration confuse the reader because they must then construct in
their
mind a different example that illustrates both 3.1 and 3.2 at once, in
order to
believe that they can follow this set of guidelines.  We don't want to leave
that exercise to the reader.

People react to illustrations in a gestalt way.  Trying to illustrate one
principle with an illustration that violates another principle or even
clashes
with another illustration will risk delivering the message that the
different
rules cannot be satisfied concurrently and the reader may ignore our advice
because they can imagine it is impossible to comply.

The way this problem has been solved in the past is that while the book
introduces features and examples of these features first, followed by a
comprehensive example that combines the features, the authors of the book
have
to develop the comprehensive example first and then extract the feature
examples from the composite to use as the feature illustrations.  This is
the
only way to exhibit in our expository style the two-to-three principles that
are concealed in the current wording of 3.1 and 3.2:

These have to do with the use of _presentation qualities_ in presenting
ideas:

1.  Parts of a page (and sub-parts of building blocks in the page) that play
different roles within their enclosing superstructures should be
distinguished
by differences in presentation qualities (font, colour, indentation, border,
etc.).

2.  Parts of different pages (and sub-parts of building blocks in those
pages)
that play similar roles in their respective superstructures should be
associated by the use of similar presentation qualities.

Note:  In the above, the "associated superstructures" constitute a
multi-level
thread of ancestors, and not only the role of the item in its
immediate-parent
part.  So navigation blocks play a particular role relative to the site.
They
should be presented consistently to theme this relationship to the site,
regardless of what frame, table or page they happen to be part of.  This is
a
conceptual way to embed _type_ distinctions in the notion of _roles_.  Types
are "roles in the universe."

3.  Avoid differences in presentation qualities that lack a compelling
motivation based on 1. and 2. above.  Contain or prevent font sprawl, for
example.

Using feature illustrations drawn from the comprehensive illustration is a
way
of reducing the amount of new stuff the reader has to digest in order to
grok
our message.

The imperative to illustrate is not part of Guideline 3 but of guideline 1
on
the use of redundancy.

Guideline A is about using redundancy to drive home your message in as many
different ways as you can.  This is a technique for achieving effective
communication.

Checkpoints under guideline A should include:

A.x Avoid single point failure modes:

In particular, if some content is dependent on the use of a particular
sense,
provide an alternative that is not dependent on that sense and that serves
to
perform roughly the same function, to deliver roughly the same information
or
afford the same action opportunity.

[Jargon to capture: 'afford, affordance' -- from Human Factors and HCI
usage.
An affordance is an effective service delivery; one that makes it into user
space where the user can actually use it.  Or the effect of the service
delivery as observed within user space.]

A.y Employ vernacular:

Where a widely recognized motif or icon for an idea exists, use it, or use
something that conveys a pretty clear allusion to it.  Example: Microsoft
Windows Recycle Bin makes a pretty clear allusion to the Apple OS Trash.

Al

Only by seeing that an illustration of 3.1 that doesn't reflect
> Anne
>
>At 06:51 AM 4/8/01 -0700, William Loughborough wrote:
>>At 08:50 PM 4/7/01 +0100, Jonathan Chetwynd wrote:
>>>None the less If someone can produce 30 words of 'approved' plain text, I
>>>am more than happy to illustrate.
>>
>>WL: OK here's 32 words - if you drop the "and" from 3.2 and 3.6 you've got
>>the requested 30.
>>
>>
>
>
>WARNING: The remainder of this message has not been transferred.
>The estimated size of this message is 4114 bytes.
>Click on the server retrieve icon above and check mail again to get the
whole
thing.  If the server retrieve icon is not showing, then this message is no
longer on the server.
>

Received on Thursday, 12 April 2001 14:36:49 UTC