[Sugar-devel] Resuming by default (was: One instance activity)

[Eben Eliason]

On Wed, Dec 10, 2008 at 6:09 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 09.12.2008, at 20:39, Bert Freudenberg wrote:
>
>> On 09.12.2008, at 18:55, Eben Eliason wrote:
>>> Pablo, for what reasons do you desire to prevent multiple instances
>>> from running?
>>
>> Hope there's a better reason than "it's too easy to create unwanted
>> instances" ... (still waiting for the home view icons to resume by
>> default)
>
>
> Circling back to the underlying problem ... why can't we indeed make
> the home view activity icon resume the latest journal entry?

I think performance of the datastore query was the primary reason,
apart from lack of time/resources.

> * this was the intention of the Journal all along (would make the idea
> of stopping/resuming activities much more obvious)

The intention of the Journal was to /be/ the space from which one
could resume previous work.  This says nothing about the functionality
of the Home screen. Experience has indicated that people (particularly
kids) more often than not would prefer to resume the last thing they
worked on, which led us to the proposed bi-modal home view.

> * it would solve Pablo's problem (this works today, resuming an
> already opened journal entry just switches to that activity)

It solves his problem /if/ his problem was simply attempted prevention
of accidental duplicate instances.  If, on the other hand, his problem
involved a technical constraint which prevents two instances from
running simultaneously, it does not.  We need to hear more about the
root issue.

> * no more unwanted Journal entries (one would be reused all-over)

This isn't quite the right idea.  We  wish to give preference to
continuing work, but that's certainly not the same thing as saying
that there is just one instance.  No entries are "reused".  Instead,
the most recent instance is simply shown by default, adjacent to a
number of older instance, as well as a "new" instance.

In any case, I think the better solution to reducing unwanted entries
is to encourage naming, and provide a "don't keep" option in the
naming prompt upon closing a previously unnamed & unkept activity.

> * creating a new Journal entry would be an explicit action (need UI
> for that)

Right. The current proposal is to provide the alternate functionality
(start new) in the contextual menu (or by holding alt while clicking).

> That last item is the only problem I can see - in the activity one
> would need a "start new entry" button, just having this as optional
> menu item in the home view is not enough. The semantics would be just
> like the "keep a copy" button now, but also reset the activity to a
> blank slate.

Hmmm, I'm not sure about this.  I think it's important for the
instance model to maintain that launching the most recent instance
does indeed resume that specific instance.  I think the in-place "new
document" breaks this idea, harkening back to the old model of
applications and files.

> If the upcoming datastore work focused on versioning as much as legacy
> file support, we would not even need that button (though it might
> still be convenient to have). Older instances would then readily be
> available in the Journal and could be resumed from there.

Exactly. This is small part of the reason we didn't implement this
yet, too.  Versions would make it less problematic if a child resumed
a recent activity, actually wanting a new document, and then
destructively edited it.

- Eben


> - Bert -
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>