Event rego - interface for additional people is counter-intuitive

[ken]

For events with multiple registrations, I find the user interface counter-intuitive.

Let me explain

• The widget for 'register additional people' is a button, which suggests (to me) that pressing it will take me to a new screen. Can I suggest using radio buttons with the choices being 'single' (the default) and 'multiple', and clicking 'multiple' enables a number-of-people field (clicking 'single' disables it)
• The single/multiple choice is made at the wrong time. It is currently placed between the email address and the top-of-page profile, which in my mind go together, as the email address and profile data refer (usually) to the person registering. Some thought should be put into whether it goes before the email or after the profile (it shouldn't go after the credit card details because the choice made affects the cost). The current wording on the button ('additional people') suggests it should go after the profile, but if the language used is 'single' / 'multiple' it should go before the email.

Ken

[lsmithgo]

The above post is spot on!  It is intriguing that no-one responded

[Dave Greenberg]

Would be great to hear others thoughts on this - it's a pretty easy change if there's some consensus - and especially if folks have gotten direct feedback from users (or done some informal usability tests) that back up their recommendations.

[xavier]

• The widget for 'register additional people' is a button, which suggests (to me) that pressing it will take me to a new screen. Can I suggest using radio buttons with the choices being 'single' (the default) and 'multiple', and clicking 'multiple' enables a number-of-people field (clicking 'single' disables it)

On about any web2 site, you get the buttons either going to a new page or staying in the same (eg compose email on gmail).

The fact that you go to a new page or not doesn't matter, you expect to get a form and you get it, doubt that having (or not) a different url and spending more time redrawing the page is relevant for the end user.

• The single/multiple choice is made at the wrong time. It is currently placed between the email address and the top-of-page profile, which in my mind go together, as the email address and profile data refer (usually) to the person registering. Some thought should be put into whether it goes before the email or after the profile (it shouldn't go after the credit card details because the choice made affects the cost). The current wording on the button ('additional people') suggests it should go after the profile, but if the language used is 'single' / 'multiple' it should go before the email.

Do agree. moving the additionnal people after the profile make sense than where it is.

X+

[lsmithgo]

All my test users (ok, my wife and mother!) couldn't understand the default method, so I hacked the .tpl file so that essentially the "show" behaviour of the button is forced.  Therefore signup looks like this:  (see attached)

[Dave Greenberg]

Hmm - this looks pretty good to me, maybe combined with Ken's suggestion of moving the "How many addtional..." field above the Email Address field.

Ken, others folks - thoughts on this?

[ken]

Thanks for all your contributions on this post!

Reflecting on the workflow, I think we need to assume the person registering has never used a CiviCRM registration screen before.

And this is why the word "additional" bothers me.

• It's a word that makes sense to people with a Civi history because we know that registering more-than-one person is a recent addition to the function set.
• Sometimes people are not registering for themselves. In that case, all the attendees are "additional".

So I don't think a person registering for an event thinks that their guests/colleagues are "additional" people. They will be thinking "I want to register for N people"

So this is the workflow I envisage ...

• Present the question "For how many participants are you registering? (Leave blank if it's just yourself)" then the rest of the rego details
• If the answer is '1' or blank then the traditional process is followed
• If the answer is 'a number greater than 1' then use some Javascript to show the text "You will need to enter the registration details for each participant. You only need to enter the payment details for the first participant." and then follow the multiple-participant workflow
• If the answer is anything else, then show an error

The how-many-participants question is only needed if the event has multiple-participant registration enabled.

I think that it is reasonable to allow a blank as the answer to the how-many question, and interpret that as '1'. It simplifies the data entry, and is the typical case. And, if that assumption is invalid, it can be picked up on the confirmation page.

The only issue with this proposal is that the meaning of the how-many variable is changed, so some back-end logic changes are needed.

[xavier]

Thanks for all your contributions on this post!

Reflecting on the workflow, I think we need to assume the person registering has never used a CiviCRM registration screen before.
...
So I don't think a person registering for an event thinks that their guests/colleagues are "additional" people. They will be thinking "I want to register for N people"

I think at this point this is worthwhile remembering that the vast majority is going to register themselves, and that's it.

The most common scenario by far is one person registers.

I'm guessing the distant second is that Mr is going to attend accompanied by Ms, or Junior(s), or both. The "add additional" kind of make sense in that case, IMO, but you are right saying it could be clearer.

• Present the question "For how many participants are you registering? (Leave blank if it's just yourself)" then the rest of the rego details
• If the answer is '1' or blank then the traditional process is followed
• If the answer is 'a number greater than 1' then use some Javascript to show the text "You will need to enter the registration details for each participant. You only need to enter the payment details for the first participant." and then follow the multiple-participant workflow
• If the answer is anything else, then show an error

The how-many-participants question is only needed if the event has multiple-participant registration enabled.

I think that it is reasonable to allow a blank as the answer to the how-many question, and interpret that as '1'. It simplifies the data entry, and is the typical case. And, if that assumption is invalid, it can be picked up on the confirmation page.

The only issue with this proposal is that the meaning of the how-many variable is changed, so some back-end logic changes are needed.

"leave blank..." sounds clunky, if we go that road, the default is "1" and that's it.

Does your workflow means getting an extra step than today for registering a single participant ? Not sure I properly understood. If that's case, your suggested improvement is worth than the actual solution.

X+

P.S. And yes, my opinion needs some proper user testing to be more than just opinion

[ken]

Xavier,

To clarify, I don't propose that the one person scenario takes an extra step. It is, as you observe, the default scenario, and it should therefore be the default in the workflow.

I envisage that if the user ignores the "number of people" field then the system behaviour defaults to become a single-person registration.

Ken

[Dave Greenberg]

Perhaps the conditionally displayed field (when "Allow registration for multiple participants" is enabled) should be a drop-down with default = 1:

"How many people are you registering for?" [ 1 v]

This is a common interface for purchasing movie tickets online etc. and is simpler IMO. However we would need to decide on an arbitrary upper limit here (10?) - which could held as a constant in the template for relatively easy override.

Ken's concept of adding the "help" for multiple participants conditionally via jscript if # of people > 1 makes sense as well:
"You will need to enter the registration details for each participant. You only need to enter the payment details for the first participant."

... although I feel like this might need some more fleshing out so it's clearer that registration details for folks other than "themselves" are entered on subsequent pages. Otherwise they might be looking for where that's suppposed to happen on the first page ??

[ken]

Thanks, Dave!

Your drop-down suggestion is what I was trying to express, but you did it much more clearly.

I'm not clear on why an upper limit is needed ... except it would be a tedious way to register 100 people!

And I agree that the text should explain that subsequent registrations are on subsequent pages.

Ken

[Dave Greenberg]

Dropdowns need to have a defined set of options - hence an upper limit :-)

Any thoughts on the specific additional text to clarify "subsequent pages" would be helpful.

[TimberlineTom]

I appreciate all the suggestions here, I don't think I have any brighter ideas than have already been made. I, too, have had problems with people using the multiple registrations mode. I resorted to putting detailed instructions how the registration process worked in the header of the on-line registration because too many people were getting lost. I look forward to some new workflows in future versions.

[Dave Greenberg]

I've filed an issue for 3.1 for this improvement. You can follow progress here:
http://issues.civicrm.org/jira/browse/CRM-5289

[ken]

Thanks Dave!