Ask HN: Why do non-techies simply not "get" the idea of a wiki?

[RiderOfGiraffes]

We here at work have been trying to reduce paperwork while simultaneously increasing knowledge dissemination. For some time the techies have been using a wiki, and others are starting to get the point that when they ask a question the first response is "Have you checked on the wiki?" The answer until recently has always been "no", and the question now is answered about half the time by doing what they should have done in the first place.

It's like "Let me Google that for you"

So we've moved the holiday booking system to the wiki. Now people can say when they're away on site, working from home, sick, or on leave. The leave days can be booked in advance and then confirmed by their line manager. At a glance we can see who is in, out, available or away, and the system is really helping our planning. Suddenly everyone knows when someone is on site and might need support, or on leave and unable to help. The non-techies have themselves said, when shown it, that it's really useful.

But the non-techies just don't "get it." They won't update the wiki, they still don't look at the wiki, they never add information to the wiki. Instead, they insist on sending things by email. Then in a few weeks time people are asking, and we have to trawl through email systems to find the information.

Except we (the techies) don't, because when we get information we put it on the wiki. Then when the non-techies ask us anything we can say "Have you checked the wiki?"

And they still don't get it.

Where is the mis-match? How can we make a wiki as accessible/understandable as a Word document?

How can we help the non-techies attain enlightenment?

Can the non-techies attain enlightenment?

[mixmax]

This sounds like a classical techies/non-techies problem. The techies are trying to implement something, in this case a wiki, that is an unknown concept to everyone else. And since the techies "get it" they expect everyone else to get it too.

The thing is that to the rest of the organisation there are probably the following problems:

- they don't know what a wiki is, and they don't much care. Even though they use wikipedia they don't necessarily grasp the concept behind it: They just see a single entry, happily oblivious to how it got there.

- they don't want to learn what a wiki is, unless it directly helps them in the short term.

- They have ingrained ways of doing things. Changing people's behaviour is like changing direction of a supertanker: It takes a lot of time and effort.

The solution is to keep pushing it, paying attention to the following:

- Make it worth people's while in the short term. Reading your post it sounds like you may already be well on the way here.

- Make it easy. Usability should be top-notch, and there should be help available everywhere. If it's as simple as a mac it will be much easier to turn people around.

- 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.

[chandler]

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.

[cgranade]

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.

[mikeyur]

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.

[dwwatk01]

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.)

[chris11]

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.

[geuis]

The problem isn't the idea of the wiki. It's the implementation. Any non-techie gets how to write a blog post in Wordpress. Spacing, make things bold, etc. I've been editing with various wiki software for years and I still find it cumbersome. If you can have a system that is a wiki under the hood but has a normal-person level interface, you would see more usage. Regular folks have better things to do than learn our odd syntaxes for doing things. It's not something that saves them time because instead of being easy and automatic, they have to break their trains of thought to do this "wiki" thing. It's no different than when your coding in the zone and your manager interrupts you about something marketing wants.

[wallflower]

>The problem isn't the idea of the wiki. It's the implementation.

We use Atlassian's Confluence. Confluence is a nice collaboration tool built on wiki concepts. Us techies used a wiki prior but Atlassian's almost-a-wiki-but-not-as-scary-as-one is now so popular that it is a major issue when Confluence is down. It is pretty much company-wide now and updated almost every minute.

[bayareaguy]

Not all wikis are that way. I regularly share stuff with non-techies via Jottit. e.g. http://jottit.com/n3yhk

[ahoyhere]

Agreed 100%.

The idea of user-editable content isn't the problem. But wikis are an unknown quantity and a slippery concept for non-nerds to grasp. There are no affordances, no guidance, no structures to help orient people[1], and while wiki syntax is awful that's only a contributing problem.

It's like if a carpenter/handyman/car repair guy handed you a smooth, featureless egg-shaped object and said "This is a Ziki. You can do everything with this tool. Now, check my tire pressure."

Even if you knew how to check tire pressure in general, you'd be SOL.

Second issue is that people use wikis for things other than collaborative documentation, just like people use blogs for project management (just because they're easy to install), and that's not helping the adoption problem.

[1] I don't mean the document tree, either. People are used to structured content.

[iamdave]

Stop calling it a Wiki. Call it a knowledge base and watch activity boom.

It works.

[dotcoma]

agree. it's full of people who ain't "wiki" enough, ya know...

(in their brains, I mean)

[artlogic]

I have seen a great deal of wiki-phobia, even among so called techies. No matter how many wikis I deploy, this inevitably occurs. Here's my take on the problem:

- Wikis require a heroic effort to keep organized. Most people, when faced with creating a new category, or even a new page would rather send an e-mail and forget it. The fact that you have to not only post something, but also decide where it belongs makes the job of posting feel much harder. "You mean I have to categorize my content before I post?"

- Wikis require more cognitive effort on the part of the poster. With e-mail or a message board, you can essentially dump your brain and hit send. With a wiki, you have to integrate your post, not only into the organization, as I mentioned above, but also into an existing post(s). "You mean I have to read and understand other content before I post?"

- Most wiki markup is based on the ideas behind the semantic web and should remain readable and understandable even in markup mode - unfortunately, people don't like to cede control of the way their document looks. I have seen non-techies spend hours jumping through HTML/WYSIWYG hoops simply to achieve a particular look - not realizing the nightmare of editing such a page (think word generated HTML pasted into the page). "You mean I have to sacrifice my format before I post?"

- Finally most wiki software doesn't have a easy to use e-mail notification system. Many times you have to manually "watch" a page instead of just watching the whole wiki or a whole category. When you do get an update e-mail - you have to actually go to the wiki - no hitting reply - this again interrupts cognitive flow for a lot of folks. "You mean I have to keep track of all the changes myself?"

I love wikis, and certainly think that they can increase productivity - but they require a greater cognitive effort on the part of the poster, and a lot of folks are unable to make the short term sacrifices to achieve the long term gain a wiki can offer.

[vivekkhurana]

What you are facing is a standard problem in adaptation of technology. What most techies think usable might not be that much usable by non-techie user. As far as wiki is concerned, I find it challenging to use a wiki even being a techie. The obnoxious syntax of wiki is sufficient to scare away several users. As you mentioned, people like to send email, I would suggest creating a separate mailbox for leave applications and then writing bunch of scripts to parse the email and put the email in wiki, db or whatever you want to. Second option is to use a CMS and create web form, as most CMS have support for forms and reporting built in. I have done this with drupal couple of times and the solution has been received well by non-techies. In the end, what ever comments you receive on this thread will turn out to be useless if you are not willing to understand the reason why non-techies are not using the wiki ? Few minutes spent with the end user will save you several hours of developing and deploying a solution that will not be used by non-technies...

[sam_in_nyc]

Agreed. Wiki syntax is a turn off.

[sam_in_nyc]

Because editing wikis is an excruciating experience. Just look at the edit page... it's a textarea with strange icons above it, and the most fucked up formatting you've ever seen.

I'm technically inclined but I shutter at the idea of having to write anything in a Wiki, because the syntax is so unintuitive and annoying. I seem to recall adding line breaks, and it NOT showing line breaks on the preview. It was one of the use user experiences I've ever had: some fucktard decided that hitting "enter" wasn't enough to add a "<br>" to the content, so I have to go and dig through documentation to find out how to do it. Pisses me off thinking about it.

[jrockway]

Sure, if you use MediaWiki that's true. As far as I know, nobody uses that for internal corporate wikis; that is what wikis like Socialtext are for.

[gaius]

A lot of management types don't really grok that an email can be written by a machine, let alone that a web page can be generated as opposed to written by hand. I am certain half the automated reports I send out, many of the recipients think I am drawing the graphs and tables in Excel, cutting and pasting them into Outlook and sending them (ermm, at midnight every night).

[Tichy]

To edit a wiki usually requires understanding a markup language. Maybe some people simply go to a blank state of mind whenever they see markup.

Have you trained the non-techies in using the markup language?

[figured]

the fckeditor plugin handles this problem, we use it at our business and people seem to like it.

[matt1]

I'm in a very similar situation.

We use Microsoft's Enterprise Information Management at my work. It was rolled out about a year ago and is now primarily used as a replacement for storing files. I started playing around with it and discovered, to my delight, that there's a built-in wiki feature.

There's a huge place for it in our daily operations. It could save thousands of hours in the long run if we got only a few people to contribute. The problem is that second part: How do you get people to contribute?

Here's my strategy:

1. Privately create lots of stubs beforehand along with an intelligent structure for linking them together. Also add tons of how-to articles (because for non-technies, obvious isn't so obvious)

2. Add pages that show how people could actually benefit from it

3. Brief our management, stressing the benefits, and ask for them to push it within their organizations

4. If all goes well, people will slowly start adding information. If even 5% of the employees contribute, it will quickly reach a tipping point and then explode in popularity.

5. I'll continue to add and edit articles on a daily basis for the next few months regardless of the initial reaction

6. Gradually make it the go-to point for certain types of information, forcing people to use it and see how useful it can be

I'm at step #2 right now. I'll have the opportunity to brief the management in about three weeks.

Also, I'm going to call it a "collaborative notebook" as that encompasses how people can benefit from it much more than calling it a wiki or knowledge base.

The thing I've found is that even just telling people what I'm doing in basic terms is unclear. They hear "wiki" and go "wiki wiki wiki" and then nod their heads when I'm explaining things to them.

What I've realized is that its not their fault if they don't understand what you're doing. Its your fault for not explaining it to them in a way that makes it clear.

We'll see what happens... wish me luck.

[brusqe]

I was heavily involved with a university project of designing and building an open wheel racecar. We tried to do the exact same thing, that is, reduce our paperwork while increase knowledge dissemination (as well as knowledge retention and accountability for work).

At first we implemented a wiki. The techie guys on the team saw the long-term value of it and filled it in dutifully, however, many people simply didn't "get" the idea. The wiki ended up stagnating, as only a handful of people used it. The non-techie guys would inevitably ask about what was currently happening, of which the answer was already posted on the wiki. People just never warmed to it. Knowledge management and communication should not be a struggle, or else it will fall by the way side.

The solution was to step away from a wiki system (MediaWiki) and towards something else (Basecamp). Basecamp fitted in with how everyone used the net. Message threads that were relevant to people were sent to their inbox, they could reply to from their own mail account. Milestones are clear - tasks are clear. It's just usable and seamless.

A wiki has a perceived barrier of entry. It's a lot to take on at once for a non-techie. Using the systems which are currently in place, (eg email, a homepage/dashboard setup) to disseminate info will go a long way, rather than fighting an uphill battle of getting people to understand #REDIRECT [[pagename]]

[Angostura]

Why on earth are you trying to use a Wiki as a calendaring app whn there are so many good calendaring apps out there. I'm fairly techie - but if someone told me to edit a Wiki to put my holidays in, I would not be amused.

You'll be getting them to use vi to enter expenses claims next.

[KWD]

I agree here. A Wiki does not seem to be a good base for a 'holiday booking' tool. Of course, personally, I've always been a fan of Lotus Notes for being able to adapt applications like this to the normal workflow of an office.

[mattmaroon]

I think the problem is that you're assuming something is wrong with the non-techies rather than that something is wrong with the wiki.

[ntoshev]

It's not a techie/non-techie distinction, it is about level of exposure to wikis and similar things that people have. Ten years ago techies didn't get wikis either.

[jodrellblank]

In our case the answer was to move from a technically good wiki with lots of features to a Microsoft solution (Sharepoint) severely lacking in features but looking prettier.

[tokenadult]

People from a certain generation (or people in your generation who studied certain subjects in school) were told that working collaboratively in school is "cheating," and so in the workplace they don't distinguish situations where working collaboratively is supporting the team. I suspect the main problem is cultural and would show up however you try to get your colleagues to collaborate.

[niels_olson]

I use a wiki to take notes. I run navyhpsp.net, which is a wiki for Navy Health Professions Scholarship students distributed all over the US and recently overtook the official Navy HPSP site on Google (google for "Navy HPSP") I also set up a wiki for my med school (at the Dean's request).

I don't understand why there would be universal appeal to a corporate wiki, not unless it's searchable by google, in which case you at least have a chance of the information coming up when you go looking for "boilerplate" information in a search engine.

People inevitably choose different ways of doing things. If a group of you is using a wiki, then run with it. Don't force people to use it. If it's better, they'll get curious and ask about it. If not, don't worry about them. Every time you ask people to play with your toys, you are spending political capital. Conserve your capital. If you make them play with your toys, you can bet they'll cry and call for mom and dad, at best. At worst, they might try to break your toys.

[zepolen]

"What the fuck is a Wiki?"

Is probably what goes through the non-techie's mind.

Use terminology they are familiar with; "the online notice whiteboard" or something.

[c1sc0]

Cognitive load: it takes effort to learn a new way of doing things, especially if the 'old way' is deeply ingrained in the organization. You'll be amazed at the lengths people will go in order not to have to memorize things. If the perceived efficiency gain is not immediately clear people will not learn something new.

[slater]

Try and get them in to a "gotcha" moment: The next time they ask some question already answered on the wiki, point them to it, instead of giving them the answer (unless it's critical that they need the answer RIGHT NOW).

Nudge 'em to explore, and then go to the next step by telling them they can edit all and everything, and add new pages.

[skmurphy]

It's an interesting thread. Historically organizations faced these same challenges getting people to consult a website and use E-mail, both of which are now viewed as the default. The problems you are facing do not come from the fact that non-techies are stupid. And learning how to solve them is good practice for working with normal prospects (vs. early adopters).

One specific suggestion: pick one thing that will reliably be in the wiki and get people used to checking it just for that. Then branch out. Two good places to start: meeting agenda page becomes meeting minutes that any attendee can modify; internal or product specifications that would benefit from a wiki's ability to branch to background and related pages.

I don't think it's a technology barrier at all (unless you are forcing them to use Wiki markup instead of a WYSIWYG editor) it's force of habit.