Talk:Wiki as a book reader

From OLPC
Jump to navigation Jump to search

Javascript microwiki

TiddlyWiki plus synchronization software would be a start. Something like a tiny webserver that used SQLite or dbh for storage would be enough.

We are currently looking into MoinMoin. It has a very good extensible architecture. It is fairly easy to add the missing features by adding actions, macros, and parsers. I will take a look at TiddlyWiki though.

I just found out about ZiddlyWiki, which uses Zope. --BobBagwill 19:39, 30 March 2006 (EST)

ZWiki-Based Dynamic Ebook Reader

There is already a GPL Wiki called ZWiki[1] that could also be appropriate as for the base of this ebook reader. It provides natively:

Many other interesting features:

  • WYSISWYG
  • File Upload, Attachment to pages
  • Access Control
  • Page history, issue tracking
  • Uses Python
  • HTML and MathML on browsers like Firefox
  • Manageable: "Zwiki benefits from Zope's manageability. For example:
    • ease of installation - works anywhere zope works, standard zope product installation
    • replication - ZMI copy/paste, import/export, ZopeWiki:ZSyncer
    • backup - as above, or backup single Data.fs file
    • customization - define custom UI templates, use acquisition, use the ZMI to edit properties
    • upgrade - backup Data.fs, install latest Zwiki, restart Zope; objects generally auto-upgrade
    • undo - zope's undo feature allows recent mistakes to be reversed
  • Backend storage can be text files, MySQL, SQLite etc.
Big problem with Zwiki. It uses Zope and Zope is a big and complex piece of software. The OLPC is a system with limited memory and limited storage. It is not appropriate to run heavy-duty server software on such a machine. The software running on the OLPC needs to be stripped down to the essentials. Using Python is good because it reduces the storage footprint, but software still needs to be stripped down and have FEWER options built into it.


Version control?

While reading the page, I couldn't help but think "subversion can do that" and "subversion can do that as well" and "yeah that should also be possible with version control". So, how about some kind of mixture between version control and wiki?

Besides, I wanted to say that I don't like those ideas about using special unicode characters:

  • breaks the concept
  • clutters the document "source"
  • disregards needs of colour-blind people
  • mixes not only formatting and content (which is bad enough in HTML) but authoring information in addition

All that is just IMHO and my 2 cents.

I'll sign up a different time cos it's late in the night. 84.158.225.130 19:11, 21 March 2006 (EST) (Benjamin B.)

Notes

> Besides, I wanted to say that I don't like those ideas about using special unicode characters:

Thank you for your comments.

I realize that the Unicode Private Use Area characters would mix formatting and content and would agree that that may not be desirable at all and, for some aspects, such as font choice and type size which could sometimes or even often apply to a whole page may always not be necessary. However, if one wants to have a system whereby, say, a student types a page of text in blue and then wants to make a few of the words stand out by making them in red, it seems to me (though I am entirely ready to learn of any alternative possibility) that there is no way to do that other than by mixing formatting and content. That formatting could be done either by Unicode Private Use Area characters or by some sort of HTML-like system with someway bracketed English-like text as one prefers, but if one needs to indicate where the red ink starts and where the blue ink is again used, mixing formatting codes and content may be necessary.

William Overington 1155 GMT 22 March 2006

Distributed Version Control?

One difficulty with svn is that it's server-based, and therefore ill-suited to ad-hoc mesh networks; a distributed version control system (such as Bazaar-NG) might be a better fit. (Bazaar-NG itself might have a problem that it expects disk space to be cheap and plentiful; but that's an implementation detail...) Basically, a distributed version control does away with svn's server, but still keeps track of which change comes from where on a peer-to-peer basis. Rather than the school server being a cache for a higher-level server, with the implication of read-only content, it would be bidirectional: changes made by the children can be consolidated by the teachers into the school's server and then forwarded either upstream or directly to other schools. It can also cope with things like sneaker-net distribution while still reliably keeping track of version history. --59.167.68.236 08:48, 19 November 2006 (EST)

Version control and formatting

In a way, wiki is a version control tool. It keeps history of all the changes made, allows you to diff between any two versions of the document and to revert to an older version when needed, some versions even detect that the version you are working with is different than the last committed version and gives you a merge view when you commit yours.

So in that sense, subversion is more of an alternative than it is complementary. There is no reason that prevents us from replacing the underlaying storage mechanism in wiki (file system or database) with subversion, making use of the branching capabilities and other features that subversion provides. But some of those capabilities will need to be exposed through the UI before the usr can make use of them.

I am afraid though that it would complicate the user interface to a degree where it negatively affects the usability of the whole application. Especially that I think subversion is of little added value in this case.

Regarding formatting, unicode formatting characters seem to complicate the formatting process to the degree that wiki could loose its appeal as an easy-to-use authoring tool. If the user is interested in providing more sophisticated formatting, then CSS is where the state of the art seems to be today in regards for formatting. It is easy, clean, and seperates text from formatting (which was another objection that I read here).

Programmable Content

[Start of note by William Overington 9 April 2006

In the OLPC News for 8 April 2006 there is the following text, here displayed using italics for the quotation.

3. Seymour Papert, Alan Kay, Walter Bender, and other members of the team spent time thinking through many aspects of the eBook/Wiki platform. Alan demonstrated a wiki that supports modifiable and executable LOGO programs within the pages of the wiki itself. It is this type of dynamism we will be supporting in the eBook. Walter is pulling together a team from the Mediawiki community to build out the basic infrastructure.

Having had no contact with LOGO except for a basic try years ago, I thought that now is the time for me to try to learn more. A web search produced the following link.

http://el.media.mit.edu/logo-foundation/

End of note by William Overington 9 April 2006]

JavaScript

Javascript makes a fine beginners' language. You can use it to do math, graphics, games, etc. All you need is a modern web browser. --BobBagwill 19:43, 30 March 2006 (EST)

A problem which I found with using JavaScript is that if I tried to do addition of two numbers, I found that I ended up with something like the following, this being because otherwise the JavaScript engine would assume that the + meant concatenate rather than add.

z=1.0*x+1.0*y;

Maybe there is some way to avoid that problem, but it seems that that could be confusing to a beginner. However, JavaScript does have some uses in programming.

Here are some pages which I produced using JavaScript.

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

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

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

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

Graphics with JavaScript was not really possible, though it is possible to manipulate whole pictures. I produced the following as "A JavaScript Program Inspired by a Hologram".

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

I did read somewhere of someone producing graphs by a technique of using lots of graphic files each 1 pixel wide. 

http://davidbetz.net/graphics/ --BobBagwill 10:48, 3 April 2006 (EDT)

However, I was not an expert with using JavaScript: also I only ever did client side JavaScript, not server side JavaScript, so maybe more could be done with JavaScript graphics than I realized.

I did manage to produce a system which I called 1456 object code whereby text in parameters of a web page applet call is used to customize a ready-made Java applet.

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

This was, if I may so myself, very successful. However, programming it was directly in object code, so it is not suitable for getting people started with programming.

I got it as far as rotating wire mesh objects using quaternions.

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

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

However, maybe a system whereby a ready-made Java applet is programmable with a simplified programming language could be produced.

William Overington

31 March 2006

Javascript manipulating SVG is probably the way to go. --BobBagwill 10:48, 3 April 2006 (EDT)


sandbox

E-book standard proposal

What I can propose to you guys that meets all your needs, is a SVG. To edit this format you can use inkscape, and other open source tools. You can edit it on notepad and it's unicode, you can do animations and more.

Readable on firefox, Internet Explorer, etc. You can make available locally "without-server", or online, it's your choice.

Server-side/client-side.

Print multi-page on printer/browser through FOP on apache (converts to pdf).

It's already a standard and I think it's a good format to use for this type of universal format need.

Questions / help: ramonklown [at[[ pop.com.br

Sorry but SVG cannot represent text except as graphical text blocks. Unlike NAPLPS you cannot have flowed text blocks in SVG. On the other hand, if your text document is XML then you can include SVG in the main XML text. SVG can go inside a text document but a text document can NOT go inside SVG.

Delete it all and start again

I suggest that this entire page be deleted and a new page started.

Wiki is NOT an e-book reader! The web browser included in the OLPC is an e-book reader. Wiki is a database format which could be used for e-books. On the other hand, any Wiki can be converted into a single HTML or XML file or something like a Plucker file. So, Wiki as an e-book delivery format seems unlikely.

On the other hand, Wiki as an application for gathering and organizing notes, seems like a reasonable idea. It can even morph into an application with no browser involved at all. If you have not experienced Wikidpad then you really should try this. http://jhorman.org/wikidPad/ Windows only at the moment but it is Open Source so is ripe for porting.

Another tool, similar to Wiki is the LEO outliner. It is written in Python and should run on all platforms. http://personalpages.tds.net/~edream/front.html Note that LEO's capability of including aliases or clones of any node give it the ability to represent the same web of links as a Wiki does. From the user's viewpoint you have the same flexibility to organize information your way.

But back to the core of my argument. Please, please change the page into a discussion of Wiki as ebook format and if you really believe it should be DELIVERED in that format, rather than a single flat HTML file, then call the page "Wiki as ebook delivery format". But you still won't stop me from calling for it to be collapsed in a single file. Go look at TiddlyWiki to see why. http://www.tiddlywiki.com/

Format control of text

Excessively long text that wasn't in flow with the main page.


I am not sure why we wouldn't just use CSS, which allows both author and reader control and is certainly up to the job in terms of pagination. There could readily be a style-sheet for BW portrait and landscape, as well as Color portrait and landscape. (Maybe this should move to the discussion page?) -- Walter

[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).

[Supplementary note by William Overington 20 March 2006

I produced some authoring-time glyphs for the colours. They are in my Quest text font.

http://www.users.globalnet.co.uk/~ngo/QUESTTXT.TTF

http://www.users.globalnet.co.uk/~ngo/questtxt.txt

The designs are based upon the Petra Sancta method of depicting colours in old black and white books about heraldry. For example, vertical lines for red, horizontal lines for blue.

They can each be accessed using WordPad on a Windows 98 PC using an Alt code.

Alt 62432 to Alt 62447 repespectively for the colours listed above.

If these were used in a page authoring system for the future wiki system here being discussed then the content author would not need to use the code numbers. The content author would simply, in authoring mode ordinary, position the cursor line before a text character and then click on one of sixteen coloured buttons within a text colour palette on the screen and the code would be inserted into the text and the display would alter. If the content author chose to go into authoring mode special, the authoring-time symbol for the colour would be shown in a black and white display. ]

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]

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Talk:Wiki_as_a_book_reader&oldid=187465"