Overview
Email is one of the primary applications for the latest generation of smartphones, yet many mobile email clients are designed essentially as smaller versions of desktop email clients. Mobile email use, however, differs from desktop email use. While desktop email users may spend significant amounts of time reading and writing messages, mobile email users typically focus on triaging their messages to determine what's new, what they can delete right away, and what's important enough to handle immediately. They defer everything else until they are at a desktop or laptop with a full keyboard and larger display.
With this research, we set out to build a mobile email client that would better fit how users actually handle email on mobile devices. We chose to focus the client on helping users triage their email to identify what to handle and capture the intended actions for deferred messages to support completing those actions at a future time.
Top-level View
The top-level view of our mobile email client illustrates the difference in our focus. Rather than showing a set of folders or jumping straight to the user's inbox, we separate the user's email into Untriaged and Triaged folders (the latter containing mail that the user has already either handled or assigned an intended action). We also provide access to the set of tasks that capture the user's intended actions.
From this view we provide color-coded "badges" to help users determine what Untriaged email they have. The grey badge indicates the number of read messages, the light blue badge the number of unread messages, and the dark blue badge the number of new messages. We report the number of new messages separately from the number of unread messages because we discovered through observation that mobile email users spend most of their time just in the inbox. Users are surprisingly good at determining how to handle a message just from the sender, subject line, and two lines of the body provided by many mobile email clients. As a result, they often never need to open a message, particularly if they defer handling it to a laptop or desktop. But if users don't open messages they remained marked unread, even though users have "read" them enough to determine how to handle them. Users are then forced to determine themselves which messages are actually new, versus just unread, the next time they access their email on their mobile device. By reporting new and unread messages separately, we allow users to avoid that additional work, as well as avoiding opening and closing messages just to remove the unread flag, which is a coping behavior we routinely observed among users of mobile email clients.

Untriaged View
The client's view of the user's Untriaged mail borrows heavily from current mobile email client design. We provide one line showing a message's sender, one line for its subject, and two lines from the message body. We help draw the user's attention to the new messages (often where users want to look first) by visually distinguishing them with a light blue background. We apply the convention of a blue circle to indicate unread status. Note that messages can be old (or least not new) and still retain their unread status.
We also apply a convention from some desktop email clients and provide information about the other recipients of a message. From talking with users, we found that many want to know how many other people received a message to help them determine the message's importance. As an example, a message requesting information about a project sent just to the user is likely to be a higher priority than the same message sent to the entire project team. In line with the convention in Lotus Notes, we use a filled green circle to indicate that the user is the sole recipient, a half-filled circle to indicate a small number of other recipients, an empty circle to indicate a large number of recipients or that the user is cc'd, and no circle to indicate that the user is bcc'd or not directly addressed (e.g., the message is to a mailing list).
Capturing Intended Actions
Supporting triage allows users to more quickly determine which messages to attend to, which they can delete, which need to be handled, and which they can defer until they reach a laptop or desktop. Supporting triage, however, is only the first step. We also want to help users capture how they intend to act on a message so that we can help them avoid making that same decision more than once and so that they can more easily resume handling deferred messages.
The approach we chose to take is to provide a way for users to capture how they intend to handle a message as a concrete task that we can store in the cloud and provide access to across devices. Users specify whether a message is something they can handle Next (when they get a few spare moments), something Deferred until later (waiting on a person or for a later time), or something that is a Reference (information relevant for some other task rather than requiring action on its own). They specify that information by displaying a translucent overlay on top of the Untriaged view and assigning the categories directly over the messages.
Users can also optionally assign a specific action to each message as well. We currently support 8 possible actions: Call, Print, Read, Reply, Save, Schedule, Send, and Visit. Users can also specify an action without assigning a category, in which case the client will assign the Next category by default.
Once users have assigned categories and/or actions to messages, they tell the client to triage those messages. In response, the client removes them from the untriaged view so that users do not have to look at those messages and remake those same decisions the next time they check email. Users can still access the messages from the Triaged view. The client also creates a task for each message behind the scenes that users can access through the Tasks view.
Accessing tasks while mobile
The Tasks view allows users to view, edit, and delete the tasks that the client creates for them. When creating a task for a message the client uses the message subject as the task's short description and the body of the message as the task's details. It also assigns the specified category and action (if any). The user can edit the task to change those details or to assign a due date or tags. The client synchronizes the tasks with the cloud so that the user can access those same tasks across devices.
Accessing tasks on the desktop
On the desktop, users can access their tasks through a sidebar plug-in for Notes. Users can access, edit, or delete their tasks, or even triage emails on the desktop by dragging them into the sidebar. By default the client also moves triaged out of the user's inbox so that the user doesn't have to mentally process them again on the desktop either. However, if the user wants to access the message associated with a task he can just double-click on the task's message icon to open up the original email message.
Video
This video demonstrates a sample session using the Mail Triage iPhone client and the Notes plug-in sidebar.
Publications
- Jeffrey S. Pierce, Jonathan Bunde-Pedersen, and Daniel A. Ford. Triage and Capture: Rethinking Mobile Email. IBM Research Report RJ10458.

