Jump to content

Wisdom in wiki production/Introducing a wiki for use

From Wikibooks, open books for an open world

This section explains what matters should be paid attention to when introducing a wiki for use and even before such introduction. The point of view in this section is that of the whole organisation while the section Starting to use wikis adopts the point of view of individual persons' experimentation with wikis and the first steps involved. The introduction process is naturally more demanding in an organisation than when initiated by individual users, because there are more users and, in addition to management commitment, the support of the whole staff is required. It is not rare to encounter change resistance.

The key element is not the choice of the wiki platform as such but the careful consideration of several issues: the organisation's processes, the purpose of the use of the wiki, and the objectives to be reached through its use; the platform selection will take place on the basis of these considerations.

Phases of a wiki introduction process

[edit | edit source]

Below, we will list phases of a wiki introduction process at the organisational level. In many cases, less might suffice and all phases need not be implemented. The key phases in the order of implementation include the following:

  1. tentative requirement specification: what is expected of the wiki; in which environment will it be used and for which purposes
  2. collection of wiki information:
    1. study of different wiki platforms and wikis implemented on them
    2. study of relevant reports
    3. interviews, visits to other organisations, benchmarking of good practices
  3. specification of typical use cases
  4. specification of technical requirements such as the expected number of visitors and pageloads
  5. specification of available resources
  6. specification of architecture-derived requirements such as integrations to user administration, back-up systems, web publication and, in particular, the intranet, workgroup software and web learning environments
  7. selection of wiki software
  8. selection of the production model: purchased external service or in-house installation
  9. formulation of rules for use
  10. possibly, installation and configuration of the wiki software
  11. testing
  12. piloting
  13. user training
  14. roll-out.

As we mentioned in our introduction, the clarification of the organisation's processes should be a key priority. It is important to define what objectives the wiki is expected to advance and what it is that people are expected to accomplish with it. Only these issues will clarify the requirements for the wiki platform selection.

Motivating commitment

[edit | edit source]

If a wiki platform replaces an earlier solution, there may be opposition and change resistance. As early as in the planning phase, communications should highlight the benefits of the new system in comparison with the old. It may be a very good argument that other alternatives do not exist and many benefits will be gained through the use of a wiki (positive coercion).

The commitment of the future users can be advanced through training and organisation-internal piloting, which we discuss in more detail below.

An organisation-internal pilot as an example

[edit | edit source]

In larger organisations, in particular, it is expedient to proceed in phases and introduce the wiki into use through pilot projects. In addition to the technical advantages, this method also assists in the formation of favourable user attitudes especially if success stories exist to be passed around after the first pilot projects.

Training to support change

[edit | edit source]

Every time a new tool is introduced, the new users and maintenance staff should be trained. The use of wikis may be completely unknown to some people, and training must start from the very beginning (what is a wiki, how do you edit pages, how do you find information in a wiki etc.). Training can be conducted in small groups in which all attendees have their individual personal computers and network connections. In this way, wiki use can be practiced under the instructor's guidance.

In addition to the technical aspects, training should cover the required work processes and, if need be, even take time to redefine them. Often, the challenges encountered in introducing wikis for use are not the technical difficulties but the changes in the organisation's processes. If the changes are too extensive, many users may feel that the old processes make more sense. On the other hand, if the processes do not change at all, we can call into question the whole rationale behind the wiki introduction.

[edit | edit source]

The copyright of materials to be created in a wiki should be considered carefully and all users should be informed. The extremes of uses may be exemplified, on the one hand, by a private enterprise using a wiki in the description of its internal processes and, on the other hand, an association operating in the spirit of enlightened anarchism, focusing on producing as open contents as possible in accordance with the copyleft concept.

Enterprises should analyse the meaning of various items of information for their internal operations as well as for their business. In some cases, even enterprises benefit from public wikis: users can give valuable comments to e.g. the user instructions of the company's products.

Content maintenance

[edit | edit source]

The content maintenance work of a wiki should be distributed in particular when there is a great amount of material. Different persons can be nominated to take charge of the various sections to handle their updates as necessary. At times, it may be expedient to nominate an editor-in-chief for the wiki to manage its creation. If participants experience the barriers to their wiki writing as too difficult to overcome, materials may be submitted to the editor-in-chief who inserts them into the wiki. The editor-in-chief may also function as a moderator. In the case of public wikis (the content of which can be edited by anyone), in particular, the contents must regularly receive attention from a moderator because any open service will attract link spam (or wiki spam) and advertisements before long.

Features of wikis

[edit | edit source]

When you start to use wikis, you must form an understanding of what features you want and need — is it important, for example, that users are able to edit text easily in a manner similar to text processing (using WYSIWYG system). Other features worth considering include page history, language, user administration, data transfer and data structure.

  • Page history. Do you want all edits on a page and information about the persons who performed these edits to be stored so that it is easy to restore earlier versions of the page?
  • Language of the wiki. Is it essential for the user interface to be written in Spanish, or would an English-language user interface be better and more appropriate for a larger number of contributors? Are other language options required for the user interface?
  • User administration. If the wiki is open to all, it may be necessary to supervise the users and even bar those who indicate their identities unclearly or in a suspicious manner. It is important to study a platform's user administration features before actually selecting it.
  • Data transfer. Situations change and it may become necessary to use the data in the wiki elsewhere or to transfer it elsewhere completely. Whether the wiki platform is in-house or external, you should learn in advance how and in which forms you can extract your data from there.
  • Structure and structuring. After several years of use, it easily happens that information is not easily found in a wiki any more. Therefore, you should observe what search features and various data classification tools are available.

Usability of wikis

[edit | edit source]

You should think about usability before selecting and introducing a wiki platform. The uses in which the target group employs information technology, the members' IT skills and the contents of their work should be studied or at least considered in advance. If you want to include new starters in the wiki writer groups, you must pay attention to the ease of writing. For example, the basic editor in Wikipedia (e.g. the wikicode editor) is not easy enough for everyone, so if you offer the extended editor as an option, you may lower some users' barriers and help them start writing.

If the use of your wiki entails only the simple production of texts and pictures and the users are new starters who use the wiki infrequently, you should select a wiki with as simple a user interface as you can find. You should do this even at the cost of the number of features available for you.

If the users are experienced wiki writers, you might select a wiki with a great number of features and a syntax appropriate for power users. Many of these users appreciate being able to write in the mark-up language instead of using any WYSIWYG editor, because mark-up languages are faster.

Ease of navigation

[edit | edit source]

If the structure of your wiki is not planned in advance, the navigation on the pages is made difficult, or in other words, the usability of the wiki suffers. If the wiki contains a great number of pages and is allowed to form itself in an organic manner without a proper structural backbone, it might soon become difficult to find the desired information there. Wikis have technical features that make navigation easier. Many wiki services allow users to create the navigation and page hierarchy. We could compare wikis to books or folders that have new pages added and old pages edited as time goes by.

Most wiki programs allow the use of meta records, or indexing terms, to facilitate the finding of wiki articles. These words also facilitate the use of wikis.

Wiki use costs and profit generation models

[edit | edit source]

Wikis do not generate direct earnings, in general. In practice, the most common way of generating cash flows is showing advertisements to visitors to open wikis. Most of the true financial benefits from wikis come from the usefulness of their services for the users.

For example, a wiki functioning as an intranet may have a more economical licensing policy than a more traditional intranet application might have. In addition, if the wiki makes employees more eager to take part in the compilation of the collective knowledge of the organisation, this added benefit may be invaluable.

Price

[edit | edit source]

The costs of a wiki service should be considered at the TCO (total cost of ownership) level, or in other words, all secondary costs should be included. These costs may come in the form of time and money. The share of the server fee is relatively small in the total costs. A good wiki requires continual care.

Cloud services

[edit | edit source]

A wiki service implemented as a cloud service may be free of charge, or it may cost a few dozen euros per month, or it may cost several thousand euros, depending on the wiki's features and the number of visitors. If the service is offered as a cloud service, there are no other pecuniary costs.

Virtual private servers, fully managed hosting

[edit | edit source]

The party that offers the host server typically imposes an annual or monthly fee, usually including all technical maintenance, the back-up system and all data security updates. When purchasing fully managed hosting services on a virtual private server, you should make sure the services include the wiki software you want. If you intend to use software that the service provider will not cover, you have the option of using a virtual server that you manage yourself.

Virtual private servers managed by customers

[edit | edit source]

The fee for a virtual private server that you manage yourself typically includes only the maintenance of the hardware and the operating system. Utility programs such as wikis installed on such servers are managed by the customers themselves. This gives the customers more options regarding their software solutions and tailoring, but it also means more maintenance work. Additional work comes from the installation and commissioning of the wiki, the required data security updates and the monitoring of the operation once active. Back-up systems typically belong to service agreements of virtual private servers.

In-house servers

[edit | edit source]

If you have your wiki installed in-house on your own server, your costs will include the purchase costs of the server, the electricity and network costs, the time required for the technical maintenance of the server, the back-up copies, data security etc. The purchase costs of the server are likely to be rather small in comparison to the costs of the required maintenance time, unless your organisation already has other servers and has put in place a properly optimized server maintenance process. In the next section, we will handle certain issues relating to wiki platforms installed on in-house servers.

User training

[edit | edit source]

Once your wiki works reliably, you should assess the users' training needs and then train them, which will create costs due to the training arrangements as such and the working time required of the trainees. Even if the use of wikis for information acquisition were familiar to your trainees, they will now, as novice writers, need written instructions and preferably also personal guidance and encouragement to web writing.

Wiki platforms installed on in-house servers

[edit | edit source]

You can obtain a wiki as a service, or you can have one installed on an in-house server of your own. In this wiki, we provide information about easy-to-commission wiki platforms in the section Starting to use wikis.

Often, the reason for setting up an in-house wiki platform is that the contents of the future wiki will be critical in view of the operation of the organisation. Even if the wiki were public and open for anyone to edit, the safety of any critical information (back-up copies) and the need to ensure the availability of the information (that the server and service are working and available) form good justifications for setting up an in-house wiki platform.

You should also consider whether the information stored in your wiki should be located on an in-house server or whether it could be placed on a server of some external party. Depending on how your organisation works, the information on an in-house server will be either easier or more difficult to administer than information on an external server. In-house installations also require technical resources to maintain the wikis. You can purchase technical maintenance services for your server from various external parties, and when you commission the server, you can also purchase externally the modification of the wiki to match it with the company's image and the intended purposes of use.

When selecting a wiki, you should consider what its contents will be, what sort of information it deals with, and how the wiki will be used. Ask yourself these two essential questions: (1) Is this information critical or in some way essential for any particular function in your organisation in the sense that the availability of the data is important or maybe even vital for conducting the daily work? (2) If the information in the wiki, or great parts of it, would have to be transferred to some other place or service, would it be possible to do this effectively (exit plan)? The more important the information is for the organisation, the more consideration should be given to the issue of who operates the service. When dealing with free-of-charge services in particular, you should study their terms and conditions carefully and determine whether or not the service levels they describe will suffice. It is the most expensive solution to set up a wiki environment of your own, but if you do, the information contents of the wiki are held more tightly in your own hands. Even if you use free and open source software, you will have costs accrue due to work and server space.

If there are good grounds for using a wiki and an in-house installation for the organisation is preferred, you should compare various wiki platforms. An IT expert from your organisation should be involved to help in the comparison, because some of the requirements that you will encounter will relate directly to the technical aspects.

There is a multitude of wiki platforms available, and anyone intending to choose one will experience some difficulty in making the choice. A good place to start the search and comparison of platforms is the WikiMatrix pages. Below, we will present examples of platforms that might be installed:

Examples of wiki platforms:

  MediaWiki is the platform used by all Wikimedia Foundation projects. It is free and open
  source software and can be installed for your own use without licence fees. There are
  hundreds of extensions available for MediaWiki to provide new features rather
  easily. If you are reading this book in Wikibooks, you are using MediaWiki at the moment.
  You could try the edit-button to see how you can write in here. There are several derived
  programs of MediaWiki that are easier to use and simpler than MediaWiki itself. For
  example, DokuWiki, compared to MediaWiki, is a light and fast
  platform with extensions still under development.
  
  Trac is a wiki that combines task management and the follow-up
  of the source code; it is suited for software projects in particular but will be flexible
  enough to accommodate also other sorts of large projects provided they can be subdivided
  into smaller "tickets". In such a case, someone should be involved in the configuring of
  the software that understands the procession of a software project and is able to adapt
  Trac logic to the needs of such projects.

Wiki selection

[edit | edit source]

In the section Wiki selection, you will find information about issues related to the selection of a wiki platform.

References

[edit | edit source]


Wisdom in wiki production contents
Wisdom in wiki production Home 1. Introduction 2. Starting to use wikis 3. Different uses of wikis 4. Target groups of wikis 5. Introducing a wiki for use 6. Wiki content production process 7. Good wiki material 8. Wiki literature