Checkbox
Moodle User Interface Guidelines > Guideline template
This guideline template acts as instructions on how to write a guideline. It describes what should appear under each heading. For relevant guidelines (patterns) on pattern writing, I have referred to relevant sections in A Pattern Language for Pattern Writing.
Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.
This is a guideline template for a Moodle Interface Guideline. Comments: developer forum thread
Problem
Describe the problem this guideline is a solution to. Imagine the situation in which a developer is when they need this guideline, and describe it as briefly as possible, but still being detailed enough to enable the reader to recognize if this guideline is what they need or not. Ensure the problem is also kept separate from the constraints of the Solution.
Example: Progressive disclosure#Problem
Further information: Mandatory Elements Present
Context
Describe the situation/context a developer is in when they need this guideline. Do not repeat information already in the problem section.
UI design problems are always being solved in a specific context, or situation. Sometimes, you can describe the context by mentioning the guidelines that have already been applied. It depends on the context which forces (see the following heading) are prioritized while selecting a solution.
Example: Progressive_Disclosure#Context
Further information: Mandatory Elements Present
Forces: factors that affect selection
List all the consideration that appear that affect choosing the solution. These often appear as points for or against the Solution. Formulate them so that they are independent of the solution and just relate to the problem. This is to make the guideline Single-Pass Readable.
Forces: The often contradictory considerations that must be taken into account when choosing a solution to a problem.
Further information: Mandatory Elements Present
For example, while writing the guideline for progressive disclosure, the following force was identified:
- "Administrators need to 'lock' the show/hide button [of progressive disclosure] because on some sites the functionality is needed by everybody"
To make it independent of the solution, I included only the force (problematic consideration) in it here, and moved the solution (locking the show/hide button) into the Solution part of the guideline:
- "Some functionality that is rarely needed on some Moodle sites may be always-required basic functionality on other sites."
Further information: Visible Forces
Solution
For on/off choices where there are two options,
Create a checkbox with an id attribute. Add a <label for="id_of_checkbox"> element after the checkbox. As the text content of the label element, write the result of checking the box:
[] Show me the money
Determine a reasonable default for the value: checked, or unchecked. the reasonable default should be such that if a user does not notice the option, they probably do not mind leaving it to default. If no reasonable default can be determined, you may want to consider highlighting the checkbox in the form it is in, since it is impossible to make a checkbox a required field per se.
(Another use of the checkbox is to require users to always check a checkbox, i.e. "[ ] I have read and I accept the terms and conditions", but in this case it is not really an option at all.)
Common mistakes
Do not express the option label as a question: "Do you want to see the money?"
Do not invert the option to negative voice: "Don't show me the money". Most times, only positive voice should be used.
Do not use radio buttons or dropdowns when there are only two choices.
Examples and implementation
Related guidelines
- Radio buttons
- Switch Button
- Sometimes extra options should be hidden with Progressive disclosure
