Interface design is more than hand waving and color preferences. When you design anything to be used by humans, there are some fundamental tools which can tell you if one interface is better than another. Quantitatively. Don’t believe me? Answer this:
Which of the following two sentences contains more information?
As we iterate on the new tab design for Firefox, we’ve run into a seeming paradox. The new tab screen should have two main functions: (A) To show you the sites you are most likely to be interested in going to, and (B) to not distract you. That’s the paradox: by design success is when the pages we show are maximally interesting/distracting, but an explicit goal is to not interrupt your flow.
This iteration focuses on solving that paradox by proposing a solution that we’ve dubbed “the cognitive shield” (coined by Alex Faaborg).
A little about the design process, growing up with Jef Raskin as my father, watch manuals, and designing in the open at Mozilla.
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.
In the concept video I recently did for laying out the interface paradigms for Firefox Mobile, I listed five guiding principals.
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 Mint.com’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 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 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.
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.
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.
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…)
Finding the right graphic for an icon is hard — and even if you do find a decently descriptive graphic, it might not be descriptive for long.
For the majority of cases, trying to represent an abstract idea like “bibliography” in a 32-by-32 pixel array is futile, even if you do have millions of colors and an alpha channel. Sure, you might choose a book with a magnifying glass as your icon, but that graphic could mean many things: “library”, “help”, “research”, “index”, “vision impaired”, etc. Any interface that uses the icon would still have to add a tooltip to explain what it means. There is a reason why we have words — it’s so that we can specify one thing in particular no matter how complex or abstract the thought.
Why make the user go spelunking for the information they need? Just give it to them.
It came to my attention recently just how fragile the connections are between the iconal representation of a concept and the actual concept. Here is the Microsoft Word icon for “to save”.
It’s a floppy disk. There is only a tenuous connection between saving and a floppy disk even for those of us who know what a floppy is (and at the moment most of us remember them), but floppy disks are on their way to becoming as unknown as Charles Yerkes. Don’t know who I’m talking about? That’s my point.
Welcome to the first installment of the Humanized Interface Puzzler. For your fun, bafflement, and desire for free stuff, we’ll pose an interface design puzzler on a semi-regular basis. To enter, simply send your answer to puzzler@humanized.com by the deadline. We’ll select the best answer and post it on our blog. Then, we’ll send the winner a limited-edition* Humanized shirt and entrance to our beta program.
The first puzzler is about modes and cars.
An interface has modes if one gesture can mean different things, depending system state. Modes are at fault when you miss a call because your phones in silent mode. And there’s little worse than having the final bars of Appalachian Spring – with harmonies as delicate as frozen cobwebs – thrashed by a cellphone who’s owner has forgot to put it into silent mode. Perhaps there is something worse: having it be your cellphone. You can read all about modes, modes errors, catastrophic mistakes, and some solutions in our article Visual Feedback: Why Modes Kill.
(more…)
Let me set the scene. It’s the comedy film “Airplane“. The flight crew is violently ill and Striker, a shell-shocked, former pilot, is forced to land a jet full of passengers in dire need of medical attention. The air is heavy with fog, rain pounds on the cockpit windows. Over the static-filled radio comes the voice of ground control desperately talking Striker through the landing.
Striker: No, never.
Ground Control: Thinking the radio is off. #@&*#! This is a waste of time… there’s no way he can land that plane. Striker starts to tremble.
How did Ground Control make this mistake? The answer is simple. Mode error.
Don Norman defines mode errors as occurring when a user misclassifies a situation resulting in actions which are appropriate for the conception of the situation but inappropriate for the true situation. In Airplane, the action could not have been more inappropriate for the situation.
(more…)
