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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
