[Etoys] Projects and Journal

[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.
>
> -- 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?
>>>
>>>   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...
>>>       
> _______________________________________________
> Etoys mailing list
> Etoys at 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