counter on godaddy
post

A Confluence of the Wiki and Document/Folder Worlds

Merriam-Webster:

confluence

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..

The result of today’s joint Microsoft and Atlassian announcement of the SharePoint Connector for Confluence. The initial features include:

  • 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 smile_wink

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.

Jevon MacDonald is pondering about the business realities behind this deal:

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 theresmile_sarcastic)

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.

Sour grapes? Competitor Socialtext announced their SharePoint integration a year ago, and CEO Ross Mayfield says SharePoint wiki was last year’s news. Well, I think Socialpoint, the Socialtext/SharePoint integration was last year’s news, this year’s news is Confluence.

Perhaps next year’s news will be which enterprise wiki vendor could translate their deals into real market gains. smile_shades

Update: here’s a video interview with CEO Mike Cannon-Brookes and President Jeffrey Walker on ScobleShow.

HOT! EXCLUSIVE! Here’s the real price Mike had to pay for this deal… just compare his looks above with this video. What’s next? A suit and tie? smile_tongue

Related posts: Read/WriteWeb, Computerworld, Don Dodge, Atlassian News, WebProNews, Between the Lines, Ross Mayfield’s Weblog, Irregular Enterprise, Radiowalker, elliptical , eWEEK.com, Socialwrite, Trends in the Living Networks, Rebelutionary.

Update (10/19): Intriguing thoughts on wiki plug-ins, KM Web-services and Enterprise SOA on – surprise, suprise! – the SAP Community Network

Zemanta Pixie
post

Wiki: the Beauty & the Beast. Usability & Functionality (Event)

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”.

The Panelists are:

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.

Related posts: Laughing Squid, Lunch 2.0, Functioning Form, Mindtouch, Brainkeeper, Wetpaint, Zoho blogs, Centernetworks.

post

Wikis are Not Knowledge Management Tools

No, this is not an anti-wiki pitch, that would be highly unlikely coming from me. But I am continually amazed how we tend to focus on features while missing the people factor. Knowledge Management is a prime example. KM projects typically do not fail due to software issues, but for human reasons: lack of input, or GIGO. Yet here’s an excerpt from a white paper by enterprise wiki vendor MindTouch::

Wikis provide a flexible alternative to the rigidity of conventional

knowledge management software.

Why wikis work for knowledge management

Based on the features described above, wikis are a powerful replacement for conventional

knowledge management software, because they make knowledge easier to

capture, find and consume:

a. Capturing information: The information is there. Somewhere. Maybe on

a PC, maybe in a file attached to an email, maybe in someone’s head

undocumented. With a wiki, all documents are stored in one central

repository, and files are uploaded rather than attached to emails. Therefore

information is more likely to be captured, stored and made available for reuse.

b. Finding information: When a user has to search a network file server,

he or she must know exactly where to look. A wiki lets a user search

contextually. In addition, because the structure is not required to be linear—

as with KM software—cross-linking of pages helps users not only find

information, but find relevant information.

c. Consuming information: In addition to finding information more easily with

a wiki, a user finds that information in context, meaning the information

is in a location that gives the user some background and perspective relative

to the data. That enables the user to more quickly comprehend the meaning,

significance and relevance of that piece of information. “

All of the above is true – yet it misses the Big Picture. The real story is not about a better tool, but being able to work differently. When wikis are truly embraced in the enterprise, they don’t just make KM easier; they put it out of it’s misery. Yes, that’s right, the wiki is the end of Knowledge Management as we know it: the after-the-fact collection, organization and redistribution of knowledge objects.

The wiki becomes the primary platform to conduct work, the fabric of everyday business, where people create, collaborate, and in the process capture information. While not a Knowledge Management tool, the wiki resolves the KM-problem as a by-product.

Update (6/15/08): Now we have pretty good terms to describe the above, instead of my clumsy explanation. See the discussion on In-the-Flow and Above-the-Flow wikis by Michael Idinopulos and Ross Mayfield.

Ross Mayfield talks about similar ideas in Manage Knowledgement (MK):

“Turns out, users resisted and the algorithms didn’t match reality. With MK, through blogs and wikis, the principle activity is sharing, driven by social incentives. Contribution is simple and unstructured, isn’t a side activity and there is permission to participate. Intelligence is provided by participants, both through the act of sharing and simply leaving behind breadcrumbs of attention.”

Update (5/1): What Happened to Knowledge Management? – by Stewart Mader

post

Read/Write Intranet 2007

Rod Boothby is running a Read/Write Intranet Idol – it’s a poll I invite you to participate in, so I am attaching it at the bottom. But first, it gives me a chance to share some of my (wiki)-thoughts.

The list is a mix of industry behemoths (Microsoft, IBM Lotus), emerging but established brands (Atlassian‘s Confluence, Socialtext, WordPress), relatively known startups and quite a few obscure names. The latter probably not by pure chance: both Rod and I are on the Selection Committee for the next Under the Radar Conference on Office 2.0, and scouting for candidates we have made quite a few new discoveries, including some of these “obscure” names, that likely won’t remain obscure for long.

Perhaps the biggest “discovery” for me was Brainkeeper, a user-friendly enterprise wiki startup that officially launches today. Totally out of left field, they aim to be like market-leader Confluence in functionality yet have a friendly UI like Wetpaint. Oh, and add niceties like Workflow (Itensil?) and an API. Like I said before sometimes it pays to *not* be first on the market …

It was really interesting to watch the poll dynamics change yesterday and this morning. First, with only a handful votes cast unknown little Brainkeeper was leading the chart. Another leader was Koral, a content collaboration startup I’ve been planning to write about way too long now (until I pull my act together, see two reviews by Ismael and John Wilson). What’s content collaboration? It’s content management without the pain of “management”. As much as I am a fan of wikis, not all companies will embrace them: Koral helps those who mostly work with desktop documents (MS Office) share, update, collaborate painlessly.

Back to the poll: as more voters came in, predictably the “brand names” strengthened their position and the “obscure” ones fell somewhat behind. Still with 117 votes cast, I believe it’s mostly InnovationCreators’s primary reader-base, where Microsoft Sharepoint or Lotus Notes Blogsphere are not exactly popular. Like it or not those products will make a killing on the corporate market. So “brand name” here means the likes of Confluence by Atlassian, Socialtext, WordPress, Movable Type…etc.

Confluence’s #1 position on the list reflects it’s real-life market position: absolute leader in market share, revenue, functionality. Of course to maintain that position they can’t just sit on their laurels and they know that. At a really productive meeting with the San Francisco team recently we discussed their development plans, most of which I cannot share for now. However, I am happy to share that in the not-so-distant future Confluence will offer a hosted version – something I’ve repeatedly asked for:-).

As for competitor Socialtext, they revamped the product a few months ago: while I was fairly critical of some of the functional misses, the single biggest improvement was the UI: they went from an outright ugly product to a pleasant-looking, clean, friendly one. In fact this, along with other players (JotSpot, Wetpaint, Zoho, Brainkeeper) has turned the table: formerly good-looking Confluence now feels a bit … well, 2005-ish (?) Still the best, but somewhat boring. They are keenly aware of this and improving the UI is one of Atlassian’s key priorities.

JotSpot is in hibernation in the meantime, although TechCrunch speculates it may open up soon. Zoho is a newcomer to the wiki space, but not one to underestimate: they may just leapfrog all other players when they tightly integrate their full Suite (Write, Show, Sheet, Create) thus creating a truly powerful read/write/collaborate platform online.

Last, but not least two smaller wiki-players from the list: Itensil combines workflow with a wiki (now, religious wiki-fans deny the need for any structure or workflow, which is probably OK for a small group, but workflow is the way large corporations work), and System One combines a wiki with relevant enterprise search.

Without further ado (wasn’t this enough?) here’s the poll, please cast your vote:

You can click “view results” after you cast your vote, then “Complete results” to se more stats on the Zoho Polls site. Once there, click the “Rating” header to sort the list in ranking order – right now, with 117 votes cast Confluence is #1 with an average of 3.54, closely followed by Brainkeeper’s 3.50.

post

Atlassian Founders Become Australian Entrepreneur of the Year

My first thought was deja vu… I myself reported on Mike and Scott winning the E&Y Young Entrepreneur of the Year Award a few months ago. Then it hit me; this is not the *young* category; Mike Cannon-Brookes and Scott Farquhar won the real thing, Ernst & Young’s Australian Entrepreneur of the Year Award.

Now, if you first win the *young* category, then a few months later the *adult* one (not *that* way… ) does it mean you grew up quickly and are no longer young?smile_tongue

Joke apart, congrat’s to Mike and Scott, in fact the entire Atlassian team. They’ve built a remarkable company… when I first met them in the spring, they had about 50 employees, now it’s 70+, serving 5,000 customers in 65 countries. Their first hit was Jira, an issue management system, the second product, Confluence became the market leading enterprise wiki. Of course there are a number of ways to measure leadership, one being a feature-by-feature comparison, but at the end of the day, customers vote with their dollars, and Atlassian outsells their competition lumped together (including pre-Google JotSpot, amongst others).

Here’s a short video from the award ceremony.

Successful millionaires or not (Atlassian is self-funded), these guys remain humble and likeable; just read Mike’s post here. Oh, as for the likeable part, they hosted the Enterprise Irregulars, a few analysts and their own competitors to dinner, and did NOT use the opportunity to pitch us smile_shades

All that said, I have to warn anyone thinking of joining them … they are a dangerous bunch. smile_wink


post

JotSpot Google Deal – Who Wins, Why it’s Big:First Thoughts

A few weeks ago the “wikirati” was having dinner with the Enterprise Irregulars in San Francisco, on occasion of the Office 2.0 Conference. Our gracious sponsor was Atlassian’s Mike Cannon-Brookes, and JotSpot’s Joe Kraus showed up, too. Missing from the photo is Socialtext’s Ross Mayfield, who was there for the first part, a briefing for Forrester‘s Charlene Li, but left before dinner. (Hm, did Joe eat Ross’s dinner?smile_tongue )

(photo credit: Dan Farber)

I heard a rumor that one of us in the group had likely gotten a few million dollars richer – and it wasn’t me smile_sad… but Joe Kraus, having sold Jot$pot to Google. The source was credible but of course we had already heard about a Yahoo acquisition, then eBay .. so who knows, after all.

I found the timing ironic, just having come back from a Google briefing where they announced Google Docs & Spreadsheets, which left me largely unimpressed. This is what they were missing, I thought.

Today we know it’s a fact: JotSpot is part of Google. After the quick post, here are my first thoughts around who wins, and what it may mean from a user prospective.

Who Wins:

  • Joe, Graham and team for obviou$ rea$ons.
  • Google, for now they have all the pieces for a small business collaboration suite, if they are smart enough to get rid of the junk and integrate the good pieces together – something they have not done before. I’ll talk about this more a few paragraphs below.
  • Some paying JotSpot customers: Jot has had a funny pricing model, where you can start free, but if you exceed a page limit (10?) you have to upgrade. Most users probably don’t realize that because in Jot everything is a page (i.e. add an event to the Calendar, it’s a new page), 10 pages are essentially nothing, if you wanted to do anything but testing, you’d have to upgrade – until now, that is. From now on paying customers will enjoy their current level of service for free.
  • Competitors: JotSpot’s market direction has never been entirely clear; they focused on consumers and small businesses, but were present on the enterprise market, too. I think it’s fair to assume that they are out of the enterprise market at least for a while, leaving only Atlassian and Socialtext as the two serious players.

Who Loses:

  • Some JotSpot customers who’d rather pay but have their data at a company whose business model is charging for services than enjoy free service by Google whose primary business model is to know everything about you. Clearly there will be some migration from JotSpot to other wiki platforms. Update: the competition isn’t sleeping, see migration offers by Socialtext and Atlassian.
  • Me, for having half-written a post about the merits of pure wikis, Office suites and hybrids, which I can scrap now.

Who Needs to Move:

  • Some of the Office 2.0 Suites, including my friends at Zoho. This may be a surprising conclusion, but bear with me for a while, it will all be clear.

So far the balance is good, we have more winners than loserssmile_regular – now let’s look at what Google should do with JotSpot.

They have (almost) all the right pieces/features fragmented in different products, some of them overlapping though. They should kill off the weak ones and integrate the best – a gargantuan task for Google that so far hasn’t pulled off anything similar. Here’s just some of what I mean:

Google Docs & Spreadsheets:
One of the reasons I found the announcement underwhelming was that there really wasn’t a lot of innovation: two apps (Writely and Google Spreadsheets) put together in a uniform look and a file management system. It’s this very file management system that I found weak: how on earth can I work online and manage a jungle of thousands of documents in a flat, alphabetical list? JotSpot may just be the right solution.

Google Groups:
It’s rare for a mature product to go back to beta, but when Google recently did it, it was for good reason: the Groups which so far has been just a group email mechanism, became a mini community/collaborative platform, offering functionality found in collaborative editors like Writely, Zoho Writers, page cross-linking a’la wikis, file management..etc, combining all this with group email and the ability to share with a predefined group. I seriously considered it a major step forward, likely attracting previously “email-only” users to the native web-interface – and we all know why Google loves that.

JotSpot, the “hybrid” wiki:
This will be the somewhat controversial part. First of all, JotSpot is an attractive, easy-to-use wiki, and I believe that’s the value Google should keep.

Second, they’ve been playing around with the concept of being an application platform, which just never took off. The “applications” available in JotSpot are all in-house developed, despite their expectations the world has not come to develop apps on their platform. (Will this change in Google’s hands?). In JotSpot 2.0 they integrated some of the previously existing applications into user-friendly page types: Calendar, Spreadsheet, Photo ..etc, along with regular (text) wiki pages. This is what I considered Jot’s weak part. Just because a page looks like an application, it does not mean it really is:

  • Try to import an Excel spreadsheet into a Jot Spreadsheet page, you’ll get a warning that it does not import formulas. Well, I’m sorry, but what else is there in a spreadsheet but formulas? The previous name, Tracker was fair: it’s a table where you track lists, but not a spreadsheet.
  • Look at a Calendar page: it does not have any functionality. You cannot do group schedules, can’t even differentiate between personal and group events. It’s just a table that looks like a Calendar – reminding me the “electronic” calendars of corporate executives in the 90’s: the Word template that your secretary maintained for you and printed daily…

I guess it’s clear that I am unhappy with Jot’s “application” functionality, but I like it as a wiki. In this respect I tend to agree with Socialtext’s Ross Mayfield, who believes in best-of-breed (whether that’s Socialtext is another question…). Best-of-breed of everything, be it a wiki or other productivity tools. I’ve also stated that my ‘dream setup’ for corporate collaboration: is a wiki with an integrated Office 2.0 Suite. Why?
Other than its collaborative features, a wiki is a map of our logical thinking process: the cross-linked pages provide structure and narrative to our documents, one could think of it as a textual / visual extension of a directory system, resolving the problem of the flat listing of online files that represent fragments of our knowledge. Of course I am not implying that a wiki is just a fancy directory system… au contraire, the wiki is the primary work and collaboration platform, from which users occasionally invoke point applications for number crunching, presentation..etc.

Now Google has it all: they should kill the crap, and combine the JotSpot wiki, their own Office apps ( a good opportunity to dump the lousy Docs & Spreadsheets name), Calendar, Gmail, the Group email from Google Groups and have the Rolls -Royce of small business collaboration.
(Update: Dan Farber over at ZDNet is pondering the same: Is JotSpot the new foundation for Google Office?)

By now it’s probably obvious what I meant by Zoho having to make their move soon: they either need to come up with their own wiki, or team up with a wiki company. Best-of-breed is a great concept and enterprise customers can pick and match their tools on their own. For the SMB market it makes sense to be able to offer a hosted,integrated Wiki/Office solution though. So far Zoho is ahead of Google in Office 2.0, if they want to maintain that leadership, they will need a wiki one way or another.

Of course I could be way off in my speculation and Google may just have bought the team.. either way, congratulations to Joe, Graham and the JotSpot team. thumbs_up

Related posts:

post

Wikis as Intranet + Extranet

I’ve written about how wikis can become *the* Intranet, that is not only easy to access but easy to edit by everyone, in the organization. Instead of a one-way communication channel for Management to talk (down) to employees, the wiki becomes a living, breathing, participatory communication platform.

Now there’s a new case study of how a a customer of Atlassian’s Confluence wiki is using it for customer communication, by building their entire Extranet on Confluence.

The wiki has become the Intranet+Extranet.

post

Socialtext 2.0: Usability vs. Usefulness

Socialtext recently announced version 2.0 of it’s enterprise wiki. The two big news are a completely revamped user interface, aiming to make Socialtext a lot easier to use, and the publication of the REST APIs to support integration and mashup development. For more information watch this screencast by CEO Ross Mayfield, and see this review at TechCrunch.

The revamped UI is a huge deal, and it’s been long overdue. For some background check out Jeff Nolan on the “UI sucks” issue. One may agree or disagree, but as long as there are reviews like this:

I have tried on at least four separate occasions to use and like Socialtext but I can’t…I just can’t use this application.” – well, you definitely know you have a problem.

Interestingly enough Socialtext, the company realizes how important ease of use is, and they are contributing resources to bringing WYSIWYG Wikiwyg editing to Wikipedia. But let’s focus on Socialtext, the product for now.

The new UI is aesthetically pleasing, has nice colors (somewhat reminds me of JotSpot’s blue), but most importantly it’s clean, simple, in short it passes the “blink test“.

thumbs_up The Home Page is of key importance in the new release: a Dashboard gives users a quick glance of a shared whiteboard, personal notepad, customizable watchlist, a listing of what’s new (i.e. recently changed pages) as well as the users active workspaces (i.e. wikis). The Home page has become the central place where you can access all extended features, like a listing of all pages, files, tags, or change settings. You can start adding information using the New Page button, which, just like the Edit and Comment buttons on all subsequent pages clearly stands out, again, passing the “blink test”. I love the new colored side-boxes for tags, inbound links and attachments.

I can’t emphasize enough how important inbound links (backlinks in the previous releases) are – a wiki is all about associating pieces of information with each other, and the inbound link shows you where the information on the current page is used elsewhere. In wiki systems without this feature on would manually have to create them, a task most often forgotten (as it does not fit the natural flow of creating new pages), thus those systems don’t offer the full potential of a wiki. I can’t for the life of me understand why inbound links haven’t yet made it into the standard feature-set in JotSpot 2.0, when it’s been long (for more than a year) available as a downloadable plugin on the Jot Development wiki – but how many users search the development wiki? In contrast, Atlassian’s Confluence has long supported incoming links.

We know from Ross and others that in creating the new design the primary objective was to increase ease of use, and in doing so Socialtext conducted customer usability studies. The number one customer request was to reduce clutter, which was quite abundant in Socialtext 1.x. They certainly achieved this objective – perhaps too much. Playing around with the beta I run into trouble trying to create a page from an already existing page – I simply did not find the New Page button. “This is something too obvious to be a bug”, I thought, and Ross proved me right: It’s all part of “getting rid of the clutter” and doing what customers had requested.

Socialtext believes this helps eliminate a frequent problem: the existence of orphan pages in wikis. (Orphan pages are valid, existing pages that no inbound hyperlinks point to; thus it’s difficult to find them, other than by searching or listing all pages).

I am not sure binding users to the Home page is a good idea (it’s not just the “new page”button, all other extended features/tools are anchored here). To me the natural flow is typically top-down: one would create a subpage from the parent where the summary level thought flows, thus creating a parent-child relationship. In a business wiki, where after a while you’ll end up having a large number of pages, the further away you are from the right place (the parent), the more likely you will forget to create a link to the new page, thus may end up with a proliferation of orphan pages.

Interestingly enough, the most elegant solution to the orphan problem comes from two products at the opposite end of the spectrum: Wetpaint, the friendliest consumer/community focused wiki (actually a blend of wiki-forum-blog features) and Atlassian’s Confluence, the market-leading enterprise wiki. Other than the standard user-created links within the flow of text, these products also offer an automatic index of subpages along with each page. JotSpot‘s 2.0 release offers a less foolproof but reasonable solution: when you create a page by using the “new page” button, technically it becomes an orphan, however when you hit “save”, you’ll find yourself at the parent level where a quick alert pops up proposing to create a link to the child page you just set up.

There’s a fool-proof way of creating new pages that can’t become orphans: create a link before the page, and forget the “new page” button. While typing, wherever you want to branch out to a new page, insert a link to the page about to be created, typically by highlighting text and using the “link” icon, or in JotSpot you have the option of simply typing a WikiWord (also referred to as CamelCase), it becomes a link automatically. This “trick” creates a shell, essentially a placeholder for your new page: you can add content later, but since it’s already linked to, it can’t become orphan. All the wikis I’ve talked about allow this method, but Wetpaint and Confluence don’t really need it, since they provide navigation based on the auto-index of child pages. (Update [2/17/07]: I’ve just discivered a perfect existing term for what I am trying to epxlain here: LinkAsYouThink.)

Back to Socialtext, perhaps there is more to the new design than the desire to create a very simple, clutter-free user experience: the underlying philosophical difference between hierarchical structures, parent-child data relationship vs. everything being flat (created at the home page ) and only associated through links embedded in page text. But hierarchy, structure are not necessarily evil; only pre-existing ones are.

smile_wink We tend to think in structures, need organizing principles – there is a reason why books have a table of contents. Wikis, as unstructured as they are in “virgin state” are a good tool to create structure – our own one. The assumption of a parent-child relationship mimics our usual workflow, and it does not impose a rigid structure, since through through cross-linking we can still have alternate structures, no matter where we create a page.

Perhaps that’s the fundamental difference between Socialtext and the other wikis I’ve mentioned – which would explain why it doesn’t have breadcrumbs (navigational line at the top): this standard feature of all the other three products (Confluence, Wetpaint, Jot) does not really fit in Socialtext’s flat world.

My other issue about with Socialtext 2.0: I really would have expected to see document versioning by now: when you upload an attachment (typically doc, ppt or xls file), Jot and Confluence shows the current version, indicating the most recent version number and the user who changed the document last. Click for details, and you get all previous versions and details. Confluence even allows you to label every instance of the attachment with a comment. Socialtext simply lists all documents with the same title (or not), not recognizing them as version of the same file.

smile_sad

Finally, a minor gripe: it would be nice to see threaded commenting, like Wetpaint and Confluence does, allowing users to enter comments to a page itself or to a previous comment. Socialtext, just like Jot, only has a flat list of comments.

Summing up, the new Socialtext 2.0 Beta is really good-looking, but in my view limits functionality for (perceived) ease of use. That said, it’s a beta, and Ross conformed repeatedly that they are seriously evaluating test user comments and it’s possible that the final 2.0 release will have a better solution for the edit/navigation/orphan problem.

fingerscrossed

Last, but not least, let’s revisit document versioning. It’s very-very important. In my “prior life” where as corporate VP I introduced a wiki-based intranet to the company, we used it for document management first, before exploring more of the native wiki functions. But here’s the catch: document versioning in wikis solves a very old problem, but solves it on the bases on yesterday’s (OK, today’s ) technology. Even with proper versioning one has to download documents, locally update them, then upload them back up to the wiki. The process is a lot easier using Office 2.0 applications, be it an editor, spreadsheet or presentation. There is no uploading/downloading, all updates happen online, if need be by multiple users at the same time, and instead of attaching them, one would simply link to, say a Zoho Sheet or Presentation from the wiki.

My ‘dream setup’ for corporate collaboration: a wiki with an integrated Office 2.0 Suite. The next step will be the wiki integration with ‘traditional’ , transactional enterprise systems – that’s a little further away (although … reading this, who knows?

smile_wink ) I hope to discuss many of these concepts with my readers next week in San Francisco, at the Office 2.0 Conference.

Update (9/5): For more insight read Socialtext 2 Design.

Update (11/1): Usability review on InfoSpaces.

post

Blogs and Wikis Are the New Web

Traditional web sites are so 20th Century – Blogs and Wikis bring them to life, and they are easier to set up. Perhaps not surprisingly, a Web 2.0-focused VC, Union Square Ventures was one of the first to replace their entire Web site with a blog – read the rationale of the switch. Corporate web sites soon followed suit, just look at Architel and Return Path as examples. Now, for some shameless self-promotion, my earlier tips on the subject: Blogs To Replace Personal Web sites.

In Wikis are the Instant Intranet I also talked about how companies can set up a living-breathing Intranet, one that people can actually use, not just passively read by deploying a wiki: ” in the large corporate environment a wiki can be a lively collaborative addition to the Intranet (see the wiki effect by Socialtext CEO Ross Mayfield), but for smaller, nimble, less hierarchical business a wiki is The Intranet.” (note: I am not just speculating on this: been there, done that in my prior life).

Now Sydney-based Customware raised the bar:

The entire web site (not only the Intranet, but the customer-facing web) is built on a wiki – Confluence by Atlassian. (hat tip: Mike Cannon-Brookes)

Update (9/28): The Atlassian Blog points to several other wiki-powered sites that look-and-feel like traditional websites.

Update (9/22): Just as soon as I posted this article, I saw this pic on Rod Boothby’s blog:

Itensil, short for “Information Utensils” builds “a self-service technology that we’re calling Team Wikiflow that captures collective intelligence and delivers it as reusable team processes.”

I have to admit I haven’t heard of Itensil – it will be exciting to meet them, as well as Atlassian, Socialtext, Zoho, ConnectBeam, EchoSign and many other companies in the collaboration space at the Office 2.0 Conference.

Update (4/12/07): Here’s a list of corporate websites powered by CustomerVision’s BizWiki.


­

post

Wired Wiki, Numbskulls and Collaboration in Business

The Wired Wiki experiment is over – the collective result of 25 ad-hoc “editors” is now published on Wired News: Veni, Vidi, Wiki

Was the experiment a success? I think the process itself was, but not necessarily the end result. After the LA Times Wikitorial fiasco the very fact that for a week civility reigned and no wiki-war broke out is a success, as both journalist Ryan Syngel and wiki-host Ross Mayfield confirm. But of course measuring success simply by the peaceful nature of the editing process means significantly lowering the bar… how about the result, the actual article? Ryan’s take:

Is it a better story than the one that would have emerged after a Wired News editor worked with it?
I think not.
The edits over the week lack some of the narrative flow that a Wired News piece usually contains. The transitions seem a bit choppy, there are too many mentions of companies, and too much dry explication of how wikis work.

In other words, it’s more an encyclopedia entry than an article, concludes Mathew Ingram: is has a lot of information (perhaps too much), but it lacks personality. Ironically, other than the different styles of the individuals editors, the desire for a successful experiment may have contributed to the outcome. After a few revisions you reach a point where the article can’t be improved by simply adding lines – some parts should be deleted, others my not feel correctly structured.

Personally I’ve been struggling with adding an idea on the organizational/human factor in a corporate environment, which logically would belong under the “Wiki while you work” heading, except that someone already started the thought under “When wikis fail”. Should I disturb what’s there, or stick my piece in the wrong place? I suppose most editors faced similar conflicts, and compromised in order to avoid starting a wiki-war – but that’s a compromise on the quality of the final article. (note: I ended up restructuring the two paragraphs).

Mike Cannon-Brookes hits the nail on the head pointing out the role of incentives:

I’d say simply that the interests of the parties are misaligned. Ryan wants the article to say something about the wiki world. Wiki vendors want a link from Wired.com. Certainly, wiki vendors want it to be an accurate piece – but they also want it to be an accurate piece with them in it. Amusingly, the recent changes page reads like a whose who of the wiki world.

This misalignment of incentives leads to bloated, long lists of links. The article trends towards becoming a directory of wiki vendors, not a piece of simple, insightful journalism.

Collaboration works best if there is a common purpose. Wikis shine when it’s not the discussion, individual comments that matter, but the synthesis of the collective wisdom.

Where else could the interest of all parties best aligned than in the workplace? As Jerry Bowles correctly points out, social media in a corporate environment is very different from social media in the public web. After the initial “grassroots movement”, if 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, is used by people of real identities and reputations, and most importantly shared objectives.

This is why Nick Carr is so wrong in Web 2.0’s numbskull factor. He supports Harvard Prof. Andrew McAfee‘s point of extrapolating the low contributor/reader ratio of Wikipedia into the corporate world and concluding that fractional participation will result in the failure of social tools. He goes a step further though:

“In fact, the quality of the product hinges not just, or even primarily, on the number of contributors. It also hinges on the talent of the contributors – or, more accurately, on the talent of every individual contributor. No matter how vast, a community of mediocrities will never be able to produce anything better than mediocre work. Indeed, I would argue that the talent of the contributors is in the end far more important to quality than is the number of contributors. Put 5,000 smart people to work on a wiki, and they’ll come up with something better than a wiki created by a million numbskulls.”

This is actually reasonably good logic, with one major flaw: it takes the Wikipedia example too far. A wiki in the Enterprise is not an encyclopedia; not even some esoteric Knowledge Management tool. In fact, even though wikis solve a Knowledge Management problem (lack of input and GIGO), they should not be considered KM tools at all at the workplace. Typical KM is concerned with the collection, organization and redistribution of knowledge after-the-fact, while the wiki becomes the primary platform to conduct everyday business tasks, and resolves the KM-problem as a by-product.

Update (6/15/08): Now we have pretty good terms to describe the above, instead of my lengthy explanation. See the discussion on In-the-Flow and Above-the-Flow wikis by Michael Idinopulos and Ross Mayfield.

I have news for Nick: not everyone can be in the top 20% of the corporate workforce – by definition *somebody* will have to belong to that *other* 80%. Are they all numbskulls? So be it.. that is your workforce, like it or not. With the elitist KM view Nick would actually be right:

“As earlier knowledge-management failures have shown, the elite often have the least incentive to get involved, and without them, the project’s doomed.”

True. Except 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.” A basic conclusion that even the numbskull-editors of the Wired article have recognized.

Update (9/7): I love Rod‘s cartoons: