Some thoughts on sounds. People don't use sound effects on the desktop. One of the first things many people do is turn them off. The only device I know where people don't turn them off is the iPod.
We have a sound naming spec[1], yet no-one seems to care to design sound schemes for them [2] I think the reason for this is twofold: a) The sound naming spec specifies too many arbitrary sounds b) The sound naming spec defines so many sounds that it is nearly impossible to a sound designer to create meaningful sounds that differentiate between the actions The sound naming spec defines 125 sounds. That is 125 sounds for the user to learn the meaning of. Because the sounds defined are incredibly arbitrary the sounds run the risk of having their meaning overloaded. For example, We have complete-media-rip, complete-copy, complete-scan, but no complete-print, no complete-fax. What sounds should be used for those? Each time the sound is overloaded, it is a new meaning for the user to learn. With sounds like window-new, window-move-start, window-move-end, window-minimized, window-unminimized will the computer ever be silent? No wonder people turn the sounds off if they're going to make it sound like there's a hyperactive child in the room screaming for attention constantly. There is a principle applied to dialog boxes, called the butler principle[10]. When there is a knock at the door, the butler doesn't ask if he should answer the door, he goes and does it. He also doesn't tell you that he's going to do it, he just does it. I think this should be applied to sounds as well as dialogs. If the butler requires the master's attention, he does it subtley, making a discrete *Ahem* not by screaming "HEY I NEED TO TALK TO YOU!" A sound effect needs to be a subtle sound. Think how annoying the windows error sound is, a loud obtrusive DUN! It wrenches your attention away from whatever you're doing and makes you angry (Or me at least) The problem with subtle sounds is that they don't convey information And they are not meant to. A butler's *ahem* is not to inform you that dinner is ready, it is to make you notice that he requires your attention Then he tells you that dinner is ready, or the house is on fire, or that he's quitting. However, enough about butlers. The sound theme spec[3] defines four[see footnote 4] categories; Alert, Notification, Support and Game. I think these 125 sounds spread over the 4 categories can be reduced to a single sound [5]. How to combine all the 125 sounds defined in the naming spec into one single sound? Firstly the Game category can go. Its not really sounds for games anyway, its sounds for card games. Games are a special case and whatever sounds the game requires should be provided by them. Secondly, throughout the other 3 categories, the sounds are either a) Very application specific (i.a. the camera sounds, the phone sounds) b) State the obvious (i.a. lid-close and lid-open. I know I've closed the lid, I don't need to be told about it[7]) c) Mean that "something has happened that you did not specificially ask to happen, and may require your attention" Category a, the sounds can be provided by the application as they are ear candy. Not necessarily essential, but make the program nicer or cuter to use. Or in the case of the audio-channel test sounds are essential to the running of the program, but are far too rarely used to be worthy of making them themable. Category b sounds can be scrapped as they tell you things that you already know. Category c sounds becomes the one single sound.[9] The user only needs to learn "Something has happened that you did not specifically ask to happen and may require your attention"[8] Sound designers only need to create one sound This sound can be subtle. Subtle sounds can repeat without getting annoying (remember the windows DUN!DUN!DUN!DUN!DUN!?) The UI for the sound can be simplified to a checkbox "[x] Play sound" and applications which supply their own sounds can pay attention to that. The world is happy and people stop turning off sounds within 30 seconds of installing a new computer. The trick is when to use the one sound correctly, but as we now have a definition for that sound "Something has happened that you did not specifically ask to happen and may require your attention" I think we can work it out. iain [1] http://0pointer.de/public/sound-naming-spec.html [2] http://0pointer.de/blog/projects/free-sound-themes.html [3] http://0pointer.de/public/sound-theme-spec.html [4] The sound naming spec appears to have slipped out of sync with the theme spec, as it has 5 categories, splitting the Support category into Actions and Input Feedback [5] Initially, I suggested 3 sounds, but some people I have spoken to have made good arguments for a single sound.[6] [6] In fact, I've changed this email 4 times now between having a single sound in the main body and 3 sounds in the footnote and vis versa [7] Ignoring the fact that laptop speakers are usually inside the laptop and are then muffled by the lid being closed (thanks nick for pointing that out) [8] There are many possible definitions for the sound. I know some people have been looking at positive sounds, where the computer always makes sounds except when something goes wrong. But to me that concept feels like the solution to the computer making too much noise is to have it make more noise. There are other ways of giving the user positive feedback when they do something, press a key and the corresponding letter appears in the text editor, is a sound really necessary as well to reinforce that? IMO no, it is not. And what is the limit for positive feedback sounds, do we make a sound every time the mouse pointer moves a pixel? [9] My 3 sounds concept was one for Alert, Notifications and "something has happened that you did not specifically ask to happen and may require your attention", but in reality the first two are just more specific versions of the 3rd. It might be interesting to have different volume levels for the one sound, so errors and alerts get a slightly louder sound than general notifications. [10] A similar idea could be "Computers should be seen and not heard" _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
