Collect question type: rank items

Should the interaction with the ranking widget match the Navigation option set in Collect's User interface options? That is, if the forward/backward buttons are turned on in navigation options should there be some sort of up/down buttons on each row in the ranking widget?

I agree @LN's sentiment that an icon just for a visual cue takes up valuable screen real estate.

Yes, space-separated ordered list (like a multi-select value).

Updated: :thinking: this makes no sense whatsoever.
For subset ranking, the fixed parts may not be relevant to include in the submission? So we could perhaps exclude those values. However, I always figured that the ranking widget would normally be used in conjunction with the new randomize() function. That may pose a problem if a part of the options are fixed. I don't really see a nice XForms syntax solution for the use of randomize() in such a case.

I hadn't thought about that. I don't think it should be governed by the same setting but I do think we'll want to introduce alternate appearances.

I'm afraid I'm not quite sure what you mean by "fixed parts"! I'm imagining them as frozen in the UI given your follow up about randomize but I do think that's what users want out of a subset rank. I think it would be more like there are, say, 12 items to rank which can be in an itemset and in randomized order but only 3 positions can be assigned. In other words, we only care about the ranking of the top 3 and the other 9 items are ignored.

Spec-wise I don't think we need to make any changes for that as I think you've implied. The value of the question can have exactly the same ordered, space-separated format but with only 3 values included, not 12. We'll just have to consider a variation on the UI.

i would think a line break or spacer of some kind after the number of rows being requested.

and/or perhaps numbers next to the rows for the number of ranks being requested. i.e. you're presented with 8 options and asked for top 3, so the first 3 rows are visibly numbered.


Ah, I totally misunderstood the subset ranking! So ignore my answer please.

Yes, it would be good to figure out the syntax for that. So, just to be clear (this time), would simply a single number indicating the desired length of the ranked list suffice (XForm and XLSForm syntax-wise)?

Right, that’s all the info that’s needed as far as I can tell. I think an attribute would make sense.

Yes, an attribute on <odk:rank> (or bind, hmm...) perhaps.

Just to bring up another possible way to approach this, which is easiest explained by including the UI. (It may already have been brought up in the UI options above.).

We could let the collection of options always be visually separate from the ranked (and therefore selected) options. In that case a count-selected() constraint could take care of getting the required number of ranked items.

Though this may be a less clean-looking widget if all options need to be included (in which case you could drag-and-drop within the same list - as screenshot in OP), it does provide consistency between All and Subset variants of this widget.

Ok, @Tino_Kreutzer, you're right -- let's figure out the subset variant.

Good idea! Regarding the UI, I admit I don't love having to drag items into a list. I think that requires quite a bit of dexterity on some devices and it makes the common case tougher.

But I think the idea works well with something like a dropdown appearance:

In the first example, all items are ranked. In the second, only the top two are ranked.

This would mean a slightly different behavior between appearances. The default appearance would always have a ranking for all items. The dropdown appearance would allow for some blank rankings. Is that acceptable? Or could we introduce an attribute for that (e.g. allow-blanks)?

If we were to introduce an attribute to specify the number of items to rank, I do like @danbjoseph's suggestion of some kind of separator to indicate the number of "ranking spots" here.

1 Like

A common approach in practice is likely to be to use 2 questions. This structure is, as far as I can remember the main one I have seen.

  1. Select the 3 principle problems that affected you

  2. Rank these problems in order

So from my perspective not combining selection and ranking would be fine. Presumably you would just use choice filter to only show the questions to be ranked as per now.


I really like @Neil_Penman's suggestion as a way to support subset ranking. It keeps the widget clean, beautiful and simple (and more fun to build imo). The widget has to be able to deal with dynamically updated options (cascading selections) anyway, so we may as well make that The Subset Ranking Method. There is 0 complexity/code added with this solution, and no syntax additions.

A dropdown appearance to avoid having to drag-and-drop sounds fine to me if there is a need for this.

1 Like

Sounds great, thanks for bringing this up! Agreed with @martijnr that this is nice and clean.

Would like to see dropdown as well but it can be a later addition as it's not needed for subsets.

1 Like

+1 on @Neil_Penman's idea for splitting it into two questions (select priorities, then rank them). This is already possible but complex/awkward to build in XLSForm.

WRT dropdowns: The previously chosen ranks should become unavailable in my view to avoid unnecessary user error OR when a user chooses a rank that was already used it is removed from the first item.

@LN I agree with the UI suggestion of dropdowns rather than dragging. Or use both: That's what SurveyMonkey does; either you assign dropdown values or you start dragging items (at which point each item receives a rank based on the current order).


I was thinking that a rank would always have a value and that resetting it would reset the order to the original one but @martijnr has pointed out on Github that it would be more consistent to provide users with a way to represent "no value".

He is planning this kind of interface for Enketo:

In Collect the equivalent would probably be to have a button that says "start ranking" shown before the list becomes modifiable. Clearing the widget would go back to showing the button.

When we introduce the dropdown variant an empty state can be represented as no rankings set. We'll then need to decide what to do when some ranks are selected but not others.

How does that sound?

This sounds good to me. It's inline (pun?) with what we do with representing null on dates.

The first beta for v1.16.0 is rolling out now and includes rank support! Please learn more about the beta program and join to try this out. You can download the Rank Test form from the default server. XLSForm support is coming soon.

Is the interface clear?

Some potential changes we have discussed are:

  • adding numbers to the left of the items to indicate which rank each has
  • changing the "Tap twice to start" interface to use a button like with the date or geo widgets
1 Like


  • adding numbers to the left of the items to indicate which rank each has

Yes this would be good

  • changing the "Tap twice to start" interface to use a button like with the date or geo widgets
    Agree something more like the rest of Collect interface

I know the beta focuses on the collect interface currently - so I presume the way the data looks on the server is not how we imagine i coming down - I would be in favour of your above comment of:
a column for each option with the number of the rank in that column.


Rank by dragging and dropping is now available in ODK Collect v1.16 and XLSForm online and offline.

To add a rank question to an XLSForm, use the same structure as select_one but use type rank instead. See a sample form.

An appearance with dropdowns will be forthcoming.


Tino, do you know where I could find an example of this, selecting priorities and then ranking them?

Hi @Oliver_Burdekin
please take a look at this sample Select_multiple choices, then rank the selected choices

1 Like

Excellent thanks @Grzesiek2010 This is exactly what I was looking for. Need to up my forum fu :slight_smile: