Campaigns/Foundation Product Team/Registration
There are many campaigns in the Wikimedia movement, such as Wiki Loves Monuments, WikiGap, #1Lib1Ref, and more. However, there is no robust, on-wiki registration system for campaign events. For this reason, this project aims to create an easy way to join Wikimedia campaigns.
We invite you to read our analysis below and share your feedback on the talk page. Your feedback will directly impact the direction of our project. Thank you in advance!
With this new feature, campaign organizers will save time, since they will no longer need to develop alternative registration solutions. Also, they will be able to collect better data on campaign participants and their needs while respecting participant privacy. Meanwhile, campaign participants will be able to join campaigns with minimal effort, and their first point of contact in the campaign will be fun and inspiring.
We have big plans for the future of registration. First, we hope to integrate the registration feature with existing tracking tools, like Programs & Events Dashboard and Event Metrics. This means that, after participants have registered, their usernames will be automatically pushed to the tracking tool specified by the organizer.
Second, we hope that an on-wiki registration solution fosters a greater sense of community. Right now, many campaign participants don’t know who else has registered, especially if they register through third-party platforms. With a new registration solution, participants can see who joined the campaign and who shares common interests or motivations with them.
Third, we envision the registration system being integrated with an events calendar. Once we have built registration, we can incorporate registration support into various calendars and event discovery tools.
Finally, we want this project to be a deeply collaborative effort. In preparation for this project, we consulted with about 50 campaign organizers. We want to sincerely thank these organizers, who provided us with a richer understanding of the organizer experience and its greatest challenges. Now, we invite all campaign organizers to share their feedback on the project talk page!
Why we want to improve registration
We believe that registration is a strong project choice for the team for the reasons listed below.
- There is currently no standardized, on-wiki system. The Wikimedia movement needs a robust registration system designed for its needs.
- The current registration alternatives used by organizers have many issues, including being:
- Time-consuming and tedious for organizers to configure and manage.
- Data-light. They provide minimal information on participant needs and make it hard for organizers to understand who participated in what events.
- Technically challenging and confusing for newcomers to register.
- Difficult for participants to edit information after registration.
- Not preventing multiple registrations of the same person from occurring.
- Not multilingual or built for diverse language communities.
- Not fostering a sense of community and inclusion among participants.
- In conflict with Wikimedia values (i.e. many tools require disclosure of private information on a third-party platform).
- Not integrated with any wiki pages or platforms, adding additional complexity for newcomers.
- Not integrated with existing tracking systems, like the Programs & Events Dashboard.
- Organizers, affiliates, and other movement stakeholders want better data on participants and their needs. Developing a registration system is the first step in making this possible.
- Registration is the building block for future work. Once we improve registration, we can begin to integrate other features into the campaigns workflow, such as improved tracking tools or improved communication tools.
- The project is manageable and within scope for the team.
Nearly every organizer we have spoken to has designed their own registration solution. Some of these solutions are learned from other organizers and some come from previous organizing experience. Others are designed around specific technical requirements. Our goal is not to design the first registration system, but to provide an improved solution that helps create a consistent workflow for organizers in different contexts.
How campaign registration currently works
We have identified several registration solutions that are currently being used, including:
Manually adding username
Some registration processes require participants to manually add their username or signature on-wiki. For example, see Wiki for Human Rights 2021 in Morocco or Women in Red events in the screenshot examples below. The advantage of this approach is that it is integrated into existing wiki workflows, and information on registrants is publicly available (example). The disadvantage is that it gives minimal information to organizers on participant needs, and it's not intuitive for newcomers.
Some organizers have built elaborate technical fixes for registration. For example, CEE Spring has a multi-wiki bot that aggregates data across multiple local events. Project Al Masaraf requires each user to generate a subpage that is then queried by a script. These solutions can be useful for specific campaigns, but they are hard to adapt or reuse across communities. They also depend on maintenance by “in the know” technical volunteers, who may eventually stop maintaining the tools, creating challenges for long-term technical support.
Off-wiki, proprietary solutions
Third-party registration forms
Some organizers use third-party forms, like Google Forms, to register participants. The advantage is that the forms are easy for organizers to configure and for participants to fill out. The disadvantage is that they are removed from Wikimedia workflows, and they have varying privacy and open source policies. Participants cannot see registrant information either, so they have little understanding of how to connect with other registrants. Also, these platforms are not universally supportive of languages and cultural contexts. In smaller language communities or at-risk contexts, these tools often prove challenging to use in an inclusive and safe way.
For example, a Black History month event to Celebrate Women Leaders in the African Diaspora, organized by Wikimedia Nigeria, African Women on Board, and AfroCROWD, used a Google Form for registration. See screenshot example below.
Third party registration platforms
Some campaigns use third-party platforms, such as Eventbrite or Meetup, for registration. The advantage is these platforms offer feature-rich and highly customizable experiences. The disadvantages are the same as those for third-party registration forms.
Tools built for campaign tracking
Programs and Events Dashboard
The Programs and Events Dashboard, developed by the Wiki Education Foundation, is a tracking tool. Some organizers use a third-party tool, which is followed by registration on the dashboard. For example (screenshot example below), you can see these steps in the Africa Wiki Challenge. In other cases, organizers use the Dashboard as their one and only registration tool.
The advantage of the Dashboard is that it's a metrics tool, so it's already integrated with tracking. The primary disadvantage is that it's not an actual registration tool. It provides minimal information about participants to organizers, and it provides minimal support to participants. Also, the dashboard is not used as a metrics tool for all campaigns, since many campaigns prefer different tracking systems.
Fountain (documentation), developed by Le Loy, is a tracking tool used by some campaigns, such as Wikipedia Asian Month. The advantages and disadvantages are the same as those found in using the Programs & Events Dashboard. Additionally, the tool, similar to on-wiki registration, is challenging for newcomers and is best used with experienced editors.
No formal registration
Some campaigns do not include a formal registration process, but instead track participants through some consistent action in an on-wiki workflow.
Registration via upload process
This is especially common for photography contests, such as Wiki Loves Monuments or Wiki Loves Folklore, in which registration is essentially built into the tracking process. When someone uploads a photograph and tags it for campaign tracking, they are effectively registered. This format works for some campaigns, but it’s not useful for all campaign types, especially for those targeting newcomers or writing articles. It also doesn’t collect additional information on participants, which may make communication and follow-up especially challenging.
Registration via Hashtag
For #1lib1ref and Wikipedia Pages Wanting Photos (#WPWP) and a handful of other program activities, the Hashtags Tool acts as a default registration tool. Like with the upload process, there is benefit in that it captures contribution data. However, because hashtags are not deeply integrated in the editing interface, it’s difficult for newcomers to understand the action, and even experienced editors may forget to add the hashtag because it is not part of their regular workflow. Additionally, it is difficult for organizers to keep track of contributions in real time, and no information is directly provided on participants and their needs.
Thank you for reading our analysis. Now we want to hear from you! We kindly request that you respond to the questions below (or share any other feedback!) on the project talk page:
- What do you think of our plan to create a campaign registration system? Do you think it would be useful to you, as a campaign organizer and/or participant?
- What do you think of our analysis of the current registration processes? Are we missing anything important to you?
- If you are a campaign organizer, what registration system do you use? What does and doesn't work well with that system? If you could change one thing about it, what would it be?
- If we create a registration system, how would you like it to work? Please provide as many details from what you would like or, if you have them, examples from other registration tools you have used before!
- We are a new team (check out the new landing page). What are your hopes, questions, or concerns for our team?
- Anything else you would like to add?
Your feedback is very important to us and it will directly impact the choices we make as a team. Thank you, and we look forward to reading your comments!
October 8, 2021
Hello, everyone! We are very excited to share an update on the Campaign Product team’s event registration project. First, we will share our project principles. Second, we will share wireframes for the desktop version (the mobile version will be in the next update). Third, we will provide questions for all of you. Thank you, everyone, and we look forward to reading your feedback on the project talk page!
As the project has developed, we have identified several principles that are core to our work:
- In the long-term, we want to build a platform, rather than one tool: Some people asked why we’re not using an existing open source solution for event registration. We’ll certainly examine the options, and nothing is ruled out yet. However, we’ll probably want to build our own solution. Here’s why: We want to build a Campaign Events platform over time—not just a registration solution. In order to build this platform, we’ll need to develop the core infrastructure, and the registration project is the first step in making this happen. To learn more, you can visit the plans & vision section of our team page.
- We want to build for multilingual, diverse communities: Organizers have explained that the existing registration solutions lack sufficient support for global, multilingual communities. We completely agree. For this reason, we won’t consider this project complete until we build a solution that is usable for all language wikis and Wikimedia projects.
- We plan to build in an iterative way: The first version of the registration solution will be very basic. We call it the MVP (or “Minimum Viable Product”), since it will just have the bare essentials to function. We work in this way so that we can collect feedback early on, and we can identify problems before we spend too long on a feature. Once we have released the MVP version, we can develop more advanced versions of the registration feature.
- The MVP will just have the necessities: For the MVP, our goal is to build a simple registration configuration and management tool. The wireframes we have shared below are for the MVP version.
- We will add enhancements later on: After we have built the MVP version, we can include the ability for organizers to add optional questions to the registration form, such as asking for the participant’s gender, location, wiki editing experience level, or why they joined the event. We can also add the ability for organizers to write custom questions.
Wireframes: Desktop version
In the wireframes below, we will share how the MVP version may look for desktop users. Wireframes are a step in product development, where we imagine the potential visual design and workflows of a tool. Wireframes are theoretical; the look may change when the engineers begin to develop the tool. Note that we’ll share wireframes for the mobile version in the next status update.
Creating registration for event
Access Organizer Center: We want to create an “Organizer Center,” where organizers can find tools and resources available to them. For this project, we may create a very basic Organizer Center, which will expand over time. The first tool to be featured in the Organizer Center will be the Event Registration tool. To access the Organizer Center, users can go to Contributions > Campaign Events.
Note that, in the future, the Organizer Center will probably be a part of a larger Campaign Events platform. To learn more, you can visit our plans & vision section of our team page.
Selecting tool to create registration: Once the user is in the Organizer Center, they can choose to create a registration system for their campaign event. To do this, they click “Create registration for your campaigns events.”
Creating registration for campaign event: After the user has chosen to create a registration form, a new interface will appear. The organizer will input the following information: the event URL, event name, date, time, timezone, if it’s online or in-person, which tracking tool will be used, URL of tracking tool instance, usernames of organizers, and a link to the event's chat group. The tracking tool and chat group information will be optional. The user clicks on “Create Registration” when they are finished adding information.
Once the registration creation is complete, a registration interface will automatically appear on the campaign event page. Please refer to the next section ("Registering participants") for more details.
It is important to note that, with this system, organizers will need to create a few things in advance: the campaign event page, the tracking instance (for example, on Programs & Events Dashboard), and the chat group in advance.
For the first version of the registration system, we will only be asking participants for their usernames. This is because it is much easier to implement. However, after the first version is released, we will look into allowing organizers to create more sophisticated registration forms that can ask participants optional questions about themselves and why they are joining the campaign event.
Registration automatically added to the event page: Once the organizer has created event registration, the registration experience will be automatically added to the event page URL specified by the organizer. The registration experience is a bottom sheet that overlays the event page. We chose the bottom sheet design so that it could work for many different types of event pages. In the bottom sheet, there is a button to “Register as userName.” So, if someone’s username was Lola, it would say, “Register as Lola.” The user can click the button to register.
More information: If the user clicks “More Information,” they can see more information on the event, such as the date, location, organizers, and list of participants. They can then click “Register as userName” in this view too. After the user registers, they should see the confirmation message.
Login and account creation support: If the user is not logged in, they will automatically see a pop-up appear when they click “Register as userName.” They can choose to login, if they already have an account, or they can sign up, if they do not already have an account. Once they login or create an account, they will become automatically registered in the campaign event.
Successful registration: After the participant has successfully registered, a pop-up will appear to confirm their registration. The pop-up will automatically disappear after a short time. If they have an email address associated with their account, we would also like an email to be automatically sent, which provides information on the event, such as the chat group that they can join. If participants would like to leave the event, they can click “Edit registration” (via the bottom sheet or side bar), which will then ask them to confirm if they want to leave the event.
In the future, participants may be able to add optional information about themselves when they register (such as wiki editing level, why they are joining the campaign event, etc). If this support is added, participants will also be able to edit this information as well.
View all registration forms: Once the organizer has created the registration form, they will be able to see all registration forms for their events. They can click on one of the forms to get more registration details, including the participant list. They can also easily delete, edit, or close registration forms via this view.
Viewing, deleting, and messaging participants: Once a registration form has been created, any specified as an organizer can view registrant information, including: participant username, and the date and time of registration. They will be able to select some or all of the participants from the list, and they will be able to message them or delete them from the list.
Organizers will be able to send a message to the participants, either on their talk page or to their email address. Depending on the technical difficulty of the work, we may choose to release an MVP version that only sends a message to the talk page, or the MVP version may allow both options. Either way, our plan is to eventually allow both messaging options.
- What do you think of our proposed system for creating and managing event registration, as a campaign organizer? What benefits does it offer compared to your current system? What disadvantages does it have compared to your current system?
- What do you think of our proposed experience for registering participants on the event page? What benefits does it offer compared to your current system? What disadvantages does it have compared to your current system?
- We first plan to build a lean version (also known as the “MVP,” or minimum viable product version) of the registration tool. # What are the essential features this first version needs to have so that you can use it?"
- When you are running a campaign, what information do you typically send to participants, and where do you usually send it (e.g., talk page, email, social media, etc)?
- Do you prefer that we build the desktop version first or the mobile version of the registration system first?
- Is there anything else you would like to add?