A quick tone can announce a message before the display captures the viewer’s eye. A spoken navigation instruction can explain the next turn without requiring the user to read a map. Sound is yet another means by which digital products can communicate; however, each audible signal is also added to the user’s environment.
Useful interface audio has a task: it conveys information, arrives at the appropriate time and gives the user control over the interruption.
A Tone Requires Significance
Voice navigation helps Google Maps communicate directions and traffic alerts. Google Maps’ support documentation describes a chime that may sound when voice directions have not been downloaded. Both are tones – one carries more information than the other.
One tone tells a user that an occurrence took place. Spoken language tells the user what the occurrence required. The distinction matters because a sound that attracts attention is not necessarily understood.
For instance, consider a hypothetical file-upload tool. A tone announcing completion would provide instant feedback to the user. However, if the same tone were used for an unsuccessful upload, then the user would remain unsure of the outcome. In order for the product to adequately describe the result, it would require additional ways to communicate it.
When a consistent cue follows a consistent event, people have an opportunity to become aware of it.
Determining Which Occurrences Warrant Interruptions
Selecting a tone for the interface is secondary to selecting which occurrences warrant an interruption. Slack lets users choose whether they receive notifications for all new messages or only for direct messages, mentions and keywords. Users can also set notification schedules and sound preferences.
Such selections provide solutions to differing issues. A schedule determines when interruptions will be allowed. A message filter determines which events are pertinent. A sound preference determines how those events are announced.
The distinction is valuable beyond workplace messaging applications. For example, within a chat room participants may share numerous mundane updates; however, a direct inquiry necessitates a specific participant’s reply. Providing both scenarios equal auditory notice obscures the difference.
While organizing an event may necessitate receiving multiple updates from participants; drafting documents typically calls for being quiet. The interface cannot assume all such factors based upon a new message arriving.
Being Able to Quiet Is Part of Using an Application
Similar questions exist during leisure time. Repeating certain effects may contribute toward establishing an atmosphere, but a player may be sharing a space, listening to something else, or simply prefer silence. GipsyTeam’s review of Pinco lists a mute-sounds option among the poker table settings, illustrating how players can control game audio while continuing to use the interface.
Additionally, any mute feature should clearly state its scope. Does it silence the current game, the entire application or the whole device? Those choices have different consequences. Muting the whole device could also silence an unrelated call or recording being played.
To illustrate, the desktop preferences for Slack contain an option titled “Mute All Sounds From Slack,” thereby explicitly defining the scope of silencing.
Sound That Competes with Other Sound
There are times when sound will provide a person with a method for accessing content; there will be times when the same sound provides a barrier to that content. Someone using a screen reader relies on spoken output to navigate, including finding the control that stops unwanted background audio.
Automatically playing audio in the background (or foreground), will create competition for this spoken output. The W3C has developed a very clear description of audio control; specifically in regards to auto-starting audio. If auto-started audio exceeds 3 seconds in length then the user must have some means by which to pause or stop it, or have the ability to adjust the volume of the web-based audio independently of the overall volume of all audio on the computer.
This is an example of a specific accessibility standard and not a rule that prohibits all audio. A sound lasting less than 3 seconds is not necessarily a good design choice.
A broader takeaway relates to competing sounds. Reducing the decibel level of an individual sound does not ensure that the listener will be able to differentiate it from a voice or voices. Allowing users to decide at what time they wish to start listening to a given piece of audio (as opposed to having it start at an arbitrary time) allows them to better define what they want to listen to.
Assessing Listening Situations in Their Entirety
Listening to a single sound file reveals only part of the listening situation. Apple’s guidelines for developing audio in applications advise developers on how best to interact with headphone connections, silent mode and audio from other applications. Apple also warns against unnecessarily stopping music that was previously started and/or playing.
For instance, the same message cue may be acceptable via a laptop speaker, but distracting while wearing headphones. Similarly, effects within games that appear to be short-duration may seem entirely different when repeated multiple times during a gaming experience.
Some examples of testing criteria may include: Does the sound tell me something? Is the timing appropriate relative to the event that triggered it? Can I turn off the sound without affecting my ability to perform another task? Testing should occur under normal operating conditions – i.e., multiple applications running simultaneously – not isolated to a single application.
Effective interaction with listeners happens when the sound used provides meaningful information. Like many aspects of effective communication, timing and control play a significant role in determining the effectiveness of audio used as an interface element.
