March, 2007


7
Mar 07

Open Source Usability Sprint

For any Mozilla contributers in the Bay Area:

On Friday 3/9 to Sunday 3/11 Mozilla will be participating in an Open Source Usability Sprint. The event will be located at Google and will run from 9am-5pm each day.

For people working on Firefox at the usability sprint, our goal will be to re-imagine the Web browser, and radically rethink how users interact with it.

If you are in the Bay Area and are interested in participating, you can fill out an application to attend. More information about the event is located on FLOSS Usability’s wiki.

I’ll be posting a recap of the event next week to my blog if you are interested in finding out what we came up with.


6
Mar 07

Would you Like to Redesign Notification in Firefox? Yes. Not Now. Never.

Yes?

Recently I’ve been thinking a lot about the way Firefox interacts with the user when it needs to ask a question, or provide a piece of information. These interactions involve topics like:

-RSS detection
-Password manager messages
-Download manager messages
-Installing updates
-Installing extensions
-Pop-up blocking
-Phishing protection
-A range of other features that are still in the design stage (microformat detection, inspecting security information, etc.)

What’s Wrong with the Current Approach?

The biggest problem with notifications in Firefox 2 is that some of them force the user to answer a question using a modal dialog box. These modal dialog boxes interrupt the user’s flow, and (while at least they are not anthropomorphized) these kinds of repetitive interruptions can get annoying:

Modalpasswordmanager

There has been a considerable amount of research into the effects of notifications. People have studied the negative effects of interruptions in terms of task performance and emotional state, and have even created models to predict the cost of interruptions. It turns out, interrupting the user is bad.

Redesign

So the challenge is to interrupt the user, without interrupting them. Notifications have to be noticeable, but not annoying. It’s a fine line. Here are some ideas I’ve had for redesigning notification in Firefox. First I’ll go through the basic idea, then I’ll iterate through a few variations. This design is still pretty rough, please feel free to propose new ideas in the comments.

First, I think we should create a centralized area in the browser chrome that provides notification UI. This could be anywhere, but the first mockups show it next to the throbber. There are a couple of reasons why this may be a good place to put notification icons: outside of the status bar this is the only area of the chrome that displays status, and the user’s gaze may already be near the throbber while the page is loading, since it animates. Also, I personally want to get rid of the status bar. But that’s a different issue that has already been heavily debated.

Some notifications are more important than others. Because of this, the design supports four increasing levels of notification:

Level 1: Icon
Level 2: Message
Level 3: UI Controls
Level 4: Modal Warning Dialog

Here is what these four different levels look like. [If you are wondering about my switch to crayons, it's an attempt to convey that these are just conceptual mockups, not final designs].

Level 1: Icon

Level1Icons

From left to right, RSS feed on page, file is downloading, and a new version of Firefox is available. These icons only appear when they are relevant. If this looks overly cluttered, keep in mind that this is a rather extreme example (normally not all of these things are relevant at the same time). Note that this is a rough sketch, the last two icons are likely to change.

Level 2: Message (non-modal)

Level2Message

Level 3: UI Controls
(non-modal)

Level3Uicontrols

Level 4: Modal Warning Dialog

Level4Modalwarningdialog

Unlike the previous levels, this type of notification is modal. The content area is blacked out, and the user must make a decision before continuing to use Firefox.

Each type of notification is assigned an appropriate default level. This isn’t a complete list, but it provides a sense of what types of notifications appear at each level:

Notificationlevels

These levels determine how the notification is initially displayed, however the user can also drill down on their own. For instance, clicking on a notification that is a icon (level 1) or message (level 2) will display the relevant UI controls (level 3):

Levelup1
Levelup2

Messages (level 2) and UI controls (level 3) are non-modal. This means that clicking anywhere outside of the notification will cause these notifications to disappear, however the icon will remain while the notification is relevant.

One problem with this design is the occasional situation where the user clicks right after a notification appears. This will cause the user to accidently dismiss the notification, and then wonder what it said. There are a couple of ways to help mitigate this problem. First, messages (level 2) and UI controls (level 3) should always contain larger versions of the same icon that appears in level 1. If the user catches a glimpse of the icon, this will help them know which icon to click on to get the notification back. Secondly, the notification should fade out, so if the user does a visual scan quickly enough they will be able to see which icon the message originated from. And finally, we can use cognitive performance modeling to calculate the average time it will take the user to view the notification and process what it said (probably a fraction of a second). Any clicks under this threshold should not dismiss the notification, because it is unlikely that the user was clicking to get rid of it.

Variations

Here are some different variations of the same general idea.

Status Bar
Everything is the same, except icons appear in the status bar instead of next to the throbber:

Varstatusbar

Location Bar / Throbber

Some notifications only apply to the current tab, and other notifications apply to the entire browsing session. The designs above don’t make a distinction between these two types of notifications, but perhaps we should. The way we currently create this distinction is to have tab specific notifications like RSS feeds and microformat detection appear inside the location bar (because they are associated with the current page). We could have global notifications like downloads and browser updates remain outside the location bar field, next to the throbber:

Varlocationbar

If this looks too cluttered, one way to reduce visual complexity is to make all of the notification icons monochrome, matching the throbber. Kind of like the upper right corner of OS X. Also keep in mind that these icons only appear when they are contextually relevant, usually there won’t be this many at the same time.

Javascript Popups
[Update: Benjamin Smedberg explains in comment #6 why this would break the Web]
While we are on the topic of page-level notification, a javascript popup window should be modal to the tab that invoked it, and not the browser. This makes it clearer to the user that the Web site is addressing them (and not Firefox), and the modal popup doesn’t lock the entire browser.

As I mentioned earlier, all of these ideas are up for debate. How do you think we should improve notification in Firefox?

Technorati Tags: ,