View Full Version : web pairing application user interface

31-07-2009, 11:30 AM
I'm thinking about the interface that a pairing program presents to the arbiter using it.

Before the first round, how does the arbiter input the information about entrants and other things like the number of rounds?

After pairing the players, how does the program tell the arbiter what the pairings are? What format does the arbiter expect them in? And should it show standings in the tournament? Or is this something the arbiter should already be expected to know? How much information does it provide about how the pairings were produced? Does it show a log of which individual FIDE rules determined the pairing, for example?

Finally, how does the arbiter enter the information the program requires to pair the next round? This involves, at a minimum, keying in the results of the matches, or clicking one of 6 possible alternative results, Win:Loss, Loss:Win, Draw:Draw, Win:Forfeit, Forfeit:Win, Forfeit:Forfeit presented to the arbiter by the progam. But it could also include late entries and withdrawals.

The special context that I am thinking of is a non-commercial web application freely available over the Internet. The server could store information about whole tournaments in the form of crosstables which it updates on input about the match results from the user, accessing the program from a web browser. This represents a burden for the server, although it does ensure the integrity of the data.

Another alternative is to store no information about tournaments on the server and expect arbiters to input pairing tables, or their equivalent, for each new round. This minimizes the immediate burden on the server, but increases the burden on the arbiter and, at the same time, the risk of bad data, which may result in more work for the server down the line. (Actually, perhaps parsing the pairing table is more of a significant burden than accessing databases for the same data?).

I think the second alternative is cleaner. It leaves the data in the hands of the arbiter, rather than in those of the server. The burden on the arbiter can be lightened by outputting a form containing a provisional pairing table for the next round, which the arbiter updates by adding to the scores of winners and drawers, moving players into their new brackets in order of their pairing numbers, deleting withdrawals and adding late entries at the bottom.

This is still something that it will be easy for the arbiter to get wrong in the rush before a round starts. Late entries and withdrawals are the main concern at the last minute, aren't they?

Untypically for a web application. rather than interaction with the web server being steady and rhythmical, access will be marked by long periods (days? weeks?) of inactivity. It will be easy for arbiters to lose all their data about the tournament by closing their web browsers.

How can the interface avoid being a mental burden for the arbiter at the same time as the least work is required of the server? Pointing and clicking rather than use of the keyboard I guess is one point that needs to be kept in mind.