Hello @gonyeahialam! Perhaps you can explore how we can do this and then share the design idea with the team? Thanks in advance!

In T365859#9830789, @ifried wrote:

Hello @gonyeahialam! Perhaps you can explore how we can do this and then share the design idea with the team? Thanks in advance!

I am working on it.

Thank you, @gonyeahialam! Could you perhaps share the concepts at the next design + engineering meeting?

To make all information about dates clear, I have made a few changes:

1. I emphasized the dates on the events. The dates are the next most important information after the event title and need to be seen at a glance.
2. I highlighted the change in month and year by adding the year beside the month and inserting a divider. This clarifies the year an event starts and when there is a transition between years in the list. For example, in the current list, you might see December, January, May, and September without realizing some months are in different years. This change, along with the previous one, will make this clear. It will also make ongoing events more noticeable at a glance (even though people can choose whether to see ongoing events or not, it will be helpful to easily differentiate them on the list when they appear together).
3. I added a filter for users to choose whether they want to see ongoing events.

Uses a checkbox to toggle between showing ongoing events	Uses a dropdown

I am exploring more ideas to make this clearer but the above are the current main ideas

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

In T365859#9856073, @gonyeahialam wrote:

To make all information about dates clear, I have made a few changes: [...]

LGTM. I personally prefer the option with the checkbox, since it's just one option. I'm also not 100% convinced by the checkbox label, but at this time I don't have ideas on how to improve it.

Looks good to me too.

Thanks for sharing the thinking behind the changes you made. @gonyeahialam

As far as the label of the checkbox, could we do something like:

• Show events that already started and are ongoing

Hi @gonyeahialam! Thank you for sharing your thinking behind the suggested changes. It is very helpful to read it :) A few small comments & questions:

• When you say that the dates are more emphasized in the new version, you mean that they are now in bold, correct? If yes, I think this makes it easier to quickly skim the event list to find this event start & end dates, so this change makes sense to me.
• I like that you included the year. My only suggested tweak is to remove the comma. So it would be, for example, "January 2023" and not "January, 2023"
• I also like that you are experimenting with ways to make the separation of the months more clear. A separating line is a way to do this.
• I prefer the checkbox rather than the dropdown as well, since there are 2 only options (so a dropdown feels unnecessary). Do you agree, or no?
• Regarding language for the checkbox, I like what @VPuffetMichel wrote: "Show events that already started and are ongoing." What do you think? If you agree, perhaps we can update the text and go with the checkbox example for the ticket?

@Daimona @VPuffetMichel @ifried

For the dropdown, I was exploring the scenario where there are more options like: Ongoing, Upcoming, Past, Closed, Ended events.

Thanks for the copy suggestions, I am still exploring the clearest copy. We can go with @VPuffetMichel copy

In T365859#9861681, @ifried wrote:

Hi @gonyeahialam! Thank you for sharing your thinking behind the suggested changes. It is very helpful to read it :) A few small comments & questions:

• When you say that the dates are more emphasized in the new version, you mean that they are now in bold, correct? If yes, I think this makes it easier to quickly skim the event list to find this event start & end dates, so this change makes sense to me.
• I like that you included the year. My only suggested tweak is to remove the comma. So it would be, for example, "January 2023" and not "January, 2023"
• I also like that you are experimenting with ways to make the separation of the months more clear. A separating line is a way to do this.
• I prefer the checkbox rather than the dropdown as well, since there are 2 only options (so a dropdown feels unnecessary). Do you agree, or no?
• Regarding language for the checkbox, I like what @VPuffetMichel wrote: "Show events that already started and are ongoing." What do you think? If you agree, perhaps we can update the text and go with the checkbox example for the ticket?

I agree with the above.
I have explained the idea behind the drop-down above.

A better phrasing will be to use 'include' instead of 'show'

• Include events that already started and are ongoing.

@MHorsey-WMF @Daimona How do we currently handle ongoing events with closed registration? Do we still show them in the list?

In T365859#9863006, @gonyeahialam wrote:

@MHorsey-WMF @Daimona How do we currently handle ongoing events with closed registration? Do we still show them in the list?

Yes.

We discussed this in a team meeting today. We should continue to display all events (open, closed, and finished). However, we can improve this user experience in the future to allow users to select what they want to see (see T366741). This work is lower priority and should be handled separately. Our high priority work right now is to allow users to display/hide ongoing events, since the current user experience is confusing to some people. Also, I still think the checkbox makes the most sense since an event can be ongoing but "open" or "closed," so all of those things would not easily fit into a dropdown in which only one option can be selected.

In that case, @gonyeahialam, let's update the ticket with the latest designs and then we can share it with the engineers for a final look. As for the updated language change to be "Include" rather than "Show," that works for me. If we want to change the UX later, we certainly can, but I think this is a good solution to the problem we have at hand. Thanks!

latest design

Changes:
The date is now bold
The year has been added to the month heading with a divider underneath
A check box below the From and To filters to include or exclude ongoing events

@cmelo @ifried @VPuffetMichel @Daimona @MHorsey-WMF Done with the design

Hi @gonyeahialam! The text in the design example is incorrect. It should be: "Include events that already started and are ongoing." In your example, it reads: "Include already started events that are ongoing." Can this be updated? Thanks!

Updated

Note: The label doesn't have a full-stop

Yup, the full stop was just for the sentence of my comment, but you are correct that the actual label should not have it. Thank you, @gonyeahialam!

• Show events that already started and are ongoing

I was re-reading this task, but noticed that either the copy is inaccurate, or I don't understand what we're doing here. Sorry for not noticing this before. I'm going to explain with two examples.

First, suppose we have an event that runs from June 1 to June 31. When you open the AllEvents page, the "From" date is set to June 11 (today). If "ongoing events" are shown, that event would be in the list. If you choose to hide ongoing events, that event is no longer shown. I think we all agree up until here.

Second, suppose you have an event running from September 1 to September 30. After you open the AllEvents page, you change the "From" date to September 10. That event would appear in the list. But, if you choose to hide "ongoing" events, that event should become hidden, is this correct? If so, the checkbox label is incorrect, because the event in question hasn't already started (it'll start in 3 months) and is not ongoing. You'd get a similarly confusing behaviour if you set the "From" date to, say, January 10, and you had an event from Jan 1 to Jan 31.

Now I understand why the prototype in T365859#9856073 had a more verbose label. Should we actually use that, or a variant of it that more faithfully represents the reality of things? I feel like this whole "From - To" thing is already quite confusing, so I'd like the label to be correct, at least.

Some options are:

Clearer but long

• Include events that started before and are happening within the selected date range

Shorter version

• Include events continuing into date range

Somes notes:

• We should display ongoing events as default. This was confirmed after talking to @gonyeahialam. We both believe that it is better to show ongoing events because, if we do not, there are many events that people could join, but they would be hidden from them. Perhaps this is not how users will feel, but we can start this way and see what feedback we get.
• As for language, thanks for clarifying that "ongoing" alone is not sufficient, @Daimona. Also, thanks for asking bigger picture questions about what should or should not happen in terms of behavior. For this reason, I have listed what I see as the main use cases below (in the next bullet point). Meanwhile, I appreciate the new language options you shared, @gonyeahialam! They are more accurate. I have a slightly tweaked version of your last example, but it is pretty similar to what you came up with: "Include ongoing events within the date range."
• I took a step back and broke down when/why people may want to use this feature, just so we can have more clarity. Here is how I break it down:
  • For events that have ended: Users may want to know which events were active during a given time period in the past. For example, "I want to see all of the events that were happening in March 2023, regardless of when they started." We already do this: see Wletg2023 in this example
  • For current events: Users may want to know which events they can join/attend, even if the events have already started. I think this would be especially useful for longer online events and content drives, in which people can jump in at various times and join the event. This is the most common use case that I think we can all agree on.
  • For upcoming events (this is the September example that was provided above): Users may want to know about all events going on during a future time period. For example, maybe an organizer wants to organize an event during that period, and they want to know all of the other events that are going on, so they can limit any clashes with other events. We already do this: see Desafío Uruguay in this example.

Overall, what do people think? Do we think this works?: Include ongoing events within the date range

In T365859#9886466, @ifried wrote:

Overall, what do people think? Do we think this works?: Include ongoing events within the date range

Neat!

I think "Include ongoing events within the date range" more accurately describes the events that start and end within the chosen date range rather than the events that start before the date range and still continue into the date range.

But all these discussion points to the fact that this solution isn't adequate we need to rethink how to better solve this.
There is still very likely going to be a little confusion(I say little because this confusion isn't going to prevent the user from achieving their goal) when the dates set in filter don't match the date on the event list. Also, this is mostly going to affect those who actually make changes to the dates in the filter, It wouldn't be much of a problem for those who just use the list/filter as they are.

I think we should go ahead with has been suggested, while I explore an improved solution for future interations of the event list.

Thanks for sharing this, @gonyeahialam, and I agree that a) the updated text works for now, and b) we may need to explore further improvements later on!

First, we'll work on this solution and then see what feedback we get from users. Then, we can see if we need to make further improvements (which very well may be the case). But, for now, let's not do any further design explorations on this until we release this first improvement and hear from users what they think. Thank you for sharing this feedback!

I'm a bit confused by the task description and want to make sure that I understand it correctly. If I choose to hide ongoing events, then enter July 20 as "From" and July 30 as to, what events should I see? My interpretation is that:

• Event is July 10 to July 15: not shown (obvious)
• Event is July 15 to July 25: not shown (?)
• Event is July 15 to August 10: not shown (?)
• Event is July 21 to July 28: shown (obvious)
• Event is July 25 to August 10: not shown (?)
• Event is August 10 to August 15: not shown (obvious)

Whether this is correct/expected, I don't know.

I think all the confusion here comes from the fact that we're trying to use just two fields ("from" and "to") to control what's actually 4 different variables ("start from", "start to", "end from", "end to").

@Daimona When the you hide ongoing events:

Event is July 10 to July 15: Not shown (event ends before the range starts).
Event is July 15 to July 25: Not shown (event starts before the range starts).
Event is July 15 to August 10: Not shown (event starts before the range starts).
Event is July 21 to July 28: *Shown* (event starts and ends within the range).
Event is July 25 to August 10: *Shown* (event starts within the range and ends after the range).
Event is August 10 to August 15: Not shown (event starts after the range ends).

In summary, when you ongoing events are hidden, you show all events that start within the From and To regardless of when they end.

When ongoing events are shown, it means you show all events that intersect in any way within the From and To dates. So you don't show events that started and ended before and the range or after the range since they don't intersect.

A longer explanation:

Include ongoing events "is checked":

The filter shows all events that intersect with the selected date range. This includes:

• Events that started before the range but end within or after the range.
• Events that start and end within the range.
• Events that start within the range but end after the range.

Code logic:
Use the following condition to filter events:

(eventStart <= selectedToDate) && (eventEnd >= selectedFromDate)

This ensures any event overlapping the selected date range is included.
Example Scenario
User selects date range from July 20, 2024, to July 30, 2024.

Events displayed:

• Event starting July 15, 2024, and ending July 25, 2024
• Event starting July 21, 2024, and ending July 29, 2024
• Event starting July 28, 2024, and ending August 5, 2024

Include ongoing events "is NOT checked":

When the toggle is turned off, show:

• Events that start and end within the selected date range.
• Events that start within the range but end after the range.

Code logic:
filter events using:

(eventStart >= selectedFromDate)  && (eventStart <= selectedToDate)

This ensures events starting within the range and those continuing beyond the range are included.
Example Scenario
User selects date range from July 20, 2024, to July 30, 2024.

Events displayed:

• Event starting July 21, 2024, and ending July 29, 2024
• Event starting July 28, 2024, and ending August 5, 2024

Thank you for posing these questions, @Daimona! And thanks for the very thorough explanation, @gonyeahialam! I think your breakdown makes sense. I will update the AC to see what people think. Also, more details below:

We are really thinking of two main use cases:

Use case 1: The purpose of showing ongoing events is to make it easy for people to see everything that is going on during a specific date range, even if the event started earlier than the start date. This way, people can join events that may have already started but are still ongoing, if they're interested in the events. This has been the status quo of what we have had so far.

Use case 2: The purpose of hiding/displaying ongoing events is to only show new events that start within the given date range selected, so that people who only want to join events when they officially start (or only want to learn about new events that aren't already ongoing) will see these results in the search results.

In both cases, the fundamental difference is: Has an event started yet, or no? For use case 1, the user doesn't care about when the event started or will start. In use case 2, the user cares about when the event has started or will start.

Change #1056987 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] EventsListPager: simplify query conditions and add test

https://gerrit.wikimedia.org/r/1056987

@gonyeahialam Thank you!

In T365859#10014227, @gonyeahialam wrote:

A longer explanation:

Include ongoing events "is checked":

The filter shows all events that intersect with the selected date range. This includes:

• Events that started before the range but end within or after the range.
• Events that start and end within the range.
• Events that start within the range but end after the range.

The code was excluding the third scenario, so I've updated the code.

Include ongoing events "is NOT checked":

When the toggle is turned off, show:

• Events that start and end within the selected date range.
• Events that start within the range but end after the range.

Thanks, I was missing the second part.

While I agree that this solutions seems to be sufficient for the typical use cases, I'm still convinced that the behaviour is really complex and potentially confusing. I agree with the sentiment in T365859#9914041 that we may need to rework this, and I'd still consider having the full 4 fields in the form. While more fields means more complexity, fewer fields also means more surprising behaviour. I've now spent hours engineering this and barely know how it works. I would assume a user coming to use it for the first time might be very confused.

Change #1056995 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] SpecialAllEvents: Add field to show/hide ongoing events

https://gerrit.wikimedia.org/r/1056995

While I agree that this solutions seems to be sufficient for the typical use cases, I'm still convinced that the behaviour is really complex and potentially confusing. I agree with the sentiment in T365859#9914041 that we may need to rework this, and I'd still consider having the full 4 fields in the form. While more fields means more complexity, fewer fields also means more surprising behaviour. I've now spent hours engineering this and barely know how it works. I would assume a user coming to use it for the first time might be very confused.

Thanks for sharing this, @Daimona, and I completely agree with you that there are a lot of ways that this could be handled (and perhaps this is not the best way). Can you perhaps share a bit more explanation of how the 4-option alternative could work? I sorta get it, but lots of questions come up in my head when I think about it, so perhaps I need more of a rundown of your thinking on it! If there is a better approach, then let's lay it out and determine whether it should be done instead. Thanks for all of the thought & work you have put into this so far!

In T365859#10016055, @ifried wrote:

While I agree that this solutions seems to be sufficient for the typical use cases, I'm still convinced that the behaviour is really complex and potentially confusing. I agree with the sentiment in T365859#9914041 that we may need to rework this, and I'd still consider having the full 4 fields in the form. While more fields means more complexity, fewer fields also means more surprising behaviour. I've now spent hours engineering this and barely know how it works. I would assume a user coming to use it for the first time might be very confused.

Thanks for sharing this, @Daimona, and I completely agree with you that there are a lot of ways that this could be handled (and perhaps this is not the best way). Can you perhaps share a bit more explanation of how the 4-option alternative could work? I sorta get it, but lots of questions come up in my head when I think about it, so perhaps I need more of a rundown of your thinking on it! If there is a better approach, then let's lay it out and determine whether it should be done instead. Thanks for all of the thought & work you have put into this so far!

The idea would be to have the following four fields: "Starts after", "Starts before", "Ends after", "Ends before". These would do exactly what their labels say, and give the user more granular control, while also being (I hope) more self-explanatory.

@gonyeahialam Just to confirm: with the dates now being in bold, we should also remove the clock icon as in the specs, right?

Change #1056987 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] EventsListPager: simplify query conditions and add test

https://gerrit.wikimedia.org/r/1056987

Change #1056995 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] SpecialAllEvents: Add field to show/hide ongoing events

https://gerrit.wikimedia.org/r/1056995

Change #1057245 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] [WIP] Update event list styles to match latest specs

https://gerrit.wikimedia.org/r/1057245

This would be ready for review but I'd like to confirm T365859#10017754 first.

In T365859#10017754, @Daimona wrote:

@gonyeahialam Just to confirm: with the dates now being in bold, we should also remove the clock icon as in the specs, right?

Yes, you are right.

Change #1057245 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Update event list styles to match latest specs

https://gerrit.wikimedia.org/r/1057245

Acceptance Criteria:

• Given that a user is on Special:AllEvents,
  • ✅ The user should be able to see ongoing events in the Event List (as default)
  • 
  • The user should be able to hide ongoing events, if they want, by checking a box below the "From" field, which states:
    • ✅ Include ongoing events within the date range
    • 
• When the toggle is turned off, show:
  • ❓ Events that start and end within the selected date range.
  • 
    • on betacluster when I switch from en wiki to ar wiki then the date range shown is inaccurate by one day. Is this a bug?
  • ✅ Events that start within the range but end after the range.
  • 
• The visual appearance should be updated:
  • ✅ The date is now bold and the clock icon is removed
  • 
  • ✅ The year has been added to the month heading with a divider underneath
  • 
  • ✅ A check box below the From and To filters to include or exclude ongoing events
  • 

In T365859#10030356, @vaughnwalters wrote:

• ❓ Events that start and end within the selected date range.
  • on betacluster when I switch from en wiki to ar wiki then the date range shown is inaccurate by one day. Is this a bug?

This is somewhere between a bug and undefined behaviour. The date selector in the filters uses UTC, whereas event times are shown in the user's preferred timezone. This definitely needs to be changed; how exactly, we don't know. We began talking about this in T363867, but we then decided this wouldn't be a blocker for the MVP.

In T365859#10031234, @Daimona wrote:

In T365859#10030356, @vaughnwalters wrote:

• ❓ Events that start and end within the selected date range.
  • on betacluster when I switch from en wiki to ar wiki then the date range shown is inaccurate by one day. Is this a bug?

This is somewhere between a bug and undefined behaviour. The date selector in the filters uses UTC, whereas event times are shown in the user's preferred timezone. This definitely needs to be changed; how exactly, we don't know. We began talking about this in T363867, but we then decided this wouldn't be a blocker for the MVP.

Okay I have made a note of this in T363867 and am sending this to design sign off.