Last June, before the Northern Voice conference, I spent some extra time in Vancouver at UBC to get insight into their success with UBC Wiki as a community platform as well as a publishing engine (w.g. wiki content being pushed to WordPress). Part of it was talking to the tech wizards behind it, (including Will, The Wiki Gardener™), librarians, and some faculty.
I was curious what I could bring back to University of Mary Washington, whether there was an opportunity for the wiki as a similar place in a school where blogging was pretty well established as a publishing platform. The uptake at UBC might be in part due to the science, math, and engineering fields that use it more extensively than other disciplines, or the timing of its start being in place near or before the rise of blog platforms.
I have my doubts about MediaWiki, not about its ability, but it is not really an approachable creating environment. Coders and geeks are fine manually editing raw wiki text, but I would never expect run of the mill folks to take it on, and yes, I know it is not really all that complicated- but it requires you to keep those codes in your memory space. Sure ==== is an <h3> tag and ”’blah blah”’ is bold text? A graphical editor is really not the full answer.
MediaWiki is powerful and super extensible, but finding those bits and tracking down documentation is a trip down Alice’s Rabbit hole with a dying flashlight. It pales in comparison to the WordPress Codex (which ironically is a wiki).
I don’t doubt its potential, but I was struggling to see how to make a use case for a mainstream faculty. Maybe I gave up too early.
What we did, at the brilliant suggestion of Brian Lamb one day sitting at the famous Table in east Van, was to start sketching out an outline for issues for this platform, and we did it IN the UBC Wiki. It’s still a brain storm list, but the OLT folks and myself added at least the meat for the technical specs– see http://wiki.ubc.ca/Sandbox:Wiki_Plots.
What I did see as potential was in the wiki as a collaborative space to write documentation and tutorials, and use the embed technology to have that appear in web sites, especially WordPress using the Wiki Embed plugin. Now the UBC runs an enterprise level set up, but I bet we could do something big with a small system. It was already somewhat in place in UMW Blogs for their documentation (using sn older version of the plugin), and we had a mEdiawiki running on ds106.
My idea was to set up two smaller wikis that would help for documentation writing. The power of the wiki embed plugin is that it would allow for instructors to embed the help docs or tutorials they wanted in their own web pages.
The aim is to not make the wiki itself a destination; it would be a bit chaotic and not cleanly organized, and really meant as a place for authors to go to. Using standard wiki markup, and extensions to embed video, audio, the content would be what is syndicated, letting the blogs format it locally.
So right now the two wiki sites I made are a bit scattered on the fornt page. I suggested using Categories to organize the content for authors to find. I could not get the DPL extension (Dynamic Page List) UBC Wiki uses (The current version was not available, an older one borked).
The one part I failed to get working is the pDF generator; the third part site that supposedly supports this function failed on my every time, and Scott McMillian at UBC had said the set up of their stand along server was “not trivial: (if HE says that, look out).
So in place now are two small wikis:
- ds106 documentation wiki http://ds106.us/docs feeding the ds106 Handbook and the UMW ds106 Syllabus
- Documentation for the DOmains of Ones Own project http://wiki.umwdomains.com feeding most of the support documentation for the Domain of One’s Own project
Setting up MediaWiki (for UMW Domains) and updating (for ds106) was not too much trouble. For internal / reference I have docs for the codes needed to embed media (quick, do you know the codes for videoflash? case proven).
Each of these have suggestions for using Categories for internal organization (can anything be more arcane than having to recall Category names or fishing through the all Category lists). And there is a separate guide for embedding in WordPress
One of the key settings in Wiki Embed plugin is that you can make it so of there any links other wiki pages, rather than jumping to the wiki, WordPress dynamically renders a page with that wiki page’s content; that is groovy, eh?
This means you can go to any mediawiki page, click the Embed Page on the left nav pane, and you get cut and paste embed code. We’ve not used it, but I have tested it. This static HTML page embeds from this media wiki page.
This is the beauty peoples. If we edit the MediaWiki content, all pages that embed it thus change. Edit once, change everywhere.
The Embed Tracker plugin gives us dome data on where the mediawiki pages are used, it shows not only where it is used by how many times it has been grabbed from the wiki- see the stats for the wik page above:
So the process again is author in MediaWiki, embed elsewhere as needed. How are we using it? Well Every page sitting on the new ds106 Handbook, a growing set of docs and tutorials, is embedded from our MediaWiki:
These are just WordPress pages with wonderfully little content; like the tutorial for Trimming Videos With MPGE Stream Clip has this for content:
[wiki-embed url='http://ds106.us/docs/Trimming_Videos_with_MPEG_Streamclip' undefined no-contents ]
Because all of the content comes from the wiki page — and that short code ius generated by the edit icon, all you really need is the URl for the MediaWiki page… and keep in mind that this plugin works with ANY MediWiki site, including the motherlode Wikipedia.
For what it is worth, for the ds106 handbook I am setting parents as children and grandchildren to make a hierarchy (and using the pagelist plugin to insert an index as a shortcode in a page or sidebar).
Some extras we get with the Wiki Embed plugin are at the bottom of every embed, some tools to force a refresh:
Since our wiki is not a huge active one, I have wordpress to check for new content once a day, but with this tool, you can force a refresh of you just edited the wiki page. The other thing you get in WordPress is an overview of all the embedded wiki pages:
(I am not 100% sure what adding a target URL means…)
This is just the first baby steps. The next thing I want to do is going to take advantage of Media Wiki transclusion a fancy name foe MediaWiki pages that use codes to include content from other Media Wiki pages.
My grand plan os to assemble a syllabus for people who sign up for ds106 on their own, it could be a self paced guide. We have several years of different readings, videos, activities, assignments. What I envision is making a wiki page for just a syllabus section, one for Audi, one for Design, one for What is Storytelling.
With this broken down into chunks, we can create a variety of syllabi just by deciding which of these separate pages to include in a master page, and what order to present them. And at that point we cna use the Wiki Embed plugin to pull in the aggregate wiki page into wordpress– it is not a hit on the wiki since the plugin embeds content for the time set (in our case a day).
There is still a lot of tinkering to do, but I am liking these steps made so far- I really did most of the MediaWiki set up in my last 2 days at UMW… its not a huge undertaking.
These little engines are in the “Can” mode – it is as always the DIY seat of our pants build it witjh duct tape approach, but it is going. I will keep working at it.
The The Little Wiki Engine That Can by CogDogBlog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.