Nov 21, 2004
Emerging Technology 2005
#author hoffmanTim's and my proposal for the 2005 O'Reilly Emerging Technology Conference, "Remixing Wikis for Elementary School Classrooms: Instiki, wifi, and Rendezvous," was accepted. The conference is in San Diego, March 14 - 17. More to follow...
Jul 31, 2004
Your Classroom Wiki
One cool thing that you could easily do with a Instiki wiki is use it to run a wiki in your classroom, off the teacher's desktop or laptop (can you run Ruby on a Pocket PC? It'll work off your phone in a few years...). Anyhow, without bothering your school or district sys admin. Of course, you can do this with any open source wiki or weblog, but Instiki is an unusually simple and (so far) well behaved server.
All you'd need to do is launch Instiki at the beginning of class and perhaps note the IP address of your computer to allow your students to access the wiki in the classroom. If Instiki's server supported Rendezvous (soon to be known as OpenTalk) it would be even easier, if everyone is using a Mac, because then "Mr. Hoffman's Wiki" would just show up automatically on the student's Rendezvous bookmarks in Safari. Even without Rendezvous trickery, this would be a very good way to experiment.
I also noticed that Instiki supports locking in editing, that is, if one person is editing the page, it warns you if someone is editing it at the same time, which would lead to someone losing their changes, at least temporarily. So that's a pretty important feature, and I'm not sure how many of the dozens of wiki's floating around actually support it. If you're thinking of using a wiki at school you should look for one that does locking.
Jun 02, 2004
Wiki Design Principles
Oliver Wrede points to an unusually perceptive "using a wiki in my college classroom" postmortem by mphillip(?), who helpfully links back to Ward Cunningham's 11 wiki design principles, which provide a good framing device for talking about when and why one would use a wiki. I've quoted them below, with some commentary.
Open - Should a page be found to be incomplete or poorly organized, any reader can edit it as they see fit.
It is interesting that Cunningham includes a specific circumstances under which someone else's page should be edited. It reinforces the idea that the reader's editing power has to be bound by clear social practices. In the classroom, these practices have to be created and taught, which is not a bad thing, but it will take some time, effort, and a reasonably sophisticated understanding of the medium by the teacher.
Incremental - Pages can cite other pages, including pages that have not been written yet.
This is the big win for class oriented work. Sustained ongoing growth rather than constructing a final product. Weblogs are incremental, but not as interlinked; documents in a content management system tend to stand alone.
Organic - The structure and text content of the site is open to editing and evolution.
Actively restructuring a growing wiki is powerful and essential. But while it is far easier to reorganize a wiki than, say, a web site in a hierarchical file system, it still takes a certain kind of mind to do this kind of work. Your average 10th grade English teacher still probably doesn't feel up to untangling a class wiki. In practice, staying within the limitations of weblogs might be more practical.
Mundane - A small number of (irregular) text conventions will provide access to the most useful page markup.
Lord knows we need more applications in our classrooms that strive to be mundane. Just remember that those text conventions are probably harder to use than you think. When they don't work the way you expect, they're pretty opaque.
Universal - The mechanisms of editing and organizing are the same as those of writing so that any writer is automatically an editor and organizer.
This is something we should all be striving for in our classrooms.
Overt - The formatted (and printed) output will suggest the input required to reproduce it.
In practice, this only holds up for the simplest cases. Luckily 80% of your content will probably be simple. Unfortunately, teachers and students tend to want colors, sounds, etc.
Unified - Page names will be drawn from a flat space so that no additional context is required to interpret them.
This is extremely important, as most people don't know what a namespace is and can't easily wrap their brain around a heirarchy.
Precise - Pages will be titled with sufficient precision to avoid most name clashes, typically by forming noun phrases.
This convention must be taught.
Tolerant - Interpretable (even if undesirable) behavior is preferred to error messages.
Yes please. It is hard for wiki software to follow this rule for formatting problems.
Observable - Activity within the site can be watched and reviewed by any other visitor to the site.
Some wikis do this better than others. Use one that does it well. I have a recent wiki changes box on the front page of our school site.
Convergent - Duplication can be discouraged or removed by finding and citing similar or related content.
I don't know how this would work.
If that read as a point by point debunking of the utility of wiki's, it certainly wasn't meant to be. My message is that creating a wiki in a classroom will require a lot of active teaching. It won't just happen, and it won't be simple. It will probably be worth it, though.
And you can always bastardize wiki software and do useful things with it despite violating many of the principles above.
May 30, 2004
Oh Lord, How I Hate Reading Educational Research
The Weblogs in Higher Ed blog points to this paper in The International Review of Research in Open and Distance Learning called "Educational Wikis: features and selection criteria." It isn't a very useful article, and they make a hash of defining wikis. They start out ok:
According to Leuf and Cunningham (2001), creators of the original wiki concept, “a wiki is a freely expandable collection of interlinked webpages, a hypertext system for storing and modifying information – a database, where each page is easily edited by any user with a forms-capable Web browser client” (p. 14). Content can be directly linked to that found in other wikis (interwiki) and in Web documents.
Browser-based access means that neither special software nor a third-party webmaster is needed to post content. Content is posted immediately, eliminating the need for distribution with the associated risk of virus transmission. Participants can be notified about new content, and they review only new content. Low graphic use results in pages that load quickly. Access is flexible – all that is needed is a computer with a browser and Internet connection. Modular construction means that wikis can be simple or complex to meet user needs and skill levels.
But then go off the rails:
Mattison (2003) states that “a wiki can be a blog, but a blog does not have to be a wiki.” Wiki use is often compared with blogging. Blogs, or weblogs, are chronological online journals written mainly by individuals (although group blogs exist), to which readers post comments.
The main differences between the two approaches relate to notification of new content, editing format, and structure. Blogs typically use RSS (Really Simple Syndication) feeds to sort information and alert users to new content. Wikis usually use email notification. For students, an advantage of blogs is the use of ‘What You See Is What You Get’ (WYSIWYG) editing. Wikis usually employ a simplified markup formatting (although there are also WYSIWYG wikis). A disadvantage of using markup is the lack of standardization across various wiki programs (Mattison, 2003).
The essential difference between a weblog and a wiki is the presence or absence of collaborative editing. If other people can change my words through their browser, then it is more or less a wiki. If they can't, it isn't. The distinctions they draw about notification, editing, and even structure are artifacts of specific implementations and are likely to become even less significant going forward.
Blogs are arranged chronologically, while wiki structure can be based on hierarchical subject divisions through new page creation and internal and external hyperlinking. These features make wikis highly suitable for educational use. Blogs are more structured; wikis are more flexible. Most wikis include a search feature; many blogs do not. Once a blog addition is posted, it often cannot be edited. User communities are found at both blog and wiki sites.
Most blogs are arranged chronologically and by some kind of subject divisions. Wiki software doesn't generally enforce hierarchical divisions. More commonly the software allows a soup of interconnected pages, which may end up looking like a hierarchy if that's how the user's shape their work. That's what makes it "flexible." Again, the search feature is just an artifact of some current implementations, not really significant. And I've never seen a blogging application that doesn't allow you to edit your posts after publishing them.
Since the authors lose track of the essential feature of wikis, collaborative editing, the rest of their discussion of specific features comes unhinged. The question should be to be "is collaborative editing of web content a useful process in distance education?" Not, "what features do we need in our wikis?" If we don't want collaborative editing, then the question becomes "what features do we need in our content management system?"
May 12, 2004
Is EditMe a Wiki?
James Farmer is shopping for a wiki and finds EditMe to be a promising choice. I'd agree that it looks like a well designed application, but it its wiki-nature is rather weak. It has a WISYWIG editor, including sophistocated features like table layout, but it isn't obvious how you can create links that will automatically generate new pages, as you often do by using CamelCaps to form WikiWords. It is possible, but I had to drill into the documentation to figure it out, which sorta undermines that intuitive thing.
I just wonder if more "sophisticated" wikis are going to become progressively less wiki-like.