Usability Bites

World Usability Day

2009-11-09T22:32:00.002Z

November the 12th has been designated World Usability Day for 2009. The principle advocated by the Usability Professionals Association is to dedicate one day of the year to promoting some aspect of usability, and to evangelize good usability to the broader engineering and design community.

This year's theme is 'Designing for a Sustainable World'. Last year over 200 events were held worldwide, and it will be similar this year - see http://www.worldusabilityday.org/en/events/previous/2009 for an extensive list. While many of the events are fairly straight plugs to advertise usability review or training services, there are a couple of events that caught my eye.

Most events require you to attend in person, so readers are only likely to be interested in stuff in their locality, but a few of the on-line events are worth a mention.

Building Smarter Cities looks like it could be an interesting on-line discussion.

There is a essay contest on the topic of "How can the User Experience Community support the future of sustainability?" You only need 100 to 300 words and you might win a kindle. I have not come up with an entry myself yet, but I will definitely be keen to read a few of the entries.

There is a webinar on the topic of Agile Design within the Usability Process.

There is an on-line panel discussion on 'How Can a User Centred Approach Drive Sustainable Design?', which would not have grabbed my attention until I noticed Ben Schneiderman was on the panel. I have read a lot of his stuff, so it might be interesting to see him in the (digital) flesh.

If any readers see any other events that deserve a mention, let me know - or if you attend/observe any of the on or off-line events I would be keen to hear any feedback.

Gallery of Icons

2009-10-28T10:24:00.002Z

I came across this link recently:
http://www.guidebookgallery.org/icons
It has a set of icons from a number of different operating systems, and from different versions of those operating systems going back years.

Many of these symbols will not apply in an embedded system, but others are more global - like 'help'.

It is a handy place to browse if you think that your embedded system is going to borrow some symbols from the desktop world. In many cases the embedded application will have less resolution available than a modern PC, and so it might be worth looking at older, simpler versions of that icon.

Form Over Function and Battling with DVD Menus

2009-10-21T13:45:00.003+01:00

At the Embedded Systems Conference in Farnborough two weeks ago, I delivered my ‘Top Ten Usability Mistakes’ talk. The last item in the list of ten is the awful lack of respect shown for the user’s time in the experience of watching a DVD. They usually force you to watch some legal-eagle’s copyright notice, and then it might or might not be possible to fast forward the trailers for future releases. And then it sits at a menu. If I am setting up a Disney movie for my kids, I want to be able to press play and leave the room, just like I used to be able to do with a VCR.

One of the delegates pointed out that such frustrations actually encourage people to use pirate copies of the movie, since the bootleggers usually remove the stuff they know no one wants. In other words they set higher usability standards than the original content creators.

While the issue of wasting the user’s time was point number ten in my talk at the conference, I want to discuss a different aspect of the DVD experience in this blog. The design of the DVD menu is usually a triumph of form over function, which means it is nice to look at, but not so nice to use. The graphic design is usually impressive, but the blaze of colors makes it almost impossible to see which item is currently highlighted, so you are not sure what you will get when you press the play (or OK) button. A simpler layout, and less background color and movement, would have given us a better user experience. The bigger the budget, the flashier the menu and the harder it is to use! I think it is derived from a movie culture of having a passive audience, and they are just not used to the idea that the viewer may have to do something, or make a decision.

Even worse than the main menu is the scene selection menu – which usually shows a set of scenes as thumbnails, numbered 1 to 5 and then a number of choices to see thumbnails for 6-10, 11-15, 16-20 etc. . Having two types of selection is confusing – I would much prefer to have one set of scenes and use the left/right to scroll them, so if there are too many thumbnails to fit on the screen, I scroll to the one I want. This scrolling would chronologically move through the film, and I would not have to guess whether I want to go to the 11-15 set or the 16-20 set, which is a guess I usually get wrong.

Of course what they really need to do is show the number of the scene when you pause the movie, so that the scene numbers have some utility - some DVD players allow you access to this number but only after another button press that most users are not aware of.

The problem that is not addressed in the design of the DVD experience is how to resume watching the movie that you stopped watching yesterday. If the scene number was displayed when the DVD is paused then you could remember it - instead you have to look at the thumbnails and try to guess if you have seen the scene before. Yes, some DVD players have a resume function, but this seems to depend on the user pressing some mad key combination within 2 seconds of putting the disk in and I have always failed to get this feature to behave pleasantly on any DVD player I have owned. It also does not solve the problem if you move the disk from the player in one room to another (if you have to ask “Why?” Then you do not have kids).

Maybe part of the problem is that the experience is designed in part by the DVD format standard and partly by the DVD movie creator and partly by the DVD player, and while they all managed to agree on video and audio formats and compression techniques, it is harder to agree on, or even define, the most desirable user experience.

While I was travelling to the conference I called in on a friend, and while I was there, he received delivery of a prototype of a remote control, called Amulet, which he is developing. It works with Window Media Center. The unique thing about this remote is that it can pick up voice commands and use them to play music, video or other content on the PC (which is normally connected to your TV for this type of use).

I thought that this gadget would be an ideal third party tool to make scene selection easier. Since you could speak the scene number instead of moving the highlight from scene to scene. Alas the scene selection thumbnails seems to be buried in a part of the system that does not have any easy external API. Basically the platform designers never really considered it to be a platform where a third party may want to sit something on top of it. This makes it difficult to present the chapters, using the thumbnails, in a way not intended by the original DVD designer.

It may be a bit harsh to blame the original format designers for this. Should they have foreseen that DVDs might be played on a range of devices from PCs to game consoles and not just in dedicated DVD players. Also an API that would allow third party software to control the menus would widen the range of input devices possible. It is always a challenge to predict the variety of ways in which future developers may want to use the formats and protocols being designed today.

Embedded Systems Conference Show Report

2009-10-12T20:58:00.002+01:00

I spent three days at the Embedded Systems Conference UK in Farnborough last week. At these shows I sometimes hunt for the answer to a specific question and other times I am keeping an eye out for trends.

One topic that got a mention at the “Current State of MicroElectronics” panel discussion was the increasing importance of low power. There was also a paper on tweaking motor control algorithms to reduce power consumption. Low power considerations now matter at all parts of the design. Reduced network traffic, means that a wireless link can spend more time turned off, reducing drain. A compiler optimization means that the processing is performed quicker, and now the device can spend more time in sleep mode, which consumes less current. It set me thinking about whether this has any influence on my own area of user interface design. We are all used to battery indicators, but in some applications there might be scope for providing more information. Some cars display the fuel consumption level, to encourage drivers to drive in ways that conserve energy (i.e. don’t accelerate so hard). Similar indicators on a GUI could influence the way the user configures a device, if battery life or power consumption is a concern. If I reduce the backlight brightness or turn down the music volume on an MP3 player, it would be nice to know what percentage change I have made to current consumption. I am told that turning on Bluetooth on my cell phone drains the battery, but there is no feedback on the device which allows me to confirm if this is the case. Current consumption could be graphically represented, with maybe some time averaging depending on the application.

A few months ago, in an ESD article (http://www.embedded.com/218101668) I bemoaned the fact that GUI library vendors do not differentiate between mouse events and touch events, and Qt (qt.nokia.com) was one of a number of products that I mentioned in that piece. At the Qt stand at the show I had a look at Qt 4.6 and was delighted to see that they not only added touch support, but handled multi-touch and have a mechanism for passing gestures to the application on OS’es that support gesture recognition.

QNX had no stand, but Garry Bleasdale, a field application engineer with QNX, gave a talk on GUI development. The talk focussed on Flash as a way of making user interfaces a lot sexier than you can with a typical GUI builder. QNX’s GUI builder, Photon, provides buttons, sliders and other graphical widgets, but could never offer the kind of slick animated GUI available with Flash. Of course you have to get Flash ported to your platform first – or hopefully someone has already ported it for you. Flash definitely gives you the opportunity to make your GUI unique, and it is often desirable to get away from the slightly Windows-ish GUI that you get with most GUI libraries’ buttons.

There was a “Current State of Embedded Systems” panel. Much of the discussion was a language war, where panel and audience kicked about ideas about why something better had not replaced C. For a while the discussion turned to operating systems. Jack Ganssle, at one point, blurted out “Linux Sucks” in the hope of invoking a riot – sometimes the Linux evangelists get rowdy at these events. Getting them all fired up probably does little for the technical content of the debate, but it makes it more fun. While I am unsure of the validity of the “Linux sucks” position, Jack made a more telling comment, that maybe Android as a more shrink-wrapped version of Linux, might take some of the pain out of integrating Linux into an embedded device. Will Android become the one-size-fits all Linux distro for consumer devices. Maybe a bit early to say, but definitely one to watch.

My other mission at the show was to investigate SPI interfaces to graphical LCD displays. I occasionally deal with a client who wants to add graphics to a design, but their preferred processor has no built in graphics controller, and no external address/data bus to allow an external graphics controller to be used. If the number of pixels is low (sub VGA resolution), then there are a number of modules available from distributors such as Arrow and Review Display Systems, who both had booths at the show. The SPI modules are basically a controller mounted on the display, sometimes with a touchscreen combined, and an SPI interface. The SPI is incredibly appealing to the hardware designers, since address/data bus issues disappear. I was warned however that these modules are usually designed for specific customers, usually for a cell phone. If the big volume customer looks for changes, then the small volume customer might be faced with the same mechanical or electronic changes. So anyone who is building a medium or low volume product, which has a long design life, should be very wary of this otherwise appealing design solution. This is the sort of stuff I learn at the shows, that you just can not find in datasheets and marketing brochures.

When you have nothing to say ...

2009-09-27T07:14:00.000+01:00

Many embedded devices have a simple text window, capable of displaying a few dozen characters. These are handy for giving the user simple instructions or displaying error messages if the device, or some connected equipment, misbehaves. In some designs there is an obvious text message to display when the device is not being used – maybe a top-level menu. In other cases, particularly if the display is used to output text, but does not allow user input, there may be nothing to say when the device is idle. In this blog I will explore some of the options in that case.

The idle state can lead to some design contradictions. If there is nothing to say, then leaving the text window blank seems like the most appropriate thing to do. Why give the user something to read (like ‘Status: Normal’) which gives them no information. However a blank display can make the device look as if it is off, which may be misleading.

If something has happened, like an alarm condition, then the user needs to read that and the message displayed in the idle state can be replaced – but most of the time there is no such alarm or other activity to display.

On one project we agreed that it would display the time-of-day. This is commonly done on home appliances such as cookers, or a hi-fi. I am not convinced that time-of-day is a good idea unless the time is being used for other parts of the application. Once you display the time, you are obliging the owner to adjust it for daylight savings. You are almost guaranteed that the time will be wrong the first time it is installed (if the delivery has crossed time-zones), so the first thing the owner finds himself doing is hunting through the manual trying to find out how to set the time, when this activity contributes nothing to the utility of the device.

There are cases where displaying the time is advisable, or even necessary. If the device timestamps events or executes actions at predefined times, then if the time were set incorrectly the device would be out of step with the real world. The only way to be sure the time is right it to make sure the user can see the time so they will notice it is wrong. However in devices where the time is not used for any of its functions I would avoid the extra work for designer and user introduced by displaying the time.

So if time-of-day is not the thing to display in the idle state, maybe a company name or slogan works. I am fond of this idea and it encourages brand recognition. But proceed with caution. I worked on one design where we decided to display the company name at the top of the display. It eventually got dropped because of pressure on space in the text window. The company has since changed names twice, and this would have led to awkward software updates, to prevent the product looking immediately out-of-date.

One current design is following the same route, but because there are number of other configurable items, the string displayed in the idle state can be set in configuration. In this particular application it is often re-branded when sold by distributors so it suits them to be able to display their own brand rather than that of the OEM.

Some systems lend themselves to displaying some internal state or measurement. I recently worked on a device connected to a CAN bus (communications network for automotive and industrial applications). Some of the CAN messages would cause conditions that were displayed on this device, but other messages were not. However it was always interesting to know how much activity was on the bus. If the user pressed a button to drive some part of the equipment, there was usually a burst of CAN traffic, and then the bus would revert to zero traffic. On the device with the LCD we displayed a ‘Traffic = N’ line, where N was the number of messages per second on the bus. This meant that even if you were not displaying a specific message about what was going on, you had a rough measurement of whether the bus was active. A bar-graph might have been more pleasing than a number, since this is only meant to be a rough indicator, but in this case the application was just for in-house factory test, and did not merit the extra development work

Other applications may have other interesting numbers. In business information systems they often refer to Key Performance Indicators (KPI) and seeing the value of these numbers at all times helps manager maintain a feel for how well the business is performing, eve if exact thresholds for those values are not established. In the same way an embedded device would display its most important number. A printer could say how many pages it printed in the last hour. A piece of factory test equipment could display the percentage of manufactured items that passed their test. If the percentage is always higher on a Tuesday, even if within acceptable bounds, then maybe there is a flaw in the system that could be tracked down.

Even if the information displayed does not contribute to analysis of the system, it conveys the impression that the device is either busy on the user’s behalf or ready to obey any command received. This will encourage the warm-fuzzy feeling that the device is eager to please.

Long number Entry and Equal Opportunity

2009-08-30T08:05:00.002+01:00

I recently worked on a security application where the employee used a swipe card to identify themselves at certain locations. The event of identifying themselves was transmitted to a server, which had a database which contained the mapping from the serial number of the swipe card to the name of the employee.

All o f the employee records existed in a database. As we added cards to the system, the long and unwieldy swipe card number had to be entered manually into the employee’s record to create the mapping. As with any long-number entry, there is a risk that the number was entered incorrectly. Checksums within the serial number detected some faults but it was still not very satisfactory. And if the mistake was not discovered immediately, it led to hassle for the employee and supervisor the first time the card was used.

As we thought through this challenge, one option would have been to add a card reader to the server, or the PC accessing the server, and allow a card to be swiped instead of typing in the number. This added a number of unwelcome challenges. This reader would be different from the already installed readers since the communications link was different. The server was updated via the web, so you could not be sure where the user would be located, and restricting them to one location or PC would be troublesome.

Many solutions look so obvious after the fact and this was one of those cases. We eventually realized that the scenario where a card is unrecognised also provided the ideal opportunity to enter the correct user name.

So when the card is not recognised, instead of simply rejecting the user, the supervisor has the opportunity of picking a name from a list of employees, and the mapping from card number to employee is then created. This solution requires no extra hardware. The supervisor no longer has to type in long error prone numbers. The card can be swiped at any location, so when a new employee receives his card he simply goes to his nearest access point, and over the phone, tells the supervisor that he is about to swipe for the first time. The swipe is unrecognised, and the supervisor sees the new serial number, and its location, and links it to the appropriate employee.

This is a case of applying a principle called equal opportunity. It means that something that was delivered as output to the user can be turned around and used as input. This means that the user never has to enter the original data, since they received that data as output. Another example would be receiving a call on your cell phone from an unrecognised number, and being allowed to add it as a contact without having to type in the number all over again.

My online tutorial on equal opportunity provides a number of other examples of this useful technique:
http://www.panelsoft.com/tut_equal/index.htm

Measurement Changes Everything

2009-08-08T21:34:00.003+01:00

Introducing an electronic or computerized system to a human activity often opens up opportunities to measure aspects of the activity that could previously not be monitored in any cost effective way. This column strays a little from pure usability issues, but the nature of the measurements you take is partly a feature-set decision, but it also dramatically changes the nature of the relationship between your device and the people using it. In this column we will first look at systems as diverse as call centers, pulse oximeters, and running aids that tell athletes their pace and distance.

Consider a call center routing phone calls to a band of support or sales staff. Once the call routing is computerized, it is possible to measure the exact duration of each call, the time before a call is picked up and the amount of time between each call. These numbers can be used to measure productivity of employees. Once that productivity can be measured then many steps can be taken to increase it, such as linking pay with the percentage of a person’s time they spend on the phone. A case can be made that such measurements make the work place more pressurized, less pleasant, and might occasionally cause the most talented employees to seek employment elsewhere. That is a discussion on quasi-ethical issues that I am not interested in addressing here – the main point is that the measurements, which are a side effect of the call routing system can have a profound effect on the control of the system.

In other cases the measurement is not an incidental by-product, but the core purpose of the system. In medical devices, many innovations have been in the area of providing real time measurements of attributes that had previously been only occasionally measureable. Pulse oximeters give real time feedback on blood oxygenation levels. Previously a blood test was required, and this limited the number of samples that could be taken, and by the time the sample data came back from the lab, the patient condition could have changed. Modern respiratory therapists can make minor adjustments to a patient’s lung ventilator or to their medication, and then observe second-by-second the impact of the adjustment. It even opens up the possibility that the control loop could be closed by automatically adjusting lung ventilator parameters’ in response to changes in blood oxygenation levels. This has been implemented in experimental cases, but is not a mainstream solution.

At one point in my career I thought that the cutting edge of medical device development was working on therapeutic devices that delivered treatment to the patient, but I now realize that measurement can have just as big an impact on patient outcome. If doctor’s decisions are based on guesswork rather than raw data, then they are going to make less precise diagnosis.

Another area that has been revolutionized by measurement is running. In the past few years, consumer devices which tell you how far and how fast you run have come to market and proved extremely popular. Some are based on a foot sensor that measures how many paces you have taken, and others are based on GPS technology to measure the distance and route of the run. This is not just a replacement of a stopwatch – because the feedback is real time during the run, these devices can provide a motivating influence that is almost as good as having a running companion who is always a couple of seconds quicker than you.

One of the big advantages of using a gym (which I do not visit often enough, but that is another story), is that most activities are precisely measurable. If I am on the treadmill for 20 minutes, it can tell me precisely how far I ran and how fast. If I return to the gym tomorrow (well OK – next week), I can try to equal or better that run, which is a huge motivational factor. Even the gym activities that do not involve electronics allow me this precision of recording. The number of chin-ups or the weight that I bench press are numbers that are easy to record.

Road running always contains a vagueness that does not happen in the gym. Unless I run precisely the same route, I cannot compare times. Even with the same route, it is difficult to know how I am performing while I am on the run. I want real-time feedback, not just a result at the end – too late to motivate me to do a final sprint. A system that measures my pace as I run, and tells me whether I am faster or slower than my target speed revolutionizes road running. I can now pick any road and just go.

It is interesting to note a couple of the differences between the two main technologies. If you use a shoe sensor then it requires calibration to match your typical stride length. A GPS based system avoids this issue and also offers the advantage that it can record the actual route and later superimpose it on a map when the route data is downloaded to your PC.

The Nike+ system is a collaboration between Nike and Apple. At first glance I was surprised that Apple did not opt for the GPS solution. They are the kings of simplicity, and would have wanted to avoid the calibration step. While I am not sure what the rational was, a case could have been made that GPS raised other complexity issues – battery life means that you have to remember to charge the device between runs – at least that is true for the Garmin wrist-watch based devices. While GPS adds lots of extra information because it knows the route, it could be argues that most of that information is superfluous – the runner just wants to know how far and how fast. So maybe their rational was to choose to measure the things that help motivate the runner, but avoid flooding them with so much data that only the statistics junkie is interested.

There is a good article on the motivational effect of the Nike+ at http://www.wired.com/medtech/health/magazine/17-07/lbnp_nike

I also wondered about the effect of a shoe sensor that might have accuracy issues as terrain, weather and fitness levels varied. It then struck me that the accuracy would be rarely tested and so a few percent of an error would go unnoticed by the runner. If you are trying to break your personal best for five miles and your monitoring device tells you that you have improved by ten seconds, when in fact you have improved by 5 seconds, then you will not realize this. The important thing is that the motivational effect of seeing an improvement is still there. Accuracy only matters if you are comparing the results to some reference, and these devices are not used to record world records, so no one will really care.

Adding measurement and recording to a device can also introduce a bond between the device and owner, which has advantages in terms of marketing – the owner feels the device is like a pet dog that actually knows the owner. It has a disadvantage for the owner that it can become impossible to share the device. If I borrow my wife’s Garmin 405 to go for a run, it cannot tell the difference between my run and the ones my wife has done, and so her weekly mileage stats will be messed up. They could have incorporated a multiple-user feature, but that adds complexity, and I guess the marketing people figured it might also reduce sales. They would obviously prefer that each runner bought their own rather than have one device shared between two or more runners.

Have a look at your own designs and see if there are opportunities for game-changing measurements that will alter the way your system motivates the user.

More Smooth Sounds

2009-05-31T20:31:00.000+01:00

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

2009-05-22T09:30:00.003+01:00

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...

2009-05-07T20:29:00.000+01:00

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

2009-03-25T20:33:00.002Z

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

2009-01-19T13:34:00.003Z

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

2008-11-01T10:19:00.004Z

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

2008-09-24T20:45:00.008+01:00

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.

Stalemate - Providing Helpful Help

2008-08-06T04:42:00.003+01:00

I am sitting on a plane, and decided to have a game of chess with the on-board entertainment system. The player is required to first select the piece to move, and then the set of possible destinations for that piece are highlighted. The player then selects one of the destinations. At some point I selected a piece by accident. I now wanted to cancel that selection and move another piece. After some fumbling I did discover that it is possible to unselect the selected piece. It is performed by selecting the current location of the selected piece. This is not particularly intuitive, but it is easy to do once you know how.

During this fumbling period I decided to consult the games built-in help facility. I was disappointed. The help feature contained a lot of information on the rules of chess and even some interesting suggestions on tactics. However it failed to tell me how to use this particular implementation of the game. Most people who choose to play a game of chess against a computer probably already know what the legal moves are. Had I wanted to learn openings from the grand masters, I would have bought a book in the airport. However, no amount of chess expertise will tell me how to unselect the selected piece. When authoring the help they should have focused on the application specific knowledge first. The domain knowledge should be considered an optional extra. There are many places where the player can get information on how to play chess, but the built-in help is the only place that can tell the player which buttons do what in this game.

I have also seen this problem on a lung ventilator. The machine used an on-screen icon that I could not decipher. When I consulted the help, which was quite lengthy, I found medical definitions of the breathing patterns that the machine used. This is information carried in many medical text books. The meaning of the mysterious icon was not defined, and again, that is not something I could have learned on another machine, or investigated with a web search.
So when you are building help, focus on the things that will be new to your user, especially if your device or application does it differently to applications already familiar to the user population.

The second thing to bear in mind when authoring help documentation is that the more text you put on the screen, the less likely it is that someone will read it. Try to be brief, and focus on the areas where the user is actually likely to need help. Some help systems try to be complete, and in the process include paragraphs describing every button and option in the system. If a large percentage of these are easy to use, then there is a danger that the really useful help is lost in a sea of text about things that are already obvious to the user.

Now back to that Zukertort opening …

Wrong Number

2008-06-28T20:49:00.003+01:00

So some guy answered and I realized I had dialed the wrong number. I apologized and hung up. Unfortunately I was left with a dilemma. Was the number on the piece of paper in my hand the incorrect number, or had I accidentally mis-dialed one of the digits. The call was over and I had no way of knowing what number I had actually dialed, so I could not check the piece of paper against the number I dialed. If I dialed the number on the paper again then I might end up talking to the same guy, which would be embarrassing, and it is a bit rude to disturb the same stranger twice.

If I had been using a phone with a call-log, the screen might show me the last dialed number and I could check, but most simple land-line phones lack such a feature.

Bear this dilemma in mind when designing screens that tell the user that they have done something wrong. If you are telling someone 'Invalid ZIP code' or 'Too many digits in account number', make sure that the data that your interface is complaining about is still visible. Too often, especially on the small UI available to many embedded systems, the error message hides the data that the user just input, leaving the user wondering what exactly they did enter. The user may know what they intended to enter, but after the fact, they may be unsure. This often leads to the user entering exactly the same data a second time, because they assumed that they made some kind of a slip the first time.

Once you reach the point where you tell the user that they input the wrong data, it is often nicer to have the option of correcting the previously entered data rather than starting over. If I got the ZIP code wrong, I may just want to fix one digit, rather than starting all over. For a string as short as a ZIP code, starting over is a minor inconvenience. As the data they enter gets larger the price of restarting the data entry gets higher. So try to find a way to save the user's work so they can reuse the majority of it.

Handing user errors is a challenging area. Read more about it in an old article of mine in Embedded Systems Programming magazine called To Err is Human

How many jobs can one button have

2008-04-05T20:02:00.001+01:00

Sometimes it makes a lot of sense for a button to do more than one thing. An on/off button turns a device on if it is off, and turns it off if it is on. Obviously there is no need to have both possibilities available at the same time. The on/off button is a toggle button. A ‘select screen’ button could allow the user to iterate through each available screen, so each press of the button brings the user to a different screen on a GUI. When the last screen is reached, pressing the button again brings you back to the first screen.

An idempotent operation is one which has the property that if the operation is repeated then the result is the same. Pressing the number 1 button on my car radio is idempotent. Pressing it once brings me to channel 1. Pressing it again will bring me to channel 1 again, which changes nothing ( we will ignore the fact that some radios might change to channel 11). So idempotence is almost the opposite property to that of a multifunction button.

So when do multifunction buttons get us into trouble. Let’s look at a few specific examples. Many slide projectors have bulbs that take several seconds to warm up. If you turn the projector on, and then look at the screen, you may wonder if the device has turned on - maybe you did not press the on/off key hard enough. A natural reaction is to press the button again. If the on/off key is a toggle (i.e. a multifunction button), you have now turned off the projector, and will possibly start to think that the device is not working.

If this projector had a separate on and off key, then the on key would be idempotent and pressing it a second time would have no effect.

The stereo in my bedroom has a ‘function’ key which changes mode from FM tuner to CD player to tape deck and to Auxiliary input. Each time the button is pressed the small dark LCD displays the name of the current function. Unless you remember the order of the functions, you will not know what function you are about to get when you press this button. That is not a big deal, since you can press the button until you arrive at the function that you want. If the user presses the button once too often, and they go past the desired function then they have to go all the way around again. This is annoying, but is not the crux of the problem that we want to address here.

Consider the case where you can not see the LCD – it might be at a bad viewing angle from your armchair, or you may be listening to music in the dark. Now there is no reliable way of selecting the function. You could press the button and then listen, and hearing a talk-show host would obviously mean that you were at the FM tuner function, but that is not very satisfactory. Had the designers placed one button per function on the remote control then each of those buttons would have been idempotent and the user would have had a quicker, more reliable interface.

My cordless phone has a toggle button which allows it to go on-hook or off-hook. Such a simple toggle should cause little confusion, but it does. When I pick the phone up I often think “well I have picked the phone up, so I just have to talk, since that is how I answer a corded phone”. On this phone the call has not been answered by lifting it from its cradle – the on-hook/off-hook state is controlled only from the toggle button. Since this differs from the majority of old-fashioned corded phones, I pause to remember that I have to press the button. During that pause I think to myself “if the phone is off-hook now, then pressing the button will hang up, and I lose the call, and probably cause marital strife”. So I wait for the phone to give another ring before I am sure that it is on-hook before pressing the button. A good interface should not leave me so hesitant to press a button. Two separate idempotent on-hook and off-hook buttons would resolve this – many phone code these keys as red and green. With a dedicated off-hook button, I could press it, and if I was already off hook then no harm would occur.

Multi-function and toggle buttons do save space, but be aware of the drawbacks, and sometimes the right call is to use several buttons instead.

Kiss: Keep It Simple Stupid

2008-03-01T20:30:00.002Z

In one of my articles, available at http://www.embedded.com/story/OEG20011220S0060 I discussed how engineers like to present lots of data on the user interface, so that they user can derive further information for themselves. This is a slant that people of less technical professions might not appreciate. Typical users do not want to be blinded by lots of data, no matter how well presented. They want the data to be pared down to the minimum amount that they need to make their next decision

Always presenting lots of details does not suit all users and I came across an example of this recently. The system being analyzed was an ambulance tracking system that stored the locations of a number of ambulances which transmitted their positions to a central server. Third party mapping applications make it straightforward to display the position of all of the vehicles on a map which is displayed via a browser. This is obviously a far better way of presenting location information than simply providing longitude and latitude. Of course this looks fairly cool too. But a little further investigation showed that the better solution for many users was far simpler. At the hospital, they are only concerned with when the next patient is arriving, so they can ensure the people and resources are ready to treat him or her. So the only bit of information they want is the number of minutes before arrival. Again third party mapping applications can provide this data based on the current position. The challenge of the user interface, from the developers and from the users point of view has been greatly reduced, since now they have a simple number of minutes to display instead of integrating a mapping system into the application. The lesson here is always listen to the customer's needs carefully to ensure that you chase the simplest solution, rather than getting lured into making things that look flashy but may make it harder to interpret the really useful information, which in this case was time to arrival.

Very often you end up implementing the flashy stuff as well, because that is needed for the sales demo that gets you in the door. But that is very different from what is useful to the end user.

Making fun of Usability Specialists

2008-02-24T12:38:00.002Z

I recently encountered http://www.usabilitymustdie.com/ which is a site that satires some of the feedback that might come from dilbert-esque usability specialists. While most of it is over-the-top and can not be taken too seriously, it is a good thing that there is someone who who will call into question the value of, sometimes expensive, usability reviews by outside consultants. And the site is also a good laugh too.

While I was reading it, it set me to thinking about the real value of advice given by outside reviewers. One thing that occurred to me is that specific improvements to a single design are often of little value, especially if, as the design matures, that specific piece of the design vanishes. It is of far more value to teach the client how to recognize problems for themselves. If you can teach the reason for a specific improvement then the client can do many similar improvements for themselves. Looking at it from the other side, if you are the client, and improvements have been suggested, you should always ask 'Why?', if the consultant has not already provided the reason. Getting at the motivation for the change which will allow you to learn more.

Ironically teaching clients how to do usability for themselves could be doing yourself out of a job, but, hey, if you are adding real value then there should be no problem finding more clients.

Integrating the GUI and Off-screen Controls: Camera Example

2008-01-06T10:00:00.001Z

Quite often the GUI on an embedded device is driven by the software team while the off screen controls are designed by the mechanical or electronic designers. Sometimes this leads to a system were these two parts of the same device are not well integrated. I have seen cases were icons or names used on the GUI are not consistent with those used on the housing.

On the other hand some devices do a beautiful job of marrying the two types of input. On my Sony camera, there is a dial which allows the user to choose the mode. The dial contains small icons. When you turn the dial you get to see the full name and a description of the new mode. This vanishes after a few seconds, so the extra information does not clutter the image of the picture to be taken.

By also showing a rounded outline around the icons being selected, the on-screen image looks like an extension of the physical dial. In other words, rotating the off-screen dial also rotates a disk that is displayed on the GUI. While this is tricky to describe the brief video below makes the idea clear.

While many other cameras only repeat the icon on the GUI, Sony make this feature far better in two ways. One is that the extra text means that the user can learn the meaning of the icons without resorting to the user manual. The second aspect is the smooth integration of the on-screen and off-screen controls makes this device feel like a single user interface, rather than two distinct interfaces to two different parts of the device.

Tradeoff: Easy on the Eye or Easy to Use

2008-01-01T22:32:00.000Z

Traveling with work I spend plenty of time in hotels. I noticed that the more expensive the hotel, the more expensive the bathroom fittings. However the more elegant and eye-pleasing the taps and faucets, the harder it is to see which is the hot tap and which is the cold. Some designers focus on form and not function. That sometimes hides the information the user needs. Large red and blue plastic moldings take away from the ascetics of the design, but they do tell the person which tap is hot and which is cold.
The same principle applies to many embedded systems - there is a trade-off between pretty and easy-to-understand. That is why kids toys have big buttons in primary colors. Easy to see and manipulate but not so pretty to look at. Think about that the next time the mechanical designer on the team is trying to make the buttons small an discrete to avoid interfering with the smooth outline of your next product.

Lying to the User: An Ounce of Inaccuracy is Worth a Pound of Explanation

2007-12-24T10:00:00.001Z

Truth and honesty are much overrated. If user interface designers decide that users should always be given all relevant information that is available then we will probably flood them with data that they can not decipher.

Engineers like precision. They go to great lengths to select the most accurate sensors and then design calibration systems to iron out any inaccuracy introduced by manufacturing variability. They sometimes expect the user to appreciate that precision too.

I have seen many cases where a system at rest displays a measurement of 0.01, which leaves the user baffled when a reading of 0.0 would have made perfect sense. Users do not want a precise reading. They want to be reassured that the device is working normally. Sometimes a gentle lie is the easiest way to give that reassurance. The interface could display any reading below 0.05 as 0.00. An alternative would be to reduce the resolution to one decimal place, but there may be reasons for showing both decimal places at larger values.

Constantly changing signals can also be difficult to interpret. One of our designs had a lightbar made of LEDs that showed the pressure being controlled in a pneumatic system.

Because we had more LEDs than the product’s predecessor, the bar could show a variation of 0.5cmH2O, while previous systems only had a resolution of 1.0cmH2O. We received complaints that our system was not as good at controlling pressure than the older alternatives. We investigated and found that while our pressure control was just as good as the older devices, small variations in pressure were reflected in the bar. These variations are not visible with a lower resolution bar. So the older system was not more stable, but it looked more stable because small variations were not visible on the lightbar.

It was too late in the design to reduce the resolution of the bar. Instead we filtered the pressure signal to make it look more stable than it actually was. By hiding some of the true picture from the user, we made them more comfortable with the system, and this avoided having to spend time during training explaining to the customer the principles of our control system in order to explain the small variations in pressure. If the target users had been engineers then providing that accuracy on the ledbar, and providing an accurate explanation might have been appreciated by the users, but with less technical users, an ounce of inaccuracy is often worth a pound of explanation.

One of my client’s designed software for specialized mobile phones. They have a small market and designing the complete phone is not feasible. They buy in sub-assemblies but run their own software these phones. One of their customers complained that a competitor got a far better signal, for a specific distance from the cell tower. This surprised my client since they were using exactly the same electronic components, bought from the same suppliers. It turned out that the customer’s measurement of signal strength was based on the number of bars appearing on the LCD. My client's software reflected the signal strength by lighting up the bars on the LCD in proportion to signal strength. The competitor was lighting up more bars for the same signal. My client resolved the matter by using an algorithm that did not light up the bars in proportion to the signal, but weighted it to always light more than its fair share of bars. The engineer would have assumed that the amount of the bar that was illuminated should be proportional the signal available, but the customer was happier to be given an indication that was as optimistic as the competitor’s indicator. In this case it could be claimed that both competitors ended up lying to the user in equal amounts.

Welcome to Usability Bites

2007-12-24T09:25:00.000Z

Welcome to the Usability Bites blog. I will be posting occasional thoughts on the topic of user interfaces for embedded systems. If you want more meaty coverage there is full list of the articles I have written at http://www.panelsoft.com/murphyslaw. Most of these articles appeared in Embedded Systems Design, where I used to write the Murphy's Law column.

In this blog, the postings will be more brief and casual, but hopefully thought provoking.