Yet-another-email-is-dead (OK, just in danger) article, this time by Alex Iskold @ ReadWriteWeb. Alex adds Twitter’s increasing popularity to the standard “reusable” arguments: teenagers using IM, or increasingly SMS, and most recently Facebook instead of email which they find cumbersome, slow and unreliable - hence email usage will decline.
I beg to disagree as I did before, and before. Sure, I also get frustrated by the occasional rapid-fire exchange of one-line emails when by the 15th round we both realize the conversation should have started on IM. Most of teenagers’ interaction is social, immediate, and SMS works perfectly well in those situations. However, we all enter business, get a job..etc sooner or later, like it or not… Our communication style changes along with that - often requiring a build-up of logical structure, sequence, or simply a written record of facts, and email is vital for this type of communication. As much fun Twitter may be, I rarely have (or see) serious ongoing discussions there - in other words Tweets are in addition, instead of email.
Email in business is being “attacked” from another direction though: for project teams, planning activity, collaboratively designing a document, staging an event… etc email is a real wasteful medium. Or should I say, it’s the perfect place for information to get buried. This type of communication is most effective using a wiki, or an increasing number of online tools supporting native collaboration. Yesterday I reviewed a startup CEO’s ppt deck, and it took us 4 rounds of emailed versions of the same presentation - it would have been a lot easier to collaborate on just one “master” presentation in Zoho Show.
So yes, I agree with Alex, even in business we’re offloading stuff off email. But email is far from dead, or even in danger, and it won’t be any time soon. We just have to learn to use the right tool in the right situation. As usual, Rod Boothby says it better in a single chart:
Rod’s chart is almost two years old, but still valid - perhaps I would update it to say “Wiki and collaborative documents”. My own post here is a slightly updated version of an older one from last year, which in turn was an almost verbatim reprint of another one from July 2006. I rarely re-post old stuff, but in this case I felt it still made a valid point. Next year, when someone brings up the “is email dead?” question, I’ll dust it off again.
Last time I thought VP Marketing @ Atlassian was the Dream Job, but this one is better. Your job will be to compare beer quality in Amsterdam vs. what they sell at Atlassian’s (almost) in-house pub in Sydney. According to a commenter you may do some additional market research, too.
Oh, well, here’s what they really want (cool company anyway).
I am deeply interested in wikis, and business oriented ones in particular, in fact was considering doing a fairly detailed comparative study, so I got really excited seeing on twitter that Tom Raftery posted an Enterprise wiki review. Too bad it’s not a review; it’s a rant that lacks any methodology or real comparison.
He goes at length describing the installation nightmare:
The setup of the Confluence wiki was far from straightforward. It took two of us the best part of a day to simply install it. Remember that as I was doing this for it@cork, this was not billable time. I was installing it on my own server and because Confluence requires TomCat as its webserver it had to run on a separate port to Apache. This meant several people couldn’t view it in their organisations.
Sounds to me like a case of bad platform choice. Now, I am by far not as technically inclined as Tom is, and am biased: I won’t touch anything that needs to be installed. That’s what Software as a Service is for. Which, incidentally is an available option for Confluence, so how Tom got into comparing “hard-to-install” Confluence with hosted PBwiki and Socialtext is beyond me - it’s an apples-to-oranges comparison. And there’s not much of a comparison either… here’s all he has to say about two other products:
By the way, I did also try out DekiWiki and Twiki but I ruled them out quite early on.
That’s not a very detailed review, if you ask me. DekiWiki is downloaded about 3000 times a day (!), so some people must like it… even though their acquisition of SocialText was just an April 1 joke.
Joke apart, a word on picking the right tool for the right job: perhaps you don’t even need an “enterprise class” wiki for a conference. The official Oracle Wiki is based on Wetpaint, a decidedly consumer and community-focused platform.
My personal takeaway from this to me is to look at PBWiki: when I last checked it out, it was a baby-wiki for some reason popular in geek circles; apparently it has grown up. I’m not sure I will get to do the wiki review I’ve been planning, but in the meantime if Tom decides to write a real one, I am looking forward to reading it.
Update: Tom responded in a comment below. The hosted version of Confluence is NOT available under the community license. He ruled out DekiWiki as when he figured he could not to create Groups. There’s more, please read his comment.
I had already spent half a decade implementing SAP solutions in the 90’s when I finally got enlightened, learning the “proper term” for what I was doing: ERP, as in Enterprise Resource Planning. The term was coined by then Gartner Analyst, now Enterprise Irregular Erik Keller. Now another fellow Enterprise Irregular, Sig Rinde introduces a new interpretation of ERP: Easily Repeatable Process. Of course he contrasts that with his new acronym, BRP (not to be confused with BPR, another 90’s favorite), which means Barely Repeatable Process. BRP is what Thingamy, Sig’s lightweight, extremely adoptable system attempts to address. But it’s a very-very tough sell…
ERP traditionally addresses the core, standard, and as such repeatable business processes. Whatever it can’t handle are the exceptions: processes to be handled by knowledge workers outside the realm of ERP, by traditional means: phone calls, spreadsheets, creative thinking and a lot of emailing back and forth. Exceptions may be a fraction of business volume, but they are what corporate employees spend most of their time resolving. If that’s the case, knowledge workers who come up with innovative solutions may consider it a good practice to document them just in case the “exception” ever occurs again… and if it does a few times, well then it’s no longer an exception, but a (Barely) Repeatable Process.
Wikis in the Enterprise are a simple yet effective solution to manage such BRPs: they facilitate collaboration of all knowledge workers involved, allow some structure (structure is helpful when not pre-imposed but flexibly created) to organize data and finally, as a by-product they serve as documentation of the solution for future re-use.
Neither process-driven heavyweight systems like ERP, nor innovative, lightweight collaboration tools like wikis are the one and only mantra for most businesses (see my previous rant on “you can’t run your supply chain on a wiki“), they have their own place and should complement each other. Standard business processes and exceptions are not black-and-white opposites either: it’s a continuum, and halfway is BRP. If ERP (in the traditional meaning) tries to address to many of theses BRPs, it gets overly complex (it already is!), hard to configure and use.
This is the dilemma Sig’s system, Thingamy addresses. It’s neither free-form collaboration, nor ERP: it’s a business system framework, that allows you to model and define business processes: a tool to create your own custom-made ERP, if you like.
And therein lies the rub. Most business users don’t want to create software. They want to use it. This was the problem that caused the demise of Teqlo: the unfunded, unproven belief, that users actually want to interactively create their tools. No, they want to deal with the urgent business problems (the BRP), using whatever tools are readily available.
Thingamy’s dilemma is finding the customer: it certainly won’t be the business user. A modeling tool, simple it may be has a learning curve, dealing with it is a distraction to say the least. Thingamy’s likely “owner” would be corporate IT which would have to create processes on demand. But we all know what happens if you need to call IT to create a “program” for you. Thingamy could possibly be a handy tool for consultants, system integrator firms - but they all have their own army of programmers, toolsets..etc, which makes it an awfully hard sell, IMHO.
Thingamy is no doubt an elegant solution, I just don’t see the mass market need for it, because it does not solve a mass market problem. Or I should say, it does, but there’s a mismatch between whose problems it solves and who can use it. Sig himself defines collaboration as a workaround for the Barely Repeatable Processes in the Enterprise: my bet is that this “workaround” is here to stay for a long time.
Update (3/18): CIO Magazine interviews Ross Mayfield, Founder and Chairman of Socialtext, an enterprise wiki company:
Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process.
… the greatest source of sustainable innovation is how you’re handling these exceptions to business process.
… So I’ve always looked at it as we’re doing the other half of enterprise software: making this unstructured information transparent.
Three weeks ago I speculated that JotSpot, the user-friendly wiki swallowed by Google a year and a half ago would soon come out of hibernation, and Voila! here it is, rebranded as Google Sites. It is the first service only available as part of Google Apps (including the free version), although I had some difficulty accessing it. Under “Manage this Domain” I could add “Sites” as a new service, but it did not show up on my account as an accessible application. When I typed sites.google.com it wanted me to sign up for Google Apps even though I was already logged in to my account. Of course trying to do so resulted in the error message:
Google Apps for zoliblog.com has already been registered by your domain administrator. Please contact your admin directly to get access to Google Apps services.
Catch 22. But there’s a solution: just type the direct URL (sites.google.com/a/yourdomain.com as default, or customize it to your liking) and you can get into Sites. I’m sure Google will soon add it to the Apps menu. (Sidenote: my old JotSpot account is still alive at name.jot.com).
Google no longer calls this a wiki, which I think is a good move. I previously wrote:
Wikis have arrived when …you don’t even have to know what they are to use one. You don’t have to know you’re using a wiki, just happily type away, creating shareable content on the Web.
I was discussing Wetpaint, the user friendly, wiki-less wiki there, and I think it’s smart of Google to follow that pattern… more later, but first, under the hood it is still a wiki, so let’s examine some of the wiki basics.
The interface is familiar from good old JotSpot (as a sidenote, the old JotSpot accounts are still alive at name.jot.com). There’s a basic wysiwyg editor, the Edit button is large and visible, and so is the New Page button. Good old JotSpot had several more ways of creating new pages, which are gone - perhaps for the best:
WikiWords or CamelCase: in old JotSpot anything you typed with embedded capitalization became a link to a page. As a relatively early wiki-user I liked it, as the easiest way to LinkAsYouThink. But in the Web 2.0 age we keep on bastardizing grammar writing EveryThingLikeThis, so more and more WikiWords had to be “unlinked”… too much confusion, especially for the new generation of mainstream users.
Linking to a shell-page before it’s created. This was a useful feature, even if we eliminate camelcase, I could use the “Link” icon, and mark up text as a link to a new sub-page, to be filled with content later. Again, this supports flow-thinking, or LinkAsYouThink, which I regret is gone.
The “New Page” button. This is the only remaining option in Google Sites, and I think the fact that it offers to pick a parent page (enforced hierarchy) is an improvement. No more orphan pages, yet relatively flexible hierarchy.
For those not too familiar with wiki terms, I discuss some of these concepts in more detail here: technically an article on SocialText 2.0, but I often make comparisons to JotSpot and Atlassian’s Confluence.
I’m glad to see Sites retained breadcrumbs for easier navigation, and they added sitemaps, a tree-style view of all your pages. This could be improved to allow for drag-and-drop style moving of the pages (changing the hierarchy), like Zoho Wiki does.
I’m surprised Sites still does not have inbound links: this is a critical feature for all wikis, whatever we call them. A wiki is all about associating pieces of information with each other, and the inbound link, also referred to as backlink shows you where the information on the current page is used elsewhere. The JotSpot tea half-recognized the importance of backlinks, as they were available as as a downloadable plugin on the Jot Development wiki, but never made it to the standard feature-set, and are apparently lost in the Google reincarnation, at least for now.
Attachment handling is as good as it was in the original JotSpot: it maintains previous versions, allows users to revert to earlier ones…etc. However, Google missed a huge chance here to by not offering to convert the attached documents to its own Google Docs style. This point takes us to the next level: stepping outside the boundaries of a standalone wiki and using it as a facility to pull together data created by other applications.
Last year I said after burying JotSpot for a year, Google can’t just release it as a wiki, instead:
…I hope that means they rethought everything and integrated JotSpot well into a number of offerings.
It overlaps with Page Creator, also with the simplified version found in Google Groups - in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.
Well, what’s the score on that prediction? Google Sites is a better replacement for Page Creator, Google ditched the JotSpot “apps”, replacing them with their own ones - so far 2 scores out of 3. As for document management.. well, I’d say half a score, or less. (Hey, that’s 2.5 out of 3)
You can somewhat integrate Google Docs (which includes documents, spreadsheets and presentations) by embedding them into any Google Sites page. You have to enter the specific URL though - why not just select from a list? Furthermore, your Google docs or spreadsheets have to be first made public and you have to use the public URL to embed them into Sites. Here’s my test site, showing first an error message, then the actual embedded spreadsheet, after I made it public.
The embedded docs appear properly in the saved page, but I can’t click on it, not even in Edit mode to get to the source. In fact in Edit mode all I see is a graphical placeholder for the embedded doc.
How about sharing / collaboration? As expected, your Sites can be:
private
public
shared with individual email id’s
shared with everyone within your domain
…and you can set view or edit options for all those levels. However, Google missed a big chance again. As a complete coincidence, it’s only yesterday that I raved about Zoho’s Group level sharing, half-announced in a fairly understated manner - hidden in a list of Zoho Writer enhancements. Well, Google already has a very good group facility: Google Groups, which started it’s life as a group discussion / forum system, but it gradually evolved into a decent collaboration platform. Once I have a “group” defined (i.e. the list of members), why doesn’t it become an entity I can share my wiki (sites) or docs with? When I invite users to share the wiki with, there’s an option to save the list as group, but I don’t know where it disappears, can not pull it up either within the wiki or gmail, or docs.
Finally there are gadgets, but if you read Dennis Howlett at ZDNet, gadgets might the feature you don’t want to touch with a ten-foot pole.
Summary: Nice to have Jot back (even if we did not get GSpot. ) Google now has a pretty good and easy web-page creator with some wiki features made user-friendly, and a half-hearted attempt at integrating the rest of the Apps empire using Sites. Perhaps they get it right in the next release.
Yet-another-email-is-dead-article, this time on Slate. It’s the same old argument: teenagers using IM, or increasingly SMS, and most recently Facebook instead of email which they find cumbersome, slow and unreliable - hence email usage will decline.
I beg to disagree. Sure, I also get frustrated by the occasional rapid-fire exchange of one-line emails when by the 15th round we both realize the conversation should have started on IM. Most of teenagers’ interaction is social, immediate, and SMS works perfectly well in those situations. However, we all enter business, get a job..etc sooner or later, like it or not… Our communication style changes along with that - often requiring a build-up of logical structure, sequence, or simply a written record of facts, and email is vital for this type of communication.
Email in business is being “attacked” from another direction though: for project teams, planning activity, collaboratively designing a document, staging an event… etc email is a real wasteful medium. Or should I say, it’s the perfect place for information to get buried. This type of communication is most effective using a wiki. No, email is not dead, and it won’t be any time soon. But we all have to learn to use the right tool in the right situation. As usual, Rod Boothby says it better in a single chart:
(The above post is an almost verbatimreprint of an older onefrom July 2006. I rarely re-post old stuff, but in this case I felt it was still a valid point. And it still will be, next year when someone declares email dead again.)
The 80/20 rule is out (so last century), 90:9:1 is in: the rule of participation in public communities, social networks, wikis:
90% of users are lurkers (i.e., read or observe, but don’t contribute).
9% of users contribute from time to time, but other priorities dominate their time.
1% of users participate a lot and account for most contributions: it can seem as if they don’t have lives because they often post just minutes after whatever event they’re commenting on occurs.
90:9:1 is a pretty good fit for most public wikis, starting with Wikipedia. Ben Gardner observed very different numbers: 50:25:x (he does not specify “x”). The interesting number here is 25, or it’s relationship to 50, meaning:
When the same question was asked about our corporate wiki ~50% of those present had used it but about ~50% of those had edited it.
Active participation in a corporate environment is much higher than in the public domain - this is not really a surprise, since the corporate wiki is used by people of real identities and reputations, and most importantly, shared objectives. This is also why Prof. Andrew McAfee hasn’t seen vandalism - a plague of public wikis - in the corporate world at all.
I suspect that 25% can go a lot higher, depending on the purpose of the wiki. When after the initial “grassroots movement” management fully embraces the wiki not as an optional, after-the-fact knowledge-sharing tool, but the primary facility to conduct work, it becomes the fabric of everyday business, where people create, collaborate, and in the process capture information. When the wiki is the primary work / collaboration platform, participation is no longer optional. Not when the answer to almost any question is “it’s on the wiki.”
1: a coming or flowing together, meeting, or gathering at one point <a happy confluence of weather and scenery>
2 a: the flowing together of two or more streams
b: the place of meeting of two streams
c: the combined stream formed by conjunction
Today we’re seeing the confluence of two worlds: the flow-oriented thinking and collaboration, represented by Confluence, the market-leading enterprise wiki, and the more traditional approach of documents, lists, folders, represented by Microsoft SharePoint. Or perhaps it’s a right-brain / left-brain thing. I’ve talked about it at length, and since Jeremiah, Web Prophet says backlinking is OK, I’ll just do that, instead of repeating myself: Flow vs. Structure: Escaping From the Document & Directory Jungle.
Now, as important forward-looking visioning is, successful business leaders recognize what the market wants today, not where they’d like to lead them tomorrow. Recognizing that Microsoft Office is deeply entrenched in the corporate workplace, Atlassian first added Webdav capabilities to Confluence (drag-and-drop files into the wiki, single click on attachment to edit them in the original MS Office format and save back to the wiki). But customers wanted more, according to Jeffrey Walker, President:
..meeting with customers and analysts, SharePoint came up in every meeting. “We have growing groups who love the wiki, and long standing users of Microsoft and now SharePoint. Help!”, customers asked..
Search: Users can search SharePoint and Confluence content together from one place.
Content sharing: From within SharePoint, users can embed Confluence page contents allowing users to blend content. This also includes Confluences numerous plugins.
Linking: Within Confluence, users can access SharePoint document facilities. By including SharePoint lists and content within Confluence, users, in a single click, can edit Microsoft Office documents.
Single Sign-On and Security: With one login, users can access both systems while seeing only what they have permission to view.
In short, access your information, whether you’re the wiki-flow type or the create-save-hide-in-folders type
The screenprint above shows a Confluence page (with the charting plugin) embedded within, and editable directly from SharePoint. For more, check out the feature tour.
The question that weighs most heavily is: is there enough incentive for Microsoft to participate in this partnership in any significant way? The immediate economics aren’t obvious for Microsoft, which leaves us with two options:
- but I’m not giving those options away, you’ll have to read his post. (as an aside, he is the only one examining the business side, but his post is not on TechMeme - let’s see if we can push it there)
Speculation aside, some numbers: SharePoint has 80 million users while Atlassian Confluence has 4,100 customers - I don’t know how many users that translates to, but I’ve just written about SAP’s SDN/BPX communities which has about a million (!) users, and Confluence is a significant part of it. That said, Jeffrey said it right, David kisses Goliath in this deal.
There is no marketing agreement behind it, but I wouldn’t be surprised to see Microsoft’s huge reseller channel show interest in Confluence. And frankly, just removing the “we’re a SharePoint-shop” political obstacle in some major enterprise client is worth it alone.
Silicon Valley Web Builder will host a wiki-focused event tomorrow, Wednesday. While their first wiki event almost a year ago with JotSpot, Socialtext , Atlassian and WetPaint was more introductory, this time the focus will be on - surprise! - the contrast or harmony of Beauty- i.e. attractive UI, vs. the Beast - functional robustness.
The Moderator for tomorrow is Luke Wroblewski, Yahoo’s design guru who has authored a book on Web interface design principles titled “Site-Seeing: A Visual Approach to Web Usability” and is working on thee next one: “Web Form Design Best Practices”.
It’s definitely an interesting mix. Playing a bit with the metaphor, I’d say market leader Atlassian is known as the “beast”: whatever enterprise wiki functionality you can think of, their Confluence will likely have it.
Wetpaint got popular for the “beauty” - that’s why I called it the wiki-less wiki. It’s a most user-friendly self-publishing tool that allows anyone to create a site and transform it into an online community. Incidentally, the SV Web Builder site is built on Wetpaint.
Brainkeeper, a user-friendly enterprise wiki startup took me by surprise when they launched in January. Totally out of left field, they aim to be the beast like Confluence and the beauty like Wetpaint, with twists not seen in wikis, like workflow. I’m really looking forward to seeing how far they’ve got since launch.
“MindTouch is transforming the Wiki from the Web’s best collaborative authoring tool into an open source service platform with a Wiki heart. Their Deki Wiki Hayes release is perhaps the most extendable Wiki tool available today.” I had to steal that line from Read/WriteWeb, I couldn’t have said it any bettr - oh, and congrat’s on reaching the 100,000 user mark!
Zoho is not a pure-play wiki player. Their wiki is just a part of a productivity/collaboration suite, and it shows. Beauty? The UI needs improvement, but this is the only wiki with not just simple a WYSIWYG editor, but a full word processor that writes true html, not wiki syntax. Beast? I think the emphasis here will not be on the standalone product, but how well it integrates with other Zoho offerings, supporting a flow-oriented world that matches how we think.
It will no doubt be an interesting event, so please check out the site details, and remember, admission is free if you register online, but $10 at the door. See you tomorrow.
Our communication style changes along with that - often requiring a build-up of logical structure, sequence, or simply a written record of facts, and email is vital for this type of communication. As much fun Twitter may be, I rarely have (or see) serious ongoing discussions there - in other words Tweets are in addition, instead of email.
Thingamy could possibly be a handy tool for consultants, system integrator firms - but they all have their own army of programmers, toolsets..etc, which makes it an awfully hard sell, IMHO.
Three weeks ago I 
The interface is familiar from good old JotSpot (as a sidenote, the old JotSpot accounts are still alive at name.jot.com). There’s a basic wysiwyg editor, the Edit button is large and visible, and so is the New Page button. Good old JotSpot had several more ways of creating new pages, which are gone - perhaps for the best:
When the same question was asked about our corporate wiki ~50% of those present had used it but about ~50% of those had edited it.
)
Zoli Erdos
