Talk:Community health initiative/Interaction Timeline/Archive

Sockpuppets

I added a sockpuppet investigation example to the list. This is a significant use of this tool independent of harassment, but many harassment cases also involve abuse of sock accounts.

I understand that entering more than two usernames into the tool generates an N^2 complexity and longer reports, but being able to enter multiple names can help identify which interactions warrant closer examination. It would be nice to allow as many names as feasible, without over taxing the system. Alsee (talk) 08:34, 16 May 2017 (UTC)

Thanks Alsee for your idea. I'll make sure the ideas is brought to the the attention of the team. SPoore (WMF) (talk) 13:58, 16 May 2017 (UTC)

Yes, thank you for adding that new example. I'm curious if we'll be able to design and build a tool that allows for 3+ user names and effectively displays the information in a comprehensible interface. And I totally agree that this tool could be useful for sockpuppet investigations. Also, thank you for pointing out that the numbers in blue on the Edit Interaction Analyzer show who edited first. — Trevor Bolliger, WMF Product Manager 🗨 20:43, 16 May 2017 (UTC)

A viable option would be to show a lot of information for two users, and have reduced information for more than two users. It could either be one tool that drops to the simpler mode for more than two names, or have something separate that accepts more than two names. Alsee (talk) 10:20, 18 May 2017 (UTC)

That's a great idea — no need to complicate the two-user tool just for the use case of a three-user (or multi-user) tool. Another idea that's been suggested is a simple overview page that provides statistics about how 2+ users interact without showing any granular details — e.g. total number of overlap pages, talk page interactions, average time between interactions, etc. Maybe this page should be renamed 'User Interaction History tools. — Trevor Bolliger, WMF Product Manager 🗨 17:18, 18 May 2017 (UTC)

Maybe I can offer a little insight here via a recent case that came up at en:Wikipedia:Administrators' noticeboard/Incidents. I came upon a complaint that an editor was writing racist edit summaries. It was a relatively clear-cut case that didn't require any special tools, and another admin gave the accused editor a final warning. The interesting thing, however, was the complainant speculated that the abusive editor was a likely sock puppet but couldn't come up with a sock master. The topics edited were all related to Hungarian politics.

What I did was look at the abusive editor's most edited pages in the X-Tools edit counter. From there, I scanned the article histories to find editors that were indefinitely blocked for sock puppetry. I quickly noticed that one site banned editor had several CU-confirmed sock puppets active in the same articles as the suspected sock puppet. He also had an LTA case open that described his edits as "xenophobic and racist". This gave me a potential match and the confidence to keep going.

I found a sock puppet of the banned editor that had operated long enough to have a substantial edit history and compared this account to the abusive editor using the Editor Interaction Analyser. I was kind of lost, however, because I couldn't tell what POV, if any, these two editors were pushing. The next part was tediously clicking on diffs until I finally found two that were very, very similar. After setting that aside, I found a few repeated edit summaries that were shared among the suspected sock puppet and several CU-confirmed sock puppets. Based on this evidence, I blocked the suspected sock puppet.

If I had been alerted in the beginning that a CU-confirmed, site banned sock puppeteer was active in the same topics as the suspected sock puppet, that would have made this easier and faster. Finding the LTA case page linked from the site banned editor's SPI archive was also important. The part that sounds most useful to this investigation, however, is the ability to potentially match POV pushing between two accounts who operate in unfamiliar topics. Sorry this is so long, but I figured it might help if I went heavy on details. NinjaRobotPirate (talk) 04:11, 14 June 2017 (UTC)

Thank you, @NinjaRobotPirate: for sharing this example with us! I'm about to get started on some analysis on when EIA is used, what people love about it and what functionality we could add and you've given me a great head start.

Can you share a little more about what was "tedious" during this process? And could you share how you tracked your work so you didn't get lost in all the tabs?

It's great to see that this EIA is useful for sockpuppet identification, but I do want to state that we see the primary use case for the User Interaction History feature to be for user-to-user dispute resolution. Building better sockpuppet identification tools is important to us, and in our Anti-Harassment Tools backlog we have an iticket for T166813 — Robust sockpuppet identification tools. I'd highly recommend following that ticket. I'll also make it a point to contact you when we start that project. — Trevor Bolliger, WMF Product Manager 🗨 00:35, 15 June 2017 (UTC)

A few months ago, there was a case where someone used the EIA to help resolve a harassment complaint: link. I don't know if it's useful, but it's the first thing that came to mind when you mentioned user-to-user dispute resolution.

In my case, using the EIA was tedious mostly because I didn't know what I was looking for, just that I'd know it when it found it (for example, a frequent typo or misspelling). I don't know anything about Hungarian politics, so it was a pattern matching game. As far as tracking work, I'm more methodical than organized. Typically, I keep the EIA master report in one tab, then sequentially go down the timelines one at a time in a second tab. From the tab that contains the current timeline I'm looking at, I'll open several diffs in new tabs. If all this becomes cumbersome, I'll open a new browser window to separate the EIA stuff from my other tabs. Besides that, I may take notes, such as annotated diffs. I sometimes write these in an offline text editor. NinjaRobotPirate (talk) 03:17, 15 June 2017 (UTC)

@NinjaRobotPirate: Ah yes, I've read that case. Those are exactly the kinds of cases where we think our User Interaction History tool (which could be built on ∑'s EIA tool) could help admins or other community leaders most accurately understand the full relationship between two contributors without having to open dozens of tabs. I also think there's room for shared notes/annotations so multiple users could collaborate on a single case.

One final question — how did you learn about the EIA? Did you stumble upon, did someone send it to you? Is there a list/database of useful tools? — Trevor Bolliger, WMF Product Manager 🗨 19:01, 15 June 2017 (UTC)

The EIA is linked from individual cases at en:Wikipedia:Sockpuppet investigations. That's almost certainly where I found it. The only other place I know of where it's mentioned is en:Wikipedia:Tools, but it's unlikely I'd have remembered this if you hadn't asked. NinjaRobotPirate (talk) 19:32, 15 June 2017 (UTC)

Thank you! — Trevor Bolliger, WMF Product Manager 🗨 22:07, 15 June 2017 (UTC)

Regarding shared notes/annotations: I'm not sure what you had in mind, so disregard my comment if I misunderstood. It would almost certainly be a bad idea to add a content system inside the tool, to hold shared notes/annotations. We use wikipages for shared content. You don't want to reinvent that wheel. Any shared content outside of wikipages would need to duplicate a staggering range of non-obvious wikipage functionality. Instead you could give us things like copy-paste links with info embedded in the URL, or results we can copy/paste as wikitext, or even directly dump-to or modifing a wikipage. Alsee (talk) 12:43, 28 June 2017 (UTC)

@Alsee: Great points, and I 100% agree that we shouldn't reinvent the wheel on any project we build. We may focus on building export-to-wikitext tools as you suggested or something to synchronize a specific wiki page with a specific interaction query. We'll still want to be extremely conscious about how publicly visible these notes are, in some cases the notes might be best kept private for the sake of a user's privacy. — Trevor Bolliger, WMF Product Manager 🗨 16:23, 28 June 2017 (UTC)

Feedback summary, Oct 16

Hello everybody. I’ve re-read all the comments here and on the talk page on English Wikipedia and wanted to provide a summary of all feedback for the Interaction Timeline so far:

• Mention and Thanks notifications could be shown, as they are publicly visible in the wiki revision history or logs. However, sometimes they may not be helpful so we will want to consider a filter to toggle them on/off.
• We’re very likely going to need filters for any non-essential data we represent in the timeline. These would most likely be a series of checkboxes to toggle certain elements in the timeline on/off.
• The two-column layout could be used to monitor more than two users by bundling the others into one of the columns. (E.g. compare ‘Apples’ against ‘Bananas’+’Carrots’)
• One vertical line (Variation 3) vs two vertical lines (Variation 2) is preferable. No explicit support for Variation 2 yet.
• Showing the explicit time calculation between users is helpful — it avoids mental arithmetic.
• In-line diffs would be preferable to new tabs, but beware megadiffs and slow performance.
• Seeing the edit summary is important, as long as they don’t take up too much space.
• Some information could be hidden under mouse-over, but consider accessibility needs.
• The timeline could be to scale to better illustrate when/how people are overlapping in their interactions — maybe a log(interval) scale.
• We should explore bundling multiple successive edits by one user into a single ‘block’, but will need to make sure there is a way to see the details for each specific edit.
• Showing cross-wiki activity could be helpful, but it would need a filter to toggle on/off.
• Showing aggregated statistics above the timeline is helpful
• It could be helpful to…
  • …annotate the timeline, but there are also some concerns about necessity and complexity.
  • …export results from the tool to wikitext for easy on-wiki reporting.
  • …show edits made by the other users outside of their direct interaction, but would definitely need a filter toggle.
  • …color code or use icons to indicate reverts.
  • …filter certain namespaces out of the timeline.
  • …represent namespaces with different icons.
  • …highlight the different usernames with different colors.
• The UI should warn when a filter/toggle is enabled that is hiding certain information
• This is a utility tool — don’t add too much whitespace. Be cognizant of information density.
• If we built a solution that allow users to specify if they want their emails logged (and visible only to admins) then this data could be shown in the Timeline.

Did I miss anything or misrepresent any feedback? And keep the thoughts coming! — Trevor Bolliger, WMF Product Manager 🗨 22:17, 16 October 2017 (UTC)

3rd Draft Wireframes

Hi all, We made our 3rd round of wireframes. I made sure to incorporate community feedback like reducing the amount of whitespace. I'd love to what you think of the differences between wireframes? We also shortened the text across all of the wireframes.

We are looking for feedback :) One wireframe has summaries that say "summary: an addition" for an example, and for another removes "summary" and just says "an addition." Is this easy to read, does this come across as a summary or should we include the word 'summary'? What do you think of the different kinds of diffs we've included? Does one look better or is more readable than the other?

let me know :)

• 
  Interaction Timeline 3rd Draft WireFrames

--CSinders (WMF) (talk) 21:39, 31 October 2017 (UTC)

Test the alpha version of the Interaction Timeline

Our team is proud to announce that an alpha version of the Interaction Timeline is now available for testing! We wanted to get the tool in your hands so you can let us know if we're headed in the right direction.

The Interaction Timeline can be found at https://tools.wmflabs.org/interaction-timeline/. If you provide two usernames and a wiki, the Interaction Timeline will display a chronologic list of edits made by the two specified users on pages where both users have edited. For example, if User:A edits on Washington, Texas, and Kansas and User:B edits California, Texas, and Kansas the tool would only show their edits on Texas and Kansas.

Known limitations

• Due to current API limitations the tool only retrieves a maximum of 1,000 edits. This is our top priority to resolve. (T179702) The tool works like this:
  1. In the background, the tool retrieves the first 500 edits by both users from the provided start date (or first 500 edits of all time if no start date is provided.)
  2. In the background, the tool then generates a list of commonly-edited pages between the two users, from all time.
  3. On the timeline, the tool only displays the edits to the commonly-edited pages within the 1,000 edits that it already retrieved.
• Performance is not optimized, and there is no loading indicator to show when the tool is still working to generate the results.
• There is no error message when there are no results.
• The tool does not support IP address, only usernames.
• Typing in the date range only allows you to type one character at a time.

Examples to test

1. User:Test-apples and User:Test-bananas on test.wikipedia.org
   • Link to timeline: https://tools.wmflabs.org/interaction-timeline/?wiki=testwiki&user=Test-apples&user=Test-bananas
   • Scenario: Wikihounding. Bananas makes a bad edit, and Apples then follows them around to other pages they've edited.
2. User:Test-carrots and User:Test-durian on test.wikipedia.org
   • Link to query: https://tools.wmflabs.org/interaction-timeline/?wiki=testwiki&user=Test-carrots&user=Test-durian
   • Scenario: "He said, she said" dispute, likely boomerang. Durian criticises Carrots until Carrots snaps back. Durian then cleans up their trail and reports Carrots to ANI.
3. User:Derby pie and User:Sweets lover on test.wikipedia.org
4. User:Tinker toys and Baby rattle on test.wikipedia.org

Discussion topics

• For comparing disputes between two users, how does this two-column concept compare to other existing tools? (e.g. Edit Interaction Analyzer, Intertwined Contributions, Intersect Contributions. Special:Contributions, etc.)
• What information or functionality is missing that would make this tool more useful than your existing tools or workflows?

Thank you, and we sincerely look forward to your thoughts on our work, and your feedback on where to take it next. — Trevor Bolliger, WMF Product Manager 🗨 21:32, 13 November 2017 (UTC)

None of the test links work in Firefox. (They do work in Chrome.) But that's not important.

Over at EnWiki I suggested that you Explicitly calculate the ratio of how many edits are visible between the two tools.[1] I suspect no one did this. Select two actual editors with a significant number of edits. Bring up a page in each tool. Scroll the header-area off the top. Count how many entries are visible in each tool. Divide, and multiply by 100 to get a percent. Depending on the length of edit summaries, I can see as few as 4 entries in the Interaction_Timeline tool, and more typically 6 entries. In Edit Interaction Analyzer I can see about 30. Depending which way you look at the ratio, that is either 13% to 20% density for the new tool, or 500% to 750% density in the existing tool.

This is not a minor issue of whitespace styling. 500% to 750% is an entirely different planet. The new tool is designed like a twitter feed. We need a data-analysis-tool design. Alsee (talk) 21:21, 15 November 2017 (UTC)

@Alsee: We'll test in more browser/OS configurations. We did not calculate the percentages because we knew it had far less information density than we would like. We used off-the-shelf Bootstrap UI elements to build this very quickly. In phab:T180090 we will use Wikimedia branding and UI elements, which should standardize the font, text-size, and spacing of elements. For this alpha version we were 100% focused on getting the skeleton built. — Trevor Bolliger, WMF Product Manager 🗨 00:33, 16 November 2017 (UTC)

@Alsee: Hi! I'm the designer on this- and if you look at the wireframes above, that's more what the final tool will look like. We know there's a lot of white space in this prototype, a lot more than we intended. This is not the final look and feel of the tool- we were interested in getting a highly functioning and working prototype out the door. But, noted, there will be a lot less white space in the final version. Can ask, have you played around with the tool yet? What do you think of how it compares interactions between editors? What could be improved there?--CSinders (WMF) (talk) 00:48, 16 November 2017 (UTC)

CSinders (WMF), the wireframes look look like any significant difference in density. I didn't comment much beyond the raw density because I assume other functionality is being built... but ok. The current version isn't usable yet. I'll start in the context of the current Editor Interaction Analyzer. An established editor may have thousands, tens of thousands, or even hundreds of thousands of edits. The Analyzer narrows that down to pages where there are mutual edits (possibly hundreds of pages), and sorts them by shortest edit-interval between the users. If the interval is weeks or months, it's probably not relevant. Then I can start at the top, or at pages-of-interest, and pull up *just* the edits by those users on that page. They may have be dozens or hundreds of edits to the page, so I want to see as many edits at once as reasonably possible. Then I can try to understand what interaction, if any, there was on that page. Then I can check other pages they both edited.

The only thing the current tool has at the moment to help sift though all of the edits is the calendar. It shows all edits by all listed users, and it shows maybe 6 edits at a time. That may be less than 5 minutes. A busy editor can make a one or two dozen edits per hour, and an editor using AutoWikiBrowser might approach a thousand edits in a day. Showing 6 edits is like peeping through a straw, and there's nothing (yet) to filter relevant edits. In most cases it's hopeless to try to scroll through unfiltered edits a few at a time. Alsee (talk) 10:07, 16 November 2017 (UTC)

@Alsee: The Timeline only shows edits on pages where both users have edited for all time, but filters what is displayed on the Timeline based on the date range parameters. Here’s a hypothetical scenario:

• User:Apples edited the articles ‘Hawaii’ and ‘California’ in June 2017 and ‘Kentucky’ and ‘Florida’ in July 2017
• User:Bananas edited ‘Kansas’ in June 2017 and ‘California,’ ‘Kentucky,’ and ‘Montana’ in July 2017
• If you perform a query for User:Apples and User:Bananas for July 2017, you will see Apples’ edits to Kentucky and Banana’s edits to California and Kentucky.

After we have full date-range support (the 1,000 maximum edits limitation is very frustrating and is one of our top priorities to fix) the Timeline and the Analyzer will show the same data in different formats, because the tools are designed for two different workflows: The Analyzer is designed to be able to drill into the interactions one page at a time while the Timeline is designed to be able to follow interactions across pages. From many cases of harassment we’ve seen, conversations are not confined to one single page. Often, a conversation will begin on one talk page, carry to their user talk pages, and culminate on a noticeboard. The edits to the article pages themselves are also important pieces of information, especially in cases of edit wars or stalking.

I do share two big concerns as you:

1. The information density, which we will address in phab:T180090 in the next few weeks
2. The ability to sift out the ‘noise’ edits, which may clutter up the Timeline. We are planning on building filters to allow certain pages or namespaces to be hidden on the Timeline. This work will begin in January/February.--CSinders (WMF) (talk) 22:01, 16 November 2017 (UTC)

Alpha feedback

See also: w:en:Wikipedia talk:Community health initiative on English Wikipedia/Interaction Timeline#Alpha comments

• I wouldn't link to the generic tool until it works for most test cases. Instead, the link to the test example would work.
• Sticky headers for the username columns (link the usernames to actual user pages)
• I personally think it's more helpful to have a brace or bracket group five posts and show that they happened within the span of five minutes than it is to see the timestamps for each individual node
• It's hard to get a sense of the disagreement's substance without inline diffs. The edit summaries (nevertheless section headers) often won't be descriptive enough on their own to be particularly useful, so the reviewing editor is back to opening diffs manually in a bunch of tabs.

smaller suggestions

• username search should support lowercase usernames (czar => Czar)

Ideally, the search would be case-agnostic and show even cZAr => Czar

• Ideally, the tool would autofill whatever project in which the first listed user participates most, or shows the user's most active sites atop the list of others—saves a few clicks

It'd be nice if "enwp" and "English Wikipedia" both corrected to en.wikipedia.org

czar 22:47, 15 November 2017 (UTC)

• Thank you for the feedback, Czar. Once we complete Phab:T179702 (hopefully next week!) the tool will support all cases better. (I also think the loading indicator and error messages will help, since long queries can take several seconds to run. We'll optimize performance once we're sure this concept holds water.)
• We'll build a sticky header in phab:T180245 which will hopefully be built before the end of the year. Same for in-line diffs (phab:T180417).
• The first-character case sensitivity and illogical ordering for wikis is driving me mad too. We'll address those in phab:T180084 and phab:T180087 but I love your suggestion to automatically fill the wiki field based on where they edit. Or hey — maybe the tool could show all edits across all wikis (but that's a much bigger undertaking. Maybe later if this tool is successfully useful!) — Trevor Bolliger, WMF Product Manager 🗨 00:53, 16 November 2017 (UTC)

Feedback summary, Nov 22

Hello all! Here is an abridged summary of all the feedback received since I posted the last update:

• Common feedback, and our top prioritizes to address:
  • The Information density is bad, there is too much whitespace, and the tool requires too much scrolling. This will be one of our top priorities to address, and we plan to show progress in the next two weeks. (phab:T180090)
  • The limit of 500 edits per user makes the tool virtually unusable for many scenarios. (phab:T179702)
  • The username field should be case agnostic. (phab:T180084)
  • The wiki field is obnoxious. It could autofill based on where ever the users interact the most, or the logic should be improved to suggest enwiki first. (phab:T180087)

• Feedback about prioritization:
  • Support for IP users is needed. (phab:T180653)
  • In-line diffs are needed. (phab:T180417)
  • Display error messages if there are no interactions to display. Right now the tool just looks broken. (phab:T180083 and we'll build a loading indicator in phab:T180072 in the next few weeks)

• Other new feature requests:
  • Make the usernames sticky as you scroll. (phab:T180245)
  • Group edits by timespan to make it easier to identify incidents of rapid reply
  • Combine successive diffs by the same user, but allow the option to see each edit individually.
  • Build a log style of this tool
  • Support IP CIDR ranges
  • Minor edits should be indicated (phab:T180415) and should be filterable.
  • We will eventually need support for more than 2 users
  • We may want a filter to show edits from other people to both users’ talk pages
  • We will want to display log items on the Timeline
  • Admins should be able to see deleted revisions
  • It would be helpful to allow for annotations of the Timeline that could be shared with other users.
  • It would be helpful to compare interactions across multiple wikis simultaneously
  • Add userlinks somewhere in the header (phab:T180722)
  • Display dates in country-neutral manner (phab:T180725)
  • If an edit summary is revdeleted, it should show as revdeleted, not blank. (phab:T180829)

• Defects to investigate/fix:
  • A bug was found that made some interactions show as entirely blank. This may be a result of the 500 limitation, but we’ll still investigate it and fix if needed.
  • We received a bug report about the tool not showing all namespaces. We’ll look into it. (phab:T180647)

Many of the suggestions that do not have tickets yet are also documented on the parent Phabricator task phab:T179607. Let me know if I misstated or missed anything. New feedback welcome, as always! I'll post an update around December 6, when we hope to have a next version ready to test.

Thank you! — Trevor Bolliger, WMF Product Manager 🗨 23:46, 22 November 2017 (UTC)

Filtering edits marked as minor is probably pretty worthless here. It's controlled by the user, and isn't particularly reliable in general. I especially wouldn't rely on it when investigating user interactions. I guess there's no reason not to include it, other than the clutter of an extra control. Alsee (talk) 14:49, 25 November 2017 (UTC)

Where to find the code?

I did not find any information where to get the code if I wanted to contribute? Also it seems like I'm supposed to check the dependencies on phab:T166807 if I wanted to know what I could contribute to? Could that be made clearer? --AKlapper (WMF) (talk) 20:53, 1 December 2017 (UTC)

Hi Andre, the github repo can be found at https://github.com/wikimedia/InteractionTimeline — We'll soon be adding a header and footer to the tool with more links on how to contribute or report a bug. — Trevor Bolliger, WMF Product Manager 🗨 21:58, 1 December 2017 (UTC)

Alsee feedback Jan16

1. When scrolling to the bottom, the pulsing wait-icon can cause the entire page to badly bounce up and down.
2. Retrieval/display of edits is extremely slow. The progress on retrival often dies completely.
3. The "(time) between interactions" is missing when that interval crosses the date-line. (For example an interval from 11:55 PM to 12:05 AM fails to show "10 minutes between interactions".)
4. The displayed times do not match the times shown in diffs, page history, and elsewhere:
   • The timeline uses AM/PM time format, but all of our tools and pages use 24-hour time format. AM/PM is meaningless and unhelpful in a purely online universe touching all timezones.
   • The times on the interaction-timeline are all off by several hours. I'm guessing that you're trying to apply a local timezone offset? I want the same time-value that I get on the diff and history screens.
5. The username-heading should probably provide the standard set of links to user page, user_talk, and contributions.

Alsee (talk) 00:29, 17 January 2018 (UTC)

Hi Alsee! Thanks for the feedback. We were stalled a little on Timeline development due to limited developer availability and the holidays, but we're back at it now. The slowness is definitely the biggest problem. We were attempting to use existing APIs for this tool but the queries are too heavy so we're building our own. This is our top priority. (phab:T184146) The "Time between interactions" is intentionally missing when the delay is longer than 24 hours. We're going to add a background border around each calendar date as a stronger visual indication. (phab:T181568, see an early mockup here) We want to add important userlinks soon. (phab:T180722)

As for timestamps: yes, we're converting the UTC timestamps to local AM/PM time. I see both time systems (12 vs 24-hour) as being useful, as well as a timezone offset (local vs UTC) — they can be useful in understanding the sequence of events. Do you think this should be a toggle in the tool?

Thanks for bringing this to our attention. We'll post a bigger announcement here and elsewhere when this "V1" of the Timeline is ready. — Trevor Bolliger, WMF Product Manager 🗨 01:33, 17 January 2018 (UTC)

Trevor Bolliger you misunderstood the bug I was reporting. "Time between interactions" has a midnight bug. The tool fails to report a 10 minute interaction when it happens to span the arbitrary midnight point of the arbitrary timezone. A 10 minute interaction which begins at 23:55, December 31 2017 will cross a calendar day, cross a calendar month, cross a calendar year, and it should still show "10 minutes between interactions".

The 'Time between interactions' is intentionally missing when the delay is longer than 24 hours". Given the page layout, you're just displaying whitespace instead. It's not a big deal, but showing "X days" could be relevant in many cases and I'd be inclined to show X months or even X years for simple consistency.

"we're converting the UTC timestamps to local AM/PM time... Do you think this should be a toggle in the tool?" No. Do not use AM/PM and do not pull a localtime offset from the browser. You can pull a timezone offset from the user's preferences setting, however I expect most editors keep this pref set to zero offset. An inconsistent AM/PM format is minor-bad, and incoherent timestamps is very very bad.

First consider an editor working in isolation: The smallest issue is that comparing AM/PM values in this tool with the 24 hour values shown anywhere else is an extra cognitive load. Timezone offsets which are invisibly-incoherent can lead to major confusion. Once the editor does understand that the offsets are incoherent and why, it is a major headache trying to compare timestamps with incoherent offsets.

The more serious problem is communication between editors. Consider someone copy-pasting evidence from this tool into a discussion. That editor could be in any timezone on the planet. Your tool would be applying an effectively random timezone offset to all of the time values. This means no one else can read the timestamps unless they can decypher what offset you applied. That's a major communication problem. (You're also implicitly leaking the user's local timezone info.) I once tried setting my timezone in userprefs. It was a major headache. It altered the timestamps I was seeing on history pages and elsewhere. I couldn't read/use the timestamps posted in discussions by anyone else. I set my pref time offset back to zero. Alsee (talk) 08:26, 27 January 2018 (UTC)

@Alsee: Ahh, thank you! Gotcha. I've created phab:T186043 for the midnight defect, and have created phab:T186042 for the UTC and 24-hour changes. They should be simple changes to make and we'll get to them soon. Thank you for clarifying and explaining the issues to me — I appreciate it and I agree that this tool should mirror the on-wiki experiences and ecosystem when appropriate.

We're going to hold off on displaying N days, N weeks, etc for now until we've added the background border. But we may add it back if we find it is a better, stronger indication. — Trevor Bolliger, WMF Product Manager 🗨 19:53, 30 January 2018 (UTC)

Trevor Bolliger, WMF Product Manager thanx for putting that all on the to-do list!

There's something else I wanted to toss out there. I wouldn't call it an objection, but the plan to put a background border around dates kind of itches at me. Most of the world operates on (roughly) some kind of 9-to-5 schedule. In the offline world it is expected that things firmly and naturally divide into "days". However Wikipedia is a 24-hour officespace. Not only is "midnight" an arbitrary point, every hour is "midnight" somewhere. If you look almost anywhere on Wikipedia (i.e. article histories or user contributions) there's no division into days. It's just a running series of timestamps.

The plan to add a background border for days seems to be a result of the layout, because the date appears once on the left. I can see motivations for that design. There's the common offline expectation that things divide into days, you avoid redundant date value on each timestamp, and you make the time shorter and easier absorb. On the other hand any space savings is illusory. Spitting off the date merely results in a column of whitespace on the left. It also differs from the standardized timestamps. Notably, to copy-paste a timestamp you have to copy the two parts separately then paste them together. I'm not saying the current design is wrong, but what do you think about just putting a standard timestamp (23:59, 31 December 2017‎) in the center? I mean putting it were the blue/green circles currently are, so that both user's timestamps align in one vertical column? It could optionally have the blue/green box if you want to keep an emphasis on who's timestamp it is. Alsee (talk) 08:43, 31 January 2018 (UTC)

@Alsee: Correct that the Wikimedia community is global so a 9-5 perspective is unhelpful. What we've found looking at some real-world examples on the current design of the Interaction Timeline is that long never-ending lists are tricky to read and would benefit for some breaks into logical chunks. We considered adding visual breaks if the gap between interactions is longer than, say, 6 hours but ultimately went with calendar date, as that information is already being displayed. — Trevor Bolliger, WMF Product Manager 🗨 19:29, 31 January 2018 (UTC)

Relaxed constraints to detect sockpuppets by correlation

Just an idea, what about adding an option to relax the constraint on users? Now you only try to detect interactions between two users, but when you have candidate articles then you can start to test which other users correlates with the user interactions in the same timeframe. A simple solution would be to simply bin contributions to see if someone tend to contribute in a pattern that correlates.

It is important to make it very clear that correlation isn't causation, and that correlation will emerge if someone tries to be helpful. — Jeblad 21:51, 22 January 2018 (UTC)

We decided to only design the timeline for two users to optimize for a single use case: a report of incivility between two users. We'll look into supporting multiple users later, once we're confident we've built a useful tool for 2 user interactions. — Trevor Bolliger, WMF Product Manager 🗨 23:26, 22 January 2018 (UTC)

Didn't work

I tried using this tool to compare the editing between highly active editors for a period of two months. The screen got all twitchy and didn't really produce the results that I expected. Best Regards, Barbara (WVS) (talk) 09:30, 6 February 2018 (UTC)

@Barbara (WVS): Sorry about that, we're still developing this Timeline so it is buggy and incomplete. We hope to have a stable and performant version ready by the end of February. — Trevor Bolliger, WMF Product Manager 🗨 20:13, 6 February 2018 (UTC)

Feedback

Just some random notes… — Jeblad 00:04, 12 February 2018 (UTC)

1. There should be some kind of throttling on how close edits are on two different pages. If a common page isn't edited close enough in time it probably isn't important enough to consider.
2. There should be some kind of override of the throttling on pages where two users name each other. Those pages should be considered even if the edits are more distant in time.
3. There should be some kind of override of the throttling on pages where a user has provided a major part of content. Such pages are sometimes used as battleground where a user removes contributions from another user. This should probably trigger a mark of the edit as "possible contentious". (Such removal is difficult to detect, but it is possible to use a method similar to mw:User:Jeblad/Detecting text segments with a convolving hash. This problem is slightly different. Sum a digest from each revision, for each of the users, and then check the cosine divergence. If the number is high, then one of the users tries to undo the other users work.)
4. There should be some kind of override of the throttling on pages where the sentiment is changing from one users contribution to another users contribution, thereby changing the interpretation of the facts on the page. This is often an indication of a disagreement over the page, and thus edit warring. This should probably trigger a mark of the edit as "possible contentious".
5. Edits that trigger an edit filter should probably be marked as such.
6. Bad words should probably trigger a mark, even if bad words can be very hard to detect in some languages. My favourite examples are combinations of animals and genitalia in the Norwegian dialect from Nordland, like "måspeis" or "dick of a seagull". It is a very harsh remark that tags a person as "braggy with no ability to do what he say". Another example is "hæstpeis" or "dick of a horse", which some may take as a compliment. Add to this that some users in the communities can have a somewhat fragile (explosive) personality, then interpretation of such constructs (especially on the intended interpretation) can be very difficult. Another example, it is perhaps rather well-known now that the Norwegian expression "drittsekk" can be translated into "bag of shit", but the Norwegian word is pretty harmless while the interpretation in England is rather harsh.
7. Interactions on subject pages should be merged, yet it should be possible to inspect individual edits. Interactions on talk pages should be merged if they are within the same thread.

@Jeblad: Thank you for this feedback. I agree that sometimes there are pages that should not display on the timeline — if there's too much 'chatter' on these pages, if the amount of time between edits is long, or some other reason. Our thoughts are to give users the ability to hide all edits from a specific page on the Timeline, or to select the date range of intersecting pages.

I would agree that edits that trigger a filter should be indicated as such, and we also want to include log entries. I disagree that we should highlight identifiable curse words — it's complicated to build and there will always be false positives and false negatives.

We've considered merging the boxes for multiple successive edits to the same page — either for the same user or for the different users. It's a nice idea, and I hope we can explore it more in V2. We are nearly complete with V1 (phab:T179607) and will wait to see what works and what doesn't work before defining V2. — Trevor Bolliger, WMF Product Manager 🗨 23:31, 13 February 2018 (UTC)

@TBolliger (WMF): As I said in point 6, detection of bad words are difficult to detect. ;) — Jeblad 23:40, 13 February 2018 (UTC)

Update, February 14 2018

Hi all!

Just a quick note that we are on track to have a stable version of the Timeline completed by March 1, 2018. I'll post an update here when our work is complete and the tool is ready to use. Thank you! — Trevor Bolliger, WMF Product Manager 🗨 22:05, 14 February 2018 (UTC)