April 12, 2016
Bob Youngblood brought it to my attention that at Kissimmee we found another operational issue with the SCORECARD software. It is not a software bug or error in the code. It relates to the possibility of inadvertent keypad entries while entering scores and comments.
What happened was – during entry of scores and comments, several times an inadvertent character (usually a period or a numeral) was entered into the comment field as the entry person would hit the enter key three times to move from the last “taste” score to the next box “presentation” score entry field. What was overlooked was a thumb resting on an adjacent key of the keypad or striking two keys simultaneously (. or 3 which are adjacent to the enter key). The results of this are comments on boxes with just a “.” or “3” in the comment field, even on boxes where there weren’t any actual comments. So when the comment sheets are printed, they would be inserted behind the cover sheets and the team would get a comment card with worthless feedback.
- When entering scores, pay close attention to how your hand rests on the keypad to avoid inadvertent key strikes other than “enter”
- Suggest entering all scores first and then going back to enter comments. This takes your hand away from the keypad to enter comments and may reduce the risk of inadvertent character entries.
- After printing the comment sheets, review each one for accuracy and discard any with extraneous characters if no valid comments would also be discarded. Edit the comments if necessary to clear out errors and reprint affected comment sheets if necessary.
April 11, 2016
This email is to advise you of an anomaly we had at Thomaston so you will be on the alert for it at your contests upcoming.
All went fine on Friday working with teams and judges in the software, despite difficult weather conditions which forced part of the rep team to relocate computer operations to the hotel. On Saturday we had two issues that arose worth discussing:
(1) Despite multiple checks and reviews by the REPS, one judge who we thought was in attendance actually was not. This resulted in the balancing and table assignment process ending up with a judge assigned who was actually not at the contest. When the judges’ cards were distributed the error was detected but time was too short to correct the issue before turn-ins began. The immediate solution was to assign one of the table captains double duty which addressed the missing judge. Two judges were instructed to ignore the name on the score card and write in their own names. It is not important whose name is on the score card when entering scores other than to verify they are in the system and you are loading the correct card associated with the card number, as long as you are aware of the judge name change. What matters is the number of the card which already exists in the SCORECARD system and all cards which have numbers need to be entered to have a complete contest.
Score entry went normally for the contest and all results were tabulated correctly, ending up with an accurate and complete set of score reports for each category and overall to support the awards and printed packets.
After the contest, we went back into the SCORECARD program to correct the judging error in order that the final judges list sent to the Secretary would reflect the correct assignments for judging and TC credit. However, this resulted in an unexpected result. Editing the judges after the contest is complete results in possible deletion of judge’s numbers on the score reports. It does not affect the scores but will show up on any reports generated after the contest (including online results printouts by teams from the website).
(a) Be absolutely sure you have an accurate account of the judges present before printing judge card labels and issuing cards
(b) Do not edit anything in the contest file on Scorecard AFTER the final results have been printed.
(2) When score entry began using the chicken score cards, after one judge’s card was entered, SCORECARD did not automatically populate the box numbers for the second card to be entered. At first we thought this may be a fleeting anomaly and we entered the box numbers manually for each card thereafter for the first table. When we began entering scores for the second table, SCORECARD auto-populated the box numbers from table 1 into the box fields instead of box numbers for table 2. This anomaly has never happened in the past 15 months of using SCORECARD on the Web.
After discussions with the software engineer, it was decided that this was likely caused by faulty data being transmitted for the first card which did not correctly set up the box numbers for table 1 in SCORECARD. Inspection of the data entered to that point indicated incomplete reception of the correct data expected by the software. Therefore, the logical solution was to reset the database with empty data and restart the score entry process. This corrected the problem and score entry resumed and proceeded normally for the remainder of the contest.
At Thomaston, the MIFI hotspots were located inside the REP tent in a depression (hole) in the terrain which is not conducive to good cellular connections. AT&T was yielding a single bar on my phone while the MIFI hotspot on Verizon was yielding only two bars of signal strength using Lorne’s hotspot, which was fully charged. I had borrowed Bob Youngblood’s MIFI to ensure we had a backup based on my experience at Thomaston last year. I positioned his MIFI in a different location on top of a roll of paper towels to get it above the table and other metal surfaces and was able to establish a link with three bars. So the second computer was connected to this hotspot for score entry to reduce the load on one hotspot which might create another transmission anomaly. We were able to complete score entry without any further problems.
(a) When setting up the MIFI for use at a contest, test multiple locations within 20-30 feet of the laptop to get the strongest possible signal before beginning computer operations.
(b) If you experience this anomaly where box numbers are not automatically populated after the first judge card is entered, take the following steps:
- Exit SCORECARD and then re-start the program and test to see if this reset the problem
- Check the MIFI signal strength to verify it is strong
- Switch to local WIFI (if available) for use as an alternative to the MIFI
- Contact me first to discuss the problem if not resolved using the above steps and we will contact Will if necessary to reset the contest database or effect any alternative corrections to re-enable normal operations.
We do not believe this is a software bug but is totally associated with unreliable wireless communications. We will be exploring a possible modification to the software to alert the REPS if this situation arises again early in the score entry process.
February 29, 2016
This email is to keep you informed of events related to the new scoring software and website in support of your FBA contest.
At Haines City we had a new and unusual problem occur with the software. One of the teams was omitted from the Brisket and Overall scores reports, after being included in the Chicken, Ribs and Pork scoring reports. This has never happened before since moving to the new scoring software.
As background, in the software, when team names are loaded they are stored in a unique data structure on the server. At this time there are no control numbers assigned to any teams. When the REP generates the Control Number report, a control number is assigned to each team and a new data structure is created into which scores will be loaded as the contest progresses. When all scores are entered, the reports are generated by the software by linking the data from the team names set with the control numbers set of data. In Haines City, one of the team’s names got erased from the name dataset, so the report module could not link it to a control number and therefore that team’s results were not printed on the score report.
The big question is “how did the team name get erased?”. Will Cleaver and I are exploring scenarios and code that could lead to such a result, but thus far have no solid answer as to how this happened. Normally the only way to delete a team name would be for the REP to go to the “Add Team” page and intentionally delete a team name. What makes this occurrence more unusual is that at the time when the team name disappeared (after finishing score entry for pork), a new team name was entered into the team list dataset – but with a blank name. This raised the number of teams from 42 to 43 in the report headings but did not print this new team since it had no name in the team name dataset.
If I thought the software were perfect, I would look towards human error or inadvertent key strikes. But this could only occur on the “Add Teams” page which is never touched again after the Control Numbers report is run.
What to look out for and actions to take in future contests:
- Check the contest results boxes list for each category against the control sheet and swap labels to verify which teams did NOT submit a box. This explains why their box was not scored and will alert you to any new teams added after the contest started.
- Check the report for each category to verify the number of teams reported against the number of boxes submitted
- If you detect a change in the team names list or number of teams after the contest has started, contact me (407-399-0327 / if I am not at the contest already looking over your shoulder) and we will work out the issues (including calling the SW engineer if needed) in real-time
In Haines City, REP computers were set up in two offices (one for PRO, one for Backyard). Many people had access to both offices when the REPS were not there (eg. Receiving / sorting the next meat entries). Both of these offices were unlocked at all times and the computers were usually left in a state where the Scorecard software was on the screen and running. Just to be completely thorough regarding this new problem, REP computers should not be left unattended if the software is up on the screen. If you have to leave the computer unattended, either log out of Scorecard so no one can make any changes to the contest, enable the screen save with a password or lock the room so no one has access to the computer.
The same REP crew that worked Haines City will be working Eagle Lake this weekend and will be on high alert for any indicators of this problem re-occurring. If we find anything that helps permanently resolve this problem I will advise everyone.
February 15, 2016
During the past few contests, the Scorecard software has experienced some unique problems that have caused some stress and extra measures by the REPS to recover and complete the scoring before awards. During Apopka, a new problem arose and during trouble-shooting Bob Youngblood asked me to send an email to all the REPS explaining these problems and how they can be avoided, corrected or mitigated.
So here goes.
(1) PROBLEM: While entering scores, entering comments longer than the field shown causes the card currently being entered to be abandoned. This happened at two events and was verified during Apopka by Wendy by repeating the long comments just to force the error. Until today the only solution was to re-enter the card but manually abbreviate the comments to stay within the displayed field length.
a. Solution: We modified the Scorecard software today to restrict the comments to 50 characters which is the length of the field visible while entering scores. If you try to type a longer comment, it will not accept the comment and truncate to only the first 50 characters of the comment.
b. Suggestion: During judges meeting we advise all judges that they must restrict their comments to less than 50 characters.
c. Mitigation: None
d. REPS actions: None
(2) PROBLEM: After entering all scores, when checking the printout for each category, a team score exceeds 200 points (which we all know is not possible in the FBA scoring model). This happened before Sonny’s and at Apopka in the pork category. Until today the only solution was to delete the scores for a particular team (box #) and re-enter them using all six cards from the table on which the box was judged (or the one entry that was identified as flawed). When individual scores were examined, one or more of the individual judges scores would have been “85.” or “95.” Which in the scoring system would be interpreted as an 85 or 95 score. We all know that scores can only be up to 10 and occur at .5 intervals between 5.0 and 10 (or 2.0 for DQ). When entering scores we do NOT enter the decimal place and the software automatically interprets an 85 as 8.5 and so on. Until today the Scorecard software would accept a 3-digit entry which enabled the “95.” entry to be accepted and interpreted as 95.
a. Solution: We modified the Scorecard software today to restrict score entries to 2 digits only. Since we do not enter the decimal character, 2 digits is adequate to support all scores from 2, 5 – 10 including .5 increments (shown as 55, 65, 75, 85, 95). Using only 2 digits speeds up the data entry process. If you inadvertently enter a 3-digit score (eg. 9.5, 95., 10., 5.0, etc…) the software will flag the error in RED and prevent you from submitting the score. Entry of a decimal after a single digit will still be accepted and be treated as a full point score (6. = 6; 9. = 9).
b. Mitigation: None
c. REPS actions: Do not enter “.” character in scores.
(3) PROBLEM: At Apopka a totally new error surfaced when we had a three-way tie in Brisket. The software was duplicating one team name in two positions in the top ten rankings. There was no error in the scoring calculations as all three teams had identical scores. The problem was caused by software code which did not account for more than two teams in a tie and the use of an apostrophe in one of the team names. When the apostrophe was removed from the team name in the SQL database, the computer screen display became correct. The hardcopy printout was always correct since the team names are drawn from the database in a different module when being formatted for printing.
a. Solution: We modified the Scorecard software today to handle the apostrophe uniquely to avoid confusing the display module logic when multiple teams end up with identical scores. The software now will handle any number of teams with identical scores and with any number of apostrophes.
b. Mitigation: None
c. REPS action: Continue to scrutinize results displays and printouts very carefully for any anomalies – especially where ties occur.
(4) PROBLEM: At a number of contests going back to early 2015 we have had a mysterious problem where scores get duplicated for one judge, ending up with the scoring only considering 5 of the 6 judges’ cards, omitting one of the judge cards. We have been trying to isolate when this occurs using a variety of internal logging and tracking methods but have not been able to precisely define when and why this is happening. The only evidence we have found that may be causing this duplication of a judges card is when the person entering scores inadvertently enters a score for presentation while the cursor on the screen is in the box number field. This causes the software to jump to an error routine flagging the box number in RED as invalid and forcing the entry person to edit the box number to correct the mistake. It is also possible that the entry person is inadvertently hitting the entry key twice (or incurring key-bounce) when submitting a judge card.
a. Solution: (possible) We modified the Scorecard software today to only accept 3-digit box numbers which will prevent the inadvertent entry of a 4 or 5 digit box number during entry of scores, thus preventing the routing of the logic into the error module we suspect was previously causing the duplicate scorecard. We are now checking to prevent a second “Submit” on the same card in quick succession. We may not have fully isolated this problem so REPS need to continue looking for this problem by checking the contest results report for errors caught by the software already (eg. “duplicate score”, “not judged by 6 judges”).
b. Mitigation: The software already flags entries that have not be properly judged by 6 judges on the Contest Results page.
c. REPS action: Continue to review the Contest Results page for the identified errors and take corrective action. This could include deleting duplicate score cards and entering the omitted cards scores or re-entering cards that got dropped when first entered.
On a general level, now that we are past the two critical contests (Sonny’s and Apopka) we are moving ahead with a list of corrections to the scorecard software on the “old” website which is where all contests are still being scored. Most of these are cosmetic issues (wrong # of teams shown, not handling all names correctly, cover sheets not sorted alphabetically, etc…). We will continue to run contests from the “old” website (www.floridabbqassociation.org) until more testing on the new site is completed. All of the problem fixes being applied to the old site are also being applied to the new site at the same time.
You may have noticed on the old site that many of the previous webpages are now gone. As they are being moved and updated on the new site, I am deleting them on the old site which will force everyone to move to the new website. Use of SCORECARD for contests will remain on the old site until we are completely confident the new site is stable enough to support contest scoring. Even then, we will keep the old site active for the REPS as a fallback option if we find problems running contests on the new site. On contest days, the scorecard databases from both sites are backed up every 15 minutes to prevent loss of data in the event of network failure, power outages, etc… Worst case scenario is having the REPS take the scorecards to another location where there is reliable power and Internet access to resume the scoring from the point of breakdown. The servers will have all scores entered up until the point of power or Internet loss.
I hope this information is helpful for all the REPS and for forthcoming contests. If you encounter any problems with the Scorecard software during a contest, your first call should be to me (407) 399-0327 (if I am not onsite in the REPS area). If the problem is not easily resolved, then I will contact Will Cleaver to work out a solution in real-time and document the problem for future correction in the software and testing.
If you have identified any other issues that are causing problems at contests, please send me a note or call me so I can categorize and prioritize it for correction in the software.
Thanks for being such dedicated individuals to the goal of running all contests with complete integrity and to make FBA the best contest sanctioning body in the country.