Wendy Fountain, Wayne Britcliffe Playing leapfrog Supporting collaboration with wikis and blogs in entry level VLE projects Wendy Fountain, Wayne Britcliffe & Cathy Colless

Support for collaboration & interaction models Session outline Starting late Training approach Support for collaboration & interaction models Examples from life Set-up & configuration Discussion

Late, phased roll-out of VLE 2005-2008 Starting late Late, phased roll-out of VLE 2005-2008 Currently in 2nd round of pilot projects 1st round ca. 20 projects 2nd round ca. 40 projects Project Timeline

Why pilot projects? Encourage innovative & enhanced approaches, with targeted support Capture and disseminate good practice via: Training, lunches, interviews, case studies, conference etc. to establish quality practice Side effect: Installing the Campus LX Suite & upgrading Bbd to 7.1 provided our users with a collaborative toolset early in their learning curves How we were able to leap-frog. Timeliness: We could offer and promote a rich toolset for the large number of pilots that had a collaborative focus rather than a content focus. The new tools in turn influenced how pilot leaders conceptualised their modules. By collaborative tools we mean wikis and blogs in particular. The use of adaptive release by group membership on content and discussion forums was also utilised in re-focussing group spaces.

Training approach Our first round pilot projects used the standard group tools. Our observations and complaints on these were that they disaggregate collaboration spaces from related learning materials in the site; usability is also very poor for both students and instructors especially with large student numbers e.g. locating your group and setting them up as well as clunky tools such as the file exchange. When the new tools were introduced, we wanted to make a shift in thinking about supporting collaborative working and students’ interactions within a module site. We focussed on our Groups & Group Tools workshop which explores what’s different about working collaboratively online, group formation and participation strategies, group process and peer assessment, tool selection and set-up so that tutors can assign group membership, set up group spaces and deploy tools by the end of the session.

Rethinking collaborative spaces ‘Background’ group membership without standard group tools switched on Folders to create group spaces into which wikis, blogs, discussion forums and content are deployed Adaptive release based on group membership if private collaborative spaces are desired We introduced the following approach in light of the new tools: - group membership without any standard group tools being switched on; - use of folders to create group spaces into which wikis, blogs, discussion forums and content can be deployed; and - finally adaptive release based on group membership to create private group spaces if chosen. Without any real examples that used the wiki and blogs we mocked up a group work site illustrating this principle – same project set up with open and private group spaces. Any guidance relevant to all groups sits up front before adaptive release is applied at the folder level. For ease of set-up one group space was created and then copied (with adaptive release and wiki/blog memberships then appropriately added to the copies).

Collaborative group work Our tutors’ aims: Collaborative writing of case study reports Collaborative glossaries Shared reflective journals with commentary Co-authored ongoing resources to develop from cohort to cohort Enhance small group teaching within large cohorts e.g. 200 students While these are expressed as products, the tutors were also aware of the importance of group process, so transparency and the ability to provide feedback on progress were important.

Single wiki for the whole module. Students can edit the wiki. Interaction matrix Wiki (Teams) interaction options Note that an instructor always has view, edit and commenting privileges to all wikis (when on). No Groups Private Groups Open Groups Single wiki for the whole module. Students can edit the wiki. Commenting can be on/off. Instructor Single wiki for the whole module that only an instructor can edit. Students can view the wiki but not make changes. Commenting can be on/off. Each group has a wiki that only an instructor can edit. Commenting can be on/off. Other groups can’t view the wiki. Each group has a wiki that only an instructor can edit. All students can view the wiki. Commenting can be on/off. Groups Single wiki for the whole module. Students can edit the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit and view the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit the wiki. All students can view the wiki. Commenting can be on/off. We started to realise that the new tools’ flexibility also meant an unprecedented level of complexity in the set-up, so we turned to Andrew Fisher’s wiki interaction matrix (which he shared at ALT-C in September 2006) and adapted it in the first instance for us - to better understand the range of interaction models possible - and then communicate this clearly to our instructors. We worked with instructors then, diagnosing how their planned activities would translate into not just the tool configuration but also the site structure in terms of folder hierarchy etc. Let’s take a look at our first example. Relating it to the interaction matrix you can see it falls into the Single wiki for the whole module/Students can edit the wiki model. Students Each student has their own wiki that only they can edit. Students can only view their own wiki. Commenting can be on/off (for instructor and student to use). Each student has their own wiki that only the student can edit. Students in the same group can view each other’s wiki. Commenting can be on/off. Each student has their own wiki that only they can edit. All students can view the wiki. Commenting can be on/off. Adapted from Andrew Fisher, Barking College, 2006

New Media & Society Module New Media and Society module example. The tutor used not only group wikis for collaborative projects (Workshop Wikis from the menu) but also both a course level wiki and blog for the whole cohort. The screen dumps on this slide are explained (and build up) as follows: Build 1 – The New Media and Society module home page. We click the “Mediapedia” option from the left menu to enter the course level wiki (“Mediapedia” is a play on “wikipedia”). The idea here is for the whole cohort to collaboratively build out a glossary for the module. Build 2 – The home-page of the course level wiki. The tutor set up the wiki home page by adding many terms into an alphabetised list. Students were asked to select a word(s), link the word to a new page in the wiki and then author a definition for the term at this new page. Build 3 – The “Internet” definition page in the course level wiki. This shows the student authored definition for “Internet” (the students name has been removed). Build 4 – The page history screen for the home page of “Mediapedia”. On this screen dump you can see that the glossary home-page is up to its 74th revision (by the time this presentation was completed it had gone up to version 90). Build 5 – The course level blog This screen dump shows some entries in the course level blog and also how students discussed their “Mediapedia” work in this context as well. Incidentally the course tutor set-up multiple ways of communicating and let the students decide how they wanted to communicate in the module. They mutually chose to use the shared course level blog in which there are near two hundred entries for a cohort of about 50 students.

Only students in that group can edit the wiki. Interaction matrix Wiki (Teams) interaction options Note that an instructor always has view, edit and commenting privileges to all wikis (when on). No Groups Private Groups Open Groups Single wiki per group. Only students in that group can edit the wiki. All students can view the wiki. Commenting can be on/off. Instructor Single wiki for the whole module that only an instructor can edit. Students can view the wiki but not make changes. Commenting can be on/off. Each group has a wiki that only an instructor can edit. Commenting can be on/off. Other groups can’t view the wiki. Each group has a wiki that only an instructor can edit. All students can view the wiki. Commenting can be on/off. Groups Single wiki for the whole module. Students can edit the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit and view the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit the wiki. All students can view the wiki. Commenting can be on/off. Our second example uses the Single wiki per group. Only students in that group can edit the wiki. All students can view the wikis. model. Students Each student has their own wiki that only they can edit. Students can only view their own wiki. Commenting can be on/off (for instructor and student to use). Each student has their own wiki that only the student can edit. Students in the same group can view each other’s wiki. Commenting can be on/off. Each student has their own wiki that only they can edit. All students can view the wiki. Commenting can be on/off. Adapted from Andrew Fisher, Barking College, 2006

KVE Module Core knowledge, values and engagement skills (KVE) module example. The tutor used group wikis for a series of collaboratively developed topics each of which could feature in the final exam. This meant that, even if a student wasn’t a contributor to a topic, it was in their interest to view (and comment on) all the other wikis. The screen dumps on this slide are explained (and build up) as follows: Build 1 – The KVE module home page. We click the “Wikis” option from the left menu to enter the wikis area. Build 2 – The “Wikis” content area. All the wikis are transparently visible to everyone on the course. Build 3 – The “Creativity in Mental Health” wiki home page. Here you can see what the group have authored on the home page of their wiki. Build 4 – The page history screen for the home page of “Creativity in Mental Health”. On this screen dump you can see that the glossary home-page is up to its 14th revision (for a group comprising of 4 people). Build 5 – Control Panel screen We click the “Assess/Export Teams Site” option for an overview of participation levels. Build 6 – A list of wikis to view participation details for. We click the “Creativity in Mental Health” link to see its participation levels. Build 7 – The participation table. Table showing the four students collaborating on the wiki and how they are contributing to the development.

Only students in that group can edit and view the wiki. Interaction matrix Wiki (Teams) interaction options Single wiki per group. Only students in that group can edit and view the wiki. Commenting can be on/off. Note that an instructor always has view, edit and commenting privileges to all wikis (when on). No Groups Private Groups Open Groups Instructor Single wiki for the whole module that only an instructor can edit. Students can view the wiki but not make changes. Commenting can be on/off. Each group has a wiki that only an instructor can edit. Commenting can be on/off. Other groups can’t view the wiki. Each group has a wiki that only an instructor can edit. All students can view the wiki. Commenting can be on/off. Groups Single wiki for the whole module. Students can edit the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit and view the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit the wiki. All students can view the wiki. Commenting can be on/off. Our third example uses the Single wiki per group. Only students in that group can edit and view the wiki. model. Students Each student has their own wiki that only they can edit. Students can only view their own wiki. Commenting can be on/off (for instructor and student to use). Each student has their own wiki that only the student can edit. Students in the same group can view each other’s wiki. Commenting can be on/off. Each student has their own wiki that only they can edit. All students can view the wiki. Commenting can be on/off. Adapted from Andrew Fisher, Barking College, 2006

Making History Module Making History module example. The tutor used group wikis for a series of collaboratively developed reports. This was the most complex set-up for a module in that there were around 200 students enrolled. The cohort were divided into groups of 16 (Discussion Groups) and then into sub groups of 4 (Study Groups). All members of a discussion group needed to be able to view the work developed in the sub study groups. Members of other discussion groups, however, were not. The screen dumps on this slide are explained (and build up) as follows: Build 1 – The Making History home page. We click the “Group Work” option from the left menu to enter the collaborative working areas. Build 2 – The “Group Work” content area. You can see here that none of the group folders are visible because they are adaptively released using group membership (of groups set up in the background). The only material visible to all students are the example sites. Build 3 – The “Group Work” content area in “Edit View”. Here you can see all the Discussion Group folders with their adaptive release notes showing. When students come in to this area they will only see one folder, the one they are meant to be working inside. Build 4 – Inside a “Discussion Group” folder. Here we can see the sub-division of the group in the form of four Study Group folders. Build 5 – Inside a “Study Group” folder. Once inside a Study Group folder the structure then changes to providing the Group with separate spaces for developing the key projects expected of them. In this case four folders labelled by the project title and the week of term they are meant to be working on it. Build 6 – Inside one of the weekly project folders. You can see here that resources relating to the project have been placed in the project space along with the wiki that is intended for developing the report online. Build 7 – The home page of the project wiki. Here we can see the top level of the wiki (in line with how the examples suggested it should be structured – home page links to the individual areas of the report). Build 8 – A report page of the project wiki. This screen shows a fully edited page of the wiki. Build 9 – Control Panel screen. Here we click the control panel to assess wiki participation. Build 10 – Wiki participation screen. Here we you can see a break down of the participation from the 3 students of the Study Group.

Single wiki for the whole module that only an instructor can edit. Interaction matrix Wiki (Teams) interaction options Note that an instructor always has view, edit and commenting privileges to all wikis (when on). No Groups Private Groups Open Groups Instructor Single wiki for the whole module that only an instructor can edit. Students can view the wiki but not make changes. Commenting can be on/off. Each group has a wiki that only an instructor can edit. Commenting can be on/off. Other groups can’t view the wiki. Each group has a wiki that only an instructor can edit. All students can view the wiki. Commenting can be on/off. Single wiki for the whole module that only an instructor can edit. Students can view the wiki but not make changes. Commenting can be on/off. Groups Single wiki for the whole module. Students can edit the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit and view the wiki. Commenting can be on/off. Single wiki per group. Only students in that group can edit the wiki. All students can view the wiki. Commenting can be on/off. Our third example uses the Single wiki for the whole module that only an instructor can edit. Students can view the wiki but not make changes. model. Students Each student has their own wiki that only they can edit. Students can only view their own wiki. Commenting can be on/off (for instructor and student to use). Each student has their own wiki that only the student can edit. Students in the same group can view each other’s wiki. Commenting can be on/off. Each student has their own wiki that only they can edit. All students can view the wiki. Commenting can be on/off. Adapted from Andrew Fisher, Barking College, 2006

Evolutionary Ecology Module Evolutionary Ecology module example. The tutor is using group wikis for collaborative projects (“Group Work Areas” from the menu) but also the course level wiki as a read only “text book” style resource. To achieve this the tutor validates and copies the best group work into the appropriate areas of the pre-structured course level wiki. Students can neither edit nor comment on the course level wiki and the tutor intends to continue to use it as a “rolling” resource. The screen dumps on this slide are explained (and build up) as follows: Build 1 – Evolutionary Ecology module home page. We click the “Online Text Book” option from the left menu to enter the course level wiki. Build 2 – Home page of the course level wiki displaying the main topics that are covered with the course. We click one of the options in the wiki home page (Speciation) to see the “chapters” for this topic. Build 3 – Topic chapters for Speciation. Here we can see the links to the actual content pages for Speciation.

Set-up and configuration Evolutionary Ecology This slide is interactive Clicking on the boxes of the matrix will take you to the set-up explanation for each of the previously shown examples as labelled on the slide. Note that the slides that these hot-spots are linked to are hidden and won’t be shown in a normal run through of the presentation. Click away from the boxes to move on to the next slide. Making History New Media & Society KVE Module

Some tips & tricks Key set-up options Making it easier for tutors This slide is interactive Clicking on the small screen-shots of the matrix will take you to the set-up explanation tip as labelled on the slide. Note that the slides that these hot-spots are linked to are hidden and won’t be shown in a normal run through of the presentation. Click away from the small screen-shots to move on to the next slide.

Benefits and challenges Enormous flexibility for collaboration Deploy in context of learning materials Transparency : participation & versions Support both group process & product Support peer review & feedback Set-up complexity Instructor learning curve Student motivation & participation Appropriate student induction is critical Too easy to deploy? i.e. students overloaded This is a very brief list of some of the key benefits and challenges to use of Wiki and Blog tools for learning and teaching. The live session ended in a Q & A session of about 10 minutes in length. Discussion

End of presentation Game over.