[Etoys] Projects and Journal
Yoshiki Ohshima
yoshiki at squeakland.org
Wed Jul 25 15:30:09 EDT 2007
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...
>
More information about the Etoys
mailing list