feat: Allow to reorder options of "checkbox" "radio" and "dropdown" question types in frontend

[susnux]

• Resolves Allow multiple choice or checkbox answers to be reordered #354

This adds support to reorder options instead of having to remove them.
It works but I had to modify a lot of places to keep smooth behavior of the list ordering.

Implementation things:

• I am not sure about the API endpoint, it does not match our current naming style
• Should we expose the "order" property or just keep it internally and only return options sorted?

@nextcloud/designers question:

• There is not much space for a "drag" handle + a11y button so I just used buttons, I do not think it looks super awesome, but it works. Do you have an idea how to improve? Especially because there is already the drag handle for the question itself.

Screenshots

Shuffle options enabled = no sorting	No shuffle = you can sort

[szaimen]

• There is not much space for a "drag" handle + a11y button so I just used buttons, I do not think it looks super awesome, but it works. Do you have an idea how to improve? Especially because there is already the drag handle for the question itself.

I think it looks fine but had one suggestion :)

[Chartman123]

Some things I found by looking at the code, did not test it by now.

[jancborchardt]

There is not much space for a "drag" handle + a11y button so I just used buttons, I do not think it looks super awesome, but it works. Do you have an idea how to improve? Especially because there is already the drag handle for the question itself.

@susnux what about using a drag handle that on click/enter shows a menu saying "Move up" and "Move down"? Then it would be 1 icon less, and both cases would be covered.

Questions:

• Should the drag handle be on left or right – I would tend towards left
• Which icon to use. I’d say the simple "drag" – or we use that for the whole question, and the "drag-horizontal-variant" for the individual replies?

[Chartman123]

drag handle that on click/enter shows a menu saying "Move up" and "Move down"

@jancborchardt This would on the other hand introduce one more click for every move operation...

• Should the drag handle be on left or right – I would tend towards left

having the handle on the left would introduce one more difference between edit and view mode, but we already have some differences, so I'd be fine with that. Whatever looks better as a whole.

[susnux]

The problem with a drag handle on the left is the conflict with the drag handle for the question itself.
We would then have two drag handles next to each other. Not sure about that.

[Chartman123]

@susnux @jancborchardt What about having the arrow icons as an overlay at the end of the input fields that only shows up when the field has the focus / hover?

@susnux should I add your backend code to the API v3 PR or would you like to keep it in here and adjust it after v3 merge?

[susnux]

adjust it after v3 merge?

will adjust afterwards :)

[jancborchardt]

What about having the arrow icons as an overlay at the end of the input fields that only shows up when the field has the focus / hover?

@Chartman123 sounds good! Then it’s not that much visual noise, and the fields are nicely aligned in width. :)

[marcoambrosini]

@Chartman123 @jancborchardt is out on vacation and I'm replacing him.
The arrows look good! Please make sure that their respective buttons are of --clickable-area size and that the icons are centered in them. Since these are tertiary buttons we don't need any extra margins.
One question: shouldn't the arrows show only when the input field is focused?

Other than that, for the left drag handle I would suggest this icon:
https://fonts.google.com/icons?selected=Material+Symbols+Outlined:drag_indicator:FILL@0;wght@400;GRAD@0;opsz@24&icon.query=drag&icon.size=24&icon.color=%23e8eaed

This drag button looks like it has too much right margin, I'd reduce that to --default-grid-baseline

[Chartman123]

One question: shouldn't the arrows show only when the input field is focused?

@marcoambrosini yes, but this might perhaps also be an a11y issue? and we can also deliver it in one of the next minor/patch releases :)

The arrows look good! Please make sure that their respective buttons are of --clickable-area size and that the icons are centered in them. Since these are tertiary buttons we don't need any extra margins.

Is the size not managed directly by using the NCButton?

[marcoambrosini]

@Chartman123 personally if we had to start from scatch, I would add two action buttons triggered by a click of the drag button. Adding the two options there. So that:

• click and drag allows direct reordering
• keyboard navigators can hit the drag button and open an actions menu with the move up and move down options

[Chartman123]

@marcoambrosini so instead of the arrows on the right a drag handle (also on the right) and the up/down actions behind the action menu?

[marcoambrosini]

Yes exactly

[AIlkiv]

I don't think you should overlap the input borders on hover. I tested on version 30.

[Chartman123]

I don't think you should overlap the input borders on hover. I tested on version 30.

Yes this has to be fixed, but not a blocker as the buttons will also be replaced in #2579 by a drag handle

[Chartman123]

@max-nextcloud any idea why the e2e tests are failing without my changes? I mean we're still using aria-labels, even if they are now coming from a computed prop: acfe0a3

Edit: I found the error... We changed the text for existing options and the aria-label had a wrong condition

[susnux]

Yes this has to be fixed, but not a blocker as the buttons will also be replaced in #2579 by a drag handle

But we still need buttons in addition so it can be moved with keyboard only

[Chartman123]

Yes this has to be fixed, but not a blocker as the buttons will also be replaced in #2579 by a drag handle

But we still need buttons in addition so it can be moved with keyboard only

Sure, they are preserved and with better styling in the linked follow up PR

[susnux]

I don't think you should overlap the input borders on hover. I tested on version 30.

Resolved

Resolved

[Chartman123]

Failing workflow unrelated (see fix in #2592)