The major challenge, she predicted, towards making our digital tools work better for people was the simple fact that people are all different: people have differing needs and different levels of expertise. She backed her view with several studies showing that tools suited for a person’s particular needs and/or levels of expertise generally improves his or her experience with the tool, increasing chances of actually completing task, faster completion times, and less frustration.

Of course, people differ in far more ways than merely needs and levels of expertise. They live in different countries, speak different languages, have different friends, assume different jobs, preferences, strengths, weaknesses, beliefs and values structures and so on. And worse, people are dynamic systems that change from moment to the next.

How can application designers possibly address such complexity when building tools not just for people, but for individuals? Unless one day we have software teams that constantly follow each each person around, study them one by one, and build what is “best” for them, will we never achieve tools that work efficiently for everyone?

A practical solution: Personalize it yourself (PIY?)

One simple approach is to have people personalize their tools themselves. This seems reasonable since individuals are an excellent source of information about themselves.

The problem, of course is that personalizing a tool is yet another thing to do, requires time and effort, and is overally tangential to the original task. For tasks a person performs seldomly, we might expect people to realistically not worry about personalizing a tool. But what about tasks that people perform very often? For example, what about managing e-mail?

The “personality” of e-mail management

E-mail remains huge. Despite the number of tools people have to communicate today, e-mail still remains the dominant overall form of on-line communication. The amount of time and effort that a person spends communicating using e-mail are significant and tangible — a recent study revealed that people spend on average of 7 hours a week writing (composing/reading/organizing) their e-mail. [2]

Given the time and effort spent using e-mail, we would expect to see some degree of personalisation, particularly among advanced computer users. Even as early as 1981, E. Rich specifically cites e-mail as an example where users could benefit from self-personalization strategies:

Consider, for example, a computer program that enables system users to communicate with each other by sending mail messages back-and-forth. The program stores the messages in a set of files and provides functions by which users can read messages, answer them, and so forth. Such systems often allow users to set system parameters to determine such things as which message fields will be displayed when a message is printed. A much greater degree of personalization is provided by systems such as most implementations of the programming language LISP that allow users to specify an arbitrarily complex program that will automatically be executed whenever the user enters the system. With this facility, a user can create his own procedures, alter system variables, or define his own symbols.

– Elaine Rich, Users are Individuals

With advancement comes … uniformity?

When I was an undergraduate in the late 1990s at MIT, I remember that writing scripts (short programs) to automatically handle e-mails was quite a common practice among my friends. Most of these scripts used a tool such as procmail, to match patterns in message headers against a set of predefined rules — which took various actions when particular messages were received. These actions ranged from simple filtering, deletion, foldering, to more sophisticated actions: automatically responding to the sender, forwarding messages to a pager, or sounding audible (and visible) alarms to get the user’s attention. One particularly memorable script written by some electronics hobbyist friends matched the contents of incoming e-mails arriving from reuse@mit.edu, a popular mailing list for announcing laboratory equipment being discarded, against a “want list” of equipment that they needed to complete their projects. A positive match triggered an audible “foghorn” alarm on his hall and caused an LED signboard to scroll the details of the message in the hall’s lounge – including where and when the prize was located – to dispatch as many people as quickly as possible to obtain the desired piece of equipment.

Today, things seem very different. Most undergraduates at MIT either graphical desktop mail clients such as Thunderbird, Outlook and Apple Mail or, increasingly, purely web-based e-mail such as Gmail. Despite the fact that the Athena environment itself has not changed, the most common customizations, if any, rely on standard rule-based foldering features of these popular e-mail clients.

But why? – I could see at least three possible explanations for this trend. It’s possible that people (or specifically their needs) have changed, somehow mitigating or changing their needs with respect to e-mail handling (h0). Another possibility is that tools themselves have changed. Perhaps general-purpose e-mail clients have improved sufficiently to encompass the needs previously addressed by individuals’ personal hacks (h1). Or, perhaps these tools have become more complicated, making them somehow less easily customized, leaving people to resort to various coping strategies (h2). These are three very different possible reasons, and I wanted to find out more.

Do today’s hackers personalize their email handling?

To find out what some of today’s power users did to manage their e-mails, I polled members of MIT CSAIL, who were mostly graduate students, staff, research scientists and professors. Given that these were members of a computer science laboratory, nearly all individuals within the building are expert computer users. I asked these labmates whether any of them actively used any e-mail handling “hacks” beyond what was built-in to their e-mail clients of choice, and for what purposes these hacks were created to serve. I describe the results below.

Twenty two (22) individuals responded to an informal poll I sent via e-mail to members of CSAIL. These responses as well as the original e-mail I sent out can be viewed here.

Respondents who did not use any custom processing: 8 (out of 22) respondent indicated that they did not (or no longer) used any automatic filing features beyond what was available to them in their mail clients. Note that 8/22 (36%) seems a large number of responses by non-customizing respondents considering that the poll explicitly asked for those who actively customized their e-mail handling. This, plus the fact that over 1000 users are subscribed to the particular mailing list, indicates that even among experienced computer programmers/engineers/researchers, relatively few people customize their e-mail handling.

Reasons for not having custom handling solutions:

1. The most commonly cited reason (when given) for not performing custom handling hacks was (6) that the person regularly used multiple email clients on multiple platforms (Windows, Mac, Linux) and mobile devices. In such situations, implementing client-side processing hacks becomes difficult becuase of the need to implement such hacks across all clients is either impossible (with impoverished clients) or deemed too much effort.
2. The second most cited reason (5) was that users have largely switched to webmail due to universal availability (4), and user interface affordances (1) of modern web mail systems.
3. The third most cited reason was that modern mail clients were not as flexible/open to custom processing solutions as old clients.
4. Another reason cited included migration effort, specifically that the effort required to migrate/port hacks to new e-mail systems required more effort than they saved.
5. Two participants mentioned that their previous hacks primarily surrounded spam management and were basically rendered obsolete by standard spam-management systems built into most clients today (SpamAssassin, etc). Interestingly, several other participants still felt that such standard spam management software was inadequate and cited that they still used custom rules to further reduce and manage spam.

Reasons for custom e-mail hacks – Respondants gave a large number of reasons for writing custom e-mail processing hacks. These include:

• Automatic foldering – 5 explictly mentioned the use of rules to automatically folder emails and reduce the number of messages that end up in their main inboxes. Several mentioned the use of websieve to do this foldering at the mail server, so that such foldering would affect all clients they used.
• Multiple account management – 3 mentioned the use of scripts to help with the management of multiple-email accounts; 2 explicitly mentioned the use of scripts to simplify handling of corporate versus personal e-mail.
• Forwarding to mobile/notifications – 3 mentioned the use of selective forwarding to mobile phones, while 2 explicitly mentioned the use of scripts to enable notification when certain important messages arrived.
• “Reflecting” e-mail to others – 2 mentioned the use of scripts that automatically copied others, acting as “client-side” mailing list.
• “Procrastinating” e-mail – 2 mentioned the use of mechanisms for having e-mails re-sent to the user (to remind him or her) at a specific later date. One respondent called this the “procrastinate” function, which he tied to a single keystroke for his mail client, nmh. Another wrote a webmail extension to provide the same functionality, supporting procrastination until arbitrary later points in time.
• Spam reduction – 2 mentioned the use of custom rules/techniques reduce spam (beyond a standard spam filtering techniques), such as challenge-response filtering.
• Archiving, Backup and Archive management – 2 mentioned the use of scripts for archiving email, backing up email inboxes to disk, and searching email archives.
• Other uses – Other participants mentioned using custom scripts for providing vacation auto-responding, off-line email access, mass-mailing (e.g., like client-side mailing lists) and attachment managements.

Respondent #17 expressed his dissatisfaction with standard e-mail filtering schemes:

i have hundreds of filters set up in tbird to auto- file my email into folders. it was a big pain, because tbird filters don’t have enough expressiveness. for example i have to say “From X” or “To or Cc X” (two predicates) to catch everything to or from X.

there’s also no easy way to express priority, for example that an individual message from a student should go to a different place than a group message. and there’s no way to capture the manual filing i do, i.e., watch me file, infer a rule based on the headers and the filing action, and put that rule in place.

all of these would be nice to have in a better suite of email management tools.

Conclusions

Revisiting our hypotheses from before, based on our responses we can see that in fact, all three hypotheses were somewhat true. With respect to (h0), it seems that users needs have indeed changed: for example, many users now need to access e-mail from multiple accounts, on multiple devices (running different operating systems and clients). These needs made customization (h2) more difficult, because clients are not all capable of the same customizations. Furthermore, modern graphical clients, while better for novice users, are less flexible, change rapidly and thus are not as conducive to customization as older command-line and terminal-based mail clients (h2). But they do some things better (h1), including spam filtering, and offer simple customizations such as keyboard macros and rule-based foldering.

Overall, these uses of personal e-mail handling indicate the presence of unmet needs in current e-mail processing tools among expert users. The question becomes whether the next generation of e-mail tools should seek to support al of these functions, or to return to a state where they can support greater personalization — letting users better fit their client to their exact needs.

References

1. Elaine Rich: Users are Individuals: Individualizing User Models. International Journal of Man-Machine Studies 18(3): 199-214 (1983)
2. http://news.digitaltrends.com/news-article/14823/survey-looks-at-hours-spent-managing-email
3. CSAIL survey results: http://people.csail.mit.edu/emax/blog/email-study.html