The WLAN here at the WikiSym seems to be completly broken now (yesterday it only was slow) so we're back to good ol' cable
On the hotel I have about 9 different wireless nets around but none of them is strong or open enough to use it reliable. So this is my report for the second part of yesterday, written in a very tired mood, so excuse any mistakes
The main topic for the panel events in the afternoon was using Wikis in educational environments. There were several talks I can't fully reproduce here anymore but there where some interesting keypoints.
There seem to be two main problems making it hard to introduce Wikis in universities and schools for teaching. One is a psychological problem which you'll also find in corporate environments. It's what I like to call the fear of loosing control by leveling the authority structures. Wikis are a very democratic thing, giving all users mostly equal rights. So it's very different from the typical top-to-bottom aproach of usual teacher-pupil-communications. In fact this is one of the big advantages which can make learning much easyier, but you have to bring this across to the teachers first.
A second concern seems to be the lack of approved ways to give out assessments and to rate individual peoples afterward. It is hard to decide how each pupil did in a collaborative task.
The speakers introduced multiple successful uses of Wikis in different educational environments in Israel, Switzerland and the USA. What I found especially interesting where different extensions which where especially developed to improve teachers tasks in the Wiki like creating new classes, giving out assessments and evaluating the contributions of the students.
An interesting benefit of a Wiki in universities and schools I hadn't thought of before is that by looking at the recent changes and page histories you can actually see how the pupils learn. You don't only see the finished result but also how it was developed. This is could have a huge impact on how teachers can reevaluate their teaching, in my opionion.
A member of the audience also pointed out the importance of links in a Wiki and how this should be made clear to pupils and that setting links actually should be rewardd somehow. He finally nailed it down to the sentence “Linking is learning”, which I couldn't put better.
In the Open Space discussions I joind two guys trying to build a new service evoloving around Wikis across the glob called “Universal Changes”. Their idea is to gather data from all those Wikis recent changes and to make it available in a central place.
We thought about the possibilities such service could give the whole community and what would be nessessary to make it a success. One of the ideas was the possibility to track either certain named pages in different Wikis (eg. get notificated if someone edits a page about me in any Wiki). But it also could work for tracking users or even IP addresses (this IP address edited a page in 100 wikis at the same time - it's probably a spam bot).
The last point raised some privacy concerns and we agreed that there should be some way to exclude certain information from the service's index, eg. by inventing something like robots.txt for it.
Another benefit would be obviously wiki research, eg. gathering statistics on used Wiki engines, number of edits and so on.
Talking about those statistical views we talked briefly about a tool by Jimmy Wales to visualize logdata. It basically creates a simple view of actions (edit or read) over a certain timeframe (eg. last 10 days) sorted by IP-Addresses. The idea is to display a dot for no activity of an IP and a vertical bar for activity. This creates very simple patterns of usage for each IP. By scrolling down the list you will quickly see any odd activity. You see very much edits on a certain time, or one edit every two hours or day and so on. The tool makes looking at lockfiles really easy because our brain is very good at pattern recognition even if you don't know what you are looking for. By simply translating the logfile into patterns you can quickly analyse data without the need for complex algorithms. I'd like to see if this idea could be extended to analyse standard webserver logfiles for strange things.
One more thing tht came up during the discussion was a new HTTP RFC called HTTP-Delta which is a logical step beyond the if-modified-since requests. It's basically the same but says give me all changes since a certain time. This of course makes sense with certain “listable” data like RSS and ATOM feeds. I have to look deeper into that.
I then joined the end of a discussion about the state of the Wiki community and came across a new meme called “Wiki Ohana”, where Ohana is Hawaiian for family. The question was how to connect the new (post-Wikipedia) wiki community with the old (pre-Wikipedia) one. There seemed to be some disappointments in the old comunity about the spawn of many new wiki engins not caring for well discussed and established ways to do things. Socialtext's try of creating a social software standards group without even having looked at all the discussions and efforts that had been going on in the “old” communities like Meatball was brought up as an example. The idea of Wiki Ohana is to make newcomers aware of the community and make them comfortable there. One suggstion was to expand the idea of the Wikipedia welcome committees to interwiki relationships. Eg. one of the “Oddmuse Wiki Welcome Commity” creates a page in DokuWiki to welcome this pretty new addition to the family.
The next group briefly discussed how to join the Wiki-way of editing with non-text media formats like image, audio and video. We talked about simpler things like cropping and rotatating images, annotate image areas (like flickr does) and then looked at what we could gain from the use of SVG.
The big question was if Wiki's should leave the browser for editing those contents (especially audio and video) by calling external clientside desktop tools with making it easy making sure editing takes a full roundtrip (storing the data back to the Wiki) or just rely on some plugin like Flash or Java.
Another idea for editing video was using a video control language like SMIL to just describe edits for reassembling different video parts.
It was a really exciting day with so much new impressions and nice people and I'm really looking forward for tomorrow.