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.

Comments

  1. Raju Vegesna says

    Having been there for 4 years, I’d expect these features to be already present in SocialText. Interesting that these basic features came in just now.

    Raju

  2. Thanks for the review.

    The backlinks feature has been present for about a year, it was hidden in the sidebar. So was the breadcrumbs feature, which is even more hidden now, but will come back soon. We were pretty aggressive at pruning for Socialtext 2, and there are a few things we’re planning to add back after first ship, like making the breadcrumbs more visible again.

    On new page, there are more ideas, not yet in the product, for making it easy to make new pages that aren’t orphans.

    On hierarchy, we see it differently. Grafting traditional hierarchy on a wiki gives you the worst of both worlds. You get the inflexibility of the paper file cabinet, where a file on home insurance needs to be be put either in “insurance/home” or “home/insurance”. Plus, because it’s a wiki, the hierarchical structure isn’t enforced. You don’t have the dictatorial department admin keeping the hierarchy pure. There need to be more ways to create and visualize and create site organization, but adding file cabinet hierarchy isn’t it.

  3. Zoli Erdos says

    Adina, thanks for commenting here.

    We actually agree on a number of items.

    Backlinks: The point I wanted to make is that they are critical, and kudos for Socialtext and Confluence for supporting it for quite some time. I revised the text (just below the pic) to reflect this better.

    Breadcrumbs: I liked them, if they come back, it will be a welcome move. Are they just “hidden” and I can bring them back myself now?

    Orphan/new page: it will be great to see enhancements:-)

    Hierarchy: I guess I was right suspecting a philosophical difference… but I still don’t see an inflexible, either/or file cabinet type decision. I am simply talking about assuming a default parent / child relationship, which “does not impose a rigid structure, since through through cross-linking we can still have alternate structures, no matter where we create a page.”

  4. Zoho Adds Wiki to Online Suite – It’s All Coming Together

    It’s nice to get your dream fulfilled fast.  Writing about Socialtext 2.0 in October I wrote:  “My ‘dream setup’ for corporate collaboration: a wiki with an integrated Office 2.0 Suite.” A little later in my post on the JotSpot/Google de…

  5. 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 beh…

  6. Hi, do you know how is the Wikiwyg project doing? I don’t see much activity there. Is the ball still running?

    I have been working on a commercial wiki project with a friend, and we developed a little visual editor based on WYMeditor. We are releasing it as open-source and I think we had some good ideas on how to make it play nice with the traditional Wikipedia editing.

    It’s released on http://www.mediawiki.org/wiki/Extension:MeanEditor
    Do you know if others could be interested in it?

    Nice blog, BTW 😉

Trackbacks

  1. […] had in the past been quite critical of Socialtext’s wiki component, and am looking forward to revisit it, as part of our wiki-series […]

  2. […] had in the past been quite critical of Socialtext’s wiki component, and am looking forward to revisit it, as part of our […]

  3. […] I came to the Conclusion that Confluence was the most robust, complete one.  I’m probably not the most pleasant reviewer when I don’t like what I see – but I could simply not find anything to criticize with […]

  4. […] wikis, I came to the Conclusion that Confluence was the most robust, complete one.  I’m probably not the most pleasant reviewer when I don’t like what I see – but I could simply not find anything to criticize with […]

%d bloggers like this: