[Sugar-devel] Autosave and Keep button

Tomeu Vizoso tomeu at sugarlabs.org
Thu Sep 2 03:27:50 EDT 2010


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

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


More information about the Sugar-devel mailing list