Web site logical path: [www.psy.gla.ac.uk] [~steve] [equator] [this page]

What technical means can we use to cement Equator itself?

Tom Rodden suggested we should reflect Equator on to itself, and research how to hold the project together using methods of the kind we are investigating. I certainly agree we need to work at holding the project together, as it is large and its distribution in space, institutions, skills, topics, and time (because people will arrive and leave the project), are all challenges that it is not easy to overcome; though I am not immediately optimistic about finding dazzling new methods. However we need to work at this, innovative or not, just to make the IRC work better.

Below are a handful of methods I've used a bit in the past, and that I suggest we adopt, subject to better suggestions from y'all. Key principles to focus on are:

1. Getting information updated is even more important than anything else. So avoid central record keeping that is then hard to keep accurate because the maintainer is not the person whose information it actually is. Distribute the maintainence job to the people most concerned (but then bully them to do it).
2. It is very important to maintain the date of the last update on each page. Pages go out of date, but with dates explicit, the reader is left with immediate knowledge of this. Inconsistencies can be understood (prefer the most recent of two contradictory versions), even if not immediately corrected.
3. If you do have a central table, put everything in a single table on a single web page, so that a web browser's Find command can search it in multiple ways. This is one of the few advantages of a web page over print. Examples of it are at: here and here. While a conventional list will be sorted by last name, and then only visually searchable by last name, this means you can, for example, search ("Find" command) by first name (often all you remember about a person), or by institution, ... Remember, it only matters looking pretty if it's designed to be serachred visually. These tables are designed to be searched by browser for the reason given (supporting access by multiple keys).

Applied to Equator:

1. Make sure everyone has their own web page (just say, if they are employed by Equator, they must create one immediately). And make sure it has ALL their contact details on: they are the ones who know this best and shouldn't expect or allow someone else to maintain these details.
   
2. A simple central Equator table (table 1) then only needs a list of people's names and their web page URLs.
   
3. Should table 1 list people's institutions? Minimising update problems says it shouldn't; and Tom is already an example of someone changing institution without changing their relationship to Equator. Furthermore from a research viewpoint, someone's institution is irrelevant. Of course if these pages are designed to support management rather than research, then the criteria will be different. On the other hand, one could imagine wanting to retrieve/browse the set of people at a site (e.g. I'm attending a workshop at Nottingham: who-all might I expect to see or look up?).
   
4. If we care, personal web pages can have various extra features. Mine for instance has a link to a page about where I am now, that is updated automatically from my login behaviour, so you can tell when I may last have read email, and if I seem to be around. Phil Gray used to maintain automatic updates of photos of his office and the people in it.
   
5. As for Equator doings, these are going to be the projects within Equator. A central list (table 2) of such projects that ONLY points to the list of projects, each such page being maintained by the project's manager. (E.g. the 3 projects agreed at the Glasgow meeting should immediately have a web page with a basic outline on, above all listing the people involved: that means Tom, Matthew, Adrian doing this ASAP.) These pages, if they are to support rapid browsing of who is involved, should only list: title, time span (this will get revised often), the leader, and the list of other people (links) involved, and a pointer to further information on separate pages.
   Redundantly with this, possibly central table 1 should list against each person the projects (URLs) they are associated with. It may go out of date, but anyone can check by going to the project's pages.
   
6. It would probably be best, though I don't know if we can get Equator people to sign up to this work, if every member maintained a simple extra page on what their relationship to Equator is. Partly this would be redundant again with the project pages, being the reverse pointers from person to projects. But it would be a great help to the rest of us to see at a glance what that person's set of interests / activities are. And the person themself must be the best person to maintain that. I guess I've convinced myself: so here's my personal draft of my page. I guess, where they exist, these personal Equator pages should be the URL listed in central table 1, so we can look people up and browse through people's self-described roles, commitments, opinions about Equator.

Summary of proposed web pages

1. Central table 1
   • Minimal version: list people's names plus URL to their personal equator page.
   • Maximal version: Person's name, link to contact details, link to a photo to help recognition when scanning table, their institution.
2. Central table 2: list projects plus URL to the project page.
3. Every equator person: personal equator page: link to contact details, and listing projects they are associated with.
4. Every equator person: personal web page: listing all their contact details.
5. Project pages: each maintained by project leader; lists people involved, name of project, link to pages explaining project.

Web site logical path: [www.psy.gla.ac.uk] [~steve] [equator] [this page]
[Top of this page]