On Sun, Aug 3, 2008 at 8:23 AM, David Boddie <[EMAIL PROTECTED]> wrote:
> On Sunday 03 August 2008, John Pinner wrote:
>
>> Is the key word here 'insane' ? Are all these things _really_
>> necessary? eg allowing whatever you want on the badge? Has it all just
>> got out of control? Could some management realism reduce the problem
>> to soemthing, well, manageable?
>
> When asked what people want from a conference system, there's usually a
> flood of requirements, many of which are really suggestions for things
> which are nice to have. Some of these reflect people's interests more
> than they do the needs of your average conference participant.
>
> Having said that, I think Doug's rant describes two main problems:
>
> 1. Scheduling
> 2. Registration
>
> My impression is that some people quite fancy the idea of tackling the first
> of these, then think that maybe they can address the second as well, and
> allow all sorts of interactions between them. In the end, you just end up
> with an ever-increasing set of requirements that obscures the original
> purpose of the system.
This is not what happened with PyCon US (thought it easily could have).
The existing registration system was just a simple python CGI which
used a VeriSign http POST type form generation. You fill out one form,
it generates a new form with hidden fields and the user hits 'submit'
on that form'. this worked well except there were problems.
the way it worked was there was a hidden 'description' text input
field in which you would encode all the registration options. This had
a limit of 256 characters. We allowed for 1-3 registrations per
transaction. No unicode, no '-' character, and a host of other issues.
When PayPal had an error, we would not know about it unless the
attendee tried to contact us. Otherwise the transaction would result
in an e-mail sent to a mailman list. a script would parse that text
and update two text files for managing registrations. We did know when
we went beyond 256 characters. During PyCon 2007 we had more than 12
registrations go over 256 characters, even though they were for only 1
person.
All problems were resolved by hand. When we changes the price (early
bird ended) we would edit the CGI. When a tutorial closed, we would
edit the CGI; often well after it was over booked because who had the
time to do a grep|wc -l on a text file all day. To give a custom price
for a person you would either copy the CGI and edit it and run the
persons card for them, or have the PSF treasurer do it and edit the
text files by hand (in a save manner to prevent an incoming
registration from occurring while you were editing). For at-door
registration, rename the CGI to something the public didn't know, and
have the reg desk use that. All problem resolution was managed by the
PSF treasurer. If a person had an extended ascii name, they had to go
through Kurt. Forget about having their name properly rendered on a
badge.
For 2008 we added a 3rd track of tutorials, and the option of woman's
t-shirts. We estimated that 20% of our 2007 attendees (~120) would hit
the 256 limit if they took an additional tutorial or selected the
woman's t-shirt option. Also Kurt was no longer going to have the time
to deal with resolutions in a timely manner, or take people cards, or
deal with mail-in registrations. We had no choice but to go for a new
registration system. The crux was that it still needed to use the
PayPal PayFlowLink interface (as the accounting was based on this
e-mail based transaction). HAving written registration systems in the
past (in PHP no less) I had no real desire to do it again.
The solution for the 256 issue was to instead send a UID in the unused
UID field and store the information in a database of some sort (text
file being one option). This meant we could create a simple yet
extensible system. We did not know how many people were affected by
PalPal errors as we never got notifications when it happened. This
time we did. It is not pretty.
There was very little feature creep over all. The only 'new' things I
let in were the 'any text' fields which people had been asking for for
years, a badge preview (which someone else wrote), the ability to edit
your registration after the fact as long as it didn't effect the
price, and to have a form to report a problem or request a change. In
the past they were told to e-mail PSF-Donations. All the form did was
e-mail PSF-Donations and store the info in the DB as well. Everything
else was just automating the 'copy/edit the cgi' steps, as that was
just stupid. The real issue is that we had all these pricing ranges
and options which have been supported in all past PyCons. Students are
charged $100 for the first tutorial and $80 for each additional, etc.
Multiple registrations. These are not unnecessary things. They just
make registration very very complicated.
Some people were very upset with me as there was a 'my way or the
highway' attitude I had about new features to registration. Things
like adding survey type questions, and social network integrations
were not done. There were multiple almost flame wars over my refusing
to implement features. (Interestingly enough no one stepped up to
implement them themselves.)
The vast majority of the features I ranted about really are
requirements that I saw no way around.
The registration and schedule systems were not tied together at all.
If you changed tutorial information, you needed to update the tutorial
listing in registration. We did have a 3rd app for finding out which
speakers were not registered yet, but that was independent of both
systems (as it should be). The sponsor management and registration are
completely independent. This caused some problems with sponsor free
registration counts, but I would argue that typing the systems would
just push the problems elsewhere.
> I think you have to start with something simple and keep it open enough
> to allow things to be added on.
I agree with this, but with multiple registrations, tutorials, and
multiple price ranges alone, you no longer have something 'simple'.
> One positive thing about splitting it all up into separate projects is
> that there people who are purely interested in one aspect of the whole
> system. I think you got a question in your talk at EuroPython about
> timetabling, for example, and I know that Zeth is determined to have a
> really simple registration system, despite Nicolas Chauvat's attempts
> to convince him otherwise. :-)
I really wish I could have gone to EuroPython :-(
-Doug
> David
> _______________________________________________
> Europython-improve mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/europython-improve
>
_______________________________________________
Europython-improve mailing list
[email protected]
http://mail.python.org/mailman/listinfo/europython-improve
