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.

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.