Improvment for user interface of repeated form elements

Improvment for user interface of repeated form elements

Oleg Sychev -
Number of replies: 10

repeat_elements function used now mainly by questions/quiz stuff (thought it can be more generally usable).

It's current interface for number of blanks handling based on using a button which reloads a form adding some number of blanks. Isn't very useful actually, especially if there are questions with 3 blanks and 30 (the last was actually seen on production site). Having 5 blanks and a button to add 3 of them it's quite unconvenient to get more than 12 blanks.

An alternative way is to get text field, in which user can enter a required number of blanks and get it in one page reload (furthemore, it can be saved in user preferences to use later). The hard thing is reducing the number of blanks - we can delete only empty blanks. This'll require some more work from the caller, as it's quite hard (if possible) to tell if an arbitrary blank is empty.

MDL-17064 holds a patch and discussion. If there will be agreement on the patch before February, I can upgrade all pages in the core that use this function too. I'll be quite busy later on.

Average of ratings: -
In reply to Oleg Sychev

Re: Improvment for user interface of repeated form elements

Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
If there is a general consensus that this is a good thing, then I will probably find time to merge it without waiting for February, because I think this gives a more usable interface.

One place where Oleg and I disagreed was that I thought a dropdown men would be better than a text box. What do other people think?
Average of ratings: -
In reply to Tim Hunt

Re: Improvment for user interface of repeated form elements

Oleg Sychev -

To state my opinion of dropdown: I just found nothing useful in it (coparing with text with PARAM_INT client-side validation), but it require more code to handle and it is more clumsy for the user when big lists of numbers is used (or if the list is small it's quite restraining - one example is number of attempts dropdown in quiz, 6 not always sufficient).

The dropdown may be useful if it can solve reducing blanks number problem, making impossible to delete filled blanks - sadly, it can't since user can get a page (dropdown numbers will be set), then fill some additional blanks - and we can't rise lower limit on dropdown (without some intricate javascript generation) on this occasion since no page reload occurs .

I'm still lacking any sort of specific argumentation, in what cases dropdown would be better than text with correct cleanup. My personal opinion is that dropdown is useful when you have 4-10 items in it, and quite unsuable if there are much more (2-3 items may be better handled by radio buttons, thought dropdown will do the job).

P.S. I'm quite surprised, that bug number woun't become a link on initial post. Maybe I write something wrong.

Average of ratings: -
In reply to Oleg Sychev

Bug number not linking

Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I was surprised too. I think there may be a bug in that text filter, where it does not work at the start of a line.
Average of ratings: -
In reply to Tim Hunt

Re: Bug number not linking

Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Fixed, filter wasn't filtering immediately after > Now, it is.

Ciao சிரி
Average of ratings: -
In reply to Eloy Lafuente (stronk7)

Re: Bug number not linking

Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Tim wrote a cool new regexp that seems to cover an even wider range of cases, I've installed it.

$text = preg_replace('#(?:MDL|MDLSITE|CONTRIB)-\d+\b(?![^\'"<>]*[\'"][^>]*>)(?![^<]*)#',
'$0',
$text);

All we need now is a reliable method using nolink tags that all the filters can use! eg MDL-15555
Average of ratings: -
In reply to Oleg Sychev

Re: Improvment for user interface of repeated form elements

sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers
So is the suggestion a box/button like this:

[ 3 ] [Add more options]

ie by default the button does the same it currently does but you can type a different value in a textbox to the side of it.

Issues:

1) You can customise the button text at the moment, I believe with a language string containing the number of options as $a. ('Add $a aardvarks.') So this would mean text changes to all of those.

2) Presumably we would keep the existing default values (which are specified in code each time).


It's kind of okay I guess but I'm not really sure about it... It basically still sucks, and now it's a little bit more complicated. Is it possible to do something AJAX with that button so that it always adds 1 option but doesn't require form reload? Or is that way too hard... வருத்தம்

One way to implement this in plain old javascript is to generate a standard 'maximum expected' number - say 10 - but hide most of them. Then have the button just un-hide one option at a time. If you run out, a reload might be required, but that reload could automatically add a really large number eg 50. Easy and effective (use existing PHP code with a fix to the initial/to-add numbers, add magic JS that hides the 'real' add button until it's needed and adds in a special JS one) - however, I can imagine this implementation running into trouble with heavyweight components like the text editor.

Btw this is the first time I read a complaint about the number being too low. Maybe there could be just a system option somewhere to force a minimum number, for those one or two sites that do weird things? Or is it common that people need to click that button multiple times?

--sam





Average of ratings: -
In reply to sam marshall

Re: Improvment for user interface of repeated form elements

Oleg Sychev -

The suggestion is to have something like:

Number of blanks [3] Apply

I'm against number for adding, as it makes user to count, how many he need to add considering the current number. I'll for direct adjusting the number of blanks.

Force a minimum number would be a perfect thing if we have a per-teacher installations. Having a university installation I have to deal with many teachers, some want 3 choices, other 30. No fixed number seems to satisfy everyone.

Average of ratings: -
In reply to Oleg Sychev

Re: Improvment for user interface of repeated form elements

Oleg Sychev -
Hmmm ... it's seems that issue become quite staled.

Could anyone from Moodle developers help me with it? It seems that Tim really couldn't find time to do this. I'll write all required code, all the way, and just need someone to review and check in the code in the HEAD.
Average of ratings: -