User Data Always Safe

Every part in Moodle should commit to keeping the data user has entered, safe.

In Spring 2009 Facebook had several groups where users spelled out their frustration when Moodle had lost hours of their work. Not being capable of trusting an application affects the user experience fatally, eventually making users paranoid and writing their work in a word processor and only copying the final work into the browser that seems likely to destroy everything given to it.

As Moodle is a web application, keeping user data safe is not trivial.

Challenges

• Users may leave forms without submitting them
  • Learning from some desktop applications (GNOME settings dialogs), users may assume their settings get automatically saved when they just enter them.
  • Accidentally hitting the back button
  • Clicking on a link on the form itself, assuming it is safe
  • Pushing a button on their keyboard resulting in accidental usage of the back/next buttons
• Users may fill out forms "inappropriately"
  • Missing data
  • Session may have expired
  • User may have logged out accidentally (browser crash; browser restores the browser session but not the Moodle session)
  • User may no longer be capable of completing the action due to loss of permissions or other reasons
    • A forum post they are were replying to was deleted
    • The time to edit a post has passed while the user was editing the post
• Users may submit data when the server has gone down

Solutions

Preserve submitted data until it can be saved

Taking care of the user's data actively when designing an application is really the only thing that can really keep users safe. Know your users and their context, and find out what they might want to do in an error situation.

If a user has posted something, but it cannot be saved, never just throw the data away. Design your application to request the user what should be done. This requires understanding the situations users may end up in. Examples:

• If the user's session has gotten closed (the user is no longer logged in), request the user to log in again, and tell them about the situation: "What you tried to send is safe, but not yet saved. The [insert descriptive label for data here] you posted could not be saved, since you are not logged in. Please log in to have Moodle try again to save it for you."

Giving the user their data back, for copying to the clipboard

Issue: In case the user has gotten logged out, it may be a security risk to give the data out. In other error situations, this is a recommended strategy.

In some browsers it is possible to have a javascripted button that copies the contents of a text field onto the clipboard. This can be used to decrease the user's effort. Not all users are fluent with the clipboard.

• If a forum posting can not be saved due to, for example, editing time having ended, offer the user alternative options that make sense. "30 minutes have passed, so you can no longer edit your forum post. Shown below is what you posted, so you can copy it to your clipboard and from there somewhere safe."
• If a forum reply can not be saved due to the parent item having been deleted, offer users the option to copy their item to the clipboard. In addition, the UI can offer users an option to add their reply to another post in the same thread.

Autosave

Related forum threads:

• AJAX-like Autosave for quiz
• Autosave for Forum Compose?

In situations where preserving the user's data is critical independent of server or client machine crashes, autosaving the data at a regular interval may be used.

• Autosaving can either mean saving form data continuously, not saving the old version, or geeping a version history. Adding version history functionality requires careful context-sensitive UI design. (Wordpress uses autosaving extensively and may be referred to if this strategy is selected)
  • Autosaving can be implemented using AJAX or by just submitting the form in question in the background using javascript.
• When technologies such as Google Gears or the HTML5 equivalent are in use, autosaving can also be done on the local machine, without straining the server.

A "save as draft" button

Sometimes it may be appropriate to let users save their work, before it is finished, without yet publishing it.

Javascript confirmation upon leaving "dirty" form

If the user is about to leave page with a form without submitting it, issue a javascript confirmation dialog confirming if they want to do this.

forward to the page, launching firebug, enabling network monitoring, and selecting to see the POSTed data.

Users should not have resort to paranoia of writing first in notepad and then copying it to the browser, or using somethin such as http://lifehacker.com/5097334/lazarus-form-recovery-saves-web-page-form-data )

Solutions: When a user submits data that can not be saved because of application restrictions (forum post editing time passed, obligatory form fields not filled), think about the scenario in question: what might the user want to do with the data as a second option?

• No other options: show them the data so they can copy and paste it for later use
• Save in a different manner/place: for example, when a forum post has expired, the user is quite likely to want to post a new comment in the thread mentioning what they were about to add to/change in the original posting. Tell them changes have not been saved due to [reason], and let them choose if they want to create a new posting instead. Give them at least the new version back, or optimally a simple graphical representation of the changes they made after the last version that could be saved.
• If they are about to leave a 'dirty' form, warn them about this with a javascript dialog.
• In case the user's computer fails, AJAX autosaving might be the only viable option.
• In case the server fails, storing the form data in a cookie (or if available, with Google Gears or a future standard solution for this) on the client's computer is possible, showing the data to the user again when they return to the form once the server is up again. When they successfully submit the form, delete the cookie. I am not sure about the privacy implications of this though.

TODO: make this a guideline, link as a meta bug and add other bugs inside it.

make form data not disappear when change on browser history

https://docs.moodle.org/en/User:Frank_Ralf/Moodle_forms1#Checkboxes

[https://tracker.moodle.org/browse/MDL-19659 MDL-19659]

• • simplicity through progressive disclosure
    • quiz question editing forms for various question types
  • on simple forms, (less than one page / four elements or less) autofocus the first field of the form on body onload IF none of the fields have any changed content in them (i.e. if the user is not returning to the page from browser history, see: [https://tracker.moodle.org/browse/MDL-825 MDL-825])
  • autosave as a standard on all forms: in case of network outage / simultaneous editing by someone else / some other conflict situation, always tell the user there was an error and **give the users their data back** so that they can
    • optimally, try again saving the data, resolving that conflict
    • or at least copy what they filled in to clipboard
    • currently losing data is also a problem when the editing time of a forum post has passed but the user is already in the post editing form and has changed something: moodle gives an error message that editing time has passed, and just discards all the changes the user tried to save.
      • The same applies when user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to do that (in a different window), submitting the form again fails and the user loses all submitted data: if there are no security issues to this, Moodle should give the user their data back so they do not lose it.
  • Feedback for form actions; an intermediate page giving feedback with META refresh
    • slow, clumsy, issues with browser history(?), not standard with most of the rest of the web
  • Like in WordPress, javascript confirmation if the user presses the back button when already having filled in data but not submitted the form. Especially when using ctrl and shift with arrow keys to move around in text (though it's possibly a marginal use case), it is easy to inadvertedly trigger the shortcut key of the back button in the browser.
  • related: when editing something in a form, if the user is exiting the page without saving page, give a javascript alert on pageunload (?) confirming whether the user wants to save the changes first
  • Configuration defaults: http://moodle.org/mod/forum/discuss.php?d=124533
  • Date selection: use javascript selector (how about time?)
  • Buttons in each module configuration: save and return to course / save and display / cancel. Are there really use cases to support having this choice each time?