If we do this we should also remove the no startDate logic from the API. However, the requirement for a startDate should only be on the UI.

This is basically what I was after with T186087, minus the dates requirement. It is probably rare, but I do envision some cases where you would want all-time results. For instance, an ArbCom case around conduct between two users (usually if the issue makes it to ArbCom, it's been going on for a long time). Requiring dates still isn't that bad though, just a few more clicks to get what you want.

Either way, I would stress avoiding unnecessary database load by assuming they want all-time results, which as you say is unhelpful in most cases. Especially with prolific users who have been around for a long time, you might run into queries timing out, or hogging up your database quota. So requiring dates or manual submission -- either is fine in my opinion.

If you do go the route of requiring dates, you might consider providing sensible defaults when the tool is first loaded (past year, perhaps).

If we do this we should also remove the no startDate logic from the API. However, the requirement for a startDate should only be on the UI.

yes

If you do go the route of requiring dates, you might consider providing sensible defaults when the tool is first loaded (past year, perhaps).

Is it safe to assume that if you are resolving an issue it is likely that you are interested in recent revisions and not very very old edits?
Regardless, there is no harm on a sensible start date

In T189847#4057117, @dmaza wrote:

Is it safe to assume that if you are resolving an issue it is likely that you are interested in recent revisions and not very very old edits?
Regardless, there is no harm on a sensible start date

In the sense of edit warring, recent (past week?) makes the most sense, but for things like sockpuppetry and ongoing harassment you might want a longer range. Hard to say! I guess one month might be a happy medium.

I know this further complicates things... but what if the edits were shown in reverse chronological order? That'd mimik Special:Contributions and revision histories, and you'd see right upfront how bad things became without having to scroll. Maybe an option to switch the ordering?

In T189847#4057320, @MusikAnimal wrote:

In T189847#4057117, @dmaza wrote:

Is it safe to assume that if you are resolving an issue it is likely that you are interested in recent revisions and not very very old edits?
Regardless, there is no harm on a sensible start date

In the sense of edit warring, recent (past week?) makes the most sense, but for things like sockpuppetry and ongoing harassment you might want a longer range. Hard to say! I guess one month might be a happy medium.

I think one month is the best smart default.

I know this further complicates things... but what if the edits were shown in reverse chronological order? That'd mimik Special:Contributions and revision histories, and you'd see right upfront how bad things became without having to scroll. Maybe an option to switch the ordering?

That's true, but I think the chronologic order provides the value of understanding the sequence of events (in utterly simplistic terms: who did a bad thing first?) I do support the idea of giving users an option to switch reverse/chronological depending on their preference and use case, but that should be another ticket.

@TBolliger @MusikAnimal T189907: Add option to switch the order of revisions

I still think adding a "Submit" button makes most sense.

The Timeline displays an error message until 2 users, a wiki, and a start date are provided.

That sounds confusing to me.

In T189847#4057731, @Niharika wrote:

I still think adding a "Submit" button makes most sense.

The Timeline displays an error message until 2 users, a wiki, and a start date are provided.

That sounds confusing to me.

That's what we do already:
https://tools.wmflabs.org/interaction-timeline/

In T189847#4057733, @dbarratt wrote:

In T189847#4057731, @Niharika wrote:

I still think adding a "Submit" button makes most sense.

The Timeline displays an error message until 2 users, a wiki, and a start date are provided.

That sounds confusing to me.

That's what we do already:
https://tools.wmflabs.org/interaction-timeline/

Whoops. I missed that. I do still think it's confusing. I cannot think of another website which makes me fill a form but starts giving me results before I've finished filling it, which is what we're doing here.
Adding a submit button is only gonna make things easier on the technical side, I imagine.

In T189847#4057738, @Niharika wrote:

Whoops. I missed that. I do still think it's confusing. I cannot think of another website which makes me fill a form but starts giving me results before I've finished filling it, which is what we're doing here.
Adding a submit button is only gonna make things easier on the technical side, I imagine.

meh it's not difficult to cancel the request when the query changes (we already do this).

I think of submission as committing a state (i.e. saving something), but here we aren't saving anything.

If you are on Google it doesn't even wait for you to finish typing before it executes the query (and cancels the in progress queries as you continue typing).

I cannot think of another website which makes me fill a form but starts giving me results before I've finished filling it, which is what we're doing here.

Pageviews Analysis, but the queries it runs are very fast. My complaints here were more about the technical side. Any heavy query probably shouldn't run unless we ask for it, not just for the user experience but also so you don't hog up your quota, and put load on the database servers for data people didn't ask for, etc. I mean that in a very kind way, not criticizing the design or user experience, it's just something that's not unhelpful to consider :)

it's not difficult to cancel the request when the query changes (we already do this).

Are you also killing the query that's running?

At any rate requiring a date range would address the technical issue, if you call it an issue :)

In T189847#4057806, @MusikAnimal wrote:

Are you also killing the query that's running?

🤷
From the UI, the whole request is killed. I can't remember if killing a request in PHP also kills the database query...

I mean this issue does "fix" the problem, but I don't think adding a submit button is a good idea regardless. It goes from 1-2 requests per visitors to 1 request per visitor (so the reduction is less than half), but the performance doesn't change, unless we are making too many requests to the server, but I assume there is probably a request limit that is much lower than whatever the database limit is.

However, adding a submit button, would decrease the perceived performance, because we'd have to wait for the user to click the submit button, before we can even start the request.

So I would say, since reducing the number of requests does not increase the performance, and adding a submit button decreases perceived performance, it's not worth the trade off at this time. However, if the number of requests does become an issue, then we can revisit that.

Technically, showing some results (or canceling the initial request) and then making another request (at least at this time) is not a problem (that I'm aware of). Now, you can make the argument that it's a better UX to require a startDate and I don't really have a good argument against that (mostly because, I'm not really sure how most people will use it). If most people are going to set a startDate anyways, then I think it's fine to require it.

Also, right now, we do set a dynamic startDate if you don't supply one, we just aren't displaying that to the user. I think at a minimum that date should be displayed to the user (I think the placeholder should change from YYYY-MM-DD to whatever the generated start date was).

There was a Community Liasons meeting this morning and the majority of the room (CLs, product managers, and designers) felt that setting a default start date of 30 days previous is the best solution to encourage the use of a start date without setting another obstacle for use.

I agree with David on the user experience benefits of not having a submit button.

In T189847#4062162, @TBolliger wrote:

There was a Community Liasons meeting this morning and the majority of the room (CLs, product managers, and designers) felt that setting a default start date of 30 days previous is the best solution to encourage the use of a start date without setting another obstacle for use.

So set a default, but do not make it required?

Sorry I just noticed your title change. :)

Correct, either or. We'll decide which one to build tomorrow. @dbarratt please review the new section I added to the ticket description.

Would either option remove the dynamic startDate from the API?

I can't think of a compelling reason to keep that logic any more. If a user explicitly blanks the field, I think it's safe to assume they want to see everything.