In T240530#6003657, @Tchanders wrote:

@Niharika @Prtksxna Since a target could be a username or an IP, should we have filter buttons on all the cells in the user name and IP columns? This means that the user name cells would have "add IPs" and "filter", while the IP cells would have "add users", "filter" and "pin".

In T245565#5993908, @Samwilson wrote:

@Prtksxna I think I've done all I can do here without your input.

In T247516#5976189, @dbarratt wrote:

Should the button be in title case? i.e. "New Investigation" instead of "New investigation" ? I expected the former, but the screenshot has the latter.

In T247516#5973346, @Tchanders wrote:

@Prtksxna Are we likely to add a help link to this page, and if so, does that affect these buttons? (Help links are added top right)

I am feeling a bit conflicted about this. I wanted the filtering action to feel snappy but with the full page refresh I don't think that'll happen at the moment. Auto-submitting on blur makes the interaction slightly faster, but confusing too.

Ooh, thanks @Samwilson :) Not able to find the rest of the OAuth IDs on Turnilo, but at least we can see this 😊

In T247356#5961901, @dbarratt wrote:

To make a smoother experience, we could render the table with JavaScript, but that's a pretty big change from what we have now. It would involve building an API to get the data. This isn't a huge lift, but it seemed like a lot if all it was for was this feature.

In T242945#5961242, @Niharika wrote:

@Prtksxna Does the ticket description sound good to go to you?

What is the difference between the two? I was trying to get some data out of Turnilo but I could only find filtering through Revision Tags.

In T246261#5952781, @ST47 wrote:

@Prtksxna True, but we don't use the time limit for that purpose. The only reason we would use a shorter time limit in the current tool is if we run a check on an IP address or range, and get the error that there were more than 5000 edits within the 90 day window. (In fact, the current log doesn't even show what time limit we chose.)

Adding a time filter to the the compare and especially timeline views might makes sense, but I am not sure if that should replace it in the initial form. My understanding is that CheckUsers always want to retrieve and log the minimum amount of information required to run the investigation. If we only provide this as a filter it would still get logged as if they saw the entire 90 days.

When the user clicks the Show all 3 IPs of this user button for the first record, User A is added as a target, the page refreshes and that button is disabled, correct? Is the button also disabled for the second record of User A?

Yes - we can disable the button for any users that are already targets in the query.

Got it. I think what you are proposing here is the same as what @Prtksxna had in mind. Let's go ahead with that.

In T246261#5939171, @Niharika wrote:

@Prtksxna The need for this arose because results for investigations on a narrower time window would be faster to fetch. It would help add in the time option for cases when there are a lot of results so we can prompt the user to choose a shorter time window to get it to work faster.

Ignore sounds like a good option. I was also thinking about Hide or Don't show:

• Don't show me emails from this user
• Don't show me notifications from this user

From the description:

changing row heights when pin buttons appear and disappear

I don't think any users have requested a custom time range till now (@Niharika correct me if I am wrong). We might not need the added complexity of Two DateTimeInputWidgets. Let's keep the duration field with the normal OOUI dropdown:

In T244507#5861473, @Mooeypoo wrote:

• Special:Watchlist: We can display the date that the article will expire on, and the time remaining. I believe the time remaining functionality may only be available in JavaScript (through momentjs) but am not 100% sure; there might be this functionality in the php side as well. We'll need to check. In other products (like StructuredDiscussions) we displayed the full date in "no-js" mode and augmented it with "xx ago" (which would be "xx days" etc for us) in JS; when you hovered over the human-readable, it switched to a date, so the user could get both experiences. Just a thought :)

In T238782#5898063, @dom_walden wrote:

Also, I don't know if it is just my screen, but I don't find the dark background much darker than the other cells in the table.

In T237299#5907053, @Tchanders wrote:

@Niharika @Prtksxna I have a few questions that arose while working on this:

• Are the round buttons with a white background a literal design? For now I've kept the OOUI design for the toggleButtonWidget. It seems sensible to have the buttons and colours look consistent with the other OOUI components on the site, so that it's clear these are buttons, and clear when they are toggled on/off.

I've uploaded a set of plain screenshots to Google Drive.

Would we want to prioritise just the languages that WWT supports first?

• I don't think the groups need to be linked to anything. The documentation about these groups if we must, but I don't think that is necessary.
• Do we know the users' home wiki, like the one they signed up on? If yes then we can link to their Talk page from the user name.
• The wiki's names could link to their User page on that wiki.

I had a few ideas around this.

@ifried spotted a typo in one of the screenshots, here is the updated file.

@Samwilson and I did some digging and it turns out Chrome supports screenshots in multiple languages (its just a very complex process). We are trying to see if we can use SVG Translate to get these translated by our volunteers 😊

I was looking at T229714: Spike: Investigate Possible Errors for WWT [4 hours] and it isn't completely clear to me in which cases it is helpful to Contact Us. We could decide to always give them that option. From that point of view the language you suggested, "Error: Refresh or try again later. If the issue persists, contact us." sounds perfect. However, it is a bit awkward to have the whole sentence be a link, but, I do understand that we might need to do this for i18n reasons.

Full resolution and retina images on Google Drive.

I'd say 0.5em for the sides and 0.75em for the top and bottom.

Was this an intentional design decision? Should the placeholder behave like other widgets, that is disappear as soon as there is something entered?

In T237034#5809605, @Tchanders wrote:

The acceptance criteria don't quite match the screenshot in the description - could you confirm that we're working to the acceptance criteria rather than the screenshot?

In T239938#5790885, @ifried wrote:

I think it makes sense to show it at all times. There are other features that always display, regardless of whether they're available to the user (such as email options before email is confirmed), so we should follow the general standard of always displaying potential options in Preferences. Do you agree, @Prtksxna?

How about something like this:

Would this be easier if only the word 'contact' was the link?

In T238782#5774466, @dbarratt wrote:

@Prtksxna or @Niharika is "Edits using this IP" the "Public" IP edits or is it the "Total" edits from that IP (Public and Logged-in Users)?

@Niharika, based on the information on each page this how I am thinking of splitting the filters

In T240530#5749286, @Niharika wrote:

Let's go with the cross.

In T241371#5772539, @ifried wrote:

@Prtksxna What do you recommend as the updated language? Perhaps something like: "Hover over text to see contributions by the same author. Click to see the author and more details."

Thanks for tagging me @ifried :)

I didn't know how to force an API error so I switched off the Wifi to get a generic error, is that the same?

The IP column currently has four pieces of information:

• IP
• Number of edits by this user using the IP
• Total number of users using this IP
• Total number of edits using this IP

In T239938#5748742, @ifried wrote:

However, if we receive feedback that users are confused, we can change the placement of the message at a later date.

In T237299#5728988, @Niharika wrote:

Yep, that would be great. :)

In T238961#5729041, @aezell wrote:

With that in mind, what if we swap the order?

@Mooeypoo, I like your suggestion of keeping the effect the same but showing it only on hover. This will still tell the user if something isn't interact-able, even if it is after they've hovered on it.

I think we should add the PRU setting right before the Email confirmation label. I had a few thoughts around this:

1. If we add it right after Email confirmation we'll have to update the message in the yellow box. While this is doable, it groups this setting incorrectly with others that actually do depend on confirmation.
2. Since we only need the presence of the email for this setting to work, it is better for it to be closer to the Email (optional) label. As removing an email will actually disable this setting, it makes sense for it to be right after it.

Feel free to re-open if we need more assets.

Feel free to re-open in case we need to reassess this.

In T238961#5722380, @Samwilson wrote:

What should this page be called? Help:Reset_password?

In T237299#5685324, @Niharika wrote:

@Prtksxna We also talked about the sticky highlights showing up in the filters at one point. Are you still planning to add that in?

I think Special:Block would be better with placeholder text too. Any field that can take two types of inputs is confusing, the one in Special:Investigate can take a combination of both which makes it even more so.

In T237034#5705040, @Tchanders wrote:

@Prtksxna I notice the requirements have been updated since the patch, hence the discrepancies in some of the placeholder text found by @dom_walden in T237034#5696564. Should we correct these?

In T236702#5709718, @MusikAnimal wrote:

The diff size fades in only if it has a summary to go with it. This can seem a tiny bit weird, because at quick glance some popups having content that fades in, and others don't. Maybe it makes sense to fade in .mw-diff-bytes in addition/separate to the full summary? That might look a little weird, and also dirty up the code.

In T234710#5710566, @ifried wrote:

Also, @Prtksxna, I originally wrote that we should remove "API Error" in the acceptance criteria. However, I just updated it so that we keep the word "Error." I think it's good to be explicit about the fact that there's an error, so users understand why we're asking them to refresh the page or try again later. The only part that was confusing to some users, in my view, was the word "API."

In T238961#5700503, @Prtksxna wrote:

I think the system already has an error message that shows up, but I am not able to see it. Will update this ticket once I figure it out.

@Mooeypoo good idea. Here is what it looks like on the Create account page:

Without JS	With JS

In T234537#5700964, @Samwilson wrote:

But this isn't true for requireemail; password reset emails are sent even for unconfirmed email addresses.

In T238961#5698703, @ifried wrote:

@Prtksxna What do you recommend as the message we display for exceptions #1 and #2?

Thanks a ton for this @nettrom_WMF!

If we are getting the bytes changed from the same API call we can't completely de-couple it. From what I understand, if the API returns no edit summary then our tool doesn't show the bytes changed either, though I suppose we do have that information (could someone confirm this?).

I am not against hiding the form elements that aren't being used, but, as Volker pointed out, if we do do this we should make sure that the ARIA mappings are correct and we're using aria-expanded and aria-controls correctly. We'll also need to test with screen readers to make sure its working properly. You can read more at — https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

From the description:

@Prtksxna should we give an error indicator perhaps?

@Aklapper, my understanding is that the legal team doesn't have the resources to do #2 at the moment, and not having #1 is already causing some confusions (people emailing asking where the latest report is etc.)

@dbarratt you're right we should try to reduce the cognitive load on the user on this page, especially with the all the tables and highlights that they're about to see. I was thinking of a few ways to do this:

1. Remove the placeholder text from the Reason input. Most people who come to this page know what they're doing and wouldn't need help filling this out. (per your comment T237034#5672684)
2. Improve the text of the checkbox label so that we don't need the placeholder text any more. (I'll also explore the options that @Niharika pointed out in T237034#5672832)