Exploiting The Potential Of Wikis
Discussion group B5: Power Users Supporting Wiki Strategies


Discussion Group B5 (Afternoon): Power Users Supporting Wiki Strategies

Issues

Based on your previous discussion and related points from the other discussion groups you should now seek to identify a Wiki strategy for your institution.

Possible strategies for providing Wiki services include:

  1. A large-scale enterprise Wiki service for use within your institution.
  2. A distributed and decentralised approach, in which departments, ad hoc groups, individuals, etc. may choose their own preferred Wiki tools, which could be installed locally or use of free or licensed externally-hosted services.
  3. Use of Wiki functionality provided in other enterprise tools, such as VLEs, Blogs, etc.
  4. In-house development of a Wiki service.
  5. Doing nothing, either because effort is limited and prioritisation is given to other areas or a view that Wikis are of marginal relevance to the institution.

Please address the following issues:

Based on your preferred approaches to the provision of a Wiki service:


Notes

The group started by talking about Deployment Issues and in terms of Wikis there are two types of deployment that need to be considered:

Central to the deployment of content is how to handle different types of media and specifically the need to decide if we need to develop to meet the needs of whatever community we are serving, or do we impose restictions on the community from the start i.e. where is the divide between quality and quantity, etc.

Also how do we drive such innovations? Is it via staff being innovative or student word of mouth?

With regard to system software, updating to a new version of a Wiki can be difficult as there may also be the need to upgrade underlying systems which support it (this tends to imply the need to involve the central IT service).

Indeed, any deployment strategy depends on identifying if people will approach a central service to say they require a WIKI or if the people do it themselves (do any institutions actually have a policy for Web 2.0 softare deployment for example). The latter option is more open to the needs of the community at the expense of them being on their own.

Next there is deciding which software is to be used. There are two main players emerging in this respect, MediaWiki (the basis of Wikipedia which is opensource but suffers from being a flat file structure), or Confluence (commercial).

We will probably need to consider restricting access to these and with this in mind proposal from Jisc that they launch a project to apply Shibboleth to these products.

Returning to the cenmtralised IT service, Web 2.0 software can present a challenge to such as more and more software that used to only be availale on the desktop now has a web based equivilent (consider Google's Writely cf Microsoft Word for example).

Whilst Wikis may start out with a simple approach they can quickly lose this attribute. should we discourage therefore the use of non-institutionalised solutions - here again maybe web 2.0 tools perhaps require a 5 year startegy developing to overcome the lack of such as already noted above.)

One option we could consider could be an in-house wiki-farm where by staff who require a Wiki for their course could fill in an online form which automatuically leads to the generation of a Wiki - this helps the IT service as being automated they wouldn't need to take on additional work, and also it can help with things like scalability and being an automated process could also present a what-next page to help each user.

Finally, the group believe that Wikis are better than blogs, as they can be seen to be self-repairing (we feel that students would want to keep the content accurate rather than spoil it for the rest). Blogs are very much an individual's work whereas Wiki are a team effort and so we see Blogs as little more than a person's Home page and so may be short lived compared to Wikis.