Difference between revisions of "Talk:Progressive Disclosure"

Jump to: navigation, search
(Site policy)
(Examples)
Line 47: Line 47:
 
* mform will automatically create the interface based on these settings plus user preferences for "stickiness"
 
* 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.
+
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.
  
 
-- [[User:Martin Dougiamas|Martin Dougiamas]] 08:46, 3 June 2009 (UTC)
 
-- [[User:Martin Dougiamas|Martin Dougiamas]] 08:46, 3 June 2009 (UTC)
  
 
: Thanks Martin. Actually, to keep the work maintainable, linking to examples of existing implementations should probably be the highest priority. Taking screenshots is pretty easy too (though it could be [http://moodle.org/mod/forum/discuss.php?d=124977#p547610 a lot easier], and then eventually implementation pages (example: [[Progressive_Disclosure_Implementation|progressive disclosure implementation]]) could be filled in with explanation or links to pages where implementing the elements is explained.--[[User:Olli Savolainen|Olli Savolainen]] 12:01, 4 June 2009 (UTC)
 
: Thanks Martin. Actually, to keep the work maintainable, linking to examples of existing implementations should probably be the highest priority. Taking screenshots is pretty easy too (though it could be [http://moodle.org/mod/forum/discuss.php?d=124977#p547610 a lot easier], and then eventually implementation pages (example: [[Progressive_Disclosure_Implementation|progressive disclosure implementation]]) could be filled in with explanation or links to pages where implementing the elements is explained.--[[User:Olli Savolainen|Olli Savolainen]] 12:01, 4 June 2009 (UTC)
 +
 +
:: I've started collecting some [[User:Frank_Ralf/Moodle_forms1| examples of inconsistencies of Moodle forms ]] and took a first [[User:Frank_Ralf/Semantic_HTML5| peek under the hood of ''formslib'']] though this is very much still a work in progress. --[[User:Frank Ralf|Frank Ralf]] 11:32, 25 June 2009 (UTC)
  
 
===MoodleDoc example===
 
===MoodleDoc example===

Revision as of 11:32, 25 June 2009

Please add your comments for the page about Progressive disclosure here. --Olli Savolainen 11:32, 2 June 2009 (UTC)

Couple issues

Two problems with this:

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.

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)
Just a reminder for Collapsible fieldsets for uncluttering editing pages --Frank Ralf 11:25, 25 June 2009 (UTC)

Examples

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 (and other activity modules), 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 re-specify what is advanced if they want to, and also allows the admin to change the default values for the fields
  • 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.

-- Martin Dougiamas 08:46, 3 June 2009 (UTC)

Thanks Martin. Actually, to keep the work maintainable, linking to examples of existing implementations should probably be the highest priority. Taking screenshots is pretty easy too (though it could be a lot easier, and then eventually implementation pages (example: progressive disclosure implementation) could be filled in with explanation or links to pages where implementing the elements is explained.--Olli Savolainen 12:01, 4 June 2009 (UTC)
I've started collecting some examples of inconsistencies of Moodle forms and took a first peek under the hood of formslib though this is very much still a work in progress. --Frank Ralf 11:32, 25 June 2009 (UTC)

MoodleDoc example

An example (not a good one but). A MoodleRooms student made a comment about the MoodleDocs Backup page that seemed to be about terminology. First, I realized the intro made some huge assumptions about the user and context. Secondly, I thought the step by step section formatting was confusing. And of course I could not resist tweaking the language which did not seem to always follow demo.moodle. I am still not happy with the overall look of the page (I am sure either I or someone else will do something about it) but I think it is an improvement on usability.

In the step by step, I tried to indent various options. My thinking was the options are similar to "advanced" or "special" or "non-default" settings. Visually, I wanted the KISS steps to be clear for those who just want to click, click, click and do a manual backup. If they want to learn more, then their eyes can wander to the indents. Also there was no word reference to 3 screenshots in the step by step. These are common edits, which once made are generally tweaked but not reformatted by the community of editors.

In MoodleDocs, I think of this like having an advanced button on a form. Sometimes bullets or the ":" features are used the same way. A very common example is the use of :''Tip:'' at the end of a section or below a paragraph of how to.

Finally, I am undecided about where the images go on this page. Should the step by step be broken down into 3 stub headings for each screen, with a mini picture in each one? Should we have quick step by steps section, then more detailed step by step section. Do the pictures work lined up on the right as they are. On a page with a template, lining up images on the right does not always work. Is variety OK ?

Olli there is one example and like most things a work in progress (WIP).--chris collman 13:58, 4 June 2009 (UTC)

Search and Advanced search of forums

Hi Olli,

I think what's really missing from the search forms is the possibility to limit one's search either to only the discussion or the subject (one of which should IMO be the default behavior for the search field anyway).

See MDLSITE-664 and MDLSITE-644 for further aspects of this topic. --Frank Ralf 11:21, 25 June 2009 (UTC)