Talk:Progressive Disclosure

Jump to: navigation, search

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

Couple issues

Three 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)

Data about user use

Having just skimmed Pattern Language for Pattern Language, I am specifically thinking about the Lesson Module page in MoodleDocs, currently #7 on the long page list. How do we know what people use and what they don't. How do we gather data and quantify it? My language in this is limited, so I will just ask questions.

What is the frequency of use for any specific activity, resource or block on Moodle sites? Categories of Moodle sites would be nice (K-8, 9-12, 13+, training, other). For example for each site, a matrix of activities, number of courses using it, number of teachers that use it and the overall count of each activities use would be interesting.

For example the Lesson Forum can not tell me but the SQL database can:

  • Lesson module -how many sites use it, what is the average number of lessons per course, how many teachers per site use it? How does it relate to other activities on the site in terms of use?
    • Dependency settings, how many lessons use them in a site? How many teachers and how many courses?
    • Slide show settings, ditto
    • Branch pages and Question pages, what is the ratio and average number per lesson
    • Clusters, ditto
    • Imports, I don't think there is SQL data on this.

Do we have a SQL query that someone voluntarily can run on their site which will give us these stats without violating confidential info?

Just a different kind of thought about useability. --chris collman 12:45, 29 June 2009 (UTC)

Using statistical data to aid making design decisions is indeed an important opportunity that would need to be grasped more efficiently. A problem indeed is privacy: how to get admins to give us that data. If they can trust that they are not giving anything sensitive away and do not have to do extra work to generate data and send it to us, this might indeed be possible.
"The Importance of Analytics in User Experience - The next big innovation in analytics isn’t going to be about the technology. It’s going to be about the UI. Smart reporting tools that answer questions and directly aid decision making – that’s what the world needs. In the meantime, UX specialists have got to get a whole lot better at analytics. Why not get started by reading this presentation by Louis Rosenfeld?"
See also: --Olli Savolainen 11:02, 30 June 2009 (UTC)
This is old stuff in the marketing department :) Realize some sites will not want to reveal any information, even how many students or teachers they have. In the US we have things like FERPA regulations. I was thinking that doing it from the SQL side would allow things like index numbers instead of names or even ids for privacy sake. For additional security, it could produce transparent data/report(s) that could be reviewed, then sent by the site administrator. These could be in a spreadsheet or CSV files. This optional report feature could be put in the Experimental part of Site Administration. Figuring out which data to collect and correlate is not going to be easy. I am sure team taught courses and meta courses add delightful wrinkles to what seems like simple questions.
Data is data. "A few" or "a lot" is meaningless without context. As an aside, I sort of wonder how much development in an open source community is driven by the squeaky wheel and special interests with resources. In private enterprise it is more about sales, that offers a slightly different spin on special interests and squeaky wheels :) --chris collman 12:54, 30 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 (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)

Forms inconsistencies

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)

Anthony's two cents

I found the Predictability section difficult to understand. I wonder how we might provide guidelines for form creation. It sounds like you are proposing that each form element should have an option for a default value and a method for indicating whether it is advanced or not. I believe you are documenting functionality that is currently available for developers and working it into a recommended procedure for future code. I wonder if we might want to start thinking about the next step which would be to allow site admins the ability to set default values and whether an option is advanced or not. Going further, being able to provide this level of control for a particular context could be interesting. For example, someone in the Math department of a school may find that a particular set of options are always needed; however, the English department does not need them. The challenge here will be that if we make Moodle so customizable it may be impossible to write any books. Even with this ability to customize, it would not change much for developers since they would have to establish the initial settings. One concern with such a finely controllable approach of course is performance as it introduces another level of complexity along the order of roles and capabilities. Peace - Anthony