Page MenuHomePhabricator

Design: External Calendar Integration for Event Registration
Closed, ResolvedPublic

Description

As an event participant, I want to be able to export information about the event to my external calendar, so that I can keep track of the event and remember it in a calendar system that is already used in my daily life.

Some additional context, from a product perspective: As a product manager, I want to know the designs for iCal and Google Calendar support in Event Registration (which are compatible with Wikimedia policy of not endorsing companies), so that we can provide a helpful user experience while also respecting Wikimedia policy.

Background: We have learned from our survey findings and from our conversations with organizers that people sometimes forget about events that they had signed up for. One way we can improve this situation is to create iCal integration between Event Registration and external calendars. For this epic, we want event organizers and participants to be able to add the event to their external calendar of choice, so that they can access the benefits of an external calendar, such as event reminders.

Where to showcase the Add to Calendar feature:

  1. In the Registration confirmation email
  2. On the Post-registration confirmation dialog
  3. On the Event page

Design

  1. Registration confirmation email

image.png (1×2 px, 322 KB)

  1. Post-registration confirmation dialog

{F42186680}

  1. On the Event page

Screen Recording 2024-02-27 at 3.20.30 PM.gif (602×960 px, 197 KB)

Event Timeline

ifried renamed this task from Design: iCal Integration Design to Design: iCal Integration for Event Registration.Jan 5 2024, 7:10 PM
ifried created this task.
ifried updated the task description. (Show Details)

@ifried do you know where I can read in detail the policy of not endorsing companies?

@Iflorez We have the ability to do both iCal and google, but google proves difficult as we can't use the google iconography to indicate it so may not be able to integrate both.

@MHorsey-WMF how do you intend to implement the calendar integration? Is it a direct calendar API integration or via downloading a calendar file(.ics)?

@gonyeahialam The iCal integration is a file download, without knowing what application the client is using it's not really feasible to do any form of direct integration and most calendar apps will read an ical natively anyway.

Google is much more straightforward as it simply redirects to the calendar of the current user anyway

Thank you for the response @MHorsey-WMF

By iCal are you referring to Apple Calendar or .ics file format?

Can you explain more about what you mean by 'Google is much more straightforward as it simply redirects to the calendar of the current user anyway'? I understand that if you click on a Google Calendar link it opens up Google Calendar and not any calendar.

@gonyeahialam Apologies, yes I mean .ics

With the google calendar integration, all I meant was that because it's all handled in the browser the user experience is simpler than with the .ics file

So the situation here is that with the .ics, users can download and add it to any calendar of their choice (though it is a longer process) but with Google Calendar, you can just click on it and it opens a link in your Google calendar on the browser(which is more straight forward). You want to have these two options available but the problem with the Google Calendar option is that you can't mention 'Google' in the Wikimedia UI.

@MHorsey-WMF please confirm if my explanation above is accurate?

Yes @gonyeahialam , That is the situation as I understand it. I'm not 100% certain on the specific details of the policy though, it may just be that we can't use the google logo? I'm not sure who can provide some clarity on that point.

@gonyeahialam I am not sure if there is a specific policy anywhere or if it is just that, from a philosophical and ethical standpoint, there is a desire to not explicitly endorse certain companies or products, if possible. From my perspective, we want to avoid product endorsement for the sake of endorsement, of course, but we also want things to be valuable and usable. Google Calendar is commonly used by many event organizers and participants, so it would be very valuable to get this support and display it in a way that is comprehensible to them.

One similar example is ebook export for Wikisource. In this case, the MOBI format is allowed, which is only used for Kindle. For this reason, you can see the word 'Kindle' mentioned in explaining the file format usage, which is helpful to users. You can test for yourself here: https://en.wikisource.org/wiki/Pelman_v._McDonald%27s_Corporation_(S.D.N.Y._2003)

Screenshot 2024-01-08 at 8.47.09 AM.png (1×1 px, 343 KB)

As a next step, I think it may make sense to consult other people on the Design team. I'm pretty sure this is something other people in the Design team have dealt with before, so perhaps you can consult with other designers for their input? For a more explicit understanding of what is and is not allowed, you can also reach out to Legal via Asana.

ifried renamed this task from Design: iCal Integration for Event Registration to Design: External Calendar Integration for Event Registration.Jan 11 2024, 3:34 PM

Just updating the task with a summary of my presentation at the Engineering-Design meeting that happened about 4 weeks ago

Problem
One of the major reasons participants don’t turn up for events they register for is that they forget about it.

One way to ensure participants don’t forget to attend events they register for is by Adding the event to their calendar

Where to showcase the Add to Calendar feature:

  1. In the Registration confirmation email
  2. On the Post-registration confirmation dialog
  3. On the Event page

Option 1 and 2 are the most effective ways to ensure participants get to use the Add to Calendar feature. This is because of their location/position in the flow and because it captures the participant at a high point of engagement - immediately after registration. You go to the event page - you register - you are shown a registration confirmation dialog with a CTA to add to the calendar - and then you add to the calendar. Alternatively, you are sent a confirmation email after registration and you see the option to add to the calendar.
Having the Add to Calendar always visible on the event page in Option 3 is the least effective among the other 3. It allows users who are revisiting the event page to add the event to their calendar at any time. It’s also useful for those who are considering attending but aren't ready to register yet. But for those who come to the page and register it is not in the best position to remind them to add the event to their calendar and the CTA might blend into the page over time and be overlooked by repeat visitors.

Most event platforms use a combination of 1 and 2.
We could start with option 3 but it is not the most effective way to achieve our goal of ensuring participants do not forget to attend the events they registered for.

Here are designs for each of the options
Registration confirmation email

image.png (1×2 px, 303 KB)

Post-registration confirmation dialog

Screenshot 2024-02-07 at 7.39.37 PM.png (1×2 px, 681 KB)

On the Event page

Screenshot 2024-02-07 at 7.41.43 PM.png (1×2 px, 693 KB)
Screenshot 2024-02-07 at 7.41.58 PM.png (1×2 px, 650 KB)
Daimona changed the task status from Stalled to Open.Feb 8 2024, 2:12 PM
Daimona subscribed.

@ifried Please review latest design :)

I would like to get the opinions of engineers on the technical difficulty of the three options, so we can weigh potential impact vs. potential effort, but my current thinking is that all three options may be useful to different users and flows. However, we should probably pick one option to work on first. Some preliminary thoughts:

  • The link in the email is expected behavior for many current event registration platforms, and it works well for those who have an email address associated with their account and are inclined to check and read confirmation emails.
  • The post-registration dialog seems like the most visible for those who have registered for the event, but we don't have a dialog yet, so there will probably be more design/product questions to consider around this flow.
  • The event page link is less intrusive and visible to all users, regardless of whether they have an email address associated with their accounts or if they clicked out of any dialog, but participants may be inclined to click out of the event page after they register and miss it
  • @gonyeahialam has said that these designs will probably need updates to include some privacy information on the users adding their event to an external calendar, so some options may be easier in terms of adding this privacy info than other options

Pinging the engineers who are working this week @Daimona and @MHorsey-WMF to see if any of the 3 options are notably more technically easy/complex or not. Thank you in advance!

I mostly agree with the comments above. Email link is my #1 preference, followed by registration header/details dialog link, followed by post-registration dialog. The main risk with emails is people who do not have an email address, or disable the notification preference. Still, I think it would be so standard (and easy to retrieve later) that it remains my #1 preference.

For the registration header option, I find that the current design is a bit crowded, with the addition of this extra dropdown button. I'm not sure how to improve that. But I see no issues with the dropdown being in the "more details" dialog.

Beside the points raised by @Daimona (about people not having an email or disabling notifications) I would like to raise another risk: notifications that go to the spam folder.
Re: crowded design, I actually think the benefits are greater :), and I would even think a little calendar icon would not hurt on the Event Page design @gonyeahialam shared :)

Thanks for this feedback so far, everyone!

@gonyeahialam: Based on what we have discussed so far, I think it makes sense to prioritize adding the calendar links to the confirmation email and the registration header. What do you think? Also, what do you think of the points raised about whether the link in the registration header is too cluttered feeling (and whether it should perhaps only be on More Details)?

@ifried Though I still think Option 1 and 2 is the best combination we can start with 1 and 3.

The crowdedness of option 3 is one of the demerits of it. I thought of putting it only in the dialog but that would further hide it and make it not discoverable. Using an icon only(though not as clear as using the label 'Add to Calendar') is a middle ground but we have to test if people recognize that the icon means 'Add to Calendar'.

Okay, thanks for this feedback, @gonyeahialam! Thanks for sharing your perspective on why you believe options 1 & 2 are the best. I hear you about the fact that option 2 (the dialog) appears right after someone registers for an event, so it may be a better option than option 3. There is also the issue of crowding the space in option 2. Perhaps an alternative is to first focus on email, followed by the link on 'More Details' and '

As next steps, can you incorporate the recommended text from Legal into updated designs? You can start with updating the design for email (option 1), since it is likely we will work on adding the links into the email first, followed by updating the designs for options 2 and 3.

Updated design for Options 1 and 3 with the privacy note:

Option 1
T358493
Option 3

Screen Recording 2024-02-27 at 3.20.30 PM.gif (602×960 px, 197 KB)

gonyeahialam changed the task status from Open to In Progress.Feb 27 2024, 7:21 PM
gonyeahialam updated the task description. (Show Details)

@gonyeahialam Hello! Can you update the link above to option 2 (no link right now)? Also, is there additional feedback from the engineers, as per Slack, or is this conversation wrapped up? Thank you in advance!

@ifried Okay, I will add the link to the comment above. The links are also in the task description.

@MHorsey-WMF is okay with 1 and 3 but hasn't given feedback on 2.

As this is currently being worked on as an engineering task, I am closing this design ticket as done.