Note: this article is not about web based interfaces to email, like Yahoo emailor Hotmail. It's about using email as an interface to websites or web services.
Mailing list managers have long used a command based email interfaceto 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 interactiondesign 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
Email interfaces have some key advantages over web interfaces:
Software systems can request interaction by
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:
Immediate feedback to the user is required upon action.
Tasks require multiple steps in a short time interval.
The asynchronocity of the interaction also means that UNDO becomes even moreimportant, since no immediate feedback is available.
Requested interaction is a unique advantage of email compared to web basedinterfaces, 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 leaveyour 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.
The main consideration to make once you've decided to use an email interfaceis 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
The body of the text.
These technical constraints limit the things we can do with email. Given theseconstraints, and looking around on the web, here are the three basic styles of email interface interaction:
Command line style
Command line style interaction requires the user to learn to use certaincommands, 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.
Link based style
Link based style interaction is easy (just click the link) and errorfree, 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.
HTML based style
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.
Would it be possible to make the form values be transmittedto 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.
There are a few conventions that have already evolved for email interfaces:
Jeff Lash offers some more examples:
Long ago it used to be common for people to provide information viaauto responders "For our price list, send an email to email@example.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 firstname.lastname@example.org" 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.
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 littletime 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
 Of course, not all email interfaces have this property. Asynchronous interactionis 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.