Friday, April 4, 2014

Can a wiki be used to construct an open text?

I teach an (very) introductory linear algebra course, primarily for first-year university students. For such students there has never been a world without Wikipedia, and having many libraries of information in their bedrooms 24/7 is as natural as watching TV. After many years of internet exposure, these students have acquired an ability to navigate and absorb information from varied sources easily. Can these skills be exploited advantageously while teaching an introductory mathematics course?

For the last couple of years I have been slowly building a wiki for this linear algebra course. By design, the wiki looks very much like Wikipedia; the usual navigation, search and toolbox frames are in the same place. It "works" the same way. Along the way I have observed several assets and liabilities to this approach.

Here are some assets:
  1. Cooperation is easy. This is the most obvious one, but one which I haven't really taken advantage of. In fact, since I am the only author, this is really an anti-wiki (that will change).
  2. All browsers include the ability to read wikis, so no special software is needed (however, see below). Any operating system with any modern browser will almost always do the right thing.
  3. No special student instruction is necessary. You don't have to tell them to click on links; they do it automatically. You don't have to tell them how to print pages; they've been doing it for years.
  4. MathJax allows mathematical expressions to be typeset (beautifully) using LaTeX. This includes the extensions from the amsmath package. This means that mathematical symbols are not bitmapped but, rather, have quality matching that of the browser text. It also means that any familiarity with LaTeX can be used immediately with the wiki, and a consistency of mathematical presentation is possible.
  5. The MediaWiki software allows for macros, so that, at least in principle, markup and presentation can be separated. It also allows transclusion (this is where the contents of a defined link is automatically included when the page is opened) so that created material may be recombined in different ways.
  6. The language for MediaWiki, both for creating pages and for running the wiki, is well documented.
  7. Tools are available when necessary for
    1. colour
    2. folding text (extra text that is opened by clicking on a button)
    3. graphics
    4. animations
    5. automatically generated links (table of contents and such)

Here are some liabilities:
  1. Controling presentation with CSS is another layer of abstraction to be mastered.
  2. The syntax for nonmathematical page markup is awkward.
  3. The default editing environment is pretty awful.
  4. Structures like tables, numbered and bulleted lists can be done in various ways (html or mediawiki syntax). All of them are awkward.
  5. Using math within tables causes unexpected results.
  6. A wiki needs a GD (gentil dictateur gentille dictatrice) to ensure consistency and quality.
Here is a sample page that illustrates a different approach for introducing the cross product of two vectors. The animated gif drives the whole presentation.

Incidently, feel free to look at any of the pages on the site and use anything you find useful. Just be warned that many pages are pretty stark and some links just dangle. You can also note that it is possible to click on a 2d or 3d graphic and a hidden PostScript version will pop up showing full detail (the initial graphic is bit mapped). With a newer version of the Adobe Reader, it is possible (in theory, at least) to grab a 3d image and rotate it, scale it and carry out other transformations. If you want to give it a try, look at the figure in

Matt Boelkins has commented in this blog that writing a textbook requires writing "2 pages a day, 5 days a week, 50 weeks a year." That's quite a burden. So here is the question: can this burden be shared by using a wiki? Is this any more feasible for a cooperative approach to the writing of open texts than any other software? Comments are welcome.

Michael Doob
Department of Mathematics
University of Manitoba


  1. I found this site which seems to take the wiki idea to all kinds of textbooks:

    There seem to be a number of works in progress listed here:

  2. Liabilities 2, 4, and 5 could be resolved by using a different wiki software. For instance, Instiki ( uses a Markdown syntax which I find greatly superior to Mediawiki. It also emits valid XHTML, can embed SVG, and displays math using MathML rather than MathJax. The latter means that (at least in browsers which support it) you don't have to wait forever for the equations to be loaded by javascript and the text re-flowed around them. (It does only accept a subset of "real" LaTeX, however, and it doesn't have fancy templates like MediaWiki, although it does allow including one page in another.)

    There are other options too. Some people swear by TiddlySpace (, though I've never really gotten into it.

    Liability 2 can be avoided by using something like Itsalltext (

  3. The underlying problem is that collaborative authoring of open textbooks is in its infancy. We don't have any of the following:

    1) Standards for marking up the structure of a textbook.

    2) Good tools to convert the source material of a textbook into the myriad of desirable human-readable formats.

    3) Good tools to allow multiple people to edit a document.

    4) Effective ways to share material between different documents.

    5) Ways to indicate that a textbook, or supplementary material, meet certain minimal standards.

    I'm sure many of us could add 5 more things to the list.

    The good news is that I think people realize these shortcomings and are working on solutions.

    So what should we do while we wait for all those great tools to arrive? Obviously it is defeatist to do nothing. So it makes sense to work in a way that has a chance to feed into the better tools that are coming along.

    In terms of using a wiki, I think the key point is to be aware that later you will want to convert the source to a more structured form that enables the work to be processed into other formats. Do you want the book to come out in EPUB3 format, with an automatically generated list of definitions and examples? You can have that, provided that your underlying source has enough structure that someone can write a script to enhance that structure.

    If your goal is for each page of the wiki to be self-contained supplementary material, then probably everything is good as-is.

    But to address the specific question asked: is a wiki a good way to share the burden of writing a textbook? I think the answer is 'no,' because the textbook has to be written in some structured form. These days that means LaTeX or XML. I don't see how a wiki is the best current option for that, especially since you probably don't want a true wiki in which anyone can change anything.

    1. What makes you think that you couldn't extract a structured text from a wiki? Indeed, wiki syntax *is* a structured text, and while Mediawiki uses a fairly idiosyncratic format for that structure, other wikis use (for example) Markdown, which is an emerging standard that is easy to convert to many other formats (and easier to use than either LaTeX or XML). As a particular example, Andrew Stacey has written a script that extracts pages from Instiki to produce a LaTeX document.

      But more radically, one might question the assumption that a "textbook" must be a *linear* arrangement of material, such as one is forced into by aiming at a printed or epub document. It sounds to me as though Michael is envisioning a world where the wiki *is* the textbook, and students read it by clicking from wiki page to wiki page. If what you want to create is a collection of interlinked documents, rather than a single linear document, then I think a wiki is an excellent option. A "semantic wiki" (which Mediawiki has a very powerful extension for) additionally allows maintining additional "metadata" about pages which can be searched and programmatically compiled.

    2. I support the idea of a textbook with a nonlinear narrative, and I claim that such an approach requires structure beyond what can conveniently be done in a wiki.

      By "structure" I include information like "this is a definition". Suppose on another page you wanted to refer to the definition of "cross product". You could put a hyperlink to the web page on Cross Products. Doing so would require the reader to jump back and forth between pages to get a reminder of the definition.

      But if you look a the way references are handled in Rob Beezer's linear algebra book ( you will see that a huge benefit has been gained by the fact that a definition is a labeled entity that can be referenced elsewhere in the book. Similar features are available for every theorem and example.

      Having looked at something like Rob's book, I begin to feel annoyed when I am on a website like Wikipedia that makes me jump all over the place, and occasionally get lost, instead of just giving me the information I want on the page I am looking at. It is the structure, provided by detailed markup, that makes Rob's book possible.

    3. I think that a semantic wiki could be used to implement what you have in mind. In semantic mediawiki, you could define a template for "making a definition" that would not only render the definition on the page where it is called, but place it into that page's metadata with a given tag. Then when you want to refer to that definition, you could call another template that would do a search over other pages' metadata to find a definition with a given tag, and display that definition inline or with a popup as you might prefer, together with a link to the page in which it was defined. Of course, mediawiki's syntax for all of this is fairly horrendous, but it proves that it can be done in a wiki.

    4. The effort required of the authors (even after the technical aspects have been set up) makes it sound to me like you are describing why it *can't* be done in a wiki. Maybe "won't" is a more appropriate word than "can't".

    5. I don't see any reason why (once it's been set up) the effort required of the authors should be any worse than any other way of adding the structure that you mentioned.

  4. One advantage of github (as mentioned previously on this blog) over a wiki for collaborative work is the notion of "pull request". Most wikis assign editing permissions in a binary way: either you can edit a page or you can't, and if you can edit a page, then your edits take effect immediately (although other editors may be notified and can revert them if they disapprove). Github also allows people to have direct "push permission" to change the main repository directly, but there is a middle option: anyone can "fork" the repository, make whatever changes they want in their fork, and then submit a "pull request" asking that their changes be merged into the main repository. Then they and anyone else can discuss the proposed changes in a dedicated forum, possibly resulting in changes to the proposal, and finally someone with sufficient permission can "merge" the pull request into the main repository. This allows a project to accept contributions from pretty much anyone in the world, while still maintaining a "gatekeeping" functionality that ensures everything that gets in meets the desired standards. There's no reason that a wiki couldn't implement a similar functionality, but I don't know of any that do.

    The ability to "fork" is also by itself a nice feature. Perhaps one teacher wants to use a textbook for their class, but they need to modify it in a few ways to make it suitable. They can create a fork and make their changes there, and then (1) anyone else who wants to see their changes can, (2) if the changes are deemed desirable, they can easily be merged back into the main project, and (3) updates to the main project can easily be merged into the fork, so that it stays up to date with what it's built from.

  5. I think that Mike makes an interesting point. At the risk of sending this discussing fairly far afield, the notion of a textbook with a single voice and a single thread may become less relevant moving forward. Students today are wired differently. They already search and skim. The idea of a single narrative voice may be less important than we think. If I write a good, self-contained exposition on the intermediate value theorem and another contributor writes a self-contained exposition on the mean-value theorem, then a calculus "textbook" can simply be a walk through a sequence of documents that has been carefully curated by yet another contributor. Our colleagues in the humanities have been designing curricula like this for centuries.

    A more likely middle ground approach to a wiki textbook might be a few people with an overall plan that recruit contributors to write particular sections. Each section writer would just need a good idea of what prerequisite information has already been conveyed to the reader in earlier sections, but I think strict stylistic and narrative guidelines could be discarded without too much effect.

    A larger issue is how to encourage people to contribute to such an effort when there is no clear professional benefit. Mike, I know that you recently participated in an open, collaborative writing project. I'd be interested in posting something from you on the front page regarding the issue of "getting credit" for this kind of professional activity. Let me know if you're interested (off blog).

  6. Albert, I think you have started an unrelated topic. I like the idea of a book organized by a few people, and written in parallel by a large number of people. To be successful, such a book will require every component (definition, example, theorem, etc) to be marked in labeled in a way that it can be referenced from the other components. LaTeX and XML are capable of providing a way to make up that structure, while a wiki is not designed to do that. Just think about the power of the \label{...} and \ref{...} commands in LaTeX. Is there any hope of writing a good textbook without that? If all you can do is refer to components on the level of a subsection of a book (I think that is a reasonable analogy of what can be done in a wiki), then the reader will have difficulty following a detailed argument.

  7. In my above comment, the blog rendered "backslash ref" as two question marks.

    1. I suspect that was some kind of weird interaction with MathJax. This blog loads the MathJax javascript library.