Hello there,
After reading quite a lot about WikiWikiWebs (mainly for a university paper), I'm convinced that our project team could greatly benefit from employing a wiki. I've already convinced the project manager that we should at least give it a try (mainly by stating how it won't cost a dime). Also, I've set up a local test environment (gotta love XAMPP), mainly for getting to know the MediaWiki engine.
However, predictably, many of my colleagues are quite skeptical - and to be honest, so am I to some extent. Now I hope to benefit from the experts' experience on this mailing list:
a) How can I motivate my colleagues to at least try it out - and hopefully realize that it might actually be a great help to them?
b) What's required in terms of basic structure? Certainly some help pages for explaining the wiki syntax (though I'll probably link to Wikipedia rather than create it from scratch), but I'm sure there are a couple of other things to increase acceptance and participation. Due to the large variety of projects people here are working on, it would be very hard to create a comprehensive basic structure right from the start. So I'll have to rely on the users/colleagues to create a kind of self-organizing wiki.
Any input on this issue would be greatly appreciated! (Hopefully you won't mind if I incorporate those suggestions into my paper as well.)
Thanks,
Frederik
On 24/11/06, Frederik Dohr FDG001@gmx.net wrote:
However, predictably, many of my colleagues are quite skeptical - and to be honest, so am I to some extent. Now I hope to benefit from the experts' experience on this mailing list: a) How can I motivate my colleagues to at least try it out - and hopefully realize that it might actually be a great help to them? b) What's required in terms of basic structure? Certainly some help pages for explaining the wiki syntax (though I'll probably link to Wikipedia rather than create it from scratch), but I'm sure there are a couple of other things to increase acceptance and participation.
The aim of a corporate wiki is, instead of "oh, Bob did that for two years, but he left last week ... I wonder how he did it", to be able to say "Bob did that for two years, he left how-to notes on the wiki."
How is your office culture? If you have a secretive office culture - where people guard knowledge through fear - a wiki won't fix that.
Due to the large variety of projects people here are working on, it would be very hard to create a comprehensive basic structure right from the start. So I'll have to rely on the users/colleagues to create a kind of self-organizing wiki.
Where I work has a *lot* of internal wikis. Mostly they work per group. I write up something on any process, procedure or in-house application I have to use a lot, as notes to *myself* and others.
You know how a lot of people start a new job by getting a notebook and writing everything in it? The wiki should be used for that. It's EVERYONE'S COLLECTIVE NOTEPAD.
The actual wiki software hardly matters. MediaWiki is very easy to use and install, but a bit heavyweight for a small team; it also doesn't even try to do access control. My work has various installations of MoinMoin, TWiki, MediaWiki, UseMod, Trac ... my group uses MoinMoin because it uses flat files rather than a database, and it's only used by ten people, so MediaWiki was a bit fat for the job.
Any input on this issue would be greatly appreciated! (Hopefully you won't mind if I incorporate those suggestions into my paper as well.)
If there isn't a wiki on how to use corporate wikis, you should start one ;-D
- d.
On the company I work for, we are in the process of centralizing all technical documentation of our software framework on the wiki, for use by several departments of the company.
The idea is catching on and other departments are exploring the idea of using the wiki to document their knowledge and also to publish documentation to customers.
These stories are helpful:
- Bootstrapping a Corporate Wikihttp://www.ldodds.com/blog/archives/000184.html - Embracing the Wiki Way: Deploying a Corporate Wikihttp://www.freepint.com/issues/270706.htm#tips - Wiki Case Study http://www.socialtext.com/node/85
Frederik Dohr schrieb:
Hello there,
After reading quite a lot about WikiWikiWebs (mainly for a university paper), I'm convinced that our project team could greatly benefit from employing a wiki. I've already convinced the project manager that we should at least give it a try (mainly by stating how it won't cost a dime). Also, I've set up a local test environment (gotta love XAMPP), mainly for getting to know the MediaWiki engine.
Well, that is a bit off track. Why should people spent their time on an experiment?
Rather: Use the wiki to solve a problem. If the employees share the problem, they have an interest in solving it.
Advertise that use with presentations.
For us, it is the documentation on our IT-System (SAP) with huge amounts of self devoloped coding. It is rather difficult to retrieve information on projects more than two years ago.
b) What's required in terms of basic structure? Certainly some help pages for explaining the wiki syntax (though I'll probably link to Wikipedia rather than create it from scratch), but I'm sure there are a couple of other things to increase acceptance and participation. Due to the large variety of projects people here are working on, it would be very hard to create a comprehensive basic structure right from the start. So I'll have to rely on the users/colleagues to create a kind of self-organizing wiki.
no. you need to give some direction in the beginning. And you need to have some kind of means to force people to use the wiki.
We startet with a simple template for the interfaces to and from our system. It is fairly easy to fill a template article, so the knowledge on how to use the wiki can be very little. Small steps in the beginning.
Then a couple people should find it interesting or rewarding to work in a wiki. Encourage that and help them solve their problems. people talk with another.
Teach the use and the possibilities of the wiki. Half a day is short but a good starter.
Make the wiki mandatory for certain types of information. Mostly it is limited time of the workers, to put down that information. have someone help them with it.
regards, Gunter
On 24/11/06, Gunter News2006@freenet.de wrote:
Well, that is a bit off track. Why should people spent their time on an experiment? Rather: Use the wiki to solve a problem. If the employees share the problem, they have an interest in solving it.
Yep! Things we use it for:
* Meeting agendas * Lists of ongoing issues for said meetings * Change requests - the canonical CR is a particular version from the history, but those working on a complicated CR can edit it as they go documenting what actually happened, which is very useful for the next similar CR * Local jargon file
The big use we put ours to was training new starters very quickly. A local jargon file was a particularly good use.
Also: one place I worked, I got them to do a radical thing ... make a documentation tree - folders on a shared drive, vendor and program, with a text file of notes on installation and maintenance issues. I would have suggested a wiki, but a mere doc tree was a head-exploding revelation for them ... a wiki is a natural for that sort of thing.
- d.
Thanks a lot for all your responses and links for further reading!
The problem is that in my current position (technically I'm just an intern), I have no way of handing out motivators of any kind - let alone making use mandatory. Even getting everyone to just enter their name and position (to make them take a look at the wiki) is quite a challenge... And the project leader wouldn't be willing to take any such steps before he sees that the wiki is actually working - kind of a catch-22...
I will get the chance to make a (very brief) presentation though. Obviously I'll have to make a good case for the wiki there (not one of my best qualities) in order to get people to at least consider using it. So as of now, I'm hoping for a "cascade effect" where a few eager colleagues will pick it up, and then others might follow. (I will of course be present to answer whatever questions might arise.)
As for a WYSIWYG interface, I'd agree that while this might erase the intial obstacle, its (current?) limitations would likely lead to frustration further down the line. I'd consider WYSIWYG if advanced users could just turn it off, but it seems that all available solutions/extensions change the way contents are saved, creating an either/or situation. (This might also lead to complications when trying to export contents from the wiki for use in some other medium!?)
Thanks again for you kind and truly helpful contributions!
-- Frederik
Good luck. It seems that the best way to start a wiki is by putting some useful content in it, even if it is just a few pages. If people use it and like it, chances are that the wiki will grow.
2006/11/27, Frederik Dohr fdg001@gmx.net:
Thanks a lot for all your responses and links for further reading!
The problem is that in my current position (technically I'm just an intern), I have no way of handing out motivators of any kind - let alone making use mandatory. Even getting everyone to just enter their name and position (to make them take a look at the wiki) is quite a challenge... And the project leader wouldn't be willing to take any such steps before he sees that the wiki is actually working - kind of a catch-22...
I will get the chance to make a (very brief) presentation though. Obviously I'll have to make a good case for the wiki there (not one of my best qualities) in order to get people to at least consider using it. So as of now, I'm hoping for a "cascade effect" where a few eager colleagues will pick it up, and then others might follow. (I will of course be present to answer whatever questions might arise.)
As for a WYSIWYG interface, I'd agree that while this might erase the intial obstacle, its (current?) limitations would likely lead to frustration further down the line. I'd consider WYSIWYG if advanced users could just turn it off, but it seems that all available solutions/extensions change the way contents are saved, creating an either/or situation. (This might also lead to complications when trying to export contents from the wiki for use in some other medium!?)
Thanks again for you kind and truly helpful contributions!
-- Frederik _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Our group got wikis started in a big way at Intuit, Inc.
a) How can I motivate my colleagues to at least try it out - and hopefully realize that it might actually be a great help to them?
Wikis need a champion - and that's YOU right now. Start using the wiki for yourself, documenting projects, figuring out article structure and classification. I would highly recommend getting a decent search system on it - if you have a Google appliance in-house, use it with one of the extensions documented on the Meta site.
When people ask you for info, point them to the wiki article about it. If there's no wiki article about it, create one and THEN point them to it. I've actually had people email me about something on the wiki that needs to change. I just email them back and tell them "It's a wiki, dude. Change it yourself."
b) What's required in terms of basic structure?
That's a tough one. Different wikis require different structure. Best to create a basic structure that you think works and let it evolve. Don't be afraid to create multiple "landing" pages and see which one works best.
We have to constantly warn people about choosing between one of Intuit's three "self-help" management, documentation and collaboration tools: Wikis, Blogs and QuickBase.
Here's a blurb from our documentation about choosing a collaboration platform (from a wiki, of course): -------------------------------------------------------------- A wiki is a great tool, but it isn't the right tool in every situation.
Do you need/want active collaboration? * If the answer is no, a wiki isn't for you.
Are you creating information that will be used/referred to over a span of time? * If the answer is no, you probably don't need a wiki.
Are you primarily looking to have a conversation or build an information repository? * Wikis have a built-in mechanism to support comments (the Talk page) but if you place more importance on the conversation than on the documents sparking the conversation, a wiki probably isn't the best fit for your project. Consider a forum or a blog.
Is process central to your project? * Wikis are generally process-less, which means they aren't the best way to manage a process. If you care about tracking status and issuing alerts, consider Quickbase. --------------------------------------------------------------
- MHart
b) What's required in terms of basic structure?
That's a tough one.
That is what I see is the problem. Where I work small groups set up a wiki and learn to use the wiki as a group with few problems since the wiki admin is typically in the group. But when an enterprise-wide wiki is set up many come to it and have trouble determining first of all that it is a wiki and they can add content, then have trouble determining how to create a page, then how to place it within the wiki's structure. We use categories in one of our enterprise wikis and a Main Page that is nothing but instructions. I've concluded that designing a wiki is as much if not more complicated than designing a web page. But like a web page it needs to stand on its own and users will rely the Main Page to guide them.
The best way I've found for designing a useful wiki is to look at other wikis. Wikipedia is an awful example I think. But its so famous that people who want to add content are motivated to learn it. That is not the case in most offices. But there are many other wikis to look at and get ideas from. One of my favorites is www.cookbookwiki.com. They state at the top of the Main Page that it is a web page that you can edit. On the sidebar they have a "Resources" menu with links to setting up an account and creating content. If you follow the "Create Content" link there are instructions on what to do to create content, including searching existing content first so you don't duplicate. Its handholding but I think that is what needs to be designed into the wiki pages to guide the helpless new wiki users along and make adding content easier. Otherwise you will end up with a small number of contributors to your wiki and their content scattered randomly in the wiki, lots of orphan pages with duplicate content, and I have one of our earlier wikis to prove it.
So, in short, use other well designed wikis you find as guides and before releasing your wiki, have some novices try to use it. This user testing should show where problems are and where improvements can be made.
-Jim
I've concluded that designing a wiki is as much if not more complicated than designing a web page.
I'm afraid I'll have to agree there; I've realized that my initial hope that the wiki will be self-organizing from the start was actually quite naive....
The best way I've found for designing a useful wiki is to look at other wikis. Wikipedia is an awful example I think. But its so famous that people who want to add content are motivated to learn it. That is not the case in most offices. But there are many other wikis to look at and get ideas from. One of my favorites is www.cookbookwiki.com.
I agree, Wikipedia really isn't the best example in terms of structure. I realized this when trying to pull some content from their help section for use in our wiki - that almost made my head spin! (Disclaimer: I love Wikipedia and couldn't live without it.) So I'll definitely take a good look at cookbookwiki.com - thanks for the tip!
-- Frederik
On 11/28/06, Frederik Dohr fdg001@gmx.net wrote:
I've concluded that designing a wiki is as much if not more complicated than designing a web page.
I'm afraid I'll have to agree there; I've realized that my initial hope that the wiki will be self-organizing from the start was actually quite naive....
Organizing a Wiki is a job for one or more persons who are enthousiastic about wiki and know something about the content and will actually once in a while go through the wiki to bring the order and organization to things. Once users see the new organization (and if it is one that works) they will bring in new documents to that structure.
In so far Wikipedia actually *is* a good example. But I agree that there are now so many organizational elements in the wikipedia that I can't find the one I need anymore. But that may be a side effect of having a 'general interest' wiki instead of a special interest wiki.
mediawiki-l@lists.wikimedia.org