[comp.human-factors] audio

kpc@pluto.arc.nasa.gov (kpc) (06/13/91)

using audio for another few dimensions is a great idea.

one thing that's important about audio is that it should be:

	disableable

	not required, so that disabling it does not remove functionality

(obviously, a voice synthesis program or an alarm clock program might
be forgiven transgression of this rule...)

	configurable in sound (volume, pitch, duration, etc.)

	configurable semantically (e.g. sound bindings, like key bindings)

some people actively avoid programs that beep!  visible-bell, such as
in emacs and vi and xterm, is a nice feature.

p.s.  on another topic, how much work is being done on
non-CTS-producing keyboards and so on?  what events will make them
widespread?  (by CTS i mean carpal tunnel syndrome and other
repetitive strain injuries that are associated with computers in
general.)
--
Tweety is a bird.  Socrates is a man.  John loves Mary.  Mary is tall.

marsh@mingus.mitre.org (Ralph Marshall 617 271-8784) (06/13/91)

In article <KPC.91Jun12175158@shepard.arc.nasa.gov> kpc@pluto.arc.nasa.gov (kpc) writes:
>using audio for another few dimensions is a great idea.
>
>one thing that's important about audio is that it should be:
>
>	disableable
>
>	not required, so that disabling it does not remove functionality

Another feature which hasn't been mentioned here is that you want the
same sort of instant-feedback that you expect with a mouse and
keyboard interface.  If the sound is always after the event which
triggers it (and not even by a consistent amount) because the sound is
produced by the same CPU which is running the rest of the application
and interface, the users will hate it.  So, you either need embedded
signal processing chips in the computer, or external processing power
such as a MIDI-controllable music device.

Also, Bill Gaver has done work in the value of adding sound to
multi-user applications, in particular where users are coordinating on
a given task but aren't in the same room.  Neat stuff!
--
Ralph Marshall (marsh@linus.mitre.org)
Disclaimer:  Often wrong but never in doubt...
---------------------------------------------------------------------------