Alan Kay wrote:
I think the bare minimum would be to have a page model (a la Hypercard,
but with a more flexible approach to "documents"), dynamic objects as
"turtles with costumes", where the costumes can be paintings, shapes,
and other media objects, and have them be scriptable using an interface
that minimizes or eliminates need to type, whose syntax is in
child-friendly terms, but which has a decent mapping to incremental,
vector and other mathematics. The "pages" should be usable directly on
the Internet via a plugin, etc. (And, of course it should be localizable
...),
There's also two major platforms on OLPC -- there's Sugar/GTK/Python,
and there's the browser/Gecko. The browser has the potential to be the
platform for much of what you talk about, though probably with some
major differences from what you discuss.
You identify three features:
1) Page model
2) Dynamic objects
3) Scriptable without typing
Pages of course are intrinsic to the browser.
Dynamic objects are somewhat intrinsic in the form of DOM objects which
can represent many kinds of visual elements, though DOM objects are not
very extensible. Specifically images are not interactive, though the
canvas has some potential, and SVG moreso if it is available (does
anyone know if it will be?).
DOM objects are strictly copies of some server-side resource (where the
laptop would often be its own server). I don't know if the copy changes
what you are thinking of an as object. That is, what happens to an
object on a page is limited to the scope and lifetime of that page. But
given explicit serialization you can save the object. As such, the
objects aren't really "live" -- but it also makes the objects much
easier to share.
In terms of scriptability, well, the story isn't great there. You can
interact directly with DOM objects. You could, I suppose, create a
graphical language of some sort. It may not even be too hard to do,
though minor details like how drag-and-drop works can be tiringly
difficult. Your logowiki experiment at least shows that some
improvements are possible over straight Javascript.
I personally think this is a much better strategy than plugins. Plugins
in a web page are just small applications, reverting to application-like
behavior in all the bad ways, but embedded into a web page, and I don't
know what the advantage of that is over just distributing the
applications directly. I suppose you save a visual context switch when
you launch (or switch to) the new application. But you also wrap your
application in the browser-based UI that is not well integrated with
your plugin -- all the controls are merely different means of escaping
from the plugin, not interacting with it.
Anyway, coming at this from another tack, what the browser accesses can
also be accessed by any other application. So a browser based strategy
is not exclusive of other strategies.
A /minimal/ approach would certainly would not have to look just like
Etoys nor be as comprehensive to be successful.
It's not clear what you consider the minimal approach. The three items
you mention before? I'm curious how you see this looking in its most
minimal form.
For several years we have been designing what we think will be a better
system with multiple UIs for different age groups (and one for
professionals as well), and just recently received a fair amount of
funding that will let us actually try out some of the new ideas. I think
the main motto for OLPC should be "Children First!", and this means that
such a scripting system should be part of the integration of all the
objects and UI needs on the machine.
If you could clarify what you mean by "scripting" that would also be
helpful. For instance, what would it mean for the chat application?
Putting it in as a separate stovepiped application would be missing the
point. Much of the integration in the current OLPC design is being done
in Python, and thus the children's system could and should be rendered
as a special view/UI on the OLPC world (and there is a possibility of
doing a more powerful, more media oriented base for Python than it now
currently has ...).
By "media oriented base", do you mean something like a Python object
representation for all kinds of media? Right now many of the APIs are
more command-oriented: "load this file", "show the image at X, Y", etc.
That's largely a choice programmers have made, not something
intrinsic... though Python programmers keep making the same choices
about this stuff, for whatever that means.
One thing that makes me reluctant to take this kind of approach in my
own software development is that it builds the importance of the OS
process and the objects in that process; I prefer treating both the
objects and the process as transient, and the process as one of many
(and so the object is potentially one of many representations of an
underlying resource). Well, often I do not design like this, but I
always feel better when I do. This seems more important in OLPC, where
the process boundary is an important way of keeping things from becoming
a mess. A laptop will exist for years without intervention from anyone
more experienced than the laptop users themselves, so you can only
facilitate experimentation on the children's part by making
experimentation safe.
Incidentally, I don't know if you have seen this before but Paul
Fernhout has been experimenting with ideas inspired by Squeak and
Morphic in Python:
http://patapata.sourceforge.net/
It's somewhat notable because it's the only serious attempt I can think
of that takes this approach in Python. I'm guessing this is the kind of
thing you are talking about when you say "media oriented", though I'm
not sure.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
