I’ve demoed federated wiki to a lot of people now, facilitated two online happenings with it, and I am in the process of teaching my second college class with it. And I would say getting started is the hardest part with it. The big problem is that for federated wiki to act like a wiki we have to pull sites together. But the actions required of individuals to pull sites together themselves are pretty advanced. For those who work in student blogging with course hubs you can imagine the problem as this: what if every student had to build their own RSS aggregator? In the first 60 minutes of the course?
The ability to build aggregation and activity engines easily is a key strength of federated wiki, especially with the new Roster and Activity plugins. The ability to hand code, via a simple syntax, your own Activity Feed selection formula still blows my mind. But it’s still not what I want to show pre-service teachers on day one.
So I spent my weekends during the end of the summer trying to make the process easier using some basic HTML and Javascript. What I settled on was a two pronged approach.
First I made a plain HTML aggregator and viewer, something that I’ve been calling wikity. In the past I’ve used a federated wiki site as the hub of the class, but jumping in-between federated wiki sites early on gets people confused as to where they are and bad things happen. For example, I might have a “Current Assignments” page there, and they will fork it by mistake, and now they have to always remember to check “twins” to find assignments. Having the hub be read-only with direct links to specific pages makes that easier.
The second ploy was to create a system in which would pre-create a whole bunch of empty sites with generic names, already connected in a roster and let the students claim one of these pre-connected sites. That saved us from the problem where the students needed to create the sites, we needed to compile them into a roster, and then need to feed that back out to the students. In the new system you’re connected to the class instantly. The site name problem also deals with another element, which is that when students create sites they often are not sure if they are going to want their name in the URL. This is especially true of public school teachers, whose online presence is often under a ridiculous level of scrutiny. In this claim process, the URL is arbitrary, but they can add or subtract their name from the site at will.
I think I run the class in such a way that they will WANT to associate their name with the result, but they can’t know that on day one.
In any case, here is the process. The actual claim process is the first 90 seconds of the video. The rest covers what you have to do when you switch computers, and we throw in a little sped-up editing for good measure.