Difference between revisions of "Usability issues - Hiding"
m (Student projects/Usability issues/Hiding moved to Usability issues - Hiding: adding to development namespace)
Latest revision as of 08:30, 14 August 2008
Would distinguishing between visible and accessible cause more confusion than it is worth?
Visibility can be applied for two purposes:
- To put all the information in the course and make it visible to students when the teacher thinks the time is appropriate. This option is really useful as it saves time to the teacher when designing the course.
- To help teachers when designing a course so information that they are not going to need does not disturb them. This helps that dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility (mentioned in Nielsen Ten Usability Heuristics.
However, it does not make sense to make at 2 the resource linkable because it would reduce visibility. Obviously, it would be very indispensable this property in 1.
If we continue to use an icon, how do we toggle through three or more options?
Let's study how implement this at Firefox and Gmail, two open source applications:
- Firefox: in the horizontal menu there is a view label where you can change the visibility of the toolbar. To view / hide the resources there is a checkbox. It uses checkboxes because every single option has its stand-alone checkbox.
- Gmail: there is a radio button in order to select if a resource is enabled / disabled (for example shortcuts, quicklinks, etc.) It used radio buttons because enable / disable are exclusive.
Here there is a detailed explanation of radio buttons / checkboxes:
- 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.
More information about guidelines of radio buttons / checkboxes can be found at Nielsen's Website
Are there times/circumstances when the open eyeball should be called hide.gif?
Where is the open eyeball or closed eyeball being use in Moodle? Is the the open eyeball or closed eyeball being consistent?
- Site Administration -> Users -> Authentication -> Manage authentication. Here the open/close eyeball means to activate/deactivate authentication plugins more than show / hide functionalities.
- Site Administration -> Modules -> Activities -> Manage activities. The hide/show column allows selected modules to be hidden i.e. they do not appear in any course "Add an activity" dropdown menu and cannot be used in any course. To hide a module, click the eye icon so that it changes to a closed eye.
- Site Administration -> Modules -> Blocks -> Manage blocks. The hide/show column allows selected blocks to be hidden i.e. they do not appear in any course "Add a block" dropdown menu and cannot be used in any course. To hide a block, click the eye icon so that it changes to a closed eye.
- Site Administration -> Modules -> Filters -> Manage Filters. If you click the eye icon opposite the filter, it changes to an open eye and you enable that filter.
- In http://localhost/course/view.php with the turn editing on. You can show / hide courses individually. If it's the eyeball open means that is visible, and if it's closed means that it is invisible.
There is the classic dispute of whether the icon displays the current value or the value to be implemented. However, Moodle is consistent as in all cases it displays the current value, but if you put the mouse over the icon the description is about the value to be implemented. So in this case, it is consistent. However, it would be desirable that when you put the mouse over the icon, it gives more information than "hide" or "show" and explains what it is hiding or showing. This would give more information to the user.
The user can get confused also in using hide / show at blocks. Perhaps the user could think that it is talking about blocking in a denying context, so confusion can appear (you enable blocking?) This problem could be solving by adding a more detailed description when you put the mouse over the icon (for example in hiding / showing a week in number 5 a detailed description is given, but not in other cases where this functionality is being used).
Set of policies that would allow users to know what they are doing and help developers to code it
- The icon displays the current value, but if you put the mouse over the icon, the description is about the value to be implemented.
- When you use the show / hide, when you put the mouse over the icon, it should say "hide this week for students", not only hide. The whole information about the hiding must be displayed.
- When you show / enable something, the colour of the description should turn black or dark blue. If you hide / disable something, the colour of the description should turn grey or light blue.
- Recommendation: it would be more standard and usable to change the visible / hide icon for a textbox "view" and a stand-alone checkbox in order to select if it's visible or not, at list in the tables where icons are not necessary because there is enough space.