Archive for the ‘Design’ Category

Interview with Geek Entertainment TV

Monday, January 5th, 2009

A little about the design process, growing up with Jef Raskin as my father, watch manuals, and designing in the open at Mozilla.

Write the manual first.

Monday, January 5th, 2009

You don’t really know a subject until you’ve had to teach it. In the same way, you don’t really understand your interface until you’ve written a manual explaining how to use it. It can be a frustrating experience. Take for example the two manuals for digital watch and analog watch. The section on setting a digital watch is over a page of dense, difficult explanation. The analog’s is a single sentence: “Pull crown and turn.”

Don’t forget to test the manual on real people. Watching them misunderstand, misinterpret, and miss might be the most aggravating experience you’ve had since trying to thread a needle in the dark. Remember, though, it’s not the their fault.

It all comes down to this: If you’re having trouble explaining how to use your product, the user will have trouble using it.

Mobile Firefox and Designing Without Modal Overlays

Friday, July 18th, 2008

In the concept video I recently did for laying out the interface paradigms for Firefox Mobile, I listed five guiding principals.

  1. Touch it with your finger
  2. Large targets are good
  3. Visual Momentum and Physics are compelling
  4. Typing is difficult
  5. Content is king

It’s these principals that inform the design of new features long after the original design as been coded, released, and iterated on. In discussions with the perspicacious Mike Beltzner, another design principal emerged.

 6. Use modal overlays sparingly, if at all.

To be sure we are on the same page—I’m may be partaking in the dangerous hobby of coining new terminology—an overlay is simply a content area that sits in front of the content beneath it. The aspect that makes a modal overlay modal is that when it is up, the content “beneath” the overlay cannot be acted upon until the overlay is dismissed. Although a modal overlay may be visually transparent, it is never interaction transparent: you must always take action, like clicking “okay”, before continuing with your workflow. While I’m living dangerously, I’ll toss one more phrase into the mix: a state-forgetting modal overlay is an overlay whose state is reset every time it is summoned. That is, any work you do in the overlay is lost when you dismiss it.

Some examples of modal overlays are dialog/monologue boxes, ever-so-Web-2.0 Lightboxes, and the bookmarks interface for Mobile Safari. Some examples of overlays that aren’t modal are transparent messages and the OS X’s on-screen display for volume. The former have a number of interaction pitfalls that the latter do not share.

What’s wrong with modal overlays? In a word, they are modal: You are either interacting with the content or the overlay. Modal overlays don’t allow you to refer back and forth between two sources of information, or move fluidly between two actions. The second problem with modal overlays are that they are disconnected and disjoint from other overlays—knowing how to access one doesn’t yield a physical sense of how to access another one; they do not scale to give a unified, cohesive interface.

Let’s take a look at a plausible interface to illustrate the point; an implementation of search-and-replace using a Lightbox.

At first glance, this seems like a friendly, Web 2.0 way of doing things: it affords the opportunity for large typography and an uncluttered screen. While using a Lightbox is Web 2.0, it isn’t necessarily friendly. In fact, it has a fairly clunky workflow, for anything but the most basic case. Imagine you want to replace all instances of the text “insightfully thought” with “perspicaciously reckoned”, both of which exist in the text, although separated by a couple pages. You copy the first term, summon the Lightbox-based modal overlay, and paste it into the “replace” field. The next logical step is to scroll through the content to find “perspicaciously reckoned”, copy it, and put it into the “with” field. Unfortunately, because the search-and-replace form is in a modal overlay, you first have to dismiss the overlay before interacting with your content, then call it up again when you are done. It’s a slow, unwieldy feedback loop. On top of that, there isn’t a great way to indicate the changes in the text without somehow hiding the overlay.

Let’s take another example, this time from the real-world. At Humanized, we wrote a review of’s thoughtful interface. One of the thing’s I liked about Mint’s interface—that I called “stunning”—was the unafraid use of text to create a huge, easily scanned list of possible categories that enabled filing a particular expense quickly. The problem, which I didn’t talk about then, was that they used a Lightbox. It feels heavy and slow at a visceral level. For example, when you are categorizing the expense type of a purchase, Lightbox’s modal nature keeps your from examining surrounding expenses that might help you to contextualize and categorize the purchase in question. Further, because it is a state-forgetting overlay, anything you enter into the create-your-own-category input is lost as soon as you consult another expense. Not good.

Lightboxes are tempting to use as a turn-key solution—we unfortunately use them in Songza—but there are better solutions, which I’ll come to in the next section.

Let’s go closer to home for the next example. Bookmarking. Firefox UX designer Madhava Enros did excellent work on many of the early UI prototypes for Firefox Mobile. In Proposal 8, which experimented with Songza-esque pie menus, you can see a lot of the thinking that directly informed the current design of the location bar. It also used a modal, state-forgetting overlay for bookmarking. This meant that you couldn’t both be bookmarking a page and interacting with the page at the same time—and worse, if you started to delve into your hierarchy of bookmark folders to file the page away, and wanted to refer back to the page before saving the bookmark, you’d have to start all over again.


Now that we’ve explored the problems with modal overlays, it’s time to look at solutions. In particular, on the solution meant to replace modal overlays that might require complex interactions—which means that transparent messages don’t cut it. I’ll talk about two solutions in this post, but I am sure that there are other solutions out there. I’d love to hear ideas in the comments.

The Tray

The first solution is arrived at by simply not having an overlay be modal, with a bit of animation for polish. The overlay appears as a tray anchored to the edge of the content area. The tray must not force interaction, meaning that the tray can be ignored, and the content perused as if the tray didn’t exist. The only down side to not interacting with/dismissing a tray is that it eats up some screen real estate.

In the browsing world, Firefox uses the tray method to defeat the annoying-as-a-blackberry-pip-stuck-in-your-molars dialog box that asked if you wanted to save your password (and worse, it asked before you knew if you had typed it right!).

Because a tray overlay isn’t modal, you can answer the question in your own time. The tray is a great way to make user-dependent decision asynchronous. In fact, almost all user-dependent questions that are in situ with your browsing experience are done via the tray-style prompts. Take, for example, the prospective geolocation prompt. Coincidentally, the conviction of never using a modal overlay/dialog box in Firefox meant changing the W3C geolocation specification. Ironically, if you drag a tray is extended to take up the entire screen it becomes a modal overlay again. Further examples of trays in action can be found in Algorithm Ink’s browsing and editing functions.

As a final example, there is extensive use of tray-style interaction in Adobe Lightroom, generally docked on the left and right side of the screen. It’s a well-placed implementation, allowing quick access to a range of manipulations that don’t get in the way of moving around the image.

The Slide

The second solution isn’t an overlay at all, instead it uses scrolling or sliding. By placing the new area next to the original content it’s easy to understand how to move between the two areas. It’s also easy to extend the metaphor across numerous additions — new features get a new physical location. This is the technique demonstrated in the concept video, where the browser controls are located to the left of the web page content.

Using sliding as an overlay substitute mechanism (when we aren’t using slow-to-use scrollbars) is a fast way of moving between content in a non-modal way that also takes advantage of visual momentum and spatial memory.

Let’s take a look at how the slide mechanism can extend the browsing controls for Fennec. Here’s a schematic view of accessing the add-on manager and preferences:

Notice that once we’ve introduce the slide, we’ve opened up the possibility for a scalable way to expand ad infinitum. It’s a good way of coping with the limited screen size of mobile.

End Game

I’ve only started to think about solutions to the modal overlay problem. The tray and the slide are two passable solutions—I’m sure there are even better solutions waiting to be discovered. Quasimodal overlays, for instance. Let me know if you find/think of any.

“Not The User’s Fault” Manifesto

Wednesday, July 16th, 2008

Jono DiCarlo, a former fellow co-founder of Humanized, and a gallivanting user experience firebrand, has condensed his design experience into a thought-provoking and irreverent manifesto.

In sweetend condensed form, here is the manifesto:

1. Why do we code? For people, not for computers.

2. What do most people want? Not a computer.

3. Why does software fail? Its social effect is not what people want.

4. Why has Linux, which is free, not taken over the desktop? “Linux is only free if the value of my time is zero.”

5. Are users dumb? Never. Good UI design is humble.

6. Is UI design marketing? No.

7. What is the task of the UI designer? To make UI disappear.

8. Where is the science in UI design? Underutilized and unknown. It shouldn’t be.

9. Is change good or bad? It has a cost.

10. What is the evil of the bad interface? The sin of wasting the user’s time, breaking the user’s train of thought, and losing the user’s work.

I agree with all of it, except whether UI design is marketing. Great UI design can form the basis of marketing. The iPhone commercials, which were simply tutorials for using the phone, are the prototypical example. Great UI makes for great marketing. It is not a two way street, however. Great marketing can make for some pretty abysmal interfaces. As Jono points out in his manifesto, undecipherable microwaves are case in point.

There is much more to the manifesto than the bullet points above. Some of it will make you angry. Some of it will make you laugh. All of it will make you think. So go read it.

Enso 2.0 Design Thoughts

Thursday, January 31st, 2008

As part of the our move to Mozilla and thinking about a free-as-in-speech Enso, I want to be more transparent with our design directions and goals. Our designs can only benefit by incorporating the criticism and suggestions of the community we have here. Open-source design is a balancing act between making final decisions and finding consensus. We hope to take the lessons that Jono spelled out in his excellent article on successfully humane open-source projects and use them in our own projects.

This post is about the new directions we are taking Enso. If you haven’t done so yet, start by reading about some of the motivations for doing some Enso redesign. In short:

  • Enso shouldn’t make you type all of “open” every time
  • Enso should be able to open paths and urls
  • Enso should support international character input
  • Enso should gracefully handle the case where there’s no convenient place to enter text
  • Enso shouldn’t require you to type out text, select it, and then run a command when you’d rather run the command and then enter the text (think calculate)
  • Enso shouldn’t make you hold down a key while typing lots of characters

We think we’ve solved these problems with our Enso 2.0 redesign. In this post, and possible follow on posts, I’ll walk through the new stuff. I should note that our upcoming prototype will not yet have have all of the features mentioned here. (more…)

Songza and a Little Thing

Friday, January 25th, 2008

Songza Logo

Last month we added an “about songza” page to Songza. It’s a simple page — just a couple headers, some text, and a return-to-Songza link. I thought I’d a walk through my thought process in through-designing this tiny feature. It’s not quite as simple as it first appears.

The first question is whether to have the about content be on a separate page, or as lightbox/hidden-div content on the main page. I was tempted by the second option; there is a seduction to having Songza exists on only one page. On the other hand, that solution isn’t particularly scalable — Songza has already added other pages similar to the about page, how would they all interact? And how do you keep the load-time reasonable as more and more content is added? — More importantly, the content is not linkable or search-able. Using clever Ajaxy tricks means that the visibility of the content is dependent on application state.

It’s clear that the about page should be, in fact, a separate page. That leaves us with a glaring usability problem. Do you see it? It’s bad enough that I would be wary of clicking links while listing to songs if I ever got bitten by the problem.


Undo Made Easy with Ajax (Part 1)

Friday, September 14th, 2007

As users, we make mistakes. As designers, we need to design with mistakes in mind, as I argued in my recent article, Never Use a Warning When You Mean Undo. Undo is the ultimate safety net, lending an incredible sense of solidity to an interface. That’s why every desktop application from Word to Photoshop provides multiple-level Undo.

So, then, why are Web apps that provide any sort of Undo so few and far between? The answer I often get is that Undo is hard to implement. I’m here to tell you that it is not.

In this series of blog posts, my goal is to explain just how easy it is to provide Undo functionality. Recently, I gave a preliminary version of this post in a workshop. After giving the front-facing demo of how Undo could work, the audience moved slightly towards the edge of their seats (it’s all you can hope for in the post-lunch session). When I opened the source code and started showing how I implemented undo, the universal response was, “Why are you bothering to explain this implementation? It’s barely anything at all. We’re software engineers. This is easy.”

That’s my point!

Adding Undo to your interfaces profoundly and positively affects the usability of your site. It reduces user frustration, and increases user trust. Both of those outcomes mean that more users continue coming back, which helps your bottom line. Remember: To the user, the interface is the product. (more…)

Iterative Design: Towards the Perfect Paper Plane

Tuesday, June 5th, 2007

Paper Airplane (Beta)Iterative design isn’t design by trial and error. Iterative design is a process of continually improving not just the design, but also the problem your design is trying to solve.

Coming up with a solution is often the most straightforward part of the design process. That isn’t to say that creating the solution is easy, or doesn’t require a deep knowledge and honed skill set. It’s just to say that when you have a set of requirements and a well defined problem, you know where you stand and where you have to get to. It’s mostly straightforward. Much harder is the implicit problem of figuring out exactly what the problem is in the first place. If the problem is vague or ill-defined, the design solution will be too.