Adding @nayoub @AAlhazwani-WMF as well for visibility and consideration for overall Contributors design strategy. As part of goals of a more unified, simplified UX for editors, a key design exploration is how might the existing Campaign Updates module in the homepage, which only supports 1 spotlight event by a community be revised and updates to incorporate this more comprehensive, discovery-centered list of many events.

Another useful resource is this task, where I've been compiling community feedback on desired improvements for the Community Updates module.: T365890: [EPIC] Community updates module - second iteration improvement ideas

Collaboration List Module on the Newcomer Homepage

Report on Early Design Explorations

Executive Summary

This report explores the integration of a Collaboration List Module on the Newcomer Homepage to help newcomers discover events and WikiProjects.

1. Understanding Newcomers

1.1 Who Are Newcomers?

Newcomers are users who have created a new account and are logged in to the wiki. Research indicates that most newcomers create their account from a reading context and are looking for ways to orient themselves within the Wikipedia ecosystem.

1.2 Some Key Newcomer Goals

• To create new Wikipedia articles
• To add or change information in existing Wikipedia articles

1.3 Some Newcomer Behavior Patterns and Insights from Growth Team Research

• High Drop-off Rate: ~94% of first-time editors don't return to make a second edit
• Orientation Seeking: Large numbers of users view their own User or User Talk page on their first day, looking for some sort of "homepage", "dashboard", or "profile page" where they can orient themselves
• Help Seeking: Many view help or policy pages on their first day
• Initial Engagement: A majority open an editor on their first day, but about 25% don't save an edit
• Account Creation Context: Most users create their account from a reading context
• Impact of Reverts: Reverting a newcomer's edit negatively impacts retention
• Community Interactions: Effective socialization and positive interactions with established community members improve retention
• Engagement Tools: Emails & notifications increase newcomer engagement
• Newcomer Preferences: Newcomers want a personalized onboarding experience
• Structured Tasks: Structured tasks help bridge the technical & conceptual knowledge gap that newcomers experience, and help guide newcomers through their first edits

2. Barriers to Newcomer Success

Newcomers face three primary categories of barriers:

2.1 Technical Barriers

• "What is an info-box?"
• "How do I insert citations?"

2.2 Conceptual Barriers

• "What is notability?"
• "What is a citation?"

2.3 Cultural Barriers

• "Why are people so mean?"
• "Why don't I get responses to my messages?"

3. Current Newcomer Homepage

The Newcomer Homepage currently hosts several modules that support newcomers in their first experiences with Wikipedia:

3.1 Existing Modules

• Suggested Edits Module: This feature is the main component of the Growth features that is increasing how many newcomers make their first edit, come back to make more edits, and the number of edits they make
• Mentorship Module: Assigns each newcomer an experienced user, and gives an easy way to post questions to the mentor's talk page
• Help Module: Lists links to commonly visited help pages
• Impact Module: Shows newcomers the number of page-views on each of the articles they have edited
• Community Updates: Admins can configure an update to highlight community initiatives or newcomer-friendly opportunities

4. Collaboration List Opportunity

4.1 Current State of Collaboration Discovery

Research consistently shows that users struggle to find meaningful opportunities to collaborate on topics they care about. The current Collaboration List helps people find events or communities (WikiProjects) but has discoverability issues.

4.2 Benefits and Support of Collaboration List for Newcomers

• Shows multiple types of collaboration opportunities (events, WikiProjects) that can be filtered for different user needs
• Provides guided opportunities and clear pathways to contribute
• Facilitates positive interactions with experienced editors, improving retention
• Offers support for overcoming technical and conceptual barriers
• Connects newcomers with topics they care about, increasing motivation
• Creates a sense of belonging that helps combat the 94% drop-off rate

5. Implementation Considerations

5.1 Design Guidelines based on understanding of Newcomers and Newcomer Homepage

• Personalization: Personalize collaboration list based on the experience level of newcomer or stage in the onboarding process and their interests.
• Clarity: Explain what events and WikiProjects are in a way newcomers can understand
• Content Prioritization: Prioritize the most relevant content based on newcomer needs and goals
• Progressive Introduction: Avoid overwhelming users with too many options at once.
• Engineering Work: Think about how hard it will be to implement.

5.2 Integration Options

1. Expand Community Updates Module to include Collaboration List
   
   Pros:
   • Natural extension of existing functionality
   • Already aimed at connecting newcomers with community activities
   • Familiar location for community-related information
   • Consolidates similar information in one place
     
     Cons:
   • Could become cluttered with too much information
   • Perhaps potential conflict with admins/community on the use of Community updates module since updates are community controlled and collaboration list data isn't.

2. Create Standalone Module
   
   Pros:
   • Clear, dedicated purpose
   • Full flexibility in design and implementation
   • Can be positioned appropriately in newcomer journey
   • Allows for comprehensive filtering and features
   • Won't impact existing module functionality
     
     Cons:
   • Adds another module to potentially cluttered interface

Design Explorations

I explored several designs for integrating the Collaboration List Module into the Newcomer Homepage.

I present 3 design concepts below to give an idea of what the Collaboration List Module could look like on the Newcomer Homepage. These concepts apply to both integration approaches but i mostly focused on integrating with the Community Updates module.

Concept 1: Full Collaboration List on the Newcomer Homepage

Community Updates Module together with Collaboration List on Right of the Newcomer Homepage	Community Updates Module together with Collaboration List on Left of the Newcomer Homepage	Collaboration List Separate from Community Updates

Challenges with integrating the Full Collaboration list

While implementing the full collaboration list UI on the Newcomer Homepage may be technically simpler since it largely replicates the existing collaboration list page, it presents several key challenges:

1. Information Overload
   • Shows too many details at once, overwhelming newcomers still learning basics
   • Newcomers are already trying to learn Wikipedia fundamentals

2. Space and Layout Issues
   • Takes up excessive vertical space
   • Pushes important modules like Impact too far down

3. User Experience Concerns
   • Too many filtering options and details can overwhelm newcomers
   • Moving Community Updates left under Suggested Edits still doesn't resolve core issues

Recommendation: NOT RECOMMENDED

These challenges persist even when you move Community Updates left under Suggested Edits

Concept 2: Simple Link Integration

Simple Link Example

This concept focuses on adding a basic link to collaboration list page within the existing interface.
It offers a clean and simple design that introduces collaboration without overwhelming details, while taking up minimal space and preserving focus on core newcomer tasks.
But it still presents some key challenges:

1. Low Engagement Potential
   • Without showing actual events, newcomers may not understand the value or be motivated to click

2. Extra Steps Required
   • Forces an additional page load and navigation step to see any actual collaboration opportunities

3. Limited Discoverability
   • Only somewhat improves the discoverability problem since content remains hidden

4. Generic Appearance
   • Might be overlooked as just another help link rather than a pathway to community engagement

Recommendation: BACKUP IDEA

This concept addresses the space and complexity concerns of Concept 1, but swings too far in the opposite direction. While it avoids overwhelming newcomers, it may not provide enough immediate value or context to encourage engagement with collaborative opportunities
This idea can be used to start if we don't implement concept 1 because of its issues and are not able to personalize the collaboration list as shown in concept 3 below.

Concept 3: Personalized Collaboration List

This concept focuses on personalizing the collaboration list based on the newcomer's experience and interests as described in the design guidelines section and newcomer behavior patterns and insights sections above.

Accordion Closed State	Accordion Open State

Advantages

1. Balanced Information Density
   • Shows enough content to be useful (maybe 4 or 5 personalised and prioritised events) without overwhelming the page

2. Progressive Disclosure
   • The accordion design allows users to expand/collapse based on interest, reducing initial cognitive load

3. Personalization
   • Events and communities are selected based on newcomers' topics of interest and the wiki they are on.

4. Efficient Space Usage
   • Takes up reasonable vertical space while keeping other modules visible

5. Essential Details Only
   • Shows just the critical information (event name, date, location, topics) without overwhelming filters

Challenges

1. Discoverability Concerns
   • The collapsed accordion by default might reduce awareness of collaboration opportunities.

2. Balancing Algorithm Needs
   • Requires good personalization algorithm to select truly relevant events. More on this below.

Recommendation: RECOMMENDED

Concept 3 strikes a good balance between providing useful information while respecting the newcomer's level of experience with Wikimedia. The accordion approach combined with personalization addresses most concerns identified in the previous concepts.

The discoverability issue can be addressedby having the accordion expanded by default for first time visitors, then respecting the user's preference on subsequent visits. Though the colllaboration list is now much shorter, if expanding it by default will still push important modules to far down we can move the module to the left hand side below the suggested edits module.

Overall, this concept aligns well with the research on newcomer needs and behavior patterns.

Ways to Personalize and Prioritize the Collaboration List in Concept 3

We currently don't collect information on what event is suitable for newcomers which would be very helpful but we can still use other information to personalize and prioritize the list.

Major Personalization Options

Topics of Interest

We collect topics that an event is focused on and when a newcomer is setting up their homepage they also get to select topics of interest. Using this information we can tailor the list of events to the topics the user is interested in.

Wikis

We only show events and WikiProjects that are on the the particular Wiki the user is viewing the newcomer homepage on. Newcomers may not know that there are other wikis available on Wikimedia so we don't need to give them the ability to filter by Wiki or see such information.

Other Personalization Options

Experience Level

A questions we should ask is: Can a Newcomer who just created an account and has made no edits find an event/WikiProject, go to the event page, understand what is happening, what to do and start contributing?
Depending on the event structure the answer may probably be no. So just like the community updates, we can limit the visibility of the collaboration list to only those who have at least made 1 or more edits or completed 1 newcomer task. We can also say that to participate in WikiProjects effectively perhaps needs more experience and therefore show the communities section to newcomers with maybe 10 edits. This way the Newcomer homepage will be more focused what a newcomers needs at each stage in their onboarding journey.

Group Chat or Meeting Link

Some events have a group chat or meeting link. We can decide to prioritise events that have such, since newcomers would have a familiar place to communicate with other participants and organisers and ask questions. Such a group would be a great way for newcomers to socialize and feel supported, which may in turn increase retention rates.

Date and Time

Currently in the collaboration list page you can find past, ongoing and upcoming events, the page also has 2 accordions sections, 1 for ongoing events and the other for upcoming events. We can remove all these sections in the Newcomer homepage and only show events that are just starting the today upward since newcomers may not have the experience to participate effectively in event that has already started.

Location/Meeting Type

Events happening physically near a newcomer would be very helpful for them since they can meet members of the community face to face and get in person support. But since we may not have the location of the newcomer, they would likely see in-person events that are far away from them and are therefore not useful. So we can decide to only show online events.

Relevant Information

As discussed above and shown in concept 3 design, we have removed the filters, the ongoing and upcoming sections and the date headings. For the event item we can still simplify things by removing information that is not relevant to a newcomer at that time. Currently the event item shows: Event name, Date, Meeting type/location, Topics, Wikis and Organizers. We can remove Wikis since newcomers may not be familiar with such concept and we have already tailored the list to show only events of the Wiki the newcomer is on. We can also remove the organisers because newcomers don't need it at this point. I kept the topics because even though we already personalize the list based on topics since we don't have descriptions on each event item, topics give the newcomer an idea on what it is about. They can still see the full information when they go to the event page.

Conclusion

These are some of the ways we can personalize and prioritize the collaboration list. Some of the options here may be more difficult than others to implement. We can start with a few that we find to be the most accurate and impactful for newcomers and require less effort.

You can read my report (the last two comments) on my initial explorations for the integrating the Collaboration List on the Newcomer homepage. I would love your feedback. Thank you.
@RHo @AAlhazwani-WMF @KStoller-WMF @Astinson

@gonyeahialam I like the recommendations -- one of the things that has always stood out to me is that we should be using more of the Newcomer Growth tools to gather data that influences the offerings for the newcomers.

Hello @gonyeahialam, thank you for this detailed breakdown of your thought process! I already shared some of my thoughts in our team discussion on Monday, but I'll also write them down here, so they can be commonly viewed for documentation & discussion purposes:

• I agree that we should not show a full version of the Collaboration List on the Newcomer Homepage. It would be very dense with information and probably feel overwhelming to the user. This would go against the vision of the Newcomer Homepage -- i.e., providing simple, clear tasks for newcomers to make their first edits and find support/a sense of impact related to their work.
• I agree that the third approach is the best option -- i.e., show a shortened version of the Collaboration List that shows a few events, ideally tailored to the interests of the user and the wiki that the user is on. I do think that it is important to note that we may not have events that fit this criteria for some users. In that case, I think we may still want to show events in other topical areas (but not events in other wikis). This is because we want to show users that there are opportunities to connect with others - and some events may end up being appealing or interesting for reasons other than topics (such as being opportunities to learn/connect/collaborate), even if they're not in the user's favorite topical areas. So, my recommendation is to prioritize topical match, but not to limit to only topical match.
• I think the second approach (i.e., a link to the Collaboration List) will have very limited impact, and I would advise against it as a secondary approach. This is because we want people to discover opportunities on the Newcomer Homepage, rather than relying on them to go decide to go somewhere else to learn more. With option 3, while we may not show all of the events/WikiProjects on the Newcomer Homepage, we at least show some events/WikiProjects, which lets the user know a bit about the Collaboration List (and events on the wikis in general), so they're more likely to take action or next steps.
• I agree that we should show on upcoming events, but not ongoing events.
• I'm not sure that we should limit who can see the Collaboration List. You mentioned only showing the Collaboration List after someone has, say, 1 edit or completes 1 structured task. To me, somebody who has made 1 edit/completed 1 structured task is not much more familiar with the wider Wikimedia ecosystem than an absolute beginner. This is a very low barrier to entry (but not a meaningful distinction in this case, I think). So, let's say we then required 10 edits or 10 tasks. Then, we're restricting a whole lot of newcomers who may benefit from learning about events/WikiProjects. Overall, my thinking is that we should show the Collaboration List to all users, since the idea is that all people (including newcomers!) should be aware of the fact that opportunities exist for them to connect and collaborate on the wikis. Meanwhile, the Community Update module has the option to show certain events to only editors with a minimum number of edits because it is curated and customized by admins based on 1 specific event at a time, so it is a different use case and audience.

ok, there's a lot to unpack here. i'm going to try to go step by step.

what is the end goal of this project? as i'm reading the user story, i'm unsure about the specific signals that will enable us to learn and observe behavioral change. is this about bringing newcomers to the special:allevents page? is this about newcomers registering to an event? is this about newcomers publishing a quality edit as part of an event? is this about organizers finding participants? something else? this information is instrumental to evaluate and assess the different design proposals. and thinking of newcomers, are we thinking of all newcomers, or a specific subset?

that said, i'm going to focus only on "concept 3" which seems to be the preferred option between phab and slack feedback. i'd like to evaluate this proposal through a content-first, and mobile-first lens.

if there's already a community update, my recommendation would be to not add other events to the homepage. i'd like to respect the community intent, and promote the event of their choice. in this scenario, could we think of adding a link to the special:allevents page? i have more comments on special:allevents that i'll share below***.

if there's no community update, we could then explore how to surface events directly in-homepage. my suggestion would be to display only one event, front and prominent. and pick the most relevant event possible, based on available newcomer preferences and information. did they edit anything before? on which wiki? how often? on which topics? i would also try to identity what information is the most valuable for the newcomer to take action. is it important to know about the start/end date? is it important to know about the location? i would try to make as many smart decisions as possible, and reduce cognitive burden for newcomers.

we could also explore how to make the event dismissible, and potentially create a learning opportunity for us. why did newcomers dismiss it? maybe it wasn't a relevant event for them? or maybe they did not understand what events are? something else?

i also agree with @gonyeahialam discoverability concerns. i would not hide content in an accordion, nor add tabs inside an accordion. the page is already information-heavy, and nesting information might make it much less discoverable, especially on mobile. i would also not expose newcomers to the concept of 'communities', yet. see comments below***.

if there is no existing newcomer information available that would enable us to provide a strong recommendation, we could explore a module that introduces the concept of events. as @gonyeahialam pointed out, newcomers might not be familiar with the concept of 'collaboration list', 'events' nor 'communities'. would it be worth exploring a more educational approach and link to (a filtered version of) special:allevents? more below***.

***comments on special:allevents

before bringing events to newcomers, i'd like to suggest to invest more in newcomer- mobile-specific optimizations.

if we would redirect newcomers to special:allevents they will be prompted with 3 new concepts: 'Collaboration list', 'Events', 'Communities'. there is currently no explainer about those concepts.

moreover the whole page is filled up by the filters, which is pushing the actual content (events) much below. we could consider implementing something to collapse the filters. for newcomers landing on this page, i'd also suggest defaulting to specific filters to reduce cognitive load.

filtering to a specific wiki (eg. it wiki) still shows many events in other languages. most organizers mark their events as open to all wiki, but then content is displayed in their language, which might be problematic for newcomers.

the 'Communities' tab is confusing. supporting materials are not translated (in italian, and that might be the case for other wikis) and several of those projects are not optimized for mobile. moreover tapping on the edit pencil brings newcomers to wikidata which might be confusing.

the current layout doesn't feel optimized for mobile, and might benefit from minor adjustment to increase the information density, and improve the content hierarchy.

finally, i would suggest to map the whole experience and visualize all the steps (and screens) and conditions that need to be true to bring events to newcomers, and bring newcomers to events. what needs to happen before an event is displayed on the newcomer homepage? what happens when the event is live on the homepage? what happens when a newcomer taps on an event? what happens when a newcomer tries to register (and later participate) in an event?

apologies for the long message, but i wanted to provide as much specificity as possible. i hope this is helpful!

I'm excited by the opportunity to surface community-organized events on the Newcomer Homepage. I think the main benefit of the collaboration list module would be to let newcomers know that they can meet other people, and develop as an editor, by joining an event. With that in mind, I tend to agree that it might be enough to show the community update and one very relevant event (if available), with a link to the full list. Repeating what others have said here, I would select an upcoming online event from the current language wiki that matches one of the newcomer's topic interests.

The collaboration list includes a wide variety of events and I worry that many of them would be more confusing than appealing for newcomers, for example, office hours, trainings for Central Notice and event tooling, and sessions about the Universal Code of Conduct. For now, I would only show contribution events like editathons and media upload events. I understand that we're not implementing event types yet but hope we could find a way to filter for this.

Looking at the collaboration list in the context of the Newcomer Homepage, I also noticed that the event titles are not always descriptive enough. I wonder if we should review the guidance we give in the event registration tool UI and/or our event registration trainings?

(removed previous comment because I pressed 'submit' too early)

Thank you so much for providing this thorough breakdown of your thoughts, @AAlhazwani-WMF! It has helped bring up some really important conversations within our team, and I'll respond with some ideas/responses now, but I think more will come up over time.

In T387793#10628882, @AAlhazwani-WMF wrote:

ok, there's a lot to unpack here. i'm going to try to go step by step.

what is the end goal of this project? as i'm reading the user story, i'm unsure about the specific signals that will enable us to learn and observe behavioral change. is this about bringing newcomers to the special:allevents page? is this about newcomers registering to an event? is this about newcomers publishing a quality edit as part of an event? is this about organizers finding participants? something else? this information is instrumental to evaluate and assess the different design proposals. and thinking of newcomers, are we thinking of all newcomers, or a specific subset?

I have updated the first user story and added a new section about "Goals," but I'll also explain a bit more about how this project came to be: We want newcomers to learn that there are many opportunities to connect with other editors on the wikis, whether through events or WikiProjects (though I agree that WikiProjects are often not newcomer-friendly, so we'll want to think about how/if we present them). This is because newcomers often feel alone on the wikis, and some events are well-suited for newcomers. They may provide training or mentorship, a worklist/set of tasks to work, a supportive group, the motivation of a common goal to work toward, and a story/narrative/statistics around the impact of their work. However, many newcomers don't know that these events exist (or how to find them). Meanwhile, organizers struggle to connect with newcomers.

The Community Update module is a part of this solution. It allows organizers to work with admins to highlight a particular campaign or event. So, you may be wondering: How is the Collaboration List different? Why do we include it too, and how does it fit in?

I see the Community Update module as sort of like a billboard that can highlight something that is especially important to the community overall. Meanwhile, the Collaboration List is not manually curated, but rather meant to be more of a general purpose tool that can surface the array of events and opportunities that are present on the wikis. It can also be customized to the interests/needs of the user. While the Community Update module is based on a community decision to highlight a particular event, the Collaboration List can be tailored to the interests of the users.

And this brings us to goals. We want to communicate that there are many events on the wikis — and they cover a range of topics, groups, and communities. And we want newcomers to feel inspired to learn about these events (perhaps peruse through some of them), and ideally, they may feel inspired to register for an event.

So, in summary we want:

• More event participants: We want to expose newcomers to events that may interest and support them, and we want newcomers to know that there are new events going on all the time. In this way, they can find events to join now or in the future.
• Events to be more discoverable: We want more people to also just generally learn about events and become familiar with the fact that events exist, which we can potentially measure through click-throughs to event pages.
• Better support for newcomers in events: We want to incentivize organizers to really think about the needs of newcomers (for example, we can start identifying which events have newcomer trainings)—and perhaps reward those who do focus on newcomers by prioritizing their events on the Newcomer Homepage.
• More pageviews of the Special:AllEvents: We will most likely be highlighting only a few events from the Collaboration List on the Newcomer Homepage, but there are many more events on Special:AllEvents. We want people to feel inspired to learn more by going to Special:AllEvents.

Regarding contributions in events: We do not currently track this data, so it is not a goal for now. However, we are planning a project for the upcoming fiscal year to track collaborative contributions. Once we have done this work, we may also consider various aspects of contributions (such as quantity & quality of edits) as another goal.

that said, i'm going to focus only on "concept 3" which seems to be the preferred option between phab and slack feedback. i'd like to evaluate this proposal through a content-first, and mobile-first lens.

---

if there's already a community update, my recommendation would be to not add other events to the homepage. i'd like to respect the community intent, and promote the event of their choice. in this scenario, could we think of adding a link to the special:allevents page? i have more comments on special:allevents that i'll share below***.

I hear you on this, however, I see it differently. The Community Update module focuses on one event that is highlighted by the community. However, that event may not be of interest to the user. What if the event focuses on gender issues, but the newcomer is really interested in transportation and engineering (and doesn't really care about gender issues)? And what if there is an event about transportation and engineering on the wiki? I feel like it would be useful to highlight such an event. It would be placed below the Community Update module, and we could present it in a different way. But I do feel there is value in showing a few events to users, so they know that varied opportunities exist.

---

if there's no community update, we could then explore how to surface events directly in-homepage. my suggestion would be to display only one event, front and prominent. and pick the most relevant event possible, based on available newcomer preferences and information. did they edit anything before? on which wiki? how often? on which topics? i would also try to identity what information is the most valuable for the newcomer to take action. is it important to know about the start/end date? is it important to know about the location? i would try to make as many smart decisions as possible, and reduce cognitive burden for newcomers.

I would advocate that we surface a few events, so that people understand that varied opportunities exist. It is very hard to predict if any one event is compelling to a given user. Maybe they are busy when the event will start. Maybe they are interested in similar topics, but not exactly that one. Maybe something about the event just turns them off or bores them. This is why it is useful to show a few — so they are more likely to think, "Oh, that one may be interesting..." or "Hmmm, none of these quite match what I'm interested in, but they're sorta related to my interests, so maybe if I look at the other events, I'll find something I like." The overall idea is that there may need to be some level of identification/sense of "this could be for me" in order for people to consider looking for more events.

As for criteria that we can use to narrow down the events shown, there is some data we have today, and there is some data that we don't collect yet... but we can.

The data we collect today:

• Whether an event online/hybrid/in person: We probably want to only show online events, and *maybe* also hybrid events. In person events are too hard to match to people, I think. So, the location is not important.
• Target wikis: We probably only want to show events that have specific target wikis, rather than "All wikis" or "No wikis." This may also incentivize organizers to only select "All wikis" if is the event is really, truly for all wikis or at least a very large amount of wikis. And, as for which wikis to show, we could restrict the events to those that target the wiki that the user is on, or we could also choose to include global wikis (such as Wikidata and Commons) as well.
• Topics: Not all Newcomers select topics, but if they do, we can prioritize surfacing events in their topical interest areas.
• Start date: We want to probably only show events that are coming up soon, such as events that are happening in the next 14 or so days.

Data that we do not collect yet, but we can (to improve the experience):

• Event type: If we start asking organizers for the event type, we can choose to only display the events that are focused on contributing content or events that provide training for newcomers, as per the suggestion of @FRomeo_WMF. Event types like community calls, conferences, and stuff that are very "in the weeds" of the Wikimedia world can be excluded.
• Primary language of event/languages supported: You bring up a good point about the fact that many of the events on Meta-Wiki are global in nature (i.e., they are for many audiences/many languages), but the title of the main event page is one language. We can begin asking organizers for the primary/base language of their event and which languages will be supported in the event (which could be complemented by translations of event titles). Some of these translations are available on the event pages, but this would be something for us to think through. It's tricky, but there are solutions we can explore.

we could also explore how to make the event dismissible, and potentially create a learning opportunity for us. why did newcomers dismiss it? maybe it wasn't a relevant event for them? or maybe they did not understand what events are? something else?

i also agree with @gonyeahialam discoverability concerns. i would not hide content in an accordion, nor add tabs inside an accordion. the page is already information-heavy, and nesting information might make it much less discoverable, especially on mobile.

I agree.

i would also not expose newcomers to the concept of 'communities', yet. see comments below***.

---

I'm of split mind about this one! On the one hand, I agree that WikiProjects are not typically newcomer-friendly. On the other hand, I do think there may be value in communicating that a bunch of communities exist! It can make the wikis feel more human, communal, and supportive. Perhaps the "Communities" tab could be more useful in the future if we had a way of highlighting the WikiProjects that are particularly active (since many are dormant) or more well-suited to newcomers (because they have regular events, more active communication, a core group of people who really want to go the extra mile for newcomers).

if there is no existing newcomer information available that would enable us to provide a strong recommendation, we could explore a module that introduces the concept of events. as @gonyeahialam pointed out, newcomers might not be familiar with the concept of 'collaboration list', 'events' nor 'communities'. would it be worth exploring a more educational approach and link to (a filtered version of) special:allevents? more below***.

---

I like the idea of providing education on what WikiProjects are and what events are, which can be complemented by a filtered list. However, I don't think a link is the best idea. People often understand new concepts through examples. Text with a link is not exciting or compelling, and I would guess that most people would not click on the link. I think it is much more powerful to see examples of real events that someone can join, and that is more likely to result in someone wanting to learn more.

***comments on special:allevents

before bringing events to newcomers, i'd like to suggest to invest more in newcomer- mobile-specific optimizations.

if we would redirect newcomers to special:allevents they will be prompted with 3 new concepts: 'Collaboration list', 'Events', 'Communities'. there is currently no explainer about those concepts.

moreover the whole page is filled up by the filters, which is pushing the actual content (events) much below. we could consider implementing something to collapse the filters. for newcomers landing on this page, i'd also suggest defaulting to specific filters to reduce cognitive load.

filtering to a specific wiki (eg. it wiki) still shows many events in other languages. most organizers mark their events as open to all wiki, but then content is displayed in their language, which might be problematic for newcomers.

I'll let Gregory respond to some of the mobile & UX considerations. Response to the "all wikis issue" is shared above (i.e., let's only show events with specific target wikis). Thank you for sharing this feedback!

the 'Communities' tab is confusing. supporting materials are not translated (in italian, and that might be the case for other wikis) and several of those projects are not optimized for mobile. moreover tapping on the edit pencil brings newcomers to wikidata which might be confusing.

Translations are through Wikidata, so the hope is that the pencil icon can encourage more people to update the info in Wikidata (including translations). But perhaps that is not coming across well? Perhaps this is also a design improvement we can look into.

the current layout doesn't feel optimized for mobile, and might benefit from minor adjustment to increase the information density, and improve the content hierarchy.

---

finally, i would suggest to map the whole experience and visualize all the steps (and screens) and conditions that need to be true to bring events to newcomers, and bring newcomers to events. what needs to happen before an event is displayed on the newcomer homepage? what happens when the event is live on the homepage? what happens when a newcomer taps on an event? what happens when a newcomer tries to register (and later participate) in an event?

I'll write some brief responses below, but I have talked with @gonyeahialam that perhaps a journey map could help answer some of these questions in a way that could be helpful for many audiences.

What needs to happen before an event is displayed on the newcomer homepage?

• User gets the event-organizer right, so that they can enable registration
• User (who is now an organizer) creates event page & enables event registration
  • When enabling registration, they specify info such as: event location, event start + end dates/times, target wikis, topics, etc.
• After the user enables registration:
  • Registration is open by default (so any logged in users can click "Register" to join the event)
  • The event automatically appears in Collaboration List
• We would need to determine which criteria are then used to surface relevant events on the Newcomer Homepage

What happens when the event is live on the homepage?

• The event should have registration open by default, as long as the event has not ended
  • Note: Organizers can choose to close and then re-open registration if they want

What happens when a newcomer taps on an event?

• The user should be directed to the event page, where there is a call to action to register for event

What happens when a newcomer tries to register (and later participate) in an event?

• A pop-up appear that asks them information for registration. Some information always appears (which is asking if the participant wants to register publicly or privately). Some information appears if the organizer configures it because it is optional (which is the participant questions on the user's gender identity, age range, profession, comfort editing the wikis, and if they are a part of an affiliate)
• Once they submit registration, the following happens:
  • A small message appears on the page that says they have registered, which also includes a link to the Collaboration List to view more events
  • If they have associated an email address with their account, and if they have not blocked registration confirmation emails via Preferences, they will receive a registration confirmation email. This email includes information about the event, a link to the event page, and a link to the Collaboration List.
• They will usually receive communication from organizer before event (such as reminder that the event is happening soon), but this is up to the organizer. Event Registration provides a tool that allows organizers to email their participants.
• The participants then will either participate or not participate in the event. We currently do not provide any tooling for support during the event. After the event ends, organizers usually write some close-out summary emails to the participants about the impact.
• The contributions of the users during the event (if any) will show up in the Impact Module of their Newcomer Homepage

apologies for the long message, but i wanted to provide as much specificity as possible. i hope this is helpful!

No, thank you for taking the time to write so much! Apologies from my end for writing an even longer message, but you just shared so many great questions that I felt the need to be super thorough :)

Thank you so much for this feedback, @FRomeo_WMF - responses below!

In T387793#10629745, @FRomeo_WMF wrote:

I'm excited by the opportunity to surface community-organized events on the Newcomer Homepage. I think the main benefit of the collaboration list module would be to let newcomers know that they can meet other people, and develop as an editor, by joining an event.

This is great to hear, and I love how you summarized the main benefit!

With that in mind, I tend to agree that it might be enough to show the community update and one very relevant event (if available), with a link to the full list. Repeating what others have said here, I would select an upcoming online event from the current language wiki that matches one of the newcomer's topic interests.

I would advocate for more like 2-3 events for the reasons shared in my comment above, but I agree with focusing on online events on current language wiki + newcomer's topical interests.

The collaboration list includes a wide variety of events and I worry that many of them would be more confusing than appealing for newcomers, for example, office hours, trainings for Central Notice and event tooling, and sessions about the Universal Code of Conduct. For now, I would only show contribution events like editathons and media upload events. I understand that we're not implementing event types yet but hope we could find a way to filter for this.

This is actually a good argument to look into bringing back the event types epic soon -- thank you for raising this!

Looking at the collaboration list in the context of the Newcomer Homepage, I also noticed that the event titles are not always descriptive enough. I wonder if we should review the guidance we give in the event registration tool UI and/or our event registration trainings?

Yes, great point! I think this could be a great topic for training organizers. However, it would be hard to add this guidance in the UI since the organizer creates the event page (as in, a general wiki page, just in the event namespace) and then they enable registration. So, they do not create the page title as part of the event registration process. However, I think organizer training could help a lot!

Update: After discussing this work with @KStoller-WMF, we are considering a reimagining of the project to be the following: Rather than finding how we can add the Collaboration List to the Newcomer Homepage, we expand the capabilities of the Community Update module. Specifically, we make it a way to flip through many events (like how you can flip through many tasks in Structured Tasks, though with a smaller number of events). The first event will be the Community Update module, if there is any. This is like being the top of search engine results — in other words, it still makes the community update take precedence by being what people see first. But users can flip through more events to find what may interest them. There’s some potential trickiness to this (since the Community Update is submitted via admins, whereas the rest of the events come via the Collaboration List), but the idea makes sense to me from a user perspective.

@gonyeahialam, for the next iteration of this work, can you focus on this concept? Perhaps you can meet with @JFernandez-WMF to learn more about how Growth has previously thought about the concept of flipping through events as a starting point.

In T387793#10634853, @ifried wrote:

Update: After discussing this work with @KStoller-WMF, we are considering a reimagining of the project to be the following: Rather than finding how we can add the Collaboration List to the Newcomer Homepage, we expand the capabilities of the Community Update module. Specifically, we make it a way to flip through many events (like how you can flip through many tasks in Structured Tasks, though with a smaller number of events). The first event will be the Community Update module, if there is any. This is like being the top of search engine results — in other words, it still makes the community update take precedence by being what people see first. But users can flip through more events to find what may interest them.

really like where you landed @ifried!

There’s some potential trickiness to this (since the Community Update is submitted via admins, whereas the rest of the events come via the Collaboration List), but the idea makes sense to me from a user perspective. [...]

specifically for this, it would be exciting to explore visual treatments to clearly differentiate events suggested by the community. think of a "featured by" or "suggested by" badge of some sort.

This is great to hear, @AAlhazwani-WMF! Thank you so much for all of the feedback, which helped us to get to this place. Also, +1 to exploring how we can provide different visual treatment to the community update event, if there is one. I will update this task; cc @gonyeahialam.

In T387793#10634853, @ifried wrote:

Update: After discussing this work with @KStoller-WMF, we are considering a reimagining of the project to be the following: Rather than finding how we can add the Collaboration List to the Newcomer Homepage, we expand the capabilities of the Community Update module. Specifically, we make it a way to flip through many events (like how you can flip through many tasks in Structured Tasks, though with a smaller number of events). The first event will be the Community Update module, if there is any. This is like being the top of search engine results — in other words, it still makes the community update take precedence by being what people see first. But users can flip through more events to find what may interest them. There’s some potential trickiness to this (since the Community Update is submitted via admins, whereas the rest of the events come via the Collaboration List), but the idea makes sense to me from a user perspective.

@gonyeahialam, for the next iteration of this work, can you focus on this concept? Perhaps you can meet with @JFernandez-WMF to learn more about how Growth has previously thought about the concept of flipping through events as a starting point.

@ifried This idea sounds good. I would explore it and also @AAlhazwani-WMF's suggestion:

specifically for this, it would be exciting to explore visual treatments to clearly differentiate events suggested by the community. think of a "featured by" or "suggested by" badge of some sort.

***comments on special:allevents

before bringing events to newcomers, i'd like to suggest to invest more in newcomer- mobile-specific optimizations.

if we would redirect newcomers to special:allevents they will be prompted with 3 new concepts: 'Collaboration list', 'Events', 'Communities'. there is currently no explainer about those concepts.

We have an explainer for communities/Wikiprojects on the tab but none for events or Collaboration list in general. We can explore add these cc @ifried

moreover the whole page is filled up by the filters, which is pushing the actual content (events) much below. we could consider implementing something to collapse the filters. for newcomers landing on this page, i'd also suggest defaulting to specific filters to reduce cognitive load.

Yeah. The filters taking up space especially on mobile is a known issue. Perhaps we can prioritise work on this @ifried
I agree we should default to specific filters for newcomers

the current layout doesn't feel optimized for mobile, and might benefit from minor adjustment to increase the information density, and improve the content hierarchy.

Can you expand more on this @AAlhazwani-WMF

In T387793#10637257, @gonyeahialam wrote:

Can you expand more on this @AAlhazwani-WMF

@gonyeahialam sure thing! these are very quick explorations, mostly to better convey what i meant, take it with a grain of salt.

on the special:allevents page we could consider maximizing the use of white space to increase the information density on smaller viewports. another aspect worth exploring is optimizing vertical spacing to better group items together. right now, for example, the event title and the event date right below are more spaced out than the event date and the event meta information.

similar optimizations might be explored for the event details, where we could increase the information density, and provide a stronger information hierarchy.

i hope this is helpful, lemme know!

i hope this is helpful, lemme know!

Yes this is helpful @AAlhazwani-WMF

In T387793#10634853, @ifried wrote:

Update: After discussing this work with @KStoller-WMF, we are considering a reimagining of the project to be the following: Rather than finding how we can add the Collaboration List to the Newcomer Homepage, we expand the capabilities of the Community Update module. Specifically, we make it a way to flip through many events (like how you can flip through many tasks in Structured Tasks, though with a smaller number of events). The first event will be the Community Update module, if there is any. This is like being the top of search engine results — in other words, it still makes the community update take precedence by being what people see first. But users can flip through more events to find what may interest them. There’s some potential trickiness to this (since the Community Update is submitted via admins, whereas the rest of the events come via the Collaboration List), but the idea makes sense to me from a user perspective.

@gonyeahialam, for the next iteration of this work, can you focus on this concept? Perhaps you can meet with @JFernandez-WMF to learn more about how Growth has previously thought about the concept of flipping through events as a starting point.

Iteration 2
Design based on the above feedback and the plan to collect more information from organizers about their event such as event type, image and description

Prototype	Design

• Community updates and events are combined into a single module
• The community update is shown first
• And about 4 events tailored to the user
• A note below each event shows what event is a community update and what are events from the collab list.
• Users can use the arrows to swipe to see more events
• On the last event, you see a button to take you to the collaboration list page

Future UI design considerations to look at:

• Max lines/length for event title
• Change in position of the image to give room room for description
  • 
• Figure out the most engaging module heading copy
• Remove or keep the events counter: While the counter may be less important since we have just a few items in the list, it maybe helpful for users to have an idea of how many events are shown beforehand. Perhaps a more visual (rather than text) indicator such as using the dot may be suitable
  • 

cc @JFernandez-WMF