Re: [Sugar-devel] Autosave and Keep button
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 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
Re: [Sugar-devel] Autosave and Keep button
Excerpts from Bert Freudenberg's message of Wed Sep 01 16:28:22 +0200 2010: > 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: Ah, good. > 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. Ah, so you create a new data store entry on each invocation? Then it's actually fine to call it Keep (a copy). I thought you'd overwrite the previous entry like before, just not automatically. > 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. A (really) bad hack would be to change the timestamp of the previous entry to something years ago, so it usually wouldn't show up. But instead we should really work on getting version support into Sugar mainline. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Autosave and Keep button
On 02.09.2010, at 09:27, Tomeu Vizoso wrote: > On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg 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. 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. How about we allow activities to disable it in activity.info? - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Autosave and Keep button
On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg 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@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Autosave and Keep button
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. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
