Moodle UI Guideline: User Data Always (Always) Safe
The single most critical usability flaw in Moodle.
As a result of this summer's UI inspection for UI guidelines, I consider improving keeping user data safe on the UI level (when users are or editing creating content) the most critical issue.
Moodle users (often especially students) easily get paranoid. A lot of this is due to getting lost in the UI, but often when I talk to students in Finland and tell them I work on Moodle, I hear frustrated stories about Moodle eating their data. Some of this needs to be solved by making the database backend of Moodle work reliably, but much of it comes from the fact that the UI does not handle the users' data reliably.
Please comment. Any thoughts, horror stories, good or bad examples of UIs, or further suggestions on how to improve the situation are very much velcome.
I think an autosave/draft system similar to Wordpress would be a great feature, most of the problems seem to be from user mistakes (for which we must forgive them). Sometimes the user simply doesnt realise what will happen if they do stuff like hit the back button whilst filling out a form (most people will only make this mistake once though, either they will learn from it or simply never bother trying again, the latter being something we want to avoid at all costs). Again however, as demonstrated by Wordpress, when editing a page or post if you try hit the back button you are warned of the consequences.
I find this sort of thing quite difficult to address, because I am used to using web applications and Moodle then its all too easy to just say "oh well the user shouldnt have been daft enough to hit the back button in the first place", but of course this is not helpful to the poor end user who has just wasted 30 mins of their life typing out a forum reply or something. Only to mistakenly hit the back button and lose it all!
I find this sort of thing quite difficult to address, because I am used to using web applications and Moodle then its all too easy to just say "oh well the user shouldnt have been daft enough to hit the back button in the first place", but of course this is not helpful to the poor end user who has just wasted 30 mins of their life typing out a forum reply or something. Only to mistakenly hit the back button and lose it all!
Hi Dale,
Lazarus is a great FF add-on to address the "back button"-lost data problem you mention. It's one of my top ten FF plugins, couldn't do without it.
Of course we cannot expect "ordinary users" of Moodle to have Lazarus installed on their machines or know how to use it. So, back to square one.
Joseph
Lazarus is a great FF add-on to address the "back button"-lost data problem you mention. It's one of my top ten FF plugins, couldn't do without it.
Of course we cannot expect "ordinary users" of Moodle to have Lazarus installed on their machines or know how to use it. So, back to square one.
Joseph
I'm not sure how well known it is, but I'll share my "horror story".
It is based on user error but arises because of a mismatch between how Moodle/the HTML editor behaves and how other "editors" behave on my Mac laptop.
I'm now onto my second draft of this post, because of this user error.
I use a Mac laptop. Now home/end of line keys, instead I've learnt the instinctive use of Command-left/right cursor key to move to the start and end of lines. I use this regularly within Word processors and various online editors - including Wordpress.
However, if I use command-left cursor key to go to the start of the line in this editor within Moodle, it will actually act as hitting the back button and take me to the previous page. Which in turn loses everything I've written in the editor. It's gone, time to re-write.
Perhaps the worse aspect of this is that if I do shift-command-left cursor key it will work as expected and select all text from the current cursor position to the start of the line.
The Wordpress editor doesn't have this problem.
It is based on user error but arises because of a mismatch between how Moodle/the HTML editor behaves and how other "editors" behave on my Mac laptop.
I'm now onto my second draft of this post, because of this user error.
I use a Mac laptop. Now home/end of line keys, instead I've learnt the instinctive use of Command-left/right cursor key to move to the start and end of lines. I use this regularly within Word processors and various online editors - including Wordpress.
However, if I use command-left cursor key to go to the start of the line in this editor within Moodle, it will actually act as hitting the back button and take me to the previous page. Which in turn loses everything I've written in the editor. It's gone, time to re-write.
Perhaps the worse aspect of this is that if I do shift-command-left cursor key it will work as expected and select all text from the current cursor position to the start of the line.
The Wordpress editor doesn't have this problem.
Joseph: Thats a nice idea, unfortunately not for us as our college uses Internet Explorer 6/7 (I know, we should be ashamed, but try telling that to the IT support team, it sends the developers and I loopy).
This really should be a feature that is built into web browsers, but for now the only way I can see around it is to implement some sort of autosave function.
David: Hmm, Wordpress uses TinyMCE, have you tried installing TinyMCE for Moodle? Might help.
You have a point though, the editor in Moodle should be very similar to Word (which I would imagine is the worlds most popular word processor software). Not just in the way it looks but in the way it functions. Of course this presents a problem for us because Moodle's editor is a third party application and not written specifically for Moodle. However, like most open source apps it can be customised.
This really should be a feature that is built into web browsers, but for now the only way I can see around it is to implement some sort of autosave function.
David: Hmm, Wordpress uses TinyMCE, have you tried installing TinyMCE for Moodle? Might help.
You have a point though, the editor in Moodle should be very similar to Word (which I would imagine is the worlds most popular word processor software). Not just in the way it looks but in the way it functions. Of course this presents a problem for us because Moodle's editor is a third party application and not written specifically for Moodle. However, like most open source apps it can be customised.
Hi Dale,
I sympathize. Your IT support team should be ashamed of themselves for not using FireFox.
Joseph
I sympathize. Your IT support team should be ashamed of themselves for not using FireFox.
Joseph
I think TinyMCE is supposed to replace HTMLArea in Moodle 2.
Dale,
in my opinion it was one of the biggest mistakes (or lacks) of moodle to build in one default editor system (HTMLArea) and to make such modifications directly to the original code of HTMLArea and lib files (so called "moodle modifications") that it has been in practise impossible to change editor in all versions of moodle before version 2.0 without loosing those moodle hacks (to create a fully functional editor integration)
Editor must be fully pluggable and changable like it is going to be in moodle 2.0. (with the latest TinyMCE as a default editor) and the changes that particularly Petr Skoda made were perfect - I have sent Petr thanks a couple of times but he deserves a new "Thanks Petr!" in every post about new editor system in moodle 2.0. 
Hi David,
I'm surprised that Command-left should move your cursor to the start of line. I do not use Macs but I expect that the Command key is the equivalent to Ctrl on a "normal" computer keyboard.
In Windows text editors, Ctrl-left moves the cursor to the start of the previous word. How do you achieve this on your Mac, then?
Surely you cannot blame that "horror story" on the Moodle editor or your browser, but on your special use of the Mac keyboard. If you use FireFox (highly recommended) on your Mac, why not install the lifesaver Lazarus (see my previous post)?
ATB
Joseph
G'day Joseph and Dale,
Sorry, as Joseph points out, CMD-left it is the start of the previous word, not line. My mistake.
However, that's the out of the box, Mac default.
From a user/ease-of-use perspective, I would expect any editor I use to hopefully support those defaults. Or at least not do something that causes data loss because it doesn't.
I take the point about there being alternatives that I can undertake to fix this problem. However, it doesn't strike me as a very friendly approach to expect the 1000s of students and staff at a university to take extra steps because a system doesn't follow some standards.
Dale, TinyMCE sounds like a solution. However, the two instances of Moodle I use the most are not ones that I control. i.e. I don't believe I can install TinyMCE on those instances to address the problem.
David.
Sorry, as Joseph points out, CMD-left it is the start of the previous word, not line. My mistake.
However, that's the out of the box, Mac default.
From a user/ease-of-use perspective, I would expect any editor I use to hopefully support those defaults. Or at least not do something that causes data loss because it doesn't.
I take the point about there being alternatives that I can undertake to fix this problem. However, it doesn't strike me as a very friendly approach to expect the 1000s of students and staff at a university to take extra steps because a system doesn't follow some standards.
Dale, TinyMCE sounds like a solution. However, the two instances of Moodle I use the most are not ones that I control. i.e. I don't believe I can install TinyMCE on those instances to address the problem.
David.
Of course he can blame it on Moodle, and should. It is a wild world of technology, and Moodle should protect its users from potential hazards, when those users are working with Moodle. There are precautions Moodle developers can take to make the above situation next to impossible. The mechanisms to do this should be built into Moodle, like they seem to have been taken into account in Wordpress or Google Docs.
Saying that the user's habits or the particular OS/computer environment is to blame, is like taking on a challenge ("yes we can build something great to really serve learning purposes") and then when we don't feel like actually facing the challenges, running behind mom's back and saying "this isn't what I wanted! it is the other guy's fault! he should have been more careful!".
Either we serve the users in the challenges they face in reality, or not. Most users will simply give up on Moodle when it is not reliable. Or get badly frustrated since their school forces them to use it.
Saying that the user's habits or the particular OS/computer environment is to blame, is like taking on a challenge ("yes we can build something great to really serve learning purposes") and then when we don't feel like actually facing the challenges, running behind mom's back and saying "this isn't what I wanted! it is the other guy's fault! he should have been more careful!".
Either we serve the users in the challenges they face in reality, or not. Most users will simply give up on Moodle when it is not reliable. Or get badly frustrated since their school forces them to use it.
It's harder to prevent in web browsers than in some other programs that do not use browsers.
Olli, read for example http://moodle.org/mod/forum/discuss.php?d=61635
and check next different browser shortcut keys from
Mozilla Firefox: http://support.mozilla.com/en-US/kb/Keyboard+shortcuts
Safari: http://safari-tips-and-tricks.blogspot.com/2008/12/safari-shortcuts.html
Opera: http://www.opera.com/browser/tutorials/nomouse/
IE7: http://www.microsoft.com/windows/products/winfamily/ie/ie7/quickref.mspx
IE8: http://windowshelp.microsoft.com/Windows/en-US/Help/223e800a-c5a3-435c-aa65-0c3710cf0d4f1033.mspx
Any user can close browser with one mouse click or by pressing Ctrl + Q in Safari (when user means to write Shift + Q for example) and you can't prevent such user events with any (reasonable) code - all you can really do is to blame those "blody browsers"... or yourself
Edit: Ctrl + W is even better, it closes the window in all modern browsers...
No, we can not purely rely on onclose events.
http://www.quirksmode.org/js/keys.html
I tested ctrl+w on firefox3 and chrome dev on ubuntu 9.04. Firefox intercepts ctrl+w but not alt+f4. Chrome intercepts neither.
"Btw, to a certain extend you can define your own action, like dismissing that javascript fake popup window, by registering to key-down / press events. The following is possible:
Firefox: only Ctrl-W can be captured, Ctrl-F4 cannot
Internet Explorer: only Ctrl-W can be captured, Ctrl-F4 cannot
Opera: both Ctrl-W and Ctrl-F4 can be captured
Alt-F4 can never be captured (closes whole browser).
Btw, to a certain extend you can define your own action, like dismissing that javascript fake popup window, by registering to key-down / press events. The following is possible:
Firefox: only Ctrl-W can be captured, Ctrl-F4 cannot
Internet Explorer: only Ctrl-W can be captured, Ctrl-F4 cannot
Opera: both Ctrl-W and Ctrl-F4 can be captured
Alt-F4 can never be captured (closes whole browser)." http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_24336084.html (scroll to bottom of page)
http://www.quirksmode.org/js/keys.html
I tested ctrl+w on firefox3 and chrome dev on ubuntu 9.04. Firefox intercepts ctrl+w but not alt+f4. Chrome intercepts neither.
"Btw, to a certain extend you can define your own action, like dismissing that javascript fake popup window, by registering to key-down / press events. The following is possible:
Firefox: only Ctrl-W can be captured, Ctrl-F4 cannot
Internet Explorer: only Ctrl-W can be captured, Ctrl-F4 cannot
Opera: both Ctrl-W and Ctrl-F4 can be captured
Alt-F4 can never be captured (closes whole browser).
Btw, to a certain extend you can define your own action, like dismissing that javascript fake popup window, by registering to key-down / press events. The following is possible:
Firefox: only Ctrl-W can be captured, Ctrl-F4 cannot
Internet Explorer: only Ctrl-W can be captured, Ctrl-F4 cannot
Opera: both Ctrl-W and Ctrl-F4 can be captured
Alt-F4 can never be captured (closes whole browser)." http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_24336084.html (scroll to bottom of page)
I found one more crazy situation - if I had another moodle open (on local test PC)and another HTMLArea open at the same time I wrote a post here in moodle.org and I tried to browse an attachment to my post guess what happened: the post here was cleaned!
It has happened to me before because I often test cases at the same time I write my posts - for students it may not be a typical loss of data...
Anyway - here comes a new post (after 5 minutes loss of work):
On good example about asking confirmation for the user action before it's done is delete icon:
if user tries to edit a resource and presses 
instead of 
moodle does ask "Are you absolutely sure you want to completely delete..."
The same logic could be used for cases where session is close to expire - give user a warning (popup with beep!) and 1 minute time to react or session will be closed (and data autosaved ?)
Or if the post you are trying to reply does not exist (has been deleted while you were writing your post) file mod/forum/post.php could check if the original post still exists in database and if it does not exist post could be left open with choises to close the post without saving or to go back and copy your post before closing...
http://docs.moodle.org/en/Development:User_Data_Always_Safe#Giving_the_user_their_data_back.2C_for_copying_to_the_clipboard is good - it might be better to give a option to copy content before posting than after posting - if editing time has ended it is better to check if you still have editing time left before posting and if editing time has ended before you managed to press "Post to forum" you could be asked to close your post or save your post before the action instead of using autosave to get a copy of post that may be 60 seconds older than your final post.
If you don't know about Mac, maybe it would be wiser to withhold comment on details of its keyboard usage? 
The Mac keyboard layout is horrendously broken in all regards. Basically, there is no Home/End key. Well, actually, there are Home/End keys on some Apple keyboards. However, Apple's keyboard guidelines specify that these keys must be useless. (They move scrollbars to start and end, similar to Ctrl-Home/End on a PC, except that they also tend not to move the cursor position at all, only the view, which moves them firmly into chocolate fireguard territory.)
So, they've broken Home/End. But Home/End are essential for all high-level keyboard users. Ooops! What now?
You guessed it - Command-Left and Command-Right do what Home/End ought to do.
(I think Ctrl-Left and Ctrl-Right still work to go back/forward a word same as on Windows, not using a Mac right now to check this. But Command-Left/Right are definitely Home/End.)
To add to the comedy value, many Mac applications (especially cross-platform ones) provide options or default behaviour to make Home and End work sensibly, in order to work around the operating system's insanely awful default behaviour. In most of these applications, Command-Left and Command-Right also continue to work, but in some, they don't.
(As it happens, I do seriously think that these keyboard shortcut issues are the single worst thing about OS X.)
Anyhow, leaving that aside - yes this same thing has happened to me several times. Command-Left ought to go to start of line, but (in Firefox on a Mac) it tends to go Back and potentially lose all your work. I think this is a bug in Firefox really, they should get rid of that shortcut since it overlays common keyboard behaviour. Don't know what Safari does, I don't use it.
The good news is that TinyMCE isn't broken in this manner* and works with ordinary form data - you can go back and forwards with TinyMCE without losing everything. We use TinyMCE at the OU now and I think this is safe.
--sam
* TinyMCE is broken in other ways, the key one being that it requires about a 653 MB download and eighteen minutes of Javascript initialisation on each page that uses it...
The Mac keyboard layout is horrendously broken in all regards. Basically, there is no Home/End key. Well, actually, there are Home/End keys on some Apple keyboards. However, Apple's keyboard guidelines specify that these keys must be useless. (They move scrollbars to start and end, similar to Ctrl-Home/End on a PC, except that they also tend not to move the cursor position at all, only the view, which moves them firmly into chocolate fireguard territory.)
So, they've broken Home/End. But Home/End are essential for all high-level keyboard users. Ooops! What now?
You guessed it - Command-Left and Command-Right do what Home/End ought to do.
(I think Ctrl-Left and Ctrl-Right still work to go back/forward a word same as on Windows, not using a Mac right now to check this. But Command-Left/Right are definitely Home/End.)
To add to the comedy value, many Mac applications (especially cross-platform ones) provide options or default behaviour to make Home and End work sensibly, in order to work around the operating system's insanely awful default behaviour. In most of these applications, Command-Left and Command-Right also continue to work, but in some, they don't.
(As it happens, I do seriously think that these keyboard shortcut issues are the single worst thing about OS X.)
Anyhow, leaving that aside - yes this same thing has happened to me several times. Command-Left ought to go to start of line, but (in Firefox on a Mac) it tends to go Back and potentially lose all your work. I think this is a bug in Firefox really, they should get rid of that shortcut since it overlays common keyboard behaviour. Don't know what Safari does, I don't use it.
The good news is that TinyMCE isn't broken in this manner* and works with ordinary form data - you can go back and forwards with TinyMCE without losing everything. We use TinyMCE at the OU now and I think this is safe.
--sam
* TinyMCE is broken in other ways, the key one being that it requires about a 653 MB download and eighteen minutes of Javascript initialisation on each page that uses it...
And what happens when the user fills a normal textarea (web form) without editor - no matter what shortcut keys we have defined to HTMLArea or TinyMCE they stop working as soon as we don't have that editor and different browser shortcuts are used instead...
Edit: What on earth do you mean by this comment, Sam:
* TinyMCE is broken in other ways, the key one being that it requires about a 653 MB download and eighteen minutes of Javascript initialisation on each page that uses it...
Do you have some special version of tinymce?
Edit: What on earth do you mean by this comment, Sam:
* TinyMCE is broken in other ways, the key one being that it requires about a 653 MB download and eighteen minutes of Javascript initialisation on each page that uses it...
Do you have some special version of tinymce?
When not using editor, if you go Back by accident, you don't lose data as long as you realise to go Forward again straight away. With HTMLArea (but usually not TinyMCE), you do.
In the comment you queried, I may have been exaggerating just a fraction However, I have pages which set up TinyMCE using AJAX (delaying it to avoid the massive impact on initial page load time, in case it is not needed) and this makes the Javascript setup time pretty visible. Watching TinyMCE jerk into life when I click my 'reply' link, like a decaying zombie struggling slowly out of its grave, is really pretty disturbing. And while its giant script file can often be cached for future use, I hate to think what that experience would be like on the initial load for a modem user...
--sam
In the comment you queried, I may have been exaggerating just a fraction
--sam
Hi Sam,
Well, I didn't intend to open that can of worms. But, in this world of ours where Mac tends to be given the role of the "good guy" and Windows the "bad guy" (cf. the clever and funny "Hi, I'm a PC / Hi, I'm a Mac" Mac ads), it is a relief to hear someone confess that "The Mac keyboard layout is horrendously broken in all regards." Each time I have to sit at a Mac I am missing something (starting with the left mouse button).
Anyway, back to square one, I do agree with Olli that Moodle (and indeed any piece of software) should protect its users from potential hazard. However, see Mauno's detailed information, showing that total protection (against wrong use of the keyboard) is an illusion. No amount of software "protection mechanisms" will compensate for the end-user's errors, habits, idiosyncrasies, in short from being a human, not a machine.
Joseph (not a Mac owner)
Just in case anyone gets the wrong impression, I am a Mac user (at home). And incidentally, I use a Microsoft mouse.
--sam
--sam
This is a lot later than the general discussion, but in case someone stumbles upon this while doing a search, here is what I do on my Mac with Firefox to deal with
the accidental go to previous page and loose your work when you only meant to go to the beginning of the line and go crazy because you, yet again, lost 15+ minutes typing.
Moodle 1.9: put TinyMCE into popup mode. Because there is no previous web page to go back to, you can't accidentally lose work.
Moodle 2.0+: No popup mode, and the "popup like mode" is still succeptible to the back a page problem. I installed a Firefox plugin, Customizable Shortcuts, that allows me to override the default behavior for certain key combinations. Specifically, I changed it so that the Alt+Left (using my MS natural kbd) does nothing. Problem solved.
Honestly - I do agree that some kind of progress autosave feature would be most useful for any such cases.
One common problem is also that students or teachers notice that they can sometimes drag and drop images from web (other browser window) directly to editor window or just copy the address or proudly explain how much faster it was just to copy and paste text from web to their courses. Then one day the same users ask why they can't edit some field (javascript event handlers inside the pasted code can make the whole field uneditable), images are lost (they were there yesterday!!!) or wiki complains about unretrospective scripts when you have added some nice Word documents (544 pages...) to your wiki - or somebody says he/she can't edit that wiki!!!
Do you know these stories, Olli?
One common problem is also that students or teachers notice that they can sometimes drag and drop images from web (other browser window) directly to editor window or just copy the address or proudly explain how much faster it was just to copy and paste text from web to their courses. Then one day the same users ask why they can't edit some field (javascript event handlers inside the pasted code can make the whole field uneditable), images are lost (they were there yesterday!!!) or wiki complains about unretrospective scripts when you have added some nice Word documents (544 pages...) to your wiki - or somebody says he/she can't edit that wiki!!!
Do you know these stories, Olli?
Yep, I totally agree about autosaving being a good solution here.
We talked about this some time ago ... there are basically three parts to a perfect solution IMO:
1) Some JS in the editor to post the text to Moodle frequently where it gets stored in a special temptext table, indexed by the current path (eg mod/forum/post.php and the user ID).
2) When ever a new editor is launched, some JS in the editor queries Moodle for default content, passing the URL as a parameter. If text is found in the temptext table, it gets inserted in the textarea by default (or provided via button if that is deemed better)
3) When saving the Moodle form, all temporary texts for that URL and user ID are deleted (ensuring they don't keep popping up).
David Mudrak was actually working on this (MDL-18014) but it would be great if you could finish it off and make it ready for HEAD!
We talked about this some time ago ... there are basically three parts to a perfect solution IMO:
1) Some JS in the editor to post the text to Moodle frequently where it gets stored in a special temptext table, indexed by the current path (eg mod/forum/post.php and the user ID).
2) When ever a new editor is launched, some JS in the editor queries Moodle for default content, passing the URL as a parameter. If text is found in the temptext table, it gets inserted in the textarea by default (or provided via button if that is deemed better)
3) When saving the Moodle form, all temporary texts for that URL and user ID are deleted (ensuring they don't keep popping up).
David Mudrak was actually working on this (MDL-18014) but it would be great if you could finish it off and make it ready for HEAD!
We were talking about this (among the other things 
) with Petr yesterday. Our ideas:
- use page on-unload handler to display the confirmation box if the user presses backspace or navigates away off the unsaved form
- use GoogleGears to cache the inserted wysiwyg text. Then we do not have any server extra load, capability checks etc. Of course, GoogleGears have its limits etc. but this seems to be the easiest solution (especially because of the performance, server load and bandwidth load).
Server side solutions can cause (tiny) server extra load, browser side solutions can cause (tiny) browser memory load and user side solutions can cause (tiny) stiffness for users... 
A combination of several methods might work best. For example if you use database to save autosave data and server crashes or some database error occurs or network connection is lost whole autosave process may fail still user has the browser window open and he/she can write several minutes data and does not notice anything untill he/she tries to save the work and moodle does not respond at all. Tinyautosave plugin keeps the data also in this kind of cases but only for the last autosaved editor content.
On the other hand if local PC stops responding and can't be restarted (hard disk failure) plugin based autosave can't be used - user could still use server side restore process from other PC and from database of moodle server. Tinyautosave is suitable for activities that use one textarea at time but not at all suitable for such activities (forms) that have lots of input fields but no editor textareas or lots of textareas open at the same time.
In my opinion these different methods do not conflict with each other
One more interesting note - if both main developer of Moxiecode/TinyMCE (Spocke) and Speednet (developer of Tinyautosave plugin) have already agreed on including tinyautosave plugin to coming releases of TinyMCE (the main package) and we are just waiting that Speednet has finished the new version that includes multiple auto-save storage spaces... we don't actually need to do any major code changes ourselves for this plugin, just add the init code of the coming plugin and configuration of possible settings + language tags to moodle when tinyautosave plugin has officially replaced old autosave plugin (it is already there in lib/editor/tinymce/plugins although old autosave plugin has a very tiny task - see http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/autosave - compared to new advanced tinyautosave plugin) - we get it automatically when Petr upgrades TinyMCE in the near future. This may happen already in TinyMCE version 3.2.6...
And for quizzes & other activities that use textareas or input fields (forms) we need some kind of a larger or complementary server side autosave solution that people like Olli and David have been developing...
David,
Xinha (nightly) seems to have a plugin that uses Google Gears to enable local document storage. With Gears installed, you can save drafts of your documents on your hard drive, configure Xinha to look the way you want, and carry this information wherever you use Xinha on the web.
http://www.xinha.org/xinha-nightly/examples/ExtendedDemo.html
The icon of this plugin is Gear which may of course be a little confusing if moodle 2.0 is going to use Gear for representing "Advanced settings" in forms in the name of usability...
I like the idea of Google Gears, at first I thought "wow think of the offline possibilities for Moodle" etc. However, our college, like many others, are reluctant to install software that is anything other than standard. I've failed to get our IT/network guys to install Firefox on our machines so I cant imagine them installing plugins like Gears.
Sorry to just shoot your idea down, it sounds great and I would use it for personal projects. However, in my opinion it would be more beneficial to develop something that is platform independent and that does not require external browser plugins etc.
One other thing I would like to see is some type of versioning system, I've had teachers editing the same resources at the same time (each at home without consulting anyone else). Of course this ends up in a mess! It's not difficult to train them in the first place but human nature tends to make us ignore warnings.
Sorry to just shoot your idea down, it sounds great and I would use it for personal projects. However, in my opinion it would be more beneficial to develop something that is platform independent and that does not require external browser plugins etc.
One other thing I would like to see is some type of versioning system, I've had teachers editing the same resources at the same time (each at home without consulting anyone else). Of course this ends up in a mess! It's not difficult to train them in the first place but human nature tends to make us ignore warnings.
Thanks Dale,
all the credit for idea of using Google Gears belongs to David and Petr and GSOC project http://docs.moodle.org/en/Development:Google_Gears_integration - my post was a direct response to David and I wanted to give him a tip about Xinha using a similar tool like we have been talking here. David has been the active person in writing those server side solutions - I have mostly tried to explain some good points of using existing client side plugins of tinymce. The tinyMCE plugins I mentioned are not external browser plugins - they are internal editor plugins. Old plugin autosave is currently included to moodle 2 with core plugins of tinymce and as far as I have understood developers of TinyMCE and TinyAutosave plugin are planning to add also TinyAutosave plugin to core plugins of tinymce in coming versions of tinymce. That way there should be nothing new that your IT/network guys should install if they just upgrade to moodle 2 sometimes in 2011-14...
Sorry it seems I did not read your post properly, I didnt realise it was in reply.
I was referring to Gears as an external plugin, as Ive found it needs to be installed on Firefox as an extension. Therefor would be something that we could not install here, we would also find that some users would have the Gears browser extension installed but others would not.
Obviously a TinyMCE plugin would work fine as I could intall it on Moodle/tinyMCE and not have to worry about how the end users would cope.
Ive got TinyMCE running as the default browser on our Moodle site now so I might give the Tiny Autosave plugin a try. Long term though it would still be nice to have a proper integration with Moodle, as in a custom solution. Like the Wordpress draft/autosave/revisions system.
I was referring to Gears as an external plugin, as Ive found it needs to be installed on Firefox as an extension. Therefor would be something that we could not install here, we would also find that some users would have the Gears browser extension installed but others would not.
Obviously a TinyMCE plugin would work fine as I could intall it on Moodle/tinyMCE and not have to worry about how the end users would cope.
Ive got TinyMCE running as the default browser on our Moodle site now so I might give the Tiny Autosave plugin a try. Long term though it would still be nice to have a proper integration with Moodle, as in a custom solution. Like the Wordpress draft/autosave/revisions system.
http://annevankesteren.nl/2007/06/gears
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=gears+html5
Happily it seems gears-type functionality will eventually be integrated in HTML(5?) so a plugin might no longer be needed. Could not find a proper article on this yet though.
http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=gears+html5
Happily it seems gears-type functionality will eventually be integrated in HTML(5?) so a plugin might no longer be needed. Could not find a proper article on this yet though.
Nice, that would be ideal! I think we'll have to wait a few years before it becomes a reality though. And then we'll have to wait a few more years for Microsoft to catch up!
Assuming we're just talking about client-side storage of large data, then the proper article is probably http://dev.w3.org/html5/webstorage/.
I think it's supported not only in Safari and Firefox, but even IE8. Haven't tried it.
There will still be a loooooong wait before IE8 takes over from 7...
--sam
I think it's supported not only in Safari and Firefox, but even IE8. Haven't tried it.
There will still be a loooooong wait before IE8 takes over from 7...
--sam
Olli,
one line in your UI Guideline in Docs made me think about some other possible solutions. The line was:
"In Finland whenever you tell someone you work for/on Moodle, students spill out their frustration since everyone seems to have the experience of Moodle losing their work."
Can't be true...
Finland has been the highest-performing country of all times on the PISA scales what ever scale they use - if our students can't learn to use moodle, who can?
I think the reason for getting such comments means that your teachers or administrators have not given enough information - guides or starter courses - about using moodle: what to do with different buttons and how...
One major lack in moodle may be lack of helper systems and instant error feedback that could control your progress - not only autosave. We have those help buttons but people use them only if they can't use some thing and try to find some guide about possible use of setting or button.
Our school has only one book about moodle written by Samuli Karevaara (in Finnish) and many teachers have been interested in reading that book since yesterday - if our school is closed during this term because the expected http://en.wikipedia.org/wiki/2009_flu_pandemic moodle will be the "temporary school environment" during those pandemic weeks...
What I have noticed is that teachers forget almost everything they had learned last year - if they haven't used moodle a lot - and to prevent boring lessons we have used groups of 5 teachers where one more experienced user can quickly give some guide for others. The same is most likely true for students as well - we expect that they can do everything better than teachers - without guiding... Most of the "lost work" is probably caused by missing knowledge of using the environment correct ( like do not paste content from Word to Wiki directly - use attachments and links to those long Word documents... )
And yes - I have lost my (really long) posts several times in moodle.org - but nowadays I select and copy my posts to clipboard every time before posting it just to be sure I won't miss it...
Olli,
I read your guidelines many times and some things may be easy to solve, some more difficult. For example David has done great work with http://tracker.moodle.org/browse/MDL-18014 (autosave) but there is also a new and very functional autosave plugin for TinyMCE available in http://code.google.com/p/tinyautosave/
It is possible that this plugin will be even an official part of coming core tinymce package - http://tinymce.moxiecode.com/punbb/viewtopic.php?id=14352
I tested this plugin with the latest moodle 2.0 and it worked very well both in Internet Explorer 8 and Firefox 3.5 ( I did not make any heavy testing or did not test other browsers - just a quick look...) - even if I simply closed the browser it was possible to get content back with life buyo button.
Default settings can be changed and implementing this plugin to moodle is really easy - all you need to do is copy the plugin to plugins folder of tinymce and edit lib/editor/tinymce/lib.php - for example :
'plugins' => "safari,table,style,layer,tinyautosave,advhr,advimage,advlink,emotions,inlinepopups,{$xmedia}searchreplace,paste,directionality,fullscreen,moodlenolink,{$xdragmath}nonbreaking,contextmenu,insertdatetime,save,iespell,preview,print,noneditable,visualchars,xhtmlxtras,template,pagebreak",
and later
'theme_advanced_buttons3_add' => "|,table,insertlayer,styleprops,visualchars,|,code,tinyautosave,preview",
Read carefully all settings from http://code.google.com/p/tinyautosave/wiki/Functionality and http://code.google.com/p/tinyautosave/wiki/Technology before trying...
I can also confirm that even basic version of TinyMCE & normal textarea keeps content if you accidentally press back and forward... but my tinymce is 100 times faster than Sam's version and loads only a couple MB of data...
And even if this original need is to keep user data safe...security has always two sides. You mentioned in docs using of clipboard - the main problem with clipboard is that any malware can get content from clipboard for example with flash (it can be used also for good purposes to allow copying and pasting of content with buttons in FF that would not allow using af clipboard otherwise).
Although it is technically possible to save last content automatically and get it back it is also good to ask for example how long do we need to keep that content, where, how often is the autosave done (interval) or how do we clean autosaved content (so that other users of same PC don't get test answers from cookies). http://code.google.com/p/tinyautosave/wiki/GettingStarted has nice explanation of available settings that can be modified to use administration of moodle as well.
Anyway thank you for raising this topic up, Olli!
I have to say that this is the single biggest annoyance I have with Moodle. The number of times I've lost a post to this forum either through a session timeout or accidental back button/refresh which Firefox *usually* handles gracefully is ridiculous.
I agree that autosaving is a good solution - the Term Review module created by my college's previous Moodle developer makes particularly good use of this. Teachers fill out a review for each student on their course and click save. If they accidentally click "next student" without saving, the review is autosaved for them to come back to.
I'm not sure how it would work in the context of a forum, but particularly for on-line assignments it's ideal.
Maybe saving and publishing should be separate actions, so a user can save/autosave several times before publishing?
I agree that autosaving is a good solution - the Term Review module created by my college's previous Moodle developer makes particularly good use of this. Teachers fill out a review for each student on their course and click save. If they accidentally click "next student" without saving, the review is autosaved for them to come back to.
I'm not sure how it would work in the context of a forum, but particularly for on-line assignments it's ideal.
Maybe saving and publishing should be separate actions, so a user can save/autosave several times before publishing?
Well I can say that this TinyMCE plugin really works well in this task. All configuration options are clearly explained in documentation of the plugin and most important settings are
tinyautosave_minlength - Number, default = 50
The minimum number of characters that must be in the editor before an autosave will occur. The character count includes all non-visible characters, such as HTML tags.
tinyautosave_interval_seconds - Number, default = 60
The number of seconds between automatic saves. When the editor is first displayed, an autosave will not occur for at least this amount of time. This option can also be specified as tinyautosave_interval.
tinyautosave_retention_minutes - Number, default = 20
The number of minutes since the last autosave that content will remain in the rescue storage space before it is automatically expired. This option can also be specified as tinyautosave_retention.
So by default, the TinyAutoSave plugin auto-saves the editor content every 60 seconds. This schedule can be altered to any number of seconds by specifying the tinyautosave_interval_seconds configuration option.
In addition to the scheduled auto-saves, the TinyAutoSave plugin also saves the editor contents just before the page exits in some manner. This is the most important save-point, because it is the point at which an accidental keystroke normally destroys the editor contents. No matter how the user exits the page, the save will occur, including:
- Clicking the browser's Refresh/Reload button
- Clicking the Submit button on the page
- Navigating to a link on the page
- Closing the Web browser
No plugin can prevent user actions like closing the browser or kicking power cable off or network connection errors but it is still possible to get the autosaved content back as long as your PC/Mac hard disk has no larger damage after unexpected shut down...
And it works with every field that you use TinyMCE for if init code just has tinyautosave as plugin and button added and the plugin itself installed.
But it is important to note that moodle will never use TinyMCE for all fields - not even in moodle 2.0 - and javascript may not be always enabled and therefore it is important to have several methods like
http://tracker.moodle.org/browse/MDL-18014
to enable both autosaving and "pre-action-actions" and helper functions (on hover popups etc) to avoid such cases that might cause loss of data and would require use of autosave to rescue data.
It's actually funny that the same methods/buttons etc that are used to control safe handling of data may be thought to be unaccessible/unnecessary by some users: "Are you sure that you want to overwrite this field...are you absolutely sure that you want to do this action..."
Thanks, Mauno for all your work!
I added a couple of links you mentioned to the guideline.
It seems that TinyMCE might indeed solve some of these problems. The problem is: tinyMCE never knows the context of Moodle it is in, and I really believe some of these issues should be solved on the server side. That rescue ring (whatever that is in English) icon does not seem like that many users will click it for... wel, whatever reason.
I'll read this thread again later this week and reply in more detail.
I added a couple of links you mentioned to the guideline.
It seems that TinyMCE might indeed solve some of these problems. The problem is: tinyMCE never knows the context of Moodle it is in, and I really believe some of these issues should be solved on the server side. That rescue ring (whatever that is in English) icon does not seem like that many users will click it for... wel, whatever reason.
I'll read this thread again later this week and reply in more detail.
Yes it's true - tinymce does not know the page or resource where you were before browser was closed but user usually knows it. It's also true that nobody knows about this icon - I just found the plugin yesterday myself. On the other hand they don't know about any other autosave features as well because we don't have any autosave features in moodle right now - we need to tell such things in documentation, help files and helper functions...
The plugin has no language strings in moodle 2.0 so we can give what ever name we want for this kind of plugins - mouse over icon shows tinyautosave.restore_content which explains the icon somehow for english speaking users...
And yes again - some of these issues can be solved on the server side - some can be solved on browser side - some can be solved on user side (guides and training) - and some (hopefully few) problems simply can't be solved...
Along with the text, I'd suggest that we change the icon if it's to be included, since the only other time I've seen a life belt icon, it's been to open a Help dialogue. If I'm correct in thinking that the user has to click the button for autosave to be "activated," the icon needs better affordance.
I hate to suggest that we should use still use floppy disks to represent saving, but perhaps a floppy disk with a small clock would be more representative of autosaving to the user?
I hate to suggest that we should use still use floppy disks to represent saving, but perhaps a floppy disk with a small clock would be more representative of autosaving to the user?
No Mark,
you don't need to activate autosave by clicking the button... check http://code.google.com/p/tinyautosave/wiki/Functionality
- Minimum length must be met (default 50 characters - can be set for example to 5 characters...). Note however text:
"Using a minimum number of characters is important because it protects against the user having their auto-saved content overwritten by empty text if they open a new editor page and it auto-saves before they have a chance to click Restore. It is possible to set tinyautosave_minlength to 0 (zero), but it is not recommended."
- Scheduled auto-saves depend on tinyautosave_interval_seconds configuration option (default 60 seconds)
- TinyAutoSave plugin also saves the editor contents just before the page exits in some manner
When an auto-save occurs, the toolbar button briefly animates and then becomes enabled (clickable), giving the user confidence that their content is secure. However, the subtle animation can be disabled by setting the tinyautosave_showsaveprogress configuration option to false.
If tinyautosave plugin finds it's way to core tinymce in the near future it might be better to keep rescue ring icon - it is of course possible to change icons and there are several optional icon types available if you search for example "rescue", "restore", "recover" (from some device) or "undo" icons. Another reason why I would not change the icon is that autosave process has those animations and there are 12 different (optional) animation versions available in this plugin + automatic gif/png selection for the main icon itself - see http://korpelainen.net/images/autosave.html
It is also possible to create new skins and themes for tinymce so for those sites that would like to use some different icon sets it could be done by other editor theme/skin selection in init code or even a totally modified version of TinyMCE - remember that moodle 2.0 will have pluggable editors...
Ah that's cool. If it "rescues" the user, then the lifebelt certainly makes sense, and if it animates/activates when an autosave occurs all the better!
Maybe an icon that has lifebelt around a clock could "autosave" and "rescue" us both, Mark
PS. It's not a bad idea at all to change icons to something better if you find or create some new icons that look better or feel better for this kind of tasks...
The original icons of this plugin are actually too small - 16x16px - they should be 20x20px in tinymce and therefore icons don't fit very well to toolbar - tinymce scales 16x16px icons to 20x20px icons.
Here you see a png version
(20x20px - if you copy this rename it to restore.png before using in plugin) and a gif version 
(20x20px - if you copy this rename it to restore.png before using in plugin) and attached an example why icon size matters (although in larger scale these are rather tiny things...) :
PS. It's not a bad idea at all to change icons to something better if you find or create some new icons that look better or feel better for this kind of tasks...
The original icons of this plugin are actually too small - 16x16px - they should be 20x20px in tinymce and therefore icons don't fit very well to toolbar - tinymce scales 16x16px icons to 20x20px icons.
Here you see a png version
(20x20px - if you copy this rename it to restore.png before using in plugin) and a gif version (20x20px - if you copy this rename it to restore.png before using in plugin) and attached an example why icon size matters (although in larger scale these are rather tiny things...) :
By the way - current editor (HTMLArea) itself is one of the major cause of user side problems in moodle. It is very hard to explain to teachers and students why content is not really WYSIWYG - more often it is WYSINWYG - What You See Is NOT What You Get
Just check the open issues in tracker http://tracker.moodle.org/browse/MDL/component/10070?selected=com.atlassian.jira.plugin.system.project:component-openissues-panel
Editor cuts tags, editor changes tags, editor does not show tags... and still editor is one of the most important tools of moodle.
TinyMCE may solve also many of HTMLArea bugs but not all and we will see some new buttons, new settings, some old things are done differently in TinyMCE compared to HTMLArea...before people get used to new editor.
In some cases it may be even useful that TinyMCE does not no where it was when something unexpected happened. For example if the post that you were trying to reply was deleted and you should try to continue replying to a post that does not exist anymore. If we don't have a pre-submitting-check for deleted posts content is autosaved when you press submit. If we have a pre-submitting-check user will have a chance to copy content before closing editor and autosave/rescue is not needed - but tinymce plugin rescue is still available if user makes another mistake and closes editor... mistakes often happen in chain and Murphy's laws are always valid: http://www.xs4all.nl/~jcdverha/scijokes/9_6.html
Or if teacher has just hidden the resource or it becomes uneditable for various reasons...
The autosave plugin was able to rescue / restore data also in Safari and Chrome ( on Windows Vista )
The only browser that failed in my tests was Opera ( 9.64 )
There is autosave code in the Assessment module we wrote for Intel Education - IIRC it's based on the already included YUI library and should be pretty easy to implement in other places (suggested this a few times I think).
It works very well and does dramatically improve the user experience.
It's important to note some caveats, though:
1. Autosave requires a hit to the database, it does increase the load on the database, so that needs to be taken into account - if implemented it should probably be off by default so that folks on lightweight webservers won't overload their db (in the assessment module there is a configuration option where an admin can set how often autosave runs to help manage load).
2. In something like Forum & other places where content is usually immediately available, autosave should probably be linked to a 'draft post' feature - e.g. if my computer crashes partway through a post, do I want autosave to send in my 1/2 completed post?
It works very well and does dramatically improve the user experience.
It's important to note some caveats, though:
1. Autosave requires a hit to the database, it does increase the load on the database, so that needs to be taken into account - if implemented it should probably be off by default so that folks on lightweight webservers won't overload their db (in the assessment module there is a configuration option where an admin can set how often autosave runs to help manage load).
2. In something like Forum & other places where content is usually immediately available, autosave should probably be linked to a 'draft post' feature - e.g. if my computer crashes partway through a post, do I want autosave to send in my 1/2 completed post?
The good point in tinyautosave plugin is that it is 100% client side, no server dependency, so it runs silently in the background and users don't need to do a thing. You only notice in editor that when an auto-save occurs, the toolbar button briefly animates...
What happens if the browser crashes?
You simply open the same browser again, navigate to the same textarea you was before server crash and press the button to get content back - try it yourself Michael...
I could imagine that this could fail if browser crashes exactly at the same moment when autosave is saving content. And it might fail if some rare browser does not support any of the 3 autosave data storage methods...it's hard to test all possible browsers.
I could not make my browsers crash in odd ways so my test method was to pull off power cable - then I restarted PC, opened browser, went back to test moodle and was able to restore content without trouble with this "content saver button".
The main idea is that the plugin uses your PC:s temporary internet files as local storage area so unless you clean browser histrory, cookies and files from temporary internet files the plugin should work with all modern browsers no matter if you press back button, close browser or press ctrl+alt+del
Some of our schools are using a cleaner tool that cleans all user files when you close/restart PC so there might be the first place where shutting down PC might be "non controllable operation"...
Honestly - this plugin is not necessarely perfect and can't be used for all cases (where you don't have editor) but it is good, easy to use and will be even better in the near future...
To make sure that it works I used the same power off method for latest IE8, FF3, Opera10 and Safari 4 but the plugin should be crossbrowser compatible also for older versions.
And there are actually 4 storage methods, I forgot one: http://code.google.com/p/tinyautosave/wiki/Technology
Michael, read also
http://code.google.com/p/tinyautosave/wiki/Functionality
That's great to hear!
I would be curious about what your implementation is like. Do you send changes to the server periodically, or only when there actually are changes? This might affect server load dramatically.
I would envision that the interval at which autosave is made, should be adjustable in addition to the chance of turning it off. Also different autosave functionalities in different contexts might have a different load on the server, so based on the performance of the server, the admin could turn on only the least intensive autosaves.
Do you overwrite the user's copy every time or can they restore an earlier version (or undo) in case of bigger mistakes?
I would be curious about what your implementation is like. Do you send changes to the server periodically, or only when there actually are changes? This might affect server load dramatically.
I would envision that the interval at which autosave is made, should be adjustable in addition to the chance of turning it off. Also different autosave functionalities in different contexts might have a different load on the server, so based on the performance of the server, the admin could turn on only the least intensive autosaves.
Do you overwrite the user's copy every time or can they restore an earlier version (or undo) in case of bigger mistakes?
I am a maths teacher - not a developer or expert of writing code - so it looks again too obvious to me (correct me if I am wrong!) that if we use database for autosave and each user action for each activity requires autosave action we easily double the server side (database) load. If we require that in addition to data autosaving process we need to control various error situations and shortcut keys with different pre-,on- and post-actions we easily triple server load.
Therefore a heavy autosave system might not only have serious effects to performance but it might also double the space used for databases unless autosave data is very effectively cleaned from database which (cleaning process) again increases server load...
In my opinion server side autosave features could be most useful only for such situations where client side autosave can't be used. Otherwise we'll easily create so heavy new features that in practice they can't be used on most "normal" hosted moodle sites
We are still talking about rare cases - moodle 2.0 can already handle most of those problematic user cases automatically - and replacement of HTMLArea (with TinyMCE) will leave current editor & textarea related cases to the history when moodle 2.0 is stable in HEAD and sites get upgraded.
Are there other "special cases" in addition to Quiz? Lesson, Workshop...?
Let's take an example: a "typical" moodle site might have 256 MB real memory, 300 MB virtual memory and 15 GB Local disc space
A site like this can no way handle moodle 2.0 with 50 concurrent users if a heavy autosave system is used. Most likely 2-4 GB Ram could be enough. It would mean that most moodle sites could use autosave features only if they had about 5 concurrent users ( I suppose my example site is rather typical moodle site - I don't have any stats) and most schools would not be able to use server side autosave at all.
It depends on your site, but on our system, the vast majority of web server and database activity comes from viewing pages - not posting.
Autosave to server would probably have a negligible effect, assuming it's implemented efficiently (one DB write and the minimum number of reads) and assuming we don't autosave too often (something like per-minute would be ok, IMO). In addition, there should be logic so that autosave only happens if the content actually changed - and not if I leave this page open for the next five minutes while I go do something else, for instance...
...(back now). Also, just to note, I don't trust concurrent-users as a useful measure, but that 256MB sounds really limiting for any use anyhow...
So anyway, it would depend on how the system is used, but I don't personally feel that server-side autosave facility would have a significant effect on the number of concurrent users the system should support. If you're really concerned about memory consumption, it would even be possible to make the autosave script bypass Moodle libraries altogether, thus requiring virtually no RAM...
--sam
Autosave to server would probably have a negligible effect, assuming it's implemented efficiently (one DB write and the minimum number of reads) and assuming we don't autosave too often (something like per-minute would be ok, IMO). In addition, there should be logic so that autosave only happens if the content actually changed - and not if I leave this page open for the next five minutes while I go do something else, for instance...
...(back now). Also, just to note, I don't trust concurrent-users as a useful measure, but that 256MB sounds really limiting for any use anyhow...
So anyway, it would depend on how the system is used, but I don't personally feel that server-side autosave facility would have a significant effect on the number of concurrent users the system should support. If you're really concerned about memory consumption, it would even be possible to make the autosave script bypass Moodle libraries altogether, thus requiring virtually no RAM...
--sam
If you can write such serverside autosave code that does not cause performance issues I have nothing to say against it - like I said before I am a maths teacher - not a developer or expert of writing code - so everything looks too obvious to me (thank you for these comments!)
The main point in my comments is that we already have a very light client side solution for autosave and page leaving warning available in tinymce and somebody should just finish (write) a server side code if you want to use it. No solution is still perfect - either they can't be used in all cases or they have some drawbacks...
The only argument against using the specific client-side code you mention would be that it is dependent on the editor, whereas server-side code could work with any/no editor (it would be saving the underlying textarea content).
In fact it would probably also be possible to build client-side code that is independent of the editor in use.
I don't see a particular reason against using client-side code, unless we think people might crash out on one system (eg a mobile device) and come back to it on another (a proper PC). Was just saying that a server-side system probably isn't catastrophic for performance. ('Not catastrophic' is still more than zero impact on performance.)
Usually, server-side code is more reliable than client-side code. However (while I haven't looked at how the TinyMCE system works) that isn't necessarily the case in this situation because the server-side system only works via complicated client-side AJAX calls. So if the client is screwed, neither will work.
--sam
In fact it would probably also be possible to build client-side code that is independent of the editor in use.
I don't see a particular reason against using client-side code, unless we think people might crash out on one system (eg a mobile device) and come back to it on another (a proper PC). Was just saying that a server-side system probably isn't catastrophic for performance. ('Not catastrophic' is still more than zero impact on performance.)
Usually, server-side code is more reliable than client-side code. However (while I haven't looked at how the TinyMCE system works) that isn't necessarily the case in this situation because the server-side system only works via complicated client-side AJAX calls. So if the client is screwed, neither will work.
--sam
Good points, Sam...
From current editors (F)CKEditor might be the most usable option for TinyMCE and if we want to use other editors in addition to TinyMCE (for example YUI RTE) they would need similar plugins too.
And what ever autosave system we choose it can't be worse than current system with no autosave features at all (with HTMLArea missing content...)
Thanks again for fresh comments, Sam!
Jeff made this comment in another thread:
There are some places in Moodle where a change is "instantly" saved. Like when assigning roles. But there are many pages where it is possible to loose something entered. I think it would be nice to have a JavaScript warning, if you have entered/changed something on a page without saving that warns you when leaving: "You have made changes on this page which have not been saved.
I think this is an important point in this discussion, as well: It is not at all clear that changes should not be autosaved at all times. At least there should be consistency: if changes are supposed to be saved in some screens with an explicit click of a button, that should be true everywhere: controls for modifying data should be separate from controls for saving data.
But since on the applications are typically server side and page loads are slow, that convention is hard to keep. If we require the user to save their changes after already having had to wait one page reload to use the controls in the UI, that is a considerable nuisance. When moving to javascript rich controls this issue is alleviated and it is easier to both
There are some places in Moodle where a change is "instantly" saved. Like when assigning roles. But there are many pages where it is possible to loose something entered. I think it would be nice to have a JavaScript warning, if you have entered/changed something on a page without saving that warns you when leaving: "You have made changes on this page which have not been saved.
I think this is an important point in this discussion, as well: It is not at all clear that changes should not be autosaved at all times. At least there should be consistency: if changes are supposed to be saved in some screens with an explicit click of a button, that should be true everywhere: controls for modifying data should be separate from controls for saving data.
But since on the applications are typically server side and page loads are slow, that convention is hard to keep. If we require the user to save their changes after already having had to wait one page reload to use the controls in the UI, that is a considerable nuisance. When moving to javascript rich controls this issue is alleviated and it is easier to both
- make all forms save themselves (though potentially heavy on the server), and
- to make even those forms that used to have submit buttons as controls for modifying form data (such as the assign roles UI), quicker to use and to require saving the changes in the end with an explicig submit.
Olli,
that's exactly what old autosave plugin of tinymce does - if you use editor for textareas and have added to init code (moodle 2.0)
'plugins' => "safari,table,style,tinyautosave,autosave,advhr,advimage,advlink,emotions,inlinepopups,{$xmedia}searchreplace,paste,directionality,fullscreen,moodlenolink,{$xdragmath}nonbreaking,contextmenu,insertdatetime,save,iespell,preview,print,noneditable,visualchars,xhtmlxtras,template,pagebreak",
Then you will get automatically a warning before getting out from the page...if you made modifications to a editor instance but didn't submit them.
This message is partly Finnish but it is freely translated:
Are you sure you want to leave this page?
The changes you made will be lost if you navigate away from this page.
If you want to continue press OK or select Cancel if you want to stay in current page.
In this example I pressed "Back" button from browser toolbar. Old autosave plugin does not have any button in toolbar, it just gives you those warnings if you try to leave editor without submitting changes.
So if we add both autosave and tinyautosave plugin to init code we don't need to write any code for moodle and both tasks are done automatically for those activities that use editor. Without any action on server.
The effortlessness of implementing that seems tempting
The only thing that worries me is that rich text editors are rarely the only form elements in the form. If we need mechanisms to keep other form data, all the mechanisms at rich text editor level can conflict with them.
And as mentioned many times, these dialogs can be perceived as disturbing. Having undo or changelogs for everything is always better.
The only thing that worries me is that rich text editors are rarely the only form elements in the form. If we need mechanisms to keep other form data, all the mechanisms at rich text editor level can conflict with them.
And as mentioned many times, these dialogs can be perceived as disturbing. Having undo or changelogs for everything is always better.
Javascripts can sometimes disturb each other - we don't know it before you have written those server side javascripts and we can test if some conflicts exist. Usually the problem is that some 3rd party javasripts disturb operations of editor or plugins but it is very easy to find out with error console and other debugging tools.
It is also very simple to add or hide a plugins with init code... and when Petr has finished his TinyMCE administration (for example hiding of buttons from administration of editor like it was done in moodle 1.9 and HTMLArea) hiding of useless buttons and dialogs is even simpler.
It's the same for dialogs - either we show them or don't show them...
Of course all kinds of dialogs are disturbing - no matter if they are useful or not - they are ment to be disturbing so that users don't go through such actions that make them loose their content and users won't need to search afterwards from logs or settings any tools they could get their content back or try to find an undo button that could cancel closing of a browser...
Is your last comment suggesting that it is better to undo and change things afterwards when something goes wrong than to prevent them beforehand? Can't be true... if you compare this situation to medicine it is always better to prevent diseases than cure patients...
These are just my opinions - and obviously my opinions don't get any larger support from developers so I will shut my mouth for a while (again).
I may come back to these usability issues when you have implemented those server side solutions - if there is anything left to comment... 
The difference between software development and medicine is that unlike medicine, we DO have the silver bullet that magically fixes everything EXACTLY back to the way it was. And creating that silver bullet may be a lot of work, but it is no rocket science.
Once we reach the situation where users feel they can trust Moodle, we gain a lot. The point with undo is that if users can rely on its existence, it facilitates learning. If users feel they can not do anything irreversible, they have the freedom to PLAY safely. And the only way anyone is going to effectively learn is by playing, by pushing the boundaries of the application, by getting creative.
If users constantly have an undetermined fear that if they do something wrong "the whole machine might explode" or "everything I worked on might disappear", they will not have courage to play.
Effective learning can only happen, if users feel that no matter what they do in whatever part of Moodle, they can *constantly* and *always* restore the situation. I guess this is our difference with the Iphone, too: http://johnnyholland.org/magazine/2009/08/the-iphone-is-not-easy-to-use-a-peek-into-the-future-of-experience-design/
Warning signs (alert dialogs) should be limited to situations where damage really is irreversible - only then users should have to explicitly demand it.
Most situations however are simple scenarios in which people just want to create something. They make errors, they mistakenly click the back button or try out what the black 'X' does next to an activity. And mostly these actions are not serious in themselves but are to be expected. Users should not have to fear the fragility of the system, but should be allowed to actually see the consequences of trying out the 'X' icon, and then undoing, having learned something about the nature of Moodle.
Once we reach the situation where users feel they can trust Moodle, we gain a lot. The point with undo is that if users can rely on its existence, it facilitates learning. If users feel they can not do anything irreversible, they have the freedom to PLAY safely. And the only way anyone is going to effectively learn is by playing, by pushing the boundaries of the application, by getting creative.
If users constantly have an undetermined fear that if they do something wrong "the whole machine might explode" or "everything I worked on might disappear", they will not have courage to play.
Effective learning can only happen, if users feel that no matter what they do in whatever part of Moodle, they can *constantly* and *always* restore the situation. I guess this is our difference with the Iphone, too: http://johnnyholland.org/magazine/2009/08/the-iphone-is-not-easy-to-use-a-peek-into-the-future-of-experience-design/
Warning signs (alert dialogs) should be limited to situations where damage really is irreversible - only then users should have to explicitly demand it.
Most situations however are simple scenarios in which people just want to create something. They make errors, they mistakenly click the back button or try out what the black 'X' does next to an activity. And mostly these actions are not serious in themselves but are to be expected. Users should not have to fear the fragility of the system, but should be allowed to actually see the consequences of trying out the 'X' icon, and then undoing, having learned something about the nature of Moodle.
An anecdote about how warning dialogs should NOT behave like:
A friend who does not particularly like computers (but likes to call me nerdy playfully;) once invited me to her place to check if her computer had a virus. She said she had been browsing the web and gotten an alert. None was initially found, and I asked her to show me the website, which she was visiting when the alert first came.
And sure enough when she did, the virus scanner (Avast! maybve? can't remember) popped up an alert window. But it was not your ordinary one: This one had a big flashing (police car style) red light animation, and the computer played a voice saying something like "A virus was found". When my friend encountered this dialog, she had gotten scared and instantly closed the dialog.
Only if she had read the fine print on the dialog, she would havelearned that the virus had already been blocked by the application.
Of course the virus scanner makers wanted to have the user know about the rare occasion the virus scanner had been useful. But if they had looked at the situation from the user's point of view, they might have made a much more subtle, small popup that would go away on its own and not seek attention like crazy: after all, the problem had already been dealt with and no user action was required.
A friend who does not particularly like computers (but likes to call me nerdy playfully;) once invited me to her place to check if her computer had a virus. She said she had been browsing the web and gotten an alert. None was initially found, and I asked her to show me the website, which she was visiting when the alert first came.
And sure enough when she did, the virus scanner (Avast! maybve? can't remember) popped up an alert window. But it was not your ordinary one: This one had a big flashing (police car style) red light animation, and the computer played a voice saying something like "A virus was found". When my friend encountered this dialog, she had gotten scared and instantly closed the dialog.
Only if she had read the fine print on the dialog, she would havelearned that the virus had already been blocked by the application.
Of course the virus scanner makers wanted to have the user know about the rare occasion the virus scanner had been useful. But if they had looked at the situation from the user's point of view, they might have made a much more subtle, small popup that would go away on its own and not seek attention like crazy: after all, the problem had already been dealt with and no user action was required.
I hope you can still remember where you shot that silver bullet, Olli...
Good luck in searching it.
Olli,
with all respect read your original question and think for example those neutral examples that Paula mentioned:
If the user FORGETS to save his/her work or does no have patience to WAIT untill uploading a large file is finished or computer seems to time out and user does not UNDERSTAND what is going on or teacher does not press CHOOSE when he/she should have picked a file and can't even REMEMBER afterwards - it may take a week until teacher asks about missing assignments - how do logs or cool autosave features or undo buttons (no matter if they are server side or client side) HELP student in this kind of cases where autosaved data may have been already deleted (if it was never created...or can such cases even be written to logs...) if nothing warns about their catastrofic user actions. If student does not even KNOW he/she has done something wrong - data is just lost and student has no idea why.
If we on the other hand talk about differences between medicine and software development there SHOULD NOT BE ANY DIFFERENCE in attidutes to pre- and post- cases. The truth is that even if you may think you are the best developer on earth you simply can't help all your "patients" afterwards - you will never find such a silver bullet in software development that lets you magically fix everything EXACTLY back to the way it was. It's not rocket science - it's IMPOSSIBLE.
The same way it is never possible to prevent all accidents with any guides or warnings - some things just happen differently than we had planned them to happen. My wife is a doctor of medicine and she always points this pre- post- issue - no matter what area of life we are talking about. You are simply wrong in this case when you take virus popups to mess up situation - I thought we were talking about totally different thing than spam or advertisement popups - at least in my opinion we were talking about helper systems that guide users to avoid wrong choises so that they don't need to ask help afterwards or teachers don't ask administrators to check logs or try to find out what could have happened.
I have also teached mathematics about 20 years and can assure you that effective learning can happen without any restore options - effective learning can happen even without the whole moodle. Read once again the feedback by Bridget Robbins in http://moodle.org/mod/forum/discuss.php?d=130007#p569129
Warnings and notes should be essential part of education and helper systems that are ment to guide students and teachers to avoid risky actions and to choose correct options if it is possible to avoid risky situations before they happen - Laissez-faire leads more often to irreversible actions than you may have noticed.
I do agree we cannot predict what users do. Tools like personas and scenarios are for helping us understand roughly what different kinds of target users might want to do in different situations. Usability testing reveals what kinds of traps we might have inadvertently created for users in our designs. But just because nearly nobody is actually doing user testing in the Moodle community, it is no excuse to say that it is impossible to understand in the first place.
We cannot predict what people do, but we can determine what the application we build can be used for. By definition we do have a system where all possible user actions can and have to be designed beforehand. If we can design them, we can also store the information related to them and manipulate it afterwards. Here, you cannot compare medicine to computer science, since we do not have access to the information processing of human beings nor the power to debug nature. However, there are software patterns that facilitate undo (http://en.wikipedia.org/wiki/Command_pattern ), and for the majority of user actions, it is not any more impossible on the web than it is on the desktop to implement undo. It is a challenge, but by no means theoretically impossible.
The scenarios you mentioned are very much relevant. And you are right, undo is not the relevant solution to any of them, but user centered design (http://en.wikipedia.org/wiki/User-centered_design) and basic usability methodology such as heuristics and usability testing are - though they are not employed widely in Moodle yet. If students have deadlines, they should have the possibility of choosing to have reminders by e-mail, for example. If the web page does not give feedback about uploading a file and the user assumes the browser must be stuck and closes the window, it is not about the user's impatience but a usability lack of the software.
The measures we take to avoid user misunderstanding in advance and those that allow users to go back when they have misunderstood anyway need to complement each other.
We cannot predict what people do, but we can determine what the application we build can be used for. By definition we do have a system where all possible user actions can and have to be designed beforehand. If we can design them, we can also store the information related to them and manipulate it afterwards. Here, you cannot compare medicine to computer science, since we do not have access to the information processing of human beings nor the power to debug nature. However, there are software patterns that facilitate undo (http://en.wikipedia.org/wiki/Command_pattern ), and for the majority of user actions, it is not any more impossible on the web than it is on the desktop to implement undo. It is a challenge, but by no means theoretically impossible.
The scenarios you mentioned are very much relevant. And you are right, undo is not the relevant solution to any of them, but user centered design (http://en.wikipedia.org/wiki/User-centered_design) and basic usability methodology such as heuristics and usability testing are - though they are not employed widely in Moodle yet. If students have deadlines, they should have the possibility of choosing to have reminders by e-mail, for example. If the web page does not give feedback about uploading a file and the user assumes the browser must be stuck and closes the window, it is not about the user's impatience but a usability lack of the software.
The measures we take to avoid user misunderstanding in advance and those that allow users to go back when they have misunderstood anyway need to complement each other.
There's no prospect of achieving 'always-works' undo in Moodle as a standard behaviour before Moodle 3 at the earliest - so we should be cautious about adding it in limited areas. Not that we shouldn't add it, but that we should make sure it's done in a way that clearly undoes only specific actions, and doesn't imply a system-wide undo facility.
There are also some cases where undo will never be appropriate:
]
In reality the most important places where Moodle needs undo are when deleting things; so undelete is more important than undo in the short term. In general, 'teachers' (or local equivalent) cannot be trusted with a hard delete facility; when a teacher deletes a module or block, it should actually just be hidden and available for restore later. I know administrative staff here would be very grateful for such a feature; not sure if it's already in Moodle 2...
--sam
There are also some cases where undo will never be appropriate:
- Some actions (e.g. those which send email) literally cannot be undone.
- Many actions should not be undone completely because Moodle is a shared application. For example, if a user posts something offensive to a forum, they should not be able to undo that post entirely (without leaving any evidence) because if other users complain, administrators may need to be able to confirm what was really posted. Similarly, if a user posts a message, then other users reply to it, users should not be able to completely undo their 'message post' because what happens to the replies?
In reality the most important places where Moodle needs undo are when deleting things; so undelete is more important than undo in the short term. In general, 'teachers' (or local equivalent) cannot be trusted with a hard delete facility; when a teacher deletes a module or block, it should actually just be hidden and available for restore later. I know administrative staff here would be very grateful for such a feature; not sure if it's already in Moodle 2...
--sam
Thanks, Sam. These are all valid points. Of course, I was painting in very big brush strokes.
The important part is that users should perceive Moodle as reliable, to enable them to play and to enable them to explore all the potential in Moodle. There is naturally no single solution to this, but I am trying to get different options fair exposure in the discussion.
The important part is that users should perceive Moodle as reliable, to enable them to play and to enable them to explore all the potential in Moodle. There is naturally no single solution to this, but I am trying to get different options fair exposure in the discussion.
Got this response from Paula, and realized that indeed, making uploading as fluid as possible may indeed be a big part of this issue!
http://moodle.org/mod/forum/discuss.php?d=130007#p570669
I have seen AJAX and flash uploaders that give progress bars, which would be an enormous improvement since without feedback uploading big files is *really* tedious.
Also, does Moodle currently give proper feedback when users try to upload too big files?
Sidethought: Interestingly, the default UI for uploading files in Google Chrome is different from the usual implementation, and I have to say it seems better than the one in Firefox for example. There should be no text input box when the file name can not be changed in the input box.
(I moved to using the dev version of Chrome some days ago since my laptop is old and Firefox is too heavy for it with all my extensions - Chrome has almost no extensions so I can't make it too heavy ;) )
http://moodle.org/mod/forum/discuss.php?d=130007#p570669
I have seen AJAX and flash uploaders that give progress bars, which would be an enormous improvement since without feedback uploading big files is *really* tedious.
Also, does Moodle currently give proper feedback when users try to upload too big files?
Sidethought: Interestingly, the default UI for uploading files in Google Chrome is different from the usual implementation, and I have to say it seems better than the one in Firefox for example. There should be no text input box when the file name can not be changed in the input box.
(I moved to using the dev version of Chrome some days ago since my laptop is old and Firefox is too heavy for it with all my extensions - Chrome has almost no extensions so I can't make it too heavy ;) )
Paula is right - if files are really large the risk that user closes browser is high but it's partly a server configuration issue. I am not sure if moodle can somehow check file size before it even starts uploading the file if file size is bigger than given max file size values - probably not...
The main settings that should be somehow checked or controlled are (at least)
max_upload_size,
post_max_size,
memory_limit,
max_execution_time,
max_input_time in php.ini
Apache LimitRequestBody
IIS-> default web site -> properties - > connection timout
MaxRequestEntityAllowed and AspMaxRequestEntityAllowed on IIS
If these settings don't allow uploading large files you can't make file upload settings of moodle larger than allowed server limits and moodle just shows a text
"Uploaded file exceeded the maximum size set by the form"
for such files that are not uploaded if they are larger than settings of moodle allow...
Sometimes uploading of large course backup files can take minutes and you are ready to believe that your browser has stopped responding altough moving files through www simply takes a long time. Some kind of a progress bar would be useful (if moodle knows the file size and can create that progress bar...)
Ah yes, at current it requires flash it seems:
http://developer.yahoo.com/yui/uploader/
Since this is such a great benefit vs. not having the progress bar, Wordpress handles the risk of the flash solution not working (for a reason or another) with a warning:
Especially see uploading multiple files:
http://developer.yahoo.com/yui/examples/uploader/uploader-advanced-queue.html
http://developer.yahoo.com/yui/uploader/
Since this is such a great benefit vs. not having the progress bar, Wordpress handles the risk of the flash solution not working (for a reason or another) with a warning:
Especially see uploading multiple files:
http://developer.yahoo.com/yui/examples/uploader/uploader-advanced-queue.html
Another chance to make users perceive Moodle as more responsive and, at the end of the day, more reliable:
Inline Validation in Web Forms
http://www.alistapart.com/articles/inline-validation-in-web-forms/
Inline Validation in Web Forms
http://www.alistapart.com/articles/inline-validation-in-web-forms/
That's a really good link, Olli
The same form guru, LukeW, that I mentioned in http://moodle.org/mod/forum/discuss.php?d=129719#p568833
Those test forms can be found and downloaded from
http://www.nexpace.com/?page=code&sub=form-validation
The only tiny "minus" is that even these form experts are using red and green in the same form...
PS that old link in my previous post seemed to be broken but here you have two more LukeW links:
http://www.lukew.com/resources/articles/WebForms_LukeW.pdf (original)
http://videos.visitmix.com/MIX09/C17F (presentations)
Another interesting note - forms in http://www.nexpace.com/?page=code&sub=form-validation have rather strict rules compared to our discussions for example in http://moodle.org/mod/forum/discuss.php?d=131286 - Swedish or finnish names starting with Å, Ä or Ö can't be used not to mention chinese etc names ... try for example Åke Äkäslompolo or 元春 in http://validation.nexpace.com/v7/signup-persist-onfocus.html
Design and functionality of different validation effects are really nice in these example forms - but if I disabled javascript no validation was done and a nice message told that all my non valid values were accpted with
Thank You!
You've successfully completed this form.
Haha . Yes, LukeW is appraised quite a bit.
Just to keep this clear to any random passers-by:
It does not _hurt_ to use colour to differentiate items, as long as you don't rely on just colour (in the above example, also shape and symbol are used so no probs).
(Using colour was avoided altogether in the solution of MDL-20011 just to avoid making the UI appear too cluttered: to have the sign available when you need it, but not to force it on you when you don't.)
Just to keep this clear to any random passers-by:
It does not _hurt_ to use colour to differentiate items, as long as you don't rely on just colour (in the above example, also shape and symbol are used so no probs).
(Using colour was avoided altogether in the solution of MDL-20011 just to avoid making the UI appear too cluttered: to have the sign available when you need it, but not to force it on you when you don't.)
To back this point up if anyone is interested, a site I found last night...
http://wearecolorblind.com/
(Design Patterns for the Colour Blind)
http://wearecolorblind.com/
(Design Patterns for the Colour Blind)
Thanks for the link,
Joseph (a color-blind person).
Joseph (a color-blind person).