Last modified: 2014-09-10 14:11:25 UTC
Created attachment 12345 [details] Current watchlist form interface (May 2013) Options form at the top of Special:Watchlist needs cleanup. Right now it features a "form" built with links to show different time ranges, then another to show different kinds of edits, and then another, this time real, form to show different namespaces. All this should be consolidated. (There's also a weird header with a one-item unordered list and a huge 'Mark all pages visited' button, but that's a different thing.)
This also partially applies to Special:RecentChanges and Special:NewPages, which have similar forms.
Related URL: https://gerrit.wikimedia.org/r/64525 (Gerrit Change I856f71f36d7f4b4baff5e968d88e4d3f7aeecce2)
(In reply to comment #0) > (There's also a weird header with a one-item unordered list and a huge 'Mark > all pages visited' button, but that's a different thing.) This part is fixed up a little in I856f71f3.
Created attachment 12346 [details] Interface after I856f71f3 gets merged
Created attachment 12347 [details] Proposed interface And here's how I'm hoping to get it to look (rough mockup).
Created attachment 12348 [details] Proposed watchlist options layout Yeah, the watchlist options definitely needs cleanup (recentchanges too, though that's apparently at least better on the backend). I looked into this before for an MDI project and came up with some possible changes then, but nothing really came of it at the time. Basically these were the changes I had in mind for the form when I looked into this before: Move watchlist-details and wlheader-showupdated (and mark visited button) out of options fieldset - they're not options, but explanations and an action. Remove wlnote about how many changes are shown - not needed, probably not even that helpful, instead just adding to the clutter. Turn 'show last' line into a dropdown menu (select) - easier on the user when scanning/using, looks better, does the same thing. Change hide links line into checkboxes to show things or not - easier to scan, more consistent with user expectations from an interface, looks better. Change 'go' button label to 'apply filters' - more descriptive. These aren't the form itself, but relate to the handling of the links above it (and in the case of enwp, would maybe provide an way to move the ridiculous notices out of the options fieldset): Remove watchlistfor contentsub with 'For <username> (toollinks)' - that's just a strange place for the tool links, and we know whose watchlist this is so that part's redundant. Add tab-style tool links with tabs (like those in the user preferences) for all watched pages and recent changes, making it easily extendable such that notices, article feedback, etc, could also get tabs if used.
(Note that the grey in the above is just styling so the stuff matches better and not necessarily relevant to this bug.)
Related URL: https://gerrit.wikimedia.org/r/64557 (Gerrit Change I9398922dc4cabc7b190f8d97c5d91a05710206bb)
Related URL: https://gerrit.wikimedia.org/r/64615 (Gerrit Change I0fcc95850aa13ea7f4b5a4fdcfddb8ca6b66bf88)
Change 64557 merged by jenkins-bot: Watchlist: Separate non-form parts out of the <fieldset> https://gerrit.wikimedia.org/r/64557
Change 64615 abandoned by Bartosz Dziewoński: SpecialRecentChanges: Rewrite the options form Reason: I might do this again one day. https://gerrit.wikimedia.org/r/64615
I was just about to file a similar bug but found this. How come you've abandoned this, Bartosz? What I was going to write in my bug is that we should move the entire set of watchlist options out of where they're currently buried in Special:Preferences and put them in the Special:Watchlist header. Your proposed layout is pretty much it, except that in addition to the "Apply filters" button, I think there should be a "Set filters as default", or "Set as my default view", or similarly-labelled button.
(In reply to Scott Martin from comment #12) > I was just about to file a similar bug but found this. How come you've > abandoned this, Bartosz? The patch as submitted did not actually work IIRC (detecting whether we've had the form submitted and should use the submitted state of checkboxes, or whether we haven't and should use defaults from preferences, is problematic with the current implementation – this probably should just use HTMLForm), and I wanted to fix bug 48641 first to make the work needed here less unpleasant. Like I said, I might do this again one day, but I don't have time right now.
Created attachment 15097 [details] Current watchlist form interface (April 2014) Uploading new version of the screenshot as the layout has changed a bit (towards the mockup from attachment 12348 [details]).
Okay, thanks for the clarification.
(In reply to Scott Martin from comment #12) > What I was going to write in my bug is that we should move the entire set of > watchlist options out of where they're currently buried in > Special:Preferences and put them in the Special:Watchlist header. Sure, this is on my radar as well. (If someone beats me at it, all the better.) (In reply to Scott Martin from bug 52817 comment #19) > There's a very similar move of preferences to page proposed at Bug 48615, > for Special:Watchlist. As this change has met approval, it would be great if > that bug could see movement - not least because this change will now cause a > preference location inconsistency, if you see what I mean. Sure, the purpose of bug 31881 is full consistency (bug 31882) across all special pages, of course we're doing one at a time.
Great - subscribed to those. Thank you!
*** Bug 66373 has been marked as a duplicate of this bug. ***
Change 149268 had a related patch set uploaded by Rohan013: A more cleaner Special:Watchlist options form https://gerrit.wikimedia.org/r/149268
