Email Interface Design 101

Note: this article is not about web based interfaces to email, like Yahoo email or Hotmail. It's about using email as an interface to websites or web services.

Mailing list managers have long used a command based email interface to manage the mailing list. Link based email interfaces (unsubscribe links) are common in email newsletters and mailing list, and job websites also typically offer email interfaces using links. Online vendors use HTML based emails with forms to sell products.

Email as an interface to websites hasn't been explored much by the interaction design community. And yet email has some key advantages: it's fast and asynchronous (you can fill in the interface, and the next time you connect to the Internet send the email), and allows for requested interaction.

Here is a screenshot of an email interface from Mail4mykids.com

Advantages and Disadvantages of Email Interfaces

Email interfaces have some key advantages over web interfaces:

1. Asynchronous interaction
   You don't have to be online while giving the commands. A significant advantage for many people who have limited Internet access. [1]

2. Requested interaction
   Software systems can request interaction by sending you an email.

3. Speed
   You can send commands from your email application, which will often be faster than opening a website.

A main advantage of email interfaces, asynchronicity, is also its main disadvantage, in that there is no immediate feedback. Feedback from the system can take over 10 minutes because of email delays on the Internet. This means that email interfaces are mainly useful for one step interactions: you get some input and you decide on an action. You shouldn't use email interfaces when:

1. Immediate feedback to the user is required upon action.
   Email delivery can experience delays of 10 minutes or longer.

2. Tasks require multiple steps in a short time interval.
   You don't want the person using this interface to have to wait for the next email to continue.

The asynchronocity of the interaction also means that UNDO becomes even more important, since no immediate feedback is available.

Requested interaction is a unique advantage of email compared to web based interfaces, but not limited to requesting action through email interfaces: requests can be sent use a web interface as well.

Speed of the email interface is mainly accomplished by not having to leave your email program: starting up a browser and connecting to a website can take up to 15 seconds, a time delay in which the task might already have been completed using an email interface. The time gains are small, but add up for often repeated actions.

Input and Output in Email Interfaces

The main consideration to make once you've decided to use an email interface is how to deal with input and output, commands and feedback. Here's what we have to play with when building an email interface:

• The email address
  Addresses can contain information, like script_submit_123@domain.com

• Additional headers
  You can make up headers with email, but you can't easily edit these headers in most email programs.

• The body of the text.
  Which can be text only or HTML

• Attachments.
  eFax's email Fax interface (screenshot) for example treats any attachment as a document to be faxed by the service.

These technical constraints limit the things we can do with email. Given these constraints, and looking around on the web, here are the three basic styles of email interface interaction:

1. Command line style
   The subject and body of the email contain text commands like "subscribe" or "start-content".

   Command line style interaction requires the user to learn to use certain commands, and introduces possible errors: commands can be misspelled, wrong commands can be given. Command line style interfaces are emailed back to the server, allowing for asynchronous interaction. Because of their learning curve, command line style email interfaces are useful mainly for power users. A special case of command line interaction is when the user is requested to reply to an email that already contains the relevant commands - mailing list software often uses this to confirm subscriptions.

2. Link based style
   The email contains links like "Delete this entry: http://domain.com/delete?12" that can execute commands.

   Link based style interaction is easy (just click the link) and error free, but requires the user to be online while using it, thus loosing one of the key benefits of email interfaces: asynchronicity. They retain the speed advantage, which is why these are also widely used for simple interactions like subscribing or unsubscribing.

3. HTML based style
   HTML forms, posted to a webpage. Browser opens after posting.

   HTML based style interaction allows for a rich interaction environment, providing all the HTML widgets (dropdowns, checkboxes, ...) people are used to using. However, it requires people to be online, thus again loosing a main advantage of email interfaces, and it still retains all of the disadvantages of email interaction.

Question:
Could an HTML form that is sent to someone be replied to, keeping the form intact? The form is filled in and emailed (not POSTed) to the server.

Would it be possible to make the form values be transmitted to the server via a reply-to? This would provide the rich interaction possibilities of HTML and yet allow for asynchronous interaction at the same time.

Conventions

There are a few conventions that have already evolved for email interfaces:

• Explain the user where the email comes from and what to do next if they aren't used to the interaction. A good example is the "This is an automatic email, no reply is necessary".
• Have subject lines that are easily filterable, preferably contained within square brackets. Having a subject line include something like [feedback domain.com] makes it easier for people to manage their incoming email.
• Avoid too many email being sent, rather compile them into one big email if possible. Nobody likes receiving heaps of email.

Examples of Email Interfaces

• Command line style: Translation email interface, another interface to a music database.
• An email interface to the Google API
• Web to email server: allows you to surf the web if you only have email.

Jeff Lash offers some more examples:

Long ago it used to be common for people to provide information via auto responders "For our price list, send an email to prices@ourwebsite.com". It was used for situations where they didn't want to provide data online for all to see but wanted it to be available to people who wanted it. Just last week I saw a personal site that had a "Want my resume? Send an email to resume@mysite.com" link, but I forget the name of the person/site. [...] Microsoft Outlook lets you send invitations and questions through email.

At work we use the Approve/Deny a lot for any changes to the IT infrastructure. I send out a request to people who need to approve it, and they just click the appropriate button in the email. You can do voting and create custom buttons, and whoever sends the email out can track responses. Of course this is a MS extension to email.

Conclusion

Email interfaces can be powerful tools that support repetitive one step tasks, and offer some unique productivity advantages for people with limited time and Internet connectivity.

The design of email interfaces has typically been left to developers with little time and resources to spend on this. It is high time the interaction design community took up the unglamorous task of designing quality email interactions.

Article history: This article originally appeared on poorbuthappy.com

[1] Of course, not all email interfaces have this property. Asynchronous interaction is possible with websites as well, but in practice it's too scary to fill in a form while not connected. Unique ids time out, the server gets confused, and too often you get an error message when connecting back and submitting the form, which means you can start from scratch.