The problem with wikis is that they require people to remember to contribute, stop what they’re doing, go to the wiki, click edit and retype what they wrote somewhere else already, such as in a blog, email, or other media upload somewhere else. I really hate it when I upload an image to my preferred image host (Flickr) then have to re-upload it if I want to use it in a wiki. And what about this blog post? As I write I’m thinking about how I might put it on the wikieducator discussion pages I’m involved in… I think I’ll just add a link there and point to this post.

George Siemens puts an interesting thought across – that wikis will get better long term use than blogs.. personally I don’t think so – I think most people find it easier to collaborate with themselves then they do with others, and the long term experience with wikis might annoy them so much that they return to blogging and rely on the network connections to aggregate some form of collaboration.

And that leads me to my vision for Wikieducator (and wikis generally) – the aggregation of individual efforts and then the collaboration.

So far wikispaces is way ahead with this idea. Long ago wikispaces made it possible to add an RSS feed to a page, to be able to add to a wiki through blogging AND to embed media like Youtube vids, Frappr maps and other services that offer embed code for redistribution. This is certainly one level of aggregation I would like to see in a media wiki platform like Wikieducator.

Imagine, you’re starting from scratch with a blank page in wikieducator.. your topic is.. oh, I dunno – the weather… instead of having to enter in text, upload images, rejig the structure and even break out new pages as the first page gets too huge.. instead of that (or as well as) you could add an RSS feed, such as a Del.icio.us tag, or a YahooPipe feed, or a Technorati search result, or the weather reports from 5 capital cities… imagine you could also embed a documentary video from GoogleVids, a popular tsunami video from youtube, a preview of An Inconvenient Truth, and even an old 1950’s B&W weather report from Internet Archive. Imagine that after embedding that media you managed to organise text based transcripts to be loaded in for the dial up users who can’t watch this broadband media. Now you’ve peppered the text and media with a few FlickrCC images and your page is about ready. It took you less then an hour, you have an incredibly rich page, you’re ready for ‘class’, and ready for further collaboration from all the people who’s media you just sampled – remember, its a wiki 😉

All of this is possible with Wikispaces already, but as much as I like wikispaces – I want to get into mediawiki and Wikieducator. Why? well there’s a few reasons – one is so the wikitext I/we create is reusable across other mediawiki installs such as our own if we ever install one. Another reason is because I am interested in the Commonwealth of Learning and the services they can offer in facilitating links across many national borders. The other is because wikieducator is focusing NOT just on educational content, but on improved communication channels to support the use of that content… Apart from those very brain centred reasons, its a gut instinct.

But my vision goes further than just getting Wikieducator’s mediawiki platform up to speed with the likes of wikispaces and content aggregation and media embeding.

Take Shaggy’s Training Packages Unwrapped (TPU) project. An incredible solution to the unusable formats that the Australian National Training Information Services (NTIS) uses to express Australian training unit standards. If you take a look at the TPU proof of concept you will see that TPU extracts key content out of NTIS unit standards and displays them in HTML with the option to extract in a number of other formats – including mediawiki text!! So take this project and apply it to many other forms of syllabus documents that almost always come in .doc, .pdf or .rtf formats and never in wikitext! and we have a short cut way of getting skeletal content like learning objectives and the like into a place like Wikieducator.

Now take a New Zealand project like eXe. eXe was formally a tool for creating SCORM compliant and XML content for reuse in Learning Management Systems and the like. It was probably designed for more than that, but when I first saw eXe back in 2005 I saw LMS tool and looked the other way. Now the project is aligning with the Wikieducator project and could conceivably be used to extract content from the wiki and reformat it ready for print. It could do the reverse as well, reformatting word processor files into wikitext ready for upload into Wikieducator as well, just like TPU can do.

Back to the aggregation inside a media wiki.. one-way aggregation is only half useful. Being able to quickly and easily compile an information piece on a wiki page from a variety of already existing information and media is great, being able to then quickly edit and add your own information around that media is even better, but to be able to dynamically export that page in true Web2 fashion would be the bomb! If each page had some form of XML with a simple step of copying a line of code and pasting it in another context so that the wikipage would redisplay on a blog, an LMS (gawd help us!) a straight website, a start page or even another wiki.. well, that would just be tops! Not just a snap shot of the wiki (we could just use eXe export features for that, but an always up to date version dynamically updating itself via RSS or something. What this would enable would be amazing. Similar to being able to display youtube vids in different contexts, but we are enabling the display of aggregated and wikified content in other contexts, where that context’s style sheet and presentation can lay over the content and make it appear native! So not only do we have open content (as in free access) but we have multiple pathways to the source as well! free and open source content on every level.

As I’ve pointed out before, Wikieducator are proactive on these things. They saw the need for better communication channels to support the content, so they introduced Instant Messaging channels. I’m informed that their IM works fine with Skype, hopefully it works with GizmoProject as well. So we potentially have VOIP in their too. Content alone is not much help to those who are trying to learn. Access to communication with others is what counts, so the provision of Instant Messaging and even Voice over IP channels for every page or content type would really kick arse. Volunteers like me who have a stake in a number of pages could list their preferred live communication channel, and the wikieducator page would be able to show whether that person was online and available, and facilitate messages between people through that page. Still on improving communication around specific content, Wikieducator has also recognised the cumbersome discussion platform of mediwiki and should be implementing threaded and slightly more graphically enhanced discussion soon as well, based on the Liquid Threads development.

So that about somes up my vision/wish list for Wikieducator.

  1. Two way aggregation and re-contextualisation
  2. Embedded media of all types
  3. Download and upload to and from static formats like word processor documents, PDFs and other text files.
  4. Good synchronous and asynchronous communication channels with every page
Advertisement