Based on the task description above and some references I got from Alex Stinson, here is my current thoughts on this:

Regarding copy,

Regarding the ticket for improvement, the last decision on it was that Ilana and I would discuss about it but we haven't done that yet. I don't think a ticket was created for it.

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.

@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 put together some screenshots of how contribution data is displayed across wiki.

Do you think this kind of data will be per wiki? For example if an organizer visits a particular wiki they will see data for only events on that particular wiki. But events can target multiple wikis so I am thinking, visiting the event dashboard on the wiki the event page is on, you get to see the data for every wiki tied to that event. @ifried

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.

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

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

My current explorations on this task

I think we should also make the change @vaughnwalters

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!

@ifried I agree with you that we should start with OR and we can create another ticket to explore OR/AND design in the future.
I believe the Language team uses AND for the topics.

@ifried Since this was designed by the team, has been implemented and another ticket T379830 was created for me to do improvements. Should I just send it to product sign-off and put any modifications and suggestions in T379830?

Instead users selecting topics in the filter, applying it and then finding out there are no events on those topics, can we disable the topics with no events on the filter dropdown so users know before hand and wouldn't select? Illustration shown below:

Collaboration list
Potential participants can filter by topics (using the same component as organizers topics input)
Topics for each event are displayed on the event item in plain text as shown below.
For event with no topics, nothing is shown in place of it

	Mobile	Desktop

Enable event registration form
Added input field for topics

Created this task for reordering these filters T380514 @ifried @MHorsey-WMF

In T367226#10336404, @Daimona wrote:

In T367226#10336135, @gonyeahialam wrote:

@Daimona What type of input field is being implemented for this, I want to see if it is useful for topics?

The current implementation is based on OOUI's MenuTagMultiselect. Based on what we've seen for wikis, this is the only field we have available for dropdown-based multiselection.

@Daimona What type of input field is being implemented for this, I want to see if it is useful for topics?

@ifried In the acceptance criteria, only Enable event registration form page, EventDetails page, Collaboration list page are mentioned. Are we also considering showing the topic lists in the more details dialog or even the event page?

In T369538#10088508, @ifried wrote:

@gonyeahialam, I believe he means that we will not work on T368404 right now, but we will first await feedback after we enable the feature for Igbo & Swahili Wikipedia and get the first real users of the tool.

After registration has been enabled on the Initiative page, for the non time bound initiatives the page could look as shown below without the time related info:

The flow for a generalised event registration can look like this:

1. Initiative organizers create an on-wiki collaboration initiative page in a permitted namespace.
2. They proceed to enable registration for the page.
3. They select their initiative type - time bound or not time bound
4. They fill out the enable registration form with relevant fields based on their initiative type
5. They select participant questions they want contributors to answer when they register and enable registration.

In T371744#10100012, @Daimona wrote:

In T371744#10094125, @gonyeahialam wrote:

Though probably an edge case, it is possible for organisers to skip this first question and fill the others below it and then comeback and select the type of activity. If they do this, some fields they may have filled will disappear. My question here is, do we have some sort of cache implemented with forms so that if the organizer switches back again and those questions reappear their input will still be there?

Yes, that is the default behaviour. [Note: I'm only replying to this very specific question. I haven't looked into the details of this broader project]

>> - Descriptions can't be truncated. I believe we should just display the full description for now.

Okay, good to know, and cc @gonyeahialam

In T370938#10081989, @ifried wrote:

@gonyeahialam: Hello! Can we get an update on whether this has passed design sign-off?

@Daimona @MHorsey-WMF
For this task I am exploring how the event registration tool can be used for other types of on-wiki collaboration that are not time-bound and/or not events.
I am exploring adding a new question to the beginning of the enable registration form, for organizers to select whether their activity is time bound or not. Upon selection of any of two options, the form updates, for example if 'not timebound activity' is selected all questions specific to timebound activities(such as date/time, location, meeting type...) disappear.

@ifried when will the fixes in this task, be likely done?

In T368115#10075041, @ifried wrote:

@gonyeahialam, I just noticed that the 'community' tab is the same as the 'event' tab. Can this be updated with the most recent designs?

In T368115#10069840, @ifried wrote:

@gonyeahialam, are we ready to move this ticket to product sign-off so you can begin the time-boxed project?

In T369538#10064597, @Daimona wrote:

Discussed 2024-08-14: we're not tackling T368404 now because we will wait for feedback from "real users" first.

In T368115#10060882, @MHorsey-WMF wrote:

Only one issue I have with designs and it's something that will come up when we have global WiPrs, Some WiPr have instances on LOTS of wikis, do we show (for example) 50 cards for a WiPr that exists on 50 wikis? Or should we indicate those 50 wikis on the one card somehow?

Find the latest designs
Desktop prototype
Mobile prototype

By the way, for me starting local means that we will have the wiki filter and default to the local wiki or the 3-4 wikis that we want to pilot.

We can portray the Wiki of the WikiProject as shown

In T368115#10051412, @VPuffetMichel wrote:

@gonyeahialam I think we should also note on the "card" the wiki the wikiproject is on. On your designs, there are two cards/boxes for wikiproject women in red. The user would need to know which wiki it is on to be able to choose the one that interest them.

For instance if I filter by fr.wiki and en.wiki,
I will have two cards/boxes for the women in red appearing (assuming Women in red is on both of those wikis), as a user, I want to know the wiki that project is on to be able to choose the right one.

Regarding WikiProjects specifically, it's not just about filters. There's also the possibility that a wiki has no WikiProjects at all, or just not any of those in the initial batch that we'll be using.

In T368115#10049797, @Daimona wrote:

In T368115#10048539, @gonyeahialam wrote:

I would like your feedback to this update to the filter @Daimona @MHorsey-WMF @VPuffetMichel

Should be doable, but is the topic MVP?

I guess that will be based on T370951: Investigation: How do we get WikiProject topics, as defined by LiftWing?

Here is my proposed design for when the selected filters produce no results @MHorsey-WMF @Daimona @VPuffetMichel Let me have your feedback.

Based on the feedback at the team meeting:

Changes based on the survey feedback

Excerpt from Community List Design Feedback Survey Report

Mobile Community List Prototype

Desktop Community list prototype

In T368115#10023721, @ifried wrote:

Thank you, @gonyeahialam! It is great to see these updated designs. One note is that both topics and wikis are important. For example, if I am user of the Community List on Meta-Wiki and I only speak Arabic, I need to know which WikiProjects that I can engage with, as an Arabic speaker. If a WikiProject is only in English, then it would not be very useful for me to learn about it.

Desktop design for Community tab

Desktop design for events tab

The most useful grouping for users will be by topic.

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?

A longer explanation:

@Daimona When the you hide ongoing events:

High fidelity designs for Community list, mobile web version

In T368115#9998529, @Daimona wrote:

In T368115#9998433, @gonyeahialam wrote:

@Daimona Can you expand more on the challenges of having a filter that applies to both events and Wikiprojects even though all the filter options aren't always going to be applicable to both?

If I understand your question correctly, it's more about the UX than a technical challenge. While events and wikiprojects are similar in certain aspects, they are also different in others. For example, it wouldn't make sense to filter wikiprojects by date or meeting type, and it wouldn't make sense to filter events by active vs inactive. From a user's perspective, if all filters are in the same place, I wouldn't immediately understand which filters work for which section.

@Daimona Can you expand more on the challenges of having a filter that applies to both events and Wikiprojects even though all the filter options aren't always going to be applicable to both?

As mentioned above the best solution should give contributors an overview and understanding of the two ways to contribute/collaborate (Events and Communities/groups). Understanding can be achieved through info like a clear title, description and examples. Such solution should probably prioritizes Events over communities based on my assumptions above. Even if events are prioritise it should give enough info about communities to make the contributor want to check it out.

Community list mobile exploration (wireframes)

Okay, great @Daimona @vaughnwalters

The text is:
Ul text S/Regular

• @font-size-small @line-height-small @font-family-system-sans

@font-weight-normal