<html> <body> Hi -- 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. For what follows, I'm using <a href="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"> 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. 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. 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. 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). 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. 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. Cheers, Alan At 03:37 PM 9/24/2006, Ian Bicking wrote: <blockquote type=cite class=cite cite="">Alan Kay wrote: <blockquote type=cite class=cite cite="">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 ...),</blockquote> 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. <blockquote type=cite class=cite cite="">A /minimal/ approach would certainly would not have to look just like Etoys nor be as comprehensive to be successful. </blockquote> 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. <blockquote type=cite class=cite cite="">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.</blockquote> If you could clarify what you mean by "scripting" that would also be helpful.  For instance, what would it mean for the chat application? <blockquote type=cite class=cite cite="">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 ...).</blockquote> 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:   <a href="http://patapata.sourceforge.net/" eudora="autourl"> http://patapata.sourceforge.net/</a> 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@colorstudy.com | <a href="http://blog.ianbicking.org/" eudora="autourl"> http://blog.ianbicking.org</a> </blockquote></body> </html>