Wiki as a book reader
O, a pointer to a buffer is part of the request. ,
Contents
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.
- This seems to be solved for download. People produce Wikislices, sets of static HTML pages of Wikipedia content, and make them available as Collections. WikiBrowse is a fancier solution involving a local web server that serves content from a compressed Wikipedia dump. -- Skierpage 03:59, 18 October 2008 (UTC)
Drupal is an open source content management platform that might be a solution to the page grouping requirement through the use of its book module.
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 LogoWiki which 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.
- NB: UNICEF has a small group working on making such an interface.
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?
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? -- 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.]
- Indeed, the user can press a button to rotate screen display on the XO, so ideally content should re-lay out to both formats (well-written HTML and SVG can do this); other content will require the user to zoom in/out in the Browse or Read activity.
Existing book readers and formats
Before people make too many decisions about book storage formats and digital 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 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.
