Copying over something that @dom_walden noticed in T237299#5923827:

Currently, highlighting is based on cells matching exactly. For example, on Preliminary Check the "Date attached" is to the nearest second, so normally only one cell highlights at a time. Similarly UA strings need to match exactly.

Do we need to rethink this - particularly the timestamp being to the nearest second?

@Tchanders Anything here that @Prtksxna should weigh in on before we can talk about it in Estimation?

In T246294#5926253, @Tchanders wrote:

Copying over something that @dom_walden noticed in T237299#5923827:

Currently, highlighting is based on cells matching exactly. For example, on Preliminary Check the "Date attached" is to the nearest second, so normally only one cell highlights at a time. Similarly UA strings need to match exactly.

Do we need to rethink this - particularly the timestamp being to the nearest second?

I think it makes sense to highlight if the date is the same, ignoring the timestamp. Is that feasible?

I think parsing the date string should be OK. Not sure how that might work with localization though. Maybe moment.js has some helpers for this? I think it's already available in MW?

As for the UA and such, we could do something like a levenshtein comparison or use some other kind of fuzzy matching. Those are generally inexpensive on short enough strings.

From the description:

changing row heights when pin buttons appear and disappear

As we discussed, the buttons should appear only on the row currently being hovered. This will change the height of that row but will keep the overall height of the table the same as the user hovers over different rows.

In T246294#5927855, @Niharika wrote:

@Tchanders Anything here that @Prtksxna should weigh in on before we can talk about it in Estimation?

Yep, please let me know. I am happy to get on another call to see the behavior.

In T246294#5929539, @aezell wrote:

As for the UA and such, we could do something like a levenshtein comparison or use some other kind of fuzzy matching. Those are generally inexpensive on short enough strings.

This is great idea! A few users mentioned this in the usability tests too. They didn't particularly request full parsing, but just that close by version numbers could be highlighted together. With something like levenshtein we could set a low threshold (~5) to just pick up minor version changes. (See experiment using levenshtein)

In T246294#5929539, @aezell wrote:

I think parsing the date string should be OK. Not sure how that might work with localization though. Maybe moment.js has some helpers for this? I think it's already available in MW?

Yes, we can do this in MW, and choose whether to localise (we currently do). So, questions for @Prtksxna and @Niharika:

• Should we only display the date in the PreliminaryCheck results (not the time), as the mock-up does?
• Should we highlight cells together if they are the same date (never mind the time)?

If so, let's add those to the task description.

In T246294#5935603, @Prtksxna wrote:

From the description:

changing row heights when pin buttons appear and disappear

As we discussed, the buttons should appear only on the row currently being hovered. This will change the height of that row but will keep the overall height of the table the same as the user hovers over different rows.

@Prtksxna OK. I'll remove the bullet point about changing row heights from the task description, since it is addressed by the point about only showing pins on hover.

Re: fuzzy matching for the UA strings, could we make another task for that? I think there are more things to discuss. (Some things that spring to mind: matching thresholds; highlights covering different sets of rows (e.g. hovering on row1 might highlight row1 and row2, but hovering on row2 might highlight row1, row2, row3, row4, etc); whether Levenshtein distance is the best measure (e.g. things like 11.99999 being closer to 19.99999 than 12.00000, etc).)

Should we only display the date in the PreliminaryCheck results (not the time), as the mock-up does?

I think there's value in showing both the date and time. I talked to Prateek about this and he concurs.

Should we highlight cells together if they are the same date (never mind the time)?

Yes. Will add to the ticket.

Re: fuzzy matching for the UA strings, could we make another task for that? I think there are more things to discuss. (Some things that spring to mind: matching thresholds; highlights covering different sets of rows (e.g. hovering on row1 might highlight row1 and row2, but hovering on row2 might highlight row1, row2, row3, row4, etc); whether Levenshtein distance is the best measure (e.g. things like 11.99999 being closer to 19.99999 than 12.00000, etc).)

Yep, I'll make a follow-up task for that. I think it's a bit low priority for now. The logging and Timeline work needs to be done first.

Some more things to review after T240530: CU 2.0: Filtering from the data table in Compare tab:

• Are some of the table cells too cluttered now that they have up to 3 buttons?
• Is it confusing to see a mixture of enabled/disabled buttons on hover?
• Should the filter button be a different colour?

In T246294#6011664, @Tchanders wrote:

Some more things to review after T240530: CU 2.0: Filtering from the data table in Compare tab:

• Are some of the table cells too cluttered now that they have up to 3 buttons?

Yeah, things are looking a bit cluttered. Are there any cells that have 3 buttons at the moment, or will it only happen once we add the filter button?

• Is it confusing to see a mixture of enabled/disabled buttons on hover?

This would be the case for the IP columns, right?

• Should the filter button be a different colour?

The original idea (T240530) was for it to be red. But the interface is looking a bit bulky with the OOUI elements so we might need to revisit this.

Some things to consider:

• Should we stop showing wikis that are attached but have 0 edits? @cwylo could there be a case where someone would want to see this?
• Should we make "Show all IPs" and "Show all users" links instead of buttons so they don't look as heavy?

@Prtksxna In the Compare results table, after removing the blue highlight on hover (T249251), there may not be enough contrast between the background colour of the target's cell and the colour of the disabled "show all IPs/users" button:

In T246294#6035958, @Tchanders wrote:

@Prtksxna In the Compare results table, after removing the blue highlight on hover (T249251), there may not be enough contrast between the background colour of the target's cell and the colour of the disabled "show all IPs/users" button:

You're right, the contrast has reduced:

But since this is a disabled element I think we should be alright. I am considering making this cell's background white as well (after seeing T249255). What do you think?

In T246294#6021298, @Prtksxna wrote:

Some things to consider:

• Should we stop showing wikis that are attached but have 0 edits?

What does attached even mean? That they visited that wiki while logged in?
Is this useful information for CheckUsers?

In T246294#6135825, @Prtksxna wrote:

What does attached even mean? That they visited that wiki while logged in?
Is this useful information for CheckUsers?

Right, it's wikis you have "logged into" as you can see from:
https://meta.wikimedia.org/wiki/Special:CentralAuth
Effectively, it's wikis where a "local account" exists for your CentralAuth username.

I think Wikimedia has this configured in such a way that just visiting another wiki when logged into another one will auto log you into that wiki.

It may be more useful to only show attached wikis that have an edit count greater than zero, but I'm not sure on that. :)