Talk:Wiki as a book reader: Difference between revisions

From OLPC
Jump to navigation Jump to search
(E-book standard proposal)
(Delete it all and start again)
Line 127: Line 127:


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

== 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/

Revision as of 23:03, 1 June 2006

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)

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

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

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/