Twenty-Three Things: Activity 14 — Wikis

I’ve challenged some of my colleagues to take the 23 Things challenge to become more invested in online learning this summer. This website includes a 10-week game plan for learning some online learning and presenting methods that are useful for teachers, and that are appropriate activities for the age group we teach.  There are other 23 Things lists out there, I know, but this is the one that we’ve chosen to work with, and that I’ve decided to complete.

The previous entries in this series are here:

  1. Getting Started
  2. Discovery
  3. Setting Up a Blog
  4. Starting with Flickr
  5. Find some Flickr Toys and Tools
  6. Blog about the role of tech in your classroom
  7. Initial experiment with RSS Readers
  8. RSS Readers continued
  9. Cloud Computing
  10. Web 2.0 Activty
  11. YouTube & Video
  12. Podcasts
  13. eBooks

Activity 14: Wikis

I’ve actually used wikis in the classroom at my old school.  That was sort of a disaster. An interesting disaster, but a disaster nonetheless.

First of all, I’d spent the entire summer learning to use MediaWiki as a power user.  MediaWiki is the software that powers Wikipedia.  WHich is pretty cool. Then it turned out that my school’s IT administrator didn’t want to learn MediaWiki’s admin-side tools, and so I was stuck with admin power on Apple’s own WikiServer.  So I had all these power-user skills for a platform I couldn’t use, and suddenly I had admin rights for a platform I didn’t know how to use. (and it also turned out that using our server for a wiki during classtime hours strained our network capacity, even when our classroom was right next door to the server and had the shortest cable distances of anyone in the school.)

Talk to your IT people.  Know what you’re going to be working with.  It’s important.

More than anything else, though, having a wiki brought up the issue of ownership.  Kids want to own things, whether it’s the contents of their pencil cases or a page on the World Wide Web.  (Remember when we used to call it the World Wide Web, and not just the Net??)  And on a Wiki, you just don’t own your own content the way you do on a blog.  (Stephen Downes is the only person who’s ever written a guest post for this blog, back in 2011… and no, you’re probably not next.  Stephen quite correctly called out my bad math, but also my failure to understand when my error was waaaaay off the mark. So, no, most people don’t get to write guest posts here.  Unless you’re Peregrin Wildoak, or John Michael Greer, and maybe not even then…)

So imagine this… here’s a bunch of kids, being introduced to the idea of wikis, and trying to write pages — personal pages for themselves, biography pages for people from their history books, event pages for battles or other crises from their textbook, pages about inventions, general pages about civilizations… and their classmates are vandalizing these pages.  It doesn’t matter that we can all look at the history and see WHICH student vandalized whose page, because it turns out that they all had very sloppy ideas about what constituted safe username passwords; and they were hacking one another’s accounts.  So I was getting angry at the wrong kids. All the time.

It also turned out that, due to the way the server was set up, that students couldn’t get at their wiki pages during study halls all the time, or from their dormitory rooms (this is when I taught at a boarding school).  They didn’t own their data on the wiki; they were responsible for updating it as part of their homework… but they couldn’t always access it while doing homework.  So they were responsible for having command of data that, as students, they didn’t have sufficient real-world access privileges to use.

These are solvable problems. What wasn’t solvable was that ONLY my students had access to the wiki “for security reasons” as both editors and readers; and most of them just didn’t care enough about the content that only I and they would see to produce their best work. They didn’t necessarily want to be great writers, and mostly they wanted to throw OK work up on the wiki and be done with it.  MEanwhile, I wanted to use the wiki tools to edit and comment on their work, and help them get better.  So, any time they put work up on it, I’d leap on it, edit it, add comments and ideas for improvement… and thus generated more work for them that they didn’t want to do, but that I (stupidly) penalized them for not doing.

So private wikis suffer from the Creepy Treehouse problem:

I’d never heard of the phrase, which seems to be a good two years old, and refers to a nexus of problems: the attempts to duplicate social online spaces in an institutionally constrained format (hi, Blackboard!); the requirement, enforced by someone in authority, that others interact socially with them (“follow me on Twitter / friend me on Facebook); and the affect that these practices give off.

Official ProfHacker undergrad Alex Jarvis and I have been talking about this problem today, and he pointed out that “social apps are going to reek of Creepy Treehouse,” and one in particular: If you’re requiring your students interact with you on Facebook, “you aren’t building a creepy treehouse — you are driving a white van into the school parking lot.”

— Jason Jones, ProfHacker

So there you go.  Wikis, particularly private or locked wikis, reek of creepy treehouse problem.  So does organizing Facebook groups for your students to work together on assignments.  There are solutions to these, but of course the problem is one of authority: anything that eases learning for students that nonetheless starts out as required behavior, may in turn generate more work for the students beyond what they’re already doing for your class.  My overall impression is that Wikis are wonderful, but it’s better to point students at a free Wiki site, and let them build their own, than try to control (and take credit for) the Wiki that you (force them to) build.

Related to this, of course, is a third problem.  An academic wiki winds up looking like an encyclopedia. Like, in fact, a bad version of Wikipedia — not peer-edited and peer-reviewed, constructed by a group of writers drawn from a limited economic and social background (same town, same school system) with roughly parallel levels of experience (all in seventh grade and thus about the same age).  And Wikipedia is already that thing you’re trying to build, but better.  Why rebuild it?

On the other hand, you can play an alphabetarium game with a Wiki:

  1. Each player (students + teachers) agrees on a Theme.
  2. Each player has a week to write an entry for “A”
  3. Each player has to link their “A” entry to an existing “A” entry and an entry they think the Alphabetarium will eventually need in another letter.
  4. The following week, everyone writes an entry for “B”.
  5. The entries previously generated for “B” in step 3, must be written too.
  6. Each “B” entry has to link to an existing “A” or “B” entry, and also to a likely entry later in the alphabet.
  7. Players can call dibs on writing specific entries for later in the game.
  8. Week 3, everybody writes their “C” entries… again, linking to earlier entries, and linking to future entries.
  9. Week 4, Week 5… Week 25, 26, always the same. Write an entry that links back to earlier ones, and to later ones.  Eventually, you run out of alphabet, and the game finishes.  But at least in theory, everyone has done some reading of everyone else’s entries, and everyone has had a chance to direct the thread of the game.

It’s not a bad little game.  I’ve written some interesting science fiction and fantasy world encyclopedias this way, and I’ve enjoyed the process immensely.  One can add in additional requirements like adding pictures and maps; a lot depends on what you’re trying to do… But, of course, the whole thing STILL looks like an encyclopedia.

Maybe that’s the point. Encyclopedias and wikis are firmly interlinked in people’s minds. Are there other uses for Wikis besides encyclopedias? I haven’t found one yet.

11 comments

  1. I haven’t made good use of a wiki for this but they can be useful for other kinds of references besides encyclopedias, like a procedural manual. Say I’m documenting how to set up OS X Server in our environment, the page could include a section on configuring SSH but since that’s something I do on other kinds of machines, I’d rather make a page just about that then link to it. The OS X Server also needs to use a web proxy but again, other systems need that too so I can make a page for the web proxy details. You probably still want one more “table of contents” style pages for traditional navigation but being able to easily create and link to new pages is helpful.

    As for non-reference uses, a wiki could be good for writing hypertext fiction, either by a single author or as a collaborative work.

    • As far as hypertext fiction goes, I’ve done that. Some friends of mine wrote an abcedarium about a medieval-like fantasy world once which was pretty cool. Were you in on that?

      I like the idea of using it for documentation, too. Maybe I should try setting one up for the Design Lab at my school.

      • Nope, I was not.

        The web is clearly a very flexible and available way to get at documentation and having the content be web-native as opposed to in linked files makes it even more so. Better wiki features like fast, robust search, WYSIWYG editing, and integration with existing authentication (so you’re not anonymous but don’t have to create yet another account). At work, my group already had a wiki with none of those features so it really wasn’t used.

        The wiki is less good when you want to mix documentation you write with existing manual/user guide files and software installers. Uploading such files to the wiki and managing them so you get rid of old versions as new ones come out is more of a hassle than having a folder on a file server with installers, manual PDFs, and your own documentation all together. Oh, and I haven’t seen a wiki that makes it really easy to sprinkle images alongside the text.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.