Thursday, 15 March 2012

Touch interface will encourage contact-centric email approach

'Touch' interface users are good at prodding things with a fat finger, and dragging and dropping items. Typing is less convenient than on a device with a 'proper' keyboard.
There are three immediate examples that show where contact-centric email benefits a 'touch' user more than a user of a regular desktop computer:
  1. Composing an email to a given contact is conveniently a click on a button by their name, business card popup, or in the contact entry itself.
  2. Adding addresses to new emails or replies can be supported via drag-and-drop from the contacts pane
  3. Searching for emails based on an email address can be done with a single click on the corresponding contact
For each of these it is common for PC users of existing mail applications to resort to the keyboard (and email client developers have worked hard to enhance the productivity of this). But a touch user might prefer drag-and-drop, and for this to be effective you really want the contact list readily available.
This post isn't intended to suggest contact-centric email is a slam-dunk obvious preferred solution for touch/tablet users, rather to suggest they might find it more attractive than PC users.

Sunday, 11 March 2012

Abstracting the framework useful for contact-centric email

I am actually modifying the open-source webmail software Roundcube to provide the contact-centric functionality described in the posts below as a personal research effort. The developers of Roundmail deserve huge credit for producing a free piece of software that is remarkably well architected.
Nevertheless it's clear that, like all email software that I have come across, Roundcube is currently constructed around a few fundamental assumptions that then constrain the way the product is used. In particular Roundcube is designed with the assumption that you are interacting with an email folder or the address book, but never both. From the screenshots in my earlier posts below I will leave you to decide whether you are looking at a list of emails (i.e. a folder view) or a contact entry (i.e. a contact view), the point being that contact-centric email merges the concepts.
With conventional email, a folder view will typically allow you to filter and/or sort your emails, so you can certainly arrive at a list of emails to or from a given individual, and from a typical email addressbook you can usually click a button that will take you to a 'compose' form to send an email to that individual, and Roundcube includes these capabilities as does Thunderbird, Outlook, and most other email user applications.
The development of contact-centric email would actually benefit from a more abstracted framework within which the component panes could be relatively independent, but respond to messages or events sent between them.
At the most basic level, clicking on a folder or contact in the left pane will cause the 'items list' pane to update with a new list of items, and the 'item preview' pane to update if a contact has been selected. Clicking on an item in the 'item list' pane will cause the 'item preview' pane to update.
Using a single-window view, the 'item preview' pane could be minimized, maximized of left adjustable within the window. The default for the size of the preview window could be adjusted for different events, e.g. clicking on a 'compose' button might maximise the preview pane (which would then also be in 'edit' mode for an email) and the same could be done if an 'edit' button were clicked while viewing a contact entry.
Particularly in the case of clicking on a contact in the 'contacts list pane', it could be imagined there are multiple types of items that could be listed in the 'items list pane', including items from systems other than an email platform. If the framework supported tabs, and general support for web content within each pane, then it is conceivable the contact-centric solution could be extended outside the email context. For example, if this contact makes documents available in Google Docs to the user of the email client, then those documents could be listed on another tab in the 'items list pane'.

Email conversation improved style

In case my post below is not clear enough, here's the contact-centric email 'conversation' view re-done with an improved style. There's plenty of room for improvement but the difference between this 'conversation' view and a 'thread' view should be obvious.

Saturday, 10 March 2012

Email thread versus conversation

I actually thought the idea of a conversation as the exchange back and forth between two people would be well accepted in email clients, but having looked around it seems all email clients that refer to a 'conversation' actually display the thread view, i.e. emails linked together on a common subject regardless of who they're from. The Microsoft Outlook documentation in particular refers to the ability to view a "Conversation or Thread" which looked like you could have either when in fact Microsoft is using both "conversation" and "thread" to refer to the same view, grouping emails by their subject line.

This conflation of two different ideas will probably hamper the development of a more contact-centric view of email for another decade.

So in summary,
a thread view would be with an inbox grouped together by subject line, and
a conversation is the list of emails exchanged with a given user, e.g. as iPhone messaging:
Modifying the email client so it becomes more contact-centric (as in my earlier screenshots) radically increases the importance of the conversation view as defined above, and the pre-selection of the contact automatically creates a context for the conversation.

Sunday, 4 March 2012

Contact images, and drag-and-drop for email

The screenshot below illustrates a couple of concepts.
Firstly is their any advantage in using portrait images for contacts where their email address might be? Maybe, maybe not. The assumption is a mouse-hover over the image would give the 'business card' with the usual information including email address and action buttons, and a 'click' on the image would take you to that 'contact' entry (as is assumed throughout this discussion of contact-centric email). A 'contact' that has no image would necessarily be represented by a similar-sized icon just containing the text email address or person name if that is available. But maybe the image at the top of a 'compose' makes it feel more like you're communicating with that person rather than their email inbox. I am aware that videoconferences that 'freeze' the image while the audio continues do still feel like a videoconference, just with an incredibly slow frame rate, so maybe there's something in this.
Secondly, it illustrates some aspect of where drag-and-drop fits in with the use of email. The open-source email client Thunderbird already allows 'contacts' to be dragged from the addressbook into the To: or Cc:, but this requires the addressbook to be opened in a separate window first. Having the contacts list (addressbook) more immediately to hand might ease this kind of drag-and-drop. Also, dragging a VCARD file from another desktop folder window (e.g. Windows Explorer) should have a similar effect, either adding the email address into a To: or Cc: field, or 'importing' that person entry to the mail address book. Drag-and-drop also makes sense for email 'attachments'.

Friday, 2 March 2012

Contact-centric email - 'conversation' view

On reflection, the 'email list' section of a 'contact-centric' view of email would be the sensible place for a 'conversation' email list view. I.e. the email to and from that contact interleaved. In my previous post I'd illustrated the 'contact view' with tabs for emails-from and emails-to that particular contact (which still might be useful) but I should also have considered the 'conversation view' which is simply the same email flows combined onto a single list, sorted by date, with the 'froms' and 'tos' clearly marked. The idea is you see the back and forth communication with that particular person in the correct order.
The mockup screenshot below illustrates the idea, although the actual 'style' of the page would need work. In particular there's a subtlety in that the user might have received an email from the contact by virtue of being on a Cc: list or From:, plus it might be useful to indicate which emails are 'replies' versus fresh 'conversations' - the screenshot below isn't great from a 'style' standpoint but is intended to illustrate the principle. 'Indent' has been use to mark the 'from' emails...
The 'Date' (Datum) column has sort up/down buttons - these might be more important on a 'conversation' view, as it is more natural to see the time flow from top to bottom, while email inboxes tend to be looked at with the newest at the top - this might be an important user preference.
Click to enlarge screenshot:

Monday, 27 February 2012

Contact-centric email

This blog post develops the basic thesis that collaboration is person-centric, while the most prevalent collaboration tool, i.e. email, remains firmly wedded to the concepts of 'folder' and 'email', leaving the concept of 'person' somewhat out in the cold.

This post is labelled 'contact-centric' (rather than person-centric) purely because 'contact' is the term used in most email clients. Actually email clients are often endowed with an 'address book', named after a thing that contains 'addresses', not people.

The argument is more fully developed on my contact-centric email page, itself really a specific example of the principles of data-driven web design.

All email clients support the concept of folder. I.e. you can click on the name of a 'folder' (e.g. Sent Items) and can expect to see a list of emails associated with that folder conveniently displayed.

All email clients support the concept of an email. I.e. if you see a list of emails (e.g. after clicking on a folder name above) then you can expect the contents of that email to be conveniently displayed.

Person has a long history of being effectively an attribute of an email, i.e. a piece of data in the form of an email address that may appear in the From, To or CC fields. As mentioned above, email clients have added 'address books' over the years but almost entirely as a convenient cache of email addresses to aid the primary task of writing an email. Person (aka Contact) remains a poorly supported entity in the system, certainly compared to 'folder'.

It doesn't have to be this way. Rather than being hidden behind an 'address book' icon which effectively takes you 'out' of your email tool, your list of contacts could be displayed within your 'main' email view.

For 'Person' to be treated at least as importantly as 'folder', something more useful should happen when you click on a person name. The illustration below shows how the 'contact pane' could actually be a composite of contact details plus mails-from and mails-to the person concerned.

Regarding 'Person', the additional consideration is what would you click on to bring you to this view? The obvious answer is the name of a contact in the contacts list (aka 'address book') left-pane. In addition the same view could be reached when clicking on any email address in the To:, From: or CC: fields of any email.

So the 'person page' has two primary qualities that distinguish it from current 'traditional' implementation of email clients:
  1. All useful information derivable from a given individual is accessible from their 'person-page', and in many cases that information is 'promoted' to appear on the page itself (rather than being provided in the form of a link that takes you away from the person page). The 'Sent' tab in the illustration above keeps the user on the person page, not off to an 'inbox view' that happens to be sorted by email address.
  2. Clicking on a person reference (typically in the form of their email address) consistently brings the user to this view.
This post doesn't attempt to provide the definitive answer on what should be on the email person-page, but provides instead an illustration that should easily justify its value. Given a person page, there are many opportunities for collecting information even within the email system that could appear on this page. For example
  • the mail lists to which that users belongs
  • relationship scores with other users of the email system (equally this allows the collection of contacts with whom this user is most associated)
  • other systems (e.g. voicemail) may provide additional information that can be incorporated.