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 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 different mediums (create them, edit them, comment on them, share them, etc.)
The following use cases describe the most probable points of intersection between media, roles and interaction models:
- 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 curricula.
- 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 relevant 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 a local exception that is not governed by the rules described in the original text.
- Before people make decisions on the technology to be used for this, they should make sure they have some hands-on experience with tools like Hyperstudio (Logo-based) or Hypercard. You can download a Hyperstudio Preview from http://www.hyperstudio.com. Hypercard itself has not been distributed for years but Revolution is available in a trial edition at http://www.runrev.com. This implements the hypercard language and the card stack model. Wiki may in fact be too simplistic for the kids because it does not allow active content, i.e. application code
- 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.
- This is already available. Get a paper book, scan it, compress it with DJVU and display it with the Evince reader included on the OLPC.
- 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 version of it should be running on the local machine. This would either be a Python-based server running locally or something like TiddlyWiki which runs in the browser. This will have additional added advantages, such as providing the children with a more powerful way to store their notes and thoughts than 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 where 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 a lot of time to render, consume a lot of energy from 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 separately, which would not be doable for the average size textbook.
Given those two alternative, it becomes apparent 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 paths for a constructionist is programming. This was clearly demonstrated by the early success of LOGO in teaching children math skills. In order for this to succeed, 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 is that wiki servers today are designed to be stores of formatted text.
Wiki could be enhanced as a constructionist education tool if its front end were to be integrated with an educational programming language as an interactive front-end interface.
For example, try the toy demo LogoWikiwhich has a LOGO interpreter in JavaScript and does not need the wiki-mode for programming, testing or saving. (This is an experiment so be gentle.)
This can be used without downloads, which are sometimes difficult or forbidden in schools, and can be taken further to make a Hypercard-like WYSIWYG system.
Via a plug-in such as Squeak uses (e.g. see Squeak Etoys, Squeak Etoys Media), a full range of authoring, compatible with the web can be accomplished within a browser.
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.
Existing Wiki Code to Start With
There is already a Wiki called Wikidpad that may be appropriate as the base for this type of ebook reader. Unlike most wikis, it is designed to be run as a GUI application, not as a web server. In addition, it is targetted at the individual user who needs to organize their work, their plans or their writing.
Strong points of Wikidpad:
- Open source tool written in Python
- Uses a single SQLite database as datastore
- has minimal GUI requirements making it easy to port from wxWindows to GTK
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]
Additional question: Should the READER be able to choose?
[Reader should definitely be able to choose. I frequently read long PDF documents sideways on my laptop using the rotation ability of Adobe Acrobat and the full-screen display. I can hold the laptop sideways like a book and my left thumb is next to the right-arrow key which tells Acrobat to turn to the next page.]
Existing E-book readers and formats
Before people make too many decisions about E-book storage formats and E-book reader features, it would be a good idea to spend some time surveying previous efforts. If you don't have experience using a PDA, then buy an old Palm or Zaurus, install Plucker or OpieReader and try them out. As far as Ebooks are concerned, the OLPC is just a bigger and faster PDA.
In addition, I think it would be a good idea to build a prototype e-book reader in Python that uses a standard XML document format. Get lots of people to try this out, add and subtract document formatting features, fiddle with the UI, etc. Then, once you have something that works well, if someone has actual data showing that a non-xml format takes less space on the JFFS2 filesystem than plain XML, then the e-book format can be changed.
Personally, I think that the ideal e-book format for the OLPC will be a modified form of XML. Each document will have two parts. The first part will be a compressed form of the XML hierarchical structure with byte offsets into the second part. The second part will contain the pure UNICODE text. However, the sequence of the text will not be the same as in the original document. It will have been "scrambled" in order to take advantage of the JFFS2 compression capabilities. JFFS2 compression works only on a single virtual block so if you can move the text around so that similar runs of text are close to each other, then you will get better compression. The byte offsets allow for this to be done. It will be processor intensive to create an ebook but decoding it will be as quick as parsing XML.