Should the same sound be played for a valid and invalid touch?

Question

I have a GPS device with a solely touch interface. From the beginning, I noticed I was having a hard time using it and I eventually realized why.

Whenever the UI asks me to write something (like a town or street name), it offers a keyboard. In this context, there are two behaviors which, when combined, happen to confuse me:

• Very often, the key I tapped is not recognized (although I haven't figured out why) and I have to press it again for it to be registered.
• The device makes a beeping sound every time anything on the screen is pressed, even it doesn't correspond to a valid action.

These, when combined, create a situation where the device beeps exactly the same way every time it's touched, regardless of whether it considered the keystroke valid or not. This makes typing extremely hard for me (even though I'm very efficient at typing on a computer keyboard), which got me thinking.

Is this a known UX design pattern that I haven't heard of (and if yes, what's its name and its advantages)? Or is it simply very poor UX design?

Answer 1

This seems to be more of a development flaw than an UX flaw. The sounds should be played when a key is pressed, but now it seems to play when the screen in general is pressed around the area of the button. It play even though the system failed to detect the key being pressed.

When the case of typing I don't think there should be an error sound, just a success sound - feedback for the user letting him know they pressed the key successfully. In a navigation system this kind of feedback reduces the time the driver has to look at the screen. They only have to look at the keyboard (1 look). If there is no sound they have to check their entry to see if they pressed successfully (2 looks).

Disclaimer
Don't text and drive, even if it's on your navigation device.

Even better would be a different sound for every key, like phones still/used to have. Those different tones enabled users to type blind, getting enough feedback by sound alone. They associate the tones with certain keys.

Answer 2

As you describe the system, it seems to be flawed.

It should make the sound not when the key/letter is pressed, but when there is an action associated to the key detected, that basically means every time a request to show a character has been received on the system. Even more, it could/should be emitted once the system is printing or has printed the letter.

About the sound when something fails, it should be different than the one when you have a successful action.

But in this case, it would be difficult to have a sound for errors. If the system beeps (success sound) when the order of printing is emitted, to have an error sound, it would have to implement a checking system to detect if the screen has printed the character, which would be complicated and very costly, not to mention impractical. If the system beeps (success sound) when the letter has been printed, there would have to be a system to check if the letter is the correct one, compared to the one you pressed, which would be, again, costly and complicated. So the best solution, is to remove sounds or just have sounds on success.

The problem with this kind of devices, is that the sound is emitted as a result of the pressing action, so the system emits a sound because you touched the screen. More and more we are used to it, but it's not what should be.