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
    • When user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to login (in a different window) while keeping the form data, submitting the form again fails and the user loses all submitted data. At a minimum, Moodle should give the user their data back so they do not lose it.
  • 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 or network connection lost

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 keeping 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.
• The strain on the server produced by autosave can be reduced by only sending new changes to the server, instead of always sending the contents of the form to the server at a specific interval
• 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.
  • This is also probably the only possible strategy when the server has gone down or when the network connection has been lost

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.

Browser-based solutions

Unrelated to Moodle development, browsers may one day integrate functionality currently provided as an extension to at least Firefox (alternate link, always storing form data for later recovery. This may raise privacy issues though.

Also developer tools such as Firebug HTTP traffic listening or the Firefox Tamper Data extension can be used in recovering lost data: Initiate traffic listening, repost the data, read in the tool what data was posted and copy it to the clipboard.

Users should not have resort to paranoia of writing first in notepad and then copying it to the browser, or using somethin such as [1] )