flow|state

Approachable UI package in Garmin Nuvi GPS

The new Garmin Nuvi GPS presents a well thought-out UI, cleanly knitting together three modes of interaction: display, touch, and audio.

Garmin and other manufacturers have been making GPS units since the late 1980s, and during that time have continually made incremental improvements in size, form factor, performance, and UI. From time to time I've looked at the category, but beyond the flat-out magic of finding your way using satellites, I found little captivating about the products themselves. GPS units have suffered from a wide range of UI problems, such as the heavy use of jargon, awkward use of a few buttons to accomplish complex tasks (such as entering an address), and cumbersome systems for transferring maps to a device with limited memory.

Sometimes you encounter a product and get the strong feeling its the first one in its category to really be Designed, with a capital "D". In my case, TomTom had the first GPS with that distinction. From the branding to the startup sound to the UI, they had clearly thought about the product as a consumer experience. Despite breaking that ground, I still felt that the TomTom product I saw came up short.

The Garmin Nuvi is the first GPS I've seen that meets my bar for a good user experience. They've given a lot of thought to an overall package of functionality a traveler might want in a single pocket device. In addition to the GPS, the Nuvi unit includes an MP3 player, a photo vault, a currency converter, a world clock, a foreign language dictionary, and a travel guide. This is a good sign that Garmin's considering the overall user experience of the device, not just trying to make a housing for a satellite receiver.

You can read thorough plenty of reviews of the Nuvi elsewhere, so I'll focus on the nice bits in the user experience:

• Clear screen organization, with careful use of color, shape, contrast, and typography to define a hierarchy of screen elements. Consider that in the above image they've made the "200" in a significantly larger font than the "m" (meters) unit that follows it. Moreover, they've top-aligned the "m" unit to maintain the legibility of the much more important number. In this particular application, it's critical for the user to be able to glance down at the screen and get a sense of how far they have to go until they need to turn. That is, if they see three characters, they know they have hundreds (3 characters) of meters left to go, not thousands (4 characters). Displaying the units as "200m" in the same font and aligned along the text baseline would make it harder for the user to intuitively grasp this.
• Responsive touch screen. Unlike some folks (like Toyota), Garmin generally makes good use of buttons placed flush against the corners to improve the chance you'll actually hit what you want. (The map screen above is an exception.)
• Generally solid implementation of a BBOP (Back, Buttons, One Task, Page Based) UI. One small nit: they show a Back button on almost every page, but not on all pages. In particular, if you click the Menu button in the main driving map (shown above), you end up a menu page with no clear way to get back to what you were looking at. It turns out you need to pick one of the menu options: the one called "View Map". I found this counter-intuitive. In general, I think that if you're going to offer a Back button on the screen, you need to offer this button on every screen and in the same location.
• Judicious use of "transparent" buttons on maps to add UI elements that take up a surprisingly small amount of actual screen pixels. The Zoom In/Out buttons shown above are roughly 46x46 pixels square and the border is two pixels thick. The borders only consume about 350 pixels, and for that price they get a pretty big transparent button. A transparent button like this consumes about the same number of pixels as a 19x19 solid button, which would be incredibly tiny on a touch screen.
• Reasonably good voice prompts with text-to-speech. I was impressed with the Nuvi's ability to not only pronounce local street names, but to apply fairly natural phrasing and intonation to an entire instruction. I do think Nuvi and similar products could benefit by tightening up the phrases they're trying to read. No human passenger includes street type or direction markers when giving instructions to a driver, unless such information is currently salient. Instead of saying, "Turn left of East Galer Street" like the Nuvi does, people say, "Turn left on Galer". People generally add more information like "East" only when that helps discriminate among the current roads the driver can turn down. It would be relatively trivial to add this refinement to a GPS voice UI.

Overall, a nice information appliance.

Okay, death *TO* the lame Recycle Bin confirmation dialog in Windows

Thanks to those of you who pointed out that the first Windows delete confirmation dialog described in the previous post only appears when the user presses the Del key, but not if they use drag and drop. (I'd been trying to reproduce the dialog using drag and drop.)

Both Windows and the Mac offer multi-key keyboard shortcuts (Shift+Del and Command+Backspace, respectively) to delete a file without displaying a confirmation dialog. Since the Mac doesn't offer a single key shortcut for deleting a file, it has no need of a confirmation dialog. Personally, I find this to be an elegant answer, although it's inconceivable that Windows would take its Del shortcut away.

I still argue that the dialog in Windows should fade away. As a comment to the earlier post describes, the dialog would be an appropriate place to educate the user on how the Recycle Bin works, where to find it, and how to get things back out of it. Once the user has figured out how the Recycle Bin works, they should be able to easily get rid of the dialog with an option in the dialog itself (and not in a property dialog far away). Alternatively, Windows could simply track user actions and determine when the user no longer required this education.

Death of the lame Recycle Bin confirmation dialog in Windows?

Before leaving behind the previous topic of deletion patterns, let's briefly look at one of the weakest implementations of the Trash pattern anywhere: the Recycle Bin in Microsoft Windows. On the Mac, when you move something to the Trash, it moves to the Trash. In Windows, when you move something to the Trash, you get this:

When Microsoft appropriated the Trash pattern (from Apple and Xerox), it was apparently helpless to resist the desire to protect the user with a confirmation dialog—even though the entire point of the Trash pattern is to avoid irritating the user with a confirmation dialog. File this one under, "Unclear on the concept".

For what it's worth, both Windows and the Mac display an additional confirmation dialog if you manually invoke the Empty Trash command. The Windows dialog says like, "Are you sure you want to delete these <number> items?" The Mac dialog says: "Are you sure you want to remove the items in the Trash permanently? You cannot undo this action." It's a matter of opinion, but here I give a slight preference to the Windows version, since the Mac dialog is redundant; an action that's permanent is, by definition, an action that can't be undone. (You could also argue that, if you know how to use  disk utilities, the delete operation isn't actually permanent. Either way, the dialog is wrong.)

The confirmation dialogs in the Windows means the lucky user has at least three chances to avoid accidental deletion! They can: 1) say No to the first confirmation dialog, 2) Undo the move to the Recycle Bin, or 3) say No to the second confirmation dialog. It's nice to know that, with all this protection, no Windows user anywhere has ever deleted something they didn't want to delete.

It's possible that Microsoft has silently made some progress on this issue. When I tried to reproduce the first delete confirmation dialog to take a screen shot of it, I was unable to get it to appear on any of five different Windows XP PCs. The "Display delete confirmation dialog" check box still exists in the Recycle Bin's Properties dialog, but as far as I can tell, this check box no longer has any effect. Perhaps the dialog was quietly dropped in a service pack update? I can find no confirmation of this on the net. If anyone has an authoritative account on whether this dialog has been dropped, let me know. It'd be nice to say good riddance to an unloved dialog.

Some basic UI patterns for preventing accidental deletion

Many client applications and web sites let the user enter and manipulate data, and these manipulations often include the ability to delete data. Designers of UIs that include deletion of data generally feel the need to protect the user from unintentionally destroying data. For such a UI, it's important to consider the context surrounding the Delete command (or whatever action triggers deletion) before settling on a solution.

It's worth asking: exactly what is the concern with the user clicking a Delete button? I've often heard people express fear that the user's mouse might slip and click a Delete button, or that the user might not be paying much attention to what they are doing and might stab at the Delete button without understanding what it will do. I suspect that, in many cases, designers now habitually second guess the user's intention behind a deletion without considering alternatives.

Designers actually have more choices at their disposal than a delete confirmation dialog. Here's a quick survey of some UI patterns for a Delete command, in rough order of what I perceive to be the most frequently encountered to least frequently encountered:

1. Delete with Confirmation Dialog. The user selects a Delete command (or press the Del key, etc.) and the application displays an "Are you sure?" dialog; the application only deletes the data if the user responds affirmatively. Such dialogs are ubiquitous. The goal is to provide the user with a second chance to consider their action. In my experience, such dialogs provide slender protection—users can blow past the confirmation dialog before their brain has even registered what it is asking them.
   
2. Delete Immediately. The user selects Delete, and the application deletes the data immediately. This is generally used if the amount of accidental loss is very small, or if it's quite easy to reconstruct any accidentally deleted data. A good example here is the Delete button next to items in today's typical web shopping cart. In my opinion, this plain "Delete Immediately" pattern is woefully underused. As shopping carts show, it's perfectly fine to blow away data immediately if the user can just quickly add back something they didn't mean to delete. (This is probably another case where the difficulty of producing a dialog in vanilla HTML inadvertently leads to a better UI.)
3. Delete + Undo (single or multi-level). The application deletes the data immediately, but allows the user to undo the deletion by selecting separate Undo command. The application may allow the user to Undo only the most recent operation, or any arbitrarily long history of operations. The classic example here is a text editor. Most decent file system browsers support an Undo stack as well. This model is actually quite nice: it provides the benefits of Delete Immediately, and moves the complexity of restoring data to those users actually facing the need to get their data back. Even a single level of Undo can be helpful, as described in this post about Gmail's Undo Deletion command.
4. Trash (with manual or automatic cleanup). The application moves deleted data to a temporary Trash bin (or Recycle Bin, if you're afraid of being sued by Apple). The user can recover deleted data from the Trash. The data is permanently deleted at some later point in time: when a time interval elapses, when some space threshold is exceeded, or when the user manually empties the Trash. The classic example here is the Mac Trash can, but most email clients follow this model as well. Perhaps because of these strong precedents, the Trash pattern is used almost exclusively in icon-based object-oriented UIs, and rarely anywhere else.
5. Mark for Deletion. The user invokes Delete, and the selected data is marked in some way (e.g., grayed out, or with strikethrough) to indicate that the data is still there, but will no longer be treated as active (included in calculations, etc.). As with the Trash pattern, the data is permanently deleted at a later point. Example: IMAP email clients such as Mozilla Thunderbird. I consider this to be another under-utilized pattern.
   
6. Delete with Context-Sensitive Confirmation Dialog. The user selects Delete, and the application determines from the data to be deleted or other contextual information whether the user is likely to be unaware of consequences of the operation. In other words, the delete confirmation dialog only comes up with when it's important. A tepid example of this pattern comes up in text editors that only give you a "Save changes?" dialog if you're trying to close a non-empty document, but that close an empty document silently. This is another pattern that could benefit from much wider use. The basic idea is that, if the dialog only came up in the 10% of the time the user was really about to shoot themselves in the foot, the user would have a higher chance of stopping to read what it said. "Are you sure you want to delete this file you've been working on for the last eight hours?"

Any time an "Are you sure?" dialog is about to be added to a UI should force you to at least briefly consider whether an alternative pattern might better suit the context.