Progressive Disclosure
| Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable. |
Moodle User Interface Guidelines > Progressive Disclosure
Problem
You have lots of features, some of which are only needed by a part of your user base and (seriously) distract the rest.
- You have allowed a wide variety of users (user groups) into your user base, which has lead to varying goals. Some are just learning or only want to get the job done. Others want to do something (that requires) more (options/visible features).
How to accommodate for everybody's needs?
Context
You are designing an existing or a new user interface for Moodle. You have found out the goals of the user groups with differing needs.
Forces: factors that affect selection
- Unexperienced users need to first learn the fundamental functionality of an application to be capable of diving in features needed in special situations.
- Unexperienced users may want to play with options to learn them, but may get confused if the application does something unexpected and if they do not know how to go back to the original ("safe") state of the application.
- Users who need some specific additional features do not want to see the other special features required by someone else - since they do not need it, it is distracting.
- Users who need the hidden features may be distracted if finding functionality they need is hidden and requires extra effort to access.
- Some functionality that is rarely needed on some Moodle sites may be always-required basic functionality on other sites.
Solution
- Progressive disclosure defers advanced or rarely used features to a secondary screen (or to a section hidden by default), making applications easier to learn and less error-prone. (Jakob Nielsen; edited)
- In its purest format, progressive disclosure is about offering a good teaser. (Wikipedia)
After studying the users' needs, you will know what options or controls are unnecessary to the most common uses of the application. Decide reasonable default values that are assumed when the user does not see these options.
- Hide the unnecessary options or controls from the UI that shows by default when a user comes to the UI for the first time.
- Provide one or more icons or links that can be used to reveal the hidden options. (A button should only be used if there is a special reason to do so.) The icon/link should indicate its use and the fact that the options in question are optional.
Each icon/link should only have options related to a specific user goal; if there are many different goals, create separate icons/links to show just one set of options (related to one user goal) at a time.
The trick is to let the less-experienced users know what they can safely ignore. They may be curious and take a peek, but they do so it in the safety of knowing they can still go back and ignore it if what they see is confusing. Also users of the initially hidden features benefit since they can skip those extra features they do not need.
Reasonable defaults
- Any options that are hidden with progressive disclosure should have reasonable defaults so that the application does the Right Thing even if the user does not understand the option in question.
- If users change values of options, they may not understand all the implications. Always indicating the default value next to or in the form element allows them to revert to the safe defaults (summer 2009 recommendation).
Persistence
Unless you have a specific reason not to, make the state of the progressive disclosure persistent across page views for any given user. In other words, when a userselects to see the additional functionality, it will be already open when the user accesses the screen the next time. (Until they hide it again.)
This way, more experienced users don't constantly have to hunt down options they need frequently.
The persistence is specific to the element in question. Showing one element does not mean opening any other elements hidden with progressive disclosure.
Predictability
Make sure the users who need the advanced functionality find it. Make it easy for the user to discern the elements that appeared when they pushed the Advanced button (or equivalent). The element that the user needs to click to see it needs to be clearly and unambiguously labeled.
It should be obvious which options were added when the element to show the hidden parts was clicked. In Moodle forms, the items that appeared should be signaled with the [decision not made: see MDL-20011] sign to differentiate them from the items that were visible by default.
Configurability
For some options it may be possible that on some sites a given option can not have a reasonable default but should always be selected by users. Consider making it possible to disable progressive disclosure in the site configuration for such options.
Common mistakes
There are no such things in reality as a novice, an intermediate or an advanced user. Different personas have various dimensions of know-how in terms of computer literacy. You have to know what the goals of the greater part of all users, as well as the goals of the users who need more options. Otherwise, you will get the split, of which options should be hidden from novice users, wrong.
A common mistake is making users choose what their skill level is, and based on that show more or fewer controls. Progressive disclosure should be based on scenarios that different actual personas (prototypical users) will be in, and the selection of features to hide is based on knowing their goals.
Examples and implementation
Simple progressive disclosure in a form
From: Quiz "Update this Quiz" screen
- Reasonable defaults: The options are designed so that ignoring them is safe. (Verify!)
- Persistence: Moodle remembers the state the form was left in from page load to another.
- Predictability: The label of the fieldset ("Question behaviour"), within which the 'Show advanced' button is, gives a rough clue about what is hidden behind the button.
Further examples and code samples: Progressive Disclosure Implementation (change the name of this page to "Progressive Disclosure Examples and Code Samples?)
Related issues in the tracker
- CREATE: Visible Defaults: The default values of the options should be visible.
- Related: MDL-19659
- MDL-20011 To provide other differentiation from the red required field asterisk * than colour, change the advanced item sign to ⚙ and include it in the button. Is this utf8 character available in all fonts possibly used with Moodle?
- it would be great to have something semantically linked to hoping to go for something would be more memorable as to avoid users double checking which one meant required and which one meant advanced - luckily asterisk is pretty strongly used as 'required' but it would help if the 'advanced' would be far from it. relatively anonymous ones: †‡•‣⇨ ♯☛ place of interest ⌘ gear: ⚙ (too strong? denotes advanced in os X so in addition to being descriptive it is known from elsewhere) lozenge: ◊ In modal logic, the lozenge expresses the possibility of the following expression. For example, the expression ◊P expresses that it is possible that P is true. (Probably this is not commonly understood though)
- To be decided: Moodle currently uses various forms of progressive disclosure. Some of these could probably be removed for consistency.
- MDL-20010 Progressive disclosure in Override permissions does not indicate what is advanced
Further information / Sources
- HTML 5 details element can be used to implement a certain type of progressive disclosure as browsers mature (in summer 2009 there was no support yet)
- Jakob Nielsen's Alertbox: Progressive Disclosure
- Wikipedia: Progressive disclosure
- Related: UI Patterns and Techniques: Progressive Disclosure (Nielsen calls this Staged Disclosure instead)
- Msdn: Progressive disclosure controls
(TODO: search progressive disclosure for examples and add some here)
