[Etoys] Projects and Journal

[Bert Freudenberg]

No response, yet?!

This will fundamentally influence the user experience on the OLPC.  
The Journal's notion of "keeping" is actually pretty much precisely  
what a project is in etoys. However, due to the design of the journal  
and the security compartmentalization we will not be able to serve  
multiple projects in one VM and image. Opening a new project will  
only be possible by starting a new VM and image. Switching between  
projects will not be a cheap operation.

So in contrast to what I wrote below there is a one-to-one  
relationship between activity instances and journal-entries. This  
wasn't clear to me until yesterday. Currently it is possible to  
create multiple journal entries from one activity instance, but  
actually the actual model would probably be that creating an object  
and launching a fresh activity instance is one and the same operation.

Other activities are far from realizing the intended user experience,  
which of course would include that on resuming the UI returns to the  
exact same state it was when it was interrupted. We are in a much  
better position for this because that's how Smalltalk always worked  
(I wonder where they got the idea ...). Still, since the reality of  
current Squeak implementation clashes enormously with the reality of  
Bitfrost and Sugar, we'll have to come up with better ideas for  
integration.

I'd really like to discuss this face-to-face but given the time  
pressure, email will have to do ...

- Bert -


On Jul 12, 2007, at 14:58 , Bert Freudenberg wrote:

> We need to think about the user experience of Etoys projects on the  
> XO. If someone is not yet familiar with the idea of the Journal,  
> please read
>
> http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/ 
> The_Laptop_Experience/The_Journal
>
> Projects are the fundamental unit of work in Etoys. So we want to  
> keep them in the Journal and resume them. However, that should be  
> mostly automatic, in contrast to the explicit save dialogs we use  
> on regular PCs. Also, we cannot save the whole image. I don't think  
> kids work the same with projects as Alan does. And I'm not sure if  
> Alan ever worked in the browser version of etoys, I only know his  
> images which have a gazillion projects preloaded ...
>
> But, ideally the user experience should be *as if* the image was  
> indeed snapshot continuously. Here's an idea I came up together  
> with Michael:
>
> We always ever have only one single project loaded at a time. This  
> is good for limited RAM. Before entering a different project, we  
> store the current one in the Journal. Then after we are in the new  
> project, purge from memory the old one.
>
> On startup, we might want to load the latest project in the  
> Journal. This would be analog to "image saving".
>
> I am working on saving to / retrieving from the Journal. This will  
> hook into the old project saving logic for now. But I think  
> something along the lines above is needed, too. As for performance,  
> with the better book morph support we do have now, perhaps having a  
> thread of projects isn't really that important?
>
> Some more thoughts below ...
>
> Versions
>
> The Journal will keep each version of the file. To keep down on  
> disk size, it is supposed to only store differences between  
> versions. That means we need to store projects in a way that  
> enables diffing. A textual representation for projects helps with  
> this, but if we are going to compress it, we need to take special  
> care (for example, like the "rsyncable" gzip option http:// 
> glasnost.beeznest.org/articles/206).
>
> We might also want to know if actually something changed in a  
> project, that is, wether we need to save it or not. Might be hard.
>
> Meta data
>
> For finding projects in the Journal we will want to add some  
> keywords. That could be strings the kid put into the project or  
> player names (if not automatically generated), maybe even variable  
> names - everything someone typed might be useful for retrieving the  
> project.
>
> - Bert -
>
>