Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

(Difference between revisions)

Audio usability design guidelines

From Wiki
Jump to: navigation, search
mayankkedia (Talk | contribs)
(Added content and formatted the existing content)
Rahulsingh1m (Talk | contribs)
Line 59: Line 59:
<b>--- Added by Mayank on 24/06/2009 ---</b>
<b>--- Added by Mayank on 24/06/2009 ---</b>
==Related Links==
* [ Audio]

Revision as of 18:20, 30 June 2009



Every aspect of interaction between the user and the application comes under the purview of usability. Visual interaction/notification mechanisms like views/options menu/and other ui controls along with the color/font/overall navigation/look and feel implementation and their possible impact on enhancing the usability or leaving the end user high and dry have been talked in great lengths on some of the articles below like General usability issues, Listbox Usability, View usability.

Another aspect of interaction/notification between the application and the user which effects the overall usability index and ensuing customer satisfaction is audio. Audio plays a crucial role in attracting the attention of the user and of notifying them of something that has happened. Though strangely the impact of audio usage within the application has seldom been discussed in usability circles.

The usability team needs to take into consideration the effectiveness of using the audio cues in guiding usability while they are designing the application.

Key usability tips for audio

Some of the key points to consider while using audio within the application for either notification of events or otherwise are as under :-

Follow the conventions & be consistent

While using sounds it is imperative that conventions are followed. There are lots of sounds/clips that are associated with certain things and they are etched on the user’s memory. Do not use sounds out of context lest it ends up confusing the user. For instance a busy tone should not be swapped for a dial tone. Another thing to keep in mind while using audio clips is to be consistent; you can’t possibly use the same clip to notify the user for two dissimilar events happening. This could end up confusing the user especially if they are not looking at the device screen. For instance if you decided to use a tone to denote a successful registration event, do not use that for a successful log out event as well.

Honor the profile settings

Audio volume/mute etc is guided by the active profile on the device. Within your application if you are intending to use audio to notify the user, make sure you are using the settings from the profile. For instance if the active profile is silent you do not want to be playing a ring tone in your dialer or playing a tone to denote a friend messaging you on your chat client etc. You should also make sure that you have some sort of a listener mechanism implemented which lets you know of the active profile and any changes related to profile, so that the same can be reflected appropriately in the application as well.

Use right sounds to reflect the application state

In case the application makes extensive use of sound for notification/informing the user, it is important to use the right sound/clips for the right state of the application. You should make sure that the sound being used makes sense within the given context, so that the user can relate to it. For instance if you are developing a car racing game, on a crash you should use a sound that sounds like a car crashing and not like a train screeching on the rails.

Consider context while designing sound

It is very important to do a user profile study before recording the sounds that one intends to use in their application. For instance if the application is targeted for hearing impaired people it certainly wont be a good idea to use sounds to notify them of an event within the application. Sound/audio has lot of cultural/religious connotations attached to it, so one should be sensitive to those aspects while deciding the sounds to use in the application. For instance using sound bytes from a holy book/religious songs/hymns etc in an application out of context is bound to ruffle feathers, something which is not desirable from either a usability perspective or the company’s perspective.

Don’t be too loud or too soft

Another aspect to consider while deciding the sound one wants to use in the application is the pitch/tone/volume settings. You certainly don’t want to play a sound which is too shrill or too soft, both the cases are bound to aggravate the user. At the same time one should be careful about the volume at which sound is played out, lot of times applications have their own settings options. In those cases if the user chooses a really high volume level, it might be a good idea to re-check with the user that they are choosing a high volume and it might be blaring. In case the application does not have its own volume settings, it might be a good idea to use the volume settings from the profile instead of simply using a hard-coded/default volume level.

Let the user decide

If you intend to use sound in your application, specially games applications it might be a good idea to let the user decide as they are the best judge of what they want in what conditions. It would also give them a sense of being in control.

The decisions the user can possibly make are:-

Volume level

The user should be given the option to customize the volume level, in case you don’t intend to pick it from the profile/device settings.

Conditions where sound should be played

It might also be a good idea to let the user decide in what all scenarios they want to play sounds. For instance in a chat application they might want to get notified when someone signs in/signs out/sends message etc, while in the case of an update level they might want to be notified with some sound along with a visual notification like a dialog of the update being available. This sort of customization gives the user the senses of being in control unlike if you were to apply the settings on a blanket basis without giving the choice to the user.

What to play when

The user knows best should be the philosophy, so they should be given the choice what sounds they want to play in what conditions. For instance in a dialer application the user might want to decide what ring tones they want to play for what contacts/groups, or in case of a busy tone being sent out to the user what exact tone do they want to send out. An option to actually pick up sounds from the external media/memory card/stick could also be a good idea as in that case the application doesn’t have to bundle in all the sound clips. This would also help in reducing the overall size of the installer file. Another option could be to give the user the choice to download sound clips if they so intend.

Background adjusting

It could possibly be a value add feature, if based on the clock timings, you could trigger a confirmation note from the user in case the sound settings are out of sync with the times. For instance a high volume during the night time or a low volume during the day time might not be a great idea. Such triggers could be again customizable where the user can set the rules for the same.

--- Added by Mayank on 24/06/2009 ---

Related Links

57 page views in the last 30 days.