Ask HN: Why do non-techies simply not "get" the idea of a wiki?
36 comments
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.
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.
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.
- 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.)
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 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.
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?
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 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.
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.
>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.
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.
+1 for Confluence
Yes, it's not free (or Free) and is made by a pretty established company, but it's a solid product, Wiki enough that if you want to get into it, there is a lot fo customization and detail that you can do, but at he same time friendly enough that if you don't care, you can just use the WYSIWYG editor to make your point. It also integrates nicely with JIRA, although I doubt that's used by much of the HN crowd.
As for getting people to use it, my team made a rule that if you sent us a question that (in our opinion) belonged in the wiki, we'd answer it there and send you back a link. After a few weeks of doing that, people just stopped asking and went there first.
Yes, it's not free (or Free) and is made by a pretty established company, but it's a solid product, Wiki enough that if you want to get into it, there is a lot fo customization and detail that you can do, but at he same time friendly enough that if you don't care, you can just use the WYSIWYG editor to make your point. It also integrates nicely with JIRA, although I doubt that's used by much of the HN crowd.
As for getting people to use it, my team made a rule that if you sent us a question that (in our opinion) belonged in the wiki, we'd answer it there and send you back a link. After a few weeks of doing that, people just stopped asking and went there first.
Not all wikis are that way. I regularly share stuff with non-techies via Jottit. e.g. http://jottit.com/n3yhk
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.
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.
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.
- 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.
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...
Agreed. Wiki syntax is a turn off.
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.
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.
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.
Socialtext! Hahaha.
There was a time once, when I was paid to work on Socialtext... but I'll spare you.
Let's just say that Socialtext is not the usability professional's answer of choice to MediaWiki.
There was a time once, when I was paid to work on Socialtext... but I'll spare you.
Let's just say that Socialtext is not the usability professional's answer of choice to MediaWiki.
I am fairly familiar with the backend (lots of bitter Socialtext friends), and hate to recommend it for that reason, but the UI seems nicer than MediaWiki.
Also, I like to shill Perl whenever possible. :)
Also, I like to shill Perl whenever possible. :)
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).
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?
Have you trained the non-techies in using the markup language?
the fckeditor plugin handles this problem, we use it at our business and people seem to like it.
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.
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.
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]]
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]]
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.
You'll be getting them to use vi to enter expenses claims next.
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.
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.
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.
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.
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.
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.
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.
"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.
Is probably what goes through the non-techie's mind.
Use terminology they are familiar with; "the online notice whiteboard" or something.
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.
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.
Nudge 'em to explore, and then go to the next step by telling them they can edit all and everything, and add new pages.
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.
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.
Wikis are like commenting code. They both require you to write some stuff down now in case someone else needs it in the future.
Think of how long it took you to learn the value of good commenting... That's about how long it will take to teach people why they should document their business practices on a wiki.
Think of how long it took you to learn the value of good commenting... That's about how long it will take to teach people why they should document their business practices on a wiki.
From what I've seen, most people really dislike the formatting the most. Plenty of people get the 'track changes' feature in Word, but when you edit a wiki you have to use a markup language. Simple or not, any kind of symbolic representation for text is patently foreign to most non-techies.
We just gave up on this. We serve professional photographers, who tend to be above average in terms of techie-ness.
We implemented PB Wiki for our support pages. No one updated it.
We spelled it out in big letters on the wiki home page. No one updated it.
We even had a contest. Every time you add to a wiki page, you're entered to win a prize. No one updated it.
Not only did no one update it, it confused customers. Customers confused the "login" link at the top of the wiki with the login area of their CMS. That simply resulted in more support tickets.
So, this year we simply moved our support pages to WordPress and only our staff can update them.
Since it appears your wiki is internal, maybe you have a better chance, but it would take some serious staff development in my opinion.
We implemented PB Wiki for our support pages. No one updated it.
We spelled it out in big letters on the wiki home page. No one updated it.
We even had a contest. Every time you add to a wiki page, you're entered to win a prize. No one updated it.
Not only did no one update it, it confused customers. Customers confused the "login" link at the top of the wiki with the login area of their CMS. That simply resulted in more support tickets.
So, this year we simply moved our support pages to WordPress and only our staff can update them.
Since it appears your wiki is internal, maybe you have a better chance, but it would take some serious staff development in my opinion.
I see the opposite problem - Customers want "wikis" and "blogs", but don't really know what they are, or don't fully understand the implications (e.g. "on our corporate wiki anyone can write anything they want? what if they write something bad!?").
In my experience, wikis are all doomed to becoming out of date and not a trusted information source, because the really important information ends up being in peoples' heads, or in code, or something like that. The wiki can only give you A) a 10,000-foot view of a system, or B) the details of that system as it existed.... two or three years ago.
Honestly, this doesn't really have anything to do with the original post, because it's happened in techie-only or techie-dominated companies I've been in. Anyone else had this experience?
Honestly, this doesn't really have anything to do with the original post, because it's happened in techie-only or techie-dominated companies I've been in. Anyone else had this experience?
This sort of thing can really slow an entire company down.
Work on getting it mentioned in performance reviews. If 'non-techies' start to have their bosses poking around asking questions about "so why do I keep hearing that you refuse to use the wiki?", that'll help.
I mean, really. A wiki is about as technical as a whiteboard... they're just being lazy. No one's asking them to make beautifully formatted pages, just get the stuff in there because _that's how we track it_... it's part of their job. They need to realize it.
Work on getting it mentioned in performance reviews. If 'non-techies' start to have their bosses poking around asking questions about "so why do I keep hearing that you refuse to use the wiki?", that'll help.
I mean, really. A wiki is about as technical as a whiteboard... they're just being lazy. No one's asking them to make beautifully formatted pages, just get the stuff in there because _that's how we track it_... it's part of their job. They need to realize it.
Technology is there to serve us and NOT vice versa.
If people are only comfortable with emails, well, techies should think of a way to scan and update the wiki with info in the email automatically.
If people are only comfortable with emails, well, techies should think of a way to scan and update the wiki with info in the email automatically.
I think the overall question is what problem is the wiki a solution too, and is it the best solution?
What information is the non-IT user really having to disseminate to others? What value is it truly providing? How have you made adding the information to a wiki not be additional work? Is it improving productivity or reducing it?
And finally, who has ownership of the project? If you do not have a non-IT owner it'll 'gather dust' if the value of the application is not easily perceived.
What information is the non-IT user really having to disseminate to others? What value is it truly providing? How have you made adding the information to a wiki not be additional work? Is it improving productivity or reducing it?
And finally, who has ownership of the project? If you do not have a non-IT owner it'll 'gather dust' if the value of the application is not easily perceived.
Have various things that are (1) essential, and (2) can only be done on the wiki.
For example: well them they can't go on holiday unless they book their holiday days into the wiki.
Also, overtime. Do people at your work get paid overtime? If so, make the system so that they don't get paid it unless they put their overtime hours on the wiki.
For example: well them they can't go on holiday unless they book their holiday days into the wiki.
Also, overtime. Do people at your work get paid overtime? If so, make the system so that they don't get paid it unless they put their overtime hours on the wiki.
It is all about momentum. From their perspective the email system still works. Sure there is this "wick-ee" thing, but they don't care because it seems like they don't have to use it. Go and checkout the book "Diffusion of innovation". It explains all about this.
"A wiki is an electronic whiteboard. Anyone can erase, add information, or redraw stuff. But try to be nice and respect the stuff that's come before; only add stuff that needs to be added."
[deleted]
Maybe you should be talking to your users more.
WYSIWYG
Period.
Period.
Your title is invalid. Non-techies get Wikipedia.
Additionally, your real question does not belong on Hacker News. You're dealing with the problem of how to accomodate the uselessness of mediocre people whom you're obligated to tolerate. The numbing pain of tolerating mediocrity has no place on a startup site.
Additionally, your real question does not belong on Hacker News. You're dealing with the problem of how to accomodate the uselessness of mediocre people whom you're obligated to tolerate. The numbing pain of tolerating mediocrity has no place on a startup site.
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?