Add support in the formbuilder for `rank` question type

[tinok]

This question type is supported by pyxform, Enketo, and Collect, but not yet in the formbuilder. See http://xlsform.org/en/#rank

The UI implementation is the same as for select_one and select_multiple questions:

After choosing entering a question label and choosing 'Rank' question type, users can enter any number of select options in the formbuilder.

During data collection, users can then change the order of these items as needed.

[magicznyleszek]

Note: we currently have a rank question type, but it is not the official one, just an old custom implementation that when downloaded to XLS or deployed, it ends up being only a group with a special appearance¹

¹ https://www.flowdock.com/app/kobotoolbox/kobo/threads/XCS8Xsq2c6G_4UOPRCWD6_Scy_P

[nanometrenat]

Hi @magicznyleszek quick comment with user thoughts.

Yes agree that Kobo formbuilder has a question type that says it is a rank type - but as per support doco at https://support.kobotoolbox.org/en/articles/1564770-rating-vs-ranking-question-types it is just a series of select-one dropdowns with validation that you can't select the same option twice. This is fine for ranking 3 or 4 options, but for questions with 10-12 options to rank it is hard for users to remember which options they have already used.

It would be very useful to have the Enketo/ODK style ranking, where the user orders the available options rather than selecting them separately (https://community.kobotoolbox.org/t/rank-widget/2212/6)

Thanks ever so much!

[jnm]

@duvld, now that you're in CoffeeLand, could you try this issue? Before there was a standard XLSForm rank type, we (@dorey) implemented a KoBo-specific ranking type (similar to the matrix type) that gets compiled into a group of select_one questions as described by @nanometrenat above: https://github.com/kobotoolbox/kpi/blob/5495a6334b432dfb2f7e5199638af6a34f7fc752/kpi/utils/xlsform_preprocessors/koborank_handler.py#L9-L45

I think we need to support the new rank type concurrently with our old kobo--rank system so that existing forms keep working as expected. We do not want anyone's kobo--rank stuff changing unexpectedly to rank, because the format of the response data will change significantly.

I propose that if someone…	…then:
Adds a new "Ranking" question to a new survey	Use the new XLSForm rank type
Adds a new "Ranking" question to an old survey	Use the new XLSForm rank type only for that new question, leaving alone any kobo--rank questions
Edits an old-style kobo--rank question in an old survey	Keep using the old-style kobo--rank logic
Edits an unrelated question in an old survey containing an old-style kobo--rank question	Make sure the old-style kobo--rank content is not modified

[Ig-Rebollo]

@jnm @duvld looking at this after Anji brought it up yesterday. Is it worth making both available in the formbuilder as different question types? We could call the rank type drag & drop rank and kobo--rank could something like drop down rank.

Not sure if this would make it even more complicated... but I feel it might make it clearer to users. We could also create documentation explaining the equivalence, so they know which one is the ODK one vs the KoBo custom version.

If the intention is to get rid of kobo--rank eventually, then ignore my suggestion, much better to go ahead with what John proposed in the table above. But if we do not plan to ever stop supporting it, I think it might be better to have it clearly represented everywhere.