Two problems with this:
1. Speed of use
There are two aspects to usability: ease of use (which this topic aids) and speed of use. (Speed could also be referred to as reducing frustration, making life easier, etc. It's not just about making things faster, it's about making you less likely to throw a brick through your computer monitor.)
When somebody doesn't know how to use software or a particular area of software, ease of use is critical. When they do know how to use it, speed of use is critical.
So clicking through to an 'Advanced' screen can be a big problem if it is an operation people need to use frequently. We have a team of experienced and busy administrators working here and anything that makes their life harder or more tedious is a bad thing.
2. Site policy
Depending on site policy, some facilities which might be 'advanced' for most sites could in fact be 'required' for others. For example, the grouping facility is turned off by default and is also marked as 'advanced'. However, we use groupings extensively and with our configuration it is an error not to select the correct grouping. Hiding a field which specifically requires consideration is obviously bad design.
So there might be some cases where a field/option which is 'advanced' for normal usage is in fact 'important' on a particular site.
My suggestions would be:
- Advanced features should not be moved to new separate pages unless we are sure there are no circumstances where people would want to use that feature on a regular basis.
- When advanced features are hidden within a page, and users choose to show these advanced features, they should 'stay shown' in future until the user chooses to hide them.
- The 'show/hide' decision should probably be remembered per screen/form/area not globally, as a user may be experienced in one area but not others.
- The 'show/hide advanced' feature should use a standard interface so that it behaves the same way everywhere and is obvious to users.
- site policy (my issue #2 above) might suggest that there should be a standard way to configure specific screens so that they always show their 'advanced' features (the 'show/hide' button disappears). In other words administrators can 'lock' the show/hide button. However I don't feel this is a critical feature provided that the standard show/hide is remembered per user between sessions.
sam marshall 12:15, 2 June 2009 (UTC)
- sam: show/hide advanced on moodle_forms is of course persisted via get/set_user_preference.--Tim Hunt 13:53, 2 June 2009 (UTC)
I would like to see this page have clear, specific examples that show exactly how and where we do this in Moodle.
For example: in the form when adding/updating a quiz, there are several options deemed advanced that are hidden behind a button. This happens because:
- the module implements a set of default defaults for which items are advanced
- the module has implemented a settings page that allows the admin to change those defaults if they want to
- the module uses mform which uses the settings to flag what is advanced and what isn't
- mform will automatically create the interface based on these settings plus user preferences for "stickiness"
I'd be the first to argue that the actual interface generated by mform is not the most usable and could be improved, but the great thing is that if all developers implement progressive disclosure this way then it means that usability for this specific example of progressive disclosure CAN be fixed across Moodle simply by fixing mform.