5 Further requirements
In this section, we list some further requirements, which are not so much
functional specification, but rather general requirements or also
5.1 Adaptability, parameterization, and options and defaults
Since the intention is that the tool is not usable for just one conference,
but for many, certain things must be adaptable per conference. We call one
conference an instance of a conference. Each instance of a
conference is characterized by number of basic data, which must be provided
in the configuration phase. At later phases, additional information
(papers, reviewers etc.) are provided.
All in all, the whole thing is required to offer quite an amount of things
the users can adapt. Part of these adaptability is described and
discussed here and is part of the standard scenario of reviewing. There are
much more things imaginable, for instance: besides the program chair,
someone wishes to have a financial chair and a local organizer listed on
the web-page, someone things the background color of the generated
web-pages should be green, and weirder things ...).
To make the tool useful in practice, a good balance between hard-coded
decisions and adaptable variations will be crucial. A couple of things
should be kept in mind here:
A useful technique in this context is also the choice of good
defaults. There are always users, who want to fiddle with everything and
they should be given freedom to a certain extent. There are also others,
who don't bother, provided the default setting are usable.
Therefore, making good defaults enhance and keep the number of necessary
variation points beyond that small, enhances the usability quite a lot.
- don't get carried away! The fact that one can easily
include another battery of check-buttons to adapt this and than and other
does not mean the user will like this.
- Empty options/switching off features
- take care that options or
features can also be switched off. If the user don't want a requistration
phase in the, he may completely switch it off, for instance. This is
related also to the point ``modesty''.
5.2 Webserver & download version
The software should be usable also as some web server managing more than
one conference. The alternative is, that one user (in the role of the
admin) downloads the source code, install it, adapts it for his or her
needs and uses it for organization. The consequence of the ``webserver''
requirement is simple: more than one conference must be held in the data
base at the same time, without any information flow (other than the
information concerning the general public and other than by the
administrator) between the two conferences.8
5.3 Changeability, non-standard scenarios
A general remark which applies to almost everything described above.
namely: we concentrated on the smooth, standard evolution of the event.
In general, the tool must be prepared that this is not the case, which
basically means, that choices once made must be changeable.
Basically, all data in the data base must be ``manually'' adapted if need
be, the problem is that is must not unnecessarily interfere with the
process. Possible non-default scenarios are:
last generated October 26, 2004 (ŠPublic License)
a reviewer does not review, and is removed.
- an additional review about a paper is delivered, or a paper is re-assigned.
- the chair (or the committee) decides that one particular paper is
rejected/accepted despite the fact that perhaps the numerical valuation
or the status of the discussion would indicate otherwise. The valuation
of the rest of the papers must not be ``confused'' by that.