Progressive Disclosure: Difference between revisions

Latest revision as of 14:38, 27 May 2022

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

Image 1: Progressive disclosure in a form

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

Image 1: Progressive disclosure in a form

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)

@@ Line 1: / Line 1: @@
-{{Work in progress|info=<br /><br />'''This is a prototype guideline, a starting point for the [[Usability/Improve_Moodle_User_Experience_Consistency]] project. ''' I am especially interested in comments about the readability, accessibility and brevity of the document.}}
+{{Template:WillNotMigrate}}
-Progressive disclosure '''defers advanced or rarely used features to a secondary screen''', making applications easier to learn and less error-prone. -[[Progressive_Disclosure#Further_information_.2F_Sources|Jakob Nielsen]]
+[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Progressive Disclosure'''
-== Context ==
+== Problem ==
-[[Image:progressivedisclosure1.png|thumb|Image 1.1: A part of a form before pressing the "show advanced" button]]
+'''You have lots of features, some of which are only needed by a part of your user base and (seriously) distract the rest.'''
-[[Image:progressivedisclosure2.png|thumb|Image 1.2: A part of a form after pressing the "show advanced" button]]
+: 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).
-Use Progressive Disclosure when you know some users will just want to get the job done with no fuss, but '''some others users want to do something more'''.
+How to accommodate for everybody's needs?
-Maybe what your grandpa does just isn't enough, mechanically clicking through the same buttons - the meaning of which he does not know - every time he goes to his online history course. After all, otherwise the pesky computer might break.
+== 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.
-Often you have to allow taking the simplest route: computer programs that try to forcibly educate users about their intricacies are never successful. '''Different key users of your application have different goals, and you have to serve all of them. '''
+== 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.
-(move the two latter paragraphs to a section higher in the hierarchy? the title of it might be as"Making things simple, but not ''too simple''"?)
+== Solution ==
-== Forces: factors for selection of this guideline for use ==
+[[Image:progressivedisclosure.png|thumb|Image 1: Progressive disclosure in a form]]
-(this is only supposed to contain the needs and the challenges BEFORE applying the pattern. move what follows to a "resulting context" section or equivalent, or where?)
-* Progressive disclosure allows novice users to first learn the fundamental functionality of an application''', and then move on to more advanced features if/when they need them.
+: Progressive disclosure '''defers advanced or rarely used features to a secondary screen''' <nowiki>(or to a section hidden by default)</nowiki>, making applications easier to learn and less error-prone. (Jakob Nielsen; [[Progressive_Disclosure#Further_information_.2F_Sources|edited]])
-* Helps meet expectations of differently skilled users with the same UI. We let the '''less-experienced users know what they can safely ignore''':  (They may be curious and take a peek, but they still so it in the safety of knowing they can still go back and ignore if what they see is confusing.)
-----
+: In its purest format, progressive disclosure is about offering a good teaser.  (Wikipedia)
-* To successfully apply progressive disclosure, you '''have to know what is the goal 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.
+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.
-* May distract those users who need the features hidden behind another click. See [[Progressive_Disclosure#Persistence|Persistence]] and [[Progressive_Disclosure#Predictability|Predictability]] below for ways to alleviate this.
-* Whether progressive disclosure should be applied to an option can vary from a Moodle site to another. If [https://docs.moodle.org/en/Development:Progressive_Disclosure#Persistence Persistence] and [https://docs.moodle.org/en/Development:Progressive_Disclosure#Predictability Predictability] aren't enough, make the options [[Progressive_Disclosure#Configurability|configurable]].
+# Hide the unnecessary options or controls from the UI that shows by default when a user comes to the UI for the first time.
-[http://www.example.com link title]
+# 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.
-== How to do it? ==
+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.
-''In its purest format, progressive disclosure is about offering a good teaser. '' (Wikipedia)
-Identify the key workflow: what users actually do most of the time. Identify other further controls or alternative workflows that are required but less common. Place them on an '''alternate, less prominent route''' that users with more experience can take to learn about further features.
+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|reasonable defaults]] so that the application does the Right Thing even if the user does not understand the option in question.
-* It should also be clear to the user how to return the application to the "default" state in case the user plays with the UI without understanding the options. '''The value that is the default of an option should be visible at all times''', or at least in the case the option is not in the default state.
+*  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 ([[Progressive_Disclosure#Related_issues_in_the_tracker|summer 2009 recommendation]]).
 === Persistence ===
-Depending on the context, often it is beneficial to make the state of the progressive disclosure persistent for any given user: Once the user has once expressed that they are willing to see the additional functionality, it will be visible by default when the user accesses the screen the next time. (Until they hide it again.)
+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.)
-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.
+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 ===
-To make sure the users who need the advanced functionality find it, the element that the user needs to click to see it needs to be clearly and unambiguously labeled.
+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 predictable to users what will happen if they select to see further options:
+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.
-* If there is a link for "advanced [noun]", such as "advanced search", the link can take to another, completely different page.
-* If there is a link to show something additional in the UI the advanced options should either appear near the button or the items that appeared should be signaled with an asterisk (*) to differentiate them from the items that were visible by default.
 === Configurability ===
-If it is possible that on some sites a given option can not have a reasonable default but should always be selected by users, consider making it configurable per-site to disable progressive disclosure for that option.
+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 user, intermediate user or an advanced user. Different personas have various dimensions of know-how in terms of computer literacy. 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 have.
+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 ==
+[[Image:progressivedisclosure.png|thumb|Image 1: Progressive disclosure in a form]]
 === ''Simple'' progressive disclosure in a form ===
-(See images 1.1 and 1.2 above)
+From: Quiz "Update this Quiz" screen
-* '''Reasonable defaults:''' The options are designed so that ignoring them is safe. However, the default value of the option is not visible to the user so that they can return the option to its original safe state.
-* '''Persistence:''' Moodle remembers the state the form was left in. If the user left the form and had the progressive disclosure in 'Show advanced' state, the advanced controls will be visible when they return to the form.
+* '''Reasonable defaults:''' The options are designed so that ignoring them is safe. (Verify!)
-* '''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. Still, the user has to learn where a given feature is since there is no information readily visible about the specific features hidden.
+* '''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.
-'''Implementation: [[Progressive Disclosure Implementation]]'''
+'''Further examples and code samples: [[Progressive Disclosure Implementation]]''' (change the name of this page to "Progressive Disclosure Examples and Code Samples?)
-=== Search and Advanced search of forums ===
+== Related issues in the tracker ==
-Change to another page with further options if the user clicks "advanced search".
-* Simple search: the "search forum" form http://moodle.org/mod/forum/view.php?id=737
-** Simple search results (with link to advanced search): http://moodle.org/mod/forum/search.php?search=sweet&id=5
-*** Advanced search form:http://moodle.org/mod/forum/search.php?id=5&user=&userid=0&forumid=0&subject=&phrase=&words=&fullwords=&notwords=&dateto=0&datefrom=0&showform=1
-**** (Advanced search results: http://moodle.org/mod/forum/search.php?id=5&words=not&phrase=any&notwords=&fullwords=&hfromday=1&hfrommonth=1&hfromyear=1&hfromhour=1&hfromminute=1&htoday=1&htomonth=1&htoyear=1&htohour=1&htominute=1&forumid=0&subject=&user=)
-=== Search options ===
+* CREATE: Visible Defaults: The default values of the options should be visible.
-Javascript implementation. When "Search options" is clicked, reveals three checkboxes. Go to a module, such as a forum, in a course, click Update module, click Check permissions. URL of form is /admin/roles/check.php?contextid=X .
+** Related: MDL-19659
+* MDL-20011 To provide other differentiation from the red required field asterisk * than colour, change the advanced item sign to <big>⚙</big> and include it in the button. Is this utf8 character available in all fonts possibly used with Moodle?
+**  <small>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)</small>
+* 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 [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element 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: [http://www.useit.com/alertbox/progressive-disclosure.html Progressive Disclosure]
 * Wikipedia: [http://en.wikipedia.org/wiki/Progressive_disclosure Progressive disclosure]
 * Related: [http://www.time-tripper.com/uipatterns/Progressive_Disclosure UI Patterns and Techniques: Progressive Disclosure] (Nielsen calls this Staged Disclosure instead)
+* Msdn: [http://msdn.microsoft.com/en-us/library/aa511487.aspx Progressive disclosure controls]
+(TODO: search [http://moodle.org/public/search/?cx=017878793330196534763%3A-0qxztjngoy&cof=FORID%3A9&ie=UTF-8&q=progressive+disclosure&sa=Search+moodle.org#919 progressive disclosure] for examples and add some here)
-(TODO: search [http://moodle.org/public/search/?cx=017878793330196534763%3A-0qxztjngoy&cof=FORID%3A9&ie=UTF-8&q=progressive+disclosure&sa=Search+moodle.org#919 progressive disclosure] for examples and add some here)
+[[Category:Moodle User Interface Guidelines]]

Documentation