And they will probably continue to do so, until the quick system is “fixed” to be more in line with regular ratings. And that’s a good thing – for now. I’m just thinking ahead a few years.
I’m just hoping to get discussions going, perhaps in time for the August 2012 delegates meetings.
Bill Smythe
I like it on the right for this form.
[quote=“EricHammond”]
In the color-coded swiss crosstable (the presentation of which is an improvement over the current form), I would like for the green that you are using to indicate “color coding inconsistent” to instead be used to indicate a complete result that has no issues identified. The blank form starts white and as players and results are entered it would become green – a visual contrast that indicates what has been entered. The way it is now with a portion of each unpopulated cell in yellow functions fine, and I would keep that part regardless.
Response: Too much green might be jarring, but this change has been made. Let’s see what others think. It might make it harder to find the ones that need to be checked on rather than easier.
A lighter or more faded shade of green would address the above, but…
In some ways we’re already running out of sufficiently different shades. There are also TDs with various forms of color blindness and they may not be able to see or discriminate between all the shades being used. That’s why when there is a text field with a yellow background (to denote an error that needs to be corrected) it is also uses a thicker border to make it visible to someone who cannot see yellow.
…this changes my opinion. I failed to consider color blindness. “No color = no alert” is the better design. Thanks for considering the change!
Response 2: For the time being, the light green (actually ‘yellowgreen’) shading for ‘no problems’ is still in, at least until we see if others react to it.
However, this did lead to another change, in part to recognize the color blindness situation.
When incompatible results are entered (eg both players are coded as winning and it is NOT coded as inconsistent results for ratings purposes), that now sets the flag for the yellow results box and heavier outlining, since that IS an error condition that needs to be corrected.
Whether there are ways to unobtrusively code the other situations that the color coding is used for (bye, color mismatch, forfeits, etc) is worth exploring further. The latest version adds a small subscript letter to denote those alerts, though forfeits are shown in a larger font because that is consistent with how they are usually notated on the crosstable/pairing results sheet at a tournament.
Greatest. It sounds as though you are now in the “about as good as it can get” category.
I’m weirdly curious about the rest. Misspellings, maybe?
Would your parser convert ‘G/’ to ‘SD/’ or vice versa, when necessary? For example, would “40/90 G/30; d5” become “40/90 SD/30; d5”? Conversely, would “SD/60; d5” become “G/60; d5”?
Bill Smythe
Yes, it can handle “SD/30 d0” as well as “40/90 G/30 d0”.
All told there are 1086 different entries that currently parse, with a total of 110,862 occurrences.
There are 827 different entries that do not currently parse, with a total of 2426 occurrences,
so quite a few of them are one-ofs.
At a guess, around half of those are time controls that vary by round. (The new form can handle that with multiple entries, one for each round, and also has provisions for handling multiple schedule events, one entry per round for each schedule.)
Some are hard to figure out, such as one that have both game/ and SD/ in them.
There are also 1535 instances of something like “Game/XX” which is what the office used to put in for mailed-in events when no time control information was provided. In the future, the office will probably need to contact the TD to find out the actual time control used. (Those were excluded from earlier counts because they cannot be parsed.)
With further refinements to the parser code, we could probably pick up another 300-400 of the stragglers, but is worth the effort?
Can you take all those that don’t parse currently and return a message such as “Does not Parse, Here are examples that do work.” followed with, well examples that do work?
Response: Have you looked at the program?
The test version of this module will only be available for testing and comments through Sunday, October 16th. Open beta testing for live events should begin around October 24th.