IM and SMS-like Interface for Email

This post follows on from: “Email Formality, Informality, and Email’s future“. How might Email adopt some of the informality of other systems?

Let’s start by looking at a simple IM session (this is the Skype client):

Here we note a key feature vs. using an email client: The threads are purely person (or group) oriented. If you open a contact, you simply see all your IM communication with that person/group, no subdivision by subject or anything else. Similarly, you are not called on to add side-copies (CCs). The way in to the interface is simply a list of contacts (or “friends” etc.) – you choose the person you want to communicate with, and off you go. This minimizes formality by maximizing simplicity.

We can see a similar minimalism in Twitter, though the communication style is different:

Also worth noting is that the Skype IM client makes it easy to switch to another mode of communication (video). In a more integrated client experience, IMs, Email, Video Calls, SMS would all be part of the same simple thread with this contact.

Of course, IM and (even more so) SMS also create a real-time “please answer right now” element, initiating a conversation, while an email is longer, more self-contained, and implies permission to provide a delayed response. It would hard to provide a reliable real-time conversation via email protocols – though delivery can be near instantaneous, delays of a minute or so are not uncommon. Accordingly, a very-simple-email client might need to be a combined IM-and-Email client (or even Very-Simple-Email+IM+SMS), automatically selecting IM or email as the case might be, but retaining the pure-contacts orientation of tracking activities; call it a “Very Simple Communication Client”.

How could a start-up address a situation? Almost certainly not by trying to build a massive new infrastructure for email (and IM and SMS and…). Rather, it would be by building a very-simplified-client that linked to some popular existing back-ends, and then taking it from there. It is even possible that it could exist as an extension to existing clients, in some cases.

Plainly, the client would need mobile support. Indeed, one of the appeals of such a client should be that it would be naturally fit for mobile (short messages, simple interface).

The client would also need to find an efficient (i.e. simplified) metaphor for handling incoming messages.

Although building a huge new infrastructure would be best avoided to begin with, in the longer term, the client might need a back-end to anchor its value. I will return to what a future back-end might look like in a future post.

I will also delve into the topic of how an ultra-simplified-messaging might apply to social walls (most notably FaceBook of course), and Twitter.