[Etoys] Projects and Journal

[Bert Freudenberg]

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 -