General developer forum

 
 
Picture of Mark Johnson
Usability idea for 2.3: Autosave
Group Developers

In a plugin I develop for our termly progress reviews, I've implemented an autosave feature that saves the reviews as they are being written.  This has proven very popular with staff as it avoids the issue where they may spend a long time working on a page, then accidentally navigate away without clicking save and lose what they've done.

I can think of several other areas of Moodle where this could be useful:

  • Couse settings
  • Editing a Resource/Activity/Block (after the initial set up)
  • "Quick Grading" assignments

The architecture is farily simple.  Javascript attaches onChange listeners to the form elements (an additional bit of meddling is required for some special things like calendar selectors), sends the field name, value and an relevant record IDs in an AJAX request to an autosave PHP script, then the autosave script gives the data to the library function that would be used to update the object/record if the form had been submitted.

Discuss/detest/suggest.

 
Average of ratings:Useful (1)
Picture of Mauno Korpelainen
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

Olli started some discussions about the same topic already in 2007

http://moodle.org/mod/forum/discuss.php?d=74710

and after that we had for example

http://tracker.moodle.org/browse/MDL-18014

http://moodle.org/mod/forum/discuss.php?d=130005

So we have several optional methods available for autosaving content wink

 
Average of ratings:Useful (1)
Picture of Nadav Kavalerchik
Re: Usability idea for 2.3: Autosave
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

I have tryed to enable the autosave plugin inTinyMCE 3.4.5 that comes with Moodle 2.2 (dev) and it did not work.

So i download the latest : http://code.google.com/p/tinyautosave , enabled it...and it works great !

I have also played around and modified the sample HTML5 LocalStorge autosave sample to save Form's fields

But, i guess it can only work on browsers that support HTML5. which is a small percentage, if considering the Educational sector. as far as my statistics show sad

 
Average of ratings: -
Picture of Mauno Korpelainen
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

I suppose the documentation of core tinymce autosave plugin is not up-to-date.

After your post I checked the code of both plugins and as far as I can tell autosave plugin is not enabled in moodle 2.2 init code - but it works when you enable the plugin... and the restoring button smile

Add to editor lib.php to plugins line 'plugins' => " .... ,autosave, ...

and to some buttons line "restoredraft" - for example

'theme_advanced_buttons1_add' => "|,undo,redo,|,search,replace,|,fullscreen,restoredraft",

Tinyautosave is a different plugin and there the name of plugin is "tinyautosave" and name of button for restoring content is also "tinyautosave"

Note also that in core autosave plugin default settings are used so it takes some time before restore content button is activated - in tinyautosave plugin you have more optional settings to give for init code like documented on tinyautosave plugin site.

I have not tested if the IE6/7 bug mentioned in tinyautosave plugin changelog affects also autosave plugin:

Version 2.1.3 (2011-03-19)
    
Updated the plugin to work with TinyMCE 3.4, which introduced internal changes that broke the plugin with IE6 and IE7 browsers.

but at least in FF (tested some minutes ago) the core tinymce plugin worked like a charm... here a screenshot

autosave



 
Average of ratings:Useful (1)
Picture of Geoffrey Rowland
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

Can also recommend use of the Tinyautosave plugin. We have successfuly used this for a while with Tiny MCE-enabled Moodle 1.9  (based on the CLAMP-IT distribution)

http://www.clamp-it.org/

For Firefox, the Lazarus Form Recovery Plugin may also be useful.

https://addons.mozilla.org/en-US/firefox/addon/lazarus-form-recovery/

 
Average of ratings:Useful (1)
Picture of Mauno Korpelainen
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

Nadav, you did not explain how the autosave plugin of moodle 2.2 did not work (if it was enabled in lib.php with correct "restoredraft" button...) but one thing that may be confusing is that autosave is not automatically used, it has some default settings in plugin code that need to be fullfilled before any content is autosaved:

In core moodle/tinymce autosave plugin the number of seconds between automatic saves (interval) is set to 30 seconds and the number of minutes since the last autosave that content will remain in the rescue storage space before it is automatically expired (retention) is set to 20 minutes.
But note also that the editor must contain at least 50 characters (minlength set to 50), or else the save will not occur.

Autosave plugin is just a little lighter version of tinyautosave plugin that has more configurable properties and methods but the functionality is the same. So every moodle 2.2 does have a functional autosave plugin included - it is just not enabled. On the other hand nothing prevents developers creating new server side autosave features that can be used together with browser side autosave features or tools. They are all good options smile

 
Average of ratings:Useful (1)
Picture of Mark Johnson
Re: Usability idea for 2.3: Autosave
Group Developers

This looks like a great solution for saving and recovering drafts.  It is a bit of a shame that it requires modification of core code to enable plugins/buttons in TinyMCE.  I've raised an issue on the tracker to discuss adding an interface to enable/disable plugins and buttons more easily.

 
Average of ratings: -
Picture of Stuart Lamour
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

Autosave would be something we would very much support - including saving as hidden/draft while authoring.

This has been requested by a few of our users faced with dodgy wi-fi conections - a modle of autosave involving local storage would get around this quite nicely.

 
Average of ratings:Useful (2)
Picture of Mark Johnson
Re: Usability idea for 2.3: Autosave
Group Developers

Sounds like there's 2 different scenarios here, then:

  1. Need to save regularly to the server to prevent data loss due to user error.
  2. Need to save/cache regularly to the client to prevent data loss due to unreliable connections, and sync to the server when possible.

Presumably a solution for 1 would be a prerequisite of a solution for 2.

 
Average of ratings:Useful (1)
Picture of sam marshall
Re: Usability idea for 2.3: Autosave
Group DevelopersGroup Particularly helpful MoodlersGroup Testers

I think the main issue is finding a solution that can be implemented:

- without significant/onerous change to any existing code that uses moodle forms (i.e. if you just have to add $form->enable_autosave() that's okay, but if you have to write whole php scripts, ugh).
- without breaking anything
- without causing performance problems (do you want to have a manual save button as well/instead of autosave?)
- with an okay user interface (how do you get back to the lost content? what if drafts were saved but you don't want that post, how do you delete? etc)

As other people said there were lots of partial attempts before. Personally I had to implement an equivalent (sort of) within a single plugin; ForumNG includes a 'Save as draft' option you can manually click to save a copy of current version of a post. (Then it has a nice interface showing you all drafts you've saved when you go into the main page of the forum.) A lot harder to do that system-wide...

--sam

 
Average of ratings:Useful (1)
Picture of Mark Johnson
Re: Usability idea for 2.3: Autosave
Group Developers

- without significant/onerous change to any existing code that uses moodle forms (i.e. if you just have to add $form->enable_autosave() that's okay, but if you have to write whole php scripts, ugh).

This is certainly an important point.  Currently my soultion requires each form to have it's own Javascript function and PHP method to handle getting the data from the field, and actually writing to the database, respectively.

Using moodle forms would help with this as each field type could have javascript written to handle it as needed, and pass a key-value pair of the field to be updated along with a record ID to an AJAX request.  This could then pass to a core PHP script which passes it on to an autosave function for the plugin/module.  I can't really imagine it being possible with just an ->enable_autosave() unless we prescibe form and database field naming conventions, but a fairly simple PHP function in each plugin's library (perhaps a method of the form's class?) sounds feasible for a lot of cases.

- without breaking anything

As long as progressive enhancement principles are followed, I can see no reason why adding autosaving should break existing functionality.  Obviously there are many who know the Moodle core a lot better than I, who may know of heffalump traps that I haven't thought about.

- without causing performance problems (do you want to have a manual save button as well/instead of autosave?)

That's another important one to watch out for - autosaving when each field on a form changes does generate lots of HTTP requests (albeit very small ones) which add to the server load.  I've certainly found this noticeable in a situation where lots of people are using the form at once, although in an everyday situation it's not caused problems.

As for manual saving as well, I've taken the approach that the manual save button is disabled (or replaced with appropriate navigation), then enabled again if autosaving fails for any reason.

- with an okay user interface (how do you get back to the lost content? what if drafts were saved but you don't want that post, how do you delete? etc)

My inital thoughts are that UI for handling drafts should be kept to a minimum - if a user has saved a draft then subsequently left and returned to a page, the draft they saved should be pre-filled in the form.  The draft could expire after a time, if unused.  Beyond perhaps a "clear form" or "revert to saved" button when an unwanted draft is loaded, the only need I could see for extra UI is if multiple drafts/versions are saved, which might be an over-complication.

 
Average of ratings: -
Picture of Stuart Lamour
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

Do you know a funny thing about our users? They think the save and display is preview or save draft. 

They use it to check if what their doing is ok, but don't realise that what they think is work in progress is actually visible to students.

Even the more advanced users...

Now there may be a cultural reason for this, in that the other web editing system at sussex has three buttons - preview | save | cancel - but not all of our tutors have access to this, so i wonder how many other users of moodle interpret the save and display button to mean some sort of draft or preview?

 
Average of ratings: -
Picture of Greg Hundermark
Re: Usability idea for 2.3: Autosave
 

I teach English in a 1:1 school, and students losing their work WAS a huge issue for us.  As a temporary solution, you might want to consider "encouraging" students to use Firefox and the plugin Lazarus, which is a free auto-form recovery add-on.  This has really come in handy for a lot of kids and it works pretty well. 

We use Macs, so I show that kids that they can access the "Recover Text" menu by holding down 'control' and clicking. 

Good luck everyone!

 
Average of ratings:Useful (2)
Picture of Mark Johnson
Re: Usability idea for 2.3: Autosave
Group Developers

Expanding on this, if autosaving were to be implemented for forms in general, it would make sense for activites to be created as Hidden by default.  If the user wanders off half way through, you wouldn't end up with a half baked version going live, but could also come back and finish it later.  You could then have a "Preview" button as well as/instead of "Save and View" which leaves the activity hidden and views it, while the existing save buttons could make it visible unless it's specifically set to hidden.

 
Average of ratings:Useful (1)
Picture of Stuart Lamour
Re: Usability idea for 2.3: Autosave
 
Average of ratings:Useful (2)
Picture of Mark Johnson
Re: Usability idea for 2.3: Autosave
Group Developers

That looks fantastic. It's a shame it relies on jQuery but perhaps it could be modified to work with YUI.

I agree with some previous opinions that it's not always ideal to restore form data automatically on page load, as this does. If I get the chance to play around, I'll have a look at implementing a restore/discard feature.

 
Average of ratings: -
Picture of Stuart Lamour
Re: Usability idea for 2.3: Autosave
Group Particularly helpful Moodlers

Thought you might like it smile

If i had the time i'd fork a version that didn't need any library - let us know how you get on.

 
Average of ratings: -
Picture of Mark Johnson
Re: Usability idea for 2.3: Autosave
Group Developers

I've done a proof-of-concept mod that detects if a form has saved data and fires a user-defined function, rahter than restoring everything regardless.

In my example, I display a "restore" button and a "discard" button for each form. Restore restores just the data for that form. Discard does nothing yet.

You can see the example at http://marxjohnson.github.com/sisyphus/

The code is in the gh-pages branch of my fork.  It can definitely be improved.  I don't have the time to work on it any further at the moment, but I intend to come back to this in the future.

 
Average of ratings: -