speaking with elijah tonight on irc, he was curious about the autosave confirmation found on line 170 of leftandmain.js and it got me wondering too

basically, it calls the autosave function and only asks for confirmation if the client is ie

from some comments, it seems like it might be a cross-browser issue with the modal dialog
if that is the case, is there anything stopping ss from using a well-established modal plugin for prototype?

The autosave feature was something we never quite finished off, so I suspect there may be more work than adding a modal dialogue box to make it work reliably.

In regards to the modal dialogue box, we are currently getting this effect by using a litebox script. it would be good to be consistent with the interfaces. Either use the existing litebox, or if the benefits are large, replace it entirely with the one you've aware of.

it wasnt anything specific i had in mind, litebox would probably be the best bet

my take was that for some reason the implementation only worked in ie, and hence the case to only show the dialog for ie

the two main gripes i have with autosave in SS:
1. too slow, as it loads a completely new page in an iframe. to be useful, it has to appear instanteous
2. opt-out: by default, all fields are captured by autosave, which means you can trigger it by changing a hidden field or something thats not actually content. you have to specifically exclude fields from the autosave detection.
the underlying code is pretty solid, but it needs some "usability-refactoring" IMO :)

just as a clarification ingo, would you prefer the opposite of the opt-out system, where fields must be explicitly set to auto-save, or some compromise of a few default fields but all configurable?

i agree with your points though, and the good code base (tinymce + prototype) should make it not too difficult to implement

I'm currently working on Usability Issue "#44 Alert users when leaving tab with unsaved changes": http://www.elijahlofgren.com/silverstripe/alert-users-when-leaving-tab-with-unsaved-changes/

It states: "Make sure there is always a ‘Do you wish to save your changes’ reminder if users have made changes and try to leave a tab without clicking the ‘Save’ button."

For example, renaming a folder in the 'Files and Images' section and clicking 'Newsletters' does not bring a confirmation or save the new folder name. This is one thing that I will work on fixing.

> 1. too slow, as it loads a completely new page in an iframe. to be useful, it has to appear instanteous

I too have noticed the slowness of the confirmation. Should I add making the confirmation load faster to my list of things to fix for Usability Issue #44?

> 2. opt-out: by default, all fields are captured by autosave, which means you can trigger it by changing a hidden field or something thats not actually content. you have to specifically exclude fields from the autosave detection.

Should I also work on implementing opt-in instead of opt-out for fields as part of my work on the Save reminders usability issue?

Thanks for the feedback,

Elijah

> just as a clarification ingo, would you prefer the opposite of the opt-out system, where fields must be explicitly set to auto-save, or some compromise of a few default fields but all configurable?

i think opt-out is the only way (although its a bit annoying), because it would have to be applied far less often than specifically "registering" fields for auto-save detection. a good start whould be to exclude all <input type="hidden">, and see where the current "false alarms" are in the CMS (i suspect MemberTableField/ComplexTableField-paging als one culprit).

> I too have noticed the slowness of the confirmation. Should I add making the confirmation load faster to my list of things to fix for Usability Issue #44?

that'd be awesome (but check back with your mentor sean here). as the functionality (three buttons) is not context sensitive, we could either produce the code directly from javascript, or automatically render a hidden div with each cms-call which is just shown on demand.

The problem with a "modal plugin" is that the modal dialog has to halt the unloading of the page - I suspect that no modal plugin on earth actually has this ability, arrongantly based on the fact that I couldn't work out how to do it :-P

To be honest, this combined with Ingo's gripes about load time makes me wonder if we shouldn't just to it the same way as Google Docs - an ok/cancel box that says "do you really want to leave without saving your changes?" and if they don't, forces people to press cancel and then save manually.

I agree with Ingo that opt-out is the only acceptable solution here: The ease adding of custom fields to pages is a massive benefit of developing with SilverStripe, and we don't want to complicate with gotchas such as this.

9 times out of 10, you want change detection on a field. The other 1 time, you're going to be deep enough into things to know that you should be disabling change detection. What we do need, however, is a documented way of opting out.