What’s the “Best” Wiki?

When I show people my introductory presentation on wikis often the first question I’m asked is. Well, then, what wiki should I get? What’s the “best” wiki?

In the Winter of 2008/9 there is no such thing as the “best” wiki or the “best” "collaborative software suite." Each platform offers different capabilities and appears to have different strengths.

What’s important is to match your organization’s requirements with a platform.

• You could think about what collaborative software capabilities are of most importance to you, and then figure out which platforms have them. I list the most obvious ones in the post before this one.

But there are lots of other things to consider as well, which ultimately may be more important.

• Beyond your tech requirements (which can include simple things like we want a platform that is installed on our server, or more specific issues like programming language, security features) there are dozens of features you’ll want to look at: things like what level of permissioning you need, notification functionality, document versioning, ease of use, quality and type of support, tagging capability, export capability—the list can be very long.

• Wikimatrix is a good place to start to narrow down options. You can perform a customized search on attributes critical to your organization. Just know that not all information on Wikimatrix is up-to-date or accurate—check out particulars on the vendors’ websites. (Potential inaccuracies create the hazard that a wiki might be the right one for you but not show up in your Wikimatrix customized search short list.)

And once you have narrowed your list, it’s important to know that there are key functionality gaps in every product, and they may not be immediately apparent when you just read about the platform.

For example:

• Search is important for every wiki. Test it and try to talk to users to see what they think of that product’s search functionality. Does it return useful results?

• If tables or spreadsheets are important to you, test out that platform’s tables/spreadsheets.

• With repeated use you are likely to find that none of the WYSIWIG editors act exactly as you would like; developers are still working on this. Play with some so you know what you are getting.

• You may also find that notification systems are lacking. Be sure to test these and any other functionality important to you.

The bottom line is before deciding on a platform: test it and try to talk to other users. Then pilot it before signing on the dotted line. (Migrating from one wiki to another, though doable, is often not a pretty picture.)

A Funny Thing Happened on the Way to the Wiki

With this blog, I have finally gotten around to publishing some thoughts about wikis.

And just as I have gotten around to it, the trend is for the wiki-as-wiki to bow out in deference to the "collaboration suite" (platforms that have wikis plus other collaborative or social capability).

The blank page of a wiki offers a lot of flexibility, but not always a lot of functionality and structure, or direction for the user.

So in the past year, as adoption of various forms of social software has accelerated, leading wiki platforms have added greater functionality.

Some vendors have added modules such as social networking or a Twitter-like micro-blogging ability. (In addition to adding social software capabilities some have made their wiki functionality stronger and deeper with a better editor, better user interface, more widgets, better extensions, or improved document management.)

Recently when I made a chart comparing eight (mostly) wiki-centric platforms I was able to compare them on these capabilities--because so many of them now had them.

• wiki
• blog
• discussion forums
• rich profile (profile which shows your "activity stream" i.e. contributions you have made)
• social networking
• document storage/search
• Twitter-like micro-blogging
• personal dashboard

Of the platforms I follow most closely, Traction TeamPage currently has all of the above capabilities except social networking, Jive Clearspace, all of the above except microblogging and Socialtext, in a re-designed website as of mid-December, touts all of the above, except forums. Atlassian’s Confluence comes out of the box with enterprise quality wiki and document functionality. I would guess a tech savvy user could build the rest in Confluence--except for microblogging and social networking--using plugins, macros and more. (See this very good webinar for tips on how a discussion forum was built in management and technology consulting firm Bearing Point’s wiki.)

It was in the last half of 2008 that Traction introduced micro-blogging, Socialtext, social networking and a personal dashboard, and Atlassian, the Office Connector which allows you to save Office documents directly into the wiki.

Wiki-centric platforms are evolving fast. Right now, as they add capablities, it looks like they are converging. I wonder, in this tumultuous climate, what we’ll be seeing at the end of 2009.

Collaborative Document Creation: Volunteer School Committee Drafts a 300 Page Report

I sent an email to my management school list serv asking for examples of wiki usage. One of the replies was from Sanjay Patel who worked on a committee in his local school district tasked with visioning "The School of the Future."

He was enthusiastic about how the wiki had worked for them. He laughingly characterized the group as "middle-aged not technically savvy people."

"The Visioning Committee tasked with writing a report on the School of the Future was made up of middle aged not technically-savvy people. We were a diverse group: teachers, administrators, parents, business and industry representatives, companies who hired locally. The tech coordinator for our school system suggested we use a wiki to log our research and pull together the multi-hundred page document we were to create. And it worked.

The wiki built on wikispaces allowed us to work on the report at a significantly faster rate than emailing back and forth. We also used the wiki to invite students in to read and contribute. We could post when we wanted, read, and respond to others."

They surprised themselves about how well and easily it worked:

"In one hour we were trained and we structured the wiki. Our school system's tech coordinator held an hour long training/workshop. There were 20 of us. We whiteboarded the structure and learned how to use the wiki. At the beginning, people were uncomfortable with editing other people's work. They would just write something underneath another person's writing. Then a couple of us decided, 'Let's get it done,' and started commenting in the text itself and editing. Others joined in. One of the things I liked best was that I could make an important contribution to the project without attending every meeting."

He explained they used the wiki for logging research and drafting the document, then used Word to finalize it.

"It evolved that people specialized on topics or sections of the document—researching an area and then drafting content. Two or three people would work on a section.

In the end, the tech coordinator, copied everything by section out of the wiki and edited and formatted it in Word to create the final deliverable report which we submitted to the School Board."

Some of the reasons it's likely that the wiki worked so well for them was that it fulfilled a real need--easing the process of collaborative document creation, and had at least one person, the school tech coordinator, who helped guide the wiki.

Email: Dispersed and Hidden

Copyright © 2008, Valdis Krebs

I love this image.

For me it says it all.

What’s the image of?

Here’s an edited version of what Valdis Krebs says about his image:

The social network map above shows the email flows amongst a large project team...Each person on the team is represented by a node. Each node is colored according to the person's department -- red, blue, or green. Yellow nodes are consultants...Grey nodes are not formal team members but are external experts...

...Only emails addressed to individuals were used...A grey link is drawn between two nodes if two persons sent email to each other at a weekly or higher frequency.

• It’s kind of astounding to think of all the information that is embodied here, but unavailable to the group as a whole.

• On the other hand, if all this information was available to the group i.e. the same information is in all these communications, there is tremendous inefficiency.

With email, ideas, plans, and information are hidden in dispersed inboxes.

With a wiki, information can be centralized, shared, contextualized in real time, allowing collaboration, and coordination. Knowledge can be retained, built upon, and is findable.

Note: This is only a picture of flows of emails addressed to individuals. “Reply all” emails are estimated to make up 30% of all emails in offices. When a wiki is introduced, wiki vendors, including Socialtext say that 30% of email migrates to the wiki, which is a much more useful place for them. 

Personal disclosure: I am a sucker for maps; I used to own and run a map business.

Peeking Inside a Wiki: Planning A Conference

For me it’s exciting to peek inside an organization’s wiki. It’s the best way to learn about how you can use one.

The Johnson Center (that’s the Dorothy A. Johnson Center for Philanthropy and Nonprofit Leadership at Grand Valley State University) used a wiki to plan their NP2020 conference. (NP2020 group pictured to the right.)

The screenshots below, for me, show—very simply—the power of centralizing information for lightweight project management.

Home Page-Orienting the User
Here's the wiki's home page with the wiki's purpose, a space to enter the conference goal, a link to last year's archive, and current announcements. (Click to enlarge the screenshots in a separate window.)

On the left is the navigation bar which has two main sections: Reference and Current Info. Current Info has dynamic information about such things as marketing and logistics.


Information—with context
Here's the page you arrive at when you click Meetings on the left navigation bar. There are action items at the top and then links to archived meeting notes.

After the meeting date, the meeting is described briefly. This is one of the exceedingly useful things about a wiki: information can be contextualized.

Broadcast email becomes the announcements archive


....retained, searchable and not cluttering your inbox.

A Table is Used for a Work Checklist
Here's the marketing checklist. Of course anyone working on the conference can add tasks, change due dates, and add the date completed. You don’t have to bother your colleague asking if that bit of the work was done—you just look here.




Centralized summaries
Finally, one of my favorite summary pages.

One liners: a record of all key decisions that have been made, centralized in real time. I was told that these were often referred to.





For the public, information about and a knowledge base of the conference
It all comes full circle. There is a public facing wiki for conference attendees. And as each session transpires, notes are entered by participants in the wiki, creating a record of the conference or knowledgebase.


Thanks to Brian Satterfield’s article on TechSoup for leading me to the Johnson Center.

Wiki Basics

The first presentation I did about wikis is here.

It’s a basic primer, and covers:

• What are the attributes of a wiki?
• How do wikis differ from other commonly used communication and collaboration tools?
• What kind of problems can a wiki solve? What are its uses?
• What are examples of these use cases? (with screenshots)
• How can you build a successful wiki?

The presentation is primarily images, not bullet points. A lot of the content is in what I said but the images still provide an introduction. The examples are nonprofits but most of the information applies equally well to for profits.

In the presentation, I incorporated a lot of ideas that Michael Idinopulos shares in his succinct, thoughtful blog, Transparent Office. Some of his most useful thoughts when you are starting your wiki are these:

Creating a Welcoming Wiki-On Structuring and Populating Your Wiki With Content

• Structure, populate, review, invite, and garden,
• How much predetermined structure for your collaboration space?
• How to populate your wiki
• Content in a wiki - Not more than one click away

Adoption

• In-the-flow wikis may be more readily adopted than above-the-flow wikis
• Redirecting work to your collaborative workspace
• Predicting wiki adoption
• A collaborative culture is not a precondition for wiki success

Wiki Uses

• 3 best practices on creating a participatory knowledgebase
• Enterprise 2.0 tools as your intranet
• Manage docs with a doc management system, collaborate with your collaboration suite
  

And finally...

Why you shouldn't worry about wiki vandalism

Why Wikis?

In the early nineties, after receiving a management degree, I worked at Procter & Gamble in brand management. P&G's vastness was unfamiliar: Before management school I had coordinated a very small nonprofit creating campaigns for activists to come together and influence government policy.

At P&G (the Shelton, Connecticut P&G, formerly Richardson Vicks), I was able to get things done by walking around and talking to people, pulling together conference calls, writing the classic P&G memo (e.g. top left corner: Mr. P. L. Wilson via Mr. H.J. Kangis Subject: ______) but, as a junior person, I had a very proscribed sphere of influence—three levels straight up vertically, and laterally to my brand team.

Having previously worked in under-resourced environments, I was wide-eyed at P&G’s resources, yet so much of what was available was underutilized.

Much of the under utilization could be attributable to the fact that there was no conceivable way—back in 1991—of many thousands of P&Gers exchanging information in a way that each of our brains might be able to process it. Nor was there a way to coordinate the work of all of us, or find that person, or piece of information, that could unlock whatever problem we sat trying to solve in our cubicle or with our brand colleagues. (Photo by Stewf)

For others, I suppose, who had not previously worked in small organizations, a large lumbering hierarchy with prescribed information flows may have seemed normal. For me, it provoked a question: How can you get the largest number of the right people the right information so together they can make the best decisions and accomplish the task of the organization most effectively?

I suppose the punch line is clear: three or four years ago when I read about wikis being used inside organizations, I was hooked.

Since then, I have been reading about wikis, exploring wiki platforms, talking to people who have implemented wikis, helping others implement wikis, and educating people about wiki use in organizations.

I’m fascinated with the idea of bringing lots of people and ideas together. I love the idea of helping create more collaborative organizations that are also efficient.

I’ve started this blog to share information and thoughts. I’m hoping that I can make it of interest to people who are new to collaborative software and also to those who work with it daily. My interests/proclivities swing from detailed and pragmatic to idealistic and theoretical. I hope what I write will be useful for others.