>>  Computer Science   >>  Data-driven web design   >>  FaceMail

FaceMail - Adding a person-page to email (contact-centric email)

Ian Lewis, University of Cambridge, 27th Sept 2010


This short 'vision' paper is intended to show that an email client is an ideal environment for the use of a 'person page'. The 'person page' contains all the infomation available in the system that can be associated with that person, e.g. the entry in the address book, the list of emails from that person, and the list of emails to that person. In fact it seems bizarre to me that email desktop clients and (even more so) email web clients do not have 'person pages'.


This idea stems from the generalized concept of Data-Driven Web Design, in which certain entities within the system should be recognized as important and given dedicated views, and any appearance of the name of that entity within the system should be linked to the corresponding page containing the view.

For example, a movie review site will sensibly contain pages dedicated to movies and actors, with the appropriate cross-linking between movie and actor pages. When you see this approach taken on a website, you absolutely take for granted this is the only way it would work and imagine anyone that did it differently would be an idiot.

However, when you visit a website where this approach has not been taken, you typically find so many more things to complain about (for example ineffective searching) that you miss the fact that the basic principles of data-driven web design have been broken. The usual situation is the web-site developer will have understood a single entity as being important in the system, but treated everything else as a search. A simple example would be your typical 'help desk' system - 'trouble tickets' are managed well, so you can view a given trouble ticket, or view the 'queue' the trouble ticket is considered to be on, but the treatment of 'person' is very much an afterthought. I.e. you can search for trouble tickets from a given individual, but access to this page is via a fairly unfriendly 'advanced search' function and there is absolutely no concept of clicking on a person name and then seeing the list of user trouble tickets. As you can see, current email clients have similar limitations.

Example #1: Thunderbird open-source email client

To cut to the chase, here is what a 'person page' could look like in the popular open-source email client Thunderbird (click to enlarge):

You get to this page by clicking on the name "Steve Williams (ISS) <>" anywhere it appears elsewhere in the system. For example, in the 'inbox' view, if you have an email from Steve Williams, then clicking on the sender name there will bring you to this page. On this page you see other names listed under the emails (as other recipients of that email). If you 'clicked' on a name there (e.g. 'Brian Gilmore'), where do you think you should go:

  1. nowhere - the name shouldn't be clickable?
  2. open a 'compose email' window with that address in the 'to' field?
  3. to the 'RUGIT list amended' email at that particular entry in the list?
  4. to the address book?
  5. to the 'person page' for Brian Gilmore?

As of 2010, Thunderbird does #1. If function was added using the current typical thinking, the likely function would be #2 or possibly #3 (#3 is what clicking on a name against an email in the 'inbox' actually does). The best answer is #5...

This is a significant change from current practice where clicking anywhere along a folder view where emails are listed takes you to the 'email page' for that particular email, and it doesn't matter if you click on the date, subject line, sender or anything else on the row. The approach recommended here recognises that 'person' is a primary noun in the system, and should be treated consistently.

In building this this sample 'person page' for Thunderbird we have re-used a few things that are already available within Thunderbird:

Example #2: 'Person' as a primary noun in Roundcube webmail

Roundcube is an open-source webmail client with a well designed, conventional, web-based user interface that is designed around the well known concepts of folders and emails. Roundcube supports an 'address book' but is designed to be modal with the user choosing via buttons whether to be in the 'mail' task or the 'addressbook' task. These two views are based upon decades of tradition: the 'mail' view assumes the user wants to see a 'folder list' with a large part of the window displaying the list of emails contained in the current folder (typically 'inbox'). The 'addressbook' view displays a list of contacts in an area on the left (where the folder list is presented in the 'mail' view) and the main area of the window displays the contact details of the currently selected person.

The image below (click to enlarge) shows a conventional 'folder view' of emails, i.e. the list of emails is those in a particular folder, in this case the 'Inbox'. The left area has been modified to show a list of contacts or a list of folders. The illustration below has the 'Contacts' tab selected in the left-pane but it is assumed the page would 'remember' the currently selected tab ('Contacts' or 'Folders') so the user is one click away from the conventional folder list. As a minor aside, this screenshot assumes the use of a 'preview pane' for the currently selected email which does not affect the contacts/folder design choice - the existing Roundcube implementation allows the user to choose whether to enable the 'preview pane' or not.

In a contact-centric email client, the key question is "What happens when you click on the name of a contact?". The current assumption in Roundcube is that the user wishes to see the 'contact details' for that particular person, i.e. the entry you would expect to find in an 'address book'. My thesis is that this mostly ignores the fact that the person name has been clicked on within a messaging client. The 'emails from' and 'emails to' this person can be made more easily accessible. Other information could also be available on this 'page' (although not illustrated below) for example the 'lists' this person is included in. The image below (click to enlarge) shows an example 'person page' that could be implemented in the Roundcube application.

Email has other 'primary nouns'

The existing 'entities' that are treated specially in an email system are folder and email. When you click on a 'folder name' you can generally be confident a 'folder view' will appear with that folder name as a heading, primarily listing summary information of emails contained 'within' that folder. Where a list of emails appears (e.g. in a folder view), you can generally be confident that clicking somewhere near a given email will 'open up' that email and present you with an 'email view'. (Email systems have been doing this since time immemorial).

Person (aka Contact) is a great 'primary noun' which presents an opportunity woefully missed in email clients to date, with an example implementation illustrated above. 'Person' has a fairly obvious choice of what you should click on to get to a given 'person page', i.e. a name or email address.

Thread is another useful 'primary noun'. The now-withdrawn Google Wave product made a worthy attempt to have 'thread' or 'conversation' as a key entity in the system. The failure IMHO was that 'thread' is a great fourth primary noun (after folder and email) but a distant fourth after 'person' and Wave did not treat 'person' as any kind of primary noun.

Group of people is a more subtle 'primary noun'. Email systems use 'groups' of people all the time, both in explicitly managed mailgroups, and also implicitly in emails with multiple recipients in the To: and CC: fields. The Roundcube webmail client has simple support for individual contacts with 'add this person to my contacts' e.g. by clicking on an icon next to email addresses in the To: or CC: fields. It does not support the concept of 'groups of people' and has no symmetrical capability for groups of people with 'add these people to a contact-group' .

Email vs. Facebook

Email clients are typically 'folder centric' and Facebook is 'person centric'. In both systems messages can be sent from one person to another, but email systems are designed to choose the function first (i.e. write an email) and then choose the person you want to send it to. In Facebook the order is reversed. The jury is out on which approach is best but my vote is with the 'person centric' approach. Either system could be extended to support the 'other' way of working, and this paper illustrates how that could be done in Thunderbird, but my comment also is that this is a more significant lack in email clients than it is in 'person-centric' systems such as Facebook.

The bigger picture

This email issue is actually an example of a much broader transition in application usability led by data-driven web design. Users expect to click on the names of things and be taken to a page meaningful about that thing. Developers need to pause to think what are the important things in their system, not just the important functions, and design views around those things. This issue is only slowly being addressed in web applications, where developers tend to think of the first thing that comes to mind (e.g. 'item for sale') and then develop the site entirely around that, without realising there are probably a couple of other 'things' that might deserve similar treatment (e.g. 'brand' or 'seller').

Person views are more important than developers think

In most systems the developer can quickly think of one or two important 'things' contained in the system, e.g. in a Help Desk System the developer will usually come up with 'trouble ticket' and 'trouble ticket queue'. But if person is a possible view that makes sense, the developer will usually underestimate the value of that view to the users of the system. Each system may have 'person' as the second, third or fourth most important 'primary noun' such that the developer never gets around to implementing that view, but in aggregate across multiple systems, these 'people views' add up to the most important usability dimension.