From WWW2006

(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

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.

Lifecycle

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.

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.

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.

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

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.

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.

Stats

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

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
Total	92668	197860	1597385	5500203	54.44 GB

<tbody> </tbody>

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
Average	2565.16	32104.60	94479.96	1.21 GB
Total	64129	802615	2361999	30.21 GB

Things for next year

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.

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.

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

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.

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.

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.

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.

Programme Data

Classess

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

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.

Day

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

DaySlot

A single slot in a day

Location

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

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

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.

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.