Thank you, @gonyeahialam! I think this would be a great topic for a future design + engineering sync.

Design Progress Update

Modified the old designs for this task to suit what we currently have.

1. Scroll to the Questions for Participant section
2. Open the accordion
3. Read the instructions
4. Select the questions they want to ask.

NB: Since selecting questions is optional this section doesn't need to be open by default. The organizers only need to open the accordion if they need to. This makes the form look shorter and less overwhelming and focuses the organizer on filling in the event details section.

There are two ways we could display the clickwrap agreement with this new feature

Design 1: The PII questions are disabled from selection until the organizer clicks the Clickwrap agreement checkbox.	Design 2: The Clickwrap agreement doesn't show until the organizer selects a PII question.
This design ensures the clickwrap isn't skipped since the organizer can't select PII questions without accepting clickwrap. Also, legal had previously preferred a version where the clickwrap comes before the questions T334761#8926326.	This design reduces the amount of text in the section and helps organizers focus on the content they need when they need it since the clickwrap only shows when it is needed (when a PII question is selected). The appearance of the clickwrap helps draw attention to it. Even if organizers try to enable registration(with a PII question selected) without agreeing to the clickwrap they will receive an error.

Design 2 appears to be the best option based on the reasons above.

In T322209#9372011, @gonyeahialam wrote:

2. Open the accordion

TTBOMK, individual form sections cannot be made collapsible; only the whole form can be made collapsible.

In T322209#9372195, @Daimona wrote:

In T322209#9372011, @gonyeahialam wrote:

2. Open the accordion

TTBOMK, individual form sections cannot be made collapsible; only the whole form can be made collapsible.

Why so?

In T322209#9374635, @gonyeahialam wrote:

In T322209#9372195, @Daimona wrote:

In T322209#9372011, @gonyeahialam wrote:

2. Open the accordion

TTBOMK, individual form sections cannot be made collapsible; only the whole form can be made collapsible.

Why so?

Because the framework does not allow it (again, unless I'm missing something, that is)

So, in that case, the options would be to have a new form/new box OR to not make the participant sections collapsible? Would that be correct, @Daimona?

In T322209#9375589, @ifried wrote:

So, in that case, the options would be to have a new form/new box OR to not make the participant sections collapsible? Would that be correct, @Daimona?

Yeah, it's fine as long as the section is not collapsible.

Okay, great, thanks. In that case, @gonyeahialam, perhaps you can update the designs based on this technical feedback?

@ifried @Daimona

The Questions for Participant section is collapsed by default because it's optional and can make the form look longer than necessary. Plus, as we add more questions, it could become the longest section in the form. An optional section shouldn't make the overall form appear more complex to users. Meeting a long-form makes users overwhelmed and discouraged from completing it.

To simplify it, I decided to use an accordion element. This keeps our main form clean, allowing organizers to concentrate on entering the event details. They can choose to expand the "Questions for Participants" section if needed; if not, it won't clutter their view — much like Design 2 above, where the clickwrap is only displayed if a personal information question is selected.

Since creating a collapsible section isn't technically feasible, an alternate solution that addresses both current and potential future issues, is dividing the form into 2 or 3 steps. For instance, Step 1. Event details 2. Questions for participants or Step 1. Event details (required questions) 2. all optional questions and 3. Questions for participants.

Step 1	Step 2	Step 3

Fig: sketch of proposed alternative

We can manage the transition between these steps by presenting one step per page or replacing the content of Step 1 with Step 2 when the user clicks the Next button. Or any technically appropriate approach.

Breaking the form into steps simplifies the user experience by reducing cognitive load, organizing information more logically, and making the form seem less overwhelming by presenting it in manageable chunks.

Thanks for this suggestion to break the form into steps, @gonyeahialam! I think this could work and makes sense, but one thing to consider that got brought up in one of our meetings is how we would handle the edit experience of the registration form. Do you recommend that the organizer clicks through multiple steps to edit as well?

In T322209#9393929, @ifried wrote:

Thanks for this suggestion to break the form into steps, @gonyeahialam! I think this could work and makes sense, but one thing to consider that got brought up in one of our meetings is how we would handle the edit experience of the registration form. Do you recommend that the organizer clicks through multiple steps to edit as well?

I am researching and exploring the best solution to this

@gonyeahialam Hello! Since we have decided to deprioritize the multi-step form for this work and we will proceed with a 1-page form for organizers to choose which questions they want in their registration, can you update this ticket with the newest designs? Thanks!

Updated design based on feedback from team and legal/privacy

Design 1	Design 2

Waiting for final feedback from Legal on clickwrap copy and design preference.

I got the final feedback from Legal to go with Design 1. The Clickwrap suggested is:
To view aggregated responses of participants which contain personal information, you must accept the following:

• I agree to handle participant information, including participant personally identifiable information, collected during event registration with care and in accordance with Wikimedia Foundation's Terms of use [https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Terms_of_Use]."

Design 1 has been updated with these changes

Updated design based on this decision:
For the organizer choosing questions, we will first focus on the simplest implementation, which is that the organizer cannot change the participant question selection after enabling registration. We can allow them to edit the questions later as a separate subtask.

We will update the designs so that the clickwrap is only agreed to on the Response Statistics tab, and the organizer will merely see text at the bottom of the event registration configuration form that says: “To view aggregated responses of participants which contain personal information, you will be asked to handle participant information, including participant personally identifiable information, collected during event registration with care and in accordance with Wikimedia Foundation’s Terms of use [https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Terms_of_Use].”

Hello, @gonyeahialam! Is this ready for the engineers to estimate & then begin working on?

In T322209#9462874, @ifried wrote:

Hello, @gonyeahialam! Is this ready for the engineers to estimate & then begin working on?

@ifried Yes, it is ready. Would you still be reaching out to Legal for feedback on the updated designs as you earlier planned?

Update: @gonyeahialam reached out to Legal regarding updated designs.

Update: The designs have been approved internally, so we can go ahead with estimation.

Just to clarify: the task description is up-to-date, right? We're not allowing edits for now, and we'll address that in T354880 instead.

Yes, edits will be worked in T354880, @Daimona. However, I think we don't want to release this feature improvement until we have edits, as done in T354880, since it could be a confusing and frustrating user experience otherwise.

@gonyeahialam @ifried I see from the design specs that the introductory text of the participant questions section has changed. See the bolded parts below.

Current:

During the event, [comma here] you can access the responses of individual participants for questions that do not include Personally Identifiable Information (PII). After the event ends, responses to all questions will be available (in aggregate form only) and individual responses will be deleted.

Proposed:

During the event you can access responses of individual participants for questions that do not include Personal Identifiable Information (PII). After the event ends, responses to all questions will be available but only as aggregated responses, individual responses will be deleted.

I'd like to know which one is the most up-to-date, thank you.

Two more things:

• We can use a standard widget for the question checkboxes, which also allows us to have proper section labels for PII vs non-PII questions. However, these headers use the normal base color, not subtle (which the framework never uses inside forms). I hope that's OK. Else we can fix it but it's not straightforward as we need to complete T351818 first.
• For the notice that appears when you select PII question: it's currently impossible to implement it natively due to T358060. I'd like to know how important it is for the text to be shown/hidden dynamically, as we would need to write a DIY solution for it.

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

[mediawiki/extensions/CampaignEvents@master] [WIP] Organizer chooses questions

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

In T322209#9561588, @Daimona wrote:

@gonyeahialam @ifried I see from the design specs that the introductory text of the participant questions section has changed. See the bolded parts below.

Current:

During the event, [comma here] you can access the responses of individual participants for questions that do not include Personally Identifiable Information (PII). After the event ends, responses to all questions will be available (in aggregate form only) and individual responses will be deleted.

Proposed:

During the event you can access responses of individual participants for questions that do not include Personal Identifiable Information (PII). After the event ends, responses to all questions will be available but only as aggregated responses, individual responses will be deleted.

I'd like to know which one is the most up-to-date, thank you.

The current one with the commas

Decisions from today's design + engineering meeting

• See T322209#9563524 for the copy
• Re field labels: we would need some way to visually differentiate form section and field headings. Our only ways are to either work on T351818 first, or file a task in OOUI / MediaWiki-HTMLForm. I don't think we made a decision on this though.
• Re notice: it's less important now that it no longer contains a clickwrap. It would still be nice to toggle it dynamically, but it's not necessary if it's too hard to implement.

In T322209#9563772, @Daimona wrote:

• Re notice: it's less important now that it no longer contains a clickwrap. It would still be nice to toggle it dynamically, but it's not necessary if it's too hard to implement.

I looked into this. Even without the native implementation I thought it wouldn't have been to hard, so I tried a different approach, until I realised that too doesn't work because of T358682. There would still be other alternatives, but they are even more complex and, most importantly, more brittle. Because this was not a must-have, I am going with a fixed PII notice until the HTMLForm bug is fixed (hopefully).

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

[mediawiki/extensions/WikimediaMessages@master] Add override for CampaignEvents legal message

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

Change #1005199 merged by jenkins-bot:

[mediawiki/extensions/CampaignEvents@master] Allow organizers to choose questions when enabling registration

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

Change #1007398 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Add override for CampaignEvents legal message

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

Acceptance criteria for first iteration

• ✅ Organizers are able to choose to include any of the available participant questions when enabling registration (as of 2024-02-20, these are: age, gender, profession, wiki skill level, affiliates)
• Organizers are able to modify the question selection when enabling registration only
  • QA note - This has changed with T354880 and organizers are now able to modify the question selections after the the event has been enabled
• Organizers cannot add or remove questions after registration is enabled, for instance on Special:EditEventRegistration.
  • Note: this will be changed with T354880 <-- is merged, so the AC above is no longer applicable
  • Note: We can potentially explore differentiating between the participant explicitly choosing to not answer vs. not having the option to answer in the future, but I don't think is high priority for the MVP.
• ✅ Note that "Questions" should not be capitalized in section headers, unlike in the design specs. Also, it should always be "Personally", not "Personal" (when referring to PII).
  • 
• ✅ Organizers see participant data in the Participants tab and Response Statistics tab that matches their selection

PII only gif	non PII gif	PII and non PII gif

• ✅ The following text should be displayed to organizers after the PII questions section:

✅ Generic version

To view aggregated responses of participants which contain personal information, you will be asked to handle participant information, including participant personally identifiable information, collected during event registration with care.

✅ Wikimedia version

To view aggregated responses of participants which contain personal information, you will be asked to handle participant information, including participant personally identifiable information, collected during event registration with care and in accordance with Wikimedia Foundation's [https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Terms_of_Use Terms of Use].

• ✅ Participants who register should still the Data Retention information, regardless of which PII/non-PII questions are selected
• 

AC met, moving to design sign off.