Description

Mock-up:

User Story:
As a user entering an edit conflict
And without javascript
I want to be able to change the order of the conflicting comments
So that I can make sure that my response is sorted in the correct order

Acceptance criteria:

The user can decide in which order the conflicting comments appear i.e. which comment comes first

I've just added the Mock-Up we came up with @ecohen but actually we have two kind of open questions that we still consider from the UX side:

We are not so sure about the wording of "Please choose a position for your entry in relation to conflicting entry:" more input would be appreciated.

Instead of radio button, we've chosen this design for selecting a position that is inspired by the "ButtonSelectWidget" OOUI item. But this might not work if there are more then two conflicting entries. So would that be a case? @awight (Any Dev input is appreciated. )

We are not so sure about the wording of "Please choose a position for your entry in relation to conflicting entry:" more input would be appreciated.

It seems good enough for now. My only input is that we might explain the specific use case for swapping the entries: "Normally, your comment would appear last, as shown here. However, in some cases your text should appear first, for example when the conflicting text is a reply to a different thread. If so, you can use the 'Insert above' button below."

Instead of radio button, we've chosen this design for selecting a position that is inspired by the "ButtonSelectWidget" OOUI item. But this might not work if there are more then two conflicting entries. So would that be a case? @awight (Any Dev input is appreciated. )

There will always be exactly two conflicting entries in this workflow :-)

@ecohen Thanks for the adjustments! A few more little details... this is currently what the JS view looks like, note that the "Conflicting entry" text has no background color and the actions block at the bottom is not indented. Should I change those two things for consistency with the latest mockup?

Here's the no-JS view, do you want me to add the text to the left of the boxes and indent everything on the page, including the actions block with edit summary and save buttons?

I'm not sure where there is a version with a background color for "conflicting entry"? I'm not seeing it but I think it is fine as is.

No-JS version:

Yes, indent everything, including the actions block to keep it consistent

Yes, add text to the left of the boxes labeling the different comments/entries

Also, in the latest mockup I switched the order, with the 'choose order actions' to the bottom of the content and above the actions block. After looking at it again, I think it makes more sense to group it with the publishing actions and not interrupt the flow. If it's too late to make this change it's ok, but if it's possible to lump it with the changes above that would be great.

I'm not sure where there is a version with a background color for "conflicting entry"? I'm not seeing it but I think it is fine as is.

I think I'm not describing it well, also not sure: In this task's description, the current mockup has background colors for the "Conflicting Entry" and "Your Entry" labels in the leftmost column. I've accidentally merged a patch which does add this background color, so feel free to confirm again whether this was intentional? It's just a few lines of .less either way, obviously.

The rest of your comments are coming through loud and clear, thank you!

Grouping order-reversal with the publishing actions is a really nice change, good idea.

@ecohen One more question, this time off-topic: what do you think about combining this radio group with the <> button in the JS-enhanced interface? Clicking the button would animate the rows, and also toggle the radio button. It seems like a win-win for accessibility, to give both textual and visual, explicit and implicit audiences something to interpret.

Ah I think I understand what you mean now about the background. You mean the background highlight of the two labels for the entries? Yes, I would keep it. I see it in all of the designs in the figma file, so it's definitely intentional. It also keeps it consistent with the 2Col styling of the version labels.

Current screenshot for the no-JS version looks great. Thank you for sharing. I am wondering if it has the same issue with the gray boxes though? Is it scrollable?

Re: combining the 'flip' button with the radio button, I wouldn't do it. I understand what you mean but I think the feedback of the two comments switching positions should be enough to communicate and having two ways to do the same thing could actually cause more confusion.

I am wondering if it has the same issue with the gray boxes though? Is it scrollable?

Good catch. No, it's got the same bug as for the article namespace conflicts. Best thing to do is probably to track this bug separately, and mention that it also affects the talk page interface, because the fix is probably just a small extension of the article page fix. I don't see a task for this specific bug yet, so I'll make visible here by adding to the acceptance criteria.

Re: combining the 'flip' button with the radio button, I wouldn't do it. I understand what you mean but I think the feedback of the two comments switching positions should be enough to communicate and having two ways to do the same thing could actually cause more confusion.

I'm running into another OOUI bug, which is making it impossible to satisfy this criterion:

The interface should be usable with keyboard commands

In this case, the RadioSelectInputWidget accepts tabIndex = 1, but the attribute is never applied to rendered radio inputs. @Volker_E should we report this as a separate issue? If we submit a patch is there capacity to review?