Monday, December 27, 2004

Not a Drop to Drink, Pt. 1

No rest for the weary or the professional nitpicker. My xmas break afforded me a number of examples of either bad UI or dodgy instructional procedures for toys.

Perhaps my favorite occurred at a neighbor’s party, when I attempted to get a glass of water. Someone directed me to the refrigerator, one of those newer models that provides filtered drinking water to thirsty homeowners. There was indeed an obvious port in the door, topped by what amounted to a toolbar of icons for different services. After a brief attempt at deciphering them, I was directed to the one on the left which was supposed to symbolize water.

I placed my cup under the icon…nothing. I pushed on the cup. Nothing. I pushed the icon, thinking it might be a button even though it didn’t really look pushable. Nothing. Someone had to walk me through what should have been a completely intuitive and easy process. The nozzle for the water was not actually under the icon, although it was indeed to the left of the services port.

I had the rare experience of feeling like an idiot and simultaneously a pretentious nerd when I turned, slightly red-faced, to the gaggle of amused onlookers and said, “Bad interface.”

A number of lessons here: Make sure your icons are understandable at a glance; if you want people to push a button, make it look pushable, and if not, don’t (i.e. is it a button or just an icon?); and make sure your controls are placed as close to the object they affect (like my cup) as possible.

Not a Drop to Drink, Pt. 2

Hello again,
Here’s a great example of a technological breakthrough meant to make life easier for people (at least I guess that’s the rationale) that simply backfires.

Ever seen one of those sinks (typically in a public restroom) that operates by infrared or motion detection? You’re supposed to pass your hands under the faucet and produce a stream of water.

It’s a hazy memory now but I seem to recall being totally stumped by this when I first encountered it some years ago. The best examples actually provide some sort of explanatory signage, but not all do. Toilets proved especially anxiety-provoking without physical flushers, whereas faucetless sinks simply resulted in (aside from grubby hands) impotent rage -- ever-popular with those poor souls foiled by hardware. Well, that was then…you’d think I’d have gotten the hang of it by now.

And yet…and yet… I regularly encounter such fixtures and find them unable to produce the desired effect. I walk away from the urinal…nothing. I wave my hands like a madman under the faucet…nothing. I look for some hidden button, I try like an idiot to press or turn the faucet. Am I doing something wrong? Has the water been turned off? Is it just a defective sink? Typically the latter is the case, since other sinks (often provided with those silly antiquated devices called handles) do happily gush with water.

Lessons: Provide more than one way to do your task with a secondary control. Provide some explanation for your control even if you think everyone will know how it works; some of your users will never have encountered it before.

Thursday, September 16, 2004

A Good Time was Had by All: OK/Cancel

Whew, that last entry took it out of me.

So, to keep this one short and sweet: here's a site that has it all: UI-related commentary, cartoons, job listings, links... a good place to settle down for a spell.

And for good measure, another great site is, which is, as they say, a "collection of widgets and UI elements from various websites, with notation of their sterling or plate metal qualities."

Anyone out there know some UI sites they'd like to crow about?

Tuesday, September 07, 2004

Car Dashboards

I’ve just returned from a month in Europe. Aside from providing a welcome break and fantastic sights and experiences, the trip offered me many chances to whine about new and different user-interface issues. Plenty of grist. Let me start with:

Car Dashboards

Well, let’s say car controls in general, especially when unaccompanied by user manuals. In particular my rental Renault Megane Scenic, while all in all not a bad car to drive for a week, was good for several rants.

First of all, the key. The key does not look like a key. It looks like a fat, black credit card. There is nothing approximating a keyhole on the outside of the car door. Since I’ve used a similar device before (though attached to a standard key) it was easy enough to get into the car, but what about novices? I must say that the icons on the little nubs that you press to lock and unlock the door are very hard to interpret (black on black = lousy contrast). You have to memorize the nub position, making sure the cardkey is right-way up in your hand; it’s a bit like Braille. Fortunately there aren’t many blind drivers. I did wonder how I would enter the car (to say nothing of driving it) if the batteries in the cardkey wore out or I accidentally ran the keys through the washing machine. Duplicate keys aside, shouldn’t there be a backup system?

Logically enough, the keyhole inside the car also looks nothing like a traditional keyhole. Anyone unused to working a cardkey at their place of business, for example, would be clueless. I do use one, but because it is a thin, white one with my picture on it, I was still momentarily clueless as to what I was supposed to do next. I suppose you could think of the key as being like a bankcard that you insert into an ATM…. I was further stymied by the fact that the slot into which the cardkey slid was located (right-hand drive notwithstanding) nowhere near where I expected it to be, but relatively high up on the dash amongst many other cryptic and unusually placed controls, and with no text or light or anything else calling it out. The slot looked more like a lacuna than an object. The user’s first task should be obvious.

Furthermore, being a cardkey, it did not turn the way a key does, and the Avis fella had to point out to me the Start/Stop button on the dash. I was embarrassed not to have noticed the text (small) on it, but who would have thought to look for such a thing? Slightly reminiscent of the fail-safe system where one soldier inserts the key to unlock the missiles and then another grunt across the room pushes the button to arm them. How many actions should it take to perform a simple task?

I also found that although I could effortlessly remove the cardkey while the engine was running (unlike standard car keys in my experience – doesn’t that seem dangerous to you?), pressing the Start/Stop button at that point did nothing. To turn off the engine, I had to reinsert the key and then press it. Inconsistent, to my mind. Either require the key to be in, or not.

Starting the car also depended on a number of other factors. The transmission (it was a manual) had to be in neutral and one's foot had to be on the brake. In my own car, if I stall, for example, I can simply step on the clutch, twist the key, and be back in business in a second. Thank goodness the Renault didn’t stall in the middle of a turn across traffic, or I would have been toast, what with all the shifting, foot action, and button pushing. Not to mention the prompt reading.

You see, to make matters worse, if not all these prerequisites were followed, not only would the car infuriatingly refuse to start, but a rather inconspicuous and further infuriating message would appear, buried among gauges and lights and so on in the dashboard pane, telling me to put the car in neutral or whatever was wrong. It took me a while to discover this prompt. Because the display area was so small, only part of the message would appear at a time, and then scroll automatically to the next portion. Orange letters on a black background like some antique text-based computer monitor. If you’re going to display an error message, make sure the user knows it’s there and can read it easily.

Finding the data

Aside from the odd chiding, one of the first things I noticed about the dashboard was that it didn’t tell me normal things I expected to have access to – such as what my mileage was. I didn’t care so much about the total mileage of the car, but how far had I gone so far? (Perhaps an obsessive desire, but a common one, I think.)

Convinced that there must be a way to display this, I consulted a friend who has a Citroen, and even she was stymied. Eventually I pressed every conceivable button I could see and finally found what I wanted. On the very tip of the abbreviated stalk (why so short, what if I were a small person?) containing the windshield wiper controls, out of my sight if I were driving, unless I leant unsafely over to the right, were two small buttons with arrows on them – one pointing up, one down. As I pressed the buttons, the dashboard display cycled through an impressive amount of data, including the miles traveled, the current miles-per-gallon average, the estimated remaining distance possible relative to the remaining fuel, etc. But the control was located almost invisibly, with no textual clue and an uninterpretable icon – and nowhere near the dashboard. Controls need to be located near the area that they affect.

The other controls that were nearly impossible to find were the hood release (once I found it, on the passenger side—why?!—I still couldn’t actually open the hood) and the gas cap release (because there wasn’t one, ha ha, joke’s on me). The rest of the car was either newfangled or out-and-out automatic (see next section) but any old yobbo could flip open the gas cap and siphon out the precious fluid ($1.60 a liter, for criminy’s sake). Again, consistency of control paradigm would be sensible.


Some might think that even Great Britain would be relatively dry in the middle of August. Oh well. The windshield wipers got a workout, and I found that they had a mind of their own, or at least half a mind—and again the user interface left a lot to be desired.

Perhaps the automation itself was a worse feature than the actual interface here, because although it seemed fairly intuitive that increasingly or decreasingly large icons of raindrops indicated how fast your wipers should move, there was usually no detectable result, because the wipers were obeying some higher law concerning how much rain on the windshield would allow or provoke them to increase or decrease speed. Finally I noticed that even set at the standard speed, they would change velocity on me of their own accord, but seemingly contrary to the actual severity of the rain. Weird. Predictability is important.

An other very weird automatic feature was the parking brake, of all things. Maybe this is de rigeur in newer cars; my newest car at home is only a ’95. But I like to be able to control some things. If I want to sit in the car with my engine on, listening to music or running the heater or wipers, I may well want the parking brake on. Don’t want to roll down the hill, for example. Apparently with the Renault, as soon as the engine comes on, the brake goes off, and as far as I know can’t be set back on again. The Avis guy tried to explain it and failed (maybe it was his Glaswegian), but it appeared that you pull a lever to set the brake (which is what I do to set my brake typically) and push a button to release it (which in theory you’d never have to do because if the engine is on, the brake is off). A couple of principles were broken here: Try to be consistent with standards, and give the user control.

Renault owners are welcome to correct any technical misapprehension on my part. But my point is that automation, while whizzy, is not always desirable. When designing, you should make sure the user has at least the illusion that he or she is in control, particularly when you’re talking about critical features like how to not roll off a cliff.

Monday, May 24, 2004

The Naming of Parts

A sure way to subtly please customers: Ensure that the UI text (button labels, link text, and so on) is synced up to the text in Help, FAQ, and other references in UI.

In the not uncommon event that the UI designer and documentation writer are different people, communication between these parties is critical!

Seems like a no-brainer, but... speaking from experience this week in trying to set up a new ISP, there is nothing more frustrating than attempting to follow instructions and finding that what you're looking for does not exist in the place where the instructions say it exists.

Thursday, May 20, 2004

Static Text and Screen Readers

Burning issue: Acommodating low-vision users

Here's something that sometimes falls through the cracks when designing UI: people with low vision might need to use a screen reader to work their way through your interface.

Several issues arise in this scenario, but let's just touch on one for now: You might have static text on a screen (that is, text that's not affiliated with a control such as an option button). This could include explanatory text for a dialog box or explanatory dynamic text that changes depending on what's been selected.

Because the user can specify how much information to have read aloud, this text might not get read as the screen reader moves down the screen; and if the user simply presses TAB to move quickly among options, this static text will probably not get read. If at all possible the UI should mitigate this by making control label text as clear as possible.

Wednesday, May 19, 2004

More Bloopers - GUI Bloopers by Jeff Johnson

More Bloopers - GUI Bloopers by Jeff Johnson

Acronyms in UI

Burning issue: Using acronyms in UI text

Some folks use acronyms whenever the mood strikes. One problem when writing for a wide audience is that many (most?) acronyms are pretty arcane. If using an acronym is unavoidable, you should ensure that the user understands it -- if it's not a common one (such as DVD), is it spelled out on first use on the screen?

Also if your content is translated into other languages, you should ensure that this won't raise localization issues pertaining to the acronym.

Check your in-house style manual, or guides such as The Chicago Manual of Style, for additional guidelines about using acronyms in headings and titles. The Internet can be a good usage resource too, although not wholly consistent. At any rate, you should ensure that the acronym is spelled and capitalized correctly in your UI, and used consistently.

You also should check with your legal department, if you have one, to ensure that there isn't a trademark issue.

Only pluralize an acronym when it's appropriate to the context, unless the spelled-out version is itself plural. For example, adding an s to FAQ isn't necessary because the Q already stands for questions.

It might be advisable to avoid acronyms unless necessary -- for example, if you have space constraints.