Page MenuHomePhabricator

Adjust UI elements for number entry on Preferences tabs for Recent Changes and Watchlist
Closed, ResolvedPublic

Description

It looks like we need a bit of mop-up for a recent UI standardization upgrade to the preferences pages. Specifically, the "days to show" and "number of changes to show" boxes at the top of the RC and Watchlist prefs pages have a couple of issues:

  • The boxes are too wide with 697px (50em). They should never have to hold more than 7 (example 1 hour of a day 0.04167, because of fractional days, see below) and 4 digits, respectively. We should:
    • Shorten these elements so that they don't confuse users about the type of input that is being requested, AND/OR
    • Use some type of number widget that would be even more suitable, and might handle the maximum allowable limits more gracefully (as compared to letting users Save and only then informing them that the number they entered is not allowable).
  • Fix the help text for "Number of edits to show" on the RC prefs page: I think it's supposed to be the same as the help text on the similar, WL prefs elements: "Maximum number: 1000."

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 1 2017, 7:42 PM
jmatazzoni updated the task description. (Show Details)
jmatazzoni added a subscriber: Jdforrester-WMF.
Volker_E updated the task description. (Show Details)

@jmatazzoni

  • 6 digits is enough? People don't get to set a fractional number down to seconds? Could you clarify?
  • “I think it's supposed to be the same as the help text on the similar, WL prefs elements”? Who could verify exactly?
Volker_E updated the task description. (Show Details)Sep 6 2018, 11:38 PM

Updated task description after conversation with @jmatazzoni to 7 digits max.

Volker_E updated the task description. (Show Details)Sep 7 2018, 5:40 PM

The "days to show" box has been set to accept 1 as the minimum number. This is not the way the code is written. E.g., users who want to set their defaults to 1 hour should be able to enter 0.04167 days. ( I know that we did have this capability. If we want to change that, we can talk about it. But I am guessing this change was just an assumption on the part of whoever did the upgrade.)

This is not being changed with the change of design. The validation checks are still the same as before. Note that there are two confusingly similar preferences:

  • For the "Days to show in recent changes" (rcdays), the minimum has always been 1. (since rSVN49790)
  • For the "Days to show in watchlist" (watchlistdays), the minimum has always been 0. (since rSVN49790) [apparently it was recently changed to 1/24 in 89dcdfa826d]

I think you tested the recent changes preference, while you meant to test the watchlist preference.

I'll remove this part from the description, I am certain that this works correctly.

matmarex updated the task description. (Show Details)Sep 7 2018, 6:58 PM

Use some type of number widget that would be even more suitable, and might handle the maximum allowable limits more gracefully (as compared to letting users Save and only then informing them that the number they entered is not allowable).

For OOUI that would involve using NumberInputWidget, I'll add T203656 as a subtask.

Shorten these elements so that they don't confuse users about the type of input that is being requested,

We apparently have a precedent for using narrower fields for numeric inputs, the min/max size field on Special:ProtectedPages is 10em wide. I don't know why we're not doing that for all NumberInputWidget fields…

Change 459238 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/core@master] Reduce width of number inputs to 10em

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

Change 459238 merged by jenkins-bot:
[mediawiki/core@master] Special:Preferences OOUI: Reduce width of number inputs to 10em

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

@jmatazzoni

  • 6 digits is enough? People don't get to set a fractional number down to seconds? Could you clarify?
  • “I think it's supposed to be the same as the help text on the similar, WL prefs elements”? Who could verify exactly?

Sorry, I meant 7.

Volker_E triaged this task as Normal priority.Sep 10 2018, 5:43 PM
Volker_E updated the task description. (Show Details)
matmarex added a comment.EditedSep 12 2018, 8:17 PM

The min and max values for these fields are still not being enforced correctly on client-side. I found that this is due to a bug in HTMLForm.

Change 460089 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] HTMLTextField: Pass extra parameters in OOUI mode

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

Change 460089 merged by jenkins-bot:
[mediawiki/core@master] HTMLTextField: Pass extra parameters in OOUI mode

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

matmarex closed this task as Resolved.Sep 12 2018, 10:17 PM

Fixed, I guess?

Volker_E assigned this task to matmarex.Sep 27 2018, 6:02 PM
Volker_E removed a project: Patch-For-Review.
Volker_E removed a subscriber: gerritbot.