Wiki as a book reader

The Use Cases

There has been alot of healthy discussions around ebooks and book libraries lately. This is not a simple tool selection discussion, it is one in which participants are trying to understand how to use (or create) the best combination of tools that will enable constructionist learning [Wikipedia] in schools in the developing world.

The challenge lies in the fact that there are multiple ways in which content can be provided (book, text book, article, magazine, multimedia, etc.), and then when constructionism is taken into consideration, there are multiple ways in which users can interact with those differnt mediums (create them, edit them, comment on them, share them, etc.)

The following use cases describe the most probable points of intersection between mediums, roles and interaction models:

1. Curriculum distribution: Content that is currently taught in schools, need to be made available to students on their new laptops. This is going to be a major way in which governments in poor developing countries will be able to justify and allocate the financial resources needed to finance those freely-distributed laptops. They are effectively a replacement for text books. Any solution will need to allow for the distribution, and offline reading of curriculum.
2. Content creation: Children should be able to create their own content. They should also be able to share their content and work together on developing it. Not just that, they should be able to modify pre-existing content, to edit it, update it or even modify it to be more relevent to their lives and experience. This means that they should be able to modify an ecology chapter to add local knowledge to it, by describing examples from the surrounding environment, or stating an local exception that is not governed by the rules described in the original text.
3. Easy third party book publishing: Any person with scientific, literary or artistic knowledge or experience should be able to easily author content and make it available to children. She also should be able to interact with readers of that content and be able to read and react to any changes made to that content or any comments posted about it.
4. Easy search and discovery of third party content: On the other hand, children should be able to access, share and interact with the third party content being provided to them, in the same way that they are able to interact with content that they themselves created and shared.

There is no software that has been evaluated so far that provides such flexibility and integration of features that would fullfill all those requirements. One class of software though, embodies alot of the basic characteristics described above and has been in wide use for a while now. It is called Wiki [wikipedia].

Wiki Required Changes

There are many ways in which those challenges could be solved, and wiki is by no means the only option available. But this write up will concentrate on wiki, and discuss what set of basic features wiki will need to get, before it can be considered as a viable option for solving those challenges.

Synchronization Support

In order for wiki to be used as an offline reading tool, a verion of it should be running on the local machine. This will have additional added advantages, such as providing the children with a more powerful way to store their notes and thoughts then the file system and text files, or maybe a way for them to solve their homework and submit it, etc.

But there will also be a school server at which more content than can be stored on the laptops will be stored or cached (in case it is fetched from yet a higher level server). The children will need to be able to obtain content from the school server and store it on the local wiki for offline reading.

They also might want to modify the downloaded content and upload the changes, or create new content and publish it on the school server to share with other students or even for backup reasons (although other more complete backup solutions might need to be provided).

The ability to synchronize specific content between two wikis is needed to allow for this kind of functionality. The user should be able to choose which pages to upload or download, and then the system will need to be able to detect differences in versions and give the user the ability to edit conflicts and make merge decisions when needed, or simply decide not to go on with the upload/download.

Page Grouping

Unless there is some basic ability to group a set of wiki pages and download/upload them together, or browse them sequentially, it will be very difficult to have ebooks or any content of considerable size be distributable or readable through wiki.

Without this feature, two alternatives come to mind. The first is to have all related content be in one page. This might result in articles that very large to the degree where they take alot of time to render, consume alot of energy form the processor to render them, and possibly run out of memory while viewing them.

The second alternative is to have the ebooks consist of a normal set of wiki pages that are not grouped in any way. It is obvious why this would be an issue, including, but not limited to, the need to download many pages seperately, which would not be doable for the average size textbook.

Given those two alternative, it becomes aparent why some grouping of wiki pages is needed, so that operations can be applied to the group as a whole, and the viewing experience of a book of multiple pages can be enhanced with simple UI features.

Programmable Content

One of the greatest educational tool a constructionist has is programming. This was clearly demonstrated by the early success of logo in teaching children math skills. In order for this it to succeed though, children will need to author those programs, interact with them and interact with other children during the creation process.

Given that most programs can be textually represented, wiki could be a great medium for storing and sharing those programs. The challenge though is that wiki servers today are designed to be stores of formatted text.

Wiki could benefit alot of as a constructionist education tool if its front end is integrated with educational programming language's interactive frontend interface.

Simplified User Interface

Wikis today are fairly simple compared to other kind of applications that try to achieve the same goal. They are not simple enough though to allow young children to use and easily interact with that interface. The function it provides is simple, which means that it should be possible to create an interface that reflects that simplicity. That user interface does not exist yet.

Landscape format or Portrait Format or a Choice by an Author?

[Start of note by William Overington 19 March 2006]

Should the display be landscape format like a web page or portrait format like most hardcopy books or should the author be able to choose?

[End of note by William Overington 19 March 2006]

Format control of text

[Start of note by William Overington 19 March 2006]

An issue which needs to be addressed is as to how a content author can insert format control commands into text so as to produce the content author's desired results upon the screen.

Unicode is good for specifying characters for text and symbols, yet does not, by choice, for the most part address formatting issues, leaving that to higher level protocols. Such protocols will be needed so as to address point size of type, choice of font, whether regular or italic or bold or bold italic, justification, page throws, colour of text, colour of paper. location of diagrams, wrapping of text around diagrams.

There are various possibilities.

One is to make the whole text an HTML or XML style document in every case.

Another is to use Unicode Private Use Area codes to signal such things, so that a default format text is just ordinary plain text and any special characters are added as needed. The format characters could have authoring-time symbols for display if desired at authoring-time though they would be zero-width at display time. So there could be three modes. Authoring mode ordinary, authoring mode special and display mode. Authoring mode ordinary and display mode would have formatting symbols as zero-width, authoring mode special would show the authoring-time symbols so that situations where a formatting symbol is to be deleted or a sequence of two or more formatting symbols needs to be inspected or edited could easily be managed by a content author.

I had a try at defining various such formatting characters some years ago.

http://www.users.globalnet.co.uk/~ngo/court000.htm

That page was the start and the first two pages linked from it were part of an attempt to produce a comprehensive system.

However, a selection of the codes would be much easier to use, for example by children.

For example, on the web page http://www.users.globalnet.co.uk/~ngo/courtcol.htm are sixteen direct colours U+F3E0 BLACK, U+F3E1 BROWN, U+F3E2 RED, U+F3E3 ORANGE, U+F3E4 YELLOW, U+F3E5 GREEN, U+F3E6 BLUE, U+F3E7 MAGENTA, U+F3E8 GREY, U+F3E9 WHITE, U+F3EA CYAN, U+F3EB PINK, U+F3EC DARK GREY, U+F3ED LIGHT GREY, U+F3EE LAVENDER and U+F3EF MINT so a word could be made red by inserting a U+F3E2 character before it and another character after it to change the colour back. That could either be the code for the colour of the text or a code to indicate that the colour should be popped back to the previous colour (the system did not include a code to pop the colour, though one could easily be added to the set of formatting codes if that is seen as desirable).

It seems to me that one way of looking at it is that this project is trying to produce an open source wiki engine which produces an end user effect of as much as possible of what the Adobe Portable Document Format does yet with having a very straightforward way of a content author entering the content and formatting it.

It seems to me that a good way to approach this is to have a system which allows good black and white effect to be produced just by a content author keying text. The text can then be edited and the formatting characters would override the default settings of the reader.

My own view is that using Unicode Private Use Area codes, (whether those in my attempt of some years ago or starting again with a blank specification) is a good way to go. However, I cannot say that it is necessarily the best way to go as I do not have much experience of other ways of doing it. It is only right and proper that I mention that the idea of using Unicode Private Use Area codes for formatting in this way is seen in some quarters as entirely the wrong way to proceed. My wish is that the best system possible is produced so I have mentioned my ideas here as input for discussions on designing such a wiki engine and if they are used or not used then that is just how it goes.

[End of note by William Overington 19 March 2006]