Maybe in the distant future, say by 2012, the USCF could develop an online pairing program? Hey, we can dream can’t we? Naturally this has already been considered, but google didn’t turn up anything in the first few pages… Just putting it out there.
What would be the advantages of that? The biggest disadvantage I can see is that if the site loses net connectivity, you also lose the ability to pair.
Welcome to Google’s technical model, Mike.
As for the main point: in my experience there are two cases worth considering:
a) a small event, run by a novice director.
b) a big event, run by an experienced director.
(well, OK, there is another case - but I prefer not to think about such things)
In case b) there is little benefit to an online pairing program UNLESS that program
had real-time access to the USCF Member Database. To an experienced director, who owns a computer capable of using an on-line service, the marginal cost of a pairing program that runs on his own computer is minimal.
In case a) it seems better to have the novice director pair manually.
Interestingly enough - I was once in the position of having a pairing program that could only be used remotely. This was in the early 1990’s - when I carried a laptop, but used it primarily as a way to access my lab machines; the pairing program was experimental and only ran on the lab machines. I don’t think I ever found myself in a situation where I could have directed an event using that program - because I rarely had network access from the playing site.
The bottom line is: if you have a computer capable of accessing the network, you probably prefer to run your pairing program on that computer.
As I glance over to my iPhone…I begin to waver…but then I remember the most important part of an on-site pairing computer - the PRINTER. Take away the printer, and the pairing program becomes almost useless. On the other hand, if you give me a stack of 3x5 index cards AND a computer with a text editor and a printer - I’m good to go. [and, if the text editor is EMACS - I might be able to write the pairing program as a macro…]
If you can’t pair a small event by hand, you have no business pairing ANY event using a computer.
If you direct large events - there’s really no reason NOT to have a pairing program and a portable computer/printer to run it on.
So…we’re back to: what is the point of an online program?
Well, what’s the point of an on-line word processor? Talk to Google - they seem to think it’s a good idea. I’m not convinced.
Isn’t there a law about the utility of an application being inversely proportional to how long it takes for someone to implement it in emacs?
I still think it would be interesting to try to do pairings using a goal programming model, but I’m about 28 years out of date on the state of the art in goal programming.
What got me thinking about this was a post from a Supernationals thread asking if the pairings would be posted online…
You mean, you lose the ability to pair online. OTOH, if some spectator spills a giant coffee on the TDs laptop (ROTFL at South Station in Boston), recovery would be much easier. Anyway, as time goes on, we might as well realize that network connectivity is becoming a non-issue. That’s no reason to force every application to use the network, but that wasn’t my idea anyway. Even in 2009, the only way someone can keep me offline is by killing my computer or by killing the power. Either way, it doesn’t much matter where the pairing program runs, I better get out the pencil and paper.
(1) The TD has another choice.
(2) OS agnostic.
(3) Pairing implementation is consistent with USCF guidelines.
(4) Multiple TDs can manipulate the same data realtime.
Need I go on?
Disadvantages
(1) TD requires net connection, as mentioned.
(2) USCF needs a new server.
(3) Latency means slower pairings.
I do not agree with most of Sloan’s remarks. An online pairing program doesn’t have to be a browser plug-in. A traditional two-tier client/server application would do the job, could even be open source developed.
Non sequitur.
‘Consistent with USCF guidelines’ is not that easy to define precisely, because there are multiple conflicting guidelines.
Allow me to raise the stakes in the “non-constructive comment” department:
A USCF pairing program would be consistent with USCF guidelines by definition.
Yes. For example - why do you believe that an online pairing program will adhere any more closely to USCF guidelines than a pairing program running on your laptop?
Are you sure that point (4) is an advantage?
Excuse me - where did I say that the online pairing program would be a browser plug-in?
Why is “open source” important?
Why is “USCF-supplied” necessarily tied to “online” - USCF could provide a laptop program that met all guidelines - or someone else could provide an on-line program. The two ideas are completely orthogonal.
Some of us have already spent many years in the environment where applications ran on central servers and were accessed by remote user machines. There’s nothing really new there. The question is whether it’s a BETTER solution.
I’m not convinced that it is.
Because the TD can’t use an outdated pairing algorithm from an old software version.
i Multiple TDs can manipulate the same data realtime.[/i]
Yes, I am sure, with the clarification that they are manipulating the same section (i.e. table) but not the same pairing (i.e. record).
That’s what I thought you meant by this:
Just a suggestion. I would hate to see the USCF outsource the project and end up having someone else own it. Not that the USCF has ever done anything like that in the past. Open source would be an affordable way to develop something like this. And would be consistent with the USCF mission statement, I believe.
Not quite orthogonal, sir: No outside developer is going to code a client/server product on their own initiative, because they wouldn’t want to run the server. (Also, please note that I wouldn’t have bothered to suggest the USCF develop a standalone software, since the currently available products already do a good job.)
Oops, sorry, didn’t realize that was the question. Thanks for setting me straight.
Unless you are saying that even an obvious mistake in the program would be “consistent with USCF guidelines by definition,” this doesn’t make a lot of sense. If you are selling that – I’m not buying.
Not realistic, unless you’re talking about a 5-10 year timeline. Most large tournaments take place in hotels, and hotel policies on wireless access vary widely. Some have the access in the common areas, but the function rooms are insulated. Some don’t have access outside the guest rooms. And before you mention EVDO, some are in places with no cell phone signal. (A plus in my view, but that’s another story.)
This sounds like a very dubious method to me, but perhaps other TDs have tried it and can comment. (Both SwissSys and WinTD can be networked, though I don’t know offhand of anyone who does it.) I wouldn’t want several people manipulating the data for a section I was directing, and if something got screwed up it would be very difficult to assign blame. The only circumstance under which I can see this being useful would be entering results for a very large (300+) section with limited time. Are there any examples of this?
Congrats. You picked up on my intended irony.
But why did you completely pass over Nolan’s unintended irony?
I didn’t see the humor. Seemed like an obvious statement of fact to me.
You have a valid concern, but I can assure you that locking schemes are a well-known domain in database applications, as are audit trails. What you would want is a choice of locks: by section or by pairing. And a choice of auditing: track all edits or track only major events or track nothing. Those who don’t trust others not to get it “screwed up” can lock everybody else out of their section, whereas those who don’t mind accepting help can accept it without too many worries.
I don’t want to minimize though. I said well-known, not trivial. If I were coding this, I would do the simple case first – one TD per section and no auditing. Release and fix. Then put in the auditing. Release and fix. Lastly allow multiple TDs per section.
Sigh. Irony, not humor. In any case, I’ll spell it out.
One of my points in favor of the USCF creating an online pairing program was this:
i Pairing implementation is consistent with USCF guidelines.[/i]
So when Nolan pointed out that this was difficult to achieve, I considered that “non-constructive”, for the following reason:
My point wasn’t that the USCF would be better at achieving this implementation than others have been (although I see no particular reason why we should be worse), but that changes in USCF guidelines could be reflected in the online application and then quite transparently all pairings by all TDs would use the new implementation. Consistently. See my post to Sloan where I made the same point.
So right above the obvious statement of fact I put the non-standard disclaimer:
Allow me to raise the stakes in the “non-constructive comment” department:
In theory, that’s a fair point. In practice, it’s kind of thin. Pairing rules change with glacial slowness, as they should. The rules committee made a lot of changes in the years between the 4th and 5th editions (far too many in my opinion), but how many of them affected pairing procedures? Very, very few.
My real problem with a USCF-provided pairing program (on-line or otherwise) is a bit more abstract. Such a service would compete with the commercially available programs and tend to drive them out of the market. It would also establish a de facto standard for what such a program should include – perhaps a minimum standard, but floors easily become ceilings. I have more faith in individuals competing in the marketplace than in employees doing a job by the hour.
Not sure what would be different for you in 5-10 years. Hotels stop trying to gouge their customers for wireless access? Doubt that. They finish installing cellular repeaters in the basements? Not likely.
To me it is simple. No network? Better not use an online pairing program. I wouldn’t want to force anyone onto the network anyway.
The current standalone pairing programs work. Hey, old-fashioned pairing cards work. An online pairing program would certainly work – in some ways better, in some ways worse. Should the USCF involve itself in creating one? If it would be a net benefit for chess, then it clearly falls in the scope of the mission statement. Then it is a question of allocation of resources.
Fair enough. I’m reluctant to use software that’s not under my direct control and fully backed up, but that’s a matter of taste. Google is betting the other way.
What’s likely to change in five or ten years is a) greater customer demand for wireless access (some of the stodgier hotels still haven’t grasped this, but they will eventually), and b) next-generation wide-area broadband, which should get a boost when they finally turn off the analog TV signals.
Well, if I were looking to drive out the commercially available programs, then I would have listed advantages like these: no uploading of files at the end of the tournament; and, especially, mid-tournament rating updates (!). But really, I don’t see a problem here. Driving out competitors by providing superior service is too bad for them but very good for the USCF members and TDs.
The true danger is in driving out competitors by anti-competitive practices. Examples would be (a) offering a break in fees for using the online service, and (b) changing and hiding the APIs to break the competing software. I think many (most) in the USCF would be on your side in not wanting to do anything like that.
The de facto standard notion has me puzzled. Are you saying that once the USCF creates such a service that it would never be improved? In that case then the door opens again for the competitors, at least on the client side.
Products made by hourly employees also participate in the marketplace. If they are too expensive for the quality, then they do not win.