Thomas Williams

Remote Controls and Design

I'm the proud owner of a Logitech "Harmony" remote that controls the TV, DVD, and sound system in my lounge room. I'm not surprised at a recent (Logitech-sponsored) European survey that I read about at Jasper van Kuijk's blog which points out:

• in 25% of homes, there is only 1 person who knows how to operate all the technology
• 87% of homes have three or more remote controls
• 49% of homes have five or more remote controls

I can openly say that my Logitech remote was one of the best tech buys I've ever made. It's key feature is that it groups commands around "activities". Click the "Watch a DVD" button and it switches on the DVD player, sets the sound system to input from DVD, and switches the TV on to the right input. Click on the "Watch TV" activity and the TV and sound system are set up correctly. And best of all, click "Off" and whatever is switched on, gets switched off. So easy even the kids can use it!

Tags: design, remote control, logitech

A Short Rant on One Example of Why Over-Engineering Stuff is a Problem

We've got a boiling water unit in the tea room that I pass by every day, that is over-engineered. I feel a short rant coming on...

This boiling water unit's primary function is to deliver boiling water, so people can make their instant coffee or tea. It does this well - there's a big black button that, when pushed, runs boiling water from a nozzle directly underneath the button. So far, so good.

If the boiling water unit was limited to this functionality, it could be regarded as a success. However, it also has:

• an screen with the time and day of the week
• four nameless touch-sensitive buttons (which are very cool - all you have to do is hover your finger near them and they flash red...but what do they do?)
• a red "lock" LED
• a switch that has a label "Lock", that is miles away from the LED

Why this over-engineering is a problem is that because no-one needs the time or day of week, no-one has set it. So now it's wrong. Further, there's no clear way to set it (unless you can find the manual). Why have the touch-sensitive buttons if they don't do anything? And why not have the "lock" switch in a visible location, and ditch the LED altogether?

Whoever made the boiling water unit could simplify it by removing the cruft, and so actually improve it. End rant :-)

Tags: design, water, engineer

Featuritis - Adding Features Causes Pain

BugTracker.NET's Corey Trager posts about "featuritis" - one simple definition is where continually adding features to software eventually pushes users beyond happiness. Corey references Kathy Sierra's original post which explains it a lot better than I can here (and has a nice graph too).

I have two counter-arguments to the simple definition of "featuritis": discoverability, and user personas (to be fair, Kathy goes into a lot more detail and her post is well worth reading).

If an application adds new features but makes them hard to discover, or does the opposite by adding new features and making the older ones harder to discover, then users will be frustrated. Microsoft Office is a classic example of an application that keeps adding features, attracting derogatory terms like "bloatware". However, Office 2007 has addressed the discoverability issue by better grouping of commands via the ribbon (yes, you may not agree with me, but I only said addressed the issue, not necessarily solved it).

My second objection to Kathy's original graph is that it lumps all users on the one scale. I reckon that for different types of users (e.g. personas), more features would actually be a good thing. Here's my take on it:

For a "power user" (you know who you are), I reckon more features make an application more attractive, although there will be a point where the "where the heck did they put that feature?" syndrome kicks in (let alone the problem of adding features at the expense of fixing existing features).

With this post I'm just making the point that adding more features does not necessarily frustrate users, especially when you take into account discoverability and different types of users. "Featuritis" is a problem; Kathy has still got the last word on it when she says that developers should "give users what they actually want, not what they say they want. And whatever you do, don't give them new features just because your competitors have them!"

Tags: featuritis, user, features

Don't Show 'Time Taken: 456.6 seconds' to Users

Instead, use this basic "natural language" elapsed time function in VB.NET.

I use this simple function to show elapsed time in the user interface. It came about because although I believe it's useful to provide some feedback at the end of long-running processes, I was getting sick of strings like "Time taken: 456.6 seconds" which is indecipherable to real people.

This VB.NET function returns a string like "less than 10 seconds", "under 1 minute", "around 4 minutes" which, as you can see, changes the unit of measure depending on how long the elapsed time is:

I'm also trying out the Simple-Talk Code Prettifier (via Mladen Prajdić) which this version of Community Server does not like (how old is the version DNJ is running anyway?).

For recommendations as to where you might display the elapsed time to users, see SSW's Rule To Better Windows Forms.

Tags: time, code, vb.net, natural, development

Book Review: Defensive Design for the Web

I've recently finished the excellent Defensive Design for the Web, authored by some of the people behind 37 Signals (Getting Real, Signal vs. Noise blog). The book is subtitled "How to improve error messages, help, forms and other crisis points", and is referenced in Steve Krug's Don't Make Me Think - one of the key reasons behind me reading it (I enjoyed Steve Krug's book a lot).

At only 246 pages, Defensive Design is a short book which means it's a quick read (and not very expensive!). There's lots of illustrations, and the book is neatly divided up into digestible chapters, like: the sort of language you should use when something goes wrong, how to display error messages, how to design forms, help design (FAQ's, Help section, contact information), search options and more.

The authors describe "defensive design" as "contingency design": "design for when things go wrong". The book includes 40 guidelines with lots of examples from actual sites (as of 2004, although in some cases not much has changed), and, helpfully, comparisons to a real-world/non-tech example (for instance, comparing searching a site for "mops" and ending up at "electronics" to the experience of walking into a Target store and getting the same directions).

Like Don't Make Me Think, there's not any code. Most of the guidelines aren't about code but about design choices, and I can understand that providing code would be tough...should the code be PHP, Ruby, ASP.NET, etc?

I would highly recommend this book. It provides clear, simple advice for what to do when coding for errors. Even though I design only intranet sites, this book has helped me rethink the help I provide, and perhaps helped give substance to the advice I read on blogs but find it hard to argue a case for with my boss!

Haven't heard enough praise? Here's some more reviews of the book.

Not sure? The publisher's site has a downloadable chapter.

Tags: book, review, usability, design, web, error

CSS Layout Generator

I'm definitely CSS-challenged, so I was interested when I found the CSS Layout Generator, which allows you to enter how many columns, whether you want a header and/or footer, and colors for your page layout. It then provides the CSS and HTML, optionally validated for HTML or XHTML (link via Daniel Walzenbach, via Jason Haley).

Tags: web, layout, design, css

Gripes: Outlook 2007 Interface Inconsistencies

I've been really enjoying Word and Excel 2007. They work as expected and I actually prefer the new "ribbon" to the old toolbars and menus. I even know where to find most of the functions :-)

However, the Outlook 2007 interface is a little "inconsistent" (the program itself is fine). First, a quick screenshot:

Here are my five gripes on the Outlook 2007 interface:

• Outlook should use the "ribbon" interface. I like the "ribbon". Word uses it. Excel uses it. Why can't Outlook?
• The double-chevron above the To-Do bar expands the To-Do bar, and "pins" it. However, only the double-chevron is selectable which presents a very small target. A better way to do this would have been to remove the double-chevron and use a Visual Studio-esque "pin" icon to keep the To-Do bar open.
• The scrollbar for the meeting request heading is not themed. The scrollbar for the meeting request content *is* themed. I have themes turned off (but Office 2007 still uses it's own visual style). This should be consistent. 
• The meeting request buttons are not standard. They should be either a toolbar button or a normal button, but not a different style from every other button.
• There's no mouse-over effects on column headers. I don't know if this is because I have visual styles turned off or not. It's just there's an orange mouse-over effect on just about everything else (except the blue for scrollbars, and silver for some other things) and I reckon column headers deserve a mouse-over effect.

Here's some of the things I *do* like about the new Outlook interface:

• The entire To-Do bar on the right hand of the screen is clickable. A click expands it, and mousing away from it retracts it. This is good because the feature is easily discoverable, and repeatable with no side effects.
• The To-Do bar is really helpful. Two thumbs up.
• The Calendar has been improved, adding links to previous and next appointment when you're in "Day" view. This makes it easier to navigate your way around appointments.

Tags: outlook, user interface, office, ribbon

A 5-second test for your User Interface

Here's an interesting metric (via Usability in the News) for testing websites:

Q: “What percentage of your interface contains stuff that your customers want to see?”

1. 10%
2. 25%
3. 100%

If you answer a, or b then you might do well, but you'll probably get blown out of the water once someone decides to enter the market with option c.

(continued at "A really simple metric for measuring User Interfaces" at iQ Blog)

This test could easily be applied to utility-type software whether web or windows e.g. Flickr or WinZip (it would be a little harder to apply the principle to fully-fledged applications, where "infrastructure" user interface is impossible to avoid).

37 Signals calls this kind of approach "epicenter design" in its online book Getting Real - start with main thing the user will need, then the second most, then the third, and build outwards.

Tags: user interface, usability, design

Book Review: Don't Make Me Think, 2nd Edition

Steve Krug's Don't Make Me Think is a thin book that packs in a lot of good stuff.

After reading only a few pages the strong points of the book stand out: easy to read, lots of practical examples, often funny, and technology-agnostic. I like good writing and Steve's style alone makes the book worth reading. However, the bottom line is that the content is fantastic and I think the brevity of the book works in its favor. The book is not the be-all and end-all of web usability but it's a good start that will appeal to designers and developers - I'm definitely in the second group - and hopefully non-technical people too.

One aspect of the book that you could take as either positive or negative is Steve's lack of precise, exact "do this" lists. It seems that he prefers dealing with broad ideas which I reckon gives his book better durability through cosmetic changes to web sites, making the book a little more timeless. For instance, Chapter 6 of the book covers navigation, and one part talks about how a tabbed interface works from a design point of view, rather than the best library to use for creating sliding, fading tabs in JavaScript.

Steve does lay out some rules, his first being the title of the book. He explains that web pages must be bleedingly obviously self-evident as to their purpose (he puts it better that that, of course). He then goes to look at some other guidelines, and sites that get it right and wrong. One part of the book is dedicated to usability testing. The final section covers accessibility and looks at CSS.

A couple of key things I took away from the book in terms of design and usability:

• keep things really, really simple
• do usability testing
• make the main page elements stand out (page title, section, navigation) and keep them consistent throughout the site
• halv