Author: Jochen Wolters

A Hardware Checkbox for Daylight Saving Time

For those of us who live in countries that observe daylight saving time, a little peculiar clock adjustment dance around the house has become a ritual that we perform twice a year. Going from device to device, we adjust all our clocks by one hour.

Most state-of-the-art computer operating systems can do this automatically or at least provide a simple checkbox to de/activate DST.1 Hardware devices like microwave ovens, video recorders, or alarm clocks, however, tend to require much more effort, since adjusting the clock on such devices usually is a tedious affair to begin with.

Enter the “DST hardware checkbox” which I found on an alarm clock radio. Thanks to this switch, adjusting the clock for daylight saving time (almost) becomes a no-brainer.

The switch is mounted on the back of the device, but is still easy to find, and the label is big enough to read. In fact, thanks to its location, it does not add any clutter to the UI elements on the front panel that users access much more often.

The switch could be made even more user-friendly by making its labels more meaningful. Unless you read the clock’s manual or just try out what that switch does, the “ST” label and the little “sun-rise/-set” icon may be a tad cryptic. Also, the settings “-1” and “+1” feel odd to any math-savvy technophile.

While replacing the “-1” with a “0” and the “+1” with “+1h” could be a small step in the right direction, why not go ahead and label the switch like this:

This would also provide a kind of “built-in documentation” for all of those people who, every time “ST” turns to “DST” or vice versa, have a hard time figuring out whether to set the clock forward or back by an hour.

Update 2010-11-19: Via email, Scott McIntyre pointed out a problem with the DST switch:

The tricky bit with the DST switch is that a naive user will just set the clock for the first time without regard to whether the switch is in the right position, since it doesn’t need to be set in the right position to get the clock to show the right time. So when DST time change comes around, the switch will either work magically (woo!), or will set the time the wrong way and be useless.

In that case, I would expect that the user has tried to make sense of how the device works by deducing the controls functions from their labels and/or by playing around with them. Had she read the documentation, she would have learned how to use the DST switch while following the setup process for the alarm clock (assuming that the documentation would explain the switch as part of the “getting started” instructions, that is).

It would make for an interesting usability test to analyze this kind of discovery process: ask people who are not familiar with the device to compile a list of its features, and explain how these features are accessed and operated — without letting them read the device’s documentation.

What happens when they come across a control whose function they cannot deduct from the control’s label: will they play around with it until they find out; will they eventually want to resort to the manual; or will they choose to ignore it altogether? And in case of the latter, will they go back to such a previously-ignored control later on to find out what it does, after all?

In a way, this goes back to two key usability concepts: “visibility” and “speaking the user’s language.”

A device that clearly communicates its feature set to the user through highly visible, clearly labeled controls, makes it much easier for the user to gauge the features’ importance, and decide which of them to use, and which to (consciously) ignore.

In that sense, a user who immediately understands that a particular control is used to switch between “standard time” and “daylight saving time” by just looking at the very switch itself, will either know what to do with that switch, or skip it. In which case I would expect them to ignore it in the future as well.

What’s more, a user who does use that switch in the scenario that Scott describes, would need to “grok” it just once, namely when incorrectly ”adjusting” the clock for DST by throwing that switch. When that happens, it takes a one-time correction of the device’s clock to ensure that it will work in the future.

  1. For a related topic, see my article “What Time is Your Zone?” about selecting a computer’s time zone under Mac OS X, Ubuntu Linux, and Windows. ↩

A Corkscrew With a Twist

Winemaking is an ancient culinary technique. Storing the result in glass bottles is an ancient culinary technology. And de-corking a bottle of wine must have been a major nuisance ever since a bottle was first sealed with a piece of tree bark back in ancient times.

There are countless designs of “de-corking devices”2 that are so intricate that simply calling them corkscrews would be a disrespectful understatement. And then there is the so-called “sommelier knife,” which, in my most humble opinion, still is the most elegant solution due to the sheer genius of its simplicity.

A sommelier knife — also known as the waiter corkscrew — looks like a plain corkscrew with the helix mounted via a hinge, so that it conveniently folds away for easier storage.

The nifty part is a little lever at one end of the handle: after you screw the helix into the cork, this lever is placed on the rim of the bottle’s neck. You then gently force out the cork by lifting the other end of the handle.

“Gently” is the keyword here, because there is no uncontrollable release of force once the cork pops out of the bottle’s neck, as you may encounter when using a plain old corkscrew. You’re also less likely to break the cork while pulling it out.3

The only minor drawback of a regular sommelier knife is that you can’t fully twist the helix into the cork, or you won’t be able to properly place the lever on the bottle anymore. Similarly, if you don’t insert the helix far enough, you won’t be able to fully remove the cork from the neck without adding a few extra twists between pulls.

The solution to this problem is a wonderful example for the power of simplicity: as you probably have noticed in the above image, the lever on this specific sommelier knife is divided into two segments. These are joined together with a hinge, and both segments are shaped so that each can lock onto the bottle’s neck.

Thanks to this design twist4, you simply screw in the helix almost all the way, place the first lever segment on the bottle neck, pull out the cork half-way, and repeat the process now using the second lever segment.

When actually opening a bottle with this tool, you would firmly wrap your other hand around the bottle’s neck. Doing so prevents the sommelier knife’s lever from slipping off, and it also keeps the bottle from toppling over. (Which is quite the impossible challenge when you’re taking pictures of the process without having a tripod at hand, of course…)

  1. For an overview of what’s available, have a look at this selection of “wine openers” at an online retailer. (Just an example, not an endorsement.)  ↩

  2. That statement is based purely on personal experience and observation. Your cork breakage may vary. ↩

  3. That must be the cheapest pun I have ever used, but I just couldn’t resist. ↩

Treacherous Toggle Buttons

Using a single push button to start and stop a car’s engine has become fashionable in recent years, especially with premium brands. One of the reasons behind this design change away from the usual starter key twist may be found in marketing, what with such a button conjuring up images of the engine start buttons found in classic sports cars. Combined with state-of-the-art electronic keys that wirelessly unlock the car, however, placing such a button in a prominent location on the car’s dashboard may also positively impact usability.

A key aspect of toggle push buttons is that the user knows exactly what will happen based on the current state of the function that it controls. In the case of the car engine, the relationship between state and function is straight-forward:

  • engine is not running ⇒ button will start engine
  • engine is running ⇒ button will stop engine

In other words, as long as a push button is controlling a single state, its toggle function is unambiguous. But what if more than one function is hooked up to a single button?

The little toggle button that could not

MAMP5 is an awesome tool for website development under Mac OS X. It comes with everything you need to run a full-featured self-contained web server environment locally on your Mac. All it takes to install the software is copying the MAMP folder to your computer’s Applications folder.

And all it takes to start both the included Apache and MySQL servers, is clicking a single button in MAMP’s control dashboard. Implemented as a toggle button, this single control is used not only to start, but also to stop both servers. And there’s the rub.

When I upgraded the MAMP installation on my iMac to a new version, I must have made a mistake when I copied over the old database configuration files: Clicking the Start Servers button successfully launched the Apache web server, whereas MySQL failed to start. Clicking the toggle button a few more times didn’t help, even though its label still said “Start Servers.” So how could I stop the Apache server now?

The MAMP application also features a Server menu with separate items for starting and stopping the servers, but the Stop item is grayed out unless both servers are running. The only work-around I could find — without resorting to methods outside the MAMP application — was to check the “Stop Servers when quitting MAMP” option in the preferences.

Give me more controls!

A single toggle button controlling multiple functions will only work properly if those functions always change their operation states coherently and concurrently.

A bit of lag between the state changes is perfectly OK, but as soon as there is even a remote chance that multiple functions may end up in multiple, different states, additional controls are an absolute necessity.

In the case of MAMP, it would be nice to see two separate buttons for starting and stopping the servers. The very least would be enabling the Stop [Server] menu item as soon as one of the two servers has properly launched.

  1. Macintosh/Appache/MySQL/PHP ↩