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:

• What are the pros and cons of these approaches?
• Which approach(es) best satisfy the user requirements you have identified?

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

• What potential problems and difficulties might you expect in the deployment of a Wiki service?
• What approaches would you recommend for the effective deployment and support for your preferred Wiki service?
• What tensions may there be between a solution to support your groups of users and a solution aimed at the needs of the student user?

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