W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2002

rationalize presentation [was: Use consistent presentation]

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 04 Jan 2002 11:14:34 -0500
Message-Id: <200201041615.LAA3997510@smtp1.mail.iamworld.net>
To: w3c-wai-gl@w3.org
Well, we are building a problem for ourselves as soon as we use
'consistent' as
the headline.  This sends too superficial a message.  It creates an appearance
that consistency of appearance is the success criterion, whereas this is not
the point.  What we are after is a consistent relationship between variations
in appearance and distinctions in the rhetoric of the site content.

The success criterion here is that most presentation differences within the
site can be explained by a systematic binding [pattern of relationship] of
presentation effects to one consistent set of organizing principles across the
whole site.  The organizing principles cover concepts not only of parts of the
whole but also kinds of stuff found here.  This includes both similarities and
differences.  It is possible to quantify this criterion with entropy measures.

What the content provider should accomplish is a balance of a dominant core
rationality - functional application of effects - and a light ripple of dither
- un-rationalized variation - to combat highway hypnosis.  

If we just say "rationalize your presentation" and people do this to the max,
the result _will_ be boring.  A modicum of reasonableness is required in
how we
try to get people to curb their wildest flights of fancy and employ discipline
in presentation.

The rational core (of presentation decisions) follows the XAG injunctions:
- have a model
- bind the model to interface specifics
- stick to this plan
- share the reasoning for those who have to re-bind

Changes in presentation are rocks that turn over.  People expect to find
information under those rocks.  When there is no sense to the change, then all
distinctions are treated as senseless.  The consistent styling of navbars etc.
to indicate the consistent functional role that they play across different
pages will be defeated if one does not at the same time hold to a dull roar
changes in presentation that are _not_ explainable by site-organizing
principles.

What Gian has had trouble selling to his customers is good design.
Exceptional
presentation for exceptional circumstances.  It is all backed up by a
well-developed design concept or model.  But the neanderthals with the money
don't have a basis for judging what is a bona-fide exceptional circumstance,
unfortunately.  So they cling to shallow rules that actually work against the
application of the better, deeper, rule.

Not a problem with a simple answer, because in many situations we need to rely
on the funding authorities to sit on the heads of the designers and make them
exercise some discipline in addressing access issues.

Al

At 07:07 PM 2002-01-03 , gian@stanleymilford.com.au wrote:
>Hi,
> 
>I think we had a very productive meeting this morning.  
> 
>On the subject of consistency of presentation, I think what we are
>trying to say (while still following our own guideline 14.1!) is that
>the presentation is similar in design throughout the entire site, and
>over a finite period of time (as in, one does not expect the
>presentation to continually change on a week-to-week basis).  I did go
>talk to one of our graphics designers and he did not like the word
>'predictable'!  So perhaps we can consider other words.  A search in the
>thesaurus for predictable found:
>- obvious
>- unsuprising
>- expected
>- anticipated
>- evident
>- observable
>A search in the thesaurus for consistent found:
>- reliable
>- constant
>- uniform
> 
>And secondly, on the actual amount of consistency, I have found myself
>arguing against the guidelines when discussing this checkpoint with
>project managers. For a large site I usually advocate the use of
>secondary navigation appearing when on a particular page (for an example
>see
<http://hnb.dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prov%A0vs>http://hnb.
dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prov vs
><http://hnb.dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prog%A0or>http://hn
b.dhs.vic.gov.au/ds/disabilitysite.nsf/pages/prog or
><http://www.womensultrasound.com.au/dev/ultra.html>http://www.womensultras
ound.com.au/dev/ultra.html).  However when I
>suggest this I get checkpoint 13.4 thrown at me and told that it can't
>be done (usually I then ask why they have employed me if they aren't
>going to listen to me- as you can tell this is a sore point!).  So I
>believe we should somehow incorporate these navigational mechanisms into
>the guidelines, or at the very least, ensure that they aren't outlawed
>by the guidelines.  The other thing to consider is the use of breadcrumb
>trails (see:
><http://www.legalonline.vic.gov.au/CA2569020010C266/All/7002B178A09E591EC>
http://www.legalonline.vic.gov.au/CA2569020010C266/All/7002B178A09E591EC
>A256958002682E1?OpenDocument&1=Lifestyle~&2=Drugs~&3=Drug+use+and+the+la
>w~ or
><http://www.doi.vic.gov.au/doi/internet/transport.nsf/headingpagesdisplay>
http://www.doi.vic.gov.au/doi/internet/transport.nsf/headingpagesdisplay
>/transport+projectsgreat+ocean+roadstrategy+process+and+timing).
>Breadcrumb trails are a very good way of indicating where in the site
>you are, especially for those sites that are very large.
> 
>Happy New Year to everyone!
> 
>Cheers,
>Gian
> 
>Gian Sampson-Wild
>Consultant
> 
>Member: Web Content Accessibility Group Working Group
>W3C Web Accessibility Initiative
> 
>Stanley & Milford
>A Software Communication Group Company
>Level 16
>644 Chapel Street
>South Yarra VIC 3141
>Australia
>Tel. 613 9826 5829
>Fax. 613 9826 8336
>Mob. 0404 498 030
>Email gian@stanleymilford.com.au
>
>********************************************
>This message contains privileged and confidential information intended
>only for the use of the addressee named above. If you are not the
>intended recipient of this message you must not disseminate, copy or
>take any action in reliance on it. If you have received this message in
>error, please notify Software Communication Group immediately. Any views
>expressed in this message are those of the individual sender except
>where the sender specifically states them to be the views of Software
>Communication Group.
>********************************************
>
> 
>
>
>  
Received on Friday, 4 January 2002 11:15:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:18 GMT