[EuroPython] Website specification

Jacob Hallén jacob at strakt.com
Wed Oct 20 22:17:19 CEST 2004


Here are some requirement for the Europython 2005 website.

Fast
====
Normal time to load a mostly static page should not exceed 3 seconds.
Normal time to load a dynamic page should not exceed 6 seconds.

Easy to navigate
================
An easy to navigate website of the size Europython needs has the
following properties:

- There is a fixed navigation bar, that is the same on all
pages. Preferably, it should show all the available options at the
same time, though one may have to use some sort of expanding type of
solution if the alternatives are too many. If an expanding type
solution is used, the ones that reveal the options on mouse-over have
better affordances than the ones that require a click to expand.

- All pages concerning the current conference should be reachable from
the navigation bar. These should be grouped according to subject and
clearly labelled. The EPC2003 navigation bar was for the most parts
good.  With a little more work and effort in labelling, it could be
excellent.

- There should only be one single link to materials not concerning the
current conference on the navigation bar. This should lead to a
different environment where you can study information like old
conference materials and info about the Europython Society.

- The front page of the site should contain a logo/picture, a
welcome/introduction message, sponsor ads and a section of latest news
(and the navigation bar).

- A search box for searching the site is nice, but not essential.

Structure
=========
Main page
Registration issues
  Registration information
  Registration
Location
  About the conference venue
  General information about Göteborg and Sweden
  Getting to Göteborg
  Getting around the Göteborg area
Accomodation
  Europython special accomodation
  Where to stay
Tracks and talks
  Propose a talk
  Track overview
  Schedule day 1
  Schedule day 2
  Schedule day 3
  Print your own programme
Events
  Keynotes
  Pub
  Conference dinner
  Breakfast and lunches
Sprints
  Sprint times and locations
  Proposed sprints
Attendee wiki
Other information

Sponsors
========
- It looks as if the link at the bottom of each page generates quite a
bit of money. We should keep it.

- Apart from the front page, all sponsors should be viewable on a
sponsors page, preferably with a short text together with the logo.
If possible, the sponsors on the front page should be a little more
prominent. This year they were totally scrolled off the screen.

- A nice feature would be to show a random sponsor logo on each page
except the first one.

Contents
========
- For the most part, the contents of the site were very good. We should
endeavour to re-use as much as we can.

- We need more maps.  People complained. Maps were made for the printed
programme. They should be on the website as well.

Website evolution
=================
A conference website is very much a living thing. It goes through some
quite distictive phases. Some information stays until later phases, while
some goes away when the phase is over.

1. Heads up about when and where the conference takes place.
2. Display of track information and handling talk proposals.
3. Displaying talk information, displaying local information
and handling registration.
4. Displaying scheduling and handling interest registration.
5. Providing talk materials and last minute information. Providing
attendee communication.
6. Providing after-conference information.

From the start, there should be placeholders for the pages that belong
to later phases, but they should be inactive until filled with
information.

There should be a plan for each page in the structure. When does it
get filled in and activated? Does it get modified or deactivated at a
later point in time?

Content management
==================
While having content management - being able to edit things through
the web and having some system for controlling the publishing - is
nice, it is not really necessary for the management of 30 odd webpages.

For registration, it is more an issue of data entry than management of
web content. A suitable tool for this is not really a CMS.

This leaves the tracks and talks information, where several people
need to be able to enter and update data. Simple extraction and
insertion of data is also essential, for automated scheduling using
external tools. While a traditional CMS will do a good job, so will a
tailored tool.


More information about the EuroPython mailing list