onsdag 25 januari 2006 10.16 skrev Michael Hudson: > Aroldo Souza-Leite <[EMAIL PROTECTED]> writes: > > Hi list, > > > > a Python software solution for the Europython conference would be cool. > > If there is someone (Joachim Schmitz) prepared to configure it using the > > experience of the last conferences, it seems to me that this little bit > > of Python sectarianism won't keep us from concentrating on the > > conference content. > > FWIW, CERN's indico conference software is written in Python too (and > is open source, gpl I believe). I also failed in my attempt to > install it, though...
When making the choice of registration software, there are some rather important points to consider. 1. The software has to work on the day we start taking registrations. This may sound self evident, but we have had problems in the past. Using something that has been tested saves a lot of grief. 2. The software needs to do a good job in supporting all the actors using the system. This means that speakers and attendees should have an easy time registering. The track chairs should be able to view and handle all the talks in their tracks. The schedulers needs to have support for scheduling. The registration administrators must have access to many different views and a powerful search interface. Last year I was able to place a payment by searching for all attendees from the UK who had ordered a T-shirt and for whom a payment was not yet registered. There were many other such incidents where the search interface saved many hours of work. 3. Producing quality outputs is essential. There are 3 major products and some minor ones needed. a) Invoices. You must be able to produce invoices in accordance with legal requirements. The smallest amount of work for the organisers is generated if attendees can print their own invoices. Don't expect everyone to manage to print an invoice at registration. You need an interface so they can come back and make a separate printout. They need fields for entering an organisation number and other reference information on the invoice. You must put the attendee information in a place that is not part of the address fields, or some organisations will complain. You must have complete payment information on invoices. b) Badges. A lot of work went into making name tags that are actually readable and that contain useful information. I decided to go for name, organisation, email address and country (plus attendee category) as useful information to put on the badge. Email address was made in a smaller and harder to read print, because I wanted that bit of information to be a bit harder to access. If the badge holder wants to give it out, he/she can point to the badge. All the major fields require scaling, as some individuals have very long names or organisation names, while most people have reasonably short ones. Adjusting everyone for the longest names means that everyone gets badges that are impossible to read. c) Programme Making a printable programme with all necessary content is not a trivial exercise. So far we have been relying on the software of Reportlab for this task. It has the nice feature of allowing each attendee to print a customised programme. d) Statistics You should be able to generate statistics lengthwise and crosswise. How many staff, track chairs, speakers, students, early birds, on-sites, no-shows, people from different countries etc. e) Talk materials You need places to store these and make them available to attendees and to the general public. Moving to a solution that doesn't support these things would be a regression, as would having a registration procedure that does not build on the lessons we have learned in previous years of Europython. Getting it right was actually hard work. This said, I'll be just as happy not doing registration with the CAPS system, as it would require a bit of work from me. However, I think that the CAPS system encapsulates the lessons we have learned in a way that the other proposals are unlikely to do. For the website with information about the conference, what we had the last 2 years was hopelessly over-engineered. There is need for some fairly advanced templating, which allows for the display of banner ads, unified dropdown menus and such, but the content management behind has really been in the way of collaborative work on the website. The ideal solution from my horizon would be a very small directory tree with a simple include mechanism and files written in either xhtml or Rest. The webserver would handle the includes, the Rest translations and finally fill in the dynamic content before serving up a webpage. Doing Plone or CPS for handling a site of about 25 web pages is as impractical as shooting mosquitos with an anti-aircraft gun. Jacob Hallén _______________________________________________ EuroPython mailing list [email protected] http://mail.python.org/mailman/listinfo/europython
