I’ve had a few clients mistakenly close their browser tab/window while actively making changes (things like image ratings, editing requests, etc) to their client feedback pages. Upon re-opening the page, they find that all their input is gone. Although this is normal behavior, I would like to help them prevent it from happening.
Is there a suggested method for adding an event handler for beforeunload events (or something similar)? Some kind of notification that warns the user that they will lose any unsaved changes if they close the client feedback page before submitting their feedback?
That approach seems pretty straightforward; but I thought you guys might be able to apply a little “Backlight Protocol” to my approach. Meaning I’m not going to be trying anything until I get your feedback first.
Ben and Matt would have to comment on adding a warning before closing an unmanaged CR album.
However, the best approach would be to use the Client Response Managed option. That way, all selections and feedback are automatically saved. The client can close the browser and come back later to continue.
But if you wanted to try out the code you found, you can do that risk free by creating a new page template and implement the code via the phplugins script hook for that page template.
Assign the template to a CR album template, create an album and see what happens.
Yeah I’ve tried the managed albums approach but most of my clients are pretty vocal about not wanting an additional step of logging in. If the “managed album approach” was coupled with some kind of group-viewing ability, I’d simply push everyone to deal with one more login in life.
Thanks for the create-a-new-template reminder, though. That does alleviate some concern about trying to Frankenstein in some added Javascript/Jquery event handlers.
Paging @Ben or @Matthew… Do either of you have a suggestion for this little QOL request?
To address your suggestion, we think Pangolin’s client response features are in a good place right now. It would take a very compelling reason indeed to drive me into that code again, and I don’t think this suggestion quite makes the cut. I would hate to introduce regressions into the code base by messing around in the existing logic flow.
Always happy to hear suggestions, though, and I appreciate your input.