The team behind the innovative and well-received Orchestra is nearing a public launch for Mailbox, shifting from
a to-do list with email-like functionality ➠ to an email inbox that behaves like a todo list. Mailbox appears to be taking a somewhat different approach from other recent email clients, so I’ll refer to its potential while exploring where I think email’s next stage of client evolution is headed.
That inboxes are simply todo lists other people can put stuff in is increasingly regarded as truth, especially after Paul Graham wrote last year about email’s noisy, inefficient status quo and the opportunities it presented in Frighteningly Ambitious Startup Ideas:
As a todo list protocol, the new protocol should give more power to the recipient than email does. I want there to be more restrictions on what someone can put on my todo list. And when someone can put something on my todo list, I want them to tell me more about what they want from me.
Efforts to modernize email-like messages are of three general types:
- Develop a new protocol (eg: Microsoft’s MAPI, Apple’s iMIP) - difficult outside the enterprise,
- supplant the inbox by creating an alternative messaging service (a/synchronous chat, status, feeds, boards, eg: Salesforce) - fracturing where users look for new content,
- redesign the email client’s content and interaction layers.
Redesigning the client’s low barriers to entry have made it a very busy space. Unfortunately, most address only superficial challenges and delivering even a superficial client is difficult. New clients must meaningfully differentiate from service providers’ thoroughly entrenched clients, integrate with existing services (Exchange most notoriously), resonate with user needs, and attract & retain notorously fickle process voyeurs necessary for evangelizing a broader audience. Achieving all that, client design is highly vulnerable to duplication.
Sparrow may be the only recent example of a successful email client, which many attribute to their port of other messaging platform models, good timing, and steady improvement over time. But even their success is relative - future development was abandoned when acquihired by Google to work on Gmail.
The best way to defend an email client that competes on design is to consistently deliver the best product in a space regularly flushed with new competitors scrabbling for niche users. It’s extremely difficult to dig a moat without other advantages. Still, the siren calls ever more developers - today’s clients are simply inadequate.
Mailbox is unique because of the potential moat afforded by using their own API in place of IMAP. While it is currently marketed as improved message delivery (ie: iOS push notifications), there’s an opportunity for its purpose to expand. Speculating, this could perhaps be similar to Apple’s Messages, sending email from Mailbox to Gmail but meta-augmented todos from one Mailbox user to another. As Graham put it,
Do they want me to do something beyond just reading some text? How important is it? … When does it have to be done? By acting as intermediary, Mailbox could deliver more useful, actionable messages to users on its platform without creating yet another inbox.
The Mailbox team has already suffered to learn the difficulty of succeeding in a sea of similar products. After all, great adoption and poor retention precipitated Orchestra’s pivot to Mailbox:
Lifehacker calls Orchestra the best to-do app for iPhone. Apple named it the 2011 Productivity App of the Year. And perhaps more importantly, user reviews have been nothing short of amazing. In short, the response has been more positive than we could have possibly imagined.
So that’s the good news. But as we analyzed how people used Orchestra, we discovered two challenging facts. First, most people (even the very excited ones) stop using Orchestra over time, in a pattern similar to other to-do lists. And second, no matter how much people use the app, almost everyone still has tasks trapped in their email. At best what you get is a two-tool world: two systems that you have to stay on top of, with one of them (Orchestra) getting used less and less over time.
Implicit in the quote above is that Mailbox, or any client, must solve email as more than just a todo problem. Todo-oriented interaction and design overhead cannot interfere with more consumer-oriented use cases, like sharing cat pictures or saying hello. If the todo workflow negatively impacts more basic communication, users won’t adopt it for anything but todos - effectively recreating Orchestra’s two-tool problem. The ideal case for all users is less time managing inboxes.
But we’re getting closer to mere implementation details. Philosophically, email clients increasingly acknowledge inbox user needs instead of simply showing unread at top. Mailbox as marketed doesn’t quite answer Graham’s challenge, but apps like it are the first breaths in email’s next stage of evolution.