[olpc-software] AbiWord, HIG

[Alan Kay]

Hi Rob --

At 08:21 AM 3/15/2006, Robert Staudinger wrote:
>Hmm, the wiki bit makes me think. Are you considering to use AbiWord
>as frontend? Currently AbiWord is pretty weak at reading HTML (much
>effort has been put into good export). Also because of being page
>oriented results may differ quite a bit when viewed in the browser.
>If the first priority word processing use case is editing HTML maybe a
>mozilla based frontend should be considered. I've been playing with
>that idea (and code) some time ago (
>http://robsta.rsm-freilassing.de/projects/ , look for "Bongo")

Here's an interesting problem.
1. Let's agree for the sake of argument that Seymour Papert's ideas are 
really great and central for HDLT (about how children can best learn many 
important powerful ideas in math, science, and thinking via constructing 
dynamic models in a specially designed programming, media and 
communications system). Some of the implications of this point of view can 
be found in the pdf docs I referenced.

2. Another part of the puzzle is that the current SW "establishment" will 
only use some systems and not others, regardless of merit or demerit. So we 
should probably not attempt the massive task of "converting the heathen" 
here, but cater to them by making the children's system in orthodox 
recognizable tools.

3. And, whatever we wind up doing for the HDLT really has to run for all 
the other children in the world that are connected to the net -- this means 
it really has to run the same (we say "bit-identically") on "everything" 
(at least anything that has a 300MHz CPU or more), and especially Windows, 
Linux, and Mac and all combinations of browsers.

4. One part of the problem now becomes how to get facilities to children 
who don't have the HDLT. People often are afraid of plugins, there are 
firewalls, schools often reject them, etc.

If the web and browsers had been thought out at all reasonably, this would 
be easy. Something like Hypercard would already be in browsers and this 
would allow scripting of dynamic media in a reasonable and WYSIWYG way. Or 
Java could have been done in such a way that it is small and runs 
bit-identically in all broswers. Or security and protection could have been 
done in such a way to allow simple safe downloads of executables. Or ...

One way to look at the problem, given that none of the easy good things 
were done, is that a thin-client (like an enriched wiki) would be adequate 
(if awkward) if the browsers could handle dynamic graphics reasonably 
without requiring a download or update. (It's possible that someone has 
found a way around this -- if so, I'd like to hear about it.)

As you can see from the white papers I referenced, we deal with all the 
problems pretty completely and easily, but via a thicker client that has to 
be downloaded by the end-users. We run bit-identically by simply being a 
mini-os with complete facilities that the host's os thinks is an app. Then 
we do all the graphics, sound, media, tools, UI, etc. See 
http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html for how. This can 
also be done on the HDLT (and we've been running on the reference HW for 
more than 6 months).

But we are looking for a way that is more automatic for all the other users 
in the world. And we are even OK with the idea of giving up our own 
advanced tools in favor of something more recognizable to the majority of 
open source programmers so long as we can fulfill the requirements in some 
other way (after all, it's "children first" here, and they don't care what 
their environment is written in). But we do need to solve these problems 
somehow.

Cheers,

Alan