Topic on Talk:Edit Review Improvements/New filters for edit review

First of all, I’m merely testing this as in „would it disturb my usual work“, I don’t see much use in it for myself. As such, everything in this post refers to the expanded watchlist.

So, let me just list the things I noticed as worse-than-before:

• First of all, (even before the page finished loading for the first time :-) ) I noticed the main list is moved to the right by about a timestamp’s width, resulting in less space available.
• Also the Legend comes in to it in the top-right corner, resulting in even less spave for the first three entryies. Even when collapsed (which would make the jumping-around worse) it would restrict the first entry.
• So, page finished loading. Whoops, it just jumped down by two rows, I almost misclicked.
• What’re those blue dots on the left? You know, those who seem to take half a timestamp’s width? Looks like selection, but doesn’t do anything on clicking. Couldn’t find any explanation (without looking for manual pages).
• When expanding one of the first rows (to show all of today’s edits to a page), the Legend keeps taking up that width on the right for previously collapsed rows below it. Also, unexpanded rows which are now below it use that new space on the right, making them suddenly wider and more difficult to find again.
• Ok, let’s try getting bot edits away. Took me a little to find how that’s done, but that’s just due to beeing used to it or not. Anyway, I click in that text box, the list opens and… moves up? Wait the whole page scrolled itself down? Why? To keep me from hitting „mark everything as watched“?
• Now I selected to filter out Bot edits. Good. I see the list reloading already. A bit early imho, because I don’t want to waste all those reloads if I want to filter out more than just one type of edits.
• Anyway, how do I get out of this filter list? The buttons in the top-right and bottom-right corners seem to do something else. Maybe by clicking somewhere outside of it? No, clicking on the background of the „active filters“ box or even the white space above it (the part that isn’t scrolled away) doesn’t cloe it. Maybe I missed a button? No. Is „highlight results“ maybe weirdly translated in my language? It does something else than closing the box, so apparently not. I figured it out by now: Clicking somewhere else, but not in the filter UI. Maybe an X button next to „highlight results“ would be good.
• After I now filtered the bots out, the Legend is still in the same position and as large as before. But now everything of the list begins below it (plus some rather large padding), resulting in about six rows of white space between the filtering UI and the list.
• Good, enogh testing for today, let me switch back now. Erm… that… looks like… is there something missing? Well, seriously now, I’ll open a second thread plus one on my local wiki’s help desk for this last issue, because it’s so severe an I really can’t solve it.

Excellent Feedback, I concur with just about everything you mentioned. I had planned on submitting a very similar case for the new Filter System, which now saves me the time.

Although, in fairness to the work put into creating the new Filters, I do believe that the ability to Filter almost any data set is top-notch. This Project must have taken considerable time, and I greatly appreciate the work well done.

Thanks for your concisely formed feedback, it’s obvious you put a lot of time and effort into voicing your opinion on the Feedback, which not many users would likely do. As a result, I gave you a public kudos.

Markhalsey (talk) 19:17, 16 January 2018 (UTC)Mark Halsey

Thank you for your feedback, Nenntmichruhigip.

The page you describe looks very strange to me. Was your interface looking like this? If you have a different display, would you share a screenshot with me?

Can you explain what is a timestamp width? There is a lot of time and date indicators on a watchlist. :) Blue dits on the left are list elements. They are not supposed to take much room (see my link on the first paragraph). Maybe you have enabled "Group changes by page in recent changes and watchlist" in your preferences (in the RecentChanges tab).

The list of filter moved to give you the best overview of available filters. Concerning the reload for all filters, how long does it takes? Is your suggestion to select multiple filters and then apply the change?

To get out of the filter list, you list have to click on any blank space around the list, or hit Esc on your keyboard (like on quite all menues like this one). I'm afraid we can't implement a way to close the filter dropdown menu when you click again in the search bar: if a user searches for a filter in the menu, and then re-click on the search bar to type something in it, it may be confusing. I've reported the idea to examine it.

> To get out of the filter list, you list have to click on any blank space around the list, or hit Esc on your keyboard (like on quite all menues like this one)

ESC generally cancels whatever selection and closes the menu. It isn't a good way to confirm the selection. That confirmation key would normally be ENTER, but because this menu uses a textarea and a drop down simultaneously it can't just close because someone might still want to select more things.

The solution for this case is pretty simple: Keyboard shortcuts (Control + ENTER), see Topic:Tynjkxyjz21aucvx . Maybe with an informative tooltip somewhere so the user knows it exists.

Those shortcut keys are pretty common in both wikis and other unrelated websites.

Re „timestamp width“: The width of "00:00:00". Just a rough measurement anyway :-)

Re „blue dots“: Yes, this grouping thing is enabled. The distance from the left to the timestamp is approx. doubled with the beta feature enabled. I suspect there might be space reserved for some other indicators? Actually, could those dots just be dropped on the expanded watchlist? Imo it’s clear enough where a new line begins (at the timestamps).

Re „filter reload“: I don’t know how long it is, but as I’m on a slow computer everything feels slowed down due to it. Also depending on the internet connection, users may have to pay per Byte, so unneccessary reloads wouldn’t be desireable there. Yes, that’s my suggestion, maybe an „OK“ button in place of the „X“ suggested in the next bullet?

Re „exit filter list“: I didn’t mean clicking the text box again (though I expected that to work, because that’s how i.e. the URL bar or regular text entry boxes work here, though MediaWiki’s search box behaving as you described), but clicking the gray area above it, or even the white ~10px above that. Actually, I just noticed that the gray area also opens the list, which I understand when clicking nearby the active filters, but is unexpected when clicking far away from them on the far right.

(Sorry for the large text, I tried switching tabs while writing and don’t know how to undo that in this Flow discussion thing) (Fixed by Alsee)

Also, while trying around to solve the issue of the missing entries, I noticed I forgot one bullet: It takes longer to load. Like, I’m used to the watchlist taking very long to load, but with the beta feature, after it’s „loaded“, it takes a little more time to load the filtering interface. Granted, it’s not that much longer, but that would still be bad if this would be not just optional.

Thanks for your feedback. We're making a lot of changes that should improve both the actual page load speed and perception of load speed (these latter have to do with some of the things you're talking about, like the results shifting around or not appearing to be clickable when they actually are or the list of abbreviations opening then closing). Some of these changes have already rolled out, so you should already see improvements. And more are coming.

Re. your comments about the layout, I'm pinging our designer, @Pginer-WMF, who will, I'm sure, have thoughts.

I’ve finally had time to create three screenshots showing the spacing issues: File:New-Beofilter-Bugreport-1.png, File:New-Beofilter-Bugreport-2.png, File:NeNew-Beofilter-Bugreport-3.pngw-Beofilter-Bugreport-3.png

About my suggestion to drop the bullets: Actually, I just noticed it isn’t clear where a new line begins with the beta feature enabled. Currently, the timestamps are always on the first line of a watchlist entry. With the beta feature, they’re vertically centered, making it harder to spot where a watchlist entry begins/ends. But the bullets don’t help with that either, because they’re also vertically centered.

I also spotted another layout bug visible in the screenshots: the "jump to navigation/search" line (only visible when for example tabbing through the page, it’s fake-focused in the screenshots) doesn’t appear in the correct place.

Thank you for the screenshots, It helps a lot!

How do you get a time stamp formatted ad HH:MM:SS? The default is HH:MM. A gadget, probably? Why also is it displaying 00:00:00?

When they are compacted, the results keep space between the dots and the timestamp, to put the shortcut letters for bots edits, minor edits, new pages... Every letter has its own column. When you add to that the selector to collapse/uncollapse the results, it can take a lot of space. We should compact it a bit more, or consider to have a different design. I'll ask if it is possible to reduce the left margin on the results list.

Concerning the bullets, they are on the left on a line where edits are grouped, but they are clore to the results when you have the detailed view. There is probably a solution that would improve the reading, but without removing them. I will also ask for some input about it.

I'm not sure about what you identify as the "jump to navigation/search" line while I don't speak German. :) Are they the two links overlapping with the page title at the top? This is not a default feature. A gadget maybe?

(About the large text, you have created a title using the shortcut ctrl+1. Select the text afain and press ctrl+0 would have fixed it, or you could have switch to the wikitext input mode, using the pen on the right of a post reply form.)

Sorry for the delayed response, I missed your reply since unread messages on Flow discussions aren’t highlighted on the watchlist (and because I’m rarely checking it on this wiki).

I'm suspecting the "Date format" setting at Special:Preferences#mw-prefsection-rendering for the time stamp format. The zeroes are just because of beeing test content :-)

The gap you’re describing isn’t surprising, as it’s no different from the current watchlist. But the gap left of it is: Currently, the collapse arrow is all the way on the right, directly under the "2" from "2017".

The "jump to" line is indeed the one with "Wechseln zu". It pretty certainly is a default feature. Try it: Click in the search box and hit the Tab key twice. Or look for id="jump-to-nav" in the page’s HTML code.

(Quite possible, as Ctrl+1 is used for tab switching at least in Firefox. Ctrl+0 conflicts with most browser’s zoom control btw… Thanks for the hint about the Wikitext mode, let’s see how well this goes :-) )

First, concerning the delay, you should consider to enable cross wiki notifications, especially if you don't visit this wiki often. :)

The case you describe concerning the arrive is not visible on the screenshots you have made, right?

I now "see" the "Wechseln zu" and "jup-to-nav". I've added quotes, because they are hidden by default. They are accessibility links. Maybe they are activated on your wiki by a gadget? Or here (but I don't see the relation)?

The two cases depend on the context and what is prioritized by the site versus the software. If you are typing or doing something on a fieldset, the controls will apply to the fieldset. If you are outside, they will apply on the browser.

That would result in too many notifications imo, that’s why I disabled Flow notifications :-) Also, Echo doesn’t reset it’s badges for me since the change made to them a few weeks after beeing deployed, so it’s almost useless to me. But that’s another issue for which there’s already a Phab-Ticket somewhere.

I don’t know what you mean by that second paragraph, but maybe take a screenshot of a normal watchlist for comparision? I.e. This one (fonts have changed since then, but placement is the same) or this somewhat older one to clearly see how far on the left the arrow is.

They’re hidden for me to, except when using the Tab key to navigate the page. On every other page (like this discussion) they’re shown neatly underneath the title (and div#contentSub), but with those filters there’s this ugly overlap.

That doesn’t stop me from pressing them by muscle-memory when inside the fieldset… :-D

Sorry for my gibberish sentence. This is probably a copy/paste accident. :-D

It is indeed about the arrows. I don't see a problem on any of the screenshots. The one using blue arrows looks a bit closer because the customized arrive is closer.

I see the arrows that way:

> They’re hidden for me to, except when using the Tab key to navigate the page.

Ha, that's an important information. I wasn't aware of that feature, actually. :) That issue is on de.wp and fr.wp, but strangely not on en.wp. Reported!

My issue with the arrows’s location wouldn’t be visible in your screenshot, as I’m talking about the distance of this screenshotted section from the left border of div#content (or, technically, the left border of div#mw-content-text).

Looks like you’ve not been the only one unaware of #jump-to-nav. Is using mostly-keyboard navigation really that rare? :-D

The margin is due to the table structure. I'll ask again about clarification points, but changing it may require some rewriting to fit all possible screen configurations. :/

Looks like you’ve not been the only one unaware of #jump-to-nav. Is using mostly-keyboard navigation really that rare? :-D

Apparently! I use keyboard a lot while writing, but not when browsing. There is so many hidden things I'm not aware of on Mediawiki!

@Trizek (WMF): There recently is a display bug with the legend in the regular watchlist, I’m suspecting because of a change relating to this new interface: The legend box (.mw-changeslist-legend) hangs out of the block it’s in (#mw-watchlist-options) because of it’s position:absolute;right:0. Also it overlaps some of that box’s content: c:File:screenshot-beobug-legendoverlap.png. This certainly didn’t happen before, as I remeber those checkboxes reflowing when collapsing the legend.

Tracked in Phabricator
Task T184165

@Nenntmichruhigip, thank you for reporting it.

I see that bug only on Wikipedias. Other wikis don't have that bug, Catalan and Hebrew Wikipedias don't have that bug either.

Wikidata was affected yesterday (the extra-long description of the ORES marker made it cover almost all of the options), but isn’t today.