Open Textbook Authoring Tools Part 1 – Mediawiki

So my last post should have made it clear that what I am ultimately hoping to promote/support for BC is an authoring and publishing system for open textbooks that:

  • can enable collaborative authoring if desired
  • can be done “out in the open” to enable as much as possible the conditions for serendipity to emerge, so that content can spread viral-ly, new co-authors and unintended readers happily stumble upon it
  • results in all of a web, print and eBook version (maybe more!) being produced as automagically as possible – i.e making the material as accessible as possible to as many learners as possible
  • is easy for authors and readers alike to use
  • is free/cheap and open/extensible (and produces open standards-based content)
  • limits the choices upstream of what authors and reusers want to do with the book as little as possible
  • gets me dates (ok, this last one was just a test to see how closely you were reading)

That’s not asking much, is it?

Mediawiki and Wikieducator

Luckily, there are some real pioneers in our field who have blazed trails in this area that those of us coming along later can follow. One of those groups of pioneers is made up of the folks at the Mediawiki foundation and Wikieducator (and I’d be remiss not to mention the Commonwealth of Learning and Wayne Mackintosh in particular for funding a lot of this work.) They have created extensions to Mediawiki, the open source wiki software that famously powers Wikipedia, that allow one to collect pages together and publish them as a printable PDF book. In addition, they worked with a print-on-demand outfit called PediaPress to enable seamless printing of the results.

To see/use this in action you need only to visit the Wikieducator site. On the left-hand nav there’s a link to Add a wiki page to a book. That’s right – books aren’t predetermined but can be made on the fly to include whatever pages you like. That’s not to say the instructor can’t pre-assemble an official “text,” but whether it be a student personalizing it or another instructor wanting to adopt it, the book can contain whatever contents you choose.

But you needn’t try it only on wikieducator; the Collections extension is freely downloadable and installable by anyone wishing to run this in their own mediawiki. There is also a second, unrelated extension, ePubexport, available to convert a set of pages into an ePub.

Now before we get to far, let me make it clear, I am not suggesting you have to do this on your own or that you shouldn’t use wikieducator. Indeed, that should probably be your FIRST question to yourself if this approach seems appealing – why would I not use wikieducator? Not only is it likely to be better supported than what you will do on your own, there are already scores of folks involved, some of whom may prove to be future collaborators. In addition, they have done lots of work creating templates and styles that come in very handy. So many of us talk about the importance of communities but then forget we don’t always have to create them ourselves; often it’s a more a question of finding those that exist and joining in.

Trying it out locally

However, I did install Mediawiki and these extensions for our open textbook pilot, in part because I wanted to learn for myself how they worked and also see what parts could be customized or improved upon. As a test, one of my colleagues gave me access to a Desire2Learn-based course from the Applied Business Technology. I exported the course to get access to the source files. A few things to note here:

  • hey D2L – your exports still kinda SUCK! I don’t know who thought it would be cute to transform file paths into file _names_ but it’s just a PITA.
  • there’s no simple way I’ve ever found of getting from an IMS Content Package to a wiki (or much else for that matter, and thank goodness for that – it would mean someone outside of higher education was actually taking IMS specs seriously, pshaw!) There is however some html import tools for mediawiki that are useful. There are also web-based HTML to mediawiki conversion tools to that can be helpful too.
  • that said, the truth is that all of the approaches that let you output to multiple formats depend to a lesser or greater extent on clean markup. So while you can get existing stuff in, its almost always better, if you have the choice, to simply author in those environments from the get go.

Here are some of the results of this initial test (trust me, the irony of the subject matter is not lost on me) – the site itself, the generated printable PDF and the ePub.

Now before you criticize, these were done with no additional attention paid to page templates, transformations or additional CSS. I also did some initial tests and it does look like the resulting PDF is editable after the fact with Adobe Acrobat X Pro, meaning there is room for manual improvements to the file in addition to refinements to the export process. And I was able to open and improve upon other automatically generated ePub’s with the Sigil WYSIWYG ePub editor, and in very short order was able to remove some of the cruft and other formatting and turn it into something reasonably usable.

So how does this approach fare? Let’s run it through the above criteria I described and see:

  • collaborative authoring – in spades!
  • can be done “out in the open” – the very definition of it
  • results in all of a web, print and eBook version – yep
  • is easy for authors and readers alike to use – let’s come back to this
  • is free/cheap and open/extensible (and produces open standards-based content) – yep, yep and yep
  • limits the choices upstream of what authors and reusers want to do with the book as little as possible – given XML exports and a multitude of wiki conversion tools, I’d say the answer was yes.
  • gets me dates – still left to be seen

So this approach seems to hit on most fronts. The big question is – is it easy to do and will instructors and others supporting them be able to bridge the gap between there current workflow and approaches and this new one?

Well many folks tell me this is just too much to expect, editing mediawiki seems just short of rocket science. And I have to concede, there is always room for improvements – I am holding out great hope that the still experimental Mediawiki WYSIWYG editor will be a big step forward, but even turning on the bundled (but not activated by default) WikEd editor is a major step forward. Even something like the Word2Mediawiki extension can serve as a useful bridging strategy (Open Office also exports natively to Mediawiki.) And implementing page templates (and wiki gardeners – a potential useful role for students too) can also make things much easier. So yes, there’s room for improvements, but is mediawiki simply just too difficult in the end regardless of what we do to improve it? If so, someone should tell the faculty and students at UBC to stop doing the impossible – their wiki continues to astound.

So I’m left thinking there is some real potential here that I want to pursue. I know there is technical work still to do. The bigger challenge, one that I’m not sure is surmountable, is the cultural chasm between the cult of authority in higher ed and the messy give and take that is a vibrant, collaborative wiki. It may well be that this is an approach that anticipates future potential benefits too highly over current realities of practice. That’s part of the reason we’re doing a number of pilots, to figure this out, and this is but one of a number of approaches being investigated. More on that in the next post. – SWL

(Author’s Note: This post was partly written, online I might add, while sailing across the Salish Sea. I just had to mention this as the fact that I could do this continues to blow my mind.)

10 thoughts on “Open Textbook Authoring Tools Part 1 – Mediawiki”

  1. Great post. Thanks for pointing out the ePubExport did not know about that one.

    About the fear of the wiki being too hard to edit I agree somewhat the new editor gives you all you need for basic editing, for copying and pasting from word or doing templates etc will always be hard but who does that? I would say less than 5% and if you add some canned templates for courses that satisfies most and what is it with people that complain about it anyways? It’s a University spend 5 minutes “learning” something new.

    The editor will get friendlier soon though check out the prototype of the new visual editor:
    http://blog.wikimedia.org/2011/12/13/help-test-the-first-visual-editor-developer-prototype/

    also the next collection wireframes also look amazing http://www.mediawiki.org/wiki/Collection_Extension_2

    as does the next gen liquid threads ui http://www.mediawiki.org/wiki/LiquidThreads_3.0/Design

    The mobile front end the same that wikipedia runs is now using PHP (although I am having difficulty with it redirecting properly so not in prod) :
    http://www.mediawiki.org/wiki/MobileFrontend

    Just trying to say the wiki is good now but is going to be great soon IMO. Hopefully people do not give up on this “old” technology.

  2. Scott excellent post and review of issues and challenges.

    Interesting observation — in the WikiEducator community we have not observed any major changes in editing behaviour since the implementation of the rich editing option.

    While anecdotal it suggests that the “editing in a wiki” is too hard might be a convenient excuse not to collaborate 😉

  3. And in this one, all images seem to be broken in the web version and the epub, but work fine in PDF… but I like the basic idea. I think I’d rather maintain a WordPress installation than a Mediawiki installation if I’m given a choice, so I hope Pressbooks comes up with something.

  4. Doh, will teach me not to proof the results better. The borken images on both are very fixable, have to do with one particular type of path not working on exports.

Comments are closed.