Developers: stop re-AOLizing the web!

No AOLI recently succumbed to the hype and downloaded Mailbox, a mobile email client that tries to help you manage your overflowing email inbox and achieve the mythical “inbox zero”.

Mailbox does this by encouraging you to immediately archive, trash or schedule the email for a re-read or response using a swipe interface. It’s pretty good, actually, and I’ve found myself with fewer new emails just sitting in my inbox waiting for me to do something with them. My older email archive is another matter.

There’s one major flaw however.

By using Mailbox, I’m effectively helping to re-AOLize the web. You see, Mailbox only supports two email providers: Gmail and Apple iCloud.

I find it incredible that an app developer working on an open, well-documented and well-understood platform like email has effectively closed down access to their product to users who are on just a couple of providers.

Don’t get me wrong: I know the problems are difficult, especially as open platforms beget a multitude of implementations.

But by choosing to lock yourself into the Google API, when there is another, really open way to do things, feels like a mistake to me. If Mailbox supported any standardised IMAP provider, they’d no doubt have access to a much wider user base who would use their app across multiple providers.

And they might even be able to charge for the app and make an income – rather than selling themselves to Dropbox to survive.

It doesn’t help that locking me even more to the Google ecosystem and all the threats to my privacy and freedom that brings with it. Dropbox is another cloud company with a questionable approach to customer’s privacy and freedom.

Google (and to a lesser extent) Apple, Facebook and Twitter, have little interest in allowing their products to inter-operate in a meaningful way. Let’s remember that this is exactly how much of the consumer internet worked in the late 80s and 90s: CompuServe only reluctantly added email to its internal messaging and AoL generally preferred to lock down users to its own walled-garden of content rather than having them access the web. Both these networks, once seen as pioneers are now effectively defunct.

When developers choose to lock-in to an ecosystem like Google, they also lock in users. And that’s when innovation dies: users’ choice is restricted, so they demand less (and alternatives don’t get developed). By using it myself, I’m helping depress demand for a good email client that works with multiple providers. That’s not a good thing because it means I’ll have less choice.

Despite email being an inherently tedious form of communication, it’s essential and here to stay. If developers want to play their part in improving email, then it’s not going to be by re-AOLizing the web and locking down to a single provider: it’s going to be by supporting open email platforms that enable a wide range of people to use your product.

As it stands, Mailbox has been a useful so far. But I know my own time with it is limited, as I continue to transition away from closed source, anti-privacy services like Gmail to self-hosted, free and open source alternatives.

And that will be a loss for the Mailbox developers.

19 thoughts on “Developers: stop re-AOLizing the web!

  1. Every app, can’t be everything to everyone. Mailbox began focusing just on Gmail because that is what their targeted demographic uses the most. After a while they built support for Me.com and presumably eventually they will add additional support. If you would like to help that process I highly recommend you apply for a job with Dropbox and join their team to help the process.

    There are a lot of features I’d like to see such as Draft support, and I for one hope they are putting their resources at supporting their existing customers Gmail and Me.com customers rather than focusing on building support for additional imap standards. They are also building Mailbox for Mac so I think supporting your particular IMAP provider is low on the totem pole rather than them some devious plot.

    If you want open source mail provider then go for it. It sounds like your still using Gmail however since you mention, “as I continue to transition”, rather than “I switched to..”. Also if you want an open source email app, then find one and use it, and surprised you are using iOS over Android for that matter, or why not use the Firefox phone coming up to be really open source. I promise your departure to those products will be of no loss to Mailbox team or Google or Apple. Wishing you the best in transition!

  2. Pingback: Developers: stop re-AOLizing the web! | NYC Startup News

  3. I assumed this was about horrible web design so I got a real kick out of this page’s horrible web design. First page entirely empty: check; Borders larger than half the page: check; zero border at the bottom of the page: check

  4. Mailbox is part of dropbox’s play to build a ecosystem like of apps and services like google, eventually the only email they will support is dropbox or mailbox.com.

  5. It’s crazy to think that have support only to iCloud and gmail is considered by marketers as an advantage/feature. Mailbox was entirely built upon hypes and lock-ins. They pre-launched exclusively on appstore without an app. And they probably are not going to change, so what about a free version of it? :)

    Great article.

  6. I liked the article, and agree on the general principles. I am firmly in the pro-standards camp. Another commenter mentioned the main problem, user experience and polish drive adoption. So standards-based solutions must have good user experience in order to be adopted. Otherwise the majority of people will adopt the closed source options that give them the most benefit from their point of view, which is often doing something in the easiest and fastest way possible. As an ironical example, the writer’s blog has buttons at the top for Twitter, Facebook, and Google+, but nowhere is there an RSS or Atom subscription button.

    • Any thoughts on what could be created standards-wise to allow for the same user experience constraints?

      Does Google’s API handle push notifications and the like, or is it something else?

  7. I already suspect the major email providers (Gmail, Yahoo, Apple, Hotmail, etc…) to send your emails more easily to their customer’s spam folders if you send them from your own server (even if you respect the good practices like spf and dkim).

  8. I imagine the MVP for the product was to support the most widely used email client first and add more services once they get momentum. You have to start somewhere.

  9. I think the app *does* use IMAP under the hood. However, IMAP implementations are not standardized across all providers. There are standards, but that doesn’t mean they’re followed to the letter. Limiting to a couple of providers to get the experience correct seems to me like a good move. They’re able to focus on what makes their app special, rather than figuring out wtf some IMAP server is doing wrong and working around it.

    • This was my initial suspicion as well. Email is such an important service to people, that anything less than flawless behavior wouldn’t be tolerated. IMAP implementations can vary so much from provider to provider that the developers likely had to focus their effort on fully supporting a few really well.

  10. The funny thing is, icloud just uses standard IMAP afaik (or at least more standard than gmail’s monstrosity), so I don’t see why this app doesn’t support other IMAP services.

  11. Pingback: Developers: stop re-AOLizing the web! | Email is broken

Leave a Reply

Your email address will not be published. Required fields are marked *