Running a Conference Website - WWW2006

Running a Conference Website

From WWW2006

Jump to: navigation, search

(If you have something relavant to suggest/add please do, but sign it so I know who you are.)

Contents

  • 1 Introduction
  • 2 Lifecycle
    • 2.1 Early on
    • 2.2 Registration
    • 2.3 Call for papers
    • 2.4 Provisional Programme
    • 2.5 Week before the conference
    • 2.6 At the conference
    • 2.7 After the conference
  • 3 CDROM
  • 4 Stats
  • 5 Things for next year
    • 5.1 Bug Tracker
    • 5.2 Signs
    • 5.3 List of committee members
    • 5.4 Mobile Internet
    • 5.5 Webdesk
    • 5.6 User Interaction
  • 6 Ideas for this document
  • 7 Programme Data
    • 7.1 Classess
      • 7.1.1 Slot
      • 7.1.2 Day
      • 7.1.3 DaySlot
      • 7.1.4 Location
      • 7.1.5 Track
      • 7.1.6 Session
      • 7.1.7 ROLE
[edit]

Introduction

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.

[edit]

Lifecycle

[edit]

Early on

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.

[edit]

Registration

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.

[edit]

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.

[edit]

Provisional Programme

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).

[edit]

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.

[edit]

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!)

[edit]

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.

[edit]

CDROM

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.

One mistake we made was we left the google javascript in the header. A cdrom should be tested on an OFFLINE machine to make sure that no links are really online.

[edit]

Stats

We put a google javascript stub which collected hit stats on the site too, but for now here's the awstats:



MonthUnique visitorsNumber of visitsPagesHitsBandwidth
Jan 20056310929821026422.84 MB
Feb 20051502001350418046.02 MB
Mar 20052162711184312829.83 MB
Apr 2005308372946212914.01 MB
May 2005163724811529539361431.30 MB
Jun 2005341289033674382646906.85 MB
Jul 2005509911991587591425101.53 GB
Aug 2005548712179616701511641.68 GB
Sep 2005638013508831822071272.16 GB
Oct 20058136183111312553224653.47 GB
Nov 200510716222671507224096122.97 GB
Dec 2005962019872961703082066.42 GB
Jan 200613396264991526845271243.86 GB
Feb 200612973265561536036387604.21 GB
Mar 200617826415562467509658696.37 GB
Apr 2006188203912024173310064519.78 GB
May 20062965364129802615236199930.21 GB
Total926681978601597385550020354.44 GB
<tbody> </tbody>
DayNumber of visitsPagesHitsBandwidth
01 May 20061344931632571393.45 MB
02 May 200618581338666007672.99 MB
03 May 200621941547354734599.78 MB
04 May 200623984609787949558.27 MB
05 May 200624422206481848673.45 MB
06 May 200616981286937068283.84 MB
07 May 200616931194831844434.47 MB
08 May 200625131974373672740.25 MB
09 May 200625992490270852701.20 MB
10 May 2006255426477741421003.86 MB
11 May 200624231932660128622.30 MB
12 May 200624571923863843475.75 MB
13 May 200617011261533041374.75 MB
14 May 200616821276634914368.94 MB
15 May 200629712834294809930.21 MB
16 May 20062655691661227502.42 GB
17 May 200624562432890011905.85 MB
18 May 200622883003886890791.08 MB
19 May 200622922208679050720.85 MB
20 May 200616081233046864527.43 MB
21 May 200616665098192524766.45 MB
22 May 20064988417842377552.59 GB
23 May 200654161090393031694.65 GB
24 May 200654671087822893575.55 GB
25 May 20062766395191162072.75 GB
26 May 20060000
27 May 20060000
28 May 20060000
29 May 20060000
30 May 20060000
31 May 20060000
Average2565.1632104.6094479.961.21 GB
Total64129802615236199930.21 GB
[edit]

Things for next year

[edit]

Bug Tracker

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.

[edit]

Signs

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.

[edit]

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) .

[edit]

Mobile Internet

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.

[edit]

Webdesk

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.

[edit]

User Interaction

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.

[edit]

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.

[edit]

Programme Data

[edit]

Classess

The programme data consisted of the following classes (in theory), I guess I should get OWL out...

[edit]

Slot

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.

[edit]

Day

A day of the conference (mon 22nd May etc.)

[edit]

DaySlot

A single slot in a day

[edit]

Location

A location. Mostly conference rooms but not all. Some locations has a default "track".

[edit]

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).

[edit]

Session

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.

[edit]

ROLE

A role is either a link to a person, a name, and maybe: an email address, an affiliation

or

an organistation

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.

Retrieved from "http://www2006.org/wiki/w/Running_a_Conference_Website"
Views
  • Article
  • Discussion
  • Edit
  • History
Personal tools
  • Log in / create account
Navigation
  • Main Page
  • I will be there!
  • Evening activities
  • Traveling
  • BOF Session planning
  • Recent changes
  • Random page
  • Help
Toolbox
  • What links here
  • Related changes
  • Special pages
  • Printable version