Page MenuHomePhabricator

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

Description

Only use case remaining after RCFilters grew out of beta is for non-modern supported browsers/non-JS clients.

Checkboxes should be inline.

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
OpenNone
OpenNone
Declined Mattflaschen-WMF
Declined Mattflaschen-WMF
DeclinedNone
OpenNone
Resolvedmatmarex
Resolvedmatmarex
ResolvedCatrope
ResolvedCatrope
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedPginer-WMF
ResolvedMooeypoo
ResolvedSBisson
ResolvedCatrope
InvalidNone
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedMooeypoo
ResolvedSBisson
ResolvedSBisson
ResolvedSBisson
ResolvedSBisson
ResolvedSBisson
ResolvedMooeypoo
Resolved Mattflaschen-WMF
ResolvedCatrope
ResolvedJdforrester-WMF
ResolvedSBisson
DeclinedNone
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedCatrope
ResolvedSBisson
ResolvedCatrope
ResolvedTrizek-WMF
ResolvedTrizek-WMF
ResolvedCatrope
ResolvedSBisson
ResolvedJdforrester-WMF
DuplicateNone
ResolvedMooeypoo
ResolvedNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Maybe it shouldn't be a "primary" button, but just a button. The difference in the default theme is pasted_file (33×65 px, 908 B) vs pasted_file (33×65 px, 925 B). 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 pasted_file (33×65 px, 908 B) vs pasted_file (33×65 px, 925 B). The primary button on that form is the "Go" one.

+1

Maybe it shouldn't be a "primary" button, but just a button. The difference in the default theme is pasted_file (33×65 px, 908 B) vs pasted_file (33×65 px, 925 B). 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.

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.

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

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?).Nov 4 2015, 5:33 PM
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.

Jdforrester-WMF assigned this task to Esanders.

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

View

Screen Shot 2018-05-03 at 08.45.27.png (553×1 px, 147 KB)

Edit

Screen Shot 2018-05-03 at 08.45.32.png (624×1 px, 82 KB)

Raw edit

Screen Shot 2018-05-03 at 08.45.41.png (713×1 px, 96 KB)

Clear

Screen Shot 2018-05-03 at 08.45.44.png (237×1 px, 34 KB)

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.

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.

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
Volker_E lowered the priority of this task from Medium to Lowest.Nov 11 2018, 1:20 AM

Similar to T117740, with T157642: Graduate New Filters UX out of beta on Recent Changes on ALL wikis finished, the scope of this task is now limited to a very small number of cases – as a result readjusting priority.

Volker_E added a subscriber: Esanders.