Only use case remaining after RCFilters grew out of beta is for non-modern supported browsers/non-JS clients.
Checkboxes should be inline.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Refactor NamespaceInputWidget | mediawiki/core | master | +307 -142 | |
| Use OOUI HTMLForm for Special:Watchlist | mediawiki/core | master | +138 -41 |
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Declined | None | T72913 Remove $wgUseMediaWikiUIEverywhere dependency for button and text input styling | ||
| Open | None | T107037 Convert all MW core special pages to OOUI | ||
| Open | None | T163098 Fix the Watchlist visual layout | ||
| Open | None | T99256 Convert old Special:Watchlist to OOUI (HTMLForm?) | ||
| Resolved | matmarex | T107868 Implement a FlowLayout/HorizontalLayout, that would arrange its contents in a single line | ||
| Resolved | matmarex | T107922 PHP LabelWidget should be able to associate with InputWidget via <label for> and generated 'id' attributes | ||
| Resolved | Catrope | T181193 [EPIC] Graduate the New Filters UX on Watchlist out of beta on all wikis | ||
| · · · |
Event Timeline
There are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
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
Comment Actions
"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
Comment Actions
@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?
Comment Actions
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:
- 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).
- 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
- 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!!).
- 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.
Comment Actions
Change 230821 had a related patch set uploaded (by Bartosz Dziewoński):
Refactor NamespaceInputWidget
Comment Actions
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.
Comment Actions
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.
Comment Actions
The collapsible feature request is covered in T67819: Make form#mw-watchlist-form collapsible :)
Comment Actions
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.
Comment Actions
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);
}Comment Actions
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.