[sugar] Resuming by default (was: Journal integration design for Measure Activity)

[Bert Freudenberg]

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.

The *actual* problem right now is that resuming an activity is much  
more complicated than simply clicking the icon in the frame. And  
*this* is backwards. We do *not* want to start with a clean state  
every time.

Take, for example, the gazillion bugs Albert filed about unnecessary  
Journal entries. This is not foremost a problem of creating too many  
entries, or of providing better ways to delete unwanted entries. It  
is a usability problem, namely a UI design that encourages starting  
fresh over resuming.

I have personally observed this over the last months, with passers-by  
as well as with regular users like my own kids. Resuming from the  
Journal is a very rarely used feature. E.g., my son (8yo) really  
likes TamTamJam and arranges instruments and adds little loops etc.,  
but even though I showed him on several occasions that he could  
resume from the Journal, this appears to be too much effort - he  
instead powers on the laptop and clicks the frame icon, always  
starting a new session and never looking at the old arrangements again.

So I think not resuming by default is a real obstacle to making good  
use of the Journal idea.

- Bert -

On Oct 23, 2007, at 6:10 , Tomeu Vizoso wrote:

> Hi,
>
> follow some comments on the suggested alternatives from Mike:
>
> On Mon, 2007-10-22 at 16:36 -0400, Mike C. Fletcher wrote:
>> Antoine van Gelder wrote:
>> ...
>>> The JokeMachine activity is a good example of an activity where  
>>> 'resume'
>>> by default makes sense.
>>>
>>> In this activity children can enter and read jokes in a list of  
>>> various
>>> joke books (Knock Knock Jokes, Riddles, Cheese? etc.)
>>>
>>> Should they exit the activity and start it up again the
>>> NaturalThingToExpect(tm) is to see your joke books in the state  
>>> you last
>>> left them, rather than a blank slate which you must populate with  
>>> new
>>> joke books.
>>>
>> Please consider the security implications of this.  BitFrost is  
>> designed
>> with the idea that the only way to access information in the  
>> Journal is
>> by having the child explicitly authorize the Journal to grant  
>> access to
>> the information.  That separation is (partially) to prevent  
>> subversion
>> of a program at time N from allowing the subverted program access  
>> to all
>> content created at time M<N without explicit authorisation.  If all
>> activities are automatically choosing some random (as far as the
>> security system is concerned) journal record to access and being  
>> granted
>> that access, you have lost the protection.
>>
>> To underline the issue, the particular activity described, collecting
>> and sharing jokes is one which can quite conceivably be very
>> security-sensitive.  If the jokes in question happen to be  
>> political in
>> nature (or religious, or whatever), having a subversion of the  
>> activity
>> at some point allow some external actor access to every joke  
>> you've ever
>> told might be very painful.
>>
>> If you need the workspace metaphor, that's fine, but I'd be wary, for
>> instance, of allowing access to the history of all jokes (even those
>> that were deleted by your parents because they were
>> inappropriate/dangerous) to be accessible by default.  That is, the
>> document of "my current joke collection" might be something that you
>> want to be auto-loading, but the trace of undo/redo might *not* be
>> something you want available after that new software update from the
>> people who just took over your government.  If you allow unfettered
>> access to the Journal (even if just the current activity's entries),
>> then the activity can be subverted to act against you at any time.
>>
>> Suggested approaches:
>>
>>     * Provide a mechanism in the Journal to flag a given entry/ 
>> file as
>>       "time-shared" with its future instances
>>           o Activities which are "workspace-oriented" in nature (mail
>>             clients, joke-collection managers, photo managers) would
>>             mark their stored "workspace" items as time-shared, and
>>             would automatically attempt to load the last record in  
>> the
>>             Journal.  That would require an extra API in the  
>> Journal to
>>             allow safe (non-metadata-leaking) requests to retrieve  
>> lists
>>             of the time-shared values.
>>           o Activities which are "document-oriented" in nature (word
>>             processors, audio-file editors, video editors, etc) would
>>             only mark their "settings" (or a subset of them) as
>>             time-shared, and would attempt to load them  
>> automatically,
>>             while not restoring the last-run-file(s).
>
> I think (Eben should confirm), that "workspace-oriented activities"
> doesn't match quite well with our current concept of Activity. The
> journal is intended (not there yet, lots of work left to do) to give a
> good browsing experience for all the content that is kept inside the
> laptop. So that if the user wanted to find a jokes collection, he  
> would
> go first to the journal and find it either by filtering, searching  
> or a
> combination of those.
>
> If any activity author thinks that his activity could give a better
> experience in browsing all the content created within it, please  
> pass to
> us your requests for improving the journal. Preferably as trac  
> tickets.
>
> We also think that a good way to improve this situation is to make it
> easier to resume existing entries in the Journal. Mike's ideas  
> below are
> good, any other in this direction would be greatly appreciated. But
> remember that the user needs to know at every point to which data an
> activity is being granted permission.
>
>>     * Provide a shell-level UI control on each frame activity icon.
>>           o On clicking (or hovering) it brings up the Journal set
>>             produced by that activity (say the last 15 entries  
>> from the
>>             activity) to be directly launched.  That is, a  
>> recently-used
>>             Journal-list for each icon, but the default would  
>> still be
>>             to create a new instance without access to your  
>> previously
>>             created files.
>
> This has been discussed, could be implemented for 1.1.
>
>>           o Alternately, launch the Journal with a pre-selection  
>> query
>>             from the control.
>
> This is scheduled for 1.0. Activity icons in the frame will have an
> option in the palette that will show the journal filtered by that
> Activity. See #4275.
>
>>     * Provide just a BitFrost protection "P_LAST_USED" that  
>> signals that
>>       the application should always be given access to the latest
>>       Journal entry from that activity (all other access (i.e.  
>> switching
>>       workspaces) would require explicit authorisation)).  This
>>       effectively just prevents "random" choice of Journal  
>> records, and
>>       reduces the attack surface to just the last items stored.  Of
>>       course, information-leakage attacks are generally the most
>>       valuable with recent data, so it's not a perfect solution.
>
> If the user wants to start an activity, has he given it the permission
> to access the last activity instance data? The user should remember
> which was the last thing he did in that activity before using that
> option?
>
> Tomeu
>