I came to a revelation of sorts earlier in the week.
Email apps, not web apps, represent New Web for the enterprise. I suppose you could say Enterprise 2.0, but if you’ve been with me for a while, you know I steer clear of that term.
Photo by piccadillywilson from Flickr used under Creative Commons
Work requires communication above all else. No communication, no work. Whether it’s meetings or phone calls, email or IM, communication at work is a requirement. Email is the method of choice for work communication, and it’s been that way for more than a decade now, depending on the industry.
The browser is also a necessity for a lot of people, but it’s not typically used for communication. There are exceptions–micro-blogging, social networks, web mail. Generally speaking though, the browser is used to collect information, and if it’s used for communication, it’s not the primary tool. There’s always an email account there somewhere.
So, web apps, like Connect, that aim to help people collaborate on work in new ways represent a destination, or more accurately, another destination.
This is a frequent complaint about Connect, and I get why. I don’t know about other companies, but we have a ton of internal apps that serve many different purposes. So, I understand that people would be bummed to have to use another app and remember another destination.
Even though Connect does a better job at many work-related tasks than email, I’ve learned to embrace email, rather than try to ween everyone off it.
So, our focus for email integration with Connect has been both to meet the needs (group digest emails, subscribe to threads, notifications) and extend Connect as an email app (post by email, comment by email)
Replacing email is a pipe dream.
The good news is that a bunch of ingenious apps have shown how email can be used as a web app client. I’m calling these email apps for the time being. You’ve heard about them here in the past: Sandy (now defunct), TripIt, Posterous, and a new one, Liaise, launched this week at DEMO.
Liaise is pretty slick, although only for Outlook (ick) currently. Check out the demo.
Soon, you can add Google Wave to that list. Wave promises to provide a platform for even more email apps; in fact, Anthony seems pretty confident he could build a Liaise-type project app with Wave.
So, what do you see in your company? Are people generally open to trying new Web/Enterprise 2.0 web apps? Or do they want to stay in their email? Do you think working with email as the client makes sense? Or should development be focused in web apps, adding email as an afterthought?
Find the comments.
Nice analysis. Liaise is definitely great and promising. But I do not think their plugin approach is sufficient :
– first they will have to face every request of non-outlook users. They say they are planning Gmail, Wave… But look at Xobni : they said they'd support every client (thunderbird, gmail…) but they are still only outlook. And even if one day they support 2/3 mail platforms, they'd still have to keep it up w product evolutions… What a hassle !!
– people do like added features provided by plugins, but they do not accept CPU / RAM overload. Here we all installed Xobni and used it for 2/3 weeks, but uninstalled it after… Or look at Chrome : it is atracting FF users mainly because it is lightweight (even if they had to quit some plugins)… And looking at Liaise, I don't think it will be any close to lightweight. 🙂
What is important is to support *integration* to the email (talk about the *protocol*), not the email clients…
I've been working on a project today which involves the updating of several documents based upon information from a bunch of people. The updates were provided to me via email, and as I complete the updates, I move them from folder to folder.
After reading your post, it occurred to me that email provides you control – or at least the illusion of control – over the content. If you're using a web application, you clearly understand that the data is “somewhere else”; perhaps it's just me, but even when the email is stored on an external server, I still feel that I have more control over it than I do a microblog post or whatever.
Another advantage of email is its near-universal connectivity. If I want to make a verified comment on your blog, I have to log in to Disqus or Facebook or Twitter; a MySpace account does me no good if I want to make a verified comment here. Contrast that with email, which I can use to connect with you whether you're at oracle.com or jippii.fi or bride2b.ru or whatever. 20 years ago, it was very hard to send an email from one service to another, but those days are long since past. I wonder if the ease of data exchange makes a difference regarding use rates for email?
Agreed. I personally don't care for the plugin approach for email clients, e.g. Xoopit, which I got bored with pretty quickly. The plugin approach does extend your development across too many clients, much like web apps only worse.
I think people would tolerate a plugin if it provides a must-have feature. Liaise is on the path, but they have work to do.
My design philosophy is to build engines that understand emails, like TripIt, Posterous and old school mail list daemons, to make the email client itself an interface with the system. So, I think we're on the same page.
Good point about data exchange. Obviously, the web has a long way to go before it gets an email like experience across sites; I suppose OpenID handled by the browser at run-time is the closest analog, very similar to email clients.
The control piece sounds about right too. All the objects are the same and are known entities, so it makes sense. Generally, people are just more comfortable with email than they are with web apps, which means adoption flows better through that approach.
Nice analysis. Liaise is definitely great and promising. But I do not think their plugin approach is sufficient :
– first they will have to face every request of non-outlook users. They say they are planning Gmail, Wave… But look at Xobni : they said they'd support every client (thunderbird, gmail…) but they are still only outlook. And even if one day they support 2/3 mail platforms, they'd still have to keep it up w product evolutions… What a hassle !!
– people do like added features provided by plugins, but they do not accept CPU / RAM overload. Here we all installed Xobni and used it for 2/3 weeks, but uninstalled it after… Or look at Chrome : it is atracting FF users mainly because it is lightweight (even if they had to quit some plugins)… And looking at Liaise, I don't think it will be any close to lightweight. 🙂
What is important is to support *integration* to the email (talk about the *protocol*), not the email clients…
I've been working on a project today which involves the updating of several documents based upon information from a bunch of people. The updates were provided to me via email, and as I complete the updates, I move them from folder to folder.
After reading your post, it occurred to me that email provides you control – or at least the illusion of control – over the content. If you're using a web application, you clearly understand that the data is “somewhere else”; perhaps it's just me, but even when the email is stored on an external server, I still feel that I have more control over it than I do a microblog post or whatever.
Another advantage of email is its near-universal connectivity. If I want to make a verified comment on your blog, I have to log in to Disqus or Facebook or Twitter; a MySpace account does me no good if I want to make a verified comment here. Contrast that with email, which I can use to connect with you whether you're at oracle.com or jippii.fi or bride2b.ru or whatever. 20 years ago, it was very hard to send an email from one service to another, but those days are long since past. I wonder if the ease of data exchange makes a difference regarding use rates for email?
Agreed. I personally don't care for the plugin approach for email clients, e.g. Xoopit, which I got bored with pretty quickly. The plugin approach does extend your development across too many clients, much like web apps only worse.
I think people would tolerate a plugin if it provides a must-have feature. Liaise is on the path, but they have work to do.
My design philosophy is to build engines that understand emails, like TripIt, Posterous and old school mail list daemons, to make the email client itself an interface with the system. So, I think we're on the same page.
Good point about data exchange. Obviously, the web has a long way to go before it gets an email like experience across sites; I suppose OpenID handled by the browser at run-time is the closest analog, very similar to email clients.
The control piece sounds about right too. All the objects are the same and are known entities, so it makes sense. Generally, people are just more comfortable with email than they are with web apps, which means adoption flows better through that approach.