[sugar] Interesting interface

[Ian Bicking]

> 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