Making books more like books

At Wikibooks we've been thinking for a long time for a way to make MediaWiki work better with books. It's no surprise that some of our users, such as the WiTTIE group that I'm working with, feel the same way. That's why one of the things on my task list for this project is to add some sort of understanding of "books" to the interface.

There are, as I see it, a few steps we need to take to make this happen. Luckily for us, a lot of the work has been done already by PediaPress with the Collections Extension. What the Collections Extension does is to take a group of pages and put them into an order, called a "collection", which can then be used to generate PDFs or even be sent to a print-on-demand publisher. The Collections Extension also has notions of "official" and "personal" collections. A collection stored at PROJECT:Collections/BOOKNAME is an official global collection. Collections stored by individual users at User:USERNAME/Collections/* are personal.

So we have a way, using the Collections extension to store a list of pages in the book in a specific reading order. All we need to do is add some code to the extension (or maybe write an extension-extension) to look for an existing global extension (and maybe default to a personal extension if a global one isn't provided, or the other way around, or whatever). Once we find the collection, we can read the page list from it, divine the page order of the current book, and create links as necessary. Presto.

It's interesting to think of other possibilities too, which are relate but might be a little bit outside the scope of this WiTTIE project. For instance, we could find interesting ways to marry a book collection with it's TOC. Creating one could automatically create the other, and vice-versa. A good graphical automation tool for creating books could create both automatically. Maybe the Collections Extension could be modified not to use a separate save page for a global collection, but to use the TOC page directly (assuming a certain simplicity of page formatting). Again, lots of interesting possibilities.

So these are some of the things to consider as we move forward. I'm still putting my team together for this, and we don't have the server so I haven't started any serious work yet. However, things should get moving soon and I'll post updates when they do.

WiTTIE Wiki Project

This weekend I was down in Norfolk Virginia talking to some people from Old Dominion University about Wiki-related stuff. The group, named WiTTIE, is researching the use of wikis to facilitate education which, as a Wikibookian, is a topic that's near and dear to my heart. They're interested in setting up a wiki website with certain features, and recruiting classroom groups from around the world to use it and generate feedback. The group has been in touch with Erik Moller from Wikimedia fame, and Wayne Macintosh from Wikieducator, and we're simultaneously getting good feedback and good opportunities to give back to the greater open-education community.

My role in the project is primarily that of lead developer. I'm trying to put together a team of people to do some contract work for the next couple weeks, so if anybody reading this is interested, let me know ASAP because there is real $$ involved. We're going to be setting up and configuring a MediaWiki server with several existing extensions. We're also going to be creating some of our own extensions to support the use of MediaWiki in a classroom environment (reviewing and grading features, etc). Some of the extensions we are interested in deal strongly with usability: FCKEditor and the Uniwiki Extensions. We're also looking to use things like the Collections Extension, FlaggedRevs, and the Quiz Extension (with modifications).

This group is interesting in pursuing a particular mechanism for peer review. Each student writes their own page, and then is responsible for reviewing another page or pages. They review the page, leave criticisms, and give grades. Then students have the opportunity to respond to criticisms left for them and grade their reviewers. So it's an interesting two-way grading system that teaches the teachers not only to write teaching materials, but also to generate high-quality reviews.

The project that I'm planning in my head to address this issue is a commenting and reviewing tool. Here are some thoughts about how it might work:

1. When a reviewer right-clicks a page (or something else) a comment box is opened where they can enter a comment, a grade, and maybe some other metadata about the page, as required by their class.
2. The review may include a short quiz for material understanding, a rubrik about the page, etc. I'm not sure whether the quizzes and rubriks will be editable or not from the wiki interface, or if they are intended to be standardized and read-only.
   
3. The review is saved somewhere, either onto a page somewhere in the wiki, or in a custom database table. Each review will include some information such as the page name and section where the review was left, the grade, the name of the reviewer, and the state of the review (open, rejected, resolved). In this sense, it becomes very similar to an issue tracker.
   
4. Comments that are rejected or resolved do not appear on the page anymore (but will be visible in either a special "comments history" page, or through another interface). In this way, students can keep track of what issues are outstanding.
   
5. Only unhandled comments appear on the page for the author to see, and he has the ability to interact with it. The author has the ability to leave a counter-statement, and a review of the reviewer before marking the issue as resolved or rejected.

This is a feature that I've been hoping for on Wikibooks for a long time: The ability to essentially create a TO-DO list on a page with comments that can be marked as such when they are completed. Such a feature would let us do content planning and reviewing directly on the page itself (not having to go to the talk page), and helps to create a very real progress indicator of page development. Obviously the ability to "review the reviewer" isn't really necessary, but an extension that allows those kinds of two-way discussions to take place is a superset of what I think WB really needs.

But, what WB needs isn't really an issue that this project is addressing directly. Once primary development on this project is over, we will be more able to focus some attention on getting these extensions and improvements folded back into the WB and WV projects as necessary.

I'm looking for people who have some prior knowledge of things like MySQL, PHP, JavaScript, and MediaWiki, but these are not firm requirements. Basically, I'm looking for interested developers who are willing to learn new things, create new projects, and earn a little bit of summer money. If you or somebody you know fits the bill, let me know ASAP.

Wikibooks Templates

I've created a handful of new books in my time at Wikibooks, and I find that there are some processes that are common to each: We need to create a table of contents, we need to create various templates and categories, etc. Being a programmer and therefore very lazy, I try to find ways to automate these kinds of processes as well as I am able. To this end, I've created a series of what I call meta-templates, or templates that are used to create other templates. The goal of these meta templates is two-fold: First, to make it easy to create new templates quickly, and to hide a lot of the "dirty" formatting stuff that new users shouldn't have to worry about. For new and inexperienced users this is a huge boon. They can substitute one meta-template and get a full-featured header template to use in their new book. Certainly beats having to make a template from scratch, especially since our documentation in this area is still far from complete.

Let's look at some of the things that a good header template will want to have:

1. The name of the book, which will probably double as a hyperlink to the TOC
2. "Next" and "Back" links, for easy navigation
3. Categories. The template should put all pages where it is transcluded into a category for all pages in the book.
4. Some documentation, to explain to users how to use the template.

A lot of these items should only appear conditionally: Next and Back links should only appear if needed. There is no "Back" on the first page of the book, and no "Next" on the last page. Documentation about the template should appear on the template page but should not be transcluded with the template into every page in the book. The entire template will also not want to be displayed in a printed version, for various reasons. Let's look at how to implement that last requirement in wikitext:

<includeonly><no</includeonly>include>[[Category:Exclude in print]]</includeonly></no<includeonly>include></includeonly>

This is quite a mess! But that's the purpose of the meta template, I write this mess once and nobody else ever has to do it again. When we substitute the meta template to create a new navigation template, we get this:

<noinclude>[[Category:Exclude in print]]</noinclude>

So that makes more sense to see the result. We have to do all the mess above because if we didn't break up the noinclude tags in the meta template, they would disappear when we substituted into the navigation template.

Let's look at the related, but more complicated, problem of having next and back links that appear only when values are provided. Here's the code that I have to use in the meta-template:

<includeonly>{{</includeonly>#if: {{{last|}}} | ← [[{{{book}}}/{{{last}}}|{{{last}}}]] | }}

Again, without the includeonly tags put in those weird places, the {{#if:}} tag would disappear when we substituted. Now when we substitute, the includeonly tags disappear, leaving a perfectly-formed tag in their place:

{{#if: {{{last|}}} | ← [[{{{book}}}/{{{last}}}|{{{last}}}]] | }}

This string of stuff isn't exactly clean and isn't easy to read either, but at least the new users don't have to write it themselves. Anything we can do to decrease the barrier to entry for aspiring new book authors is always a good thing.