Posts Tagged ‘GUI’

World Usability Day

Monday, November 9th, 2009

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

Wednesday, October 28th, 2009

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

Wednesday, October 21st, 2009

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.

Three Most Painful GUI Challenges

Monday, January 19th, 2009

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.