Exploiting The Potential Of Wikis
Discussion group B3: Beyond Student Requirements


Discussion Group B3 : Wiki Strategies to Support the Needs of Disparate Groups the Institution

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


pros
cons
1. A large-scale enterprise Wiki service for use within your institution
  • cf. Phil's ease of editing
  • everyone having shared experience
  • no re-learning
  • stability maintained
  • editorial control
  • authentication

  • choosing: could be too soon
  • the choice is critical
  • retraining postgraduate people (but transferring should be easy)
  • insular

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.

  • each discipline can choose its own tool (eg chemistry molecules)
  • departments don't like being told what to do so they can have ownership
  • cross faculty: could be either pro or con
    • have two different wikis to learn
    • consistency for students


  • support and maintenance: multiplied by the variety of systems
  • but also other software implications (eg Java etc)
  • security
  • cross faculty: could be either pro or con
    • have two different wikis to learn
    • inconsistency for students

3. Use of Wiki functionality provided in other enterprise tools, such as VLEs, Blogs, etc.

  • familiar with the environment
  • authentication: don't need extra password
  • closed environment space for student activities, including assessment
  • easy to integrate with existing systems
  • can be developed organically based on feedback
  • 'one stop shop'
  • need to make things easy


  • pale imitation
  • they could charge more

4. In-house development of a Wiki service.
  • get what you want?
  • if you know what you want, then OK!
  • institutional buy-in: the people within use "their" product
  • collaboration between establishments
  • complex model of reward for those directly involved


  • expensive
  • long time to develop
  • need proper analyisis of requirements
  • "a decision has been made"
  • "I don't want to know"
  • the one person who know all about it leaves the institution!

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.
  • subversive: individual will adopt something
  • do I need one?
  • Is it just a trend?
  • will students use it?
  • do they care


  • possible embarrassment?
  • institution being behind the times
  • not providing a service