Moodle

Mouli, thanks for your suggested improvement.

Just to confirm, if you enter a username and an email address in the forgotten password form, the message "Enter either username or email address" is repeated twice. I guess some javascript can be used to grey out one of the boxes.

Assigning to Eloy for consideration.

Please see MDL-19563 for further comments about this issue.

Graying the other field out in addition to what is suggested at MDL-19563 can help I guess, but requires javascript so we cannot depend on it.

Thanks, Helen for clearing the duplicate.

why not just add one field and say - Type your username OR email?
It should not be significantly less secure imho.

This is not really a critical issue, but it is an important feature and should be done right nonetheless, so I will try to explain the reasoning in MDL-19563 in more detail.

It is clearest to the user to do the communicate just what has been attempted in the UI already, but do it all the way. This does not clutter the UI since there is nothing else in the UI, there is no reason to make the UI more simple than the functionality actually is. It may be even more confusing to some users if a single field is actually acting in two roles.

Heuristics of UI design (http://www.useit.com/papers/heuristic/heuristic_list.html):
"Consistency and standards - Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. "

• Form fields take in one type of data. Allowing different types in one field is unconventional and unnecessary.

The UI makes the user make a selection between their username and their e-mail - the clearer this fact is communicated to the user, the better. I believe this is how the HTML elements were designed to be used in a situation like this: It makes sense to have two fields since these are two different questions to answer, in this case they are just alternatives. It makes sense that they have their own submit buttons since there are two different operations to trigger.

Combining the fields is a hack in terms of the UI logic and in terms of the underlying technology. This shows in the fact that validating the field becomes nontrivial if there is only one. If the user attempted to input an e-mail address but failed to enter '@', the form processing would supposedly decide the user tried to enter a username, since what they gave can not be recognized as an e-mail address. The user needs feedback, and if what they entered was not found, they would be even more confused should Moodle tell them that the username they entered was not valid.

The discussion this originated from:
http://moodle.org/mod/forum/discuss.php?d=123512#p546931

Thought about this a bit more:

Using javascript to disable the other field in forgot password may be confusing, since the planned UI for this does not directly communicate why the other field was disabled. Usability is also about taking into account the user's temporal circumstances; the user may not be concentrated on the screen continuously but may have done something and may return to the UI in its unfinished state, and may not remember what they have previously done to explain why the UI looks like it does.

A user may start writing in one field and then change their mind if, for example, the e-mail they tried was not working. When they return to the page with the back button, the username field may be disabled and they don't know why or how to fix it.

So, I recommend to just have two separate forms with a submit button for each and no javascript involved whatsoever.

A patch that applies to current 2.0 HEAD, and possibly even to 1.9 since I guess this has not changed much?

This is otherwise ok now, but, ehm, the second form ("Find by email address") does not work. The validate method never gets called, for example, and even if the input is OK nothing still happens but the form always returns to display the forms. I have no idea why QuickForm does not seem to allow two separate forms on a page, and will keep debugging. Just thought maybe someone else knows a solution to the strangeness of QuickForm/mforms.

Not usability tested yet. Will see if I manage to do that.

Tim, if you feel like it you can check out the patch. See the ticket for details on how it does not work yet .

Yes. You may have found a formslib bug.

This is a way round this. If you look at question/import.php, which will either let you choose a course file, or upload a file directly, you will see another way to handle this. bascially, do one form with two submit buttons, and give the two submit button different names, so you can tell which was clicked.

Oh no, but that is so ugly! And may introduce further usability/accessibility point since the whole point of this is that not only the fieldsets, but also the forms are separate. It does not matter if it looks good to a regular browser, a screen reader or anything else depending on the actual document semantics will still likely be confused. Alas, we are back to square one.

So you're sure there's no way around this?

I wonder if this is a quickform or formslib/mforms (what's the difference?) bug. Will try to see if there is sth related to quickform.

Now that I still remember: the patch overwrites one lang string. Feel free to change this, I wasn't sure what to do.

-$string['passwordforgotteninstructions'] = 'Your details must first be found in the user database. Please enter <strong>either</strong> your username or your registered email address in the appropriate box. There is no need to enter both.';
+$string['passwordforgotteninstructions'] = 'To reset your password, submit your username or your email address below. If we can find you in the database, an email will be sent to your email address, with instructions how to get access again.';

Just since I am doing usability testing, here are the new/changed strings translated to Finnish.

A patch with some minor improvements to the previous one. This version has been usability tested with 100% success rate so far (two more test subjects to come). More information about the test will be posted at http://www.pilpi.net/software/moodle/ and later in Moodle Docs.

I am bad at compromise. But here is the attachment that now looks like two forms but actually is exactly the same one form functionality wise as the previous one.

That is, it is not really necessary to recognize the submit button since the original code already has recognition for what field the user filled.

I really can not see danger in the situation where a user would, for some reason, purposefully fill in a field in one fieldset and then press the submit button in the other fieldset. That is the only situation where this does not work like two forms would, in addition to the situation where there is input in both fields or no input in either.

Then there is the accessibility disaster mentioned above, which makes this particular patch hard to submit. It does not seem likely anyone would ever end up trying to fix such a bug, unless the motivations to do things dramativally change in the community.

That is, loginformpatch2009-08-15-compromise.txt is the current fix to this bug that applies to Moodle 2.0, which still needs to be fixed with reverting those changes and then by applying patch2009-08-15.txt - as soon as mforms starts to work. Tim, please tell me if I should create another bug for that.

Wordpress is doing it better again.

If you request the email twice, it tells us:
Login error
A password reminder has already been sent, within the last 24 hours. To prevent abuse, only one password reminder will be sent per 24 hours.

And well, the form in Wordpress is just as simple as I guess it should be. Now that I see it I think that might have worked better. (Especially due to the formslib bug we have that makes it impossible to have two forms on the same page and thus probably makes the current solution not accessible). Nonetheless, since we now have promising usability test results for my design
http://www.pilpi.net/software/moodle/2009/08/19/quickie-usability-testing-file-upload-and-forgotten-password/
and none for that of Wordpress, I still recommend keeping my design for now.
http://demo.opensourcecms.com/wordpress/wp-login.php?action=lostpassword

Also, this was the original suggestion. http://moodle.org/mod/forum/discuss.php?d=123512 . Painful :F

Committed to CVS. Thanks Olli.

Thanks!

Tim, I remember you saying lang strings are immutable, so as you seem to now have committed the change of a lang string in my patch (which I asked about earlier) just want to make sure this was not a mistake?

Will translators notice such changes and change other languages accordingly?

Oops, I missed that. I have now created a passwordforgotteninstructions2 string for the changed string. Thanks for noticing Olli.