It might be useful to ignore a single bot (or more) and not all.
For example, MsnBot makes a lot of minor changes and my list is full of these changes, while they are not risky, so it's harder to track changes from other bots.
Another useful way to reduce the visual number of results with attributes (authors, bots, categories, dates, tags, etc) not of concern would be to let users group results by such attribute(s) and then click to expand/collapse desired groups, and also specify such as part of saved filters and/or queries, as needed.
@Wikicat, I'm not sure to understand. You mean creating batches of edits from a given group, and then expand them?
The current system could do that, role by role (or by combining roles) if we create filters for those groups. There is a ticket about that, but declined with no explanations. I've reopened it.
@Trizek: Just a hierarchical sorting tree with collapsible branches, like a file-directory; and depending on which and what order attributes are selected each time, for example each "author" folder might contain all "months" for that author, and each "month" all "categories" that author edited that month, and each of those the pages; or each "month" might contain all "authors" for that month, and each "author" all their editing "days". Sorting first by "author", or "bot", or whatever, and not expanding selected top-level folders would hide all their activity in the results. This could also be a multi-sortable table with collapsible row-groups. Further, to save strain on the server, could dump top-level-sorted blocks of records to browser and do the remaining sorting in a wikitable. Also, this sorting-tool could apply to any generated list of pages.
It looks like a new tool, not an improvement of the existing filters. I'm afraid that's out of the scope of the small improvements that can be made through the maintenance process.
I almost did not leave any new messages here, because I only accidentally found the link to this talk page.
The link should not be buried in the closed "Filter changes" menu.
Many people may want to give feedback here, or ask questions, but will never scroll down to the bottom of that menu, or will forget that the link is buried there.
Put the link at the top of the menu, and out of the menu.
A feedback link was available during the whole Beta process. We have received many comments that have allowed the development tram to improve that tool. In theory, the feedback link you used was supposed to be removed, now that the filters are default for every user.
The Filter menu is the most used element of the tool for people who take action. It is the best place to put the feedback link. That link is always visible: the bottom of the menu is stick to the bottom of your browser window. There is no need to scroll, even if the page is really compact.
Thanks. That is an improvement making it always visible in the filter menu without scrolling.
I hope you didn't mean that developers were no longer accepting or wanting feedback. Please don't remove the feedback link. Most people will not hunt around for Phabricator threads to give feedback. Or come to Mediawiki. Unless a feedback link from Wikipedia takes them there.
We don't plan to remove that link. We still need it to have a way to be aware of bugs.
If someone wants to suggest a change or an improvement, we will look at it but it may be implemented later.
Have a like like that is done on more and more tools because of the reason you mention: people won't come to Phabricator or elsewhere because they aren't aware of it.
That helps a tiny bit, but the box needs to be much wider. I want much longer descriptions so that I can quickly scan the list and pick the sets I like.
What developers need to understand is that many editors, if not most, desire SPEED. All changes to the watchlist should be made with that in mind.
Recent changes no longer lists changes starting from a specific date.
Background
Normally, if one wants to see changes from 20 days ago and it is not visible because there are too many changes in between it would be possible to use the URL "&from=" parameter to start showing changes from an older date limited by number of days. This is how the API works.
Steps to reproduce:
Disable javascript to use the older recent changes
Go to Special:Recentchanges
Click "Show new changes starting from" ...
Alter the url so it starts showing changes from a few days before the last wiki action, e.g. https://www.mediawiki.org/w/index.php?title=Special:RecentChanges&from=20181225000000
Click enter
Expected
Recent changes start from 20181225000000 or a date close to that (if it is less than the 30 days maximum).
Contributions by you/other editors. You have two mutually exclusive options but you designed them as check boxes. Because they are mutually exclusive, they should be radio buttons, not check boxes.
yes, indeed: but all our filters are designed to filter potentially problematic edits... many edits I want to see are not tagged because they are not problematic, so...
-> just did what you propose... and got absolutely no answer - that's a good sign: it means we do not have a lot of really problematic contributors ^^
but that is not what I was hoping for... just wanted all edits except those AWB that are made by one of our admins...
well, we'll have to wait for a solution from our dear devs ;p
In most software, a tick box either selects or deselects a particular option: simple. So you'd expect a group with no boxes ticked to be equivalent to selecting none of the options, and you tick one or more of them to add the options you want. In fact, no ticks seems to be the same as all-ticks: ticking a single box in an unticked group surprisingly and without notice deselects all the options other than the one selected.
Now it's true that this is documented half way down the long documentation page, but it should be clear on the face of the controls themselves.
Checking the appropriate check boxes by default accompanied by 'Select all' and 'Deselect all' options.
For example, by default results from all Namespaces are shown but none of the boxes are checked. Checking the box for a namespace results in results being only shown for that namespace. In this case, the suggested change would be as follows. Check boxes for all the namespaces should be checked by default and the user could use a combination of 'Select all', 'Deselect all', checking some namespaces to achieve their desired output.
Unfortunately, this seems to result in some added UI elements which might add up to page clutter (the namespace drop down might become over crowded, for example). I don't know how to avoid this though:-)
When you had first access the watchlist, you had that pop-up offering you to opt-out. If not, I'm sorry about the inconvenience, but you may have a script or a gadget conflicting with that notice (and probably other stable tools).
In any case, there is an option in your preferences, Matěj gave you the link.
I went here immediately, since the optout popup is hidden behind the first.
In the future, please consider adding a "Get me outta here/Bring everything back as it was" button already to the first popup.
Btw, how do I get back to the regular talk pages? (Suspecting each wiki has its own setting; please add "luddite" option to globally make any and all new developments opt-in) CapnZapp (talk) 10:42, 17 July 2018 (UTC)
Have the opt-ing out button on the first pop-up is definitely a lesson learnt.
Concerning the talk pages, all talk pages are using Structured discussions on mediaiwiki.org. You can't opt them out. (And you don't need to sign anymore.)
The amount of white space is blinding. I realize this is not the place, but please tell the "structured" devs to add a "condense" option so less screen estate is wasted. Please don't "beginnerify" Wikipedia (or rather, do, but for new users)
Having to sign is obviously something I can live without, though.
Sorry that is unacceptable - I call that hit and run development. Revert back the introduction of new features if the programmers are unavailable right after release to polish their new stuff properly, that should lit a fire under their collective arses.
Please direct me to the proper feedback/discuss page of "structured" talk pages, so I can give my mind to those responsible: leaving development in this shape is unacceptable.
"learn more about indentations" - why not simply say "indentation is not supported"? That page says "you don't need to indent anylonger" as if that's a good thing?! No wonder English Wikipedia rejected this mess. Luckily I'm not a frequent contributor to mediawiki, so I leave it to others to battle down this misguided and overwrought mess. The simple truth is that the Flow Project should have been shut down entirely; its team members dispersed over many other projects so their collective will is broken. It's not unheard of for smaller communities like this one to be usurped by a fanatical core of devs who ignore common sense arguments, and I will certainly not waste anymore effort here. For your sakes, I hope the flow programmers are ousted sooner than later. Signing off (because I want to), yours truly CapnZapp (talk) 09:44, 18 July 2018 (UTC)
And I hope the next time wiki isn't afflicted by hit and run programming. Implementing something and then immediately "stalling" development (without a clear opt-out path) is like a punch to the face, and deserves all the unpleasant feedback it can get. Have a nice day. CapnZapp (talk) 15:44, 4 December 2018 (UTC)
Switching to the mobile interface will display the old display, without the filters. If you force purposefully the desktop view on mobile, you will get the filters, which are, indeed, not mobile compatible.
That's not the whole story. I use desktop only (no interest in mobile) and, while the new watchlist has some cool features, it certainly does "jump all over the place" as OP describes. I may be trying to click on items in the history, and suddenly the whole thing leaps away from me as a large JavaScript panel loads into place. I might even hit Rollback by accident, which is embarrassing. Can't you pre-load an empty white space to prevent things from jumping? (BTW this is true in other places too, like the late-loading Citations tab on Wiktionary.) My computer is old and slow but I shouldn't be punished for that.
I wouldn't suppose the developers wanted to punish the people with old and slow computers. I would suppose they would have missed this use case (it's really hard to develop software that works out-of-the-box for everyone!) . It might be of help to them if you could provide more information about your configuration in which you face this issue: OS, browser (with versions). They might use it to see if they could do something about it.
A temporary solution would be to switch to the old interface if that worked well for you. You could do that via Special:Preferences.
I mean that the page loads, and then further additional things load (like extra tabs), and as those things appear, the page "reflows" (like adding words in the middle of a paragraph) so that things I am trying to click on might continue to move to new positions. It would be better if the page didn't appear at all until everything was in place -- since having things jump away from under the mouse pointer is very frustrating.
