[Sugar-devel] Autosave and Keep button

[Gary Martin]

Hi Bert,

On 2 Sep 2010, at 11:36, Bert Freudenberg wrote:

> On 02.09.2010, at 09:27, Tomeu Vizoso wrote:
> 
>> On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>> On 01.09.2010, at 14:01, Sascha Silbe wrote:
>>> 
>>>> Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010:
>>>> 
>>>>> My first gut reaction (not having seen it yet) is that the Keep button is a real problem generally (and causes confusion and misunderstanding in Sugar). Habitually training kids to click that icon each time before exiting will, for all other activities, generate many confusing duplicate Journal entries over time and make matters even worse.
>>>> 
>>>> +1
>>>> 
>>>>> For the Etoys case, as a workaround for not knowing your clean/dirty state, I think having the regular Stop UI button that when clicked _always_ displayed some sort of "Do you want to Keep the changes to this project in the Journal?" Keep/Don't Keep dialogue.
>>>> 
>>>> Having the Stop button ask which version (the one in the Journal or the
>>>> one currently loaded) to destroy is a bad idea, but unsolvable without
>>>> version support.
>>>> Please avoid the Keep terminology in this context; it's only going to
>>>> confuse users even more.
>>>> 
>>>> Sascha
>>> 
>>> That's one of the reasons I did not want to overload the exit button with saving functionality. It simply exits (after confirming) without ever saving now. To avoid confusion, it does not look like a regular stop button:
>>> 
>>> 
>>> 
>>> But you can't really discuss autosaving and keeping separately. They go hand in hand. If an activity cannot autosave, it has to rely on the keep button, right? And keeping should create a new entry - that's how it is in every activity. Only autosave destructively overwrites the current entry.
>>> 
>>> I am warming up to Gary's suggestion though because it's the only way to avoid needless Journal entries, unless we introduce a "save/save-as" distinction.
>>> 
>>> Incidentally, on other platforms Etoys does versioning itself - every project saved has a version number embedded in the file name that is not visible in the UI. In the file-open dialog, all but the highest numbered versions are hidden. Now maybe if the Journal had a "hide" attribute for an entry, the Journal would look less cluttered. Also, when running out of space the hidden entries could be used to free up space. Wait, that's re-inventing the trash can ... but maybe not a bad idea after all.
>> 
>> The (some?) plans for versioning in the journal called for hiding the
>> less relevants revisions in the main view and only displaying them in
>> the detailed view.
>> 
>> Regards,
>> 
>> Tomeu
> 
> Yes, I know. However, "real" versioning seems to be far too complicated to actually get implemented and adopted. It might be too large a step.
> 
> It would be (IMHO) much simpler if updating a Journal entry would just make a "hidden" copy with the old contents and metadata first. 

Yes, even some way to distinguish them visually in the Journal would help, right now you have no idea if one is the current version or an old version, until you resume and take a look. At least we landed Journal view by creation date in Sugar 0.90, so we can see an un-mangled by modified date history, and find the most recently created version.

> This "poor man's versioning" would alleviate the destructive nature of auto-save. It *would* be possible to access "overwritten" versions if necessary.
> 
> OTOH that's tangential to the Etoys problem, which would not be solved even by a real versioning scheme. In Etoys, auto-save is rarely what the user needs. Maybe if the explicitly kept versions were preferred over the auto-saved ones ... But then it's hard to tell. 
> 
> Hmm, remind me again why resume-by-default from the home view was a good idea. I know I supported it at the time we discussed it. It works well for e.g. Terminal. But for activities like Etoys it gets in the way.

Primarily I think it was that folks were almost always starting new instances and filling up their Journal with cruft rather than using the Journal to resume (because it was filling up with cruft and they couldn't find what they wanted to resume). We tried a two pronged attack and landed two largish UI changes back then:

1. resume recent activities by default from home view
2. show naming dialogue on stopping a new user un-named activity

This seems to have resolved the original cruft issue but has raised some new issues:

1. kids resuming past work and erasing/modifying, when they really intended/wanted to start new
2. many see the pop-up naming dialogue as an annoying nag screen and click past it as fast as they can

I was working with Christian and others on Nº1 back in June/July, the sugar-devel mail archives seem to be missing emails from the thread that contained the actual mock-ups so I've uploaded the last one Christian sent out to the wiki, take a look at page 3 particularly. The goal is to make start new and resume of equal UI importance so users consciously make a decision:

    http://wiki.sugarlabs.org/go/File:Design_mockup_100710_home_overlay-2_christian.pdf

We were derailed at the time by a dislike of adding a new dialogue, and requests to see this dialogue in a pie menu style design of some kind:

    http://wiki.sugarlabs.org/go/File:New_Resume_pie_menu_mockup.pdf

We should get back on the case for 0.92 and see if we can find some consensus.

Walter was working on Nº2 which removes the automatic Sugar naming dialogue nag, but makes it optional to call up at any time while using an activity. It could be called up via a new menu item in the activities frame menu so activity code didn't need to be changed. This feature didn't land either as there were difficulties accessing the correct Journal entries data, i.e. if there are more than one activity version with the same activity id, the shell can't distinguish which is the current entry – just like us humans can't either ;)

> How about we allow activities to disable it in activity.info?

I'd rather we kept a consistent behaviour for the home view, otherwise it will get rather more confusing to predict what happens when clicking an activity icon.

Regards,
--Gary

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