[sugar] Resuming by default

[Mike C. Fletcher]

Tomeu Vizoso wrote:
> On Tue, 2007-10-23 at 09:27 -0400, Mike C. Fletcher wrote:
>   
>> Bert Freudenberg wrote:
>>     
>>> You guys are caught up way to deep in technical detail already. I'd  
>>> place the desired user experience first, then see if this has  
>>> security implications, and then worry about implementation.
>>>       
>
> Agreed with that, but who has been talking about concrete implementation
> details?
>   
I believe Bert was referring to my proposals for how to implement the 
security details.

> Activities can already store configuration data that is not tied to an
> activity session in their own profile dir (env var SUGAR_ACTIVITY_ROOT,
> something like ~/.sugar/default/<activity bundle id>).
>   
Fine, but it lacks version control, doesn't have visibility in the 
Journal, and is generally kind of hacking around the idea of the Journal 
being the storage on the machine.  It also requires special support in 
the backup systems.  If all file-system access is going to be Journal 
based, why are we not using it for this type of work?  Why do we have a 
"special" external storage instead of making the Journal capable of this 
kind of operation?

The answer is probably "time".  I do realise that.  Still, going 
forward, if we are going to require substantial rewriting of activities 
to port them to the Journal anyway, why not provide the services so that 
settings information get all the benefits of the Journal that we are 
providing for content information.
>>> So I think not resuming by default is a real obstacle to making good  
>>> use of the Journal idea.
>>>   
>>>       
>> Resuming by default is a particular application design.  Starting fresh 
>> each time is another design.  Neither is necessarily correct or proper, 
>> they are design-time (or even run-time[1]) decisions that should both be 
>> supported.  Your own experience with porting eToys to the platform has 
>> shown that making such application-level design decisions at the OS 
>> level causes all sorts of problems, particularly when porting 
>> already-extant code-bases.  The OS should support *either* approach.
>>     
>
> I certainly see it not only activity dependent, but also dependent on
> how a particular user uses a particular activity.
>
> And having some activities resuming by default and some others showing a
> blank sheet, looks like confusing to me... How can we explain that
> distinction?
>   
They are different.  This one goes back to where you were.  This one 
starts at the same place each time.

As the children grow familiar with the machine, you can explain the 
security system and the ability to let a given activity start with its 
last content via the security settings page.  Children are quite capable 
of dealing with such differences.  Activities that start with default 
resumption are going to be those where it makes sense, or where the user 
has explicitly configured that resumption.

Consider these questions:

    * why doesn't my mail client remember my emails from yesterday?
    * why does the mail client remember my emails from yesterday, but
      the word processor starts with an empty page each time?

the first is a simple, concrete question regarding why something doesn't 
work.  The second is a complex abstract question that requires 
type-based reasoning.  While we (most of us being over 12) think of the 
second as a serious question, most 7-11 year olds are still in the 
concrete operational stage and will simply accept them as two different 
types of thing, one which remembers where you were, one which does not.  
As they approach 12 (formal operational), they may begin to wonder what 
controls that decision and may poke under the covers to find the 
security bit and/or the configuration/setting.
> About making easier to resume existing entries, well... I have already
> said that we aim to improve this situation. Any other ideas in this
> direction are welcome.
>   
That's wonderful.  Will continue to think about it.

Take care,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com