Some notes from our team meeting with the ambassadors to share some ideas:

• The 'show everything in 1 page' with 2 columns view may be a good starting point, since it allows people to discover everything in one place (though perhaps more challenging for mobile?)
• Perhaps default view for WikiProjects can be recommendations based on editor contribution history, but they can apply search filters
• "The less we can explain and the more we can get people to act, i think that is better for sustainability of the feature"
• Is it possible to have events that are linked to WikiProjects? For example, a color change or indicator that shows that this event is linked to a WikiProject. This may interest people since they may want to join a campaign that is tied to a WikiProject.
• Maybe we can have an entry-point from the Newcomer Homepage.
• WikiProjects are spaces where people can engage and find stuff to work on, but many community conversations happen off-wiki in things like Telegram groups. It is important to have this in mind. Maybe we can make it easier for people to find/discover the Telegram links.
• If we have events and WikiProjects in 1 page, it would be interesting to see what people choose to join or participate in. For example, how many people join a campaign event vs. a WikiProject? Do we have ways to measure this data that can help us learn and how they come in contact with the page?
• Most WikiProjects do not have a date/time. A WikiProject can contain many campaigns and/or events. If we want to display them in one page, it is not easy, but it could be a good opportunity/strategy to include the WikiProjects into the projects we are working on.
• Many WikiProjects are not very active (dormant/in hibernation), but maybe people can be inspired to revive them?
• In the event form, if we have an additional field to ask for WikiProjects, it can force organizers to ask if their event is a part of a WikiProject. And we could get data/metrics on which events do & do not have WikiProjects attached to them and see which ones are more successful.
• Event organizers can learn about wikiprojects, and wikiproject organizers can learn about campaign events

Draft ideal user journey for finding communities(like Wikiprojects) and events (like campaign events)

Some design explorations

An onboarding screen explaining what WIkiprojects and campaign events are

Wikiprojects and Campaign events in separate tabs with individual filters

WikiProjects categorised by topics

Wikiprojects and Campaign events on the same page in different sections.
Wikiprojects related to the filters and events are shown by the side.

More explorations

Concept: Have Events and projects on the same page

Combined together with the same filters

Same filters but separated by a toggle filter

Separated by a toggle filter but with unique filters for each category

Separated by tabs

Design exploration

Note: These are low fidelity wireframes focused on the layout mainly. More detailed design of the details will be done later.

Here I am exploring arranging events and Communities (Wikiprojects) by topics.

Exploration 1

Step 1: The contributor selects the topic they are interested in.	Step 2: Then they see all the events and communities around that topic
	Layout A: The events and Wikiprojects are arranged in separate columns	Layout B: Wikiprojects are shown, then Events

Exploration 2

Step 1: Based the topics contributors selected during account creation or their editing history or other ways we get their interest,	Step 2: they see a tailored list of events and communities
	Layout A: WikiProjects and events are grouped according to the different topics the contributor has shown interest in.	Layout B: The Wikiprojects and events are not separated by topics but combined together

Based on some internal feedback, the 2 column layout was seen to be more clear.

The events and Wikiprojects are tailored based on the topics the contributor is interested in. We can use the topics contributors selected during account creation or their editing history. These defaults are reflected in the filters so the contributor can modify it any time.
The Wikiprojects closest to the contributors interests are shown and they can click on "See more" to view a full list of all communities with filters.

Some entry-points we can explore for community list:

1. Adding it to the user home page as illustrated below

2. Adding it to the user profile menu

3. Prompting contributors to join events or communities related to the article they are editing on the Editing page

@gonyeahialam and I are talking about some of these design explorations, and here are some notes on ideas & questions that have come up:

• Stuff that I think works well
  • Calling it ‘communities’ rather than wikiprojects
  • ‘See more communities’
• We should aim for something that is mobile friendly, since I could see this being heavily used on mobile
• The first design for the MVP should be very simple since the goal is to deliver something quickly so we can begin to collect insights from collaboration with WikiProject organizers
• The first design for the MVP can assume that we will have a smaller number of WikiProjects at first that we work with (for example, between 15 to 50)
• After the first design with just adding WikiProjects, we can assume that we will add wikis and topics for events/communities
• The preference so far is design that allows everyone to see all events and all wikiprojects, since we will start with only a few wikiprojects at first without filters -- but how could this work well for mobile?
  • Where do we put communities? We probably don’t want it to be at the top or bottom of the page, since it may make it hard to find other data. Maybe separate tab? Or just show some of both?
• What info do we want to share about WikiProjects?
  • At first, we should probably focus on only sharing information we already have or can easily get. One way to do this is to see what data we can get from Wikidata (for example, see https://www.wikidata.org/wiki/Q23875215), which is: name, description, founders, logo
  • We should ask in the surveys, but maybe: topic, 1 sentence summary, maybe image/logo?, maybe creation date?, wiki of wikiproject
• Priority is to add WikiProjects to Event List first, followed by additional search filters such as wiki and topic

@ifried What info do we want to share about WikiProjects?
At first, we should probably focus on only sharing information we already have or can easily get. One way to do this is to see what data we can get from Wikidata (for example, see https://www.wikidata.org/wiki/Q23875215), which is: name, description, founders, logo
We should ask in the surveys, but maybe: topic, 1 sentence summary, maybe image/logo?, maybe creation date?, wiki of wikiproject

The logo is a good one because organizers said in Event Discovery Ideas Feedback Report, that they want engaging graphics, logos, and visual elements in the the eventlist.
Also, the description could contain any of the information needed below or provide general information to help the contributors decide if they should attend or not.

From the Campaigns event discovery survey report, the most important information editors said they need to decide what events to participate in include:
Top 3

1. Subject matter, theme or topic of the event
2. Participants’ level of expertise and knowledge or level of expertise required by the event
3. Main activity of the event (writing articles, taking photos, adding references)

Next 2

1. Date and time of the event - Personal availability)
2. Location

From Event Discovery Ideas Feedback Report, we also know that Wikimedia project of the event was important for organizers.

Many of these could still apply to Wikiprojects. We can learn more from research.
Since we do not have many of these information, we can start with what we have and identify what other data that we have that can give an idea of the above and help contributors decide what events or communities to join.

Thank you for sharing this, @gonyeahialam!

+1 to the importance of imagery. We also learned in the Invitation Lists experiment that event pages with graphics and images tended to perform better in terms of attracting new registered participants. If we do take the images/logos from Wikidata though, we'll need an empty state, since not all of them have images uploaded.

I also learned in a chat with @Sadads that there is a technical way that we can link the 'subject' data from Wikidata with the topical model in LiftWing (which is what we'll want to use). So we could probably get topics/subjects as well (though the engineers will need to investigate).

Great points too about skills needed and activities that will be done. We don't collect this data yet, but it is something for us to think about in the future.

As for location, perhaps the work being done in the scope of T361052 can help us later add in geocoding support.

Overall, I agree that we should first focus on the data we can get from Wikidata (or other sources) and then we can see what feedback we get about gaps or needs related to data.

Community list mobile exploration (wireframes)

Goal: How might we design the layout of community list on mobile and desktop in a way that contributors have an overview of the two ways to contribute/collaborate (Events and Communities/groups) and understand them?
Examples of info that give an overview and will help contributors understand:

• Clear title
• A description
• Examples

Some other considerations:

1. If we are working with events and communities, should one be prioritize over another? Would contributors have a preference for one or the other?
   • Can we prioritize events since it is currently event list and we are adding communities?
   • Are events a faster way to get started in collaborating than WikiProjects hence the need to prioritise first?
2. Technical feasibility of a single filter for both communities and events

Concept 1

• This gives an overview of the two options, a title, description and examples are present for both.
• Though Events are first, this layout gives roughly equal prominence.
• It uses a single filter for both events and communities
• Clicking on 'See all' expands the list in full

2A. This uses a single filter for both events and communities	2B. Separate filters for both

Concept 2

• This gives an overview of the two options, a title, description and examples are present for both.
• Events are given more prominence. The most relevant communities to the user (based on filters) are shown on this page and the 'see all' for communities takes you to a different page dedicated to communities as shown below.

Events page	Communities page

Concept 3

• This gives an overview of the two options.
• It shows the title, description and examples for events but only the title for communities.
• Prioritizes events by showing the event tab as the default.
• It has separate filters for each.

Events tab	Communities tab

Concept 4
This page gives an overview of the two options.
It shows the title, description and examples of events and communities.
This page focuses on events with a button to take you to the communities page. But in a strategic place on the event list relevant wikiprojects are shown to the user, the see all directs him to the Communities page

Concept 5

• Gives overview of the two options, shows the title, it can also show descriptions using accordion descriptions. But now examples are shown.
• Both are treated equally, none is prominently

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.

The concepts that achieve these best among those above are concept 4 and a modification of concept 3 to include communities within event list

Concept 4	Concept 3 modified

@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?

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.

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.

Okay. If it is mainly a UX problem then that is solvable.

High fidelity designs for Community list, mobile web version

@gonyeahialam The high fidelity designs look great. This is totally a good starting point for the engineers.

Have you explored what kind of groupings would make sense for wikiprojects?
For events, we group them by date.
For wikiprojects, we could group them by topics. What else?

@gonyeahialam, yes, these designs are a fantastic starting point, and I loved that you looked at what data we can get from Wikidata as a way to provide context to users on the WikiProjects. +1 to the question of how we can group WikiProjects to provide filters to users. I think the groupings could potentially start with: wiki(s) of WikiProject & topic(s) of WikiProject. It would be good to explore how those filters could work/look.

@ifried @VPuffetMichel

The most useful grouping for users will be by topic.

We can also group by type/focus of WikiProject. As written in the definition WikiProjects, they focus on;

• a specific topic area (for example, WikiProject Mathematics or WikiProject India).
• a specific part of the encyclopedia (for example, WikiProject Disambiguation).
• or a specific kind of task (for example, checking newly created pages).

Desktop design for events tab

Layout of the event tab

Option 1: Exactly the same as mobile, with related events within the event list	Option 2: Take advantage of the width on desktop to show a few related communities by the side rather than within

Level of information on related communities
Using the extra space on desktop to show more information on the related communities on the events tab

Though I am yet to decide the most usable option the engineers have said all options are doable.

Desktop design for Community tab

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.

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.

Yes, you are correct. One thought that comes to mind based on your explanation is that the real goal(for the main use case of finding events/communities to join) isn't necessarily knowing what wiki but knowing what skill is required e.g editing in spanish, editing in arabic... While experienced editors may understand the relationship, newcomer editors may not.
While still retaining the Wikis info I see an opportunity in the future to additionally phrase this in terms of skill. Newcomer editors aren't necessarily asking what wiki is this event but rather can I participate in this event.

Yes, thanks for this feedback, @gonyeahialam! I think that, once we get info on the event type (such as if it is a photo contest, an editathon, a meetup, etc), then we can also inform users about what skills are suited for the event.

Desktop Community list prototype

Mobile Community List Prototype

Excerpt from Community List Design Feedback Survey Report

Summary of Feature Requests, Improvements, and Modifications

Clearer Search
Clear Search Bar: A more prominent and intuitive search bar, similar to the main Wikipedia search, with a magnifying glass symbol.

"A clearer search function, as stated before. Meaning a search feature similar to the main Wikipedia search function, whereby you have the magnifying glass symbol to search, rather than having to go into filters to search by keyword.”

Filters

• Filter options: Options to filter events and communities based on relevance, such as targeting specific types of participants (e.g., new editors, experienced trainers), date, location, activity level, event-type filters (e.g prize/gift-based contest, article creation or destubbing events ), areas of contribution (photography, uploads, research, data).
• Prioritize certain wikis in the Wikis selection list:

“please set pages like Commons, en.wp, de.wp, fr.sw at the top of the selector list ("Wiki"), a standard selection (en.wp if this is your home community e.g.) would be helpful”

• Permanent pre-selection: Set default filters to be applied always instead of always filtering to find events or communities of interest.

Activity Indicators and Relevance

• Activity Level Indicators: Visual or textual indicators showing how active a project or community is.

Visual and Aesthetic Improvements

• Welcoming Design: Aesthetic changes to make the interface more inviting, particularly for newcomers.
• Visual Distinction: Use of images, icons, or clip art to visually differentiate content and make the design less monotonous.

Additional Information and Guidance

• Participation Guidance: Links or sections providing information on how to get involved in projects or events, either generally or specifically per project/event.
• Event Descriptions and Details: Clear descriptions of events, including what they are about and any specific roles needed.

Geographical and Language Considerations

• Location Filters: Filters to search for events based on geographical location, including postal code.
• Language Filters: Options to filter content based on language, supporting multiple languages and localized keywords.

Membership and Participation Features

• Community Membership Tracking: Indicate whether the user is already a member of a community on the community list.
• Symbols for Training/Support: Icons or markers indicating events that offer training or support for newcomers.

Specific Additional Features

• Exclude Tags Option: An option to exclude certain tags/topics from search results.
• Support for Task Forces: Additional support and visibility for task forces within projects and events.
• Date Tracking: Add additional labels showing when events are starting soon for example - Staring in 3 days, Starting tomorrow, Ongoing, Ending soon - rather than just full dates.

View full report here

Changes based on the survey feedback

Clearer Search
I brought out search from the filters dialog and placed it directly on the page so users can easily access it.

Activity Indicators
I added labels on each wikiproject and filters for the community list showing how active a wikiproject is.
One of the most important information that participants seek about WikiProjects is how active they are. If a Wikiproject is inactive, they can't effectively participate in it. Letting them know beforehand rather than finding out the hard way will help them decide whether not to join or to join and work on reviving it (It will be helpful to provide info on how to revive inactive Inactive wikiprojects).
Where to get the data: There are wikiproject directories which state what projects are active or not. Also, we can use some existing data we have to estimate the activity of a wikiproject, for example the last post on the wikiproject talkpage in the last one year. Even if we don't do it now, it is something to consider for future plans.

Permanent pre-selection
Users don't want to input their preferred filters each time they visit the community list. To solve this I added a checkbox a the bottom of the filter dialog to save/remember their filters and have it applied any time they visit the community list. I also added a button for them to clear this saved filters if they no longer want it.

Topics listed out in the filter

In the Wikis filter, Wikimedia projects that are not based on language (like Commons) are shown first before those with various language wikis. This way these wikis are not pushed to the bottom of the list by the length of the language wikis

Based on the feedback at the team meeting:

• I have removed the activity level from each wikiproject card and the community filters

• The 'remember filter preferences' checkbox and 'clear filter preferences' button as explained above was removed in favour of a simpler solution where whatever filter the user selects in one session will be the default automatically in the next visit to the community list. On the community list, there is no way to know that certain filters have been applied to the list without opening the filter dialog. So users may not know they are seeing a smaller list. To solve this I added a number to the filter button label and added a reset filter button. These only show when a filter is applied and will notify the user about it so they can clear/modify it if they want to.

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

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

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?

In T368115#10049085, @gonyeahialam wrote:

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

I'm not sure if I understand what, if any, changes to the events list are in scope for this task.

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?

In T368115#10049085, @gonyeahialam wrote:

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

I'm not sure if I understand what, if any, changes to the events list are in scope for this task.

Are you approaching this as a completely different project or just modifying the eventist to become community list?

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.

I will work on that

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.

Here is the message for this scenario @Daimona

@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.

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.

Since we are starting local, it means they will only see the version of the Wikiproject for that wiki. Do you still think this will be necessary?

@gonyeahialam

I think it is useful to have as it removes ambiguity. Just share where you’d have it on the card as you’re going to go on parental leave. It’s better to get your thoughts. We can then decide to include it at a specific stage of the MVP.

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.

Personally, I’d add it from the start as it is just one piece of information to add to the card, not a lot of extra work on the engineering side.
If we do not add the wiki filter with “default” as suggested above, then we add the filter, it will then just work when we add the wiki filter.

We can portray the Wiki of the WikiProject as shown

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.

@VPuffetMichel I thought starting local meant we are only going to be able to show the WikiProjects of of the Wiki a user is on

Find the latest designs
Desktop prototype
Mobile prototype

Ok, this is a lot so I'm going to try to pick out important points here.

@Daimona AFAIK MVP is simply listing local wiki project pages
@VPuffetMichel This means no wiki/language filter initially?
@gonyeahialam Topics are most definitely not MVP, it's too big a topic to approach here

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?

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?

I believe this is out of scope for the MVP since we are starting local.
One option which I mentioned in slack and which is portrayed in the current design:

"From my little research,
These Wikiprojects across various Wikis appear mostly independent from one another, with different members and processes.
Based on this, my thought was to treat them separately. If a user has a wiki selected in the filter (or we work with local first) only the version of the Wikiproject on that Wiki is shown and if no Wiki filter is selected then all the variations of that Wikiproject are shown separately on the list and would link to their respective pages."

Another option is to have a general Wikiproject item and when users click on it they get to see the full list of all the variations or the option to select the language.

I prefer the first option because it works better with the filters. If users select for example filters for ig.wiki and en.wiki they will only see the WikiProject Women for igbo and english wikipedia but with the 2nd option they will need to go through 1 or 2 more steps to find the specific Wikiproject.

More solutions can be explored for this if needed when we decide to work on it in the future.

I believe this is out of scope for the MVP since we are starting local.

Absolutely yes it is out of scope, I was just curious of the intention going forward. Thank you for your clarity @gonyeahialam :)

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

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?

Yes it can be moved

@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#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?

Done