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 -
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 -
Bert,
No response, yet?!
Sorry about that...
I may be in a very old fashioned mind set, but still explicitly saving a project when the user is confortable has some virtue. Following that a senario of user experience is like this?
1. At the very first time to launch the Etoys activity from the bar, he would see a blank or some initial screen that encourage the user to create a new project see an example or a project already exists.
2. If he creates and enters a new project, Etoys creates a new project in the image (as we do now) and go there. (2.1, probably we just create a new activity (with name "Unnamed" at this point.)
3. He would (should be able to) checkpoint his intermediate work. He presses the "save" button for this purpose.
4. His work will be interrupted by himself (to choose to do something else), or the system decide to warn the Etoys VM to quit.
5. The user might want to simply abandon the ongoing work here, or save the current status. Let us say it shows a dialog and ask the user whether the project should be saved.
6. If the user wants to keep the ongoing project we save this as a new activity created at 2. And, the user probably want to name it here.
7. If the user wants to abandon, should it create a journal entry as well but later the user delete it in Journal?
8. If the system decide to kill Etoys, it could just do the same thing as 6. If we decide to create an activity at 2.1, it can just add a new version of it.
9. If the user chooses to open a system provided example, we proably wouldn't want to create a new activity when it is opened. He should be able to make changes and save it.
10. If the user chooses to open his or his friends past work, it should be a new version when a "meaningful" change is made to project.
11. When the user wants to see another project/activity on the disk... Do you say that the VM has to be re-launched?
12. So, for a presentation like usage (bunch of slides), an activity should be able to contain multiple projects.
Ok... Senario two:
13. Alternatively, we cut all these complications, and the user always stay in the "Current Etoys" activity. It is checkpointed upon pretty much every time the user is leaving Etoys. Can it be that loading a project from file just loads it into the currently running image (without trapped by Bitfrost) here?
14. Oh, but, when the user asks to save, the user gives a name and create a new version of the activity. But, "Current Etoys" activity is different from that activity, so you cannot write into it?
In any case, the problem is the saving/loading time of a project. We've been thinking about it but not much real progress.
And, in any case, making new activity or storing into different activity is not easy because of the security limitation?
Sorry for throwing unorganized thought...
-- Yoshiki
It is very good as if we don't need to care about project saving.
This is much different from current model. But I want to try how Bert's idea realy works. We can back Yoshiki's explicitly saving model anytime if it doesn't work well.
Cheers, - Takashi
Yoshiki Ohshima wrote:
Bert,
No response, yet?!
Sorry about that...
I may be in a very old fashioned mind set, but still explicitly saving a project when the user is confortable has some virtue. Following that a senario of user experience is like this?
At the very first time to launch the Etoys activity from the bar, he would see a blank or some initial screen that encourage the user to create a new project see an example or a project already exists.
If he creates and enters a new project, Etoys creates a new project in the image (as we do now) and go there. (2.1, probably we just create a new activity (with name "Unnamed" at this point.)
He would (should be able to) checkpoint his intermediate work. He presses the "save" button for this purpose.
His work will be interrupted by himself (to choose to do something else), or the system decide to warn the Etoys VM to quit.
The user might want to simply abandon the ongoing work here, or save the current status. Let us say it shows a dialog and ask the user whether the project should be saved.
If the user wants to keep the ongoing project we save this as a new activity created at 2. And, the user probably want to name it here.
If the user wants to abandon, should it create a journal entry as well but later the user delete it in Journal?
If the system decide to kill Etoys, it could just do the same thing as 6. If we decide to create an activity at 2.1, it can just add a new version of it.
If the user chooses to open a system provided example, we proably wouldn't want to create a new activity when it is opened. He should be able to make changes and save it.
If the user chooses to open his or his friends past work, it should be a new version when a "meaningful" change is made to project.
When the user wants to see another project/activity on the disk... Do you say that the VM has to be re-launched?
So, for a presentation like usage (bunch of slides), an activity should be able to contain multiple projects.
Ok... Senario two:
Alternatively, we cut all these complications, and the user always stay in the "Current Etoys" activity. It is checkpointed upon pretty much every time the user is leaving Etoys. Can it be that loading a project from file just loads it into the currently running image (without trapped by Bitfrost) here?
Oh, but, when the user asks to save, the user gives a name and create a new version of the activity. But, "Current Etoys" activity is different from that activity, so you cannot write into it?
In any case, the problem is the saving/loading time of a project. We've been thinking about it but not much real progress.
And, in any case, making new activity or storing into different activity is not easy because of the security limitation?
Sorry for throwing unorganized thought...
For the record, I did put two alternative in my email. However, item 13 should have been named 1', and 14 should have benn named 2' ^^;
Plopp is based on the ever-keep-going model, as far as I can tell. It works. But, how much of it translates to the multiple documents environment.
-- Yoshiki
At Wed, 25 Jul 2007 08:52:02 -0700, Takashi Yamamiya wrote:
It is very good as if we don't need to care about project saving.
This is much different from current model. But I want to try how Bert's idea realy works. We can back Yoshiki's explicitly saving model anytime if it doesn't work well.
Cheers,
- Takashi
Yoshiki Ohshima wrote:
Bert,
No response, yet?!
Sorry about that...
I may be in a very old fashioned mind set, but still explicitly saving a project when the user is confortable has some virtue. Following that a senario of user experience is like this?
At the very first time to launch the Etoys activity from the bar, he would see a blank or some initial screen that encourage the user to create a new project see an example or a project already exists.
If he creates and enters a new project, Etoys creates a new project in the image (as we do now) and go there. (2.1, probably we just create a new activity (with name "Unnamed" at this point.)
He would (should be able to) checkpoint his intermediate work. He presses the "save" button for this purpose.
His work will be interrupted by himself (to choose to do something else), or the system decide to warn the Etoys VM to quit.
The user might want to simply abandon the ongoing work here, or save the current status. Let us say it shows a dialog and ask the user whether the project should be saved.
If the user wants to keep the ongoing project we save this as a new activity created at 2. And, the user probably want to name it here.
If the user wants to abandon, should it create a journal entry as well but later the user delete it in Journal?
If the system decide to kill Etoys, it could just do the same thing as 6. If we decide to create an activity at 2.1, it can just add a new version of it.
If the user chooses to open a system provided example, we proably wouldn't want to create a new activity when it is opened. He should be able to make changes and save it.
If the user chooses to open his or his friends past work, it should be a new version when a "meaningful" change is made to project.
When the user wants to see another project/activity on the disk... Do you say that the VM has to be re-launched?
So, for a presentation like usage (bunch of slides), an activity should be able to contain multiple projects.
Ok... Senario two:
Alternatively, we cut all these complications, and the user always stay in the "Current Etoys" activity. It is checkpointed upon pretty much every time the user is leaving Etoys. Can it be that loading a project from file just loads it into the currently running image (without trapped by Bitfrost) here?
Oh, but, when the user asks to save, the user gives a name and create a new version of the activity. But, "Current Etoys" activity is different from that activity, so you cannot write into it?
In any case, the problem is the saving/loading time of a project. We've been thinking about it but not much real progress.
And, in any case, making new activity or storing into different activity is not easy because of the security limitation?
Sorry for throwing unorganized thought...
Yoshiki Ohshima wrote:
For the record, I did put two alternative in my email. However, item 13 should have been named 1', and 14 should have benn named 2' ^^;
Plopp is based on the ever-keep-going model, as far as I can tell. It works. But, how much of it translates to the multiple documents environment.
-- Yoshiki
At Wed, 25 Jul 2007 08:52:02 -0700, Takashi Yamamiya wrote:
It is very good as if we don't need to care about project saving.
This is much different from current model. But I want to try how Bert's idea realy works. We can back Yoshiki's explicitly saving model anytime if it doesn't work well.
Cheers,
- Takashi
Yoshiki Ohshima wrote:
Bert,
No response, yet?!
Sorry about that...
I may be in a very old fashioned mind set, but still explicitly saving a project when the user is confortable has some virtue. Following that a senario of user experience is like this?
At the very first time to launch the Etoys activity from the bar, he would see a blank or some initial screen that encourage the user to create a new project see an example or a project already exists.
If he creates and enters a new project, Etoys creates a new project in the image (as we do now) and go there. (2.1, probably we just create a new activity (with name "Unnamed" at this point.)
He would (should be able to) checkpoint his intermediate work. He presses the "save" button for this purpose.
His work will be interrupted by himself (to choose to do something else), or the system decide to warn the Etoys VM to quit.
The user might want to simply abandon the ongoing work here, or save the current status. Let us say it shows a dialog and ask the user whether the project should be saved.
If the user wants to keep the ongoing project we save this as a new activity created at 2. And, the user probably want to name it here.
If the user wants to abandon, should it create a journal entry as well but later the user delete it in Journal?
If the system decide to kill Etoys, it could just do the same thing as 6. If we decide to create an activity at 2.1, it can just add a new version of it.
If the user chooses to open a system provided example, we proably wouldn't want to create a new activity when it is opened. He should be able to make changes and save it.
If the user chooses to open his or his friends past work, it should be a new version when a "meaningful" change is made to project.
When the user wants to see another project/activity on the disk... Do you say that the VM has to be re-launched?
So, for a presentation like usage (bunch of slides), an activity should be able to contain multiple projects.
Ok... Senario two:
Alternatively, we cut all these complications, and the user always stay in the "Current Etoys" activity. It is checkpointed upon pretty much every time the user is leaving Etoys. Can it be that loading a project from file just loads it into the currently running image (without trapped by Bitfrost) here?
Oh, but, when the user asks to save, the user gives a name and create a new version of the activity. But, "Current Etoys" activity is different from that activity, so you cannot write into it?
In any case, the problem is the saving/loading time of a project. We've been thinking about it but not much real progress.
And, in any case, making new activity or storing into different activity is not easy because of the security limitation?
Sorry for throwing unorganized thought...
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Have you looked at the Scratch project saving. It's quite powerful (and even has java player playback :-) ) I'm not sure about multiple projects though.
Karl
Yoshiki Ohshima wrote:
For the record, I did put two alternative in my email. However, item 13 should have been named 1', and 14 should have benn named 2' ^^;
Plopp is based on the ever-keep-going model, as far as I can tell. It works. But, how much of it translates to the multiple documents environment.
Alternatively, we cut all these complications, and the user always stay in the "Current Etoys" activity. It is checkpointed upon pretty much every time the user is leaving Etoys. Can it be that loading a project from file just loads it into the currently running image (without trapped by Bitfrost) here?
Oh, but, when the user asks to save, the user gives a name and create a new version of the activity. But, "Current Etoys" activity is different from that activity, so you cannot write into it?
The main goal in Plopp (actually inspired by the Exobox implementation) was to never let the user know there even is a filesystem. So no naming, no explicit save let alone save as (that would imply using names). Blanking a project (throw away everything) would be the equivalent of save as aka start new. In Plopp we still have the notion of storage and versions though. For etoys that might translate in something like a project gallery that you can browse through (maybe comparable to the scene library in Plopp).
Michael P.S. For those not familiar with Plopp take a look at http://planet-plopp.com
etoys-dev@lists.squeakfoundation.org