Wiki In The Workplace

Welcome to a discussion on wikis in the workplace. We're trying to get a handle on this topic for a course we're taking at the University of Michigan's School of Information. Please take our survey (hosted at surveymonkey - requires javascript on) and post your thoughts below.

Many thanks from the CooperativeWorkWorkGroup.

WorldOfWikis

THE SURVEY RESULTS: (minus open-ended): http://www.surveymonkey.com/Report.asp?U=18425284569 is there any way to get this to launch in a new window?

Open-ended results are excluded here because it's not clear how to share those without sharing the id of anyone who left it for us to contact - and we don't want to violate anybody's trust there - if we figure out how to share more anonymously, we will.

(*discussion of the survey itself can be found at WikiInTheWorkplaceSurvey*)

THE DISCUSSION:

My comments on the survey expressed my displeasure in the deletion of my wiki by my sysadmin, with backups that were totally unautomated. The SizeProblem contributed to the apathy of writers who were too verbose. I hacked WardsCode? to do what I wanted, and lived within the size problem for years.-- ChrisGarrod

Pragmatic Utopianism?: Wiki is about trusting the competence of your fellow workgroup members -- Wiki is about trusting the collective competence (thus, one makes mistakes, another corrects them...) -- It's about trusting the essential good nature of others -- that is, trusting that most people *mean* to do the right thing most of the time (wiki isn't gullible -- intentional sabotage can be recovered from)- so, if the space is set up to allow and incentivize it, good things will follow... TomAllison

TwikiClone is most likely the wiki used the most. I, MichaelFinney, used to use Twiki in the workplace before the workplace closed its ColoradoSprings doors. It was a great tool to use. I hear administrating Twiki is a pain though. At the workplace, project documentation was more likely to be kept up-to-date than Microsoft documents. I bet that is due to its automatic notification of changed pages functionality as well as its versioning control. With the versioning control, you can see what has changed quickly and easily. See http://twiki.org/cgi-bin/rdiff/Sandbox/SandBox43?rev1=1.4&rev2=1.3 for a diff example.

If I were starting this project today, I think I'd focus on TWiki -- it seems to be a wiki specifically designed for supporting traditionally defined workgroups -- would I be correct in that conclusion? So far, (23 respondents) only(?) 50% are TWiki users...Granted its far from a random sample. -- TomAllison

An article on TWiki (it won an award): <http://www.unixreview.com/documents/s=1820/uni1011715271489/0201j.htm>

Hey! A Heuristic Evaluation of TWiki: <http://twiki.org/cgi-bin/view/Sandbox/SandBox07>

So, what, if anything, is the down-side to TWiki? Or, should anybody who wants to put a Wiki on their Intranet definitely choose that clone?

Logins and passwords will discourage some people from using it.
- Not an issue if authentication is done against the corporate accounts.
Installation is more complex than many other wikis (but is not too bad).
Lots of complex features, which is both good and bad.
Very infrequent releases. Patches can be difficult to keep track of and to apply. The development team is moving in a lot of different directions.
- Daily Alpha releases
- Production releases are once or twice a year and very stable, a must in a corporate environment.
Subwebs feature can be confusing.
- Subwebs solve the name space problem, a must in a large corporate deployment with hundreds or thousands of users
Default skin is considered ugly and complicated by many people.
- Most corporate users create a skin in their corporate standard.
By default, keeps all revisions of everything around forever. This may be discouraging to those who are afraid that their old writings may be used against them.
- A complete audit trail is required / nice to have
Page locking can get in the way.
- Content is not lost even if you break a page lock.
With all the templates, skins, plug-ins, and other customization features, a CompulsiveCustomizer can spend a lot of time generating and fixing big messes instead of being productive.
- Time well spent for one person to make hundreds of users more productive

In short, TWiki is one of the more powerful, adaptable, and complex WikiEngines available. If you need that power, then it's a good choice. If you don't, a simpler solution may give the administrator fewer headaches and may be more approachable for the users. The hardest thing about successfully using a wiki in the workplace is getting people to use it, and TWiki can intimidate people unless you customize it to suit them.

See also ChoosingaWiki.

I personally haven't figured out twiki wikis yet, they look confusing. I prefer UseMod.

From my perspective TWiki's biggest problem is the packaging. It's like buying a motorcycle in a box and having to assemble it before you can really use it. Sure you can drive it right away, but installing the seat, signal, brakelights, headlights, side mirrors, saddle bags, windscreen, etc. sure makes it a lot more pleasant to use! -- MattWilkie

Well worth putting a link on TWiki.org at (say) http://twiki.org/cgi-bin/view/Codev/WikiInTheWorkPlaceSurvey - will also link from http://twiki.org/cgi-bin/view/Codev/HowToGetInternalBuyInForTWiki which has discussion of getting adoption of TWiki in the workplace. -- RichardDonkin

I'm still trying to articulate what it is that wiki does well and what it doesn't --- It's difficult to tell whether its successes and failures are in the code or the culture of the groups in which it has succeeded and failed. Here's an opinion expressed by one of our survey respondents:

"[Wiki is o]nly really good at linear textual content. That's really the only thing. For details, read on, but basically TWiki is aimed at capturing linear text and not much else. That makes it very powerful *IF* your organization has a majority of that, but the rest is a problem. Not good at tables that are larger than "small", not good at all for graphics like diagrams, graphs, flowcharts, powerpoints, or even databases. Editing non-text attachments is cumbersome, and attachments aren't searchable from within TWiki either."

Is there a sweet point in terms of numbers of people on a workteam that works well with wiki? I realize that there are community wikis that seem to have an enormous number of contributors, but our work to date on wikis in the workplace seems to suggest that "relatively small" is much, much better -- large enough to take advantage of wikis distributed editorial workload, but small enough not to have the organization of the information give in to entropy. Best I can tell from several sources that number is less than 30 on a workteam. Does this seem right? I know our collecting of data has been skewed by several factors, and that "workgroup" may not be a firm enough concept to comment upon, but, all the same -- any thoughts in favor or against such a conclusion (that <30 workgoup size is best for success with wiki in a work setting)? Ha, what IS the LOWER bound of usefulness? I suppose it's more a lower bound of Buy-in or somesuch - if you are only 2 and you both use the Wiki heavily, then it's useful --- but how often is that the case?

Besides this page, other pages about, or touching on, the use of WikiInTheWorkplace include:

ProjectWiki and TeamWiki
WikiAsProgrammersNotebook
some of the WhyWikiWorksNot and WikiFailures discussion, since it points out weaknesses that might be considered fatal in an application that was relied on as a workplace tool (although of course that doesn't disqualify all wikis; it simply provides points of comparison for making an appropriate choice from among the many WikiWikiClones and WikiEngines)
some of the WhyDontOthersGetWiki discussion, talking about why a workplace wiki might be technically adequate (sufficient features, and no fatal flaws) but still fail to catch on
ProgrammingInWiki, which asks the question "Why shouldn't an IDE be wiki?"
likewise, parts of WikiWithProgrammableContent, relating to wiki as a code development environment
...and of course see http://c2.com/cgi/wikibase?WikiInHyperPerl for the original example of this idea, the original Wiki script itself, which can still be extracted by means of the form at http://c2.com/cgi/hp?WikiInHyperPerl
Scribble, which for some reason has the WikiName "ScRibble" (instead of, say, "ScribbleProgram") is "a Wiki-inspired attempt at a Web-based project dashboard/notebook." Sounds like a wiki that has been extended and customized to be a WikiInTheWorkplace.

As I search here and there, I find that this topic (ways of using WikiInTheWorkplace) has already been explored in many interesting ways in many pages on this wiki, but in separate discussions that proceeded independently of one another and haven't (yet) been tied together. I think this topic would benefit from some refactoring, but I have not yet thought it through sufficiently to do it in a way that would improve things. (I could rearrange the content to an organization that would seem more natural to me, but I'm not sure that would be an improvement.) So for now I'm satisfied just to link together pages on this topic, so that when they are refactored, it will at least be clear what content to include in the refactoring effort.

Perhaps this is an invitation to a WikiMaster to apply his/her wisdom...

Perhaps a WorkplaceWikiRoadmap? is what I'm creating. If so, I'll eventually move the list above to a page with that name. (The WorldOfWikis page seems to have started out with that purpose, but diverged.)