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:

post

Lessons from the TechCrunch Wiki War

Mike Arrington’s TechCrunch Parties have become “THE EVENTS TO ATTEND” in the Valley – in fact not just in the Valley: last time around I remember participants driving up all the way from San Diego, and this time people will fly in just to be there. The last party as well as the next one this Friday both sold out within hours after the announcement, and a lot of readers felt frustrated:

  • Some felt that first-come-first-served is not fair enough with such a short notice (an hour or so)
  • Some publicly asked for special consideration to get in
  • Some proposed to pay for “tickets”
  • Just about everyone complained for the lockups in the registration wiki.

I don’t envy Mike in this situation. It’s his party, his house (well, at least for the previous events), it would be perfectly OK for him to have an invitation-only party. Yet he obviously wants to see new faces, so he opens it up to anyone, but then of course he can’t please all… This time around, for the seventh TechCrunch Party hosted by August Capital there was more than the usual rush: the registration wiki has become constantly locked up and Mike was forced to move RSVPs to comments on his blog, closing the wiki.

Mike received ample feedback on why the wiki was not the right platform to handle hundreds of almost simultaneous registrations, and several entrepreneurs seized the opportunity to announce new offerings. Central Desktop announced a free public event wiki, and since it’s a hybrid not-just-a-wiki solution, Founder and CEO Isaac Garcia claims they do not have lockup issues (they use a form with a database in the background). Zoho Creator would have been another elegant solution.

However, what almost no-one talks about is that this was not simply a technical glitch. Having been lucky enough (?) to wake up 4am the day the wiki opened I managed to register myself at exactly position #100 in the wiki, then observe the wiki-war that soon ensued. The major “sins” I witnessed were:

  • Individual users registering entire blocks (dozen or more) names
  • The same users sitting on the wiki (blocking), probably while coordinating with their buddies who else to sign up
  • Previously registered names getting deleted

One can perhaps justify registering others, although I don’t know where the reasonable limit is ( I only signed up myself), but deleting others is the absolute cardinal sin. Apparently fair play is a strange concept to some.

This raises another issue though: are these people not aware that wikis provide a perfect audit trail and what they did can easily become public? Or do they simply not care? Is getting in on the TechCrunch party worth being displayed on a virtual “hall of shame”?

This particular incident aside, I think the major learning here is the overall lack of awareness of a typical wiki’s capabilities and how to “behave” while using it. I know many who’d like the collaborative capabilities but are afraid of “chaos” and the potential lack of civility… in short a major ‘wiki war’ if they open up editing to anyone. Most wiki platforms offer technical controls to limit chaos: even consumer /community focused WetPaint introduced several security schemes in their latest updates, and enterprise wikis like Socialtext and Atlassian’s Confluence have for long had elaborate security schemes – heck, that’s why they are “enterprise”.

Just as important as the permissioning is the role of social- behavioral norms, which clearly are more common and more forceful in a corporate environment, where all wiki “contributors” work for the same company. “Ross Mayfield said that in four years of building wikis for corporations Socialtext has seen precisely 0 trolls and 0 instances of vandalism.” He also maintains a Best Practices wiki (hey, it’s the new skin!). Now, remember, it’s a wiki – you can contribute, not just read.

As for the TechCrunch Party, the guest list is currently at 738(!) and here’s a preview of who’s coming, courtesy of CustomCD.us. (who may have intended to keep this a surprise, but I found it anyway….)

Update (7/28/2007): Here’s another case of wiki “who done it”.

post

Atlassian Taking On the World

(Update: apologies for the dead video links, Youtube is apparently down, here’s their message: ”

We’re currently putting out some new features, sweeping out the cobwebs and zapping a few gremlins.“)

I’ve recently had a chance to meet Mike and Jonathan in Atlassian’s San Francisco offices, and frankly was blown away by their enthusiasm, the company’s growth, but most importantly by a demo of Confluence, the market-leading enterprise wiki.

Market-leading? Never heard of them, you may say …. Certainly they enjoy a lot less brand recognition than let’s say JotSpot or Socialtext, both of which enjoyed abundant PR from the moment they launched, largely thanks to Joe and Ross‘s star-power. (Hey Joe, you were my early inspiration to get started with blogging, time for YOU to post again!). Lacking the “instant brand”, Atlassian spent their money on product development instead of PR, and it has obviously paid off. Watch this video for background:

Less PR or not, they are not exactly unknown to customers, as Confluence’s corporate market share is more than the others put together. From what I understand Confluence’s sweet spot is larger organizations, where administration, sophisticated permissioning schemes (groups, pages, activities…etc.) scalability, performance are increasingly important. (Yes, permissioning kinda goes against the social, “we’re-all-contributors” nature of wikis, but it’s a fundamental corporate requirement). The largest implementations currently run up to 30k users, but Atlassian is working on a clustered release that will be scalable to hundreds of thousands of users. Pricing also reflects the focus on large corporations: while at the entry-level Confluence is typically more expensive, at the high end (large user-base) it costs less then either Socialtext or Jot.

Despite it’s impressive feature-set and favorable price Confluence is not an available choice for some customers; namely those who are determined to use SaaS solutions. Confluence is strictly on-premise, download and install-behind-the-firewall software. Being a big believer in SaaS of course I would like to see them offer a hosted version, but today’s market reality is that only 10% of all software sold is SaaS. Atlassian’s own customer experience is that a lot of larger organizations do want their wiki behind the firewall, and competitors must have been receiving similar feedback, as both Socialtext and JotSpot are adding an installable product to their offering. However, Confluence may be missing out on the bottom-up, grassroots adoption by business users that both Jot and Socialtext are enjoying – at least until it becomes available on-demand.

And while the Founders did not have the star-power of their competitors 4 years ago, they are getting closer, having just received the 2006 Ernst & Young Eastern Region Young Entrepreneur of the Year award.. Watch the video of the Awards Ceremony here:

Congrat’s, Mike and Scott!

 

post

WetPaint, the Wiki-less Wiki

Recently I wrote: “You Know Wikis Have Arrived When …. they become the feature post in your regular junk mail – this time from an Executive Recruiter firm:
What in the World is a “Wiki”? If you don’t know what a Wiki is, you probably should
.”

Well, maybe you shouldn’t. Let me rephrase the original statement: 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. This just became possible on Monday, with the launch of WetPaint, a hosted free service that combines the best of wikis, blogs, and forum software.

  • It’s like a wiki: you can create any number of pages, arrange them in a hierarchy, navigate through top-down in a tree fashion, or via direct links between pages. Anyone can edit any page a’la wiki (optionally pages can be locked, too). There is version control, audit track of changes and previous releases can be restored at a single click.
  • It’s like a discussion forum: you can have threaded/nested comments attached to each page
  • It’s like a blog: editable area in the middle, sidebars on both sides with tags and other info.

The launch created quite some interest: TechCrunch profiled Wetpaint, and several bloggers say it’s the best wiki platform ever. I respectfully disagree. There is no such thing as a “best wiki” – there are only “best” tools for specific purposes. Here are a few examples:

Confluence and Socialtext are both Enterprise Wiki’s , robust, well-supported, targeting corporate customers. Clearly not end-user products.
JotSpot is more geared towards smaller businesses and consumers and in fact it’s a mix of a wiki plus a few basic applications. I still had to watch the demo videos before getting started though.
Central Desktop is a “wiki without the wiki”, more of a full-featured collaboration platform with calendar, task, project ..etc features for small companies.

Yet I couldn’t have used any of the above platforms for setting up the Techdirt Greenhouse wiki, the online space supporting the recent successful “unconference”. Why? We needed the simplest possible site that’ so easy to use that anyone can get started without even a minute of training. WetPaint (in closed beta at the time) was simply the only choice:: easy-to-use, yet powerful, a platform that allows anyone to contribute to the website in minutes, without any training, or even reading help.

Forget wiki. WetPaint is a wiki-less wiki. It’s the most user-friendly self-publishing tool that allows anyone to create a site and transform it into an online community. Don’t take my word for it though: the proof is the 3000+ sites that were set up in the 3 days since the launch. That probably includes people who have not had a site before, and some who moved, like Mike:

I’m moving from the current Wiki (based on Mediawiki which runs the beloved yet always under fire Wikipedia) to a new Wiki doo-fangle called Wetpaint. Why? Coz it’s a gazzilion times easier to use and I like it.” Well said.

Here’s what Yule says: “I just started a wiki – my first ever… Blame WetPaint – couldn’t resist starting this up.”

Check out samples of WetPaint sites, then it’s your turn to create your own… I will soon be launching mine.

post

You Know Wikis Have Arrived When ….

You Know Wikis Have Arrived When …. they become the feature post in your regular junk mail – this time from an Executive Recruiter firm:

What in the World is a “Wiki”?

If you don’t know what a Wiki is, you probably should.
The term “Wiki” refers to both a collaborative site on the web or your company’s intranet/extranet and the software that runs the Wiki.

A wiki is a website designed for collaboration. Unlike a traditional website where pages can only be read, in a wiki everyone can edit, update and append pages with new information, all without knowing HTML, simply by using a MS Word type interface.

Wikis are the latest, greatest tool for group collaboration, project teams, document editing, etc. And, best of all, they are easy to use, affordable, and extremely flexible.

The easiest way to learn more is to click on the link at the end of this section of the newsletter and try it for yourself!

What can you do with a wiki?
Whether you’re at work or at home, you can access and use a wiki. The wiki allows free-form collaboration, but most wiki software providers and hosts also offer structured applications that allow you all kinds of very helpful functionality.

Here are some of the things that can be done (depending on whose software you use and what applications may be available:

  • Create an intranet
    Publish company information, such as news or employee guidelines
  • Project management
    Schedule project deadlines, assign tasks, and define product specifications
  • Document collaboration
    Multiple users author documents with aid of version history
  • Manage a group’s activities
    Utilize event calendars, discussion forums, blogs and other apps
  • Collaborate with virtual teams
    Communicate with remote contractors or clients
  • Track software bugs
    Log defects and build custom queries
  • Call center support
    Access case histories and increase customer support

A wiki can be hosted on your company servers or there are a number of hosted versions available. There are a number of suppliers, each touting advantages over their competitors, of course.

One important aspect of a wiki — it is highly cost- effective and versions/solutions range from those for the smallest teams on the most limited budgets scaling up to full enterprise versions.

If you are unfamiliar with this explosive growth phenomenon, you may want to take a look for yourself. [Company name] has found one supplier offering free trials. It’s pretty neat stuff and has become indispensable in our own operations. Click the link below for a free trial.

This is not a [Company name] product but we have used the free trial ourselves and had no problems, no hassles, and no sales calls. It just takes 30 seconds or so to sign up.


For spam, this is actually pretty good. The original letter pointed to the signup page of one particular provider, and of course the sender forgot to disclose the paid referral relationship … So instead of just one, here’s a list of a few wiki providers:

Confluence and Socialtext are both Enterprise Wiki’s , robust, well-supported, targeting corporate customers.
JotSpot is more geared towards smaller businesses and consumers and in fact it’s a mix of a wiki plus a few basic applications.
Central Desktop is a “wiki without the wiki”, more of a full-featured collaboration platform with calendar, task, project ..etc features.
WetPaint blurs the line between wiki, blog and discussion group, providing an amazingly easy to use interface, but it’s currently at beta stage.

The above list is by far not complete, it’s just a few of the top of my head – feel free to contribute in the comments section.

 

 

post

Web 2.0 in the Enterprise – Round …n.. (I can’t keep track)

Stowe Boyd picks up where Ben Metcalfe left off in Web 2.0 doesn’t work in the mothership, but… essentially recommending that Web 2.0 is best introduced in the Enterprise “in a satellite operation at arms length from the rest of your operation

While this is often the easy solution, I think a case can be made for the seamless mashup of process- and workflow-centric enterprise applications and the more creative, unstructured, collaborative tools like wikis.  Case in point is JotSpot’s integration with Salesforce.com based on the Appexhange. Granted their target is not the largest of enterprises, but another example I heard of at SAP’s annual conference is the SAP Help Desk wiki by  Socialtext targeting the entire SAP ecosystem.  In any case, I agree that spontaneous, project-focused use is how wikis will become adopted in the Enterprise, but at the same time I believe they should be a logical extension of any Enterprise system – SAP, Salesforce.com are starting to recognize, and I think the day when we’ll have both top-down (enterprise sale as part of the large package) and bottom-up (departmental initiative) penetration is not that far.

But then Stowe goes one step further, and this is where the trouble starts:

…the larger question — whether the enterprise would be more agile, more adaptive, and more of a survivor is it could somehow break away from the need for slow-to-change applications that span the needs of many departments, beholden to many but satisfying none — has not really been addressed by Ben or the others I am interviewing on the on ramp to CTC 2006….
My gut says yes. Enterprises would be better off if their IT departments could move to small, low cost, web-based apps that satisfy local needs — a project group, one campus in Denver, the marketing department in Japan — without having to subordinate local needs to corporate controls. The benefits of enterprise standardization are measured in the IT budget, but the true costs are distributed thoughout the enterprise: less collaboration in the research team leads to slower innovation, a less-thatn-intuitive UI for the sale staff in France leads to lowered sale numbers, and a heavyweight finance solution that slows down invoicing costs serious bank in collection time
.”

Oh, boy. When we’re talking about large multinational corporations, as Stowe does in his example, the primary benefit of standardization and integration is NOT measured in the IT budget. The key benefit is competitiveness, simply being able to conduct business.  Here’s a case study from my “previous life” when I was implementing SAP systems in exactly these types of companies: The Client, a major test and measurement equipment manufacturer had no real-time visibility of their available-to-promise inventory throughout their own plants accross the US and several countries in Asia and Europe.  It typically took them 3 weeks to be able to promise a delivery date to customers. Needless to stay they started to lose business. After the SAP implementation customers could receive the promised delivery date in real-time. For this company the implementation of the standard system was not an option, or driven by IT savings, it was the only way to stay in business.

As a matter of fact, prior to standardizing on SAP the individual plants operated exactly according to Stowe’s ideal model: each doing whatever they wanted, picking their own systems that simply did not talk to each other.

Web 2.0, collaboration is great, it has it’s place in the Enterprise, but so do those “ugly complex” transactional systems.  Don’t try to run your supply chain on a wiki

Update , more than three years later: Would You Manage CRM with a Wiki?

Tags: , , , , , , , , , , , , ,

post

Software 2006: Wikis Win

(Updated)
Wikis and blogs -social software in general – were the “latent” subject at Software 2006, popping up at several sessions throughout the conference.

In his opening keynote Ray Lane talked about the inter-personal enterprise: collaboration, increased participation through friendlier, better user experience; the user as an individual, “consumer” has to like the software, then will use it, and usage spreads within the company: a pull process, rather than push – the traditional enterprise sales model. This is exactly the model wikis are “sold”, as we discussed earlier. Ray specifically mentioned how useful they found using a wiki at Kleiner Perkins.

Then during the last panel, Toby Redshaw, CIO of Motorola talked about how he installed wikis and blogs: turned it on, decidedly not telling anyone “above” or laterally until it was too late for anyone worried about “control” to interfere. People discovered the new tools, started to use them, and before he knew there were 1900 blogs and 2000 wikis used in Motorola. Grassroots action at it’s best, just like Ray explained. Joe (JotSpot) and Ross (SocialText) could not have asked for a better plug of wikis, just minutes prior to their software showcase.

On the way from this session to the showcase room Ross was showing me his latest baby, Miki, the mobile wiki. One of the conference attendees (Director at a major organization) walked alongside us, overheard the conversation, and jumped in: “where can I get it?” Wow, I think Ross just closed a 30–second sale

There is something funny about these product names, though. Ross just found out that Miki in Irish slang means male genitalia… hm… close .. here’s the Urban Dictionary definition. Never mind, it didn’t hurt Jobby, won’t hurt Miki either. Incidentally, Miki in Hungarian is nickname form for Nicholas, and in Japanese a female name meaning “flower stalk.” Not bad.

The Miki launch was the last announcement of the day, then we headed off for some “Open Source” cocktails and appetizers.

Related posts – Miki seems to enjoy a warm welcome:

Update (4/8): It was fun to see JotSpot and SocialText together – would have been even more fun to see the third (and by the number of enterprise customers definitely not last) product: Confluence by Atlassian.

post

Wikis are the Instant Intranet

(Updated)

Since I received a few questions after my post: 43 Wiki Prank and the Whiteboard Test, I though I should add a bit of clarification. The underlying thought in that article was to pick the right tool for the right situation, and the whiteboard-test is just one trick to differentiate when Wiki’s are helpful vs. Forum, Blog ..etc software. It’s by far not the only situation when a wiki is invaluable.

Another example is setting up a living, breathing Intranet, one that people can actually use. Anybody who works in large corporations probably thinks of the IntraNet as a one-way communication channel for Management to talk (down) to employees. Getting your own content in? Forget it! Even when I was VP in a mid-sized organization and did not have wait for approval, I still had to talk to the IT Director, wait for him to fit it in his team’s schedule, then tell him what was wrong when my content finally showed up.

It does not have to be this way! Companies “own” (well, at least part of the day) the intellectual capacity of their employees, so why not put it to work? Even in the large corporate environment a wiki can be a lively collaborative addition to the Intranet (see the wiki effect by Ross), but for smaller, nimble, less hierarchical business a wiki is The Intranet.

At a much smaller organization I wanted to introduce a wiki for collaboration, for all the reasons explained in the video below. The company was a bit more old-fashioned, not exactly the early-adopter type. I expected some resistance against something with a geeky-funny name like wiki… so I simply announced we’ll be creating an editable Intranet. People started to use it from day 1, and few cared that the thingie behind is called a wiki.

David Terrar describes a somewhat similar story here.

Finally, the excellent video by JotSpot Founder Joe Kraus.

Other related posts:

Update (4/9): A really good guide to wikis by David Terrar.

Update (10/22): Here’s a case study of Confluence, the leading enterprise wiki being used as the ExtraNet.

Update (4/9/07): Read/WriteWeb on The Age of Instant Intranets.

Update (9/20/08)A Funny Thing Happened on the Way to the Intranet