Re: diversity in web UI design

There's another major concern I have about multiple interfaces.  It stems 
from my experiences in a Relay center, where some of the communications 
assistants (CA's) were blind. (details in [1])

For a while, the blind CA's had equipment that was completely different 
than the equipment used by the sighted CA's.  One of the problems was that 
this prevented the blind  CA's and their sighted colleagues from talking 
about the system and exchanging tips and ideas.  It also increased training 
and support costs since the interface was so different.

When we upgraded the workstations we made sure that the user interfaces for 
blind and sighted CA's were the same as much as possible.  Both had the 
same windows and forms.  The main difference was an added caption line to 
give simultaneous access to the call setup information that sighted CA's 
accessed with a graphical diagram.  This way a Blind and sighted CA could 
sit side by side and simultanously see the status of the call and talk 
about what was on the screen using the same terms. A casual observer 
wouldn't even know one was blind and the other was sighted.

Everyone was a lot happier with this setup.  I should add that the upgraded 
system also gave the blind CA's equivalent functionality which they didn't 
have before... which was even a bigger advantage of course.  But I think 
having the same interface was also a major factor.

And this isn't the only situation.  People may also want to sit in front of 
a screen together at home, at an internet cafe, or a library.  Might just 
be two people having fun, or one person supporting the other.

For example, how is a blind librarian going to help a sighted patron use 
the web if the librarian is seeing a completely different interface?

In all these cases it's best for them to have views that are the same, or 
nearly the same.

I don't want to be utterly dogmatic about this.  This debate predates the 
web.  There are times when it's necessary to have an alternate 
interface.  But I still like the spirit of WCAG 1.0 where it's done only if 
it's in some sense really necessary... and "really neccessary" takes me 
back around to considering the page's "essential purpose" in a recent 
ancestral thread of this current thread.

Len


[1] Kasday, L.R., A graphical user interface incorporating Braille and 
Musical Sounds to Accommodate Blind Communications Assistants, Proc. Resna 
1994, Nashville Tennessee, RESNA Press.


At 02:24 PM 11/1/00 -0500, Al Gilman wrote:
>At 08:23 AM 2000-11-01 +0200, Lisa Seeman wrote:
> >It is better, because of users with multiple needs that are not all
> >addressed any of the user group specific optimized interfaces.
> >
>
>AG::
>
>Do we actually know ahead of time whether the unanticipated combination
>will be
>better served by bending the one solution that has to do for all; or one
>out of
>several, where one of the several may be optimized for a case that is
>closer to
>the person's actual situation than is the 'universal' page or site?
>
>Or are we are all guessing?
>
>The status quo is most often that we get one version optimized for one
>interaction situation.
>
>A few people actually take pains to ensure that it transforms gracefully, but
>more don't.
>
>Compared to this, a range of selectable options which are optimized for
>different situations could possibly be expected to sometimes have one option
>among them that transforms more gracefully into your situation than did the
>one
>choice when you had only one choice.
>
>It is true that in developing multiple targeted versions, the targeted
>versions
>may be done in narrower, more inflexible ways than would be one common
>server-side version.  But that is not a given.  It is William's strong
>suspicion, for example; and I have to say there is evidence for such
>suspicion.  But it is not logically necessary.  The technical facts allow the
>centering of an optimized version to be independent of the breadth of range of
>flexibility.
>
>Part of my problem, in listening to this either/or discussion, is that in my
>current working guess it would seem that the optimum site design is a hybrid
>that uses some of both techniques.  That it is useful to teach designers both
>how to serve the specific UI needs of specific cases and also to teach them
>how
>to generate flexible encodings of their designs that transform gracefully.  I
>genuinely believe that a package where they do some of each is a) more
>effective and b) more salable than a purely single-source,
>automatic-transformation strategy.  If we try to pick which approach 'they'
>will use, the world may indeed go on its merry way paying us some lip service
>but little heed.
>
>On the "make sure there is a maximally robust safety net under everything"
>side, I would advocate for a hierarchical table-of-contents style site
>index in
>text.  Always.  Just do it.  Automate it.  It is going to be the best way for
>some people, for both sensory and cognitive reasons, to find stuff.  The
>market
>for this particular service doesn't go away.  This lets the user do a text
>search on the titles with the 'find' function in their browser that they are
>facile with already, not some peculiar search interface that works differently
>from other sites.
>
>On the "different strokes for different folks" side, I would cite databases
>like transit schedules.  Here tabulated data (timetables) are effective for
>visual access but a more interactive query-driven application would appear to
>be more effective for people operating in audio.  The 'common source' for this
>is a database that can't be expressed in web media today.  The best current
>solution is a server-side application with different web-encoded views into
>it.  Yes, in PF we are campaigning for XML Schemas so that more of the basic
>model of the application can be encoded and shared in a Web-standard way.  But
>that is not here and now.  People designing Web-delivered services have to
>design something now with what is at hand now.
>
>The evidence I have for the following is preliminary (anecdotal) but the
>evidence does agree with my prejudices, so I tend to believe it:  "With the
>best accessible site design and the best assistive technology, you can make
>information retrieval eyes-free almost as usable as a voice portal designed
>for
>use in audio from the ground up."  Check out TellMe and BeVocal.
>
>Another data point is that there is a graded sense of distance between
>different interaction situations.  It is easy to make a reasonable WAP site
>out
>of a voice-enabled site.  It is not so easy to make a reasonable WAP site out
>of an arbitrary Web design.
>
>This is why it is plausible to me that "starting your transformation from
>something closer" is actually a factor in having a better result.  Not the
>only
>factor.  But something that should not be ignored or dismissed out of hand.
>
>[Oh dear -- yet more ideas]
>
>You have to understand that even if the encoding is going to be in terms of a
>single deep underlying content model and transformations that express the
>common information in different views, I don't believe you can explain the
>model to authors without showing them multiple views.  To get the
>content-sourcing community to understand the model, and to be able to map
>their
>message into this framework, you pretty much have to confront them with the
>divegent demands of different interface situations, and challenge them to do
>the compare-and-contrast across what they would present as customer interfaces
>in each.  And in the practical result, you are going to come up with a mix of
>common source which can be transformed (as with text content today) and
>separate data forming equivalent alternatives (as with captions vs. audio
>tracks).
>
>As a technical matter, you can implement this with a common database server or
>with separate datasets that use cross-links to identify equivalent
>alternatives.  The experience delivered to the user can be exactly the same
>either way.
>
>Al
>
> >L
> >-----Original Message-----
> >From: w3c-wai-gl-request@w3.org
>[<mailto:w3c-wai-gl-request@w3.org%5DOn>mailto:w3c-wai-gl-request@w3.org]On
> >Behalf Of Cynthia Shelly
> >Sent: Wednesday, November 01, 2000 3:33 AM
> >To: 'Ian Jacobs'; Leonard R. Kasday
> >Cc: w3c-wai-gl@w3.org; jacobs@w3.org; kynn@idyllmtn.com;
> >asgilman@iamdigex.net
> >Subject: RE: General Exception for Essential Purpose
> >
> >
> ><quote>
> > 2) It is better for designers and users to produce fewer sites that
> >meet
> >    the needs of more users.
> ></quote>
> >
> >Now you're treating designers the way many complain they treat users <grin>
> >You're presuming to know their needs better than they do.  Why *restrict*
> >designers to single interface?  Why not let them decide for themselves how
> >much work they're willing to do to create optimized interfaces?
> >
> >-----Original Message-----
> >From: Ian Jacobs [<mailto:ij@w3.org%5D>mailto:ij@w3.org]
> >Sent: Sunday, October 29, 2000 10:56 AM
> >To: Leonard R. Kasday
> >Cc: w3c-wai-gl@w3.org; jacobs@w3.org; kynn@idyllmtn.com;
> >asgilman@iamdigex.net
> >Subject: Re: General Exception for Essential Purpose
> >
> >
> >"Leonard R. Kasday" wrote:
> >>
> >> Ian, Kynn, Al
> >>
> >> Thanks for all the detail on the 2.0 philosophy but I'm still not sure I
> >> understand the essentials.  Would you indulge the following lapse into
> >> math-ese.
> >>
> >> Consider
> >>
> >> the set of all user groups U1, U2, U3... with different sets of abilities
> >> and disabilities.
> >>
> >> and the guidelines UA and GL for user agents and web content.
> >>
> >> 1. Is the goal of WAI to produce UA and GL guidelines such that if both
> >are
> >> followed in their entirety, than each user groups U1, U2, U3... will have
> >> available maxium feasible access to all web sites?  Here "maxium feasible"
> >> means the maxium that can be obtained with current knowledge and
> >technology?
> >
> >At first glance, yes. Users have needs, we try to write guidelines
> >to meet those needs, by assigning responsibilities to meet those
> >needs to different parties. It's up to us to choose the scope of those
> >guidelines, how many problems in the real world to account for, etc.
> >
> >> 2. And is it completely acceptable to fulfill this goal by providing each
> >> of the user groups U1, U2, U3,.... with different versions of the site S1,
> >> S2, S3... ?
> >
> >Yes, but:
> >
> > 1) I think that it may not be possible to meet some needs anyway,
> >however
> >    large the set of sites is.
> >
> > 2) It is better for designers and users to produce fewer sites that
> >meet
> >    the needs of more users. Also, this doesn't take into account the
> >    issue of providing content that has been tailored to specific needs
> >    and therefore may be inaccessible to other users. (The issue of
> >    whether accessibility has to be measured on the client side or
> >whether
> >    it can also be measured on the server side, as long as users have
> >    access to full content, etc.)
> >
> >> If at all possible, please answer with one of the following
> >> - "yes"
> >> - "no"
> >> - "what  _are_  you talking about Lenny?"  <grin/>
> >
> >So, yes and yes. As I mentioned in an earlier email, this is a new
> >model that I'm playing with in my head, and so I expect it to be fragile
> >at this stage of its existence.
> >
> > - Ian
> >
> >
> >> or offer rephrasings of a sentence or two (with or without math-ese) to
> >> which you can say "yes".
> >>
> >> Len
> >>
> >> p.s.
> >> Also, if this is the philosophy, I don't understand where Kynn's
> >"minimally
> >> accessible" fallback fits in.
> >
> >--
> >Ian Jacobs (jacobs@w3.org)
><http://www.w3.org/People/Jacobs>http://www.w3.org/People/Jacobs
> >Tel:                         +1 831 457-2842
> >Cell:                        +1 917 450-8783
> >

--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/

Received on Thursday, 2 November 2000 10:28:24 UTC