Task, Activity and Personal Information Management (PIM) in Email (1999-2006)

The work that I am best known for took place at PARC in collaboration with Ian Smith, Nic Ducheneaut, Mark Howard, Jim Thornton, Nathan Good, Brinda Dalal and Beki Grinter. I worked for many years trying to reinvent email as a knowledge worker's activity hub. Email has evolved since we did this work and it's headed right in the direction we laid out because the problems today are still the same as they were then, only more so. The insights we unearthed have been highly influential in the start-up world and, as a result of all this work, I have regularly been invited to review or act as an adviser to PIM start-ups, particularly those that have embedded PIM resources in an email client.

The figure to the right shows a screenshot from the first prototype engineered by Ian Smith. The design of the system, Raton Laveur, was based on the observation that people were doing PIM in email rather than on paper. The name comes from the French for raccoon since racoons are notorious for collecting shiny items; we thought of our tool as a way to manage all your 'shiny' important items in email.

This prototype had some very nifty features such as the ability to embed and view certain kinds of files in your email. Something that, only recently, Google has figured out (14 years later) with its new inbox. What you're seeing in the inbox in the figure is an image file with some of my art-work. I also designed the little raccoon icon on the right of the viewer panel.

We invented something called slicky notes that stuck to messages or documents but always remained in view (sliding over the item as you scrolled up and down, hence "slicky").

We took seriously the idea that your inbox is a to-do list and made emails and documents actionable as to-do items.

OK, so it's not beautiful, but we were exploring functionality and this tool as a functional email tool that we were able to use for a long time. This, driven by the idea that in order to really design a PIM tool well you really have to eat lots of your own dog food.

Raton Laveur Screenshot

One Overloaded Manager's Active Email Threads

In subsequent work, I analyzed the threads in study participants' inboxes to try to understand email overload and particularly the cognitive load of trying to track all the complex interdependent tasks that people are tracking where they are waiting for others to respond before they can complete them.

What you see on the left here is one manager's threads in a coded representation of the manager's incoming and outgoing messages (incoming, outgoing and distribution lists incoming are color coded pink, yellow and blue respectively). The colored bars on the left are the threads and the horizontal projections show which messages belong to which threads.

There are 28 threads all told in this figure... this is enough to exceed anyone's memory of things they need to keep track of at any given moment.

Our next prototype was TaskMaster, engineered by Ian Smith and Mark Howard with Nic Ducheneaut and me, working on the user experience research and driving the design through an agile development approach. TaskMaster took the whole idea of embedding resources in email even further. We made it so users could view Office documents (Word, Powerpoint, Excel) and web pages right in your email browser. And we made documents into first class citizens that could be included like emails in the inbox list.

We invented 'thrasks' which, despite the unpleasant name, were very useful ways to collect related emails. They were customizable threads that could or grouped or broken apart by the user so that all task-related emails could be kept together in the inbox (thrasks continued to collect new related items after being manipulated).

Other features included two-week warning bars that turned from green to red as deadlines approached and could be used to sort messages. We also had action items (represented as red and blue balls for "my" and "others'" actions) that could be attached to messages and these were aggregated in the list view of emails and thrasks so the user could see what commitments needed to be followed up on.

Again, this was a tool we all used for a long time and was popular with other test users.

TaskMaster Screenshot

TV-ACTA the To-Do List and Activity-Centered Task Assistant

The final prototype I worked on with Jim Thornton, with some help from Nathan Good, was called TV-ACTA. It's a pun that only works if you're British like me. TV stands for Task Vista, the comprehensive drag-and-drop to-do list into which you could put emails, files or just text that you typed in the field at the top. You'll see on the left of the figure to the left that TV borrowed the TaskMaster warning bars.

If a user dragged anything onto an existing to-do, it would turn into an Activity which was a container with sub-containers called Components that the user could determine by selecting a type for the Activity. In the figure, a Meeting Activity is open in the Outlook folders list with its pre-specified Components, such as an Agenda and Attendees.

Users could drag email into the Components and useful information would automatically be extracted (with the user's agreement) and organized. In the figure, the Contacts is open. The Agenda had a drag-and-drop agenda form that could be re-ordered and collected documents for meetings that could be launched from within the Agenda. Attendees were a subset of the contacts as specified by the user and messages could be composed and automatically sent to some or all attendees. There were various other Components, but you get the picture. Everything was customized for the meeting activity and all the user had to do was populate this framework by selecting what to pull out of emails during drag-and-drop actions.

This tool was tested on a number of users who were happy to have folders created for them and did use the different activity types we created for them for the purposes they were intended for. The tool was really designed to make machine learning about activity content much easier, but we didn't end up plugging in a smart back-end as we decided that PARC and Xerox were not likely to gain a commercial advantage from our doing so. So this tool ended up simply being a proof of concept that others have since used as a basis for their design work.