Moodle uses quite a lot of dropdown menus for yes/no questions. These require (at least) two mouse clicks for selecting an option. Therefore alternatives like a simple checkbox or radio buttons would make for better usability and avoid some inconsistencies in the Moodle UI (see screenshot).
See http://www.idrawboxes.com/2008/yes-no-questions-dropdown-radio-buttons-or-checkbox/ and http://www.isocra.com/2008/02/poll-a-yesno-question-in-a-web-form-which-controls-would-you-use/ for further information.
Frank
Yes-No_vs_checkbox.png
Frank,
I could not agree more. There are quite a few places in Moodle where I find those Yes/No dropdown menus quite irritating, for example on the course backup page (see attached extract). Radio buttons are way to go.
Joseph
I could not agree more. There are quite a few places in Moodle where I find those Yes/No dropdown menus quite irritating, for example on the course backup page (see attached extract). Radio buttons are way to go.
Joseph
Consistency is always a good UI guideline to follow. Personally, I'm the type of person that always prefers dropdowns over radio buttons. Dropdowns take less space than radio buttons. Also depending on the css styling, dropdowns have less issues with floats and overflow.
Consistency is critical, and this would be good changed everywhere. Jakob Nielsen's take on this:
[ ] Shuffle questions
- Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.
- Checkboxes are used when there are lists of options and the user may select any number of choices, including zero, one, or several. In other words, each checkbox is independent of all other checkboxes in the list, so checking one box doesn't uncheck the others.
- A stand-alone checkbox is used for a single option that the user can turn on or off.
[ ] Shuffle questions
One other comment here, something I find frequently confusing is the use of a single checkbox, usually empty, with a Default statement. Consider the example screenshot.
Usually, a checked checkbox I think of as Yes, and an unchecked checkbox as No. I believe that is the intent in these cases in Moodle. However, given the many settings in Moodle, suppose I come back to this page later, and can't remember whether I checked or unchecked the box in the screenshot. If I check it now, does that mean I want the default No, or does it mean I am checking the box to say Yes? If it is unchecked, am I safe to assume that unchecked is No, the default? To me, I think it would be clearer to use the radio buttons to have it always clear that the value is set to a specific state.
Carvell
Very good, thanks. I had forgotten about this.
I had heard about this before but only now I get it, I think. This shows pretty well how intricate some UI problems can be: who would have thought it makes any difference if the label describing a checkbox is on the left (wrong) side of the box, compared to how it is recommended to be used?
Maybe it would not matter, if there was nothing on the right side. Now it really does. Of course, the way the visual structure of Moodle forms is done so far makes doing this really right pretty difficult.
Stating the default value can still be tricky. Just created a ticket: MDL-19659 to do think about it further and to test it.
Would it help to state it more verbosely: "By default, this check box was checked."? Maybe, but it is awkward, and a pain to read. A graphical representation of the default state? That is pretty intrusive and will probably confuse even more users. One way to do it would be to add something unintrusive (small link?) to just restore that one value to its default. That only risks the user clicking it by accident and then trying to figure out the value they (someone else?) had set for it. So another link that would say "restore previous value"? Ha-ha. Umm, no.
I'll actually need to make it clearer what is recommended for progressive disclosure.
I had heard about this before but only now I get it, I think. This shows pretty well how intricate some UI problems can be: who would have thought it makes any difference if the label describing a checkbox is on the left (wrong) side of the box, compared to how it is recommended to be used?
Maybe it would not matter, if there was nothing on the right side. Now it really does. Of course, the way the visual structure of Moodle forms is done so far makes doing this really right pretty difficult.
Stating the default value can still be tricky. Just created a ticket: MDL-19659 to do think about it further and to test it.
Would it help to state it more verbosely: "By default, this check box was checked."? Maybe, but it is awkward, and a pain to read. A graphical representation of the default state? That is pretty intrusive and will probably confuse even more users. One way to do it would be to add something unintrusive (small link?) to just restore that one value to its default. That only risks the user clicking it by accident and then trying to figure out the value they (someone else?) had set for it. So another link that would say "restore previous value"? Ha-ha. Umm, no.
I'll actually need to make it clearer what is recommended for progressive disclosure.
Here's an even crazier use of checkboxes and default settings: User:Frank Ralf/Moodle forms1#Checkboxes.
Frank
Frank
Ohh, /me likes this page
(I'll add things off it to the guidelines I think).
oops, I didn't know you can resize these smilies :D
Oh, but it didn't save the size. Riiight.
I am not sure I agree if that one is really serious at all, but it does seem a bit strange.
(I'll add things off it to the guidelines I think).oops, I didn't know you can resize these smilies :D
Oh, but it didn't save the size. Riiight.
I am not sure I agree if that one is really serious at all, but it does seem a bit strange.
I guess I would ask the question does the default value in these cases add any necessary information? I understand if the goal is to display a recommended setting, especially in when it applies to security settings. For example, if you deviate from the recommended security, there could be consequences. But in the screenshot case, is it actually important for me to know what the default is? I would argue no. I only care that I can always tell what the value is set to, and that it is clear what will happen if I change the state of the control. In the case of the screenshot I included, if there were no default text, then I think it would be clear that the checkbox is a yes/no, or an on/off.
Carvell
Another confusing thing about that form is: does the "Default: No" apply to the dropdown, or to the "Advanced" checkbox? It seems like logically, it would apply to the dropdown, but by proximity, it is linked more closely to the checkbox.
Here's another one, this time from Moodle 2.0.
Actually, the AJAX setting for the main course page is dependent from the site wide AJAX setting, but that's far from clear in this form, especially as the YUI option was added between those two.
Or what do you get if you uncheck both AJAX boxes? Logic would dictate that this would mean AJAX for ONLY the main course page.
(See also http://docs.moodle.org/en/User:Frank_Ralf/Moodle_forms1#AJAX_and_JavaScript)
Actually, the AJAX setting for the main course page is dependent from the site wide AJAX setting, but that's far from clear in this form, especially as the YUI option was added between those two.
Or what do you get if you uncheck both AJAX boxes? Logic would dictate that this would mean AJAX for ONLY the main course page.
(See also http://docs.moodle.org/en/User:Frank_Ralf/Moodle_forms1#AJAX_and_JavaScript)
Nice catch, Frank. I find that AJAX and Javascript options screen totally unintelligible.
I tampered a bit with that form and created a suggestion for an improved version.
Frank
BTW
I noticed that legend elements for fieldsets are turned off by default on administration pages:
#adminsettings legend {
display: none;
}
Besides causing me some headache because my legends weren't showing I think this misses a chance to better structure forms and make them more usable.
Frank
BTW
I noticed that legend elements for fieldsets are turned off by default on administration pages:
#adminsettings legend {
display: none;
}
Besides causing me some headache because my legends weren't showing I think this misses a chance to better structure forms and make them more usable.
AJAX_and_JavaScript_improved.png
I still don't understand the difference between Enable AJAX and Enable AJAX course editing.
For example, what are the things that can still be done with Enable AJAX set to YES and Enable AJAX course editing set to NO ?
Joseph
For example, what are the things that can still be done with Enable AJAX set to YES and Enable AJAX course editing set to NO ?
Joseph
Have you tried searching the code for $CFG->enableajax, etc.
No, Tim, I haven't. But if an admin has to search the moodle code for $CFG->enableajax in order to understand the workings of that Enable AJAX setting, then it does mean that that setting is pretty obscure and not self-explanatory, don't you think?
I wasn't suggesting that typical admins do that. I was suggesting that you, as a developer, should do that if you really want to understand what is going on.
If I understand Development:lib/formslib.php Form Definition#Use Fieldsets to group Form Elements correctly you won't be able to create nested fieldsets, which might be a drawback for creating better structured forms.
On the other hand, it may be that if you think you need nested fieldsets, you should instead be re-thinking your UI, becuase the chances are it is too complicated.
Point taken (but IMO one level deep nesting should be OK).
If only we could always rely on formslib to make such wise design decissions for us...
If only we could always rely on formslib to make such wise design decissions for us...