22 Jan 2001 ............... Length about 1,000 words (7,000 bytes).
This is a WWW document maintained by Steve Draper, installed at http://www.psy.gla.ac.uk/~steve/equator/reflect.html.
You may copy it. How to refer to it.
Web site logical path:
What technical means can we use to cement Equator itself?
Stephen W. Draper
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
- 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).
- 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
- 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
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:
- 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.
- A simple central Equator table (table 1) then only needs a list of people's
names and their web page URLs.
- 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?).
- 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.
- 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.
- 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
Summary of proposed web pages
- 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.
- Central table 2: list projects plus URL to the project page.
- Every equator person: personal equator page: link to contact details, and
listing projects they are associated with.
- Every equator person: personal web page: listing all
their contact details.
- Project pages: each maintained by project leader; lists people involved,
name of project, link to pages explaining project.
Web site logical path:
[Top of this page]