Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!lnk10562
From: lnk10562@uxa.cso.uiuc.edu (Louis Koziarz)
Newsgroups: comp.human-factors
Subject: Re: Audio feedback from GUI's
Keywords: sound windows widgets
Message-ID: <1991Jun13.003210.23083@ux1.cso.uiuc.edu>
Date: 13 Jun 91 00:32:10 GMT
References: <1991Jun12.171211.2716@cs.umn.edu> <31228@hydra.gatech.EDU> <1991Jun12.202741.16629@ux1.cso.uiuc.edu> <1991Jun12.215523.7379@cs.umn.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 67

brsmith@cs.umn.edu (Brian R. Smith) writes:

>Maybe I should rephrase the question.  Instead of "Wouldn't it be NEAT
>if interface operations made sounds", it should be "What interface
>operations would BENEFIT from audio feedback?"

I was about ready to followup to your original post when the system went down
and came up with this response.  This is a much better question to ask, IMHO.

>This is a wide open question.  Use your imagination (mine's about
>tapped).  What other common operations are there and what kind of
>sound would suggest that operation to you?

Well, you can look at the audio channel question from a few points of view.
The examples you mentioned, and the ones that are used in SonicFinder
seem to simply provide redundant feedback to visual operations that are 
occuring upon the desktop.  With the advent of multitasking, I think a much
better idea would be to provide auditory feedback on background processes,
since your visual channel is already preoccupied with the foreground task. 
Why not use the other hemishpere as long as it's idle, right?   A good table
to segregate the visual and auditory channels comes from B.H. Deatherage, as
lifted from Chapter 9 of _Readings in Human Computer Interaction_ by
Baecker and Bruxton (eds).  Here goes:

     Use auditory presentation if:        Use visual presentation if:
     -------------------------------      ---------------------------------
     1: The message is simple.            1. The message is complex.
     2. The message is short.             2. The message is long.
     3. The message will not be           3. The message will be referred
        referred to later.                   to later.
     4. The message deals with            4. The message deals with events
        events in time.                      in space.
     5. The message calls for             5. The message does not call for
        immediate action                     immediate action. 
     6. The visual system of the          6. The auditory system of the person
        person is overburdened.               is overburdened.
     7. The receiving location is too     7. The receiving location is
        bright or dark-adaptation            too noisy.
        integrity is necessary.           8. The person's job allows him to
     8. The person's job requires him        remain in one position.
        to move about continually.

Your original article pretty much picked up on these concepts, and they're
important ones.  This might explain why so many Mac users trashed SonicFinder.
A few good concepts came through, such as the rising pitch of the water
sound as the file copy reached completion.  A background compile could benefit
from this, since a user can judge progress as well as speed of progress in
one metric.

I'm not anywhere near an expert on HCI (I'd like to be! :), but these are a 
few of the things I've picked up along the way.  The book I mentioned earlier
is a good read, although a bit dated by now (1987). The auditory chapter
deals a lot with speech synth and recognition, but there are a few good points
to be found about non-speech audio.  Maybe with 3-D sound we can do a few
neat things.  Of course the user can shut it off at any time, nobody would
like to work in an office full of chattering CPUs, which means audio will 
have to be a redundant medium for a long time, unless everyone gets headphones.

Before I get _too_ long here, I think audio could be very useful for interface
design, but it needs to be thought out carefully.  We all rely upon audio
feedback, like the sound your car door makes when it doesn't shut right, or
when your muffler springs a leak.  Can anyone pick it up from here and think
of new directions for sound?

Louis Koziarz
University of Illinois at Urbana/Champaign
koziarz@uiuc.edu