17452 Posts in 4473 Topics by 1971 members
Page: 1 2
|Go to End||Next >|
12 June 2007 at 4:19pm
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?
Core Development Team
12 June 2007 at 6:19pm
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.
12 June 2007 at 8:28pm
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
12 June 2007 at 10:01pm
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
13 June 2007 at 3:00am
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
Google Summer of Code Hacker
13 June 2007 at 6:27am
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,
13 June 2007 at 9:46am
> 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?
13 June 2007 at 11:50am
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.
Page: 1 2
|Go to Top||Next >|