Event Tickets: split first name & Last name

[xrossglobalgroup]

Hello, I organise many free and paid events. Your new plugin is a step in the right direction of what I need. I would like to know for now whether It would be possible to have a first name and last name box, instead of one full name. I want to capture and forward all data to a CRM system and full names cannot be easily split (many people have several first or last names, such as people from latin countries).

[George]

Hey @xrossglobalgroup,

Changing the name fields to something other than the default one-input field would unfortunately require custom coding beyond the scope of the support we can provide 🙁

It is possible, just a bit of a complex change to make.

One important thing to keep in mind regarding the current name field is that the simple “First name” / “Last name” naming convention does not fit for many, many people on this planet, and so for us as the developers of this globally-used plugin we opt for a more accommodating, single-field approach. You can read more about the complexities and varieties of name structures here, for example → http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

You yourself seem to acknowledge this:

many people have several first or last names, such as people from latin countries

So if you think that one-field for names is limiting, then two fields for names is even more limiting.

If you want this first-and-last-name approach just for your CRM software, then maybe a simpler solution would be to have that CRM software itself use the better one-field approach, or at least reach out to them via their support channels. They may have an option for setting the name fields to just be one input.

Let me know what you think about all of this!

If you really need two fields instead of one, and are interested in hiring a professional to help with those customizations, there is a list of highly-rated customizers that we maintain here that might be helpful → http://m.tri.be/18k1

Sincerely,
George

[xrossglobalgroup]

Hello George,

Thanks for your elaborate answer. I understand that for TEC you have to bear in mind the software is used all over the world. However, I still do not agree with your view on the first name and last name separate would be difficult or maybe even undesirable.

It is, despite the considerations in the linked article, the standard the have a first name and last name. Your software is no doubt mostly used in the Western world (Americas, Europe) where people have a first name and a family name. Also Facebook, Google and virtually all of the other networks, associations, clubs, schools etc require people to fill out a first and last name. Actually, even Woocommerce uses this (linked to Wootickets). This is also how things are usually stored in CRM systems, every piece of data separately.

Therefore I think that it is just a small adjustment to your software that would make it much more powerful. Simply give users the option to select what field(s) they want: name OR full name OR first & last OR EVEN only first name. These field options can be shown on the front end by selecting the preference in the backend. Alternatively you can give the option in the back end to merge fields if you ask for a first & last name in two separate boxes on the front end. In the attendees list they can be put together again, depending on what the users prefer. This gives full flexibility.

Just imagine the following:

How many tickets do you want? [quantity selector]
First name: John
Last name: Kennedy

On the participants list you could simply join them, so John SPACE Kennedy. Two separate fields allows people to select for first or last name in the list. You can actually create a setting in the TEC backend that allows users to indicate whether they want to have the fields shown separately or together. This also works when more than one first or last names are used:

How many tickets do you want? [quantity selector]
First name: Maria Christina
Last name: Balbo Hernandez

On the attendees list it could be then shown as:

Name: Maria Christina Balbo Hernandez

OR

First name: Maria Christina
Last name: Balbo Hernandez

OR EVEN

Name: Balbo Hernandez, Maria Christina

I’m sure that many users want to be able to collect full information. I don’t want to give people to fill out a “name” because that may write a full name or just a first name. That’s useless and unprofessional. Selection and search becomes then a senseless exercise. Just consider the following attendees list based on just a single box:

1. Barack Obama
2. Donald J. Trump
3. Tom
4. Melissa K.
5. Tom
6. Karen V.
7. T.F. Van Buuren
8. Tom
9. Alice Thompson
10. Marie Cristina Balbo Hernandez
11. Marie Cristina Hernandez (Cristina being the first name of the family name)

The lists is just a mess like this, you can’t really see who is Tom, you can’t select on first names properly, and you can select on last names, or may not not see where a last name starts. I want to force people to fill out a proper first and proper last name. Some others may only want a first name, whereas yet others want to search on a last name.

To conclude, I think you should reconsider the single name field and give us the option to show specific fields on the front end.

I’ve already talked with my developer and he could either adapt the plugin (I don’t like that for obvious reasons) or we could separate first and last names in the CRM but using the SPACE between the first and last names as a separator. However, in many cases from the above list that would lead to bad results as well.

Thanks for your consideration.

[George]

I appreciate the length of your response and the thoughtfulness here.

To be clear, when I described our reasoning for using the single-field name approach, I was not saying you should not try to change that! 😀

If you feel very strongly that a two-field approach is best for your site, then please build that out. Your arguments are great here and well thought out.

I just have to be honest about two things:

1. The reasoning why we chose the single-field route ourselves.

2. The fact that we cannot help change the single-field method to a two-field method. You said that you think this would be a simple change; it is unfortunately not 🙁 There are many core plugin code components that would need to be modified, an amount of work that is unfortunately far outside the scope of support we can provide.

If we ever do do make this a simple option in the admin panel, then even this would unfortunately not make it into our plugins for at least a few more releases 🙁

I’m sorry about the disappointments here – let me know what you think and if I can help with anything else.

Sincerely,
George

[barback]

I also would like the choice of how names are handled.

In the case of tickets, let’s say the Smiths want to come to my show. Either Bob or Nancy takes care of ordering two tickets.

We work with a printout of the ticket names and if we can’t sort by last names, then we can’t search in the S’s for Smith, we’ll have to instead check the B’s for Bob, N’s for Nancy – and then…. oh, it’s under Robert! This is not very efficient at the door when everyone is trying to check in.

Our process is to export a CSV to prepare the guest list to check people in at the door — fortunately, we are a small theater — we’ll just have to make it work — by manually creating that field in the spreadsheet, or by taking the time to search by first names at the door.

I tried a snippet you had provided for adding a telephone number to the attendees list, but that was from a previous version also, and no longer works.

I am very disappointed to update to a new version and now not be able to do what I was able to do in the previous version.

[xrossglobalgroup]

I didn’t even consider the practical issue that Barback is running into.

Although I’m not technical and have no idea what it would take to write that code, the solution is disappointing. Despite my lack of knowledge, I do honestly believe the current solution is sub-optimal and TEC standard unworthy. You have such a strong product and then you come up with this rather useless solution. On top of that, we had to wait a very long time for it. Had I known this solution before, I would have started my own development. Since you have much to do I can imagine that you can’t work on everything at the same time, but the fact that within 1 single week my developer came up with a tailor-made solution that provides me with exactly what I need (and others apparently), make me think you’ve not given enough thought to this issue. On my site http://www.expatclub.org I can now collect first and last names, I can order and select names, and it’s fully connected to my CRM system. Moreover, it is fully connected to BuddyPress and I can add and remove names myself from the guest list, including BuddyPress profiles. The events even show pictures now.

[George]

Hey @xrossglobalgroup,

There is a lot of great feedback here, though comments like this one of yours are not appreciated:

but the fact that within 1 single week my developer came up with a tailor-made solution that provides me with exactly what I need (and others apparently), make me think you’ve not given enough thought to this issue.

Surely you can see and comprehend the differences between your situation – one developer, working for one customer, on one website – versus our situation – many developers, hundreds of thousands of users, hundreds of thousands of websites.

I’m not being snarky here! Just asking for a bit of respect for our development process 🙂 We have given this much thought, and for the practical realities of the present, we have shipped the first versions of things with one name field.

None of this is to rebuke the feedback provided here though! – quite the opposite! The feedback here is excellent and I appreciate the input from both of you immensely.

I’ll be sharing all of your feedback with our development team. I would not expect a change like this to happen any time in the immediate future, as it would require numerous structural changes through our whole codebase. However, feedback like this makes our product better, and we like making our product better, so more versatility for the way names are handled is something we are quite interested in.

Thank you both for your feedback here. I wish you the best of luck with your projects in the meantime, and for now will close up this thread.

Sincerely,
George

—

PS

Just to address some of the specifics of @Barback’s feedback, the situation you described @Barback is indeed one that can be improved. However, it’s tough to jump to the conclusion that allowing two fields for a name would fix this. (I’m not saying it wouldn’t! Just elaborating on some of the complexities that this would open up).

For example, despite all of the problems you mention, let’s say there are two name fields as an option.

Well, should the second “name” input be a “required” field? i.e. users cannot submit the “buy ticket” form unless both first and last name are required?

If so, then what about all of the problems with the binary name format as elaborated on in the article I shared earlier in this thread?

You might say, “well, make it optional to decide which fields are required”. Okay – but now, from a product design perspective, there are two options for something that there are currently no options for. That is two more decisions a user has to make – by which I mean two more decisions all of our users would have to make, even though at this time your complaints and @xrossglobalgroup’s complaints are the only complaints about this we’ve had so far.

So, does it make sense to add two steps to the installation/setup process for Tickets and Events for hundreds of thousands of users, based on two complaints?

Hmmm…

Next, you bemoan the inefficiency with your process and claim that it is our naming field that is the cause of this. However, note that you also said that you PRINT OUT your list of names – surely choosing this over using a smartphone or computer is a big part of the inefficiency too, no? If using a smartphone or computer for check-in is not possible, I don’t mean to deride your choice to use paper – but I’m just acknowledging that there’s a whole robust, efficient, and fast Check-In / Attendees Management system provided by our plugin that you leave completely off the table by choosing to print out the names.

Finally, tickets do have unique security codes. Perhaps an even better option than any name-related option would be to put the attendees items into a CSV, and then just sort them by security code – which, since these are numeric, you would not have to manually do. Any good CSV / spreadsheet system allows for auto-sorting for numeric content. And so then at the door, you check folks in based on security code and just scan by leading number, then glance at the name to ensure you’ve got the right number without having to check each digit-by-digit. And so on…

Again, your feedback is much appreciated and I’m sorry about the current inefficiencies of the plugin you are facing. I hope that my comments here have clarified why, perhaps, the decision of name format is not as simple as it might seem and all of the implications of a product design decision like this one.

Thank you very much for reading any of this, if you do 🙂

[Author]

Posts