| Msz2001 | |
| Sep 1 2024, 6:22 PM |
| F57438915: image.png | |
| Sep 3 2024, 9:58 PM |
| F57385420: image.png | |
| Sep 1 2024, 6:22 PM |
Introduced in T191156: Convert FlaggedRevisions to Codex, the new "Page version status" popup is functionally a popup but looks like a dialog: it has a Close (X) button and two actions (Cancel and Review). This is very strange given that this popup is modeless and disappears after moving the cursor away from it.
I believe the UI could be tweaked to match to the actual behavior of the popup.
I don't have a strong preference here – either delete those two buttons or make it a proper dialog that appears on click and that is modal (completely or dismissed by clicking outside).
Hard to write code for this ticket until we have a proposed plan of action. Someone should post what they think the fix is for this ticket, e.g. delete X button, or do Y thing.
Change #1070056 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):
[mediawiki/extensions/FlaggedRevs@master] advanced.js: remove a couple ways of closing #mw-fr-revision-details
Change #1070056 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@master] advanced.js: remove closing #mw-fr-revision-details using mouseout
A proper dialog doesn’t open on hover either (at least not in the Codex/Vector 2022 world). The current solution is annoyingly asymmetric: it just takes a hover to open it, but I have to position to the close button to get rid of it. (Remember that it’s huge and its content is rarely needed – I don’t say it would be unnecessary, but most people either don’t care or already know what’s in the popup.) Please remove the open-on-hover effect as well.
The indicator doesn't currently have anything to indicate that it is clickable. Taking away the open-on-hover effect could make it difficult to figure out that the dialog exists. I'd like to get some more opinions on removing the open-on-hover effect before proceeding.
The arch-issue seems to be that the new indicator isn’t actually coded semantically. A semantic way to do this would be something like the script running at https://ru.wikipedia.org/wiki/Служебная:Поиск (see indicators): a properly marked up button (<button type="button">, sadly OOUI is only able to do <a role="button">) with proper attributes and icons, and then the dialog opening from that button via JS and closing via cancel/close buttons. Currently the indicator doesn’t actually control the dialog, and there is nothing in HTML to suggest it does. That makes for a poor UI experience for people using screen readers and keyboard, since they can’t actually access this information at all in the low-information mode.
I am not sure if Codex allows to do the button like in my example above, but since OOUI does, it should be theoretically possible. Then the code for mousein/mouseout can and should be removed.
There is also a separate issue that the new dialog is completely inaccessible if JavaScript is disabled. For that reason, it would be better if the ‘detailed’ mode (one you can see at https://ru.wikipedia.org/wiki/Гаванский_рабочий_городок) would be shown by default and then, if the low-information mode is enabled, enhanced via JS to be a Codex dialog.
To clarify, the code for Russian Special:Search gadget is at https://ru.wikipedia.org/wiki/MediaWiki:Gadget-common-special-search.js
I am not sure if Codex can provide the same level of flexibility with icons, but if it can’t, then it is better not to use Codex for this rather than code something that isn’t even up to Codex standards. Currently, comparing this dialog with example in https://doc.wikimedia.org/codex/latest/components/demos/dialog.html#configurable-dialog, the dialog in FlaggedRevs lacks a bunch of accessibility affordances that actually are there in Codex/OOUI.
Sorry, I haven’t get around replying on T374214. Since that task is now closed, and we’re actually back to where we were when the current task was opened, I think it makes more sense to reply here:
My preference is still Option 3, but I’m glad that we’ve at least arrived at Option 2, which isn’t great (all my points in T191156#10080919 continue to apply), but still much more acceptable than Option 1.
The indicator doesn't currently have anything to indicate that it is clickable. Taking away the open-on-hover effect could make it difficult to figure out that the dialog exists. I'd like to get some more opinions on removing the open-on-hover effect before proceeding.
As @stjn wrote above, it should be a button. If it had the usual hover affect of “quiet” buttons (not necessarily by being a <button>), then the clickability of the indicator would be obvious for sighted users using a mouse. (If it wasn’t a real <button>, it wouldn’t be accessible for keyboard-only users or those using a screen reader, but the current solution isn’t accessible for them either, so at least it wouldn’t be a step back. Neither the current nor the button-like nor the real <button> solution is really discoverable for touchscreen users, but I’m not sure if we can do anything about that.)