MediaWiki for a Museum (Non-technical issues)

While the article MediaWiki for a Museum describes the technical steps to build a wiki for a museum using MediaWiki, this article focuses on the non-technical issues which might be considered as well.

At the National Museums in Berlin, the internal website was replaced by a wiki. The author describes possible issues referring to his experience during the project.

Non-technical issues with a wiki

A wiki system (or shorter: a wiki) is an application for creating and managing content. Therefore the wiki serves as a container and toolbox for the content, it's not a purpose itself. The design of the wiki, the specific configuration (e.g. extensions), and the organizational management (e.g. administration and user account management) should follow the objectives of the project and aim to support the content management which is conducted by the participants of the project.

Wikis are considered to be social software↑, therefore the specific interests, relationships, and social skills of the people using the wiki are much more important than the technical framework. For example the use of MS Word↑ as a text processor is mainly an individual process. Although there are some tools included like tracking changes, or comparing and merging documents, which can support a collaborative use of MS Word, it is more an application designed for individual purposes. The philosophy of wikis is totally different, although one could employ a wiki as a unique user as well. As soon as a wiki is being occupied by more people, the social components of this application will become obvious.

Because this is a relatively new kind of software, most users are not familiar with these principles, and they will express their concerns, objections, and problems in the manner customary for them by describing a "technical problem" or an organizational issue. The following questions or statements are mostly caused by non-technical problems and should be transferred to the social level where they can be addressed. Due to the enormous number of possible modifications and extensions of the MediaWiki software, some problems could be solved with functional or organizational means as well. For example there are functions to protect pages or extensions to implement more sophisticated models for user rights including the exclusive authorization to read specific namespaces. But these instruments will change the character of collaboration dramatically and modify the wiki to a more conventional content management system. If this is really intended by the project management group or the community of users, another CMS↑ might be a better choice than a (Media)Wiki.

This is too complicated.

What exactly is complicated? Please specify your problem.

I don’t have time for this.

Collaboration needs time. If you really want to cooperate, you need to spend time for your communication with colleagues.

Others will not accept this.

If you accept, others can take your approval as an incentive example.

This is too new for me; I'll do it later.

Before you start to work in the wiki continuously, it will appear to be new and inconvenient to you for a long time.

This information is important only to me. How can I protect it from viewing by others?

Is it confidential information? Why do you think, nobody else could require this information? You might define the subjects suited for collaboration with others.

I don't want to have this altered by others.

Why? Do you really think, this information cannot be enhanced, updated or completed?

Why don't you trust your colleagues?

This text is not ready yet.

Perhaps others can add something before you think it's ready.

Why does it need to be complete before sharing it with your colleagues?

I'll deal with it later when I have more time.

Collaboration is a continous task. It's more efficient to spend smaller amounts of time regularly than larger ones infrequently.

More complex issues and misunderstandings

The people in the IT↑ department are the specialists we need for the wiki project.

While the technical implementation and the embedding into the existing IT infrastructure can be handled by IT specialists probably in the best way, the other aspects of a wiki project, i.e. the non-technical ones, should not be considered as IT-specific. For the definition of the main project objectives referring to content, content management, and organizational aspects, other staff members should be involved. A mixed project group including senior staff and decision makers might be a good idea.

A smaller test group will build up the wiki before it's released to the entire group of potential users.

The interests and the dynamics of a smaller group can be significantly different from a larger social unit. This will change the nature of the wiki and might reduce the acceptance and depreciate the motivation of the main group.

The wiki is meant to be an additional source of information, and shall not replace other means of communication or information mediums.

In many organizations newsletters, distribution lists, mails to all users, or other utilities are well established and accepted. However, the maintenance and the regular use of these instruments require workforce and time which is therefore not available for the new wiki. Why should your colleagues use the wiki when there are well established utilities which also serve the purpose in their believe?

The wiki is a really good idea, but there need to be some changes before I (our department / my colleagues and I) will join.

If something is missing or needs to be changed from a specific point of view, who could be more competent to make the necessary adjustments, changes, additions and supplements than the one(s) observing them? In most conventional information systems, various user roles are created, each with their own distinctive rights, requiring other people to be involved when additions or changes are necessary. The very flat hierarchy of rights in a (Media)Wiki enables almost everyone to do anything. But this also means to take full responsibility without the alternative to refer parts of the obligation to another specialist or expert in the editorial process before making a decision. However these other authorities can still add their expertise if necessary.

I need to learn more about wikis in general before I feel safe enough to join. Or from the perspective of the organization: The users have to be trained before they can use the wiki in an appropriate way.

The general principle of a wiki is simply to provide tools for a collaborative community to create, collect, and manage information. But in most organizations people are not accustomed to accepting preliminary or unfinished texts to be "published", i.e. made accessable for others. The demand to master an application before using it, seems to follow the same pattern of acceptance. There are different ways to encourage the liberal use of incomplete or "raw" bits of information in an collaborative environment, but they should be connected with the wiki itself. Otherwise, parts of the information management will stay outside the wiki consuming additional time, tools, and work, therefore reducing the efficiency of the wiki project. It might help to remember, that wikis are being employed very efficiently by many software developers to ensure quality, best practice, and continuous enhancements of their product. Usually this work is never "finished," but will be constantly customized to new evolutions and requirements. This perception can be transferred to other collaborative objectives and purposes as well.

"Learning by doing" seems to be the best way to get familiar with the structure, tools, and functions in a wiki. Small steps of practical use will do better than extensive training of the whole equipment, and continuous work in the wiki on a regular basis is more efficient than intense periods of use interrupted by weeks of absence from the wiki. It is helpful to split the workload into parts which can be accomplished before starting something else so that others in the collaborative community will have the opportunity to interact if they want, and the preceeding editor can see the possible result of interaction when returning.

Conventional software training focuses on the individual learning process, while a wiki needs the more collaborative skills.

See also

• MediaWiki für ein Museum (nicht technische Fragen) (German version)
• Social software and museums