[Etoys] Projects and Journal

[Takashi Yamamiya]

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?
> 
>   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...