<html> <body> 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: <blockquote type=cite class=cite cite=""> <blockquote type=cite class=cite cite="">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.</blockquote> 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... <blockquote type=cite class=cite cite="">For what follows, I'm using <<a href="http://www.squeakland.org/pdf/etoys_n_learning.pdf%3Ehttp://www.squeakland.org/pdf/etoys_n_learning.pdf" eudora="autourl"> http://www.squeakland.org/pdf/etoys_n_learning.pdf>http://www.squeakland.org/pdf/etoys_n_learning.pdf</a> and <<a href="http://www.squeakland.org/pdf/etoys_n_authoring.pdf" eudora="autourl"> http://www.squeakland.org/pdf/etoys_n_authoring.pdf</a> ><a href="http://www.squeakland.org/pdf/etoys_n_authoring.pdf" eudora="autourl"> http://www.squeakland.org/pdf/etoys_n_authoring.pdf</a> 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.</blockquote> 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) <blockquote type=cite class=cite cite="">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.</blockquote> 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. <blockquote type=cite class=cite cite="">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.</blockquote> EToys is so UI-oriented, I have a hard time separating the UI specifics of EToys from the underlying idea. <blockquote type=cite class=cite cite="">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).</blockquote> 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. <blockquote type=cite class=cite cite="">IOW, the children's environment should be built so that it is quite portable (Squeak's is, so it can be done).</blockquote>> <blockquote type=cite class=cite cite="">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.</blockquote> 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. <blockquote type=cite class=cite cite="">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.</blockquote> 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@colorstudy.com | <a href="http://blog.ianbicking.org/" eudora="autourl"> http://blog.ianbicking.org</a> </blockquote></body> </html>