Ever since I started directing tournaments I’ve wondered why all pairing software is still software designed to run locally and not on a server. There are so many reasons why pairing software in the cloud would be better than the desktop versions we are now using. Imagine the integration and convenience of cloud based pairing software.
Players could use a single web page application interface to create a user login ID and register and pay for events- declaring byes as needed and withdrawing themselves as needed. Of course, the TD account would have the ability to register anyone without internet access but a majority of players these days would register and pay from their phone and show up to their board in time for round one without ever so much as sending you an email.
When the TD approves the pairings for the next round all players could instantly see their board number and color allocation without killing a single tree.
Prize distribution and cross tables could be emailed as a cron job after an event to all user emails who played in a tournament - perhaps prizes could even be paid in paypal or bitcoin instantaneously if users connected their paypal account or bitcoin wallet address to their user ID with a token - obviously that’s a pretty 21st century idea and it’s only 2016 but still- I can’t help but think everytime I fireup Swisssys, Vega, WinTD- sheesh- the possibilities we’re missing out on. Any programmer who built this and got their pairing program certified by the USCF and FIDE (I know not an easy process) would instantly become the global standard.
This is increasingly the case as the Chromebook will become the laptop of the next generation. The only people who will be working on machines with huge hard drives and sophisticated operating systems like windows, osx, linux will be hardcore developers. The rest of us (not writing code) will just use chromebooks for all of our needs.
I’m curious to hear anyone’s thoughts on this matter- or maybe there’s some glaring reason this doesn’t yet exist that I’m missing.
It is generally unwise to assume internet availability at tournament sites. Perhaps we will get to that happy state of affairs some day, but we are not there now.
On top of that, mobile hotspots are also iffy as the building where the tournament is being run can have a weak-no signal. Hence, why I am against wireless printing at tournaments as well just use the cable?
There have been occasional cases of a TD accidentally withdrawing the wrong player, but players unused to the programs would never either accidentally or intentionally withdraw the wrong player, would they?
A number of tournaments post their pairings, standings and cross-tables on the web each round (often using multiple computers networked together). Not everybody walks around with web-capable devices so the paper still needs to be printed, so trees would still get used (admittedly, web posting does cut down on the crowd at the wall).
It’s also faster since you don’t have to wait for pages to reload, slow internet, etc. I can see the local software interacting with a server back-end to more quickly show pairings, receive entrants, etc. But, I think overall it’s more efficient to use locally and certainly more reliable.
What do you do when your Cloud server hiccups or gets hacked? You may not be that concerned by overall security, but the hacking of allegedly secure servers has increased. Would you really accept entry payments in “bitcoin”?
This is a good point- I personally have never been at a tournament that didn’t have wifi but it’s a good point nonetheless i’m sure there are large parts of the country off line that I don’t visit so indeed your point is valid.
However, I’m not saying that we should build this application and then it should be the only thing anyone is allowed to use- some TD’s will still do pairings by hand with cards- some will use desktop applications even when alternatives are available. I’m just pointing out that it seems really odd to me that this hasn’t already been designed and marketed - good or bad- it’s weird to me it hasn’t been tried.
This comment seems disingenuous and almost mean spirited so I’m reluctant to reply to it but in case someone else doesn’t understand the structure of an MVC framework I would like to give a couple examples.
When you create a user login for an application like gmail, facebook, or bankofamerica or citibank or chase bank if you use online banking- obviously you don’t have access to every other persons account or information and can’t “monkey” with their files or their money. The controller serves the user a “view” that is specific to that user and the user only has permissions as defined by the controller. So - if i login in as myself with my uscf ID - enter an event- pay my EF- declare byes- I would only be doing so for myself.
At the moment- if a player uses a pen and writes “out” in ink next to their name on a pairing sheet and then simply doesn’t show up to the next round as often happens- it’s up to the TDs to withdraw the player. It seems like if a player could login in and withdraw themselves OR just use a pen to write “out” next to their name- some players may choose the application.
In terms of a server crashing/getting hacked- do servers crash? yes- do servers get hacked? yes. But servers are also backed up (if a server crashes the money in my online account doesn’t disappear - ). And what kind of hack are you afraid of specifically? SQL injection that would dump all of the data into a spreadsheet for a hacker? USCF ID’s, ratings, and names are all public info freely available online so I’m not sure it would be worth the effort even if the application were stored on a vulnerable server somewhere. Obviously, the payment wouldn’t be on the server if it came from paypal it would be on paypals servers and we would simply integrate their application into ours. And finally- this could also be a tip toe process where the desktop application works together with the cloud so everything is backed up locally and you work on it locally and then push it to the server when you post pairings- like google drive- both a desktop application and a server storage solution.
Even if you think it’s not a good idea for all the reasons mentioned- - I honestly just find it really hard to believe that some kid in California hasn’t built this already. Don’t you?
It does seem like a cloud-based solution to pairing is an obvious next step to try. As Mr. Keener says, whether it will a successful one is almost beside the point - no reason why chess software has to be stuck in the 20th century.
Most already do that. They have web pages to take applications and payment and to generate player lists. Then they import the results to the pairing software.
What you call “killing a tree” I call “carbon sequestration.”
And the larger events do post to the web. The application would, of course, need to allow the TD to review the pairings before “instantly” posting them as they are made.
Crosstables are also generally posted online in larger tournaments. If players are getting pairings from the website, they will also get the crosstable from the website.
If players want that, it can be done. I do believe that for larger prizes, the organizer needs to submit income information to the IRS – including the Social Security numbers.
It is amusing how we are trending back to the mainframe, isn’t it?
I am a developer myself. The joke with these web applications is “write once, debug everywhere.” They have to be written for all manner of browsers, which is no mean feat sometimes. (And WinTD, at least, works fine under WINE.)
Frankly, I see little reason to run a web program when a program can run locally. As others have pointed out, you run the risk of hacking and of network instability.
Finally, the nice middle ground already exists. Use Swiss Manager, which is FIDE certified, and publish pairings and results to chess-results.com/.
The original poster is actually making two suggestions: One is putting the pairing software on the cloud, the other (more significant IMO) is integrating all aspects of running a tournament – online tournament promotion, registration, payment, membership verification, pairing, reporting, prize distribution – into a single software package. Wouldn’t THAT be cool? But would enough of us organizers be able/willing to pay for an app that does it all?
Right now there’s a lot of file import/export/conversion between apps to make it all happen. That both slows things down and increases the chance of errors.
There are essentially two issues with Mr. Keener’s (well intentioned and reasonable) idea.
First, wireless Internet is not available everywhere. I’ve run a number of large tournaments and not had wi-fi. That’s one of the things some organizers fail to investigate, IMO, when scouting sites, precisely because it’s simply assumed that it exists, and is sufficiently robust (or protected from general use) to accommodate bandwidth needs of an event.
Second, there’s just not much demand for a SaaS-type pairing program. There is essentially a three-part litmus test for whether it’s worth developing a shared service.
Does the desktop version take up excess disk space?
Does the desktop version compromise machine performance?
Is there some way to reduce the startup cost, and introduce a maintenance fee?
For both WinTD and SwissSys, the answer comes back with a solid “no” on the first two counts, and a very likely “no” on the last count (as the software doesn’t sell enough copies AFAIK to make that change economically feasible, and earlier versions can run fine without updating anyway).
Moreover, if one really wanted to run a pairing program remotely, that’s not hard, as one can fairly easily set up a machine with Remote Access, install the pairing program of choice on that machine, and then patch into it from anywhere.
Finally, a word of caution about Swiss Manager. I love the one-button Web publishing capacity of the program, and I highly recommend it for running FIDE events. However, it is completely useless for running US Chess events, as it cannot generate the DBF files needed for submitting rating reports in TD/A.
I have in mind a list of six specific people who I’d love to lock in a room together and not let them out until they’d developed wireframes and requirements for such a program. I’m not so sure they’d go for the idea, though.
Of course, Ms. Thorpe’s final question is the largest stumbling block of all, as developing and testing such an application is going to be a bit more involved than a weekend GUI project.
They’d more likely build it out of existing software modules, no? Other than the chess pairing thing (and maybe the membership verification thing), these are all generic processes used by a variety of businesses.
If we keep dropping hints, maybe it will happen. Maybe it’s already happening and we don’t even know it.
Actually, it’s a bit more involved than that. Just one example: the software would have to be able to handle both US Chess and FIDE requirements. This would directly impact registration (FIDE ID, FIDE flag status and US Chess membership status would have to be validated), pairings, prize calcs, and rating report generation.
(That’s just off the top of my head…in just that one area. Back when I had spare time, I had started trying to sketch out what a real cradle-to-grave program might look like and need. To summarize what I found: “Yikes.”)
Pieces of it are happening (or, in some cases, has already happened). But to make it all work together is rather tricky. This brings us back to locking key people in a room.
just use the cable?
Maybe it’s already happening and we don’t even know it.
Just one example: the software would have to be able to handle both US Chess and FIDE requirements. This would directly impact registration (FIDE ID, FIDE flag status and US Chess membership status would have to be validated), pairings, prize calcs, and rating report generation.