@gonyeahialam: I think we're ready for you to take on this work. You have already done a lot of work around adding topic, so I think the engineers have enough to get started. This task is the next high priority piece of work for the team. Thank you!

In T380202#10355139, @ifried wrote:

@gonyeahialam: I think we're ready for you to take on this work. You have already done a lot of work around adding topic, so I think the engineers have enough to get started. This task is the next high priority piece of work for the team. Thank you!

I have begun work on it. Thank you.

My current explorations on this task

To clarify, the confusion is not between ongoing versus upcoming events. The confusion arises because you see events that started outside the date filters. Depending on whether the date filters are in the past, present, or future, these events could be past, ongoing, or upcoming respectively. For example,

Remarks	From	To	[ ] Include ongoing events within the date range	[x] Include ongoing events within the date range
If the default date filter is set, which is today's date (Dec 3, 2024)	Today's date (Dec 3, 2024)	By default, this is blank	When NOT checked, you can see the first event starting on December 4	When checked, the first set of events displayed are events that started outside but still continue into the date range, and they are all ongoing events
If we change the default date filter to a date in the future	February 1, 2025	March 3, 2025	When NOT checked, all events shown start within the date range, the first being Feb 1, 2025	With this checked, you see events from March 15, 2024, to January 30, 2025, added. Given that today's date is Dec 3, 2024, all events that started before today, from March 15, 2024, to Dec 3, 2024, are ongoing, and all events after today to January 30, 2025, are upcoming. But these two sets of events are all displayed when the ongoing checkbox is checked despite many of them not being ongoing. In our earlier discussions, we thought of putting all of them in a separate Ongoing section.
Past date filters	November 1, 2023	March 3, 2024	When unchecked, we see events starting November 1, 2023	When checked, we see events added that start from March 18, 2023, to October 29, 2023. Now none of these events added by checking the Include ongoing events within the date range are ongoing; they are all past/ended events.

From the table above, we can identify two issues:

1. The problem with the UI is not about Ongoing/Upcoming but rather whether, if a date range filter is set—whether by the user or by default—you show only events that start within or also include events that started before (or without) but still continue into or overlap with the selected date range. Any of these events could be past, ongoing, or upcoming.

2. The label '[ ] Include ongoing events within the date range' is inaccurate, because:
   • (A) It specifies Ongoing events, but when checked with different date filters as shown in the table above, it displays past, ongoing, and upcoming events.
   • (B) It is also inaccurate because it says within the date range; when unchecked, it shows events strictly starting within the date range, whether ongoing or not. When checked, it adds events that start outside the date range but continue into or overlap with the date range.

We may also have used the word 'ongoing within' to mean 'going on within' (as hinted in the old task https://phabricator.wikimedia.org/T365859) and not actually that it is currently ongoing, but it is confusing to outsiders without stating the missing first half: 'Include events that start before the date range but are still ongoing within the date range'. It is also more confusing to them when dealing with past and future date filters, and it is going to be more confusing if 'ongoing events' is used standalone like having a separate section titled just 'Ongoing events'. "Include events that start before the date range but are still ongoing within the selected date range" is a longer but more accurate version of the checkbox label. We can make a few changes to make it more accurate—remove ongoing within as explained above and replace it with continue into: "Include events that start before the date range but continue into the selected date range". Remove repeated words: "Include events that start before but continue into the selected date range".

This is also supported by the technical definition of '[ ] Include ongoing events within the date range'.

With these corrections in mind, here are my explorations:

1. Separate event sections based on date filters

As I mentioned above, the main issue is if a date range filter is set, whether by the user or by default, do you show only events that start within or also include events that started before but still continue into or overlap with the selected date range. The idea builds on this: you have two sections. The first, which is closed by default, shows events that started before but continue into the selected dates, and the second, emphasized by being open by default, shows events that started within the selected date range. The first section can also be removed by unchecking the checkbox in the filter that states 'Show events that started before but continue into the selected dates'.

2. Single list (No separate sections)

A. Wikimedia Diff calendar method

Currently, when we include events that start before the date ranges, it is confusing to people because they see events with dates so far off from the current date or their selected dates at the top of the list. Diff handles this by showing the calendar dates rather than the start dates of such events. For example, looking at the image below, the filter is today, Dec 3, 2024; the start date of the first event in the image is January 30, 2024, to December 10, 2024, but the big calendar date displayed is December 3. My understanding of their solution is that 'for any given or selected day, what events can you join?' You can join an event that started 11 months ago but is still on as of Dec 3, 2024, or you can join an event that started today. So the big dates represent the calendar dates and not the start date of an event. This is similar in calendar views like your Google Calendar in month view; if you look at a particular day, you can see events that start that day and also events that started earlier but continue into the date (although the fact that they started earlier is more obvious).

B. Users have to explicitly include events that start before but continue into the selected ranges.

By default, such events are not shown, and users have to press the switch button to show them.

3. Separate events by status

You have three sections: Ongoing, Upcoming, and Past (ended). Depending on whether the date filters are in the present, past, or future, you may see only Ongoing and Upcoming sections. The sections to be displayed are not based on the checkbox that states 'Show events that started before but continue into the selected dates'. Checking this box can display events in any of the sections depending on the date filters entered.

Please review the above explorations
cc @Daimona @ifried @cmelo @VPuffetMichel @MHorsey-WMF @vaughnwalters

In T380202#10377758, @gonyeahialam wrote:

"Include events that start before but continue into the selected date range"

I agree that this is more accurate than the existing label. One thing to keep in mind, as I pointed out a few days ago, is that both date filters are optional. So you could, for example, only use the "To" filter and leave the "From" field blank. In this case, the checkbox would have no effect, and all events would "start before [the selected range]" regardless. Obviously, the same is trivially true when neither field is used. Maybe we could hide the checkbox as part of these improvements, when the "From" field is not used? I just wonder if it wouldn't be more confusing for users. Maybe not.

1. Separate event sections based on date filters

This is the solution we began looking at a while ago. I'm sure we've talked about this extensively, but surprisingly there's no trace of any discussion either here or in T379981?! At any rate, it is doable, but each section would need its own pagination controls.

2. Single list (No separate sections)
A. Wikimedia Diff calendar method

At the very least, I think this would kind of defeat the purpose of this change, which is to make the event list feel less static. And no matter what the label says, the events in the list remain the same. In fact, I'd argue it would make things even worse, because you may well have a single date for the whole first page (and more). This is not just a hypothetical scenario, either: the current list on meta would show 44 events with today's date. If anything, this makes it harder to navigate the list IMO.

There's also a question of whether it makes sense to follow this approach for start dates that are not today. For example, when browsing past events you are likely more interested in seeing when they begun, rather than what events you could've joined on a given day.

B. Users have to explicitly include events that start before but continue into the selected ranges.

This would be straightforward, but it goes in the opposite direction as previous decisions. For context:

• In the initial implementation of the event list (T353382), there was no concept of "ongoing events". The only available "mode" is what you'd get now by unchecking the checkbox (i.e., no "ongoing" events shown). This came up in QA (T353382#9755426 and following comments), and the consensus was that we needed to show ongoing events unconditionally. In this task already there was confusion on how these filters would work, and that hasn't changed since then.
• T363865 was created as a follow-up of the initial implementation task. Here, we updated the page so that it would always show "ongoing" events.
• And finally, in T365859 we added an option to show/hide "ongoing" events. But the product consensus was that the default should be to display "ongoing" events because it'd be more useful.

So yeah, we can reverse that decision, but I do want to highlight how intentional this seems to have been. I don't know if the original rationale for making this the default still stands true.

3. Separate events by status

I think this would be roughly the same as option 1, right? I might need some more time to think about it though.

Thank you for sharing this breakdown of your thoughts, @gonyeahialam! It is so helpful for me to read. I want to jot down some quick thoughts in response, which we can discuss more in our 1:1 today:

• On language choices: We need to consider both accuracy and usefulness. If the description of what we have generally called "ongoing events" is too wordy and long, I think it may just confuse most people and not prove helpful. So, I think we need to ask ourselves: Why do we want to show these events anyway? The answer is that these events are or were still going on within the selected date range, so they were relevant. They were active and in progress. So, I think we may want to aim for something short but helpful, such as: "Active events within date range," "Live events within date range," "Events that already started within date range" or something like that.
• I am drawn to option 1 - the idea of separate sections, with default being to display upcoming and the user can choose to also open up the ongoing.
• I don't really see the value in listing all past events within a selected date range - what was your thinking on this? Maybe I am missing something.
• We previously decided that we don't want to hide or make seemingly invisible the ongoing events (or whatever we want toc call them). I think that still holds true.
• I think the single page option defeats the purpose of this work, as well, since it still makes the page seem static

I have gotten plenty of feedback so far and I am still collecting feedback. I just what to jot down my current thoughts.

Background
The main use case for the Collaboration list is for people to find and join events that interests them.
Therefore their primary need is for events happening in the present or in the future.
For example:

• I am free today and this week, what events can i participate in? (present)
• I have new year's holiday coming up and will be free from January 1 to 7 2025, what events can i participate in? (future)

In these scenarios events that fall/start strictly within the available dates is the major need. But also an event that started a day earlier or a week earlier (e.g Yesterday or December 31 2024) are still useful to participate in, hence the need to include them.

Another use case, which I would consider secondary is finding events in the past perhaps for research. I don't have much info on the reason for this but it will be helpful to know what the use case is around this to help us design better.

Problem
Currently, on the Collaboration list these events that started before the selected dates are displayed by default. This sometimes causes confusion because users will see events with dates so far off from the selected dates. These extra events push the main events further down the page and each time you visit the Collaboration list you mostly see the same old events.

Goal
We want to give users the option to see these other events that started earlier in a way that doesn't confuse them (which happens when they see dates so far off) or reduce the visibility of the main events (these extra events push the main events almost to another page).

I will now rank most of the ideas I presented above based on how they solve this problem.

Rank from best to least	Ideas	Solves users confusion	Retains visibility of main events (events within the date filter)	Notes
1.	Idea 1	This removes the confusion with the dates because the main events have their own section and the other events that start before but continue into the date range have their own section	Same for this too	A better design for this idea is to display the main events directly on the page and only put the other events inside an accordion. We can also choose to remove the check box in the filters as it is not so important anymore.
2.	Modified Idea 2B: As mentioned earlier it is useful for users to see events that may have started earlier but the major need are the events within the date filters, given this hierarchy it will be okay to not show these other events by default as long as the button to make them visible is prominent and easily seen by users. This is what i have done with this design by bringing the check box out of the filter and placing it more prominently on the page. Prototype:	It solves this by not showing the extra events by default and since the user makes the decision to show it themselves they are probably not going to be confused	This doesn't completely solve this since these other events will still push the main events down the page but this will be less of a problem for users since they made the decision to show it.
3.	Idea 3	This is solved for the default date filters (that is, the current day) where all the events that started before but continue into the date ranges will fit neatly under Ongoing events section which will be minimised by default. But when the date filters are set in the past or in the future these other events will be spread across different sections depending on whether they are ongoing, past(ended) or upcoming. The confusion is reduced here but not solved completely.	Same for this too

cc @Daimona @ifried @cmelo @VPuffetMichel @MHorsey-WMF @vaughnwalters

As we have discussed previously, we would arrange these other events in the list in reverse order, that is, the ones whose starting date is closest to the date filter ranges are displayed first and those farther away are displayed last. We can show only a few events and have a button to show more. When the button is clicked more events are shown as well as the pagination which shows at the bottom.

In T380202#10384816, @gonyeahialam wrote:

Another use case, which I would consider secondary is finding events in the past perhaps for research. I don't have much info on the reason for this but it will be helpful to know what the use case is around this to help us design better.

I'm not sure how this would make a difference. Some reasons that come to mind are statistics (write a report on how many events were organized this year), curiosity (similar to statistics but less "formal"), and investigations (e.g., "why did we see a surge in account creations in month X? Were there any events?"). Surely there's more.

I will now rank most of the ideas I presented above based on how they solve this problem.

Your ranking makes sense to me.

This is what i have done with this design by bringing the check box out of the filter and placing it more prominently on the page. Prototype:

This file needs to be attached to the task or something like that. It is currently not visible.

In T380202#10384847, @gonyeahialam wrote:

As we have discussed previously, we would arrange these other events in the list in reverse order, that is, the ones whose starting date is closest to the date filter ranges are displayed first and those farther away are displayed last.

Yup, this is doable. I just hope it isn't too confusing to have different sorting in different sections.

We can show only a few events and have a button to show more. When the button is clicked more events are shown as well as the pagination which shows at the bottom.

I'm curious about this. In this design, the events would be inside an accordion that is collapsed by default. Why would we need an additional layer on top of that (i.e., accordion within accordion)? My gut feeling is that it might be somewhat messy to implement, and inconvenient to use: if you want to see "ongoing" events you have to expand twice; if you don't, you can just close the accordion. Also, I think in the proposed implementation with a button you would no longer be able to collapse the list once you expand it.

@cmelo & @MHorsey-WMF, this ticket is in dev input. Curious to know if you two have any feedback to share. I would like for us to have feedback documented in this ticket by our Monday meeting, so we can discuss potential next steps. Thanks!

@Daimona

Yup, this is doable. I just hope it isn't too confusing to have different sorting in different sections.

That's why the events in the different sections have different designs, which can also be modified further. The big calendar dates in the first section are replaced with the starting month. This difference helps communicate that this section operates differently.

I'm curious about this. In this design, the events would be inside an accordion that is collapsed by default. Why would we need an additional layer on top of that (i.e., accordion within accordion)? My gut feeling is that it might be somewhat messy to implement, and inconvenient to use: if you want to see "ongoing" events you have to expand twice; if you don't, you can just close the accordion. Also, I think in the proposed implementation with a button you would no longer be able to collapse the list once you expand it.

There is only one accordion. The reason for the extra step to see more is because the events that started much earlier may be less useful to join or as Alex Stinson said, they might not even be considered events. So this design focuses the user on the most useful ongoing events.
We could also decide to limit these events that started earlier to only those that start 3 months or less and not show those outside that cc @ifried

I'm not sure how this would make a difference. Some reasons that come to mind are statistics (write a report on how many events were organized this year), curiosity (similar to statistics but less "formal"), and investigations (e.g., "why did we see a surge in account creations in month X? Were there any events?"). Surely there's more.

Understanding the use case of past events is actually quite important because the goals of those seeking past events are completely different from those seeking current or future events to attend. So a design that is good for our main use case may not be good for the use case of past events and vice versa. So far I have tried do design something that works for both. If I was only focused our main use case the designs will be different.

Thank you for sharing this information, @gonyeahialam! I think your ranking makes sense; I agree that idea 1 seems the most intuitive and clear. One note is that I cannot actually see the image for idea 3 - can you update the comment with the image?

I'm curious about this. In this design, the events would be inside an accordion that is collapsed by default. Why would we need an additional layer on top of that (i.e., accordion within accordion)? My gut feeling is that it might be somewhat messy to implement, and inconvenient to use: if you want to see "ongoing" events you have to expand twice; if you don't, you can just close the accordion. Also, I think in the proposed implementation with a button you would no longer be able to collapse the list once you expand it.

There is only one accordion. The reason for the extra step to see more is because the events that started much earlier may be less useful to join or as Alex Stinson said, they might not even be considered events. So this design focuses the user on the most useful ongoing events.
We could also decide to limit these events that started earlier to only those that start 3 months or less and not show those outside that cc @ifried

I don't think we should hide older ongoing events if they are indeed still ongoing within the selected date range. That would be confusing. If someone wants to see ongoing event, we shouldn't assume what the user wants. Rather, we can provide more filters in the future to help them narrow down their selection.

Overall, for the MVP, I think we should keep things simple. If a user chooses to see all ongoing events within a selected date range, we just show them the full list with no extra steps required.

I'm not sure how this would make a difference. Some reasons that come to mind are statistics (write a report on how many events were organized this year), curiosity (similar to statistics but less "formal"), and investigations (e.g., "why did we see a surge in account creations in month X? Were there any events?"). Surely there's more.

Understanding the use case of past events is actually quite important because the goals of those seeking past events are completely different from those seeking current or future events to attend. So a design that is good for our main use case may not be good for the use case of past events and vice versa. So far I have tried do design something that works for both. If I was only focused our main use case the designs will be different.

Thank you for doing this, Gregory! I think you have designed a solution that works for both use cases. Overall, looking for past events within a date range is less common, so it is our secondary use case. However, some reasons why someone would want to do it include the following:

• An organizer thought more people would attend their event than actually did. They want to look back at other events going on in that period to see if there was a conflict.
• Someone is interested in organizing an event during a certain time period (for example, in March 2025). They want to see what events were going on in March 2024, so they can see what other events typically occur during that time to avoid conflict and/or to find potential collaborators.
• Someone is interested in a certain topic -- for example, an editor who really cares about adding more content about sustainability and environmentalism to the wikis. They may want to see not only what is currently coming up as an event to join, but also past events that happened. This way, they can get a better sense of what has historically happened around the topic, so they can answer questions like: Is there already a lot of activity around this topic? Who is organizing the events? Who is participating?
• Someone is interested in learning more about some changes in user activity - such as a surge in accounts being created on a wiki. Looking back at past event data can help one understand if events with lots of newcomers played a role in this.

In T380202#10387633, @gonyeahialam wrote:

@Daimona

Yup, this is doable. I just hope it isn't too confusing to have different sorting in different sections.

That's why the events in the different sections have different designs, which can also be modified further. The big calendar dates in the first section are replaced with the starting month. This difference helps communicate that this section operates differently.

Right, good point!

I'm curious about this. In this design, the events would be inside an accordion that is collapsed by default. Why would we need an additional layer on top of that (i.e., accordion within accordion)? My gut feeling is that it might be somewhat messy to implement, and inconvenient to use: if you want to see "ongoing" events you have to expand twice; if you don't, you can just close the accordion. Also, I think in the proposed implementation with a button you would no longer be able to collapse the list once you expand it.

There is only one accordion. The reason for the extra step to see more is because the events that started much earlier may be less useful to join or as Alex Stinson said, they might not even be considered events. So this design focuses the user on the most useful ongoing events.

I kind of get that, but I still feel like if someone chooses to see ongoing events, they should see all of them -- "chooses" being the key word here, since you have to intentionally expand the accordion. If they don't care about older events, they can just stop scrolling and/or close the accordion. Also, yes, there is only one accordion. I used the word "accordion" to indicate the general concept of expanding/collapsing information. But I also think it doesn't change much; in fact, I'd argue the button version is slightly more cumbersome because you can't collapse the data after you expand it.

BTW, one thing to keep in mind for when we'll be writing AC: it would be helpful to know how these sections should behave exactly. For example, I assume that the default state would be to collapse ongoing events. But then, if someone uses the pagination controls in that section (to change the number of results, or go to another page), then I guess the accordion should be expanded by default?

This also goes to show how having a nested accordion-like thing would make things more complex. I agree with Ilana above that it would be best to keep things simple, at least for the time being.

We could also decide to limit these events that started earlier to only those that start 3 months or less and not show those outside that cc @ifried

I also agree with Ilana on this.

I'm not sure how this would make a difference. Some reasons that come to mind are statistics (write a report on how many events were organized this year), curiosity (similar to statistics but less "formal"), and investigations (e.g., "why did we see a surge in account creations in month X? Were there any events?"). Surely there's more.

Understanding the use case of past events is actually quite important because the goals of those seeking past events are completely different from those seeking current or future events to attend. So a design that is good for our main use case may not be good for the use case of past events and vice versa. So far I have tried do design something that works for both. If I was only focused our main use case the designs will be different.

Ah, I see, thank you! I was just thinking about it in the context of specific ideas, and not holistically as you were doing.

I don't think we should hide older ongoing events if they are indeed still ongoing within the selected date range. That would be confusing. If someone wants to see ongoing event, we shouldn't assume what the user wants. Rather, we can provide more filters in the future to help them narrow down their selection.

Overall, for the MVP, I think we should keep things simple. If a user chooses to see all ongoing events within a selected date range, we just show them the full list with no extra steps required.

I agree @ifried

Hi all, sorry I would have posted this on Friday, but my wife got sick, but here are my thoughts on this.
@Daimona @ifried @VPuffetMichel @MHorsey-WMF @vaughnwalters

To me, sounds like all these dates filtering is really confusing because:

1. Ongoing events should have its own separated place, because they rely on today's date, so the date filtering should not be applied to them.
2. The date filter, filter the events based on the event start date, and we added the checkbox to kind of show/hide ongoing events which kind of also filter the events by event end date.

That said, I think we should have a separated place for ongoing events and the date filtering does not affect it, while other filters do, such as filter events by wiki e.g.
Also, I think we should just remove the checkbox and change the text of the date input fields to instead of, From To, it could be, Events starting from To so it is clear that the date filtering only filters the events based on the event start date, and if we want to allow the users to also filter the events by end date, maybe it is time to add another date filtering so we would have both dates filtering below:
Events starting from -> To
Events ending from -> To

E.g:

Before I go ahead I'm going to define my terms. I will not be using the word "Ongoing" because it's become too muddied in discussion.

"Window" - the time between the start and end dates chosen (inclusive)
"Active events" - Events which are currently in progress, on the day that the search is being performed
"In-window events" - Events which fit in the chosen window
"Out-of-window" events - Events which would have been/will be active in the window chosen, but started before the chosen start date.

For Active events, I think conceptually this whole thing makes perfect sense and we have no issues (correct me if I am wrong)

Likewise for in-window events, as that is how things worked before we added the dreaded checkbox.

This issue arises when talking about past and future out-of-window events. Assuming we definitely have valid use-cases for both of these, the design (while very useful) is not going to communicate the concept well enough and I think we need to have robust help test on any field that we use to allow this. I also feel like conceptually they are different enough from the active events that they warrant their own control to hide/show/disable them and we shouldn't be grouping them with active events.

Hello, In addition to my comment above and the meeting we had today, here are some question I have about the proposal, I know that some of them were already explained in some comments above, but I would like to be sure that I understood everything, thanks in advance :)

BTW as @MHorsey-WMF I will also use "Active events" to refer to events which are currently in progress, on the day that the search is being performed

Date Filtering Options:
What date filtering options we want to allow?

• Filter past events
• Filter upcoming events
• Filter active events
• Filter past active events
• Other options...

Display Sections:
What should be displayed in the main section and the proposed collapsed section?

Default Date Filter Setting:
If the date filter is set from today to an undefined future date (null), the following will apply:

• The main section would display:?
  • Only upcoming events, including those starting today.

• The proposed collapsed section would show:?
  • Only currently active events (events that started in the past but are still active).

Filter Set to Past Dates:
If the user changes the filter to a past date range, such as from 2023-01-01 to 2023-12-31:

• The proposed collapsed section would display:?
  • Events that were active during these dates, meaning events that started between these dates but continued beyond 2023-12-31. For example, an event that started on 2023-12-01 but was still active on 2024-01-01. This section will include events that have ended but were active during the specified period, and it may also display real active events if they started within the given period and are still active. meaning that this section would be used to show not only current active events, but also past active events depending on the date filtering, and there will be no fixed place to see real active events, it will be dependent on the dates choosen by the user.

• The main section would show:?
  • Events that both started and ended within the selected dates (i.e., past events).

Filter Set to Future Dates:
If the user selects dates in the future:

• The proposed collapsed section would:?
  • Possibly be hidden or show nothing, as there are no active events from the future.

• The main events section would display:?
  • All upcoming events.