## General developer forum

### Usability Changes to Forms and Module Selection for Review (demo included)

Usability Changes to Forms and Module Selection for Review (demo included)

Hi All,

At LUNS, we've recently been working on some features which we hope should enhance general usability of Moodle 2.x.

These features are nearing production readiness and we'd like to share them with the community with the hope of targeting inclusion into Moodle Core. You can try them out at http://moodledev.luns.net.uk/a. The code is available from our git repository on the MDL-uidemo-master-1 branch.

Both of these features require Javascript to be enabled, and are written in YUI3. They take the Progressive Enhancement approach so make no changes to Moodle if Javascript is disabled.

The first of these features is a Module Chooser. It acts rather like the questionbank question type selector and gives the help text for each module, plus it's icon. With this module we wanted to reduce the confusion caused by the 'Is it a resource or an activity?' issue that we've seen amongst our users. We also wanted to present the icons and give additional information about what that module does to help users to identify each module more quickly and without having to change page and use the help icon to check that they have the correct module.

The second of these features was aimed at simplifying moodle forms by hiding optional/unimportant settings to make the forms less scary. We've received a lot of feedback from our users simply saying that the forms are too long and there are too many options. We also found that many of them don't use the 'Show/Hide Advanced' button - I suspect that this is because they don't consider themselves 'Advanced' users, so don't think that the options are relevant to them. As a result, we've seen queries coming in from users unable to get a module to behave as they'd like, because they haven't clicked on 'Show Advanced'.

This enhancement works by:

• always displaying the 'General' section and closing all others by default;
• always displaying a section with a required element;
• opening any section which contains validation errors;
• opening any section which was previously open on previous submit (e.g. when adding new choices);
• displaying elements which are coded as expanded by default (e.g. $mform->setExpanded('foo');); and • removing the 'Show Advanced' button (using JS) - this is something we're trying to explore at present. There are still a couple of minor issues that we're aware of and working to address: • repeated elements are not shown by default because none of them are required until they're submitted - we've fixed it for the 'choice' module, and we're working on extending it to all affected modules; • the modchooser currently doesn't work on the frontpage. Any feedback would be gratefully appreciated. Thank you in advance, Andrew Nicols and Ruslan Kabalin LUNS Limited Average of ratings:Useful (6) Re: Usability Changes to Forms and Module Selection for Review (demo included) By the way, we're posting this in the General Developer forum rather than the Usability forum because of the changes to formslib which we want feedback on and developer input. Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) Hi Andrew, we also found that users were often unable to complete basic tasks in moodle because "the forms are too long and there are too many options." "simplifying moodle forms by hiding optional/unimportant settings to make the forms less scary." is something we have been working on as well, and i think its something moodle hq would class as 'low handing fruit'. "many of them don't use the 'Show/Hide Advanced' button" - we found exactly the same, but for different reasons which render it just as ineffectual a paradim. We have a UX paper on moodle forms, currently in review with some other moodlers, which i'll pm you a copy of - be interested to hear your thoughts, and glad to know others are working in this area. Cheers Stuart Lamour Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) This sounds an excellent idea. Moodle forms can indeed be very long scary and complicated. Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) Hi Marcus, Have you looked at the demo site: https://moodledev.luns.net.uk/a/ What do you think about what has been done there? There has been a lot of talk on this matter, we decided to create some action, and see what people think of the result. thanks Dan Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) Can you send me a copy too please? (email address in my profile.) Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) Hi Stuart, I'd be interested to know what you think of our solution to this issue then - have you taken a look at our demo? Andrew Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) Stuart, I'd also be interested in a copy of the UX paper. Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) Me too. tia Frank Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) I just looked at this. My opinion: 1) Module add dialog Yes, this is a really big improvement, can we have it in core please. With some possible concerns (apart from the greengrocer's apostrophe in the default help): does it cope with smaller screen sizes, is it at least keyboard accessible? I note that if you don't have JavaScript it falls back is to the old interface, so that's good. 2) Folded sections in forms This is neat but I'm uncertain it is really compatible with all forms - there might be forms where something in section 2 is vital, for instance, and/or there are only 2 short sections anyway; so it would need a way for authors to indicate that something should be expanded by default - and I'm not quite sure it is the best way to solve the 'module settings are bloody awful' problem. I.e. I think it might be better to use different forms for certain things that are currently part of the main module settings, rather than put it all in one form, similar to the way Permissions page works. --sam Average of ratings: - Re: Usability Changes to Forms and Module Selection for Review (demo included) 2) Folded sections in forms This is neat but I'm uncertain it is really compatible with all forms - there might be forms where something in section 2 is vital, for instance, and/or there are only 2 short sections anyway; so it would need a way for authors to indicate that something should be expanded by default As mentioned in the initial post this is accommodated with this prototype with:$mform->setExpanded('foo');

and I'm not quite sure it is the best way to solve the 'module settings are bloody awful' problem. I.e. I think it might be better to use different forms for certain things that are currently part of the main module settings, rather than put it all in one form, similar to the way Permissions page works.

Agreed this is somewhat of a stop-gap, but it might be one which could be applied without breaking/rewriting the world.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)
Just my 2 cents from a Drupal perspective. Drupal uses mainly three ways to reduce clutter on forms (which technically are all derived from fieldsets):

1) collapsible fieldsets
2) tabs
3) vertical tabs

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Sorry for not reading the initial post properly. But at least I did try the demo unlike some others!

If implemented in core, I think it would be appropriate to make the default be 'expanded'. This way all existing stuff including third-party whatever keeps working as before, and it's not like it is a big deal to add a bunch of ->setCollapsed(true) to the module form and course form (which are the only places it's really needed, right?)

Re breaking the world - true, but the module settings form doesn't really seem too big of a 'world' to rewrite. Then again, maybe combining this approach with some minor reorganisation of the standard options (to put things in a more sensible order with better headings, e.g. integrate the availability options with standard 'Visibility show/hide' into one section) would be a sufficient improvement.

Non sequitur: I'd like to get rid of 'group members only' checkbox - not the way Petr wants to get rid of it where the feature is removed, but so that there is no checkbox/option, none of this advanced feature malarkey, but it's just always on if you specify a grouping or separate groups.

--sam

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

> If implemented in core, I think it would be appropriate to make the default be 'expanded'.

Sam, the whole point of making forms simplier is to make them shorter, that is why the suggested default state is 'collapsed' (these sections that contain something important will be expanded anyway). Forms are already expanded now and the suggested feature then makes little sense in that case. What we can do in fact, is add a user preference setting to control if the forms will be 'all expanded'.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Perhaps I wasn't clear? My opinion is that the default setting, if not specified in the code, should be 'expanded'. I think you've read that as meaning that the default setting for every user should be 'expanded', which would obviously be pointless, and is not at all what I meant!

For existing forms in core code (module settings, course settings) which we know benefit from this change, as part of this change the code to set each section to default to 'collapsed' should be added. Obviously this would be about a 10 minute task, one line of code per section.

That way, let's say for example if we have 100 custom plugins. Some of these contain forms and some of those forms have more than one section. In nearly all cases those forms are short and it would be silly to hide the second section. There might be a few where we'd want to but I would much rather have people requesting 'wouldn't it be nice to add that cool new collapse feature to the form x in plugin a' than people all jumping up and down on release day 'omg the forms y, z, q, r, and w in plugins b through f are all defaulting to collapsed since this morning so i have to expand them every time, it's really annoying, why did you do that you unfeeling b******!!!!'

I think it would be better if plugin developers assess their existing forms to see whether they benefit from this new change and, if so, add it (in the code) with a very easy change.

This retains the key benefit - for all users, course and module settings, plus any other forms in core that have been identified as sucking, start to suck less - while not causing any unexpected changes to any area of behaviour.

I don't think there is probably a need for a user preference, but I might be wrong!

--sam

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Hi Sam, thanks for reply. I see what you mean - you suggest to make them expanded in the code by default and collpase only those to which setCollapsed setting was applied. So, rather than rely on the 'best guess' what to collapse, it will be done manually by developer.

Hmm, not sure if this is good approach as this will require extra work from developer and using it for every form in the future, some third-party developers may miss this feature and their forms will always be expanded which will make forms througout the moodle a sort of incosistent. Controlling expansion using 'required' elements sounds more logical to me.

Would be intersting to know what others think?

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Another way to do it would be to change the function used, so if (from memory) it is currently add_heading, make a new function add_heading_folded, that way it is no more effort to do this for all new code (and changing existing code requires only extra 7 characters, not even an extra line, and you can do it with search/replace across a whole plugin/set of plugins).

Really just thinking it's better to do something which fixes the only severe problems in this area (course form, mod settings form) and leaves other forms unchanged with the potential for improvement, than to change all forms on the system including ones in custom code where nobody has considered whether it is an improvement or makes it worse. Nicer on upgrade day if you can be sure there are no nasty surprises for custom code. (As nasty surprises go, this is a lot less nasty than many moodle API changes since affected forms will still work, just with requiring an extra click! But still, seems easily avoidable.)

I'm not that bothered about this by the way, maybe others disagree with me, and it wouldn't be a disaster if it was enabled by default for everything (as long as we do at least have a way to turn it off in code for specific headings that should be expanded initially).

--sam

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

add_heading_folded seems like a terrible API to me. Having a whole new method name for one specific feature is yucky.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Well, it only does one thing at the moment, now it does two, having two functions doesn't seem unreasonable

But yes, maybe adding a parameter to the end of add_heading is a better idea, although this has fewer conversion benefits (and I bet there are some useless params on it already).

--sam

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)
It would be interesting to see if this really breaks forms with the current rules in place (opening if a required param contained etc).

We saw a few of these when developing the conecpt, but with each rule adding we seemd to make to make it work sensibly. If it looks like it'll work ok in the majority of cases then I don't see the advantage of doing it your way round.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Even if it's a minority of cases that break I still think it's better not to make unnecessary API changes (unless we're sure it's a really tiny minority).

I just have the impression that the majority of our forms are small. Of course, if one of your rules is about the number of items in the form in total, then maybe that would be covered...!

--sam

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Hi Sam,

Thanks for the feedback. I'd really love to get this into core. I'll try and sort out the incorrect apostrophe and update the branch.

The module chooser dialogue should be keyboard accessible:

• upon opening, the first element is focussed allowing selection of radio elements;
• as long as an element is selected, standard form listeners should apply (e.g. up/down/space/tab/return etc);
• clicking elsewhere on the chooser whilst it is open will always refocus to the currently selected element so as to maintain the keyboard accessibility; and
• whilst the chooser is open, the escape key is listened for to allow a user to cancel selection.

With regards to small screens, the module chooser uses the following rules:

• a default maximum height of 530px is imposed for the height of the module list;
• if the window height <= the default height then the current window height is used;
• if the window height <= 300px, then 300px is used instead.

We also always take off a little of that height for the header, footer, and a bit of spacing so that the interface doesn't feel too cluttered.

If there are more modules than the screen height allows, then a vertical scrollbar is added to the module list - the same goes for the help area.

Thanks,

Andrew

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Pleased as pie to see this kind of work being done to make Moodle easier for the user.  Keep forging ahead -- hope its in core soon.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

From a far more basic perspective and a user who hates Moodle, I think this would be a massive improvement! For users who are just starting out, I think this is a far more simplistic approach to selecting forms and modules. Are you planning on following Dan to Moodle HQ Andrew? ;) /Mytwocents

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Just a quick update,

I've opened a feature request on the tracker for the modchooser element of this - MDL-30615 and submitted the code for peer review.

I think that Ruslan will also be submitting a feature request for the compacted forms side of this usability work.

Andrew

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

As Andrew mentioned, I have also created a tracker issue for shortforms feature - MDL-30637

There are two subtasks that require some input.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

I have added a functionality of disabling shortforms feature for particular forms using:

\$mform->setDisableShrtforms();

Could be useful for the cases where shortforms are not approprate, e.g. when lesson activities are presented to student (reported by Mary Cooch). The public branch has been updated as well.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

I just wanted to add a pointer here that we (the OU) have some more specific proposed changes to the question editing forms: http://docs.moodle.org/dev/Question_editing_form_improvements / http://moodle.org/mod/forum/discuss.php?d=175290#p838699.

Please let us know what you think.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

I've only just noticed this today.  Low level comments follow.  I do like the first screen, the help on the right and the simplicity it brings to the screen.  I'd like no text, just the green plus.

Forum options don't seem to be working, they are th same as regular Moodle. I tried the fiel and label.

### 1. I like save buttons at the top as well. I'm not sure if this breaks a UI rule.

On my screen, the save and return button is often cut off or requires scrolling.  Could one be added at the top as well??

### 2. The initial choice:

Same for this. Have to scroll.  Why not add/cancel at the top aswel?

### 3.Is it confusing to have TWO or more sets of options that are hidden?  Why not just one?

I know why you do it.  But, from the user point of view, do they distinuish between these settings like this?

-Derek
Not much activity here in this dscussion.  Should you put a note in the Useability forum/Lounge saying there is this dialogue occurring here?
Should there be a forum "Requests for Feedback" currently underway, or a message to this effect?
What is the chance REALLY of seeing this in the core.  Is it worth our time to think more about this?
I have asked for the UX paper.
Good luck.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

2. Initial choice

Agree with this comment. Why change the interface to introduce the likelyhood of having to scroll?

Module help files: Not sure where to find this - is it a single description of the module. Are they up to date? Need to be broad in their application i.e. not suggest use of the module that is too focussed on a specific use case. So (off th etop of my head):

Not: Students submit their assignments for teachers to mark.

Better?: Facilitates the submission of files and online text. Options: Recording grades (simple and advanced), providing feedback, scheduled availability, offline activity, group submissions, blind marking

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)
Hi Ray,

As I commented to Derek, there shouldn't be many times when you have to scroll - it will depend on the amount of usable screen space available, and the number of modules you have installed and enabled.

The module help files are packaged in the language files for each module. As part of this work, I'm hoping that we'll also be able to get these created where they don't already exist and updated where they're out of date. They're meant to be a description of the module and explain what it does.

I'm confused by your third paragraph - what does this mean:
Not: Students submit their assignments for teachers to mark.

And also by your final paragraph.

Perhaps you could clarify what you mean?

Thanks,

Andrew

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

"it will depend on the amount of usable screen space available, and the number of modules you have installed and enabled."

Exactly, so assume at the very least that all standard modules will be enabled.

Regarding the other paragraphs, I was trying to convey that this help text needs to take account of the wide variety of contexts in which Moodle is used. So student/teacher centred descriptions that are drawn from the help files will be a major turn off for many users. The third para was a quick attempt at what I would consider to be a poor approach, the fourth a more generalist approach that would be more useful and appealing to a broad userbase. This is important,  so if that's still not clear feel free to say so.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)
Hi Ray,

That is to say that the it's been designed to show, at the very minimum, all standard moodle modules plus a few extra. Obviously, this is dependant on screen size.

The individual help texts are really up to the module maintainers to write. At present, quite a few of them are entirely missing, and the ones that are there differ in lenght, audience, etc vastly. I do agree that these need to be improved in such a way that they suit all audiences as best possible.

That said, for your specific installation you can easily change these strings using the Language Editor if you're not entirely happy with the descriptions for your users. Additionally, you could raise an issue in the tracker with your specific suggestions for improvements.

Andrew

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

In core Moodle these need to be non-specific to cater for the broad range of useage scenarios. If this usability change is to be in core then ensuring that the text displayed is appropriate needs to be part of this development.

The majority of sites won't change this, they'll just be turned off if the text that has no relationship to their potential use and that negates the efforts to improve their experience.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)
Hi Ray,

I don't disagree that they need to be changed, in fact I very much agree. I'm just saying that I don't know if I'm the best person to write the text - I'm a developer rather than a course designer so in my opinion it would be far better to hear from real users who have real use cases -- that's why I suggested opening new issues in the tracker.

Additionally, most of these texts really need to be added/replaced regardless of the module chooser I've written -- another reason that these belong as a new issue in the tracker rather than as a part of the module chooser work. They should probably be linked to one another but I don't believe that one should block the other.

Andrew

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Is there anything in the tracker on this atm that I can link to?

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)
Hi Derek,

Thanks for the feedback. Firstly I just wanted to point out that this is already posted in the Usability forum as well (http://moodle.org/mod/forum/discuss.php?d=191768). There have also been screencasts and I've tried to announce it in various places as I'd really like to get people's views.

I'll try and take each of your points in turn starting from the top.
I did originally consider having just the icon, but found that it looks a little confusing for users. It should be pretty trivial to move the text to a span element with a class so that you can use a local CSS file to remove it entirely. The institution we developed this for have actually completely re-themed it to suit the rest of their site. I've attached this so you can see what I mean.

I'm not sure what you mean about the forum options - could you clarify?

### 1. I like save buttons at the top as well. I'm not sure if this breaks a UI rule.

There's nothing to stop you adding these - if you think that this is worthwhile, have you considered raising these in a separate tracker issue? It's not part of the work that we've done so I can't really comment. Personally I do think that it reduces the natural feeling of the site - I'll explain more in the next point.

### 2. The initial choice

In terms of the usability of this screen, I personally think that it's superflous to duplicate the controls at the top of the screen. Most users don't require this and I think that it breaks the workflow. The rest of the interface is ordered - you read the title (and have the option of using the cancel button), you read down the list to choose the activity you desire, then you read (if you want) the associated help text on the right, then you choose the 'Next' button. You're naturally moving down, right, down, which is a natural flow that is common across many areas of life (e.g. books, advertising, etc).

By adding an additional set of button to the top, you're breaking this workflow. You wouldn't read a page of text, and then expect the last sentence to be on the top line for example.

I'm intrigued as to why you've having to scroll - when I wrote this interface, I tried to make sure that it would fit within a standard laptop screen as best it could. When you first open the chooser, it tries to fit all of your modules in the browser window without requiring any scrolling.
If your browser's viewport (window size) is smaller than the size required to display the chooser, it should add a scrollbar to the list of resources/activities but keep the buttons at the bottom visible. This can also happen if you have an inordinate number of modules to display.
At some point (I forget the exact size) it will eventually force you to scroll your browser window down to get to the buttons because without doing so you wouldn't have any space left to view the list of activities.

As you can see, this is something I gave careful consideration to and I would be interested to know what OS, browser, and window size you're working with so that I can try and replicate this and try and improve the experience for you (and others).

### 3.Is it confusing to have TWO or more sets of options that are hidden? Why not just one?

I think that most users do actually distinguish between these settings if the labels on them are accurate enough.

These sections are all defined by the relevant forms and they're not something we've made changes to - all we've done is to minimize them so that they're not visible unless you want to go changing them.

I think that this works best for most users as most of Moodle has sensible defaults.

I actually think that there's a good chance of seeing this in core. We actually undertook this work partially because Martin Dougiamas specifically requested this kind of interface in the last developer meeting. I'll be demonstrating these features (and a few other changes we've been working on) at the Developer Meeting at the end of the month too.

We're also actually using this in two production deployments of moodle already and we've had some very good feedback. Of the people we've spoken with, all have been very pleased with the changes that we've made and I don't think that we've had any negative comments.

Andrew

I notice on your screen that you have the browser Find bar open in Firefox which seems to be changing the usable area. I suspect that this may have something to do w

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

There are many ways in which moodle forms can be improved. Logically grouping and separating some of the items would be a first step. I have just blogged about how we improved one moodle form using user experience patterns such as progressive disclosure.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

great work, I'm keen to see this implemented in core. A couple of questions/comments:

• Will functionality be available at a form level to configure which forms display as accordions and which remain 'traditional'?
• For forms typically completed infrequently by users:
• Consider if an accordion is the best display - it hides content and contains default 'answers' which are initially invisible to users and easily overlooked.
• Headings could be misconstrued as hypertext links to other pages by inexperienced users. A matter of styling and I see the triangles do provide a cue as to the heading's behaviour.
• Infrequent users of a form might benefit from more descriptive, verb-based heading labels rather than the current short headings.

Thanks for putting this together

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

This came as a bit of a shock to our learning technologist.

We only just found this via the latest integration but I've got some feedback based on the 2.3dev implementation:

The main issue raised was that it doesn't actually improve substantially the usablity, and for users who know what they want to do it actually slows them down. It now takes 3 clicks (and potentially a drag of a scroll bar to move the list of items) versus the click(,scroll), click from the "old" drop downs. And this still only gets you to the page to fill out "new" activity details.

One improvement that we think might be worthwhile would be to display the actual "add" form (basically modedit) in the right hand pane (possibly with the help text at the top) so that it is 1 click to popup the browser, a scroll & click to select an item, and then you're at the "add" page. It's then just a single click to add (or cancel) the item.

I've attached an idea for comments

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Michael - just a minor point, but if you prefer the old drop-down menus, then there is an option in the settings block to get them back again.

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

A small bump for this.

Has anything moved on from here?

-Derek

Average of ratings: -
Re: Usability Changes to Forms and Module Selection for Review (demo included)

Derek - if you mean the "simple forms" then the tracker issue is here MDL-30637

Average of ratings: -