Planet: Muvenation Case Study


Published on

A case study for the Planet project from the MUVEnation project.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Planet: Muvenation Case Study

  1. 1. Case study: Building an environment for effective collaboration and communication between distributed EU project partners Contributors: Steven Warburton, Margarita Perez-Garcia Project: MUVEnation Date : April 2008 This case study is presented as material for the Planet pattern language project, see
  2. 3. Situation <ul><li>Project tagline </li></ul><ul><ul><li>Peer supported learning using social technologies for teachers engaged in the deployment of MUVEs in educational settings </li></ul></ul><ul><li>User group and the work context </li></ul><ul><ul><li>7 project partners across 5 European countries with limited opportunity for face-2-face interaction </li></ul></ul><ul><li>Technological setup (and frequency of use) </li></ul><ul><ul><li>Project blog – semi-formal public dissemination of project activities (medium) </li></ul></ul><ul><ul><li>PBwiki – multipurpose tool for organisational issues that range from setting to-do lists to sharing project documents (medium) </li></ul></ul><ul><ul><li>Googledocs – for shared editing of project documents (low) </li></ul></ul><ul><ul><li>Go ogle calendar - for marking key dissemination events and deadlines (medium) </li></ul></ul><ul><ul><li>Group mailing list for all project partners - general discussion and often the default space for group conversations to begin (high) </li></ul></ul><ul><ul><li>Moodle VLE – a course delivery space for the induction course aimed at teachers but also some use of the discussion space and wiki for PM (low) </li></ul></ul><ul><ul><li>Flickr group - for documenting and sharing in-world activities (low) </li></ul></ul><ul><ul><li>Telephone conferencing - for audio meetings (medium) </li></ul></ul><ul><ul><li>Tagging - to formalise and aggregate data (low) </li></ul></ul><ul><ul><li>Aggregation of personal data feeds using widgets/tags/RSS (low) </li></ul></ul>
  3. 4. Task <ul><li>Describe what you are trying to achieve. Describe the forces in play: </li></ul><ul><ul><li>the project is in the process of designing a coherent platform built from from a range of distributed social tools to support project management and partner collaboration during the lifetime of the project. The forces in play might be summarised as geographical distance, language differences, digital literacy and working practice, level of prior experience and individual/partner expectations </li></ul></ul><ul><ul><li>ideally the electronic environment will also be used to manage and deliver the teacher training programme that the project is aiming to develop </li></ul></ul>
  4. 5. Actions <ul><li>How did you try to address the issue/s? </li></ul><ul><ul><li>hold an early face-2-face project meeting to discuss user needs and possible social tool-sets and services that could be adopted </li></ul></ul><ul><ul><li>assign responsibilities for their instantiation. There was open acknowledgement that not one single tool could fulfil all the requirements of project management, communication, co-operation and course delivery </li></ul></ul><ul><ul><li>set basic ground rules for their use e.g. production of a tagging handbook to help aggregate personal and public data </li></ul></ul><ul><ul><li>draft a set of guidelines for use that is open to contribution from project partners </li></ul></ul><ul><ul><li>negotiate the use of these tools through email correspondence and telephone based conference calls </li></ul></ul><ul><ul><li>conduct an iterative review process of the tools ‘in use’ and evaluate those which are effective and those which are not </li></ul></ul>
  5. 6. Results <ul><li>What were the outcomes of the actions? </li></ul><ul><ul><li>multiple social platforms were created and basic content added but not everyone was immediately active. </li></ul></ul><ul><ul><li>constant mailing ensued about the ‘correct’ use of each of these platforms yet this did not solve what were identified as an unmanageable number of content locations </li></ul></ul><ul><ul><li>partners did not feel engaged by the tagging handbook and this resulted in minimal contribution to the site guidelines for tagging use </li></ul></ul><ul><ul><li>there was a clash between the use of open tools such as ‘blogs and wikis’ and closed tools such as Moodle. Open tools were favoured and Moodle was not fully adopted by the partners even after an initial flurry of activity. A discussion forum is now being added for the project partners that will be independent from the Moodle platform </li></ul></ul><ul><ul><li>the wiki was spontaneously adopted (despite initial resistance) through its value as a place for immediate action, particularly during a two day face-2-face project meeting. Expanding the use of the wiki to other project processes became a contentious issue as debates around public/private were raised i.e. which processes should remain internal? </li></ul></ul>
  6. 7. Observations (1) <ul><li>Lessons learned and conclusions drawn: </li></ul><ul><ul><li>simple tags work but tagging handbooks do not seem to work (lack of literacy and discipline?). Registration of user-defined tags may work and is being adopted as a way forward. </li></ul></ul><ul><ul><li>guidelines are needed to orientate project partners and individuals towards document and information locations and to set the ground rules for use - though these guidelines may only serve a limited purpose </li></ul></ul><ul><ul><li>technologies are appropriated to serve unexpected needs - through use it is clear that certain technologies are able to support all of the project partners whereas others do not fit with normal working practice and end up left to one side e.g. extending Moodle for document management and internal discussion (as opposed to simply for the development and delivery of the course) </li></ul></ul>
  7. 8. <ul><li>Continued: </li></ul><ul><ul><li>‘ purpose’ is an emergent property that grows from user behaviour and activity across the available tools‘easiness’ is a driver of project partner toot-set use. Applications that mimic Office kinds of document handling are the most used as well as what might be described as owned tools e.g. blogs </li></ul></ul><ul><ul><li>the external facing Pbwiki was appropriated as opposed to the internal facing wiki inside Moodle. </li></ul></ul><ul><ul><li>using multiple platforms requires discipline and acceptance that user behaviours will eventually shape the environment that emerges </li></ul></ul><ul><ul><li>project partners need to be flexible and understand the above property and be willing to adjust accordingly </li></ul></ul>Observations (2)