[sugar] Interesting interface

[Ian Bicking]

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