Page MenuHomePhabricator

Add new field to Event Registration to specify event type
Closed, ResolvedPublic

Description

User story

As an organizer, I want to be able to specify the event type, so that it is easier for prospective and registered event participants to understand the structure and goals of the event, and therefore they are better equipped to decide whether they want to join.

Acceptance Criteria:
  • Given that an organizer is on Special:EnableEventRegistration or EditEventRegistration (with a valid event id),
    • They should see a new field below "Organizers" labeled "Event types"
      • And this field should be mandatory
      • And its placeholder should be "Add event types"
      • And the user should be able to add in a maximum of 2 event types
      • And they always see the following instructional text below the field: Add up to two event types. If you choose “Other,” it must be the only selection.
      • And if they add more than 2 event types, they should see the following text: "The number of items you specified is above the maximum of 2."
      • And if they enter both "Other" and another type (doable by disabling JavaScript), they should see the following text: "You cannot choose 'Other' along with other event types. Please choose only 'Other' or remove it to choose other options."
  • Given that any organizer of an event is editing event registration information,
    • They should be able to edit the event type at any time (including after an event ended)
  • The work to display this data on special pages will be handled in separate tickets
  • Add a feature flag

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Priority:

  • This ticket - and in particular the question on "Other" shared below - is the first priority for design work in this epic.

Design questions to figure out include:

  • How do we handle the selection of Other? The reason we have Other is because we want to make the selection event type mandatory (so we can get complete data on event type), but we believe some people may not think our list of event types covers their event. For this reason, we want to allow the option for Other. However, if we do allow Other, we don't want organizers to pick a second event type. If they do, it defeats the purpose of Other. So, we want that organizers can pick only 1 option for Other (i.e., Other) but a maximum of 2 options for event types. The question is - does this make sense, or is this break in pattern too unnecessarily confusing? What design options do we have? These are the questions to explore.

Change #1144699 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add feature flag for event types field

https://gerrit.wikimedia.org/r/1144699

Change #1144701 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add multiselect field event types

https://gerrit.wikimedia.org/r/1144701

Change #1144699 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add feature flag for event types field

https://gerrit.wikimedia.org/r/1144699

Change #1146805 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Get all event types option messages

https://gerrit.wikimedia.org/r/1146805

Change #1146805 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Get all event types option messages

https://gerrit.wikimedia.org/r/1146805

Change #1144701 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add multiselect field event types

https://gerrit.wikimedia.org/r/1144701

Hi folks, I documented the observation and insights for the 'Other' behavior here T393954: Run user tests on 'Other' behavior for Event type selection.

The final recommendation is to disable the 'Other' option when a standard event type is selected, and that standard event types are disabled when 'Other' is selected. @cmelo @Daimona @MHorsey-WMF @ifried how does this sound?

Hi folks, I documented the observation and insights for the 'Other' behavior here T393954: Run user tests on 'Other' behavior for Event type selection.

Thanks for investigating this!

The final recommendation is to disable the 'Other' option when a standard event type is selected, and that standard event types are disabled when 'Other' is selected. @cmelo @Daimona @MHorsey-WMF @ifried how does this sound?

Is it possible to disable options in the MenuTagMultiselectWidget? I've never seen that done, and a quick look at the demo and code seems to suggest that it isn't possible. I'm probably missing something though, so waiting for others to weigh in.

Hi folks, I documented the observation and insights for the 'Other' behavior here T393954: Run user tests on 'Other' behavior for Event type selection.

The final recommendation is to disable the 'Other' option when a standard event type is selected, and that standard event types are disabled when 'Other' is selected. @cmelo @Daimona @MHorsey-WMF @ifried how does this sound?

This sounds good & makes sense to me. I'll wait for more engineers to weigh in on the feasibility/complexity.

@ifried the patch above in T386273#10830023 was merged by mistake while not fully ready. We have some error messages that are not present in the AC but that have already been merged. I'd like to hear your thoughts on these and make any necessary changes to those ASAP (although we already got various translations):

  • Error message when "other" is selected together with another event type. Note that this will also be used by the API, so it would be great if we could make it a bit more abstract and avoid terminology strongly related to a visual input field, like the verb "select". This wasn't mentioned above, and the merged copy is:

You cannot select 'Other' along with other event types. Please select only 'Other' or remove it to choose other options.

  • Help text below the field. No mention in the AC, but as noted in T386273#10589695, I wonder if we should have one and mention the limit like we did in T385339. Here's the merged copy; note, the text assumes the design proposed in T393954, but we haven't implemented it or determined its feasibility:

Selecting 'Other' will disable and deselect all other event types.

  • Placeholder for the field, also not mentioned above. For comparison, we use "Add specific wikis" for wikis, and "Add topics" for topics. Merged copy:

Select event types...

  • According to the AC, the field should be labeled "Event type", but the merged version is "Event types", which actually makes more sense to me. Can we update the AC?
  • Error message for adding > 2 types: I previously said we may not need it, but on closer look, we actually do. This would also be used by the API. The current proposal in the AC ("Enter a maximum of 2 event types.") works for me and is consistent with the messages for wikis and topics, so just double-checking that we can finalize that in the AC.

@Daimona, responses below:

@ifried the patch above in T386273#10830023 was merged by mistake while not fully ready. We have some error messages that are not present in the AC but that have already been merged. I'd like to hear your thoughts on these and make any necessary changes to those ASAP (although we already got various translations):

  • Error message when "other" is selected together with another event type. Note that this will also be used by the API, so it would be great if we could make it a bit more abstract and avoid terminology strongly related to a visual input field, like the verb "select". This wasn't mentioned above, and the merged copy is:

You cannot select 'Other' along with other event types. Please select only 'Other' or remove it to choose other options.

Given that we want to avoid the word "select," we can replace it with "choose."

So, the text would be: "You cannot choose 'Other' along with other event types. Please choose only 'Other' or remove it to choose other options."

  • Help text below the field. No mention in the AC, but as noted in T386273#10589695, I wonder if we should have one and mention the limit like we did in T385339. Here's the merged copy; note, the text assumes the design proposed in T393954, but we haven't implemented it or determined its feasibility:

Selecting 'Other' will disable and deselect all other event types.

Sounds good to me.

  • Placeholder for the field, also not mentioned above. For comparison, we use "Add specific wikis" for wikis, and "Add topics" for topics. Merged copy:

Select event types...

Wouldn't it make sense for it to be "Add event types" instead?

  • According to the AC, the field should be labeled "Event type", but the merged version is "Event types", which actually makes more sense to me. Can we update the AC?

Yes, I will update the AC for the field to be "Event types."

  • Error message for adding > 2 types: I previously said we may not need it, but on closer look, we actually do. This would also be used by the API. The current proposal in the AC ("Enter a maximum of 2 event types.") works for me and is consistent with the messages for wikis and topics, so just double-checking that we can finalize that in the AC.

Yes, sounds good & will add to AC.

ifried updated the task description. (Show Details)
  • Help text below the field. No mention in the AC, but as noted in T386273#10589695, I wonder if we should have one and mention the limit like we did in T385339. Here's the merged copy; note, the text assumes the design proposed in T393954, but we haven't implemented it or determined its feasibility:

Selecting 'Other' will disable and deselect all other event types.

Sounds good to me.

To clarify, what copy are you suggesting here? Keeping the current sentence and then explaining the limit? E.g. Selecting 'Other' will disable and deselect all other event types. You can choose a maximum of 2 types.

Daimona updated the task description. (Show Details)
Daimona updated Other Assignee, added: Daimona; removed: cmelo.
  • Placeholder for the field, also not mentioned above. For comparison, we use "Add specific wikis" for wikis, and "Add topics" for topics. Merged copy:

Select event types...

Wouldn't it make sense for it to be "Add event types" instead?

Also, yes. To clarify, the currently merged text were not ready to be merged, and I do believe that some messages (like this placeholder) have room for improvement. Unfortunately they've been on translatewiki for ~10 days already, so we got a few translations, but it's never too late to prevent more.

Change #1152077 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Re-order event properties

https://gerrit.wikimedia.org/r/1152077

  • Help text below the field. No mention in the AC, but as noted in T386273#10589695, I wonder if we should have one and mention the limit like we did in T385339. Here's the merged copy; note, the text assumes the design proposed in T393954, but we haven't implemented it or determined its feasibility:

Selecting 'Other' will disable and deselect all other event types.

Sounds good to me.

To clarify, what copy are you suggesting here? Keeping the current sentence and then explaining the limit? E.g. Selecting 'Other' will disable and deselect all other event types. You can choose a maximum of 2 types.

We should swap the order, so it is: You can choose a maximum of 2 types. Selecting 'Other' will disable and deselect all other event types.

This message assumes that we implement support for the Other option as the way described above.

Change #1151804 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/extensions/CampaignEvents@master] Add validation for event types

https://gerrit.wikimedia.org/r/1151804

Current status: I implemented, updated, or refactored event type validation to match the AC (this was also needed for the API task I'm working on: T387491). Left to do: investigate feasibility of design proposed in T386273#10852933; implement it; make sure the related error message is accurate ("will disable and deselect all other event types").

@cmelo I've done a bit of work here that I needed for API stuff. Since you began working on this task, I'll back into the bushes and let you finish this.

Change #1152077 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Re-order event properties

https://gerrit.wikimedia.org/r/1152077

Change #1151804 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Add validation for event types

https://gerrit.wikimedia.org/r/1151804

Current status: I implemented, updated, or refactored event type validation to match the AC (this was also needed for the API task I'm working on: T387491). Left to do: investigate feasibility of design proposed in T386273#10852933; implement it; make sure the related error message is accurate ("will disable and deselect all other event types").

@cmelo I've done a bit of work here that I needed for API stuff. Since you began working on this task, I'll back into the bushes and let you finish this.

Ok, I saw that and already reviewed them, thanks.

Hi @ifried since we decided to split it into two parts:

  • Deploy it as-is, meaning we will use the default behavior of the component, which is:
    • The user will be able to select the “Other” option along with any other option, but if the form is submitted this way, the application will return an error message stating that the “Other” option cannot be selected together with other options (see image below).
  • Create a new task T396502 to explore and test possible customizations. The options are:
    • Implement the behavior described in the IC for T386273, which disables and removes all other options when “Other” is selected. I’ve already implemented this and there’s a patch for it, I have moved it to code review to get feedback on its implementation, so we can decide if it is really ok or not, since it's a bit hacky.
    • Another option we discussed, suggested by @Daimona, is to add a front-end validation that informs the user as soon as “Other” is selected together with any other option. This would be easier to implement but still counts as a customization.
    • We could also choose not to do any customization for now and revisit it later — possibly when we migrate the entire page to use Codex.

All that said there is a final decision we need to do about this task which is: What should be the help message we show below the event types field?

  • Currentlly it says: Selecting 'Other' will disable and deselect all other event types. but that is not the case anymore since we will not do the customization now, so I am wondering what message should we show now @ifried

Screenshot 2025-06-11 at 09.22.31.png (789×924 px, 94 KB)

Note - bottom instructional text needs to be updated to say something: Select a maximum of two event types, except if you pick Other (1 only).

text updated to be: You can choose a maximum of 2 types, except for "Other." You must select "Other" alone.

@JFernandez-WMF, do you think the language is clear?

thanks @ifried! that looks good to me. i made some minor suggestions for improvements on clarity and tone:

Select up to two event types. If you choose “Other,” it must be the only selection.

how does that sound?

@JFernandez-WMF - even better! i love your suggestion. i will use it and will update the ac. thank you!

i just made one tweak to make the first word be "add" rather than "select," since we're trying to avoid "select" and it is more consistent with topic text ("You can add a maximum of 5 topics.")

ifried updated the task description. (Show Details)

Change #1156929 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Update event types multiselect help message

https://gerrit.wikimedia.org/r/1156929

Change #1156929 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Update event types multiselect help message

https://gerrit.wikimedia.org/r/1156929

vaughnwalters subscribed.
  • Given that an organizer is on Special:EnableEventRegistration or EditEventRegistration (with a valid event id),
    • ✅ They should see a new field below "Organizers" labeled "Event types"
      Screenshot 2025-06-17 at 2.51.56 PM.png (270×364 px, 26 KB)
      • ✅ And this field should be mandatory QA Note - this field IS mandatory, but it is not marked as such in the UI, see follow up tasks T396392 and T396395
      • ❌ And its placeholder should be "Add event types"
        Screenshot 2025-06-17 at 2.52.26 PM.png (176×440 px, 21 KB)
        Currently the placeholder is "Select event types" and it should be "Add event types"
      • ✅ And the user should be able to add in a maximum of 2 event types
      • ✅ And they always see the following instructional text below the field: Add up to two event types. If you choose “Other,” it must be the only selection.
        Screenshot 2025-06-17 at 2.54.23 PM.png (190×998 px, 33 KB)
      • ❌ And if they add more than 2 event types, they should see the following text: "Enter a maximum of 2 event types."
        Screenshot 2025-06-17 at 2.56.14 PM.png (1×1 px, 109 KB)
        The message that is currently shown is The number of items you specified is above the maximum of 2. Does the AC need changed here or the message that is shown? @ifried
      • ✅ And if they enter both "Other" and another type (doable by disabling JavaScript), they should see the following text: "You cannot choose 'Other' along with other event types. Please choose only 'Other' or remove it to choose other options."
        Screenshot 2025-06-17 at 2.59.00 PM.png (244×1 px, 48 KB)
  • Given that any organizer of an event is editing event registration information,
    • ✅ They should be able to edit the event type at any time (including after an event ended)
  • ✅ The work to display this data on special pages will be handled in separate tickets
  • ✅ Add a feature flag

Change #1166036 had a related patch set uploaded (by Cmelo; author: Cmelo):

[mediawiki/extensions/CampaignEvents@master] Add custom message for max of event types

https://gerrit.wikimedia.org/r/1166036

Thanks, @vaughnwalters, I have fixed both to match the AC, I will move then to qa again as soon as it is merged

  • ❌ And its placeholder should be "Add event types"
    Screenshot 2025-06-17 at 2.52.26 PM.png (176×440 px, 21 KB)
    Currently the placeholder is "Select event types" and it should be "Add event types"

✅ Done

  • ❌ And if they add more than 2 event types, they should see the following text: "Enter a maximum of 2 event types."
    Screenshot 2025-06-17 at 2.56.14 PM.png (1×1 px, 109 KB)
    The message that is currently shown is The number of items you specified is above the maximum of 2. Does the AC need changed here or the message that is shown? @ifried

✅ Done
I think what is in the AC is the correct one, but just as a note, this multi select field has a max parameter, and by defining it, as in our case the max is 2, it automatically generates the error message, so I used a validation callback in order to use the custom one in the AC.

cmelo updated the task description. (Show Details)
cmelo changed the task status from In Progress to Stalled.Jul 9 2025, 1:57 AM
Daimona changed the task status from Stalled to Open.Jul 9 2025, 11:13 AM

Change #1166036 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Update placeholder for event types field

https://gerrit.wikimedia.org/r/1166036

Thanks, @vaughnwalters, I have fixed both to match the AC, I will move then to qa again as soon as it is merged

  • ❌ And its placeholder should be "Add event types"
    Screenshot 2025-06-17 at 2.52.26 PM.png (176×440 px, 21 KB)
    Currently the placeholder is "Select event types" and it should be "Add event types"

✅ Done

This is correct now.
✅ And its placeholder should be "Add event types"

Screenshot 2025-07-09 at 2.37.56 PM.png (168×418 px, 20 KB)


  • ❌ And if they add more than 2 event types, they should see the following text: "Enter a maximum of 2 event types."
    Screenshot 2025-06-17 at 2.56.14 PM.png (1×1 px, 109 KB)
    The message that is currently shown is The number of items you specified is above the maximum of 2. Does the AC need changed here or the message that is shown? @ifried

✅ Done
I think what is in the AC is the correct one, but just as a note, this multi select field has a max parameter, and by defining it, as in our case the max is 2, it automatically generates the error message, so I used a validation callback in order to use the custom one in the AC.

AC is now And if they add more than 2 event types, they should see the following text: "The number of items you specified is above the maximum of 2." so this is also correct now.

Screenshot 2025-07-09 at 2.41.28 PM.png (216×1 px, 38 KB)


With these changes, everything looks good to me - I am sending this to design sign off. Nice work yall. The remainder of the AC testing can be found at T386273#10925560.