Recently, my attention has been directed to .Mail, which is yet another email application project that wants to “make email right”. I started using email in 1997, rather late compared to other people in my age range, and I never really had problems or experienced any kind of particular friction when using this means of communication.
A recurring argument in recent times is that email ‘needs fixing’ because we’re not living in the 1990s anymore, because we have different needs, because email is not ‘social’ enough or fashionable enough, because it has become somehow inadequate. And so on and so forth.
Email isn’t perfect, I’m not arguing that it is. But I have the feeling that all these efforts to reform this medium are focusing too much on cosmetic things. Interface and user experience are important, don’t get me wrong, but I believe there are a couple, bigger problems to address first: reliability and flexibility.
“Delivered”
One of the features I like most of iOS’s and OS X’s Messages is that when a message is sent, you know it has actually reached your interlocutor because the word Delivered appears under your user icon. As I was saying on Twitter yesterday, it’s 2012 and I still have to deal with email snags and consequent misunderstandings because someone hasn’t received an email I sent, or vice-versa. This mysterious phenomenon doesn’t happen all the time, but it still happens remarkably often if we consider how much technology has otherwise advanced since the 1990s. Sometimes behind an email message apparently not received there’s a too aggressive spam filter, but in many other cases the message seems to vanish into thin air. In this regard, even fax technology is more helpful, because you always get a return receipt stating whether the transmission has been successful or not.
Perhaps it’s a matter of upgrading the protocols, but it would be wonderful that after sending an email message, a “Delivered” label (or equivalent status icon) would appear on the sent message. This would effectively put an end to that mild ’email angst’ and uncertainty that often users have. Sure, we usually take for granted that a message sent has been delivered correctly, but there’s always that one percent of doubt, quickly increasing the more time passes before the recipient replies (via email or whatever alternative means).
Related to this issue: how about an email client that translates in human language those nasty “Mailer-Daemon” or “Mail Delivery Subsystem” automated replies when something has gone wrong. Usually the contents of the message are rather cryptic or too generic to understand what happened (I know, nerds are fine with them, but I’m talking about the average user). Furthermore, very often these messages are in English, so people who don’t speak English don’t even know that there was a failure in delivering the message. It would be nice that the email client could interpret the error message by reading its status code and display a more user-friendly alert explaining the error with simple wording and in the language the user specified for the operating system. (For example: Your message to Gary Wilson was not delivered. Check the email address you entered because gary.wilsooon@example.com was not recognised. — or something like that).
“I want simplicity!” — “And I want complexity!”
Another problem with email management and email clients is their lack of flexibility and adjustability. Some email clients offer too many options for certain users, or aren’t versatile enough for power users. People have surprisingly different needs when it comes to something as apparently straightforward as email. Mailsmith aficionados love its scriptability, and its powerful text and filter handling features. Other people love Sparrow because it’s simple, fast, user-friendly and it has great Gmail integration. Apple’s Mail seems to be a decent happy medium between these two, and that appeals to yet another category of users. But whatever the email client of choice, you’ll always hear people complain about something: it’s not simple enough; it doesn’t have many power options; the interface is too rigid; it creates friction in my workflow; it has Features X, Y, Z that are so useless to me and I can’t get rid of them; I want Features X, Y, Z of that other client but within my favourite email app because I don’t like that other client’s interface; etcetera, etcetera.
Wouldn’t it be great if an email client could really adjust its interface and feature set according to the user’s needs? Imagine something that starts with a minimal interface, like Sparrow’s or Reeder’s minimised layout, and that has the ability to expand according to what you want to use or display. Some sort of modular interface, adding elements as needed, and hiding them if/when not needed, so that they don’t clutter the program’s interface and confuse the user. Or something like Safari, which, again, starts simple in its default layout and configuration, but can be made more powerful, sophisticated and versatile by adding Extensions in a simple, user-friendly way. I know, it’s complicated, but in the long run it can be a more effective approach than modelling an email client based on what the developer thinks the user’s workflow is or must be.