More Smooth Sounds

People are not very good at distinguishing the pitch of two sounds, unless they hear them close together. My Casio watch makes good use of a fairly subtle change in tone. The watch has several modes: normal time, stopwatch, set alarm and dual time. The mode button changes from one to another. When I am finished using a mode, I can press the mode button to leave that mode, but I have to visit each of the remaining modes before I get back to normal mode. At first I found this a bit frustrating. The number of button presses required to get back to normal mode varied depending on what mode I was leaving. If I had just used the stopwatch, I iterate through set alarm and dual time to ge to normal mode, so that took three presses, but if I was just using dual time it would only take one press to get to normal mode. Of course one press too many means that you have to iterate through the whole list again.

Then I noticed that the tone of the key beep when entering normal mode was slightly different than the key beep when entering any other mode. The interface designer was giving me an easy way to know when I had reached the end of the list. So now, rather than watching each mode appear on the display, I press the button quite quickly and listen for the button beep to change.

I have used other devices that have different tones to convey different messages, but they rarely succeed because it is too tricky to remember what each tone represents. There are some ways to encode meaning into sounds, sometimes humorously called ‘earcons’ ! A rising tone suggests success or happiness, while a descending tone implies the opposite.

Beeps can get closer together to imply that some threshold is about to be met. Anti-bump sensors in cars can provide these beeps while reversing. Note that the driver can not usually map the spacing of the beeps to the distance from the object behind. However the driver can judge the spacing of the beeps relative to the spacing a second earlier, so he knows he is getting closer. This changing sound also has a natural limit as the reduction in the gap between beeps eventually leads to a constant tone implying that collision is imminent, or perhaps has already occurred.

A much less critical application is a kid’s music keyboard. We have one at home with five volume levels. When you turn the device on it always defaults to five – the loudest. It is always easier to convince a kid to turn up the music than to turn it down, so why did they not default to a quieter volume? An even better solution would be to remember the last used volume, but that might have a cost impact since some non-volatile storage would be required. Without that ideal option, try to pick the volume defaults to be the least disruptive.

These scattered examples of the use of sounds in the user interface might influence your thinking the next time you add a beep.

Sounds Exciting

Sounds, beeps, buzzes and clicks can make a useful addition to your user interface, or they can form the most exasperating parts. Subtle sounds can give feedback that a button press was detected and less subtle sounds can inform you that urgent action is required or your machine, or car, or patient might be permanently damaged. But badly designed sounds can annoy the user, and those near to the user.

One common assumption that your system is the central focus of the user’s attention. That leads to the assumption that if your device is making an ‘urgent’ noise then it will be attended to quickly. This violates another rule, that I often refer to, that states that the designer should always assume that the user is very busy. While you are designing one piece of medical equipment, it is easy to forget that the user may be responsible for thirty pieces of equipment spread across six patients. When your device starts beeping urgently, it may mean that a patient needs urgent attention, or it might mean that the machine is sitting at the side of the room waiting to be used, and it is not interacting with a patient in any way. So for urgent noises, it is important to investigate use-cases of the worst case, most dangerous, scenario, but it is also important to investigate the most benign case to find out if the harmless case is going to lead to nuisance noises.

Another common decision is to sound a buzzer if the device is stuck in reset, or in some ‘not working properly’ mode. I recently worked on an after-market automotive device that did this. If some configuration parameters were not set up right, then the device would beep constantly. It seemed reasonable, since you never wanted to drive down the road with the wrong configuration parameters. The problem was that the device would often be like this in the workshop while the vehicle had wiring installed. While the vehicle was being worked on, no one cared about the configuration, but the noise drove everyone nuts – they used to ring me up rather than e-mail me just so I would hear how annoying the background noise was so that I would add an override feature.

You should always give some thought to whether noises can be silenced for these special cases. For the service guys, the ideal thing would be a simple dip switch to turn off the buzzer, but of course the danger with that sort of measure is that it would be left turned off when the device is shipped (or a user would turn it off) and then the buzzer would be disabled in the field. So you have to find a balance between ‘easy to override’ and ‘hard to accidentally override’. The solutions tend to be application specific.

If the user can not override the sound, then it can lead to undesired behaviour.Consider a pasanger seat with a weight sensor, that will beep if the vehicle moves while the seat belt is open. Now a driver who regularly leaves a bag of shopping on the passanger seat gets beeped at even though there is no passanger present - just a bag of groceries that weight enough to be a small person. So the driver plugs the seat belt in and leaves it that way permanently, just to make sure the beep does not happen. Of course this makes it more difficult for a real passanger to put on the belt on the occasions when this driver has a passanger, and it might even discourage this passanger from using the belt at all, which is the opposite of the original design intention. If the original warning sound been only temporary and more subtle then the driver may not have felt obliged to work around it, and so the problem might have been avoided. Again there is a trade of between making the sound so annoying that the user can not ignore it, and allowing for the case where that sound is actually a false alarm.

When designing a sound, always consider whether it is just for the ears of the user, of if other will hear. If you have a ‘failure sound’ (usually implied by a descending tone), when the user presses an illegal key, then the people near to the user will hear it and get the impression that the user is doing badly (if the user is a doctor, and the patient can hear the ‘wrong key’ noise then that can reduce the patient’s confidence in the doctor !). No user will thank you for announcing to the world that they pressed the wrong button, and these users will quickly want to silence the device. Having an easy to access mute or volume facility is vital for any noise-making device. Beeps that might be very subtle in noisy lab environment may be deafening in a library.

For the urgent noises that you might not want to volume control, consider having long silences between the beeps. If a noise is too intrusive, then the user’s priority is to silence the noise, and not to solve the problem. In medical devices I often see staff silence an alarm before they make any attempt to see the alarm message or to asses the patient. It is obvious that their first thought was ‘How do I stop the noise- it is driving me nuts’ when their first thought should be ‘What is the patient care issue that needs to be addressed’. Design noises to inform the user, not to bully them into responding.

My next post will point out some particularly bad uses of sound, and some particularly good ones. In the mean time, if you have any examples of your own, let me know.

(Code) Size isn't everything...

I have been looking at some code sizes recently and wondering why GUI code gets so darn big. I can understand that compiling in fonts and bitmaps are bulky and so the executable size can get big, but even when measuring lines of code the number of lines taken up by the GUI always seems to be greater than the rest of the system put together.

I pointed this out on one project where we had about 12 KLOC (thousand lines of code) for the GUI and about the same for the rest of the system. One of the other engineers quite reasonably queried if I had included the third party library that we were using. No – that was another 30 KLOC that I had left out; since it was not ‘our’ code (i.e. we did not write or maintain it). That 30 KLOC dwarfs our system, though I guess we probably only used about 20%. Still, a fair chunk of the graphics code was done for us before we even started.

So even when a lot of the drawing and filling routines and screen drivers are left out you still find your self with tons of code to manage what is visible on the screen. And I have seen this pattern repeat on many projects.

“So what” you might say. The interesting thing for the developers is that if the company is making photocopiers, then some of their programmers are going to have knowledge specific to photocopying, ink pump control and the like. But once their photocopiers get more complex and have a GUI on board the company is going to spend just as much on GUI expertise. If they do not purchase some third party tools, then you are going to spend an awful lot (of time/money/resourses) on graphics code.

All this is worth knowing when you are hiring a new engineer, or if deciding to buy a GUI library, or write one yourself. Having a sense of the size of the challenge helps drive good project management decisions.

In fairness the 50/50 split might be slightly exaggerated. Controls code is often shorter but more difficult to write than GUI code, so each 1000 lines of code is not an equal measure.

The numbers still tell me that there is a real benefit in third party tools that dramatically reduce the workload on the GUI portion of the project – since that is a big chunk of the total project, and there are even cases where you can justify spending more on the hardware if it makes the programming job easier.

If you have used any tools that you think tipped the balance on the amount of GUI code that you had to write, let me know.

The meaning of Life, or at least, of words

Federico Fellini, the Italian film director said “A different language is a different vision of life.” I find this rule applies to spoken dialects, but also to the differences in the language used by engineers and that used by their customers or end-users. I have written previously about the usefulness of a glossary when working on user interface design, or any engineering project (http://www.embedded.com/columns/murphyslaw/53700319). If the team are careful about defining the terms the engineer’s use, it also affords them the opportunity to decide which terms should be visible to the user, that is the terms that appear on the user interface or in the user manual. The term ‘signal’ might have meaning in an engineering design document, but mean nothing to an end-user. On the other hand the term ‘message’ may have a well defined meaning, within the scope of the product, for both the engineer and user.

On one project we had a customer complain about certain features that they wanted to work during low-power mode. With a small bit of effort the engineers added some configuration flags to turn on some outputs that were normally off during low-power mode. The customer received the update, but was still not happy. More flags and features were enabled but still no success.

The reason we were failing to satisfy the customer is that we were interpreting the term ‘low-power’ in the way we had defined it internally within the team. The processor had a low power mode, where the main software loop was not running, and the processor only woke up occasionally. However the customer had no understanding of CPU cycles and the like, in fact the customer did not know or care that there was a processor in the product. To the customer, ‘low-power’ meant that the LEDs on the front of the box were not lit, so it looked like it had been turned ‘off’, in some sense.

We finally satisfied the customer by providing a button that turned off a set list of outputs and turning off the LEDs on the front panel. The LEDs remained off until there was some further interaction with the device. The device never actually entered ‘low-power’ mode (as the engineers interpreted it). This was fine as the outputs that consumed most of the current, were turned off. In terms of current consumption, the difference between the processor running its full loop or going to ‘low-power’ mode was negligible.

So the customer continued to call it ‘low-power mode’ whenever we turned the LEDs off. Ideally we should have come up with another term for it, since it was bound to lead to some confusion later. While you do not want to take a George Orwell style control of your customers thinking by dictating what words they are and are not allowed to use, resolving ambiguities will ease the path for everyone.

So the next time a customer uses a term that you engineers have very strictly defined, stop and think about whether that is the same definition that is in the customer’s head.

Three Most Painful GUI Challenges

I have been thinking recently about which parts of GUI design are truly the most difficult. The programming side of it has gotten easier over the years. Faster processors mean that the programmer does not have to spend endless hours making his bitmap-rendering algorithm a little faster on the draw. Graphics libraries are widely ported, so most programmers do not have to spend too long pouring over the data sheets. These libraries make constructing the higher level screens fairly straightforward, unless you are looking for something unique.

So the hard stuff is not writing the software to put something on the screen, but actually deciding what it is that you want to put there. In this piece I will identify three of the areas which I feel are the most challenging – unfortunately I do not have any answers to challenges, but at least if you also feel the pain in these sensitive areas, you will know that you are not alone.

The first pain that I feel in this area is the pain of backward compatibility. In most projects, the product being developed has some precedent in the market. The products already out there have names for the concepts you are dealing with, and the users have a certain mental model of how they believe products in this category behave. This may be a blessing if you can simply copy those concepts that are already established, but it leads to endless internal debates on naming if you want to come up with something new, either because the new device does not exactly match what was in the field, or because a better name or mental model is now available. Driving a change to a better mental mode or naming system has to be weighed against causing current users to learn something new when they purchase your product.

There are far better keyboard layouts than the QWERTY style, but none has caught on because so many people would have to learn a new keyboard – and people are far too busy to learn something new, unless the payback is many, many multiples of the time spent learning.

The question ‘Do we make it the same as the products out there, or try to achieve something better?’ is often the hardest one to answer when establishing user interface requirements.

The next tricky bit is the mechanical design. I know it is a GUI and, in theory, you can draw whatever is allowed by the resolution and color palette of the screen and graphics controller, but the GUI is hugly influenced by the small set of buttons and/or knobs that are placed around it. In every project I work on I end up frustrated that we left out some hard buttons, or left in some hard buttons for features that would have more suited to soft graphical buttons. Early prototyping should resolve these issues, but somehow the prototyping is never extensive enough, or early enough, or the requirements just change too much after the mechanical design has been set in stone (or in plastic tooling).

See my latest ESD article: ‘Mechanical vs. digital: a GUI isn't always the answer’ available at http://www.embedded.com/design/212700448 for more discussion on the pros and cons of mechanical design in a GUI environment.

After those two issues have left my head throbbing, the final ache comes from featuritis. No matter how large the ‘Keep it Simple’ sign hanging in the team’s coffee area, there are always too many Yes men and not enough No men, and the product always has everything and the kitchen sink thrown at it. Almost every project I work on would benefit hugely from having someone take an axe to the feature set and get rid of the features that will never be used by 90% of users. Out with the feature that was included because some competitor has it, but no one ever uses it. Out with the feature that is some team member’ pet project, but no on else can see any use in it.

As diligent engineers we all want to say ‘Yes we can do that – it will only take a few hours’, but we really need to say consider whether we should. Deciding whether a new feature will provide real value to the customer or is just a case of showing off what the technology can do is often a difficult call. Sometimes you have to rely on the marketing guys to know their market well. Sometimes you have to get out of the office and find real users in the wild.

The Numbers Game- How we oversell the wrong properties and usability suffers

Engineers are always trying to improve the numbers that define our products, whether it be the number of pixels for a camera, or the pages-per-minute for a printer, or the resolution of an oscilloscope.

Marketing will always seek to trump the competition by having a number that outstrips their rival, regardless of whether that number has any meaning to the end user. Customer surveys constantly find that ‘ease-of-use’ is much more important than quantative measurements like picture resolution or sound quality, but it is far more difficult for a marketing campaign to state and prove that the user experience with one product is superior to another – it is a more subtle message and require more marketing nuance. It is often a reputation that has to be earned over time.

Be careful that seeking better numbers lets you lose sight of what the user really cares about, which is a better overall user experience. When the world transitioned from records and tapes to CDs, the marketing people were telling us all about the improved quality of sound from digital media. To be honest, I think few customers cared. CDs allowed instant access to a specific song. They are smaller and easier to store than either of the other media, and less easily damaged. So ease of use was more important than sound quality. My proof for this thesis comes when you look at the next transition. People were more than happy to allow the sound quality to be reduced when transitioning to MP3s because that allowed for miniature MP3 players, no media to cart around, and easy access to extra information such as song title, artist etc. Users will follow a better user experience, and quality will not be an issue except for a few audiophiles, who only make up a tiny percentage of the market.

So what does this tell us about the future of other products? Blu-ray disks are having trouble gaining traction in the market, even after seeing off the rival HD format. Why? Well the user experience is the same as a DVD. We have not given the customer a compelling reason to upgrade their hardware. We have not made anything easier or better for the user, so they are not going to bite just for the sake of a few extra pixels. Blu-ray will limp along while the real user experience enhancement will come from video-on-demand and downloadable rental movies. Not driving to the video rental shop is a real user-win, and that will trump high definition every time. Most users will choose a faster download and less wait time.

Another example of dodging the numbers game is the Wii success storey. The designers did not follow the path of the Xbox 360 and PS3 which easily trump the Wii based on the screen resolution and graphics processing power, but the Wii won out on sales because they revolutionised the user’s means of controlling the game.

Camera manufactures blindly followed the herd as they increase the picture resolution. My camera takes 7 megapixel pictures, but I always keep it set at 5 megapixels so the pictures are smaller – I keep more pictures on the camera, and use less disk space to store them on my PC. Increasing the picture quality was actually damaging my user experience because the camera was full more often, and other operations such as e-mailing the pictures was more difficult.

Bear this in mind the next time you want to revamp your product to get more of what you already have. Do you want your 60 page-per-minute printer to do 70 pages-per-minute, or should you investigate why it sometimes takes the user ten minutes to resolve a paper jam (maybe they could be given better indication of exactly where the problem is when it happens). Saving the user time this way more than compensates for printing a little slower than the competition. But it is hard fro marketing to sell that message. They fall into the Gillette trap – think of a bunch of marketing guys sitting around saying that they have a razor with 3 blades, “What will we do next?”. It takes less imagination to simply give the customer more of what they already have – a fourth blade. But many customers will go ‘So what!’.

Apple regularly outsell higher spec products because their customers know that the experience with an Apple product will be better, and that is why they will buy an iPod that might have less memory than another player at the same price point.

So try to think outside the box of numbers, and come up with products that change the game.

When Good Text Goes Bad

Using text wisely in a graphical user interface can make the difference between an interface that flows well, and one that resembles a game show riddle. The first rule to remember is that the more text you put on the display, the less the user will read. Always assume your user is busy. If you put a paragraph of text in front of them, they will likely decide that they do not have time and continue using the interface without reading it. They usually figure that they can come back and read it later if their actions do not work out.

Short blunt messages like “Check Tyre Pressure” will work far better than “Tyre pressure is approaching the low threshold, and confirming pressure in all four tyres against recommended levels is recommended”.

The first message does appear to be ruder and it is not good to be rude to the user, but in this case it is the lesser of two evils.

Text as a Band-Aid
The second rule is that text should not be used as a BandAid. In some cases a design leads users to make a specific mistake. When this is seen in trials, the navigation of the interface should be fixed to make the mistake less likely. The less pleasant alternative is to add a text message that says “Warning: do not press red button while attached to patient”.

In my home town they built a roundabout with 5 entrances and exits. Each had multiple lanes. It did not work very well and led to traffic chaos. Instead of simplifying the junction, the planners added more complexity by installing traffic lights at some (but not all) of the entrances, and two sets of traffic lights halting traffic that was already in the roundabout.

Because drivers were not used to lights in a roundabout, many, many cars simply sailed through the lights oblivious to the fact that they were running a red – there were also so many sets of lights visible that you could sometimes see multiple red and multiple green lights and it was hard to be certain which ones applied to your lane.

The next step should again have been to consider simplifying the junction to something that drivers could use effectively. That of course was an expensive option. Instead the Band-Aid was to put up a sign telling the drivers what they should have already known: “Stop when Red”. This sign fails, partly because drivers (and users) read almost nothing and secondly any driver that has already been confused to the point where they ignore a red light, will likely ignore this sign also.

The lesson here is that if your interface is so difficult to use that you have to add text telling the user things that they already know then the interface is causing counter-intuitive behaviour, and the interface should be fixed rather than expecting the user to read instructions.

There are lots more rules for effective text use in my article “Wordsmith” available at http://www.panelsoft.com/articles.htm.