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.

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.

Design Progress Update

In T322209#9350424, @ifried wrote:

Hello @gonyeahialam, I have discussed this ticket with some members of the team, and I have decided that this is a high-priority design task to work on. This is because I think this would be a very useful feature for organizers, since some organizers would not want to ask any questions (or some of the questions) to their participants. In that case, could you add this ticket into your work for this week and beyond to develop some designs to determine how we could handle a scenario in which the organizer can pick which questions are a part of the event registration form? I see that there is also a design file link in this ticket, but I'm not sure if any work has already been done. Curious to hear your thoughts; thanks!

1. For the copy, go with the copy in the build.

UI Task in order of priority

In T334761#9276848, @ifried wrote:

@gonyeahialam Hello! It looks like this task is the same as T340115 at this point (in terms of the AC). I can close it, correct?

@Daimona If the number of participants who answered the affiliate question or the number of responses, 20 yes 20 no, don't change after people cancel their registration, why can't we leave the 'No responses' value the same after registrations are canceled?

Current iteration on Event Invitation - Mobile web (Work in progress)

@Daimona what do you think of using 'Less than or equal to X' for the No responses scenario you described?

@Daimona my recommendation was for only numbers not percentages. So we can use Less than X for numbers only

Latest design exploration on event invitation
@ifried
Constraining ourselves to the character length limit and normal functionality of echo notifications. The echo notification could look like this:

2b. For events using the Event registration tool
Event Invitations within the Event registration tool

Design explorations

Design exploration

@Daimona yes

In T340115#9253353, @MHorsey-WMF wrote:

@ifried The message here is Wikimedia specific "In accordance with the Wikimedia foundation's terms of use", we will need a generic version.

@Daimona In the future, the form may become longer and will need to be further broken down into more sections. It would be cluttered to have many such rectangles. We can explore this at that time or if another need requires it.

In T345353#9259626, @Daimona wrote:

Data retention information icon is in focus (see outline around the element) any time the user clicks on the Participants tab from another tab

That's the default behaviour in OOUI where it auto-focuses the first clickable element of each tab when you select that tab. We can disable that if we want to.

In T348338#9253955, @Daimona wrote:

In T339978#9224231, @Daimona wrote:

That's how the standard form sectioning works, each section is put inside those rectangles. We could have a rectangle for the whole form, but that's only available when the form itself has a legend, which it doesn't in this case.

Is this task blocking the release?

In T340115#9253353, @MHorsey-WMF wrote:

@ifried The message here is Wikimedia specific "In accordance with the Wikimedia foundation's terms of use", we will need a generic version.

@MHorsey-WMF What terms of use will the generic version be linked to since the one currently linked is Wikimedia's?

@gonyeahialam The text is inconsistent with regular styling, the light grey is usually reserved for disabled text or help text. can we agree that it will not be grey and instead the standard black?

The color I am using is the color for subtle text #54595D/Gray600/Base 20. The disabled color is #72777D/Gray500/Base30. But since this text is for an action and clickable you can go ahead to use the standard black (#202122/Gray700/Base10) so it is not confused as disabled.

In T321814#9248145, @ifried wrote:

@gonyeahialam: I have updated the copy for grant ID based on the fact that we will be asking for numbers only. Here is my suggestion; what do you think?

"If this program or event is supported by a grant from the Wikimedia Foundation, please provide your Grant ID, which you can find in the Grantee Portal (Fluxx).
Please enter the numbers and dashes in your grant ID, but exclude the letters. For example, if your grant ID is G-1111-1111, please enter 1111-1111."

Yes @ifried @vaughnwalters I agree we should follow the same format. I mentioned it above in T346329#9188346:

Any range, whether it is for the options or 'No response' that starts from zero as in <5 or 0 ≤ x ≤ 8 we use Less than 5, Less than 9(or whatever the number is)
If the lower range is above zero as in 8 ≤ x ≤ 16 we use Between 8 and 16

In T340115#9249494, @MHorsey-WMF wrote:

@gonyeahialam The AC says that this will appear when enabling registration, but does not specify if it should appear when EDITING registration. If the organiser does not accept the agreement initially, should it show on the edit form for them?

I don't know if you have already identified it but I think I may have found a bug. @vaughnwalters
What happens when an organizer tries to send a message of less than 10 characters? @Daimona

In T321814#9236333, @ifried wrote:

Okay, update :) I spoke with @cmelo and it is a very small amount of work to allow organizers to provide the full grant ID, so we will not require the organizer to add only the last 8 digits. This means the designs can stay the same and the organizers can add in the full grant ID. cc @gonyeahialam and @Rmaung

@ifried
We would need to modify the description/helper text above to clearly inform organizers to only input the numbers.
If organizers are not used to using the numbers alone, the chances of the organizers making mistakes will increase

@vaughnwalters
Is "Event details: Sandbox/VWalters..." the email subject?

In T321814#9234901, @cmelo wrote:

Hi @ifried and @gonyeahialam I would like to check with you on the grant ID format we will ask the organizer to provide, for what I saw in the designs on the tasks, it says:

e.g. G-RF-1201-3302

But I remember we mention that we would be asking only the digits, so it would be only:
e.g. 1201-3302

So I am wondering if we will really be asking the full grant ID, if we do, we will need to update T346956 AC, also it adds a small complexity on the code which is make a regex to remove the "G-RF-" before sending it to be validated, because the API only accept the digits like "1201-3302"

In T339978#9224231, @Daimona wrote:

In T339978#9224183, @gonyeahialam wrote:

@Daimona Can't the two sections be inside a single rectangle/border, instead of rectangles around each section?

That's how the standard form sectioning works, each section is put inside those rectangles. We could have a rectangle for the whole form, but that's only available when the form itself has a legend, which it doesn't in this case.

In T339978#9221828, @vaughnwalters wrote:

In T339978#9221656, @gonyeahialam wrote:

@vaughnwalters Can I see the screenshot of the full form?

@gonyeahialam I had to zoom out to see the whole form but here it all is together.

and here's a gif of it:

In T321814#9222435, @Rmaung wrote:

On this meta page for grants you can view the icons currently used-- I think it would make sense to mirror the one used for the grantee portal ("Add ltr") but if that presents an issue I think the star would be a safe choice.

I am working on adding Grant ID to event details but I am a bit stuck on finding the most appropriate logo. @ifried would like your feedback on the logo.

In T339978#9185375, @vaughnwalters wrote:

I think this text is confusing, since "past" and "future" are not defined: "Past event dates cannot be changed to future dates to protect participant data." We can rewrite it to something like: "The event has ended, so you cannot change the event dates to future dates. This restriction protects participant data." This is lengthier, but perhaps more helpful in actually conveying the behavior to organizers. What do you all think? Curious to hear other opinions, especially from @gonyeahialam.

@cmelo 80vh is good.

@ifried Does the last AC "The grant ID should not be displayed in the event page user interface. It should only be viewable in the organizer view when configuring or editing registration." also mean that the GrantID wouldn't show up in the organizer view of the event details page?

I have updated the design to include the correct format of the grant ID as a placeholder text in the form field "e.g. G-RF-1201-3302". @ifried Can the acceptance criteria be updated to include this?

In T322332#9192276, @ifried wrote:

@gonyeahialam: This task can be closed, right?

@ifried what is the reason for this AC "The grant ID information should be entered as freeform text"? Does the GrantID have a fixed format?

In T346329#9192751, @Daimona wrote:

Also one more thing, which could maybe be addressed in a follow-up task. "less than 5" is not capitalised as per T336855. Instead, "Between X and Y" is capitalised. I think we should be consistent here. (I would personally vote for capitalising everything, but I don't feel strongly about it; what I do feel strongly about is consistency).

@ifried
The error message due to the Flux API ('There was an issue with validating the grant ID. Please try again later.') isn't clear enough on the next steps for the user. Should they pause filling it and come back later to try again? Do they clear the field, submit the form, and come back to edit it and see if the ID goes through? This can leave the user frustrated.
A better message might be:
There was an issue with validating your Grant ID. You can try submitting the form again in a few minutes. If the issue persists, you can still submit the form without a Grant ID and add it later by editing the event details.

Yes. it can be the last field in the Event details section of the form. I can work on it next.

In T339979#9188485, @Daimona wrote:

In T339979#9188410, @gonyeahialam wrote:

@Daimona The predefined error message shows when you submit the form and not when the field turns red immediately after you enter a future date.

Yes, you're right, and I think showing the message immediately could be a potential improvement for MW core's date widget. However, given that:

• We already have an error message showing (after you submit the form)
• You already see a notice informing you that future dates cannot be selected
• You have to enter the date manually for this scenario to happen
• The field turns red
• It may not be easy to turn the notice into an error

Could we just leave it as a notice for now, to keep things simpler?

Also, the pre-defined error message is for when you input an earlier date. I don't think there is one for when you input a future date

There is one:

@Daimona The predefined error message shows when you submit the form and not when the field turns red immediately after you enter a future date.
Also, the pre-defined error message is for when you input an earlier date. I don't think there is one for when you input a future date

In T346329#9184307, @Daimona wrote:

In T346329#9183019, @ifried wrote:

Thank you so much, @Htriedman! It's great to hear that you like this idea, so we'll go ahead and implement it. We really appreciate your help on this topic!

And @Daimona, thank you for thinking this through & coming up with a new idea!

As a next step, @gonyeahialam, do you have a recommendation for the best way to represent the range (such as 8 ≤ x ≤ 16 in the example shared above)?

In T339979#9184328, @Daimona wrote:

In T339979#9183116, @gonyeahialam wrote:

In T339979#9183092, @gonyeahialam wrote:

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

My question is: If the user enters the dates directly without using the calendar picker what happens?
Perhaps we turn the notice into an error message.

In that case, the field outline becomes red. If you try and submit the form, you get a predefined error message. This can be tested on beta by manually entering a date in the past (the only difference is in the wording of the error message when the date is in the past vs future). I'm not sure if we would be able to replace the predefined error message in this scenario. Maybe we could have our notice remain a notice, in addition to the predefined error?

In T339979#9183092, @gonyeahialam wrote:

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

@Daimona suggests we disable future dates in the calendar picker instead and show a notice message explaining why always. This prevents the user from making the error in the first place.

Decision(Design/Eng Meeting): Remove the limit from the message body and keep 200 character limit on the subject

Since separate tickets have been created for the changes, I am moving this to product sign-off.

In T339979#9180881, @ifried wrote:

Yeah, I hear you, @gonyeahialam. I was basically trying to do a few things to improve the sentence, which were:

• change from "can't" to "cannot" (since "can't" is a bit informal)
• change from "the future" to "future date," since I thought it was a bit more clear
• change "ensure participant data safety" to "protect participant data" since I found it a bit more accurate & clear

Do you agree with any of the choices I made above?

If yes, what do you think of this rewritten version (see below)?:

"Past event dates cannot be changed to future dates to protect participant data."

In T345200#9178199, @Daimona wrote:

In T345200#9178143, @gonyeahialam wrote:

Also, the title in the build says Multiple organisers, the title is supposed to be the event name

In F37097121, "Multiple organizers" is literally the name of the event.

Also, the title in the build says Multiple organisers, the title is supposed to be the event name

In T326619#9177160, @vaughnwalters wrote:

The AC in this task is met, but there are a few UI issues, and if these should go in another ticket I can make that instead:

1. The search bar is in a different place now than where it is in the comp. Is this intentional?

The build is correct. This page was updated for the Participant questions feature/tasks.

2. The Message participants button should be disabled (gray button) if the organizer does not have an email. The tool tip copy is correct, but right now it is on click of the button - @gonyeahialam can you clarify if this tooltip should appear on click or on hover of the disabled button?

comp	build

If we leave the button disabled then the tooltip will only show on hover. However, we can leave it as it is in the build where the button isn't disabled and the tooltip shows on click.

3. The To message participants... warning should go above the Recipients / Add recipients button

comp	build

Yes, it is above. The warning is a central warning for the whole page.

4. The Delete and Message participants buttons have a slight vertical alignment issue. When inspecting it you can see where it is off:

5. The Delete button and the Message Participants button should not have any space between the buttons.

comp	build

Yes, the buttons are together, the component is called a ButtonGroupWidget (destructive and progressive ButtonWidget)

In T336855#9175638, @vaughnwalters wrote:

Looks good, passing this back to design sign off:

In T339979#9175099, @ifried wrote:

@gonyeahialam & @cmelo, what do you think of the following update to the copy (see below). Do you think it's a bit more clear to readers? Let me know what you think!

"Past event dates cannot be updated to a future date in order to protect participant data."