flow|state

LCDs recreating old physical controls (whether or not that makes sense)

As LCD prices comes down, we can look forward to seeing small LCDs appear on every device or appliance we own. During this transition, manufacturers are likely to replace physical device controls with an on-screen UI that exactly duplicates the old physical controls, sparing them the real labor of thinking.

Consider the LCDs showing up in cars. My Toyota Prius is a great little car, but its LCD is the weak point of the car's design. Most of the time, the LCD displays a power transmission diagram that lets you know when you're using the battery in some way. During a test drive, this diagram serves the useful function of giving the salesperson something to point at, because otherwise it's hard for them to prove to you that you're in a hybrid car. After the first week of actually owning the car, the power transmission diagram is mostly pointless.

The Prius designers did come up with some other uses for this LCD, using it to replace a random subset of controls that used to take the form of physical hardware buttons and knobs. For example, the LCD controls most—but not all!—of the radio functions. The Prius designers have carefully preserved many of the limitations of the old controls, particularly the hardware radio preset buttons (the original "radio buttons" in user interfaces):

You can only see six radio preset buttons on the screen at a time, most likely because earlier Toyota cars had six hardware preset buttons. These preset buttons are tiny compared to the overall screen size. I can only assume that the designers were influenced by the physical dimensions of the old hardware buttons, and mirrored those old sizes on the new screen—even if the new screen isn't subject to any of the physical constraints that governed the old buttons. The designers also seemed to believe it was important that all buttons be about the same size, even if some buttons could benefit from longer, self-explanatory labels.

The tiny buttons on screen are actually less easy to use that the old physical buttons that you could feel with one hand while keeping your eyes on the road. The tiny on-screen button size does add a spark of excitement to the driving experience, seeing as how each time you have to look down at the screen to stab at the buttons, you risk smashing into the car in front of you.

What could the designers have done instead? They could have made the radio present buttons bigger, but that would all be small potatoes. They really should have thrown out the old model completely and started over by considering their users' basic radio listening needs and the physical nature of an LCD screen.

Years ago I saw a demonstration of a bank ATM UI that had been completely redesigned from the ground up to meet the needs of the bank's blind customers. (If I recall, it was designed by Chase in New York City.) The bank's design team recognized that the easiest regions to find by feel alone are the four corners of the screen. They created a UI in which every page had four huge buttons that each took up a full quadrant of the screen. The buttons ran all the way to the edge, because that made it easier for the user to be sure they were pressing something. (The Prius designers studiously keep all their buttons away from the edge of the screen. It probably looks better that way in a graphics editor on a computer screen in the design team's office.)

Perhaps this bank ATM UI could inspire better on-screen UI for car LCDs, making it easier to change stations without risking death. There are surely many other factors at play here (I'm no car designer), but the point remains that there are many ways to take better advantage of a graphical interface than simply duplicating the old way things were done before in hardware.

As LCD prices drop to the point where they approach the cost of physical hardware buttons, LCDs will crop up absolutely everywhere. Some manufacturers will get this transition right, but most probably won't, at least the first time. It's a virtual certainty someone will end up making a toaster with a tiny touch screen showing a picture of knob from "Light" to "Dark".

Vista UX details starting to arrive

As part of Microsoft's Professional Developers Conference 2005, the company has released more information on how to design user experiences for Windows Vista. I was the UX architect on Vista for a number of years, so it's good to see this information finally starting to coming into the light of day.

(As it turns out, Microsoft has created a remarkably poor user experience for reading their guidelines on user experience. You have to go to a section on Microsoft's MSDN developers site for the Windows Vista UX Guidelines. You need to go through some Windows verification foolishness, although I'm baffled why it matters what platform you're using to read the guidelines. You then need to download a ZIP file. This ZIP file turns out to contain... wait for it... a copy of a web site that describes how to design good user experiences. Oh, the irony. The byzantine reasons behind Microsoft's web site production process are not worth delving into. Let's just say I'm glad I now work at a tiny startup.)

Some of the Vista work I'm most excited to see deals with an effort to bring clarity to muddled dialog boxes and wizard pages. Vista offers OS support for a new "task dialog" style. This style—and the accompanying guidelines—call out a dialog's main question or instruction as a single sentence in clear, natural language. (The blurry example JPEG images below come straight from the guidelines; too bad they didn't offer lossless PNGs.)

This same task style is reflected in the new standard wizard template:

This wizard style is, in fact, an operating system feature designed specifically to make every piece of text count. Gone are the big pointless graphics that took up a third of the page, and a single piece of instruction text replaces the old stack of redundant headings. Hallelujah. It's gratifying to see the evolution of direct OS support for the inductive UI style I developed way back in the late 90s for Microsoft Money.

Some Vista UX guidelines are specific to Vista development, but many of them make just as much sense for products that ship on Windows XP, OS/X, or Linux. Worth a look.

Media Center nicely blends data sources to create album list

Microsoft Windows Media Center Edition contains a UI nugget worth a close look: the My Music area's list of albums includes any CD that happens to be in the drive:

This sort of thing looks obvious after the fact, but consider the fact that the list is blending data from two completely different sources: 1) Media Player's local music database, and 2) whatever CD happens to be inserted in the drive. All actions in the UI work essentially the same regardless of what kind of item is selected (with the difference that a CD can be ripped).

Faced with this design problem, most teams would have created a UI that directly reflected the underlying data model. This would force the user to deal with two distinct UI elements: one area for the the albums already in the database, and a separate area for the local CD drives. (This is, in fact, what Windows Media Player does.)

The Media Center team did a bunch of work to let the user work at the right level of abstraction: everything in the list is an album, regardless of whether it's ripped yet or not. This sort of thing doesn't come up every day, but it's worth thinking about whether your own application could benefit by adopting this nice trick.

Google Earth: Drop-dead gorgeous satellite photo rendering with clunky visuals

My favorite app of the past year has been the satellite imaging client Google Earth. Much of this product's design is absolutely state of the art, but the fact that they've done such a good job in the core UI makes some really clunky parts stand out.

If you haven't tried Google Earth yet, you owe it to yourself to stop what you're doing and download their free version. While you're downloading, here's the summary: they give you a 3D model of the Earth that you can spin and tilt freely, zooming in to incredibly detailed images of your own city—and (if you live in a big city) your own house. The main window looks like this:

I first tried Google Earth when it was an independent product called Keyhole. The core user experience remains the same: a set of navigation controls let you manipulate the virtual globe and camera. Given the complexity of doing anything in 3D, I think they've done a reasonable job. Most of the magic in the user experience comes from what happens under the covers: the high performance incremental downloading and caching of huge images that all happens in the background, with exactly the right degree of progress feedback in the UI.

Since Google acquired Keyhole and rebranded it as Google Earth, they've tweaked the UI a bit. Most noticeable is an attempt to give the product some Google branding. Google's visual branding strategy appears to consist of randomly selecting user interface elements and coloring them pure red, blue, yellow, or green. You can be the judge of whether the above screen shot really says "Google" to you. In my mind, this UI is dominated by the rendered globe, and the arbitrary splashes of bright color elsewhere in the UI offer little more than distraction.

What's really striking are the parts of the UI that have remained completely untouched. Just before the product shows you a magnificent, full-motion, high resolution magic 3D globe of the whole darn planet, you see... a gray dialog box:

I'm a believer in trying to establish positive emotion from the point of first contact, and dialogs like this don't help. This would be a lame dialog in any product, but it's particularly odd to see something like this—something that clearly no one has spent any time on since the day the dev first coded it—followed immediately by one of the coolest visual experiences available in any product on any platform. What's even odder is that the above status dialog appears in the startup sequence after a rather attractive splash screen. To cap it off, the dialog is pointless: the status text doesn't communicate any information that's meaningful to the user beyond the fact that the app is starting up—precisely the fact communicated by the splash screen that precedes this dialog.

Anyway, the fact remains that Google Earth is such a draw-droppingly cool product that the clunky parts don't spoil an amazing user experience. Now that Google Earth has finished downloading, go take the next two hours off from work looking at every place you've ever lived.

How big is a big download these days?

I've noticed that a previously answered question has recently become open again: where does a typical user place their threshold for a download that's too big?

Companies that distribute client software via a web download used to agonize over how to reduce their download size in order to encourage adoption. Browser developers in particular used to crow about how their download was smaller than their competitors. This was a big deal in the days of dialup. If I recall, a rule of thumb in the mid 90s held that each 1MB of download would take 10 minutes over a typical dialup connection of that period. Worse, dialup connections could easily fail, forcing the user to sit through the long download again. A user who had to devote an hour of their life to babysit your 6MB download was quite cautious about clicking the "Download Now" button. The user was also concerned about how much disk space your product would ultimately eat up was everything was installed.

The relevant factors have changed significantly: many users have broadband connections, download managers exist to cope with flaky connections, and hard drive space is easy enough to come by. Many companies now seem to pay scant attention to their download size, so I can only assume many users don't care either. Download Adobe's Reader product (a business requirement these days) and you'll see a lightning quick 500K download... of Adobe's Download Manager, which then brings down another 80MB or so of software—including some other Adobe products slipped in for good measure.

One reason this question is interesting to client software designers is that there are some pretty interesting client runtimes coming down the pike that open up some great UI possibilities at the expense of download and install size. The forthcoming .NET Framework version 2.0 package is 22MB. The Windows Presentation Foundation ("Avalon") or Windows Communcation Foundation ("Indigo") add more on top of that. If you're building a product that itself already depends on broadband use, does the download size of your client even matter at all? If anyone has actual, recent data (not anecdotal experiences) on how todays user's react to download size, I'm interested in hearing it.