CiviCRM Community Forums (archive)

It feels like Christmas. The multiple participant registration is finally here, profile fields work with it, and you can even set "PayLater" as the ONLY payment type - and it works beautifully. Thank you all (especially the person who lead this feature)!

I have some feedback on the user interface for the multiple participant registration:

1. The "Register additional people for this event" link may need to be more visible/apparent. This could be solved with an option to include an icon next to the text, and/or to make the font bigger, and/or to have the fieldset expended by default. Anything to make the option stand out more.

2. The "Skip Participant" button is just asking to be mistaken for the "Continue" button. "Skip Participant" could perhaps be placed slightly above or below the "Continue" and "Back" buttons. Or some other brilliant way of showing the option while reducing the chance it will be mistaken for the "Continue" button.

3. While entering registration information for the participants, I can see some people freaking out when the info they entered 'disappears' as the next (blank) participant fields appear. If you're not looking at the header "Register Additional Participant No 3 of 12" you may think that your entries are disappearing as you click 'Continue'. This could be solved by making the font for the TOTAL number larger than the font for the current number, like this:

Register Additional Participant No 3 of 12

Or (and this would likely need to be 2.1.x or 2.2) we could have a continually updated checklist along the right side, showing the first and last name of the entered participants. I have made a mock-up example and attached it as a PNG.

Just my observations about the interface. FANTASTIC JOB getting these important features added. They work great!

THANK YOU!

I like the idea of some type of highlighting on the fact that data entry has moved on to the next participant. It took me a second to notice that number change when I did my test. But one modification of the PNG mockup. I like the idea of the expanding list, but would not show numbers for unentered guests. The list of numbers ending at 12 might make some people think that this is the maximum number of people that can be included in this transaction. To show that that this is an expanding list, the final entry could some special name like "Being entered" or "Next entry" to show that the one currently being typed in.

Thanks for this feature. This is one I have been looking forward to.

Thanks for the feedback!! I'll discuss these points with the team and post back here.

Thanks for the feedback! Responses inline...

1) Instead of asking the person for the number of extra participants, just have a button labeled "Add Another Participant".  This button should be available on each screen.  So no matter if they are on the first participant or the 10th, there are buttons labeled "Add Another Participant" and "Review all Participants"   

This seems like a reasonable alternative approach but would require a pretty big re-do of the code. For now we'll stick w/ the current model and see how it flies.

2) On the summary screens where info for all participants is listed, the "Participant Role" is currently listed in the "Event Information" area. Should be listed with each participant.

Can you clarify which screens you're referencing here??

3) In an example where I entered 3 participants, the summery screen labeled the section for the first person as "Name and Address" then the 2nd person as  "Additional Participant Information - Participant 1" and the 3rd person as "Additional Participant Information - Participant 2"   

I think those labels would confuse many of my users.  Instead could the labels be "Participant 1 Information ", "Participant 2 Information ", and "Participant 3 Information" Or something similar.  If a user registers 3 people, they should see participants listed as 1, 2 and 3.

In general, the first person registered should not be treated differently than any of the other people registered for the event on any of the screens. 

We've fixed this so that 'additional participants' are numbered 'properly' as you've suggested - and changed the labels. There is still some differences in how the first participant is displayed - partly due to needing to handle the single vs. multi participant cases in shared code and layouts. Also, I think this makes sense logically as the "first participant" is also the person who is doing the registering AND doing the paying.

4) On the summary screen for a paid event, the fee per person should be listed with each participant's info.  ( Just the grand total should appear in its own section)

We've grouped all the fees in order to show sub-totals+grand total in a block. The email confirmations sent to each "additional" (non-paying) participant show only their fees.

2) On the summary screens where info for all participants is listed, the "Participant Role" is currently listed in the "Event Information" area. Should be listed with each participant.

Ahh missed that because it only shows if the (default) Role is something other than "Attendee". Moved that to it's own display block.

You are making too many assumptions about various use cases for CiviEvent. In my use case( a parent registering their 3 kids for school) the "first participant" is just the first kid, not the parent who is filling out the form. The person filling out the form may not be the one paying. It may be a free event. Or it may be a paid event where I have chosen "Pay Later" as the only payment option.  In the pay later case where it is one adult registering other adults ( friends) , everyone just brings their own fee to the door.

Point taken - hopefully you'll be able to tweak the labels / layout on the templates in a way that make sense for your use case(s).

Thanks for adding the message "Registration information for participant x has been saved. " I think that really improves the usability. But the message never shows up for the first/main participant. The message only shows up for participant 2 and higher.

This is fixed.