[sugar] Interesting interface

[Alan Kay]

Hi --

Well, even though there was no good reason for the browser being done 
in such a limited way (and, worse, a way that severely limits 
attempts to fix the problems), it is the way it is, and as such is a 
real show stopper. The DOM is the main problem, and JS (while not so 
bad expressively) is just much too slow and has such a limited 
environment (and theory of environment) that it is really not up to 
making a separate OOP model of graphical objects, etc. The problem 
here is that most of the "scripting languages" are essentially "glue" 
languages, and there is not enough fundamental stuff in the browser 
that runs fast enough for gluing to work very well.

For what follows, I'm using 
<http://www.squeakland.org/pdf/etoys_n_learning.pdf>http://www.squeakland.org/pdf/etoys_n_learning.pdf 
and 
<http://www.squeakland.org/pdf/etoys_n_authoring.pdf>http://www.squeakland.org/pdf/etoys_n_authoring.pdf 
as references and background.

What I'm thinking of here is that it would be really good to do the 
children's system around an ability to publish and share their 
creations -- and for them to be able to collaborate with other 
children around the world. So integrating through the web seems like 
the most natural approach. And, for OLPC integrating through the wiki 
that Ivan is doing seems like a good way. What I've been nudging 
about is that the media on the wiki should be WYSIWYG and dynamic and 
scriptable by children.

1. One way to do that (up to the barriers discussed above) would be 
to use JS to make something like LogoWiki but stronger. At some point 
we run out of steam. OTOH, for example, we know how to make a JS 
engine that is about 20 times faster than the ones in the browsers 
and this could do quite a bit more.

2. Another way to do this has already been done, and that is to 
bypass the browser resources and run (say) Squeak Etoys as a plugin. 
This allows Etoy pages to be found in a browser, automatically 
fetches them and launches the Squeak Etoy plugin to run them. This 
gives absolutely WYSIWYG authoring to all the media on the page, 
allows children's creations to be saved automatically, both locally 
and back to a web server, etc. This year, we've also experimented 
with using the OpenDocument conventions for these Etoy pages (so that 
they are in a format that is more recognizable by the open source 
world). It is very easy to do a WYSIwiki here because Squeak has lots 
of its own rich text as part of its media resources.

I don't quite understand your comments about the problem with plugins 
(we simply over-ride everything and write on our own canvas and 
handle our own UI -- in fact, we allow the child to get rid of the 
browser chrome so the whole screen is available for their creations). 
The main problem with plugins is that many SysAdmins won't allow them 
to be downloaded. This is not a problem for OLPC, but is a problem 
for children using other equipment that we want to share with.

3. However, I think the best way to do this would be to have a richer 
and more dynamic theory of objects on the OLPC machine, and to use 
some of these ideas (via Python) to make a UI that allows young 
children to script and (perhaps through a tiles UI) to do it without 
having to type on a keyboard.

(I have seen Fernhout's stuff and it is somewhat in the right 
direction, but currently misses many of the needed amenities and UI 
design.) But the UI doesn't have to be the way we do it, it just has 
to be above a pretty high threshold so it is smooth enough for the children.

We certainly don't want to make anything the child deals with have 
any reference to the OS, etc. ... In part because we should want to 
have the OLPC environment run on any machine and underlying OS 
(Squeak's does, so it can be done).

IOW, the children's environment should be built so that it is quite 
portable (Squeak's is, so it can be done).

Then we should make for the children's objects a viewable and 
manipulable API to allow them "Model-T" access to the things in their 
world. "Scripting" is (a) being able to manipulate and extend 
existing objects and (b) to make new objects with similar 
capabilities. For example, Squeak's Etoys scripts can run as fast as 
Squeak, so it is possible for a child in a two line script to make a 
real-time sampling synthesis synthesizer from scratch. This provides 
a wonderful and real glimpse into sound and starts thinking about how 
the more complex "Ferrari" of Csound might work.

What I'm urging here is not new invention, but to simply not lose 
what was so good about Hypercard for end-users, and what has worked 
quite well with children in Etoys. I will support any better designs 
(as I said, we think something much better than HC and Etoys is 
needed and can be done), but urge OLPC not to do anything retrograde here.

My current notion is that Ivan's wiki is the key here. He is making 
it nicer than existing wikis, and with dynamic scriptable objects, it 
would be nicer still,and start to be the universal integrator for all 
the media creations of children. If we think of "new-web" pages as 
the integration media then I think the design starts to become 
cleaner and more scalable to the whole world of computing.

Cheers,

Alan

At 03:37 PM 9/24/2006, Ian Bicking wrote:
>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 | ianb at colorstudy.com | http://blog.ianbicking.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/sugar/attachments/20060924/012b9040/attachment-0001.html