| Kaartic | |
| May 11 2018, 7:43 PM |
| F23507301: image.png | |
| Jul 9 2018, 4:19 PM |
| F18178266: image.png | |
| May 12 2018, 12:28 AM |
| F18169686: name and values should be distinguished. names-don't change, values-change.png | |
| May 11 2018, 7:43 PM |
| F18169949: name and values distinguished-old UI.png | |
| May 11 2018, 7:43 PM |
It's hard to distinguish the text that changes ("values" such as "Your existing signature") from those that do not change ("titles" such as the signature of the corresponding user). They should be distinguished in a better way in order to help the user find the current state of a value easily.
![name and values should be distinguished. names-don't change, values-change [1].png (146×756 px, 10 KB)](https://phab.wmfusercontent.org/file/data/urzsronwnewdlfdjkpyx/PHID-FILE-vegqw5fnydroykwxcue2/name_and_values_should_be_distinguished._names-don_t_change%2C_values-change_%5B1%5D.png)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core | |||
| Open | None | T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core | |||
| Open | None | T100161 Convert all of MediaWiki core to OOUI PHP (tracking) | |||
| Open | None | T101480 Remove 'wgUseMediaWikiUIEverywhere' and code forks, always using the off/false path | |||
| Open | None | T101471 Convert core forms that use MW UI with wgUseMediaWikiUIEverywhere false to OOUI FormSpecialPage or explicit OOUI PHP | |||
| Open | None | T107037 Convert all MW core special pages to OOUI | |||
| Open | None | T64559 Redesign Special:Preferences (tracking) | |||
| Resolved | Volker_E | T180538 Improve Special:Preferences UI/UX | |||
| Resolved | Volker_E | T117781 Convert Special:Preferences to OOUI | |||
| Declined | None | T194535 Special:Preferences-OOUI: distinguish titles and the values |
Not fully convinced, that it's more unclear now by position.
My first approach would be to replace “Treat the above as wiki markup. If unchecked the contents of the box above” by “Treat the signature as wiki markup. If unchecked the contents of the input above”, or maybe “input box”
Proposal:
Another alternative would be “Customize signature”.
@Kaartic would you provide a closer insight in what is problematic to you? Even after revisiting, I really don't think that the position is problematic here?
My proposal earlier falls short, as the input can either be a nickname or a signature and making this explicable is just adding to the already overly length of the checkbox label.
The order of
is in my opinion clear and useful.
Sorry for the delayed response. First of all to clarify, I wasn't speaking just about the signature field and the corresponding checkbox. I was speaking in general about the pair of preference titles (e.g. "Email (optional)", "Prohibit these users from emailing me:") and their values (e.g. "example@example.com").
I thought it was easier and quicker to search/locate for the preference titles (e.g. "Email") in the non-OOUI preferences page by means of quick scanning as the titles and the values were in different columns. In the OOUI version it's a little hard to search/locate them as they seem to be in the same column (which isn't a big deal) and seem to be using the same font styles (which seems to be the issue for me). I think distinguishing the titles and the values by styling them a bit differently might help in locating them easily.
@Kaartic Thanks for the clarification! After revisiting this, I would like to share some arguments on why the changed layout is a superior treatment, even though it implies some habitual changes.
The main reason for the re-positioning of the labels above and the labeled preferences widgets/contents below is that in OOUI we follow a user-experience best-practice in regards of several factors, like ease-of-use/quick scanning, internationalization, and other more. You can find a comparison of different label position approaches and an extensive list of their advantages/disadvantages for example here.
Therefore I'd suggest to decline this.
I don't have a strong preference here. I just thought it might be better if there was a way to distinguish the preference titles and their values. If it does more bad than good, it's not worth it.
@Kaartic Ok, thanks. I will close this ticket for the time being and we'll keep this in mind in case we receive similar feedback from others as well to revisit the task.