The Email View Problem

So far, I have explained how current email software is flawed and suggested a number of approaches which might improve it. But implementing these changes is not simply a matter of adding features to existing software. We must keep in mind the original problem, which is roughly this: the email we deal with every day is overwhelming. The problem with email is not too little, it’s too much. Adding features is exactly the wrong approach; what we need to do is take things away. The trick is selecting just the right things to keep.

Looking at email in terms of time, people, and topics suggests a number of promising ways to view email. For example, instead of a list of messages there could be a list of people, or messages could be sorted by some sort of calculated priority, or they could be displayed in order of time.

These views may be useful, but they are not all compatible. For example, messages cannot be sorted both by time and priority. Displaying by person is not compatible with displaying individual messages. Instead, existing software offers views, between which the user can switch: one button might change the sort order, while another switches to a threaded message view.

This idea of switching views is deeply flawed. Email clients offer numerous views, yet many people still use a cluttered inbox as their primary view, and seldom if ever change to another view. This could be because the functionality is not obvious, it could be because switching views requires too much thought to determine what view is appropriate for the task at hand, or it could be that out of sight is out of mind. Whatever the reason, simply adding views is not going to fix email.

The use of views should be minimized because they are complex, the user loses context, and they over-emphasize interface manipulations. In order to get things done using views, the user often ends up switching between them frequently. Whenever a user switches views, it means that whatever she wants to see or wants to do isn’t available from the current view. Rather than switch views frequently, most people choose not to switch at all.

The real problem isn’t the existence of views, it is that they are not centred on the user, but on the capabilities of the software. To the computer, email is a collection of pieces of information: a sender, a date, a subject line, some text, and assorted other details. Email software can perform a number of manipulations: it can sort, it can group, and so on. Most software presents this assortment of tools directly to the user. But the user doesn’t want to sort by subject, or sort by date, or whatever. She wants to deal with the contents of her inbox – that is, read and answer messages.

Views can make perfect sense – if each view is coherent, and if switching between them is minimized. In other words, related activities should be grouped into a single view, so the user only needs to change views for unrelated work. The question then becomes: what are those related activities, and can we construct views which correspond.