[sugar] Interesting interface

[Ian Bicking]

Alan Kay wrote:
> _Etoys are so UI oriented_:
> To me, there are lots of different possible UIs for Etoys. The best 
> thing in Etoys is the universal object model that allows all media to be 
> mixed and scripted in a similar manner. Another important criterion for 
> an Etoys like system is to do away with typing on a keyboard to make 
> programs. Another is to allow unlimited parallel running scripts (young 
> children are much better at parallelism than at sequential code with 
> control structures, etc. There are a number of workable UIs for these 
> principles.

Regarding mixed media, well... more about that down in Reliability...

> The one we have now was originally done for short child-parent "lapware" 
> experiences making fun dynamic toys. The current tiles and how they are 
> obtained are very good for this. But for more extensive use, this is not 
> the best way to have a typing-free UI. For example, the extreme (and 
> useful) polymorphism would allow a very nice left to right script 
> building without typing. We've experimented with this but are waiting 
> for the next real version. Because all the objects are graphical, they 
> have scaling and rotation handles. This suggested that more handles for 
> other uniform operations (like delete, copy, slide, etc,) be included. 
> However, this could also have been done in MacStyle with pulldowns away 
> from the objects. Similarly, the viewers are one way to show properties 
> and behaviors, but these could have been done MacStyle. The individual 
> scripts are kind of cool when there are only a few on them and you have 
> a big screen, but one might like to have a nicer way to organize them, 
> especially on a smaller screen (and there are a few experiments buried 
> in the system for these).

Text programs seem okay to me, but I'll have to defer to you here on the 
program representation.

But I can speak a bit about the feasibility.  Within the CPython runtime 
it is possible to compile to bytecode from other representations (such 
as a graphical language), and to show useful debugging feedback after an 
error that refers to the original source.  I haven't done this myself, 
but I just looked at some code that does this (a templating language 
called Genshi) and it looks pretty reasonable.  But the CPython runtime 
isn't the only runtime on the system; there's no single runtime so 
there's no single way to script everything.  There is the message bus, 
and that is universal, but I don't know if it's powerful enough for what 
you want.  I suspect it isn't, but maybe it could be.

> This is why I'm ecumenical about both UI and underlying implementation 
> vehicle. The really important things for children's scripting don't 
> depend on the details of our particular UI or that it happens to be 
> implemented in Squeak. But the integration and uniformity and 
> interoperability of the media objects are tremendously important.
> 
> _On Reliability_:
> This discussion is out of the scope of this email, and has to do with 
> the tradeoffs between dynamic and static systems. But one way to look at 
> it from the user view is that it is not errors that hurt but whether or 
> not UNDO works for the error in question. (BTW, since Squeak is employed 
> in its own system building at all levels using extreme late binding, it 
> has to be more "reliable" in many senses than load and go systems, in 
> that it always has to stay alive to allow debugging of things that have 
> gone wrong.)

Well, I'm coming from a Python background, so it's not so different. 
Certainly not a static/dynamic distinction from Squeak.  But most Python 
does make a strong data/code distinction (there are object databases and 
things like PataPata, but I don't know if we'll use anything like that). 
  Like Squeak it's all very late bound, and it's a bug in Python (or a 
linked C library) if the process dies because of user error.

But I don't actually feel like undo is sufficient protection.  Much of 
my own opinion on this actually comes from my own experience with 
Squeak, though it was many years ago and I was a much younger programmer 
(though more experienced than these children will be, at least until 
several years from now).  When I was trying to do something in Squeak, 
I'd modify anything that made sense, adding things to Object and 
Collection and Point and whatever else.  Sometimes this was a good 
solution, sometimes the result was just the kind of scattered code that 
is typical when you're coding something you don't understand yet.

But what bothered me about the system was both the difficulty of sharing 
the results, and the decay I felt in the image I was using.  I didn't 
even know how to throw away my bad experiments, because I only would 
realize the experiments were bad once I implemented what was right. 
Simple undo doesn't handle that.  And the software I wrote was tied to 
my image in ways that were sometimes mysterious to me.  I didn't have 
any sense of what code was "mine" and what code was "Squeak's".

Python is pretty picky about this.  So you can't add methods to object, 
you can only subclass, and while you can mess around with other people's 
code and objects -- Pythoners coined the term Monkeypatch for this, 
somewhat irreverent, somewhat derogatory -- and it's considered fragile 
and a bit impolite.

So the way I'd like to see children modify the software is by doing a 
full and explicit fork.  For instance, if you want to change the chat 
activity, you copy the chat activity and start modifying it, and (if the 
system is designed right) you can have both your custom and the original 
chat application working on the system at the same time.  And if you 
don't change the persistence aspects, they can keep sharing data (which 
is external to the activity) and happily coexist.

> But I'm not trying to push the Squeak model on anyone. I'm trying to get 
> a few more things that I think are important for the children into the 
> OLPC discussion here.

The difficulty I see is that the EToys model -- I think -- is that it is 
a model involving live objects directly linked to each other living in 
the same memory space, all directly modifiable.

My own personal opinion (not necessarily shared by the Python community 
in general) is also that in-memory objects should be considered 
transient and low value.  You should always be ready to throw them all 
away and build them up again.  Or have those same objects represented 
multiple times in different processes.

> _On Activities:
> _I'm not interested in the desktop/file metaphor: this whole discussion 
> started because I thought that new Gnome document oriented model was a 
> good thing (and that quite a bit of experience has been gained in some 
> quarters over the years).

I don't believe anyone is planning a desktop/file metaphor.  There will 
be a document store, but it won't be the same as the filesystem.  How 
the store is accessed, I don't know -- I suspect there will be a variety 
of ways to access the data.  Some will be comprehensive, giving you the 
ability to view and modify everything, and some will be more specific.

But I also think they will be documents, not live objects.  They won't 
contain behavior, except occasionally in ways specific to the document 
type -- like an HTML file that contains Javascript.  No in-memory 
representation of the document will be considered a canonical or 
authoritative version -- only the (static and dead) document living in 
the store is authoritative.  And maybe even that copy isn't 
authoritative, if it's just an offline cache (or for some other reason 
the "original" document lives off the laptop).

So there's some limitations.  But I think there's still opportunities there.

> And you are right that I don't like the separated stove-piped activities 
> very much. I think a design space that started with the /appearance/ of 
> a web page (as mixed media of many kinds, some of them dynamic) and took 
> a more Hypercard-like view of how all this should be made, manipulated, 
> scripted, etc. using modeless WYSIWYG editing is the way to go. That is 
> what I'm arguing for here. It hooks the kid's space into one of the main 
> resources (the web) and gives them the best possible interface for 
> making all kinds of things and publishing and otherwise sharing their 
> creations.

A part of me thinks when the machine boots up a browser should open, and 
that's it.  Figure it all out in there, change the browser itself when 
we have to.  I don't know if anyone here would agree with me on that ;)


> _On Collaboration:_/ /
> Yes, collaborative editing of text is difficult, and it's not that much 
> fun to collaborate on a painting, but it is fun to collaborate on a game 
> because different children can make different parts of the game (some 
> can make cars, some can make spaceships, etc.) and many games can be 
> played collaboratively. Having separate objects, scripts, and many 
> parallel processes allows more to be done, and more to be done 
> collaboratively, etc.

This makes sense -- people are working on their individual 
object/documents, and bringing them together is then a task in itself. 
The collaboration can also take the form of copying (or creating from 
scratch), then merging/overwriting/adding.

> In one of our earlier systems (Playground, ca 1990) the user space was 
> large and one of the quadrants was shared. This allowed the children to 
> do lots of things, some outside the shared space, but still in contact 
> with it, and some inside, etc.
> 
> _On Documents:_
> I'll end as I began, by saying that a document model is a very good 
> basis for this and many other end-user designs. I have always advocated 
> getting that straight first since it defines the integration and 
> interoperability that has to be facilitated.

Indeed.  Hopefully Ivan will have a first draft about this soon.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org