Using webform and UC: uc_webform_productize -- an analysis
I'm currently looking at http://drupal.org/project/uc_webform_productize with a view to how it could be used for event registration.
My current use case is:
- one site
- several events
- registration is paid
- events have options such as how many days you want to attend, diet requirements. these affect price.
- users will want to register several people for an event: eg, an organisation's admin will register all their members. So registrations can't be tied to users -- data about who is registered must be collected in a different way. Ideally, an email address should not be compulsory (since when did a tired office admin know everyone's email address? does everyone even have one?)
The module has quite a lot of glitches that need fixing (see what I've filed in the issue queue today)
However it is rather promising in that it allows:
- submitting data when purchasing, such as name, dietary requirements, that sort of thing (which frees us from requiring email addresses for each participant!)
- we get Ubercart attributes to do things like 'book only 1 day of this 2 day event', with price reduction etc
However I am now wondering about the wisdom of in effect having 2 sets of data to collect -- atttribute options and webform data. Does it make sense to collect data with two different systems? (and then store in two places?)
On the one hand we have some data that affects the product (days, extras), and some that doesn't (name, special diet possibly if this doesn't affect price).
Another consideration is that product data is something you might buy several of (eg 4 people coming on Saturday).
Whereas webform data is something that's unique per person: you buy 4 tickets, but you need to give 4 names.
On the data collection front, UC doesn't look that good: attribute data is serialized into uc_order_products which means getting, say, a list of "everyone who needs special lunch" or "everyone who is booked in for Saturday only" is going to be tricky.
Webform stores a big table of component data with the nid and what looks like the submission id, so getting that into Views would only require a join with a WHERE clause or two.
The real biggie is how to provide a smooth workflow for multiple submissions....
at the moment webform itself tells you "You have already submitted this form".
I'm not even sure what the best workflow is.
Something like this perhaps?
- select attribs and add product to cart
- add how many multiples you want
- get sent to webform
- webform makes you submit N times according to how many tickets in the cart.
But uc_webform_productize currently puts the webform on the node along with the cart stuff, so some work would be needed there.
That's all I've had time to look at so far.
Any thoughts? Ideas?
Is anyone else interested in taking this further?
Workflow
I don't have an opinion of webform_productize, but I do have an opinion on the right flow.
I think that different sorts of events need different flows.
For free events, you need to collect the maximum amount of information before issuing a ticket because people won't come back to fill in forms later. You also need to guard against multiple registrations because people will register themselves more than once: there's no pain to them. For free events, group bookings are not always a good idea, unless it's an event that's internal to an organisation.
For paid events the sooner you get the money, the better. Short forms are good. You can take details afterwards. Once someone has paid, they care more about filling in forms.
For pre-registered events, what you need is confirmation of attendance, which is similar to booking a ticket, but not entirely the same. For example, when you confirm your attendance at a meeting, you don't expect to be asked how many tickets you require. It's a very similar workflow, but needs a different entry point, so that the system understands what is appropriate.
Each event has a different set of required data. For instance, the name of the the participants are not always required for an internal event; you might just need to know the number of attendees. Different roles at the same event may need different data collection. For example, for speakers, you usually need a synopsis.
In general:
Take the email address of the person making the booking, and save immediately. This might be ajaxed.
You want this because forms are complicated and there's quite a drop-out rate. People start registering, get distracted and forget what they were doing. People think that they have finished applying, and haven't. You want to be able to mail people who have started the process, but not completed it, to say 'Hey, we noticed that you started but didn't complete. Follow this link to carry on.' This doesn't have to be implemented from the beginning, but if you don't make space for it, it becomes impossible because of architecture.
If the person has an account, show and take their password. Populate later forms with info you already hold.
One person may make more than one booking for a paid event. If the person has a booking you may need to check whether they mean to alter the booking or need to create a second booking.
You want to be able to save each step of the multistep-form. You need to save intermediate representations to be able to send follow up mails. The saved steps are not necessarily This can be implemented later.
Ask for any discount and access codes. If there are no discount codes or its a free event, then this can be skipped. If an event has no tickets requiring an access code, then this can be skipped.
Go into a loop of adding tickets. More below on what this entails.
Take the details of the person making the booking.
Show the details with the option to make alterations
Take the money or confirm the booking for a free event.
Confirm via email, issuing tickets if required. Include URLs to allow the booking administrator, and individual attendees to alter the information.
Collect the additional info.
This may be an ongoing process. For instance, if it's a group booking, then the person making the booking often won't know the details of the people he or she is booking for, and may need reminding via email more than once that the booking isn't complete. You will usually want to allow some alterations. For group bookings both the booking administrator and the attendee should be able to alter/add details. For some events, it's only possible to issue tickets once this additional info is know.
Adding tickets
An event can have a single ticket type, or multiple ticket types. Each ticket type can have a price. Ticket types may have optional extras which may carry cost. Each ticket type is related to a role. Some ticket types may not be visible to everyone - they need an access code to become available. For instance invited guests often have free tickets, but may need to register.
To add a ticket you need to display the list of ticket types, and ask for the number needed for each type.
Then for each tickets with optional extras, you need to collect the optional extra.
Collect information about the attendee at this point. Some data collection can also be left till later. There's a balance between making the form big and collecting information up front. The ideal is that the system administrator is able to indicate which info is required to complete a booking, so that these fields are included in this step. Any other fields can be collected in step 8.
Altering a booking
For paid events, there's a state sequence for payment - not-yet-paid, payment-being-processed, paid. Sometimes it's useful to let people make bookings, but only pay later. In this case the system may need rules for how long the booking is valid for when there are a limited number of places.
Some aspects of a booking may be alterable, depending on business rules. For example, a plane ticket normally isn't transferrable, but a conference ticket can be assigned to any attendee. There may also be business rules about when a booking is alterable. For instance, once a conference badge has been issued, for a paying event, it's not a good idea to let the booking administrator change the name of the attendee. It allows for an easy way to add attendees without paying.
Changing setup
It's not unusual for events to change during the registration time. This means that data requirements change. System administrators need a way to clone and alter ticket types. There's a problem with dealing with ticket type changes. For example when an event already has some people who have registered, it's usually no problem to change a ticket type to require another optional field. It's not a problem to change an existing field to fix some spelling error. However it's rarely a good idea to delete a ticket type unless there are no registrants with that ticket type. It may or may not be a good idea to add further required fields. The system needs to be able to cope with changes without errors.
Storing the data
Depending on who is running the event, the data should be secured in different ways. Commercial organisations rarely want to let attendees make their contact details available without some checks because it makes it far to easy for their competitors to gather up a useful mailing list. So ticket data should sometimes not be stored in the user profile. On the other hand - if the organisation runs events frequently, and the same people attend repeatedly, then it's useful for them to be able to avoid filling out their details in full each time.
Attendance data is also transient. Once an event is over, the purpose for which data was collected no longer justifies keeping the data, so it should be deleted. In the EU anyway.
Ideally, the system administrator needs to be able to map ticket fields into the profile, and needs to be able to specify profile privacy rules.
Wait lists
When an event has a limited number of places, wait lists are useful. Many events have cancellations.
Refunds
People cancel, are unable to attend and need money back for numerous reasons. Ticket types should carry conditions, including refund policies for paid tickets. The ecommerce system may need to be able to deal with refunds. It's often a good idea to be able to display the conditions & require agreement prior to sale.
Reports
In this ticket-type orientated system, there's a problem with Views. Because each field is assigned to a ticket type, and not necessarily in the profile, it becomes very difficult to make reports which aggregate data from each ticket type. Just making a list of all attendees can be difficult and may require custom code. It might be possible to provide Views add-ons which compensate for this.
Sorry: I started to write down notes on registration flow and ended up with an essay on requirements.
You might look at
You might look at http://drupal.org/project/uc_node_checkout which has already had a lot of this kind of work put into it. This is used for things like event registrations where you need to create a node of data from the registrant as a part of the checkout process. It has privacy settings and you can use it to register anonymous users and lots of additional edge cases. You create a content type for the checkouts and add whatever fields you want to it and store and retrieve them in the normal way, except that the node is linked to the order. With that you can create views of the results, etc.
It doesn't use webform, you create a regular content type and fields, but you can create any number of different content types with different fields for different purposes.
The problem with
The problem with uc_node_checkout it's very much geared to a one-shot system.
Otherwise, you're creating a fresh content type per event, because events have different data collection requirements. You're also have to give the event manager the permission to administer content types so they can make the form.
And there's something that just seems wrong about saving this as nodes -- this is user data, not content.
Webform is also saving data
Webform is also saving data as nodes, that's what we do in Drupal. We have a node that contains information about users. :)
Yes, you have to create a different content type for each distinct collection of data that you need. If you have totally different needs for every event webform would make that easier. I would say that in many cases multiple events put on by the same organization will have the same data collection requirements. We put on a series of seminars, we usually need the same info for each one. I work with other organizations that put on multiple events over the course of the year and they need pretty much the same info for each. So it's not a 'one shot system', it's a system for organizations that don't create lots of different 'one-shot events'.
I just wanted to point out that it is an alternative and that lots of the data collection/storage/privacy issues you raised are already addressed there. And it is still an early-stage solution that could be made more robust if anyone wants to take that on.
Webforms are nodes, but the
Webforms are nodes, but the data you enter into a webform and submit doesn't become a node -- it goes into a table webform_submissions.
With uc_node_checkout you have content types -> nodes
with webform, nodes -> webform_submissions data.
I'll take another look at it, but I am wary of the case of an organization that does a new conference twice a year, and may end up with fairly different data to collect for things like how many days people attend, and so on.
Imagine something like Drupal UK using this system to register at their camps. Each camp is going to be a different city, different hosting, different number of days -- could have subtly different data collection requirements each time.
Users, nodes, events data: Users
Moved to http://groups.drupal.org/node/25018#comment-86445 and expanded.
Users, nodes, events: Events
In my view:
An event can have one or more types of registration. Different types may have different data collection requirements. Different types have common data collection requirements.
I don't think this information is content, so it's not node data. And that makes it difficult for me to advocate storing this data in CCK types. Webform is attractive for this reason. On the other hand, CCK has great widgets, brilliant integration with Views, and everyone uses it.
And for many events, this information is confidential, and should never be displayed to anyone who doesn't have some administrative access over the info. Control over appearing in search results is crucial.
CCK is tactically a better fit. But strategically it's worse. [What we need is meta CCK: the understanding that we have different data collections, to which different rules apply, so that User info is just as CCK as nodes but we recognize that it doesn't follow node rules.]
Fields in D7 will be pretty
Fields in D7 will be pretty much what we need, as they can be put on anything.
But that's D7... :/