User talk:UncleDouggie/smart watchlist.js

This script grew out of a thread on Jimbo's talk page. The current version is for demonstration purposes only. Any use of settings may not be compatible with future versions. Settings are saved automatically. There is currently no settings editor; only "undo" and "clear all" are provided. Once the set of features starts to settle out, a settings editor will be added. It is too much work considering that features will likely change.

The long list of buttons is a bit unwieldy, but hey, it's a demo! Lots of big colored icons all over the page wouldn't be very pretty either. Please provide feedback below as to what type of user interface is desired. Adding more features may start to look even more cluttered until we figure out a better way.

To install, add the following line to your custom JavaScript file:

importScript('User:UncleDouggie/smart watchlist.js'); //[[User:UncleDouggie/smart watchlist.js]]

If you get a message that says To use Smart Watchlist, enable "enhanced recent changes" in your user preferences., go to Special:Preferences#mw-prefsection-rc, check both the 'Group changes by page in recent changes and watchlist' and 'Use non-JavaScript interface' boxes, and click 'Save'. Remember to bypass your browser's cache.

Browser support

• Firefox 3.5+ (tested on 3.6 and 4.0)
• Chrome 4+ (tested on 10.0)
• Internet Explorer 8+ (untested)
• Opera: should work in theory, but it currently doesn't.
• Safari: should work in theory, but it currently doesn't.

Some older browsers will be able to perform actions temporarily, but the settings will not be saved for the next time the watchlist page is loaded. A warning is displayed in this case.

All settings are saved on the user's local computer, but no cookies are created. There is a separate datastore for each combination of local user account, browser type and logged in wiki username. Therefore, changes made when running on Firefox will not be visible when running on Chrome even on the same computer and account. An ability could be added to export/import settings to other browsers and/or devices using an on-wiki userspace page for intermediate storage. This would also provide a useful backup capability for settings in the event that the local datastore is lost.

Requested features

1. Rank pages by importance, ability to select display of only a certain level or range – partial capability currently to flag high importance pages
2. Watch only talk pages, or only article pages, respectively, for individual articles  Done
3. Group pages by type, either Category, or user-supplied tags; effectively, have multiple watchlists  Done
4. Mark changes as read or 'patrolled'  Done
5. Record the STiki/CBNG/WikiTrust scores alongside changes, optimally with some visual signal for higher risk edits
6. Ability to watch search across more than one criteria, so that I could see [Articlespace] edits, which are [high priority (my tag)], which are [MilHist related] and have a [high CBNG vandalism score]. Basically a dashboard like there is now, but with parallel, simultaneous, categorization or filtering.
7. Include *all* edits to a page, not just the latest one (see enhanced recent changes)
8. Some way to mark groups of edits as patrolled, (e.g. mark all as read, or mark [low priority] as read, or "automatically accept reverted edits"--Graham's idea)
9. Ability to watch article sections (really wild) – actually, this could be done pretty easily, but it would be more of selecting which sections to exclude
10. Sort by number of page-watchers. (to look more closely at little-watched articles) – too slow to query the toolserver every time, not sure the best way to do this
11. Sort by number of page-views. (to look more closely at highly viewed articles) – too slow to query the toolserver every time, not sure the best way to do this
12. Ability to show only changes since last watchlist check (i.e. assuming personal patrolled changes, present all 'pending' changes since last 'patrol')
13. Hide changes by a specific user  Done
14. Flag changes by a specific user  Done
15. Work with alternate list of pages to watch using "related changes"
16. Sort by oldest change first (Jimbo request) – doesn't seem very compatible with the hierarchical view when in "enhanced recent changes" mode, would this be for the standard mode not grouped by page?
17. Merge all changes for each page under a single header instead of being split arbitrarily by days
18. Integrated watchlist with other WMF sites – in work

—UncleDouggie (talk) 21:44, 17 April 2011 (UTC)

Discussion

A, you're awesome. B, this is going to kill me because even Kingpin couldn't help troubleshoot my .js of which only pop-ups and twinkle are working (basically the gadgets, not the scripts). Here's to hoping it loads. Ocaasi ^c 08:52, 11 April 2011 (UTC)

Cool. I use visited/unvisited links for the same purpose ... i.e. if I've checked a user's contributions page before, I know that I've encountered their contribs before (either for good or for ill). Unfortunately the expanded watchlist doesn't work that well with my screen reader, JAWS. TBH I personally don't *want* to change the way my watchlist works ... I'm so used to it as it is already! Graham87 12:59, 11 April 2011 (UTC)

Douggie, for 10 and 11, watch/view counts, would it be possible to store a static version somewhere local, and maybe update it daily or weekly? I realize that would mean each individual user would need their own cache, or the 'entire' encyclopedia's watch/view counts would have to be dropped into a text file somewhere, but is there some intermediate way to just go with a static number rather than an up-to-the-minute one, as a way to reduce loadtime to something trivial--just querying that single number stat rather than checking the whole database to recalculate it? (note: IANAProgrammer, and maybe toolserver doesn't do full recalculation each time either, in which case this suggestion would not be an improvement.) Ocaasi ^c 08:48, 12 April 2011 (UTC)

• There seems to be data being stored in localStorage.undefinedGUI and localStorage.undefinedhiddenRevs. --Yair rand (talk) 18:45, 12 April 2011 (UTC)
  • Thanks, I'll fix it. I'm going to be overhauling the options next. —UncleDouggie (talk) 00:43, 13 April 2011 (UTC)
    • Fixed. —UncleDouggie (talk) 10:00, 13 April 2011 (UTC)
• A couple more things:
  • Making clearer what the difference between "patrolling" and "hiding" a revision would be helpful, IMO. (I'm certainly not able to tell what the difference is...)
  • If it doesn't already, it should probably wipe from the storage the information that certain revisions are hidden after the revisions are old enough not to be on the watchlist anyway.
  • Integrating this interwiki watchlist script would probably be helpful (probably with wlallrev:true to the api and a whole bunch of complicated reformatting...).
  • Adding the option for desktop notifications, maybe?
  • It might be better if flagging users or pages caused the whole li to be highlighted, not just the user or page name.
• --Yair rand (talk) 11:07, 14 April 2011 (UTC)

I just loaded a new version with a better GUI for assigning page categories so you can see where I'm headed with it. I left out the category editor because it still has bugs.

"hide" impacts only a single revision. "patrol" hides all revisions up to the patrolled version. There are tool tips to help. Any ideas of what would be more clear and non-intrusive?

It doesn't cleanup local storage currently, but it's on my list to do. It won't be an issue for most people because the size of each data item is very small.

I like your inter-wiki watchlist. That's also on my list to add.

I would prefer to do notifications for more than webkit users.

I'm reserving whole line highlighting for the vandalism scores from STiki once we get its API upgraded. I thought that by making the user highlighting very noticeable, the short form would be OK and more clear as to why the highlighting is being applied.

I'm getting close to adding multiple highlight colors for pages and users to replace the current clunky "flag" buttons. —UncleDouggie (talk) 12:30, 14 April 2011 (UTC)

Re notifications, is there any way for notifications to be possible on all (or at least most) browsers? It would be much better if it would work for all users, but if there isn't any way to notify users of most browsers of updates, I don't see why not to at least have the option for those who could have it. (Firefox 5 will also support desktop notifications, but that's probably not going to come for a while...) --Yair rand (talk) 12:50, 14 April 2011 (UTC)

You would still need to keep the watchlist page open in a tab somewhere so the JS can run. I was thinking of a "notification mode" in which it would make the window go purple or something when there is a new change. The window can then be made small and/or placed somewhere on the edge of the screen until there is something new. —UncleDouggie (talk) 07:54, 18 April 2011 (UTC)

Hm, I get the feeling that that would be really annoying to use, and that barely anyone would use it. Maybe it could change the document.title, like what Gmail does? --Yair rand (talk) 16:18, 21 April 2011 (UTC)

Favor. Would someone mind uploading or linking to a screenshot? I am sadly .js-script-less since the 1.17 changeover and haven't been able to fix it despite a bunch of help. So I'd love to see the interface. Ocaasi ^c 05:52, 18 April 2011 (UTC)

See below, but it really needs to be experienced. Try disabling all of your preferences. You probably have some set of incompatible gadgets trying to load. —UncleDouggie (talk) 07:54, 18 April 2011 (UTC)

It looks very cool. I mean, the screen shot does at least. (The actual, live, breathing version is probably ugly and worthless... very jealous). The color scheme is neat, especially with multi-category display. What do you think about a color-key/legend? Otherwise it might be easy to forget what the colors match up with. Ocaasi ^c 11:52, 18 April 2011 (UTC)

The page and editor colors are currently set only by the watchlist owner, so the legend is in the eye of the beholder. Different categories can be displayed even if no color is used. There could be many possible ways to automatically set colors, but it gets complicated pretty fast. Hopefully the dual scheme of categories and colors will allow users to slice and dice their watchlist any way they like. The one thing I'm planning on is using the STiki scores to set the color for an entire change row. Get your system fixed and try it out. Just go download a different browser (either Firefox or Chrome) and turn off all of your preferences. —UncleDouggie (talk) 12:21, 18 April 2011 (UTC)

Wow, so many colors... If only I had pages on my watchlist! OcaasiTesting (talk) 13:41, 18 April 2011 (UTC)

Ok for serious. This thing is disgusting...ly cool. Very well done. Great start. Looks pretty well integrated for something in alpha mode. Specific suggestions:

1. Wikilink 'enable enhanced recent changes' directly to http://en.wiki.x.io/wiki/Special:Preferences#preftab-4

   I hope to remove this restriction eventually. —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

2. explain the difference between hide vs. patrol a bit better

   Agreed. Any ideas that don't create further clutter? —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

3. add options to 'unhide changes' or 'unpatrol changes' (is that what clear settings does or does it also clear categories?)

   Agreed. You actually can unhide currently, but the button text doesn't change to "unhide" right now. —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

4. Here's my biggest suggestion and it's a big major, but might be worth it: categories should have colors associated with them rather than colors being a separate and additional layer. Primary reason: it's a bit busy looking and requires several steps per entry (3 vs. 2); it's too manual. It requires remember what the colors mean rather than having them linked to a meaningful category. It's easier to integrate user and page colors through the single category interface. Requirement for implementation: allow multiple categories per article (category drama; category ocaasi; category genius). That way you only set up the color once for each category and it then auto-colors as the entry comes up. This would require a) marking certain categories as 'user categories' so it knows to color the username not the article name; or b) have the ability to put entries in multiple categories with some designated as user categories, which would color the username not the article name. An added benefit here is the ability to group users, such as (friends, hellraisers, dilettantes, etc). Summary: consider making the category the central control point and have color be integrated through it for interface ease. Allow multiple categories per entry rather than multiple layers (category, color user, color content). This might also require an option to turn off colors, so that people could search by category without having to see colors.

   I could add user categories and allow for all categories to have an optional color. I think it should still be possible to override the color for a single page or user. This allows people to setup a few colors quickly without dealing with categories. For users, I kind of like having all changes by a user highlighted the same way without any meaning behind the color. It would be a pain to have to setup a category for each user just to get this. Allowing a page to be in multiple page categories seems like unneeded complexity. How would I decide which color to use? A given change could have both a page color and a user color, just as it does now. —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

5. What does sort order 'wiki' mean?

   This is for inter-wiki watchlists, which I'm working on. —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

6. Add numbers 1. 2. 3. 4. for the sort list fields, otherwise it's not clear you can do all of them, and that they're sequential. or add some indication that's how it works in the dropdown menu

   Yes, this needs to be reworked, probably several times to get it right. —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

7. Category display: any chance of giving that list 'ctrl' or checkbox functionality so you could select multiple cats to display?

   If I change it, checkboxes are probably the way to go. However, to jump from one category to another, people would then need to deselect the old category and then select the new one, which is two steps instead of one. I currently have the "all" mode for a quick glance and the individual category selection for detailed review. Is there really a need for a hybrid? —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

8. Category display: add options or a separate box for displaying the various namespaces (it's already in the top page field, but better to keep it central in your dashboard. similarly, it might be worth copying the 'invert selection button'

   A separate menu sounds like a good idea. The advantage this would have over the menu in the upper box is that you wouldn't need to wait for the watchlist page to reload when making a change. Although, I'm concerned about confusion with the namespace menu in the upper box. Maybe I should hide that one if it's in "all" mode or make it flashing red if it's not because in that case my namespace menu won't work. I don't like the confusion of "invert selection". Better to support multiple selection if that's what's desired. However, like the page category menu, I worry about needlessly complicating the user interface. How do you think people will be using this? —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

Nice Work! OcaasiTesting (talk) 14:17, 18 April 2011 (UTC)

Thanks. It will be awhile before the next version as I have some busy days ahead. —UncleDouggie (talk) 22:27, 18 April 2011 (UTC)

Oh, while you're busy not working on this, I realized once it's implemented on the watchlist, the obvious next step is to add a STiki/CBNG .js layer to enhanced recent changes. You probably thought of that ages ago. Cheers until you return. Ocaasi ^c 12:17, 19 April 2011 (UTC)

• I think it would be an improvement if the labels next to the checkboxes in the settings box used the label tag. --Yair rand (talk) 20:09, 21 April 2011 (UTC)

  Like this... --Yair rand (talk) 04:47, 5 May 2011 (UTC)

To clarify: If I put a page in the "hidden" category, does it hide just that page, or it's associated talk/main page as well? ··gracefool☺ 18:03, 20 June 2012 (UTC)

Screenshots

Here are some sample screenshots with exaggerated use of color to show the many options.

• 
  Displaying all categories
• 
  Displaying a single category
• 
  Changing settings
• 
  Category setup dialog

Integrated watchlist

I think an integrated, interwiki, global watchlist is the best thing a smart watchlist could implement. See this implementation here:

• User:Yair rand/interwikiwatchlist.js

See discussion at User talk:Yair rand/interwikiwatchlist.js

What is the status of implementation of a smart watchlist? --Timeshifter (talk) 07:01, 4 July 2011 (UTC)

Import / export

Hi, which files (path?) do I need to back up if I need to clear my local cache and cookies without loosing the settings so that I can place the files back later manually after a sweep? (or perhaps if I am on another computer). --lTopGunl (talk) 14:13, 15 May 2012 (UTC)

Massive kudos

This is the greatest thing since sliced bread. THANK YOU! I heard about this via Quiddity at T7875. Your implementation of this tool is superb. It's hard to believe that it's not part of MediaWiki by default. — Scott • talk 11:13, 14 January 2014 (UTC)

Oh - you've been gone since April 2011. Well, I hope that you come back some day and see this (and restart development!). Maybe someone else will take up the torch in the meantime. — Scott • talk 14:05, 14 January 2014 (UTC)

Unfortunately, I've discovered that the settings for this tool don't persist between browser sessions, so have had to disable it. That's a shame. I hope one day that someone will fix it. — Scott • talk 13:30, 20 January 2014 (UTC)