Hacker News Reader

Where I work, I've noticed several trends:

- Duplicate work; as long as the wiki doesn't replace existing processes, placing things there is simply additional work. Moreover, because it's additional, there's no guarantee that any desired piece of information will exist in the wiki.

- People don't like not having an "owner" to a document, especially regarding private edits and such.

- Wiki's make you search for a topic (i.e. they require work), whereas email threads are pushed to you by others motivated enough to CC. Unfortunately, my motivation in tracking an issue will never be the same as the person directly affected by the issue.

- Mostly, however, wiki's don't provide a substantial functionality improvement to what I'm now going to dub the "enterprise wiki": i.e., Word documents on a shared drive. Here, Windows provides structure (well, technically Solaris does, but it's accessed by the user via Windows Explorer), while Word provides the standard document editing interface (although we do work with many document types).

The main drawbacks are terrible search, manual (and content limited) revision control, and an inability to track updates.

The main upsides are a rich editing environment for documents (compare Word to a textarea), support for any document format (don't like doc files? Use something else), and the opportunity for private collaboration & edits without implementing temporary ACLs (i.e., copy a file to the local drive, and email back and forth until publishable).

Personally, I think wiki's are great for collaboration between a heterogeneous, dispersed population. However, at the large corporation where I work, Word + Explorer is a ironic example of the worse-is-better Unix approach (many tools, barely working together) clearly beating the wiki/web-based Monolithic design.

This is very insightful.

Wikis are for text that people want to read and change, regardless of its source. This makes them ideal for Wikipedia but inherently out of tune with the big-corporate environment, a large crowd in which people prioritize based on who is talking to them. A boilerplate memo from the generic HR-department address can be skimmed very quickly; an email from HR addressed solely to you might need to be read; an email from the HR rep who has been assigned to your team might need a more careful reading and perhaps an acknowledgement; even a boilerplate email from HR might need careful attention if the author is someone you befriended at the company Christmas party.

You don't want an automated alert every time your boss's assistant reorders the columns on the weekly report. Ideally, your boss will only call your attention to the report when it is important for you to read it. That's part of the boss's job -- to protect your attention so that you can spend your time being useful instead of rooting through irrelevant wiki documents! And how is the boss going to direct your attention? Email. And while she's sending email, what's wrong with just pasting the information itself right into the message and saving the recipient some additional clicking?

Put all that stuff on the wiki and file off the TOs and FROMs and datestamps and you might as well just label it BOILERPLATE, because nobody's going to have the time to sort through it all. Even a genius super-librarian can only help so much, because the social context of email (its timing; the number and identity of the CCs, the history embedded in all the quoted emails that extend far down the page, etc.) is hard for a librarian to capture, let alone convey in wiki form. And, no, the version history does not help much. (Deriving people's motivations by reading their diffs is a techie art, not a liberal art. And emails carry a semi-reliable record of who has read the message as well as who has helped to write it.)

(A minor note: You left out Powerpoint in your description of the "enterprise wiki". It's pretty important, and for more than just stupid effects-laden bullet points. I worked in an engineering firm. All of us were capable of understanding wikis. I never tried to set up a wiki, though, because people communicated in charts and graphs, and at the time I couldn't find a wiki whose chart-and-graph workflow was anything short of "excruciating". The state of the art was to mail out arguments that consisted of stacks of graphs with commentary, rendered as Powerpoint docs.)

Make sure that some things can only be done in the wiki, forcing people to do it. Don't put people's e-mails in the wiki, force them to do so themself.

I second this point. Essentially, you don't want to be in the position of doing for your users what they "should" be doing themselves. While it sounds like you are there to support your users, you can support your users better with a bit of cooperation. From my experience with non-techies and wikis, I don't think it's a problem of not getting it so much as a problem of making it easier to learn how to use the wiki than continue not using it.

I agree that you should force them into making the change. You won't make the most friends doing it, but it'll be less of a hassle.

You need to take the 'facebook approach.'

A lot of people HATED the new facebook design when it originally launched. I'm sure you remember, there were groups with millions of members saying "bring back the old facebook" and complaining about everything.

Months later everything has calmed down, for the most part people like it and the change needed to happen. Facebook needed to make the change to implement new features, design elements, etc.

They'll be mad at first but eventually get over.

They needed the change so that they could kill the insufferable profile-widget apps.

History looks backwards, but decisions have to be made looking forwards.

How do you distinguish the case where you do something unpopular, refuse to change it to conform to your users' wishes, and are wrong?

It's a gamble you have to take. Facebook has enough users and enough people depend on the platform that they can make a change (not too drastic) and not many, if any people will leave.

I'd also add that if a new user sees inaccurate/out-of-date information they are very unlikely to ever trust the reliability of the wiki again. Something we're trying is asking those sympathetic to our wiki cause spot-check the wiki periodically to catch and fix glaring mistakes.

(I know, I know the idea of a wiki is a collaborative one, but you must take baby steps, especially in a large organization.)

I agree with forcing people to use the wiki. At my school, the email system was getting overwhelmed with mass emails from students selling stuff, looking for rides, trying to find items. There was already a site created by a student to sell things, look for rides, and post lost items, but nobody used it. Now they have just cut off access to mass email for nearly everyone, and the adoption of the site has gone up somewhat. So I would suggest that you first start with managers, trying to get them to only accept some things from the wiki, and consider cutting off some mass email access if it is being used for things that you want to move to the wiki. You will upset some people, but you will get them using the wiki.