Archive for the ‘Redesign’ Category

The Design Review Ep 1: The iPhone and Firefox Mobile

Friday, December 5th, 2008

The Design Review is an introspective on design across the web and everyday artifacts. It’s the brain-child of Alex Faaborg, and co-hosted by him and myself. In the future, we’ll be interviewing the folks behind Firefox, design visionaries, answering questions, and arguing about interface banalities.

Here’s the very first episode. We focus on the mobile space: What makes the iPhone good, what makes it suck, what’s up with Firefox Mobile, and how it was conceptually designed. We’re like Tom and Ray from Car Talk, but not as funny.

Episode One: The iPhone and Firefox Mobile

Let us know your comments, suggestions, and questions!

Redesigning the iPhone’s Buttons

Monday, July 30th, 2007

In my recent article about the first generation woes of the iPhone, I complained that the volume buttons are difficult to use in landscape mode; that the natural mapping that works so well in portrait mode (up means louder, down means softer) fails after the rotation (left means louder, right means softer). I suggested that the iPhone could detect its orientation and correct the mapping accordingly. In other words, the iPhone should swap the meaning of the buttons based on the phone’s orientation. The result? Widespread criticism. Even the venerable Apple pundit John Gruber weighed in with “I strongly disagree with [Aza's] idea about the volume buttons.”

It’s clear I need to make my case stronger, or else banish the idea to the halls of interface shame (a fate normally reserved for Clippy and Adaptive Menus).

What Makes a Good Autocomplete?

Friday, March 30th, 2007

We’ve been working on a problem for the past couple of weeks: an optimal autocomplete algorithm.

Many of our users have said that while Enso is great, it requires a bit too much typing. We’re inclined to agree. Yet, figuring out the best solution is tricky: there are more autocomplete algorithms than bones in a school of lionfish. There are straightforward algorithms, too-clever-for-their-own-good algorithms, standard command-line-style autocomplete algorithms, and the list goes on. A lot of the algorithms seem to go down fairly easily when you first start playing with them, but they end up getting stuck in your throat due to some unforeseen edge-case. This post explains our thought process in evaluating the algorithms given the (g)astronomical number of possibilities.

Monolog Boxes and Transparent Messages

Monday, September 11th, 2006


We’ve all seen dialog boxes that look like the picture on the right.

Dialog boxes are bad enough: they pop-up at inconvenient times, they derail our train of thought, and normally we don’t even read them. But this type of dialog box is worse. It’s not even a dialog box. It’s monolog box. There’s nothing one can do with this messages but click “OK”. Or wait and click “OK”. They have, as I’ve explained before, 0% efficiency. Beyond that, monolog boxes can have frightening consequences: because I often use two monitors, I’ve spent panicked seconds thinking I’d lost my work due to a crash… only to discover later that a monolog box had appeared on the other screen and stopped Word from operating normally. Even with a single monitor, you can miss the dialog box, and you’ll have a similar scare.

In the article The Spelling Check is Complete by Jensen Harris (of the Microsoft Office User Experience team) defends the “Word has finished spell check” monolog box shown above, along with the “Word has finished searching your document” box. The Office team had tried removing those documents but discovered that “people who were spell checking their document manually had no idea when the process was complete.” Thus, the monolog boxes were reinstated.

This is classic inside-the-box thinking. The problem is valid: people have trouble knowing the process is complete. But the solution isn’t to use monolog boxes. I can think of two different—and better—solutions. You can probably think of more.

Solution 1: Bypass the problem

Implied in the justification for reinstating the monolog boxes is the false idea that spell check is a fundamentally modal operation. In Jensen’s words:

“Spell check is one of those great features that have a beginning, a middle, and an end. The beginning is you clicking the spell check button. The middle is the computer conversing with you about potential misspelled words and giving you an opportunity to fix them. And the end is the computer telling you that the process is complete.”

But Spell check isn’t necessarily a modal interaction at all. Word’s own spell-check-as-you-type feature is a great example of a non-modal spell check. The text is underlined with a red squiggle: you only need to “converse” with the computer if you decide to fix it. The Gmail spell check, although ever-so-slightly modal, is another example of a spell check that does not require a “conversation”: spell check is done when you are done. Besides obviating monolog boxes, non-modal spell check has another benefit: it isn’t mutually exclusive with writing. If you are correcting a misspelling and you see something else you’d like to change, you can do it without exiting spell check. Your train of thought is never endangered—let’s see the standard Word spell checker and it’s monolog box do that!

Solution 2: Think outside the (dialog) box

If you keep Word’s somewhat antiquated spell check mechanism, then it’s true that the user needs to be informed when Word has finished spell checking. As I’ve explained, a modal monolog boxes are dangerous and inhumane. Luckily, there are many other methods of presenting information that are not modal. In particular there is one we are using in Enso, our upcoming product: transparent messages.

Transparent messages are the brainchild of Jef Raskin. It’s simply a large and translucent message that’s displayed over the contents of your screen. They fade away when the user takes any action (like typing or moving the mouse). In practice, the message is both noticeable yet unobtrusive. And because the message is transparent, you can see what’s beneath it. It’s just humane. Take a look:

Message Log

Transparent messages, however, introduce a problem: messages disappear easily. What happens if the user wants to see what it said? The solution is message log—simply a list of past messages. This way if the user doesn’t have time to read a message, they can go to the message log to view it only if they think it is important enough. And think about it: a message log would be a great thing to have anyway. How many times have you wanted to reference the contents of a dialog box and couldn’t because you had already dismissed it? And how many times have you had to transcribe the contents of a dialog box because the text wasn’t selectable? The lives of users and the lives of tech support staff would be greatly simplified by the addition of a system-wide message log.

On the web

The transparent message also has a place on the web. Web designers have a constant struggle to come up with non-obtrusive means of conveying fleeting feedback to users. For example, validating user input and checking login credentials. It is in instances like this that the transparent message really shines. Give it a try below.

The correct email is and the correct password is pass. Make sure to play with incorrect login information.



Feel free to nab the source code.


Transparent messages are a simple and elegant solution to a problem that is normally either over-looked or over-engineered. They’re not right for everything, but for messages that need no user interaction, transparent messages are hard to beat: they have an efficiency of 100%.

Plus, they look pretty.

No More More Pages?

Tuesday, April 25th, 2006

Google’s good. But it could be better. Chances are that you’ve done a search where you haven’t found what you’re looking for on the first page. If so, then you’ve had to click on the unhelpfully numbered more-result pages:

Google's aging links to get more search results.
There’s no semantic meaning in these numbers; there’s no telling what’s lurking behind a representing numeral’s bland exterior. If I find something good on the fourth page, I’ll be unlikely to find it again without aimlessly clicking on random number after random number. Normally, if I don’t find what I want on the first page, I’ll usually just give up.

Redesigning Stoves

Friday, April 7th, 2006

The kitchen is a great place to go bad interface diving. Who can resist taking potshots at undecipherable microwave controls? Do you know how to set its clock? Its power level? I don’t. And I’m not about to dig out the manual with buttered fingers. But today’s dive isn’t about the technological gizmos that we all know complicate our cooking lives. Instead, its about re-evaluating an interface that we all take for granted; an interface that is so ingrained in us that we don’t realize that it’s possible to even think about making it better. Today’s bad interface is The Stove.

Redesigning Volume Buttons, Old Style

Tuesday, April 4th, 2006

I thought it couldn’t get any worse than volume buttons. You know the kind: You get in your car, start it up, and get blasted by a wall of sound. And you continue to be blasted as you frantically search and then mash that tiny button again and again until the radio is once again at a reasonable level.