Re: Auditory interface ideas, what would help?

  • From: Andreas Stefik <stefika@xxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Fri, 28 Aug 2009 21:52:00 -0500

>  snickers *smile* -- hear attachment
> But seriously, why not have the voice say error or warning or whatever at
> the beginning of the line? or play a short but recognizable sound (actually
> the boing sound is a bit long).
>


This is a good question. In experiments where we watch people browse
auditory interfaces, what we see is that people only list to the first
microseconds of a sound on each line most of the time anyway, so we
generally put the most "recognizable" bits first.  So, in the case of
whether there is an error on the line, we would generally class that as
being somewhat a secondary concern (the top concern being "what is on this
line."). So, since it's secondary, we tend to either put it at the end or
try to use some other kind of sound to indicate it.

For example, if you are browsing looking for something, and at the beginning
of each line is a term (if, while, repeat, loop, whatever), that's really
helpful. If, however, on every line there's an error it says (Error, Error,
Error, Error), and you have to wait past the first term just to hear where
you are, it's aggravating to most of the users we've tried it with.  Of
course, it's a crap shoot sometimes as to what is important and what isn't
on a particular line. Sometimes it's obvious and sometimes we don't really
till we get to the lab (and --- of course, discover we were wrong). It's a
good question though; it's definitely very important which part of the cue
goes where.

Probably the classic example of poor design here is the auditory cues for
error messages in in visual studio in their watch window. I almost always
present this one particular cue I gathered a year or two ago at conferences.
The syntax error was that a variable was not defined somewhere in the file,
but the auditory cue for it doesn't tell you this until about 40 seconds in,
and it lasts almost a minute and a half!

So, I guess what we strive for is to put the most crucial information first,
as it can really save a lot of time. Individuals vary, but we've found it to
generally be a good rule of thumb, and our experimental data seems to
corroborate that.

Stefik

Other related posts:

  1. Home
  2. programmingblind
  3. Archive
  4. 08-2009