Registration Data

The first thing we want to know is what do we want to ask people. There are some obvious items here, but new ones always crop up. Think of every possible situation you could want to know, and then ask someone else the same question and see what elese they come up with!

The way these questions are asked is also very important. We also note that not everyone who will be reading this will understand English (you could easilly put in support for multiple languages...).

Presenting the user with the form will be a four stage process:

When showing the form, we have two three possibilities:

Simple Questions

Some of the easier parts of this are:

Email Address

Email address is a relatively simple case to deal with; we want to mandate that everyone who registers must have an email address, and this address must meet some standard validation conditions. For example, a regular expression test can be set up to ensure that there is at least one character before the first '@' symbol, and two-level domain name ('blah.com') after it. Anything that doesn't match this minimal constraint is not valid for Internet SMTP systems, so we can reject it. We could send a message to this address, asking the user to visit a special URL (eg, 'www.linux.conf.au/register/iamreal.cgi?id=01231232') to ensure that this registration entry does have a valid email address, but this will slow down some users, and will annoy some people. The choice is yours, as this is easy to implement.

Name

Some people have different ideas about their name. Some people have aliases. Some people have only one name (eg, Madonna). Some people put their surname (family name) first. Do we want to mandate a first and last name? Not really, as we only want the name they go by so we can put it on their name badge as they would; we chose to leave this as one field that people would enter in freely (up to some size, eg, 100 characters?).

Postal Address

A physical mailing address, or a residential address? For our purposes, we didn't want to go and meet/stay with people, but wanted to be able to post them a CD of the proceedings (eg, pictures, electronic copies of the presentations). Looking at a postal address, we can work in reverse and see the simple bits can be their own questions, which aids in validation:

Validating this data is not simple, so we can leave this as freeform, with just length validation (eg, greater than 2 characters, shorter than 100?). This leaves just a street address, which again has to be freeform, since it may be a Post Office Box, a house, a flat and street number, or just a name (eg, "Bag End").

Registration Types

For our event, we had three different registration types: student/concession, hobbyist, and professional, each of which were charged at different rates. We had this as a list, and displayed it as a drop-down selection when permitting the user to chose.

T-Shirt size

We hacked this in, but it should have been much cleaner as a table in the database.

Special Requirements

This is vital. Some people are vegitarian. Some people are alergic to various substances. If you are going to feed people, you need to know this. You may also want to ask people what their alergies/medical conditions are. We had one situation where an attendee was unable to talk and had to be admitted to hospital for a few hours; what data do you need here on someone you don't know (next of kin? religion? health care cover? travel insurance? blood type?).

We also used the special requirements field as our back door for our freebies: speakers, organisers, sponsors, and services-in-kind. We had everyone in our database, which made it easy to know our capacities for venues. We issued people with special codes and instructions on how to use them, and these codes provided a percentage discount (eg, 100%), but these codes were only valid a certain number of times, typically once.

Registration Code Index

James Bromberger (james_AT_rcpt.to)
hosted by Pelican Manufacturing.