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: @@
-'''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]]
+{{Template:WillNotMigrate}}
-{{Work in progress}}
+[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Progressive Disclosure'''
-I am especially interested in comments about the readability, accessibility and brevity of the document. ([[Usability/Improve_Moodle_User_Experience_Consistency|UI consistency guidelines project]])
-== What? ==
+== Problem ==
+'''You have lots of features, some of which are only needed by a part of your user base and (seriously) distract the rest.'''
-'''Progressive disclosure''' is a technique used in user-interface design to alleviate clutter that often misleads users, especially inexperienced ones.
+: 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).
-== When to use? ==
+How to accommodate for everybody's needs?
-When you know most users will want to take a simple route and just get a job done, but '''some users will want to do something more advanced'''.
+== 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.
-What you need first: [[Know your users|know the users]] of the app/module in question, and their goals.
+== 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.
-== How to do it? ==
+== Solution ==
-Take advanced controls out of the way of the users who do not need them. Place them on an '''alternate, less prominent route''' that users with more experience can take to learn about advanced features.
+[[Image:progressivedisclosure.png|thumb|Image 1: Progressive disclosure in a form]]
-One typical way to do this is to have an "advanced" button, which leads to further configuration options. They should all have [[Reasonable defaults|reasonable defaults]] so that the application does the Right Thing even if the user does not.
+: 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]])
-=== In depth ===
+: 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. If there are further controls or alternative workflows that are really needed by some of the key users sometimes, but would distract the most common, basic workflow (especially when used by the users who are just learning the basic workflow) create an alternate route.
+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.
-== Why 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.
-Progressive disclosure the benefit of letting the '''less-experienced users know what they can safely ignore''': when a button is labeled "advanced", they will know that the program is designed to work just fine without seeing what is behind that button.
+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''.
-(They may be curious and take a peek, but they still so it in the safety of knowing they still don't have to do anything more.)
+=== 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.
+*  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 ===
+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 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.
+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.
-Please see [[Development_talk:Progressive_Disclosure#Couple_issues|the talk page]] for further caveats. To use progressive disclosure, you need to know the circumstances of different personas: since it typically hides features, it needs to be made sure progressive disclosure does not unreasonably slow down experienced users.
+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 ==
+== Examples and implementation ==
-=== Simple progressive disclosure in a form ===
+[[Image:progressivedisclosure.png|thumb|Image 1: Progressive disclosure in a form]]
+=== ''Simple'' progressive disclosure in a form ===
+From: Quiz "Update this Quiz" screen
-This will store the information in a session, about in which state the form was left, so if you press the 'Show advanced' button once, you will see the advanced controls shown anytime you come back to the form.
+* '''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.
-''META: can someone explain why these images explode out of the page on my 1024x768 laptop? isn't mediawiki supposed to resize to fit the page by default?''
+'''Further examples and code samples: [[Progressive Disclosure Implementation]]''' (change the name of this page to "Progressive Disclosure Examples and Code Samples?)
-[[Image:progressivedisclosure1.png|frame|the form before pressing the "show advanced" button]]
+== Related issues in the tracker ==
-[[Image:progressivedisclosure2.png|frame|the form after pressing the "show advanced" button]]
+* CREATE: Visible Defaults: The default values of the options should be visible.
+** Related: MDL-19659
-For information about how to implement this, see [[Progressive Disclosure Implementation]]
+* 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