[sugar] Interesting interface

[Alan Kay]

Hi Ian --

Thanks for the extensive reply.

On plugins:
Right now they are the only way I know to get around things that the 
browser can't pragmatically do for the user (including taking over 
the entire browser display for arbitrary interactions and authoring). 
But because of the needless security problems SysAdmins (especially 
in school systems) often bar the download of needed plugins, and thus 
the children can't get what they need.

But, at the next level wrt OLPC, if the OLPC system were presented as 
an app on other platforms, then it would probably have enough buzz 
and cachet to get school systems, SysAdmins, and parents to allow the 
children to download it. This is probably the best route right now - 
but it does require that the OLPC system be multiplatform (as I 
believe all systems on the net should be).

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.

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).

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.)

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.

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).

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.

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.

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.

Cheers,

Alan

At 01:01 PM 10/2/2006, Ian Bicking wrote:
>>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.
>
>Personally I don't mind the eclectic underpinnings of the browser. 
>Well, I mind it, but not enough to keep me from using it.  It's the 
>most important platform of our time, so it's worth putting up with 
>it warts and all.
>
>Of course OLPC can build new platforms, as we're discussing here...
>
>>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.
>
>I don't think Ivan has a WYSIWYG wiki in mind.  He's pretty set on a 
>wiki markup language.  You can make vaguely WYSIWYG-like tools on 
>that, but they are more like a facade around the underlying markup 
>than a real WYSIWYG experience.
>
>I don't know what the story is for compound documents.  I'm assuming 
>in the wiki you just make explicit links between 
>documents.  (There's a garbage collecting problem there -- how do 
>you know you can get rid of a document that was only created for the 
>purpose of another document, like an embedded image? -- not really 
>related here, but it just occurred to me)
>
>>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.
>
>I'm comparing a plugin to a stand-alone application.  With the 
>stand-alone application you click on the link, something with a mime 
>type of application/x-squeak or whatnot is served up, you launch the 
>program that can handle this mime type, and then you are 
>done.  There can be some small interruption if the browser asks you 
>about launching the file, but you can get around that too.
>
>In comparison a plugin does almost the same thing, except 
>potentially with a dialog to install the plugin, and once the plugin 
>is installed the media is displayed without any dialogs, and you get 
>a little box on the page to run in.
>
>So I don't really see the benefit of the plugin.  It's not really 
>part of the web, anymore than the media file handled by an external 
>application is part of the web.
>
>>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.
>
>EToys is so UI-oriented, I have a hard time separating the UI 
>specifics of EToys from the underlying idea.
>
>>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).
>
>Running a virtual machine on top of the host machine is, of course, 
>possible.  Integrating with the underlying OS in a portable manner 
>is harder.  Right now it doesn't seem like a big issue for OLPC.  If 
>it was then we'd have to think about what level of insulation we 
>want, how much we want to integrate with the rest of the 
>environment, etc.  Figuring out that compromise is hard.  But for 
>now entirely avoidable.
>
>There's also a lot of build issues that I can't speak to at all (for 
>things like GTK, Cairo, etc), except that they seem hard, but 
>probably become easier once we totally separate all libraries from 
>the libraries provided by the underlying OS.
>
>>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.
>
>I think there are conflicting architectural goals.  OLPC needs to be 
>really reliable, which means that children can't easily hose their 
>systems, that the security is reliable and safe, and that the 
>integrity of the system doesn't decay over time.  I'm assuming that 
>these computers are going to land without much in the way of 
>training or support staff, so the software has to be really 
>reliable.  Letting a kid dig around in a junk drawer that contains 
>razor blades will not give the child a passion for exploration.
>
> From that perspective the Squeak model where all the objects live 
> in a big persistent environment where you can manipulate everything 
> is a bit scary to me.  (But I haven't worked in a Squeak 
> environment for years, so maybe that's more refined than when I 
> last was there.)
>
>Now I don't know that there's some insurmountable conflict here, but 
>there is a real conflict between these goals.
>
>Just in terms of UI, I see some conflicts:
>
>* Currently Sugar has "activities" as the central 
>metaphor.  Activities are applications, probably in a style you 
>don't like.  Since we don't have a metaphor for documents yet, it's 
>not clear what an activity will really turn out to be.  That is, 
>Sugar doesn't look like a desktop where you double click on some 
>file and it opens up an application that edits or views that 
>something.  Because we have no desktop and no files.  So it's a 
>pretty incomplete picture right now; the few activities that exist 
>don't have much of any persistence.
>
>* The window manager being used leads to a single activity being in 
>focus at any one time.  So you can't really mingle activities 
>together -- one activity is in full control at any one time.
>
>* I don't think an activity is an object in the manner you are 
>thinking.  Certainly we can support certain operations on activities 
>-- for instance to clone an activity to make it editable (preserving 
>the original activity so the edits can be reverted by deleting the 
>cloned activity).  But I don't think activities will be particularly 
>inviting places to begin programming, not to mention general exploration.
>
>* I think the objects you are thinking about are more like documents 
>or media.  An activity might be seen as a generator of documents, 
>and a view on documents.  For instance, a chat application generates 
>chat history, and that history is a document.
>
>* I guess another kind of object is a reference.  A buddy is a 
>reference.  There's no single set of actions you can perform on a 
>reference.  The chat application adds a "start chatting" action to 
>buddies.  Buddies in general have a "is reachable?" property.  You 
>can also pass around the reference -- e.g., add a buddy to a work 
>group, which doesn't do anything *to* the buddy (or require the 
>buddy be reachable).  Instead the action happens to the work group 
>-- a concrete object that contains references.  We don't have any 
>general way to think about references.  We have URIs for many 
>documents, and I imagine all the documents internal to the laptop 
>(like a chat history) will have URIs too.  I guess we assign a buddy 
>a URI?  A URI alone is just an identifier, so a lot more 
>infrastructure is called for.  The thing on the other end of the URI 
>is the document, but the document is not all-encompassing (maybe not 
>even retrievable).
>
>* This leads me to think that annotations are really important. 
>Annotations can be accumulated, and don't require modifying the 
>thing-being-annotated.
>
>Hmm... well, that wasn't really a set of bullet points so much as my 
>wandering thoughts.  Hopefully useful.  Annotations (and the simpler 
>idea of containment) make a lot of sense to me here, and maybe can 
>provide a way to provide some of the experience you want as well.
>
>As an example, Ivan and I were talking about collaborative editing a 
>little.  Collaborative editing is rather hard; when two people edit 
>a document at different times without synchronizing (by choice or 
>necessity) they then have to merge their changes, you can get 
>conflicts (which are just plain hard), not to mention subtle issues 
>like losing a sense of voice.  With a synchronized system like 
>sharing an editor live, or using a centralized live wiki, it's not 
>so bad.  But a lot of educational situations start with some starter 
>content, and every child makes their own branch, and you aren't 
>really trying to keep things synchronized.
>
>So collaborative editing is perhaps the wrong idea entirely for many 
>problems, and annotation is much easier to consider.  You can share 
>comments.  You can even try to move comments between documents (for 
>instance, comments on the original material that you are reacting 
>to). You can suggest edits with an annotation -- and then share that 
>suggestion -- but merging is done manually.
>
>That's just the idea of annotation applied to text.  I'm not sure 
>exactly what it means applied to other things.  I guess it implies 
>more wrapping, less direct modification, and there can be multiple 
>wrappers around any one object so annotations are less authoritative.
>
>>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.
>
>As I've been looking at DBus more closely, and I think that this 
>will also be a very important extension point.  But if we start 
>adding lots of ways to control applications over DBus we'll get 
>something like AppleScript, which is nice I guess, but clearly not 
>what you are thinking about.  However it works, it is going to have 
>everything to do with the way documents work and that's still a 
>pretty open question.
>
>
>--
>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/20061003/66b711d6/attachment-0001.html