A little while ago Trebor Scholz suggested that I should respond to a post of his on the Institute for Distributed Creativity mailing-list, about using wikis and blogs in teaching. I finally got around to this yesterday, and thought I might post it up here as well. This also refers back to the interview Trebor did with me last year, and to the Large Teaching & Learning Grant project which I co-direct at QUT (see Blogs and Wikis in Teaching at QUT for some more information). Any comments welcome!
Trebor asked me to add a few reflections on blogs and wikis in teaching, so here I am… By way of background, I’m co-coordinating a largeish project here at QUT which is trialling blog and wiki systems in various teaching environments (large to small units across various disciplines); we’re using Drupal for the blog system and MediaWiki for wikis, with a potential to move to Confluence (as a significantly more powerful, but proprietary, wiki solution) some time soon. I’d love to point you to the sites we’ve set up, but right now they’re mainly available only internally, so it won’t make much sense, I’m afraid.
There are a few things which have been mentioned in the discussion so far, and which I’d like to add some comments on:
1. Blogs vs. wikis:
I don’t think the question of which one is ‘better’ is particularly relevant, or useful. Both technologies can be useful tools in different teaching contexts, and it’s simply important to make an informed choice as to which may be more appropriate for any one case (in in which configuration). I’m sure it’s no news to anyone that the key difference between them is usually the underlying organisation of information (temporal in blogs, spatial in wikis), and the answer to which one should be used can often be found right there already. So, blogs can be useful for ongoing personal/group reflection, or for the incremental development of skills / gathering of information / provision of feedback; wikis can be useful for compiling information and ideas in an ad hoc form, with informational structures emerging as information is being compiled.
2. Levels of openness:
This is something we’ve struggled with (in the case of both blogs and wikis) as well. Especially with large groups, total access to all information for all visitors can be confusing («how do I find students in my unit»; «why is this person replying to me») and intimidating («I don’t want my personal reflections to be visible to all visitors»); the more competitive students are also reluctant to post information to their blogs for fear that lazier students will appropriate their work for their own assignments.
Currently we’re trialling an extended permissions system within Drupal, organised through its in-built taxonomy functions: students are asked to tag posts relating to specific units with those unit codes, and only current students within those units can access that content. Additionally, there are also generic ‘public’ (available to all visitors) and ‘private’ (available only to the originating user) tags, as well as a number of other tags which can be limited to other groupings (staff, interest groups, etc.). It’s also possible to apply multiple tags, of course — this could be used to make a unit-specific post available to all (but we’re still working out the details).
Yes, this does to some extent go against the spirit of openness in the overall blogosphere, but it’s proven necessary to help collate content that relates to specific units or groups, and eases students into exposing their thoughts and work to a wider audience.
In the case of our wikis, a similar approach applies, but here it’s usually individual unit wikis which are either entirely internal, entirely open (but editable only by authorised users, or use a two-step process (internal during the editing phase, then published to the wider Web). When we move to Confluence, we will be able to apply more specific permissions which will also help. And again, the point here can’t simply be a doctrine of openness at all cost, but rather it’s important to use the available tols as fits the teaching situation.
3. Group collaboration:
Given the ongoing development work in the blog environment, it’s too early to say much here, so I’ll focus on our experiences with wikis: success here has been very dependent on the size of groups. We’ve had considerable success with small to medium groups collaborating in developing wiki knowledge bases: some colleagues have used wikis for example in language units (German and French, respectively, with the wikis also using these as interface languages so that they become immersive language experiences), and this has worked very well. One exercise for language students was to build/update a wiki on Berlin as a place of commerce, for example, and this has been very successful — also for the staff member teaching the unit, who rapidly progressed from virtually no experience with wikis to using them very expertly.
My own experience in developing an online encyclopedia of new media terms and concepts (which I also discussed in my paper with Sal Humphreys for WikiSym 2005 [PDF]), and in my interview with Trebor one year ago) has had mixed results so far, and I’m learning more about the level of instruction students need for this purpose — in earlier semesters I’ve allowed students a great deal of freedom in choosing topics for their entries, and this has produced a wide range of quality in the content produced; in the future I’ll be more rescriptive in what should be covered in the encyclopedia. The point here is that we don’t have the luxury of a very wide contributor base, contrary to the Wikipedia which can cover some fairly esoteric topics without losing coverage of key topics — in a unit of 150 students, run once a year, we need to make sure that their work is covering the key topics before it moves on to less crucial ones (for example, at present we have an entry on ‘cultural imperialism’, but no entry for ’email’ — that’s not acceptable for our purposes).
Another problem is the maintenance of content across the semesters. For some of our wikis, that’s not a problem — where they’re used simply as a collaborative authoring environment, they can be wiped at the start of each semester. But where later semesters build on what’s already there, students must rapidly become familiar with what’s already there, learn how to improve on or expand it, and also continue already established frameworks (naming and formatting conventions, taxonomies, etc.) — that can be a tough ask in a short timeframe. As Trebor suggests, the use of stricter content templates and other guidelines might help here, and I’m looking forward to trialling Confluence in this regard, too…
Anyway, that’s about where we’re up to. Sorry about the braindump here — look forward to any comments.