RE: Multiple interfaces - a concrete example

We're both talking about user choice.  Perhaps we're not as far apart as it
would seem.

I want to let users choose an entire interface, rather than requiring them
to make choices at every button. 

I'm not convinced that a single interface can be developed that will work
for a voice user, a sighted congnitively disabled user, and my mom.  The
requirements for each are very different.  In my experience, trying to meet
too many requirements at once results in compromising on all of them.

-----Original Message-----
From: love26@gorge.net [mailto:love26@gorge.net]
Sent: Tuesday, October 31, 2000 4:52 PM
To: Cynthia Shelly; Cynthia Shelly; W3c-Wai-Gl@W3. Org (E-mail)
Subject: RE: Multiple interfaces - a concrete example


At 04:24 PM 10/31/00 -0800, Cynthia Shelly wrote:
>Is it to have a gestault view of a brochure for the bank, or to get your 
>bank balance?

No. Not either of those choices and that's the problem with "multiple 
choice" systems - they ignore all the stuff in between their notion of what 
the choices should be.

If the "object" is to do one's banking via the Web, it's quite a different 
matter than "get your bank balance" and in the latter case we may have less 
disagreement.

The systems are touted to "do banking" and getting one's balance is an 
extremely trivial part of that process. However in a properly passworded 
system that shuld be trivially easy to do and it clearly isn't. It is easy 
at the ATM where the process merely requires PIN entry and prints a balance 
right there, even as part of another transaction. The Web should be even 
easier to use than the ATM - for everyone. It's not. That's why we're here.

CS:: "I'm not sure why a synthesized voice reading a Web form is more human 
than a recorded voice reading a menu.

WL: Because in the former case the user is in control. The synthesized 
voice can not only read 5X as fast, but can be skipped over and in a 
familiar context the information is *right there* not at the end of some 
serialized whim. The former is more like reading, the latter more like 
being read to and the difference is like night and day.

Spend a full day using a synthesizer instead of a monitor and you'll begin 
to "get it". It's very hard to do but very instructive and cannot be 
explained, only experienced. Most of us who write these specs are clueless 
as to what this world is actually like and wonder (that when we select some 
upper speed for a voicing system as 350 wpm) why some of the blind guys 
laugh at us. 600 is not unusable by experienced and inflection is a 
hindrance for many. Etc., etc.

Among other things, we are here to learn and one of the first principles is 
that control of all the parameters is absolutely paramount. Being able to 
skip around (random access of a sort) is so much more significant than we 
might think. Control is a major part of access and the site where the user 
chooses trumps any imaginable "being read to" scenario we can ever devise. 
This is a principle that applies to so many areas that the notion of 
"permitting" access to a semantically rich source document shouldn't even 
be considered optional, but mandatory.

We (authors, site designers, database gurus, etc.) shouldn't get to decide 
what's best for the user. The choices must be there. It's true that a herd 
of people will go for some equivalent to "final form" in all cases but 
that's not what we're about - we need to preserve choices for the user and 
she must be able to choose from the most semantically rich source available.

--
Love.
                 ACCESSIBILITY IS RIGHT - NOT PRIVILEGE

Received on Tuesday, 31 October 2000 21:03:30 UTC