post

JotSpot Born Again as Google Sites, the Wiki-less Wiki.

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 could provide for much better document management than the current Docs &­ Spreadsheets UI.
  • 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 3smile_tongue)

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

Summary: Nice to have Jot back (even if we did not get GSpot.smile_embaressed ) 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.

Related posts: TechCrunch, eWeek, Ross Mayfield’s Weblog, Irregular Enterprise, Mashable!, InfoWorld, Between the Lines, Portals and KM, CNet, Webware, GigaOM, Web Worker Daily, Venture Chronicles, Insider Chatter, Learning and Technology, Solo Technology.

post

Email is Still Not Dead

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…smile_wink 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 verbatim reprint of an older one from 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. smile_tongue)

Related posts: mathewingram.com/work, Techdirt, Fractals of Change, Don Dodge, WebProNews, Thomas Hawk’s Digital …, Andrew Hyde and This is going to be BIG., Rev2.org, CrunchGear, A VC , Good Morning Silicon Valley, Socialtext Enterprise … , Between the Lines, Publishing 2.0, Jonathan Nolen

Technorati : , , , , , ,

post

Beating Social Media’s 90:9:1 Rule in the Enterprise

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

My earlier posts on this subject:

(hat tip: Stewart Mader)

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

JotSpot…Gspot … Google Wiki

So they figured Gspot would be too risky a name for Google’s JotSpotTongue out, it’s now (almost) official: the new name will be Google Wiki.

JotSpot was (I assume still is) a good, user-friendly wiki, and if it comes back now, it took Google almost an entire year to release it after the acquisition. I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

  • It could provide for much better document management than the current Docs &­ Spreadsheets UI.
  • 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.

In fact there are so many opportunities to waive the wiki into Google’s current offerings, I can’t even imagine what it would look like… or, perhaps, are we going to see a standalone wiki? Thinking

Related posts: Google Operating System, Google Blogoscoped, Read/WriteWeb, TechCrunch, Download Squad , Mashable!, Insider Chatter, Ben Barren, Squash, Parislemon.

post

Flow vs. Structure: Escaping From the Document & Directory Jungle

I do not think/work/create like a machine.

My thoughts flow freely and I tend to discover relationships between events (hence “Connecting the Dots” above in the Blog Header), so I like linking things – at least mentally. Why would I confine myself to the rigid directory & file structure that computers have forced on us for decades? There are better ways… let’s look at some.

A while ago Atlassian CEO Mike Cannon-Brookes wrote and excellent piece on how Enterprise Wikis Replace Shared Drives. Shared drives as collective document depositories are a disaster, we typically can’t determine where, to put things, and certainly don’t know where to find them. And if we do find a document, how do we know whether we have the latest version? How do we know who changed what in the dozen other copies with similar but cryptic filenames spread around the shared drive?

Wouldn’t it be easier to use the equivalent of a directory structure with meaningful names, the ability to attach longer narratives to our documents and find them easily via search and tags? That’s essentially what you get when you use an enterprise wiki as your “shared drive”. Think of not documents/files only, but the very reason they exist: in business we typically work on a few “projects” at any one time. If we create wikis / wiki pages for each project / function, the page content becomes the “narrative” that describes what we do, why and how, and further supporting details are in the document attachments. There really is no reason to bury documents (doc, xls, ppt) in some central dumping place (document depository) anymore – they belong to the wiki page (project description) where by definition they are in context. Of course they can be used in several other places, in different context, which is where linking comes handy – linking to wiki pages as well as other content (documents, web sites, etc).

Now that we established the wiki as the “glue” to tie all our documents together, let’s take a step further. As we get comfortable with the wiki, we’ll often wonder when to create a separate document and when to use native wiki pages. If your wiki supports a rich word processor, textual content can easily move in the wiki pages themselves. (Interestingly, Blogtronix, the Enterprise 2.0 platform vendor uses the “document” metaphor for what others call a wiki-page.) Of course whether we call them pages or documents, they should still be easy to share with “outsiders”, by using workspace or page-level permissions, or exporting to PDF and other file formats should you need to “detach” content and email it.
This works well for text, while for other needs we shoot out to the point applications and attach the resulting files (ppt, xls… etc.)

However, like I stated before, I do see the irony of working in an online collaboration platform (the wiki) yet having to upload/download attachments. Atlassian’s Webdav plugin for Confluence is an elegant solution (edit offline, save directly to the wiki), but for most other wikis the process involves far too many steps. Why not directly edit all these documents online? This of course takes us to the old debate whether the wiki should become the new office, or just the “integrator” holding the many pieces together. As a user, I don’t see why I should care: I just want seamless workflow between my wiki, spreadsheet, presentation manager, project management tool …etc. Such integration is easier when all applications/documents are online, and there are excellent applications from Zoho, ThinkFree, Editgrid, Google, to do just that.

Working directly on the Web is not just a matter of convenience. Zoho’s Raju Vegesna points to mobility, sharing & collaboration, presence & communication, auto-Versioning, auto-save, access & edit history as native benefits of web-documents.

As we link web documents to each other, and smoothly transition between applications, a paradigm shift occurs: the definition of what we call a “document” expands. Offline, a document equals a file, defined by application constraints. Spreadsheets, presentations need to be saved in their own specific format, and they become “black boxes”: there’s not much we know about them, other than a short title. There is an overhead in opening every one of them, they need to be virus-checked, then “stitched” together to support the “flow-thinking” I was referring to earlier.
Those boundaries are stretched on the web: a document is no longer a file of a specific type, generated by a specific application: it’s a logical unit, defined by context, which weaves together content created by several applications.

Zoho’s Notebook is an experimental application that allows us to create, merge and store information the way we think, no matter whether it involves writing text, drawing charts, shapes, crunching numbers or recording/playing videos. Experimental in the sense that we don’t know how it will be used. In fact I don’t know what the future web worker productivity / collaboration tools will look like, but I suspect they will have elements of Notebook – multi-format, multi-media – and wikis – user-created structure, everything linked to everything – merged together.

Files, formats become irrelevant: there is only one format, and it’s the Web, defined by URL’s.

Additional reading:

Update (11/13/07): Read I Hate Files on Collaboration Loop. (via Stewart Mader)

post

Atlassian: Is There a Message Behind the New Homepage?

Atlassian, makers of Confluence, the market-leading Enterprise Wiki has a new homepage. So what? – you may ask. Well, as they say, a picture is worth a thousand words, and this case is no exception. Two pointers (not that you need any):

  • Atlassian is a four-product company, and the old site reflected that.
  • Their original hit was Jira, later Confluence, as a downloadable product. They were somewhat late with a hosted version – but they delivered what the market wanted, and their numbers speak for themselves.

Times change. One would have to be blind not to see they are getting a new religion: (old page to the right, new one below)

Update: One would either have to be blind, or just look at the site at another time… as it turns out (see Mike’s comment below), the big banner is a rotating one… so much for going to SaaS Church together smile_embaressed Oh, well, if you want to find out more about Atlassian, you can attend their user conference in Boston on Palo Alto.

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.