[Etoys] [sugar] Implicit saving

[Eben Eliason]

On 8/31/07, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Aug 31, 2007, at 8:00 , Eben Eliason wrote:
>
> >> The implicit saving on activity close gets in the way of how etoys
> >> traditionally worked. If I create, say, a simulation, I will arrange
> >> everything and then save that project, so when I later open it for
> >> demonstration, it is in a state ready to be started. But when I then
> >> run the simulation and quit, it will not be in the ready-to-run state
> >> anymore.
> >>
> >> Any idea how that problem should be tackled in Sugar?
> >
> > Hmmm, that's a little tricky.  The implicit saving is designed to
> > track versions naturally and to prevent data loss, but it does seem to
> > get in the way in this case. I don't know the APIs myself, but I
> > assume the activity gets prompted to save upon close and then handles
> > the save itself.  It seems you could keep track of "read" vs "write"
> > actions, where pressing "run" or "reset" buttons (basically a revert
> > button) wouldn't count as "write" modifications.  You would only need
> > to save upon close if code or graphics were actually changed during
> > the session.
>
> Well, in Etoys there really is no distinction between "authoring" and
> "running". Like, we can't really distinguish between a kid moving an
> object intentionally to a new "start state" or moving it while
> playing a game.
>
> > In any case, you might actually think of this to your advantage.
> > Since the files are (will be) properly versioned, this implicit save
> > hasn't actually erased your default simulation setup, which will still
> > live in the Journal as an entry from yesterday when you set it all up.
> >  Instead, you now have that "starting state" entry and one or more
> > "experiment" entries which represent the results of running that
> > simulation.  With randomness this could actually create a series of
> > interesting results that would be useful for learning.
>
> Honestly, I don't think we should treat every design bug as a feature.

I'd also prefer not to write off every difference from other known
platforms as a bug up front. We certainly do want to handle as many
cases as possible, though, and I appreciate any feedback about these
potential problems.  There are a lot of new ideas at play, and they
might not all be correct.  I just want to explore all of the
implications of these issues with respect to the current system so
that we make changes when we know for sure they are necessary.

With a game, for instance, I think that keeping state automatically
upon exit can actually be quite useful, as it can store the state of
our game so we can resume it again tomorrow.  It's not always desired
behavior, but it can be a good thing in many cases.

> But anyway, since in trial-3 there is no versioning, what's the short-
> term solution? Do we have the option to store a new version without
> clobbering an older one?

The "keep" button is going to explicitly create a copy of the current
state as a new entry within the Journal, so that incremental saves are
supported until we have proper versions.

- Eben