Convert old Special:Watchlist to OOUI (HTMLForm?)
Open, NormalPublic

Description

Checkboxes should be inline.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Legoktm added a subscriber: Rillke.Jul 30 2015, 7:24 PM

My plan for NamespaceInputWidget is:

  • Implement a FlowLayout in OOjs UI, that would arrange its contents in a single line (using display: inline-block for its items)
  • Extend OOjs UI's PHP LabelWidget, so that passing a input config option will generate an actual <label for> pointing to the right widget, possibly generating the id attribute where necessary

    Then:
  • Refactor NamespaceInputWidget into two, NamespaceInputWidget + ComplexNamespaceInputWidget: the former would be only the dropdown (and inherit from DropdownInputWidget), the latter would be dropdown plus two checkboxes
  • Use the new LabelWidgets for checkbox labels, to replace the FieldLayouts
  • Use the new FlowLayout to wrap the dropdown and checkboxes, to replace custom CSS we have
  • Refactor ComplexNamespaceInputWidget to take nested configuration options for invert, associated, and namespace, rather than require parameters like invertName and so on for every combination. We already have this on JS side in e.g. PopupButtonWidget to pass all the parameters for the PopupWidget inside using popup config option, or in DropdownWidget to pass parameters for the MenuSelectWidget inside using the menu config option.

Hmm, I didn't realize that there's no line-wrapping on the namespace selection form now, that is definitely problematic and probably should be fixed now rather than soon.

From T107414:

From a functional perspective: While I find this spacy style useful on mobile devices (big fingers ...), on desktop I have a very precise mouse and a good screen and good light conditions so there is no need for the space.
If a designer would contradict, then I'd ask the designer to present a concept for an overhaul of the entire watchlist, as design should not be only awesome to look at but also functional. As of now, the watchlist is not really nice to look at - in particular the entries are squashed together while the form controls are spacy - and part of their functionality was lost by wasting >100px.

Some screenshots from posterity (from pl.wp):

Current state
The reverted change
How it should have been

I moved some pieces around in Paint to create the last image above. I think that would be the right balance between aesthetics and utility. Compared to the current state, that loses about one line of text (the reverted change lost about 2-3 lines).

The bulk of the change is because the OOjs UI buttons use the same font size as surrounding text, while "native" buttons have smaller font size than the one used for Vector skin. On MonoBook the change was much less drastic, since the font is smaller in that skin. (It also happens to use different style for the buttons, but the rule of "same font size as surrounding text" is also true there.)

Lupo added a subscriber: Lupo.Jul 30 2015, 8:09 PM

I only saw this change (on monobook) for a short while before it got reverted.

I can understand the desire to standardize/unify the UI , but this OOUI version simply uses way too much whitespace around its elements.

Using that much whitespace may be fine for a touch device, where the "mouse pointer" is a (relatively thick) finger, but on a desktop computer with a "real" (fine-tipped) mouse pointer, it's just a very annoying waste of screen space. When I have a proper mouse pointer, I don't need huge buttons, nor do I need drop-down lists with items spaced so far apart that it looks as if there was an empty line between each item. Nor do I need buttons that are three times larger in both dimensions than the browser-native buttons. All that just means that space is wasted, I end up seeing less in the same window size.

Maybe the theme for this OOUI stuff should distinguish between touch devices and others, and drastically reduce the extra whitespace (paddings, margins) on non-touch devices, so that the element sizes of OOUI elements are close to the browser-native elements.

GOIII added a subscriber: GOIII.Jul 30 2015, 8:47 PM
  • Colored buttons very prominent on the page -> eye catcher what I do not like/need on the watchlist

I agree that the colors are a bit overpowering.

Maybe "Mark all as read" shouldn't be a button?

Maybe it shouldn't be a "primary" button, but just a button. The difference in the default theme is vs . The primary button on that form is the "Go" one.

Maybe it shouldn't be a "primary" button, but just a button. The difference in the default theme is vs . The primary button on that form is the "Go" one.

+1

Izno added a subscriber: Izno.Jul 31 2015, 2:34 AM
Florian reassigned this task from Florian to matmarex.Jul 31 2015, 3:34 PM

Maybe it shouldn't be a "primary" button, but just a button. The difference in the default theme is vs . The primary button on that form is the "Go" one.

+1

"Mark all Pages Visited" isn't the end of a workflow, it's an action you can take on the page. This can be a neutral button. As for the button "Go," if the user hasn't changed anything from the dropdown or checkbox, this can stay disabled until the user makes a change. What do you guys think? @Florian @MGChecker

@violetto from the living styleguide:

It conveys to the user they are completing a single or multi-step process. In most case Constructive color shows the user what will happen.

(Source: http://livingstyleguide.wmflabs.org/wiki/Main_Page#Constructive)

That sounds like the "Mark all as read" button fulfills this? But I think, that a neutral button is fine, too :)

As for the button "Go," if the user hasn't changed anything from the dropdown or checkbox, this can stay disabled until the user makes a change.

That would be limited for users, which uses JavaScript, what do you think about the color for non-JS users? Neutral?

That would be limited for users, which uses JavaScript, what do you think about the color for non-JS users? Neutral?>

In this case it would be green (if that's the last step of the process, or blue if there is more steps ahead)


Here's an example drawn from the Special:UserLogin

"Log in" button should be green because:

  1. It's a main constructive action (It's a log in page, this green button will help users move forward from this page that's intended to log users into Wikipedia).
  2. It's the last step of the log in process.

If "Create another account" was a button instead of a link, it would be blue. The reason because

  1. It's a main progressive action (because we want users to create accounts in this log in page if they don't have one. Plus, we want more logged-in users!!).
  2. It will initiate a process to create another account.

We use colors to help users find out what they would want to do next (as a suggestion, etc.), what to expect in the process (this requires some learning on your colored buttons) and give an indication if it's a destructive action. So not all progressive actions should be blue, or constructive actions need to be green. Best to only use one blue, green and red colored buttons once in a page unless there are good reasons not to.

These are guidelines, you guys should decide if "Go" is a main progressive button and if "Mark all as read" a main and constructive action.

Drawing from the same example, although "Forgot your password?" or "Upload file" in the left side bar initiates a process, we kept them as links because they are not main processes or actions.


I'll make sure to update our documentation.

Meirae added a subscriber: Meirae.Aug 10 2015, 3:22 PM

Change 230821 had a related patch set uploaded (by Bartosz Dziewoński):
Refactor NamespaceInputWidget

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

I previously said that this is likely to happen this week, but I didn't manage to do all the cleanup I wanted just yet, so it'll probably be next week… ish.

Em added a subscriber: Em.Aug 14 2015, 1:14 AM

This needs to take up less space on the watchlist. I feel it already takes up too much space, and this new change is going to make that area take up even more space. I'd really like to even collapse that box. I don't use it often, and would like to see more of my watchlist.

TLDR: make the options box smaller/collapsible to read what really matters: recent changes.

In T99256#1538253, @Em wrote:

TLDR: make the options box smaller/collapsible to read what really matters: recent changes.

The collapsible feature request is covered in T67819: Make form#mw-watchlist-form collapsible :)

In T99256#1538253, @Em wrote:

TLDR: make the options box smaller/collapsible to read what really matters: recent changes.

Workaround: https://www.mediawiki.org/wiki/Snippets/Collapsible_ChangesList_options

Em added a comment.Aug 15 2015, 2:24 PM
In T99256#1538253, @Em wrote:

TLDR: make the options box smaller/collapsible to read what really matters: recent changes.

Workaround: https://www.mediawiki.org/wiki/Snippets/Collapsible_ChangesList_options

OK, sorry, how do I implement that?

Change 230821 merged by jenkins-bot:
Refactor NamespaceInputWidget

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

Florian renamed this task from Fix Special:Watchlist to use HTMLForm to Convert Special:Watchlist to OOUI (HTMLForm?).
Florian removed a project: Patch-For-Review.

Hi folks, OOjs UI is not coming back to the watchlist yet, but since many people watch this bug, I thought I'll mention a different upcoming change to the form, which should be uncontroversial: changing the links into form elements. See T50615#1785794 for details and screenshots.

matmarex removed matmarex as the assignee of this task.May 17 2016, 2:39 AM
Scott added a subscriber: Scott.Jan 7 2017, 2:25 AM
Jdforrester-WMF closed this task as Resolved.May 3 2018, 3:48 PM
Jdforrester-WMF assigned this task to Esanders.

As of now in master (1.31.0-wmf.3+), all Watchlist interface pages use OOUI:

View

Edit

Raw edit

Clear

Declaring this Resolved.

foreach ($list as $item) {
  work_miracles($item);
}

Patches for edit/raw/clear were https://gerrit.wikimedia.org/r/#/c/428603/ and https://gerrit.wikimedia.org/r/#/c/428604/.

Note that if you disabled the preference "New filters for edit review", the view mode still has plain checkboxes/dropdowns/buttons.

Jdforrester-WMF reopened this task as Open.May 4 2018, 11:36 PM

Patches for edit/raw/clear were https://gerrit.wikimedia.org/r/#/c/428603/ and https://gerrit.wikimedia.org/r/#/c/428604/.

Note that if you disabled the preference "New filters for edit review", the view mode still has plain checkboxes/dropdowns/buttons.

Oh, hmm, good point. Yeah, this is blocked on T181193.

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 12 2018, 8:36 AM
JTannerWMF moved this task from Inbox to To Triage on the Growth-Team board.Jul 18 2018, 6:32 PM
SBisson moved this task from To Triage to External on the Growth-Team board.Jul 20 2018, 6:16 PM
Trizek-WMF renamed this task from Convert Special:Watchlist to OOUI (HTMLForm?) to Convert old Special:Watchlist to OOUI (HTMLForm?).Jul 26 2018, 12:49 PM