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