Running a Conference Website
(If you have something relavant to suggest/add please do, but sign it so I know who you are.)
I (Christopher Gutteridge) am going to try and capture as much as I can of my experiences of running the conference website. This will be useful to next years organisers. Hopefully it can also be turned into a general guide for running a conference website.
I'm the web projects manager for ECS at Southampton, the school organising the conference. I have been to a few conferences before. I've never been to WWW before. I've never been around people running a conference before. I expect that that may be typical of many people running the website for a conference.
My motto for the website is "it may not be excellent, but it mustn't suck". I know people who've been in previous years and they always bitch about the website. Other requirements were that it should reflect best practice in standards (XHTML, CSS, accessability) to a 'best effort' level.
We ran a development website and a live website so changes could be checked and approved before going live. The script which made a page live validated the XHTML first so that (in theory) invalid pages could not be made live.
The site was edited using text editors.
A php library was used to generate the template for the site. It basically just had renderHeader($title) and renderFooter() methods.
We decided that, where possible, the programme data would be stored in a single place and that one source used to generate the pages. The data for the programme was provided in a variety of machine readable formats - tab seperated, CSV (from excel), and so forth. Rather than normalise this in the datafiles, I took the files supplied and built a php library which parsed them all and turned them into a (huge) php data structure which could be queried by the various parts of the site.
Early on we decided to keep things simple by making all the slots 90 minutes long, and to dedicate each room to a track. Of course, things were not that simple. The anomalies to the rules included: Some workshops in session 2 ran for 3 hours (taking up the morning break, session 2 and an hour of the lunch break). Some tutorials ran for either all day, or sessions 2,3,4. Some shuffling meant that a few talks were not in the track that their room was "dedicated to". A few sessions were jointly in two tracks.
Rendering the programme as XHTML wasn't too hard due to the fact that the sessions were not too complicated in terms of when they started and ended. We didn't make the time slots in the table a set proportianal height. Each vertical column represented a single room, not a track. Although obviously these were mostly the same. It was hard to render all the information without depemending on colour (which is bad for colour blind people, screen readers etc.). Showing the talks which were in two tracks at once was a pain. We had to place a hack to make the pentland session 1 sessions span the entire width.
The person who produced the paper programme told me they heavily modified the data from the website to produce the programme. This was clearly a mistake in our process - they should have been correcting the site, and then exporting only when the data was correct. The way we did it means that mistakes on the website did not get corrected.
Initally the website has different goals to those it will have later. These are to look like a conference worth sponsoring and to act as a general advert for the conference, and to tell people how to get in contact with the conference organisers.
At this stage the site is almost completely just an advert.
One registration opens then it was considered very important to keep the website up and functioning. At 700 per ticket, even a single person registering or not makes a difference. As it was the website was offline for a while during our peak time (we had a HUGE fire). I'm not sure how much this really affected registrations, the conference got over our target number but not quite our max capacity. The actual registration occured on the website of in-any-event - the conference company. To brand their form we placed it in a frame. This also allowed us to provide a back-to-homepage link and, more usefully, allowed us to watch the hits on the page.
Call for papers
I wasn't too involved in this - Les set up the pages so I'll get him to comment when he's less busy.
The provisional programme consisted of a number of datasets. These were created in a variety of formats - the most common being csv exported from excel.
I didn't get to talk to the creators of the data before hand. I should have done as some of the fields have data+comment.
eg. the field usually contains a controlled vocab. but now and then a comment has been added. If these comments had been a seperate field my life would have been easier and the person managing the data would not have had any problem with this. By the time the data is created, its too late to clean it (well, no, but it's expensive to).
Week before the conference
This is when the programme is going to recieve the most attention. Up until this point it's more of a guide, now it becomes a vital planning tool.
Also it's the point you need to make sure information you want attendees to know is online. You can't assume people will read updates to the site at the conference - some will, some won't.
eg. I set up a contest to use the conference RDF to do interesting things, but nobody has. I think if we'd put it on the site the week before then we might have got more interest.
At the conference
At the conference it can be hard to find people, people are in and out of network access and they want to attend talks. The people with authority are likely to be busy so both responsibility and authority should be delegated before the conference and everyone should know who has the responsibility and auth. (including the person who has it!)
After the conference
After the conference there is still some need to work on the site. It needs to be mothballed but kept online. Slides etc. should be linked in. The next conference should be linked.
Also, the current webmaster should update this document and pass it on!
The ball was dropped a little here - I spent all day Saturday travelling so didn't have a chance to look at my email until Sunday when I was exhausted. We should have prepared IN ADVANCE what the site would change to at the end of the conference. Also it does not yet show who won what for various papers and posters awards.
We also still have not sorted out all the slides :( which really should have been put online ASAP.
Our upload page has recieved 25 so far, but some are tests and duplicates.
I think I may make a script to just link to them directly as I don't have time and resources to sort through them.
We made the php header/footer methods detect a custom agent (WWW2006CDROM) and then used wget to capture the site, but with the template for the cdrom instead.
|Month||Unique visitors||Number of visits||Pages||Hits||Bandwidth|
|Jan 2005||63||109||2982||10264||22.84 MB|
|Feb 2005||150||200||1350||4180||46.02 MB|
|Mar 2005||216||271||1184||3128||29.83 MB|
|Apr 2005||308||372||946||2129||14.01 MB|
|May 2005||1637||2481||15295||39361||431.30 MB|
|Jun 2005||3412||8903||36743||82646||906.85 MB|
|Jul 2005||5099||11991||58759||142510||1.53 GB|
|Aug 2005||5487||12179||61670||151164||1.68 GB|
|Sep 2005||6380||13508||83182||207127||2.16 GB|
|Oct 2005||8136||18311||131255||322465||3.47 GB|
|Nov 2005||10716||22267||150722||409612||2.97 GB|
|Dec 2005||9620||19872||96170||308206||6.42 GB|
|Jan 2006||13396||26499||152684||527124||3.86 GB|
|Feb 2006||12973||26556||153603||638760||4.21 GB|
|Mar 2006||17826||41556||246750||965869||6.37 GB|
|Apr 2006||18820||39120||241733||1006451||9.78 GB|
|May 2006||29653||64129||802615||2361999||30.21 GB|
|Day||Number of visits||Pages||Hits||Bandwidth|
|01 May 2006||1344||9316||32571||393.45 MB|
|02 May 2006||1858||13386||66007||672.99 MB|
|03 May 2006||2194||15473||54734||599.78 MB|
|04 May 2006||2398||46097||87949||558.27 MB|
|05 May 2006||2442||22064||81848||673.45 MB|
|06 May 2006||1698||12869||37068||283.84 MB|
|07 May 2006||1693||11948||31844||434.47 MB|
|08 May 2006||2513||19743||73672||740.25 MB|
|09 May 2006||2599||24902||70852||701.20 MB|
|10 May 2006||2554||26477||74142||1003.86 MB|
|11 May 2006||2423||19326||60128||622.30 MB|
|12 May 2006||2457||19238||63843||475.75 MB|
|13 May 2006||1701||12615||33041||374.75 MB|
|14 May 2006||1682||12766||34914||368.94 MB|
|15 May 2006||2971||28342||94809||930.21 MB|
|16 May 2006||2655||69166||122750||2.42 GB|
|17 May 2006||2456||24328||90011||905.85 MB|
|18 May 2006||2288||30038||86890||791.08 MB|
|19 May 2006||2292||22086||79050||720.85 MB|
|20 May 2006||1608||12330||46864||527.43 MB|
|21 May 2006||1666||50981||92524||766.45 MB|
|22 May 2006||4988||41784||237755||2.59 GB|
|23 May 2006||5416||109039||303169||4.65 GB|
|24 May 2006||5467||108782||289357||5.55 GB|
|25 May 2006||2766||39519||116207||2.75 GB|
|26 May 2006||0||0||0||0|
|27 May 2006||0||0||0||0|
|28 May 2006||0||0||0||0|
|29 May 2006||0||0||0||0|
|30 May 2006||0||0||0||0|
|31 May 2006||0||0||0||0|
Things for next year
I think it would make sense to use TRAC or bugzilla (or whatever) to keep track of changes to the conference website/programme. Some people complained that their change had slipped between the cracks. This would allow us to make sure corrections were approved, assigned and dealt with. This sounds like overkill, but often (a) the person who approves the change is different to the one who will make it and (b) the change may need to be made in more than one place.
Not really a website thing, but people don't read the stuff in the programme. More big signs saying where they should be and what facilities were available. Many people didn't seem to be aware of the free printing service.
List of committee members
While this was available from the site, there wasn't a single who-to-contact page with all the various relevant peoples contact info (committee, web master, marketing, volunteering etc) .
Everybody is looking at the web all day at the conference. We should be an examplar of cool stuff. The thing is it takes a real commitment to get good content appearing in a timely fashion.
It seems like quite a nice idea to have a person at a desk who has access to the conference website. They could
- accept slides (and other files) from speakers and make them live at once
- accept photos off delegates and put them on the site
- make other updates to the site - eg. the programme. The catch is that they must know who can and can't authorise changes.
This year the conference centre provided a speaker support desk which accepted powerpoints for the larger rooms, but also helped the presenters tweak their powerpoints if they had problems. This is apparently a very dull job so maybe it should be manned by different people on different days.
I would describe the wiki as a limited success. Other than that we provided a webforums sesrvice with one forum per paper. That has had a total of zero posts to date.
I think it might have made more sense to just use the wiki, with one node per session. That way the presenters could add links to related resources and additional questions could be asked and answered offline in a public way.
Ideas for this document
Pass it on to next years webmaster and make sure it keeps getting updated.
Contact webmasters of other recent conferences and see if they've got any useful additions and perspectives.
The programme data consisted of the following classes (in theory), I guess I should get OWL out...
A time slot. We had am1,am2,pm1,pm2 these have a start time and an end time. Evening may also be a slot, and maybe the breaks and lunch should have been.
A day of the conference (mon 22nd May etc.)
A single slot in a day
A location. Mostly conference rooms but not all. Some locations has a default "track".
keynote => 'Keynote', invitedSpeakers => 'Invited Speakers', refereedPapers => 'Refereed Papers', workshops => 'Workshops', tutorials => 'Tutorials', w3c => 'W3C Track', panels => 'Panels', developer => 'Developer Track', satellite => 'Satellite Meetings',
These also had a colour (in fact a high and low version of the colour).
An atomic session which people will plan to go to all of. eg. a tutorial, the morning plenary etc.
The session has a location, and one or more dayslots. It also has a start and end time and these may be different to the start/end times of it's slots (ie. it may over/under run).
This is NOT how we represented the data but I wish we had. We stored it as belonging to a single dayslot and a flag indicated if it ran in all slots from there to the end of the day, and one if it overran into the break. There was no easy mapping from a session to all the dayslots it spanned. I think that it makes sense for a session to have an 'override' start/end time, but if not in inherrits from the dayslot times. Also if a session runs before and after lunch, it should be made clear if it runs through lunch or breaks for lunch (or other breaks).
Sessions had 0-n speakers and 0-n papers assocatied with them.
We had a flag to indicate that a session should NOT be shown on the website yet (or at all). I can't remember why - I'll ask Les.
sessions had a title.
sessions have a short description and a long description. The short description was not used much. We had XHTML in the descriptions, I think that was a mistake, but it was handy in some ways.
Sessions had a chair (should probably be 0-n)
The class of speakers and chairs should not be "PERSON" it should be "PERSON_WITH_AFFILIATION" (or ROLE) because the same person can be giving to talks/posters/papers BUT with different hats on, or they may have written a paper at one university but then moved. People and roles should be assigned unique ids as early in the process as possible, not added as an after thought like we did.
A role is either a link to a person, a name, and maybe: an email address, an affiliation
eg. "Google Inc."
I'm not 100% sure that's needed but it might be.
Note that email + affiliation and even the way the name looks belongs to the role, not the person. The person has email,name, affiliation of ALL their roles.