embedded software boot camp

World Usability Day

November 9th, 2009 by

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

October 28th, 2009 by

I came across this link recently:
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

October 21st, 2009 by

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

October 12th, 2009 by

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 …

September 27th, 2009 by

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.