Maybe I’m getting picky in my old age, but if Apple’s going to tell people they need to stop thinking of their digital devices in terms of real-world objects (address books, wooden shelving, burnished metal, etc) and should start treating them on their own terms, then they need to be consistent and cover all the bases—or rather—senses. I’m talking about sounds.
At first, I thought this was just an oversight on Apple’s part, but when I installed iOS 8 on my old 4S (I’m not foolhardy enough to put it on my 5S), I was immediately greeted by the same skeuomorphic—sounds. The Passcode buttons still made that little click (Tock.mp3) as though I had actually pushed some real buttons. When I locked the phone, I still got the sound of a metal latch (lock.mp3) clicking into place. Since there is no real lock, this sort of user experience goes square in the face of Apple’s assertion that skeuomorphs are outdated and should be abolished from our digital lives. I’m guessing Jony Ive doesn’t do sounds.
Suggesting a device’s power button should trigger a sound in addition to the sound the button actually makes when you depress it is akin to thinking an app that displays iBooks needs to look like it’s made out of wood. It’s kitschy. Which we’ve been explicitly told is the wrong way to go about things.
Launch the camera and take a picture and you still hear the sound of a sampled shutter click (photoShutter.mp3). Again, technically a skeuomorph since there’s no actual moving shutter.
The alternative to a clicking lock and a sent email taking flight (mail-sent.mp3) would be to replace these with abstract versions of themselves. To be consistent with the ‘new’ flat design, any sampled tinkling wind chimes should be replaced with abstract electronic sounds. Many processes are already presented in this manner: new-mail.mp3, shake.mp3, beep-beep.mp3, ct-keytone2.mp3, jbl_ambiguous.mp3 but the overall library lacks consistency.
And this is where things get interesting. Because—the way I see it—there’s a sensorial dichotomy in the digital world. We’ve all grown accustomed to how things ought to be visually represented on our smaller screens. We know that a button is anything with a border, that table cells can be slid back and forth, and that any text can be a link. Switches, buttons, form fields and much more can all be depicted minimally and suggestively because we’ve all been immersed in digital technology long enough to understand what these symbols represent. But when it comes to the sounds these elements should make there are no similar standards. It would be nice if there were some kind of audio language in place, but there just isn’t.
In trying to identify some patterns, I thought I was on to something in thinking that a sound that dipped down at the end suggested closure or that something was received by the phone (ReceivedMessage.mp3) while a sound that rose upward suggested something had been successfully sent from the device (Sent Message.mp3).
But this is hardly a rule of thumb (the default sound for a received SMS message rises upwards: sms-received1.mp3). There may be some truth to the idea that a lower pitch tone carries a negative connotation while a higher pitch connotes something happier, as in the Siri sounds: jbl_cancel.mp3 versus jbl_confirm.mp3, though I’m not about to put any money on that either.
At the very least, we could try to propagate the notion that a single-beep indicates the beginning of a process, as in the iPhone’s begin_record.mp3 sound, and a double-beep marks the end of that process, as in end_record.mp3. That seems logical enough.
Indeed, when it comes to sounds, rather than try to create a standard, Apple has chosen instead to provide an opportunity for personalization. Apple lets users customize a handful of processes by selecting from a set of some 91 sounds. It’s interesting Apple lets users select “classic” sounds for their device but won’t let users revert to a “classic” (iOS 6) look (or even modify the colors). It’s the one area where Apple still places kitschiness above usability. As a result, some real old-school stragglers still remain. It’s an issue that resonates on a wider scale when it comes to enterprise applications: when to set a standard and when to let the user decide? Not that I’m complaining, exactly. The only way I can hear my phone ring is if by going with Old Car Horn! Can you hear me now?
Content Strategy Lead at Anexinet