@dbarratt — is this necessary for Sprint 15? Or can we drop it back to the backlog?

This logic may have some problems: what if User:Apples is editing the Donald Duck article in July 2015. User:Bananas registers in August 2015 and begins editing Donald Duck. The edits from July would not display, correct? I'm not saying this is a deal breaker, just something to take into consideration.

Edit: It looks like the workaround would be to manually set the start date. And since we're placing a default start date, my concern above might not be an issue....

In T187406#3974165, @TBolliger wrote:

@dbarratt — is this necessary for Sprint 15? Or can we drop it back to the backlog?

@dmaza mentioned in sprint planning that he was planning on building this into T185459, but I wanted to create a separate ticket for tracking/discussion purposes.

Also, this ticket doesn't strictly depend on T185459, we could lookup the user's oldest revisions first, then execute the current logic (or feed that date into T185459).

This logic may have some problems: what if User:Apples is editing the Donald Duck article in July 2015. User:Bananas registers in August 2015 and begins editing Donald Duck. The edits from July would not display, correct? I'm not saying this is a deal breaker, just something to take into consideration.

That's true, that could happen, but if you cared, you could always set the Start Date to July 2015 and then they would show up. We could also implement a reverse-paging (it would have a "Show More" button at the top that would load edits before what you are seeing).

More likely, User:Apples edited Donald Duck in 2008. :P

We'll have to have some sort of visual indication of what is happening, and allow users to set the date range back. Reverse paging could work, but will require adding a new UI element. What do you think of populating the 'Start date' field for the user? That way the input boxes match what is displayed on the timeline.

In T187406#3974254, @TBolliger wrote:

What do you think of populating the 'Start date' field for the user? That way the input boxes match what is displayed on the timeline.

That works for me. It's what @dmaza and I suggested to @SPoore in sprint planning who had the same concern. I think this would also allow us to skip adding reverse paging, because the user can just modify the start date.

In T187406#3974258, @dbarratt wrote:

In T187406#3974254, @TBolliger wrote:

What do you think of populating the 'Start date' field for the user? That way the input boxes match what is displayed on the timeline.

That works for me. It's what @dmaza and I suggested to @SPoore in sprint planning who had the same concern. I think this would also allow us to skip adding reverse paging, because the user can just modify the start date.

OK, I must've been jujitsuing other tickets or emails during that conversation. Sounds good to me.

If the shorter user's first edit is on 2018-02-14 at 20:00 then the start date would be set to 2018-02-14 at 00:00. This would only happen if the timeline user does not specify a startDate.

I never said first edit. I was saying by registration date. First edit means an extra call for each user to the revisions table (which is extremely large).

In T187406#3974432, @dmaza wrote:

I never said first edit. I was saying by registration date. First edit means an extra call for each user to the revisions table (which is extremely large).

I know. But there's no registration date for anonymous users... should it be consistent or is it ok if it's not? I could always get it with the API and then feed it to the endpoint if that is faster/easier.

• If a user does not provide a start date, generate the start date based on the most recent first interaction edit of the two users that displays on the timeline.
• The start date should be the calendar date before the first edit. (24 hours before)
• The Start Date input box should be populated with the value.

For example, if looking at User:Apples and User:Bananas. If User:Apples' first edit is January 5, 2017 and User:Bananas' first edit it on February 13, 2018 (regardless of the hour), the start date should be February 12, 2018 at 00:01 (midnight). The 'Start Date' input box should be populated with 2018-02-12

An in-depth example:

In this scenario, the users are making no other edits other than these listed here:

• Apples registers before 2016
• Bananas registers before 2016
• Apples edits Washington on January 5, 2016
• Apples edits Washington on February 5, 2016
• Apples edits Washington on March 5, 2016
• Bananas edits California on April 5, 2016
• Apples edits Colorado on May 5, 2016
• Bananas edits Colorado on June 5, 2016
• Apples edits Washington on July 5, 2016
• Bananas edits Washington on August 5, 2016
• Bananas edits California on September 5, 2016
• Apples edits Washington on October 5, 2016

The timeline should populate the start date at June 4, 2016 and show these edits:

• Bananas edits Colorado on June 5, 2016
• Apples edits Washington on July 5, 2016
• Bananas edits Washington on August 5, 2016
• Apples edits Washington on October 5, 2016

In T187406#3979623, @TBolliger wrote:

February 12, 2018 at 00:01 (midnight).

Midnight is 00:00 :)

@TBolliger: I don't really understand this task. When someone loads the Interaction Timeline, there are no users specified, so there's no way to know the date of registration or first edit. That's why I proposed setting the default to today - 1 year. The alternative would be to wait until the user has entered 2 users and try to fill in the start date then, but having the page alter the form data at the same time that the user is filling out the form is weird and unexpected behavior (and could potentially overwrite the user's input if it takes more than a second or so to get the API response).

David and/or Dayllan — please refresh my memory if I'm incorrect. :)

From what I remember at standup a few weeks ago we discussed this possibility and David/Dayllan believed this would be very fast to identify the first revision and populate the field.

But you're right — we'll want to be sure this isn't interruptive for people who want to fill in the parameters sequentially.

If we're just using the first revision date, there's no point in updating the UI to reflect this. It should just be an internal optimization (and probably handled on the API side). Setting the start date while the user is filling out the form is just overkill and potentially will cause problems. Clearly users can't "interact" prior to one of them first editing, so it should be fine just to leave the start date blank for those cases.

TBH I've been going back and forth with the usability of this.

The idea is to remove "irrelevant" edits from the timeline if no date filter is specified, for example: Apples & Bananas (both edit San Francisco page)
Apples has made multiple edits to the SF page since 2010 and Bananas made an edit last month. In this particular scenario we will have a few pages of only Apples's edits showing up before we get to an edit from Bananas. With this change, we'll see Apples's edits only 24hs prior to Bananas first edit.

I agree with not populating the start date and instead adding a message explaining what is being displayed

OK, we can add a new UI element. I'm sure David can find something in library. :-)

In T187406#4025680, @kaldari wrote:

Setting the start date while the user is filling out the form is just overkill and potentially will cause problems.

if I have two separate properties in the state object, then it wouldn't interfere with user input. I would just check to see if the field is focused, or the user has provided a start date before using the "internal" start date. I guess there is a possability that I could set it a split second before you click on it, which would be frustrating. However.. I think I might have a better idea....

In T187406#4025695, @dmaza wrote:

I agree with not populating the start date and instead adding a message explaining what is being displayed

I was thinking of changing the placeholder text from the default YYYY-MM-DD to whatever the startDate returned from the API is. This way it doesn't interfere with user input (even if it happens a second before clicking in the field) and it's just a subtle indicator that the start date is internally set, if you remove the one you set, it will go back to the placeholder text (which is what the API is doing). @TBolliger What do you think? The only downside to this strategy would be that you can't manually adjust the text without typing in the date again, however, when you click on the start date, should it open the calendar to the month of the set start date or to the current month as it does now?

Also.. I think for consistencies sake, the end date's placeholder would change to today's date.

Or do you think we need something more explicit? if so then I'd probably go with something like the blue info message box... but that kinda feels overused. I think since we're between not needing a message at all on one side (@kaldari) and having an explicit message on the other (@dmaza), I would prefer having something subtle that doesn't interfere with user input. :)

I think we're overthinking this. IMO, the only change that is needed is:

• If no start date is supplied by the user, have the API query begin at the user registration date of the newer user.

Otherwise, you end up getting results like: https://tools.wmflabs.org/interaction-timeline/?wiki=enwiki&user=Kaldari&user=Funcrunch, i.e. you have to scroll through hundreds of edits by me before you see any actual interactions.

I don't think we need to do anything with the UI, as this behavior seems intuitive to me. I wouldn't expect my 10 years of previous edits before Funcrunch joined Wikipedia to be considered "interaction".

If no start date is supplied by the user, have the API query begin at the user registration date of the newer user.

This is what we are doing (WIP) but using the first edit in common pages instead of the registration date.

I don't think we need to do anything with the UI, as this behavior seems intuitive to me. I wouldn't expect my 10 years of previous edits before Funcrunch joined Wikipedia to be considered "interaction".

Message or not, it should be explained somewhere how it works.. even if it is on the tool's wiki page.

Modifying user's input might be confusing, +1 for not updating the form

In T187406#4025866, @dmaza wrote:

Modifying user's input might be confusing, +1 for not updating the form

placeholder !== user input

but no UI changes is easier on me. :)

Message or not, it should be explained somewhere how it works.. even if it is on the tool's wiki page.

True.

We discussed this, including Sydney and Caroline, in a few meetings. I should've documented the discussion here. We prefer this ticket over T184147 because we want the timeline to be both performant (which the API gives us) and we want the Timeline to show content in both columns on load.

There are some valid use cases to see one persons' edits before the second created their account. (e.g. sockpuppetry, creating a troll account just to harass, etc.) This won't be the common use case — we anticipate the most common use case will be to look at a month/week/day — so we don't need to overengineer our solution.

Here's my product requirement: It should be possible to see all edits on overlapping pages via the Timeline UI, regardless of registration date. This can be accomplished via:

1. Leaving the startdate input blank but allowing users to manually select a startdate before both users' registration.
2. David's proposal of altering the the placeholder in the startdate input (my most preferred solution)
3. A new UI element at the top of the timeline that says "see all edits" (least preferred solution)

UI

David's proposal of altering the the placeholder in the startdate input (my most preferred solution)

IMO changing a placeholder is as not visually relevant.

Leaving the startdate input blank but allowing users to manually select a startdate before both users' registration.

This is what I would expect if I'm using a form to filter/search and get no results or maybe an alert. Usually what you get is no results

API

If no start date is provided. Should the behavior change if the user sets an end date? And what happens if they set an end date before the generated start date?
Right now if the end date falls before the generated start date I don't set a start date. This can result in a "no results" interaction if it just happens that the generated start date is very close to the selected end date.

My suggestion

I suggest that we pick the simpler, less complicated UI/Behavior which in my opinion is:

• Don't change the UI, explain how it works in the project wiki page
• if start date is not provided, generate one based on the first revisions in common pages from the users (<-done). If end date is provided and it falls before the generated start date, ignore the generated start date

In T187406#4032424, @dmaza wrote:

UI

David's proposal of altering the the placeholder in the startdate input (my most preferred solution)

IMO changing a placeholder is as not visually relevant.

Leaving the startdate input blank but allowing users to manually select a startdate before both users' registration.

This is what I would expect if I'm using a form to filter/search and get no results or maybe an alert. Usually what you get is no results

These two things are not mutually exclusive. Changing the placeholder text would still leave the form field blank.

API

If no start date is provided. Should the behavior change if the user sets an end date? And what happens if they set an end date before the generated start date?
Right now if the end date falls before the generated start date I don't set a start date. This can result in a "no results" interaction if it just happens that the generated start date is very close to the selected end date.

I think this should throw an error, because technically, as @kaldari pointed out, anything before the generated start date is irrelevant. This actually would be clear if the placeholder is updated, you'd be able to see that you set the end date before the start date.

Regardless, I will need you to return the startDate (whatever is used) from the API because if there are no results, it should still be communicated that the startDate is what it is.

• Don't change the UI, explain how it works in the project wiki page

That expects people to read it. Critical information needs to be in the UI. The best UI's do not need a manual, in other words: Don't Make Me Think™. I don't think it needs to be overt, but adding more of an explanation in the wiki is fine, I just don't expect anyone to read it.

If end date is provided and it falls before the generated start date, ignore the generated start date

If the behavior changes, then the UI needs to reflect the change of behavior.

I think there are several fine solutions, each with their pros and cons, and we're just waxing philosophical at this point.

Let's finish and ship whatever is the least amount of effort to finish and move on to blocking tools.

These two things are not mutually exclusive. Changing the placeholder text would still leave the form field blank.

Exactly why I say it is not visually relevant IMO

I think this should throw an error, because technically, as @kaldari pointed out, anything before the generated start date is irrelevant. This actually would be clear if the placeholder is updated, you'd be able to see that you set the end date before the start date.
Regardless, I will need you to return the startDate (whatever is used) from the API because if there are no results, it should still be communicated that the startDate is what it is.

I don't agree. Revisions before the startdate are relevant in certain cases

(e.g. sockpuppetry, creating a troll account just to harass, etc.) > Trevor said

The generated start date is part of the business logic of the API, it should be clear how it works and how we get it but it should not come back from the API.
If we are gonna return the params we use we might as well return the "common" pages between the users and whatever else we use to get the interaction.

@TBolliger Less amount of effort is what is currently in Code Review. And it works as my suggested solution in my previous comment

@TBolliger Less amount of effort is what is currently in Code Review. And it works as my suggested solution in my previous comment

Let's go with this. 👍