Exploiting The Potential Of Wikis
Full Discussion Group Notes



Discussion Group A1: Supporting The Needs of the User

Discussion group A1 has the theme "Supporting The Needs of the User".

Two sets of issues are given below. You can chose whether to address one of the issues, both of them or possibly split you group into two.

Issue 1

Issue 2

Report

Here's the inital brain dump of this morning's discussions:
Mixture of e-learning and IT.

Issue 1

What case studies are there?
Students reluctance to collaborate? Assessment driven and very good at time managing.

How do you get valid assessment?testing

How do you get staff to look at these type of technologies? Get away from the VLE focus.

Just started using a wiki with a e-moderating course. Using to start setting-up pages.

Decon uni - still evaluatingthe production of the wiki. Main findings 92% joined in. 70% understood. But didn't found any benefits.
as opposed to f2f collboration.

LSE have run a few. Taxepedia - produce a glossary.
Research, "travelling concepts" being used with external institutions.

Using a wiki to evaluate VLEs!

First use tends to be research collaboration.

Is assessment essential when using a wiki with students?

Group work.

Changes to institutions

What bits of a wiki are the best bits for educators?
What learning activities fit best with a wiki?
Struggling with being the facilitator.

Encouraging with collaboration in any tool.
Is this a challenge even with f2f?
Can a wiki help with undestanding that collab? i.e who is contributing to collab.

Do wikis offer more student ownership?

Is there a danger of a wiki overload? Trying use it. Do we require more educational research? Measure the outcomes.

Assessment is still key.

Are they being used because their novel?

Where the students see benefit, ie henry's wiki can be seen a resource.

Do we know why it worked?

what quality of work do we get out of a wiki?

Trusting wikipedia? Hence trusting web sources? It looks authorative.

Bebo, myspace in spaces outside VLE.
Are they putting pressure on tutors to change. They haven't bridged the gap between social and learning spaces.

Is this because the students has a fixed idea of the learning process?

Does this make it harder in the long term.

Who wants to use wikis?

Students require personal space.

Wiki don't suggest about how they should be used. Information support staff creating FAQ.
Project development/management.
Product development.

Produce a joint doc in a wiki through field work.

fSuggest resources, and then open it up.

Replacement for endless email discussions on project work.

Giving students/staff tools for making this open.

Either using informal spaces. Can we bring those into the institution.

Introducing them as personal tools. Started with theindividual tool.

Are the practices of collaborative teaching skills still developing.

Academics reluctance to share. If completely open, feel threaton.

Needs to have the stakeholders understanding of using the wiki. Understanding the benefits.

Content is not king.

Who owns the content? Are the same problems being faced with the digital repositories the same for wikis.

Defintely being used for teams.

How do we ensure for engangment and don't loose students?

Assumptions about digital natives, feeling excluded.

Scaffolding issue. Are we looking at an evolution of these tools. First years a small amount of blogging and full own wki for project work in the final year.

Still need case studies.

Talking to students/staff about their confidences.

Networks, interactions are being made easier via web2 technologies.

Ask more questions!

IT institutions hanging on whereas.

23things in library in states. Blog + podcast. Drop in a level 1.

Need to bring staff through different environments, i.e. Gilly Salmon's 5 step model.

How many institutions are using blogs?






Discussion Group A2: Supporting the Needs of the Institution"

Discussion group A2 has the theme "Supporting The Needs of the Institution"

Suggested topics for discussion:

Report

Who are the organisations, departments and instititions which have an interest in Wikis?

In institutions - IT departments, Libraries, Management, Community - student experiences on year abroad or placement, Pre-registration work with new students - in addition to the academic uses we heard about this morning.

What case studies?

- Use for collaboration between various management teams to build policy documents
- Use for annotation in project development
- Chaotic growth - authentication problems - people get to hear about them only via mailing lists - eg three in one department
- Knowledge-base for Library staff
- Document procedures - server settings - troubleshooting - ease of use over traditional issue tracking mechanisms.


How would the various organisations benefit from the provision of Wikis (as opposed to individual members of the organisation)?

- People feel happy that the Wiki is simpler and attracts naive users.
- Visibility during development
- Get round the "container" problem - services people talk about "documents" while academics talk about "lessons" hence no container constraint.
- Promotes quick change of errors - chaos prevented by audit and lock-down.
- System issues shared so documentation builds itself.
- Marketing tool to promote recruitment.

What requirements do the organisation have (as opposed to individual members of the organisation)?

- Control of the message at institutional level - but should be able to take criticism? Confidence of the institution.
- Who owns the copyright? What disclaimers? Trust the users and delete the material if there's a complaint.

What conflicts may there be between the needs of users and organisations?

- ditto above!
- Tends to attract a geeky audience - could be dominated by a certain element - certain students will feel challenged - Mature students - generational.

What other key issues need to be addressed related to organisational needs?

- Overall that institutions are still nervous about this technology.
- In use for filesharing - but is that a Wiki?
- Too many systems? Wiki / filesharing / EDM / Portal - which to use.
- Constraints - signed-off documents - print problems

Discussion group A3: "Beyond the Needs of the Student"


Discussion group A3 has the theme "Beyond the Needs of the Student".

Suggested topics for discussion:

Report

1. Besides use in teaching, what other key user groups may have an interest in wikis?
a. Learners
b. Publishers
c. Industry
d. Tool for innovation (eg "brain-dumping" [like brainstorming])
e. Research for academics working on the same theme
f. Course development teams
g. Getting academics to collaborate with users
h. External examiners (eg if students are using wikis then the external examiner would like to look at the wiki
i. support services (eg central administration, IT support)

2. How would these various groups benefit from the provision of wikis?
3. What requirements do these groups have?

4. What conflicts may there be between the needs of these groups of users (with the needs of the student user?) Q1 Acceptable behaviour: try to keep as free as possible. Different requirements (eg placement)
Q2 Student feedback: in USA it has [been tried?] but it's early days

Could a wiki be used for getting student feedback? requirements/conflicts: different style of approach
Appropriate wiki use
5. What other key issues need to be addressed related to the needs you have identified? 6. Additional points
* as opposed to have it forced upon them

Participants (please add your name/contact if you were in this discussion group)

Kim Whittlestone, RVC
Frances Bell, Salford Business School
Peter Adamson, University of St Andrews

Discussion Group A4: "Beyond the Institution"

Discussion group A4 has the theme "Beyond the Institution".

Suggested topics for discussion:

Report

Add a report on the discussion group below:

Discussed setups at own organisations:

Issues - sign on, single sign on, shibboleth, LDAP, who do you give access to? University of Cambridge currently can't let external people in. Wiki farms

University of Bath are willing to share their managed wikil service - the model. Would this be appropriate for every institution?

Can we benefit from using external services - maybe by a JISC managed environment or Google?

Then the issue of external users goes away because we are all external users.

Issues if IT Service are difficult!
:-)
All to do with community - context of community.

What service you are providing in the first place. Pan institutional is different from extra institutional.

Some people are resistent to using wikis. Clear from start who will and won't use the wiki.

Collaborating - not everyone will contribute but this is ian't always an issue.

Authenitication is easy

Lots of cross intitution collaboration, cross country collaboration accross (for example Chemistry) different institutional departments. Very useful for writing documents - is it the right format - versioning issues. UOC use sakai - not so Web based. Shared space - set of people sign up for a space and work together - benefits over a wiki. Elements of trust. Access to other things - wiki would need to put in links. This is more personalised and desktop and not so html based like a wiki. Coul crow bar this functionality into a wiki but with difficulty. More working towards a finished document - wiki is not so organic. Better to lock it on a wiki - rather than versioning. No overview of everything. No easy way to see a picture. This is metadata, categories etc.

Subject departments in other Unis, students union, communities of practice.

Wikis lack the heirarchy - v.flat heirarchy - links go everywhere. Formalisation of this would be good. Solution in Bath does support hierarchy.

Worry that by adding by heirarchy etc. that we take away the very essence of wikis. Will all technologies blur over time - just fitting it for whatever suits you. Or will technologies become more specific over time? Can't prescribe what wikis are for just observe patterns of usage.

Communities of practice - observing how communities work. Who do communities have as a champion? Whose role is this within your intitution (who is reponsible for the Wikipedia site). Empowering students - getting them to write stuff on their university - can't write marketing hype (citing data).





Discussion Group A5: "The Power User"

Discussion group A5 has the theme "The Power User". Note this session will be held only if there are sufficient numbers.

Suggested topics for discussion:

  • What are the main challenges related to provision and user of Wikis from your perspective as a Wiki power user?
  • In what areas can Wiki power users support effective use of Wikis?
  • How can our user communities best benefit for the expertise of power users?

Issues you might like to consider include:

  • Getting data into and out of Wikis
  • Migration between Wikis (including issues such as markup standards, application logic, etc.)
  • Quality of HTML from Wikis
  • Wiki URIs (conventions, length, application dependencies, ...)
  • Inter-WIki interoperability (transclusion, syndication, etc.)
  • Wiki access and authentication issues
  • Managing risks (e.g. open access Wikis)
  • ...

Report

Add a report on the discussion group below::

The group's discussions covered a number of the above points in general terms looking specifically at the following :
  1. Quality of content
  2. exporting the content of a Wiki
  3. Metadata issues
  4. Engagment and contribution (of and from student)
  5. Bots
1. Quality of content held in a Wiki : in terms of the actual content, there is the way the content will be displayed (controlled by the quality of the use of the mark-up language that is used. Templates were felt better for students to use compared to standard HTML for example created via some external editor (if ony that there would be some consistency), whilst the user needs to be aware that unlike traditional HTML, every character can count and spaces take of specific meanings. Indeed students can and will add their own templates.

There are of course other mark up lanuages that should be considered such as XML, SVG and CML and there can be issues around the use of these.

There is also the trust factor and so this can lead to issues around the engagement of staff / students (but as the group later concluded Wikis by their nature are somewhat self-repairing).

2. Exporting the contents of a Wiki - many Wikis include an export facility, usually in the CSS 2.0 specification, but this is often via a weak XML schema, and so only really suitable for input of the information into another similar system.

3. Metadata - whilst it's use is vitial this is often problematic for the user (they may view it as a chore and so avoid doing it accurately if at all. One answer to this is automated production (possibly via a Bot - see part 5 below) but this itself is problematic. Although semantic templates whereby the Wiki learns look very promising and can for example be via an automated approach working in the background with no human intervention (and so no risk of human error!)

At present the results are generally 80% useful (maybe more in sopecific fields (see below), the remaining 20% (mainly based around logical inconsistencies) is still dependant on human intuition beyond the current capabilities of the systems that do exist.

Ideally what we need is a library of semantic templates that can themselves call on human help when human understanding is called for and this may well result in at least 95% accuracy (such as the concept of the Mechanical Turk set out below).

The value of metadata is increasing but as systems develop we run the risk of making them difficult to use and a major problem will be getting the right mix of usability and resilience (i.e. we would not wish to see something so secure that it becomes difficult to use).

4. Engagement and contributing are also factors to be considered - e.g. how can we encourage students to participate and use software like Wiki's especially in situations where they prefer to be spoon-fed? Indeed will Web 2.0 tools which by their nature are dependent on human to human interaction be of use here. Ironically, the fact that Wiki's are so free-form may help.

Widening this out, are web 2.0 models really going to that effective for use in educational institutions? Our group doesn't pretend to know the answer, but it is worthy of debate nontheless.

Trustability is another issue - whilst trust in the content of Wikipedia for example is quite high there are occasions when through either misconception, or as a deliberate act some of the content can be incorrect. The way forward might be along the lines of http://www.citizendium.org/ where a panel of trusted experts such as University Academics monitor / create content.
5. Bots can be useful as they can for example work through pages correcting e.g. spelling errors. Indeed Bots may be the answer for automatic creating metadata. They are however limited in areas such as dealing with logical inconsistencies where human intervention will be helpful.

Dr Peter Murray-Rust has developed a GREP of some 3000 lines which is said to be 90% accurate for checking the content of cemical articles. Although very much textual at present a group is looking at expanding this to check diagrams.

Then there is Amazon's Mechanical Turk linked to a database of human experts when it meets a problem it finds to be unresolvable. This in turn will help us to appreciate the 5% - 10% that we need to move towards 100% accuracy (Knowing what we don't know to paraphrase Donald Rumsfold.)

Discussion Group B1: Wiki Strategies to Support the Needs of the User

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:

For Your Notes

Strategies for Using Wikis

Conversion tool useful. Not feasible to ask IT services to support multiple wikis services.

Do you have to force your own pedagogical designs on the wiki?
Does it give people space to play. What design baggage comes with the tool?

Want something completely flexible.

If you want flexibiltiy then must have IT support to develop it.

Most people are still at experimental stage so tool needs to be flexible.

VLE's can be too prescriptive.

External hosted : pbwiki, jotspot, wetpaint.Being used "under the radar".
But may need wiki farm at later stage when institution sees the need.

Standards would be seem now more important as more enterprise wikis become required.Other tools could provide some of the support.

It's difficult to be a pioneer. Scalability could be an issue.

Some instituions are waiting to see what MS are building into Sharepoint. They are building in more blogs/ wikis.

Where do we find out about these different issues with wikis? No source about caveats.
Should we be asking JISC to set up an advisory service?

Wiki functionality inside other enterprise tools? Will open-source community help?

Different sites for different tools? With more tools is it becoming harder for students for manage?

But students are comfortable in a social context navigating between this but no so in their learning spaces.

I f wikis are behind the walls of an institution how do students/staff talk to their peers in other institutions - even internationally.

Leaving these tools outside the institution makes them more open and allows for information to come into the institution.

Identifying user requirements?
Is it a bit of chicken and egg situation.

Some trials starting and identify requirements. Made up a large cross-spectrum, including students.

CETL for useable learning objects. You need everybody involved in looking at these technologies and should be an iterative process. Should be able to re-evaluate.

What are the key aspects of evaluation?

Selection -

deployment - outsource or pushing IT srvice to host wiki farm. Wait to see how things emerge and evolve. Learn by your mistakes.

Little sucesses can be tried in a bigger arena.

Need different pedagogical ideas for use. May get some of this from HEA subject centers. Find more case studies. There's a discpline approach, pedagogical approach. Looking through different lenses at these tools.

Do the institutions have to adapt the way students are comfortable using. Need to keep learning relevant.

The success or failure of technologies depends on how embedded they are in the learning and teaching.

Always will have the champions but need to get the rest involved.

Are wikis that easy to use? Are we happy collaborating?



Discussion Group B2: Wiki Strategies to Support the Needs of 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.
    Possible plugin processes
  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.

    We need to be clear about the requirements before we can determine the best approach.

Please address the following issues:


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


Discussion Group B2: Notes


Would type of work determine what solution is adopted? Use of VLEs for instructional information (other than academic). Potential issues for external collaboration with VLE.

Support - we don't have the resources to support yet another institutional service. Organic nature - backup/archive.

Must have Buy-in, sustainable growth, good practice, capacity, migration.

User control - who is the gatekeeper. NOT IT! devolve rolls. Depends what it's for. What's the data? Keep user control fairly coarse - similar to other IT services. Impossible to monitor by policing.

Visual style - most institutions would want their own. How do we ensure accessibility of this user-generated content.

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


Discussion Group B4: Wiki Strategies to Support the Needs of External Groups

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

Providing an enterprise service is a solution that will succeed in most institutions but in many institutions departments will want their own because they'll want something different. Whether that is commercial or a open-source product will depend upon the institution, local expertise and money available. Small groups might choose to use an external hosted service just because it's are available.

A managed service can be provided but you have to choose the application carefully and have the foresight to anticipate what difficulties you need to try to get over.

Problem areas:


Approaches:







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.