Page MenuHomePhabricator

Create a drag-drop solution for ranked choice voting
Open, HighPublicFeature

Description

Feature summary (what you would like to be able to do):
The current MediaWiki-extensions-SecurePoll interface for ranked choice voting shows a series of drop-down menus to represent the first choice, second choice, etc. This task asks for creating an alternative UI in which each candidate is represented as a box, and the boxes can be dragged and re-ordered by the user.

Steps to reproduce (a list of clear steps to create the situation that made you report this, including full links if applicable):
(Section name is weird; "reproduce" is for something that exists, and this is request for a feature that doesn't exist)

Please see https://jqueryui.com/sortable/ as an example

Use case(s) (describe the actual underlying problem which you want to solve, and not only a solution):
When ranked-choice voting has many options and it is not allowed to have two candidates in the same rank, achieving this using drop-down menus can be difficult (you have to keep rechecking your other choices, unless you really have a clear picture of your ballot in your head or paper). The UI will allow users to more easily express a ranked choice vote.

Event Timeline

Yes, DraggableGroupWidget (vertical) would be a great choice.

Hm, what has to be noted is that I have tried interacting with both the OOUI widget and the jquery ui one on my phone (Firefox for Android, with my fingers and with Samsung S Pen) and failed to do so. I guess there should also be some buttons to move the options higher, lower or to have them removed from ranking completely (I guess there should be a button for the latter in any case; IIRC some people recommended that a sure way to vote "against" some candidates was not to rank them at all)

We've had hundreds of kilobytes of discussion on fawiki about "remove from ranking" (or not rank at all) phenomenon and believe me, many users believe that most user don't understand that no rank = worst possible rank.

I am actually against it. If no rank = worst possible rank (which is true, at least in ranking methods we have implemented in SecurePoll) then let's keep it explicitly that way, i.e. have the user move undesired choice to the bottom of the list. Let's not make any assumptions about how the user will understand the meaning of an "unranked choice".

jrbs triaged this task as High priority.Sep 23 2022, 10:20 PM
jrbs moved this task from Backlog to Needs evaluation on the MediaWiki-extensions-SecurePoll board.

Change 865096 had a related patch set uploaded (by STran; author: Pavlo Yashchenko):

[mediawiki/extensions/SecurePoll@master] Create a drag-drop solution for ranked choice voting

https://gerrit.wikimedia.org/r/865096

Thanks to @jsn.sherman for CR back in August, much appreciated!

This breaks nojs: current stv polls work without javascript. I don't know that this is blocking, but doesn't look like it was a considered tradeoff.

I brought this up internally to work out our stance on this. I think the ideal solution here would be having a no-JS backup option (that users can be automatically driven to, or click a button to get, whichever is most feasible).

The drag and drop code is STV-specific, yet it runs all polls: This code should only run on polls for which it serves a purpose. The minimum fix would be to limit it to STV only. I suggest that you consider adding support for other ranked polls as well.
There are no js tests: code that introduces console errors should not pass CI. This is a larger problem with this extension, which you have inherited.

These two items I don't know much about personally and will defer to the engineers :)

I brought this up internally to work out our stance on this. I think the ideal solution here would be having a no-JS backup option (that users can be automatically driven to, or click a button to get, whichever is most feasible).

Perhaps a silly question but is it possible to "detect" that a user does not have JS enabled and to present them with the "old"-style dropdown selection boxes, while defaulting to the drag-and-drop JS solution?

I brought this up internally to work out our stance on this. I think the ideal solution here would be having a no-JS backup option (that users can be automatically driven to, or click a button to get, whichever is most feasible).

Perhaps a silly question but is it possible to "detect" that a user does not have JS enabled and to present them with the "old"-style dropdown selection boxes, while defaulting to the drag-and-drop JS solution?

When js is enabled, the <html> element gets the .client-js class. When js is disabled, the , the <html> element gets the .client-nojs class. Quite a bit can be done by providing the basic interface via php and managing visibility of elements via nested less rules. If that doesn't get you all the way there, more complex tweaking of the js-enabled experience can be done by having the js code manipulate the dom/css of elements when it is running.

@TAdeleye_WMF my suggestion would be:
if the css class client-js is present, we enable drag and drop for STV and if it is not present, or client-nojs is set, the previous interface with the dropdowns is used. I would not use any other alternative such as multiselect, as the order can also play a role here, so I would leave it as it is.

@Miriamin I think that would be a good enough compromise.