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.
on September 28th, 2005 at 10:32 am
Conversations on the Web, Sep 29
Interesting conversations going on around the place: Zimbra on “Why Email?”. Scott writes about why Zimbra has entered the email software market, starting with the major pain he experienced in dealing with email using traditional software products. Com…
on September 29th, 2005 at 6:43 pm
Hi Scott,
I have comments. Wanna help.
IMHO you are missing the target. Sorry I can’t express myself in as good as English as I’d like to … Anyway if something sounds offensive it’s an error in the handling of the words and I humbly apologize.
Let’s try to say it.
The phrase that sounds in my mind is “more of the same”. Yes Zimbra looks great but this is not the point.
Your main complain is that you were chained to your email, right?
This has a twofold solution, one part to be done by you (or whoever) and the other by the email.
As of you, the first idea is not to receive so much email, period.
As Bea’s CTO you were a rather expensive and scarse resource, right? Well, in front of each mail you should have pondered “is this worth the expense?” and devise a means to reject the message politely. Now this would be an enhancement: a polite rejector. Right click, see a contextual menu of rejection levels and the sender’ stats (freq, last, …) and click “Reject by … method”.
Or arrange early meetings every morning with the most prolific emailers ant say it all in person.
The other part is the mail system. You wrote “… chained to my email…”.
Whay not “our” email? what is it, a tooth brush?
One problem with email is that it’s sooo personal. Now think of the snail paper mail. Anybody else can open the envelopes and read, proprocess, classify, discard, panic, any reaction. Unless the envelope is labeled “personal”, then you’d get an unopened letter.
AFAIK there is no such functionaluty in email: preprocess and tag as personal. This would be a step forward: the ability to delegate email processing into a network of dependents, some technical and other not so.
As of the integration with other applications, I’ve seen those inlined constructs and somehow my intuition tells me that this is not the way, it looks unstable, it feels like a demo that might crumble in real life.
Whay you have are pieces of text and with some magic you make them live, or am I wrong?
Who says that this is a telephone number? I’d better have it work “the other way”.
I’d have “consumers” and I’d feed them with the texts. Lemme sketch an example: there is a phone number, you select it (no need, but let’s imagine it so) and somehow you right click it and ger a “consumers” contextual menu.
Contextual because the context is you, for example you are the company’s lawyer clicking a part number: no way. You’d better click something like “Kramer vs. Kramer” or “SCO vs. Them All”.
The “consumer” (more below) you chose can extend the selection skipping the quoted text >s and fire the right application, can’t it?
This is like the Windows shortcuts but not quite. The “consumer” does not need a “document” (whatever the meaning of this) but anything from a couple characters thru a whole attachment.
And specially, the “consumers” do not stay in the desktok waiting for a drop but they strive into your texts (email and the other too) for a string to chop.
According to your profile you have the right needed mix of consumers set in your profile, and always updated from the server where they live.
A consumer (what a horrible name!) gets it’s litle piece of data and a lot more from the context, the context is you. In Windows ShortCuts the context is a mere starting directory, lame.
A consumer is implemented not as a silly code line (as in Windows) but as a , any piece of software available on the net. Hmmm, sounds like a “service”, doesn’t it?
Well, that’s what I think. About how to cope with scads of email, by being able to share the burden, and about the magic by creating a new “let’s not call then shortcuts”.
Today I’ve seen the demo. It’s neatly crafted but there are problems, sorry.
At first sight it’s soo “VB4″ where everything has to be 3D with rounded shaded borders.
This ads nothing to the application, specially now that’s even not desired. Notice that the applications tend to be flatter, with less, lighter, artifacts.
There are good reasons for this, you should take some usability advice like this I’m giving here.
The more complex, visually “rich” the interface is, the more you put a burden in the user’s brain.
The poor guy has to look at the screen and tell the information from the noise.
In Zimbra the signal to noise ratio is not excellent.
Recall your first words at Email sucks: “… chained …”. Imagine you are chained in a heavily decorated scenario like a chinese restaurant (of the cheap class I mean). After a while you’ll loathe all those artifects. The millionth time you look at it you might kill.
For a heavily used application a minimalist approach is better. Unless you are hiding lack of content with excess of decoration, a la web by 1998.
Also the artifacts limit your chances severely. For example I don’t see well and I’d like a bigger font. If I hit control+ the layout might get severely compromised.
And it’s not a means of providing “skins”. This is the no-solution solution, it’s handling the problem to the user. Imagine the other CTOs, no-nerds, searchig in the skin gallery for one that fits: it’s not so, we the application designers and developers must solve this problem from day one.
A skin is a usable for WinAmp, I have a retor Sony receiver much like the vintage real one I use to feed my Tannoy accoustic boxes (vintage too).
Well that’s enough. It’s 10:30 PM ans still at work. I’m writing this into a vim frame, will all this text fit into the small textarea at your blog’s page? [yes it did]
One more idea. We developers tend too often to make a program that solves the problem we have. For a program to be a product it must solve somebody else’s problem, so they want to give thay money to you. The argument “.. I was chained …” is to be reviewed. You might receive empathy gestures while expressing that, but the question is “what’s the potential user’s problem”.
Seeya!
–
Juan Lanus
TECNOSOL
Argentina
on October 31st, 2005 at 7:35 am
Is Zimbra really an ambient microsearch engine?
I read somewhere this morning that Alan Turing said, and I paraphrase very roughly here, most computing tasks are actually about search. That seed sparked something in my mind while reading Scott Dietzen on Zimbra today. Zimbra, for those of…
on November 5th, 2005 at 11:05 am
Whatever happened to the notion “Beauty in Simplicity” ?
on November 16th, 2007 at 8:39 am
Hi,
We are a company dedicated to providing services to your mobile device, We provide push e-mail to Windows Mobile devises and smart phones but will soon offer you a range of standards based co-operation and groupware components built on our simple but attractive technology; Mobile E-mail, Mobile Calendaring, Mobile Task Management.
The features for sending include Online and offline composition, Natural integration of your address book, Attach files, use signatures and store drafts. For receiving you can receive mails in “stand-by” mode, receive and edit attachments, receive only “the beginning” of a message to save data, read HTML emails. Receive only “recent” mail to avoid downloading 1000’s of e-mails, sent/deleted mailbox synchronization can be done as well. Some other features include SMTP authentication, consolidated notifications (…you have 10 new e-mails). All this and still often 50% smaller than competing software – saving your RAM and speeding up your device.
You can download and try for free, no obligations at his link http://www.emansio.com/download or you can buy this product at http://www.emansio.com/buy.jsp
Regards,
Sankalp (Emansio Team)