[Sugar-devel] Autosave and Keep button

Bert Freudenberg bert at freudenbergs.de
Wed Sep 1 10:28:22 EDT 2010


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:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 3659 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100901/d3346fc5/attachment.png 
-------------- next part --------------


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.

- Bert -




More information about the Sugar-devel mailing list