My post earlier today (here) has attracted some interest: 'wikis and teaching' is a troubled partnership, but it's being attempted by many ... Doing Something Different (Doug Miller) links discussion of the "problems" experienced by some of us with wikis to an earlier posting of his about Tinderbox:
Most of the criticism I read of Tinderbox seems to me to arise from people approaching it with preconceived ideas about how it "should" work, and not being able to shed these preconceptions enough to understand how it actually does work. Nor is this problem limited to Tinderbox; I read similar remarks related to wikis, news readers - hell, it wasn't all that long ago that I had discussions of a similar nature with people concerning web browsers.
IrishEyes (Bernie Goldbach) trackbacked to my earlier post and has this to say:
After immersing in the way-Alpha Mobhaile, I think it's actually a wiki flogged as community webware. Most of its early adopters cannot spell either "mobhaile" or "wiki" and they certainly won't be ready for the wiki approach to information management. As David Smith notes, this is not an unusual problem. ... Another part of the metric is in the uptake and follow-on use and that metric will be challenged by people who cannot figure out wikis. Wikis are inherently difficult hard work. To be used correctly, they need to be taught. The implementers need to understand how to use them.
I can quite see how wikis can be 'paradigm busting software' (Doug Miller's term for Tinderbox). Franz Dill, writing at Future Now, has a fine short post today about wikis in the workplace:
The blog is like an online newspaper, it's serial and you may expect to be able to only scan the headlines each day. Of course you can use a blog like an archive, since all blog software has a search. I do that, but the readers of the blog sometimes don't grasp the wealth of information a blog contains. In contrast, a Wiki does not look serial. If organized reasonably it looks like a reference work. So it looks like an archive and users figure this out right away. It does suffer from a critical mass problem, if there is not enough there, users just won't think of it when they need it. To create a critical mass, you need lots of contributors. If your Wiki is public you can get enough enthusiasts to provide content. Within a corporation it's harder to get enough people to invest the time to get the Wiki to a state where it's a viable resource. I am optimistic about the use of Wikis in the workplace, and look forward to working with them in and outside of the corporation.
Even in praising wikis, then, Franz Dill recognises some of the problems — and in teaching (UK secondary; 13–18) these can seem pretty daunting. This autumn, we will be trialling wiki/wiki-based software with classes, but I have found that even Basecamp, a fairly straightforward collaborative software environment, just isn't given the time by (most) students that it requires if it is to yield the greatest benefit. (It tends to end up as a teacher-directed portal for pushing out information and as a node of online study references. None of this is bad, but I'd had greater hopes for it than this.)
It comes back to what we want IT to be about in schools and how we prepare pupils for a world in which electronically conducted/assisted collaborative activities (something that wikis are so good at) will be part of their adult working environment. Of course, wikis won't work if just dropped in to classrooms and the worst thing would be if we end up turning them into electronic work-sheets. Many2Many quoted Kairosnews:
Each week, I prepared the material, each week I contrived some kind of in-class activity to let people ‘interact’. But as I mentioned before, I was merely creating fill-in-the-blanks exercises … I realize now, that to get to the level of which I was aiming, in terms of communal constructivism, you need to let the participants identify their own blanks.
The challenge of wikis, of any paradigm busting software, is one which must necessarily send us back to re-examine the ways in which we work. The challenge is bigger than "just" IT, but IT departments have to bite this bullet. As I noted before, the IT priesthood (in schools, in business — anywhere) has other interests ... This earlier posting concerned something Ross Mayfield had found in eWeek, and it's only fitting to end by linking to Ross Mayfield's post today with its hilarious photo of a meaningless barrier. Ross's five points for software design: don't create false barriers; trust users to create (my addition: and invest in the training and re-thinking needed to give teachers and young people the skills and confidence to be creative with these tools); keep it simple; recognise that the old notion of authority is displaced by the new tools; recognise that what matters is not ticking off the number of filled blanks.
