[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [olpc-software] AbiWord, HIG

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]