Email sucks. Let's make it better.

One question I’m answering a lot these days is “Why Email?”

In my prior life (CTO of WebLogic/BEA Systems) I was chained to my email for a minimum of 3-4 hours per day. Even while traveling to Asia or Europe, my admin. had to carve out an additional 2.5 hours of time from every meeting day for email. No doubt much of this overhead was due to sheer volumes (hundred+ inbound per day, not counting spam and mailing lists). But I also became convinced that I was wasting perhaps 1/3 of that time on tasks that my email software should have been doing for me:
(1) Sorting/moving email across north of 600 nested folders so I could hopefully find communications again (my self-defined sorting system probably worked 75% of the time; other times I would give up before finding the thread I was looking for);
(2) Managing external/internal conversations between customers and tech. leaders—At least ten times a day, a sales/customer question was sent to me. As CTO, I often (probably most often) didn’t know the answer, but I did know who did, and so I had to play intermediary in forwarding and editing responses;
(3) Managing the workflow of communications to make sure none of the balls got dropped (To accomplish this, I had “hot”, “hotter”, “hottest”, “on hold”, and so on “staging” folders);
(4) Switching context from email to my contacts, email to my calendar, email to other web applications, etc. and then having to hand cut and paste content from one to the other; and
(5) Waiting for my email client while it sync’ed with my email server (consuming most of my client CPU and bandwidth in the process).

Like many other power users I have commiserated with, email became the most frustrating application I had to deal with, and it was the one that I was spending the most time on by at least an order of magnitude. How can it be that Yahoo! and Google are offering innovative, Web 2.0 email solutions with a gigabyte+ of storage for free, while my corporate messaging is still stuck in the mid 90’s?

What I decided I was seeking was more of a “Web 2.0” solution:
(1) Rich search that covered every syntactic aspect of email and the associated attachments, so that I could always lay my fingers on what I was looking for without that a prior foldering overhead;
(2) Conversation management that spanned folders, so when new communications came in, they would be automatically correlated to relevant content in my archives;
(3) Content that was automatically linked to Web and enterprise applications: When a customer case number was included in email, why did I have to cut and paste it by hand into our product support system? When a travel itinerary showed up, why did I have to cut and paste it into my calendar, to print tickets, or to check for on-time status? What I really wanted as an AJAX-style “mash up” of email and the relevant application right there in my email client! That, by the way, is the real power of AJAX for email—not just the zero install/zero-management client: If the browser is the defacto pull interface, then email is the defacto push interface, and an AJAX messaging client allows the user to mix-and-match both paradigms without switching UIs.

What was surprising to me after my first six months as a Zimbrian is how similarly frustrated the system administrators are with the day-to-day care and feeding of enterprise messaging deployments. Laments I hear include:
(1) Why don’t I have out of the box compatibility with my existing messaging PC and wireless clients?: Outlook—on-line and off-line, Apple Mail & iCal, Evolution, Thunderbird/Sunbird, Eudora, Blackberry, Good, Treo, Nokia, and so on;
(2) Why are messaging servers “black boxes” that prevent me from understanding what’s on the disk, making my own back-ups, and reasoning about scalability?;
(4) Why do I have to restore an entire storage group to recover an individual user’s mailbox at a particular point in time?
(5) Why do I have to buy enough SAN or NAS storage to redundantly store email attachments once per user (some systems) or once per storage group (other systems)?
(6) Why do I have to bolt on and then manage complex, unintegrated solutions for retention & archiving, replication & disaster recovery, HSM, and discovery/cross mailbox search when all of these services could be provided in a more integrated fashion?
(7) Why do I have to install and configure VPN and client software on every machine required to support email (including my employee’s home systems) when the web security model and AJAX provide such a rich, zero administration client experience?
(8) Why can’t I prevent potentially dangerous attachments from being downloaded to less protected clients by instead opening them on secured (Unix) servers with the latest anti-virus software, and providing an HTML rendering of relevant documents to those clients?

Hopefully, you agree—email today is well short of what email could and should be. So that’s why email was the best choice for me—the opportunity work with a great team to strive to deliver a compelling better user and administrative experience was simply too much fun to pass up.

One Response to Email sucks. Let's make it better.

  1. Will Arnford October 21, 2010 at 4:17 PM #

    A few quick reasons why Zimbra sucks even as a desktop solution:

    1. No easy way to setup hotmail or aol. Odd, two major email providers and they are not even listed as options. Oh, that’s because you can’t in Zimbra, they’re incompatible. Brilliant.

    2. Where are the files to easily backup? Where’s the corruption repair tool?

    Stuck with outlook, just because it’s been around so damn long everyone knows how to deal with it, even if it is kludgy to use.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures