Re: skepticism about generic access solutions (was: issues with XWindow)

["L. C. Robinson" <lcr cyberhighway net>]

On Wed, 25 Aug 1999, Jason White wrote:

> A few points need to be emphasized here:
> 
> 1. It is a misconception to frame the discussion in terms of text vs. gui
> interfaces; rather, the point is to develop useful abstractions which make
> the application logic and data representation available, via a software
> interface, to whatever input/output modules the user has chosen.

Again, a seductive vision that may only be very workable for GUI decorated
textual apps: that could cover a lot of ground, though, as I pointed out
before, and might justify the effort all by itself.

> Structured data representations are starting to become increasingly common
> in a variety of areas, as can be observed by reviewing the various markup
> languages which have been developed over the past several years. On the
> "application logic" side, T. V. Raman's work offers a number of
> suggestions which capture, but in so doing, generalise, some of the basic
> user interface functions: selecting a single option from a set; selecting
> multiple options from a set, answering a yes/no question, and so forth.
> Through the evolution of user interface design techniques it may well
> become possible to encode these abstractions more directly, whilst still
> offering control over their presentation in a particular medium (E.G. the
> visual medium).

But let's not expect too much from this.  Much of what needs to be done is
fundamentally textual, though, and should lend itself to such approaches.
In the end, won't this result in more apps that work in both text mode, and
X?  If so, the access interface should be transparent to the user
(invisible, or selected automatically), so that the user will not really see
any access interface -- just an app that works all the time.  Only the
programmer need know how the coding was simplified.  This would be very
popular in lots of situations for even sighted users.  BTW, more
programmers may come on board if you drop the speech emphasis and rename
the project, so that people see it as a way to get both GUI and text
functionality at the same time.  Text mode apps continue to be needed in
the sighted world, too.

> 2. Software developers will, no doubt, always wish to implement new and
> novel user interface components; the solution here is to make it as easy
> as possible to incorporate therein the additional code required for
> access.

Yes, I anticipated this when I pointed out the potential problem with
increasingly complicated APIs, built to overcome the possible defiencies of
this concept.  A possible way to sidestep these problems might be to make
it clear at the outset that the toolset is only appropriate for solving a
certain domain of problems.  The big mistake might be in pushing things too
far.  

> 3. I reject completely the assertion that such an approach represents a
> centralised or authoritarian approach. To the contrary, it merely takes
> advantage of the existing tendency to use and reuse prefabricated user
> interface components in different applications, while at the same time
> creating opportunities for experimentation, innovation and creativity on
> the part of user interface designers.

I didn't mean to imply that.  I meant to suggest that widespread adoption
might be unlikely without some enforcing authority, which is thankfully
_absent_ in the open source culture.  That won't be a problem either, if
the project turns out to be as successfully seductive as the vision of it
is.

> 4. Referring briefly to one of the specific questions that has been
> raised, the Emacspeak user interface is an excellent example of an
> auditory interface which relies heavily on its non-textual aspects. The
> auditory icons are the most obvious example, but also, perhaps more
> instructively, the different speech characteristics employed by Emacspeak
> to convey structure and semantics, are not part of the text itself;
> rather, they are parameters of the speech synthesizer which have intrinsic
> significance only in the audio medium.

By "non-textual aspects" I am guessing that you mean things like
underlining, font changes, parens, brackets, color changes, and the like?
Things that are part of text mode apps, but need auditory interpretation,
apart from words?  I really need to try emacspeak.  Do these features work
with the software synths, like mbrola?

Thanks, LCR

-- 
L. C. Robinson
reply to lcr cyberhighway net

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html