Re: Auditory interface ideas, what would help?

  • From: "qubit" <lauraeaves@xxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Sat, 29 Aug 2009 08:53:30 -0500

Yeah, way back in the stone age doing compiler development we used to joke 
around as to what would be the best and worst ways to identify an error. Of 
course, best case, the message should tell where the err is and as much useful 
detail about it as possible, but we came up with the worst case being having 
the compiler beep once if there was an error or warning somewhere.
Anyway, I know this is a different problem -- you want to convey messages as 
quickly as possible audibly only.  Sometimes it is fun to step back and think 
of worst case scenarios in an effort to avoid them...
Anyway, happy hacking.
--le





  ----- Original Message ----- 
  From: Andreas Stefik 
  To: programmingblind@xxxxxxxxxxxxx 
  Sent: Friday, August 28, 2009 9:52 PM
  Subject: Re: Auditory interface ideas, what would help?




    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