Page MenuHomePhabricator

Design Exploration: Generalize Event Registration for On-Wiki Collaboration
Closed, ResolvedPublic

Assigned To
Authored By
ifried
Aug 2 2024, 11:42 PM
Referenced Files
F57347099: image.png
Aug 29 2024, 6:18 PM
F57346905: image.png
Aug 29 2024, 6:18 PM
F57346826: image.png
Aug 29 2024, 6:18 PM
F57346815: image.png
Aug 29 2024, 6:18 PM
F57346766: image.png
Aug 29 2024, 6:18 PM
F57346702: image.png
Aug 29 2024, 5:33 PM
F57342260: image.png
Aug 29 2024, 5:33 PM
F57296056: Screen Recording 2024-08-26 at 9.35.55 PM.gif
Aug 26 2024, 8:39 PM

Description

Design exploration request: Provide design examples and a report/summary of learnings on how we could generalize Event Registration so that it can be used for on-wiki collaborations that are not necessarily time-bound. Design examples should show a few versions of how this could work, so we can share with community members & get feedback. Examples of such collaborations include WikiProjects, a weekly collaboration on a topic, etc. The goal is that organizers of many types of collaboration can be able to use our tools in the future. However, any risks and/or concerns with such a vision and approach should also be shared in the course of this exploration.

Time period: This is a time-boxed exploration, due on Sept 2, 2024.

What will we do with the design exploration?: Once complete, we will share these design concepts with organizers of on-wiki collaborations. We will see what feedback they have. Then, when Gregory is back from parental leave (before going back on leave), we will share what we learned and then see if he continues/expands these designs or if we pivot to something else. In total, this means that this design exploration will help us determine if we want to proceed to generalize event registration to work for other use cases, namely on-wiki collaboration.

Background: The Event Registration tool was originally built as a way for campaign event organizers to manage events, especially for in-person events and smaller to medium-sized online events. We have learned that the tool is useful for a variety of use cases, such as many different event types (edit-a-thons, hackathons, meetups, community calls), and we have seen it used for increasingly complex events (such as multilingual events, larger online events, etc). This has led us to wonder: What other use cases could be accommodated if we expanded or changed some elements of the tool?

Meanwhile, we have begun thinking about how the larger work of the Campaigns team can help contributors on the wikis connect with one another, so it is easier for contributors to find a sense of belonging and work on tasks together on the wiki. This is because we believe that many contributor are happier and more productive when they have communities and groups that they can rely on and feel like they are a part of.

This has led us to wonder: Could Event Registration help with other forms of collaborative activity on the wikis? This way, we could make it easier for people to come together with other like-minded contributors, so they can work on projects together. Meanwhile, our other organizer tools (Event List and Invitation Lists) either already work for collaborations beyond events (such as Invitation Lists) or we are in the process of expanding their focus (such as transforming the Event List into a Community List).

Overall, we would like to explore what an experience could look and feel like if we were to generalize Event Registration for on-wiki collaboration. We want to know what ideas come up and what concerns/issues may arise as well. This can help us think through if such a project could be worth considering for the team in the future, and it could help us see what questions and issues we would need to confront and think through early on.

User story:

As an organizer, I want to be able to easily create and manage collaborative activities on the wikis, so that I can more easily reach the goals of my activities.

As a participant, I am excited about joining a collaborative activities because they offer a positive community experience and make it easy to have an impact

Problems we are trying to solve:

Summary: There is a lot of collaborative organizing that is happening on the wikis, but it is a complex, manual process for organizers to create these activities, so we believe this makes it harder for organizers reach their goals and for participants to have a fulfilling experience. Also, there may be other people who are not starting up collaborations at all because it is just too hard to get started, so we're missing out on a new generation of organizers who could help fuel further collaborative activities.

For organizers of collaborative activities on the wikis, it is hard to create & manage these activities. For example:

  • There is no standard way to create spaces for collaborative work
  • There is no standard way to collect participant usernames
  • There is no no universally accessible way to communicate with participants in bulk
  • There is no easy way to know when/how participants have done work in the scope of the activity

For contributors on the wikis, it is often hard to join a group/collaborative activity and develop a deep sense of belonging/identity within the group without substantial work on the part of the contributor. For example:

  • It can be hard to find out about collaborative activities
  • Onboarding can be confusing; what do I do? How do I know that I am doing the right thing?
  • The impact of one's work or of the activity overall can be hard to gauge

For the Wikimedia movement overall, we have the following problems:

  • Many collaborative activities are largely invisible to us, so we don't understand their impact very well
  • We do not have an easy way of determining how many people are members of WikiProjects or other collaborative activities.

Some things to consider:

  • What do we mean by generalize?
    • We don't want to remove the existing behavior, but rather offer support for both events and other types of collaborations. We still want to be able to support events.
    • We want to design something that works for many forms of collaborations on the wikis. This can be WikiProjects or different forms of collaboration. We should not limit the use case to specifically WikiProjects, but this should ideally also be usable by WikiProjects.
  • Differences between events & other forms of collaboration
    • On-wiki collaborations may or may not be time-bound, so I think dates/times should probably be optional.
  • Information that we may want to collect
    • Important information to collect from organizer may be: type of collaboration, topics, tasks
    • Important information to collect from participants may be: what are you interested in working on?, why are you joining? -> it could be a good idea to look at the questions people are asked when they join WikiProjects
  • New feature requests
    • When we talked to organizers of other types of collaboration at Wikimania, we heard interest in a version of Event Registration but with an added feature for a participant to indicate what they worked on. For example, if someone registers for an activity, there can be a checkbox or drop-down that allows them to indicate if a contribution they are making is in the scope of the activity they joined. If they say yes, then the organizer and all members can easily see that such a contribution is for that activity. There can also be a way for them to indicate that a past contribution is for an activity if they forgot to initially indicate it being so (such as in the user contributions, recentchanges, etc). The flow would not need to necessarily follow this; this is just an example. The goal would be to have a light-weight way for users to say that a contribution they are making is part of a collaborative activity.
  • Big questions to consider
    • If we generalize Event Registration, does it provide enough of a value for organizers and participants of other forms of on-wiki collaboration, or would they need a lot more to be built out?
    • Would there need to be new features to make such an expansion useful to organizers of on-wiki collaboration
    • Would we just need something that is totally different from Event Registration?

Design explorations
Figma

Details

Due Date
Sep 2 2024, 7:00 AM

Event Timeline

ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried renamed this task from Design Exploration: Generalize Event Registration for On-Wiki Collaboration [draft] to Design Exploration: Generalize Event Registration for On-Wiki Collaboration.Aug 14 2024, 5:00 PM
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried set Due Date to Sep 2 2024, 7:00 AM.
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
ifried updated the task description. (Show Details)
gonyeahialam changed the task status from Open to In Progress.Aug 16 2024, 6:55 PM
gonyeahialam claimed this task.

I discussed this work with @gonyeahialam today, and here are some topics that came up:

  • We are generalizing event registration for all types of on-wiki collaboration (not just WikiProjects).
  • We should focus on generalizing event registration, and then after that we can look into adding more features. This means:
    • Time and date should be optional
    • It does need to be on an event page in the event namespace
    • Event registration should still probably be managed by those who have the organizer right
  • Worklist support is a feature we could consider later, but it would probably need a separate design exploration & there are work-arounds now for organizers to have the worklist on the page, so I think it is probably out of scope for this exploration
  • What happens after someone joins a collaboration? Right now, we just have a confirmation email. Perhaps we can add an on-wiki confirmation message that has more information on next steps, including: a link to the Community List to join other events/communities.
  • Organizers have told us they are really interested in simple, light-weight ways to track contributions that are in the scope of an a collaborative activity. For example, if we know that someone is a part of a collaboration because they joined it via event registration, we could have a checkbox (or perhaps dropdown because they may have joined multiple collaborations that are going on at the same time) that asks if their edit that they are about to publish is for that collaboration. If they say yes, then it can be publicly viewed as part of the collaboration data.

So priorities can be:

  • Priority 1: Provide a wireframe (simple first version) that allows organizers to use event registration for other types of on-wiki collaboration that are not time-bound and/or not events
  • Priority 2: Provide wireframes (they can be low-fidelty) for pathways to discover the Community List through Event Registration workflows, so that it is easier to discover the Community List for those we already know are interested in events/communities
    • For example (but this is only an example): When the participant registers for an event, they can get a pop-up that shares that they can learn about more communities & events on the community list)
  • Priority 3: Provide wireframes (and they can be low-fidelity and rough) to explore this idea: Is there a simple way that we can make the tool more valuable to organizers of other types of collaboration by allowing them to have a light-weight way of tracking contributions that are in the scope of the collaboration?

Hello, @gonyeahialam! I discussed this ticket with Carolyn, and here is the update: You only need to focus on Priority 1 for your final week before leave. For Priority 2 and Priority 3, this can be taken on by Alex or other folks if we want to explore them in the coming months. Thank you!

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

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?

Screen Recording 2024-08-26 at 9.35.55 PM.gif (670×960 px, 116 KB)

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]

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]

Thank you

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.

The Enable registration form can be modified as shown:

Option 1A: A single form with time related fields optionalOption 1B: Timed and date related fields disabled until start date is entered.Option 2: Form is tailored based on initiative type
Organizers will fill the required fields and can fill the optional fields like date and time if they chooseAll time and date related fields are disabled except the start date. When the start date is filled the end date is enabled and when the end date is filled all the other time related fields are enabledWhen organisers select the time-bound or not time-bound initiative the form updates to show only questions for that type
image.png (2×1 px, 238 KB)
image.png (2×1 px, 236 KB)
Screen Recording 2024-08-26 at 9.35.55 PM.gif (670×960 px, 116 KB)
Challenges: Some challenges I predict with this flow: 1. Users may think they need to enter a date and time even if they don't need to for not time-bound event. Unlike shown in the design, the implementation of this form (OOUI) only indicates the required filled and doesn't explicitly state that a field is option, this could also influence the challenge mentioned previously. 2. Required and optional fields may change based on what fields the user fills. For example, the start and end time and date fields are optional but if a start date is entered then the end date should no longer be optional. Option 1B was the solution i came up with for this.This seems to be the most straight forward solution.

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:

Initiative pageEvent details dialog with participant listEvent details tabParticipants tab will remain the same except we add some other non PII questions for other forms of collaboration
image.png (1×2 px, 793 KB)
image.png (1×2 px, 215 KB)
image.png (2×2 px, 249 KB)
image.png (2×2 px, 204 KB)
image.png (1×1 px, 136 KB)

No changes seem necessary for the Messaging and Response statistics tab for other types of collaboration.

Thank you for this work, @gonyeahialam! I am now closing this task because we have determined two epics which this may apply to (T385341 and T385342), so I have provided a link to this work in both epic descriptions and this work will be revisited for next steps when either of those epics are taken on.