The Future Of Judging

I'm going to be trying to make a mock up of some sort, but if anyone more qualified (which isn't that hard) wants to make one, you'd be better and probably faster than I.

I'd be happy to volunteer to help out with a project like that but I'm tied up with work in the short term and unsure when things will clear up enough that I'd be able to commit time and focus to it. Feel free to check back with me in the future if there's still a need, time for side projects will come back around at some point.

Lots of tech savvy people around, though, and my instincts say a basic HTML/Javascript implementation would not be difficult and would work in practically any environment. Native apps seem sexier to everyone but they generally bring the weight of platform dependency along with them. Maintaining parallel forks/branches has never been a fun game. I'll also parrot @Lucas Garron on simplifying as much as possible.
 
Lots of tech savvy people around, though, and my instincts say a basic HTML/Javascript implementation would not be difficult and would work in practically any environment. Native apps seem sexier to everyone but they generally bring the weight of platform dependency along with them. Maintaining parallel forks/branches has never been a fun game.
There are always options like Cordova which can turn an HTML/Javascript app into native apps for several platforms. They can have slight performance issues but for a simple data entry app it should work great.
 
Obviously integrating with cubecomps would be amazing... but my idea is just to have a separate local database at the competition which can then be manually entered into cubecomps by the data entry person. Just like reading from a scoresheet, only there is no need to wait for them to come in anymore and data entry can be done so much faster. It also still means that a staff member checks every time manually before it's submitted.
 
I'm going to be trying to make a mock up of some sort, but if anyone more qualified (which isn't that hard) wants to make one, you'd be better and probably faster than I.

Already started. ;)

I'd like to see how a few people would go about it though, so don't let it discourage you. IDK if I'd be able to implement everything honestly, but we'll see how it goes.
 
Obviously integrating with cubecomps would be amazing... but my idea is just to have a separate local database at the competition which can then be manually entered into cubecomps by the data entry person. Just like reading from a scoresheet, only there is no need to wait for them to come in anymore and data entry can be done so much faster. It also still means that a staff member checks every time manually before it's submitted.

Oh okay... Maybe it goes live, but it has to be confirmed by someone. That way you do have truly live results.
 
An app that simply "reads" a completed scorecard (with the name, ID and times), interprets the times and pushes the data into Cubecomps via an API would be good.

The app would simply be:
  • An inspection time stopwatch (like Billy's original suggestion)
  • Could contain a link to the WCA regulations.
  • A data validation tool - it could contain Cubecomps style functionality that detects records and checks with the user.
  • A button to send a notification to a nearby delegate if there is a contention (like Billy's original suggestion) after they sign in to a competition with the app (applications here for registration too)

The main obstacle is messy handwriting. But I think handwritten digit recognition is probably pretty well-developed by now with machine learning etc. There is probably a free tool out there like TensorFlow that can be used too.

(Developers, go!)
 
Last edited:
An app that simply "reads" a completed scorecard (with the name, ID and times), interprets the times and pushes the data into Cubecomps via an API would be good.

Why does it need an inspection timer? An app for reading scorecards seems a seperate idea / tool, and you would only need one device with that app per comp.
 
The main obstacle is messy handwriting. But I think handwritten digit recognition is probably pretty well-developed by now with machine learning etc. There is probably a free tool out there like TensorFlow that can be used too.

or we can just print scorecards with digit stencils and force judges to enter times properely

300px-Russian_postal_codes.svg.png
 
1. Competitor sits at station.
2. Face recognition software identifies them.
3. Competitor drops cube into scrambling bay, cover automatically slides over, and machine applies the correct scramble, after checking that the cube is solved and legal.
4. Competitor says "I'm ready" and speech recognition software causes cover to slide back.
5. 8 and 12 second warnings given automatically until timer started.
6. After the solve, cameras detect DNF or +2 scenarios and also verify that the cube is solved and was the same cube initially scrambled, by signature recognition of sticker chips or plastic texture.
7. Results are live on cubecomps within 0.01 seconds.
8. That's enough of that, time for a cup of tea...
 
Why does it need an inspection timer? An app for reading scorecards seems a seperate idea / tool, and you would only need one device with that app per comp.

Doesn't need one. But since we're discussing modernization of comps then an all-purpose 'WCA app' could include something to time inspection, automate and validate data entry, handle comp registration (by logging in with your WCA online account) or alert users of records in real time.

Doesn't hurt to dream.
 
There are always options like Cordova which can turn an HTML/Javascript app into native apps for several platforms. They can have slight performance issues but for a simple data entry app it should work great.

Yeah, that's why I qualified it with "generally". The important thing to weigh is what you would gain by making it an app. If you need access to device hardware then there may be no other option. I've spent too many years in legacy code-bases so everything added to a project simply means technical debt to me. For a quick little trip through how my mind works on this: every line of code and every dependency multiplies the vectors for breakage and will increase the long-term maintenance burden. Don't re-invent the wheel; definitely use well established and tested libraries rather than roll your own, but carefully weigh each and every one as if you were on a code diet.

Making it an app it just so it's "an app" doesn't justify the overhead to me. Tools age, break compatibility, and die. It adds a learning curve for new contributors and even returning contributors that may have forgotten details. Cordova being open source is at least one positive for longevity/stability IMO. I haven't kept up with the state of the art on these "wrapper tools" so my past experience of them being dodgy and quirky colors my opinion as well.
 
1. Competitor sits at station.
2. Face recognition software identifies them.
3. Competitor drops cube into scrambling bay, cover automatically slides over, and machine applies the correct scramble, after checking that the cube is solved and legal.
4. Competitor says "I'm ready" and speech recognition software causes cover to slide back.
5. 8 and 12 second warnings given automatically until timer started.
6. After the solve, cameras detect DNF or +2 scenarios and also verify that the cube is solved and was the same cube initially scrambled, by signature recognition of sticker chips or plastic texture.
7. Results are live on cubecomps within 0.01 seconds.
8. That's enough of that, time for a cup of tea...

LOL you've officially called it. We will come back to this in 20 years time and see what's gone down.
 
Yeah, that's why I qualified it with "generally". The important thing to weigh is what you would gain by making it an app. If you need access to device hardware then there may be no other option. I've spent too many years in legacy code-bases so everything added to a project simply means technical debt to me. For a quick little trip through how my mind works on this: every line of code and every dependency multiplies the vectors for breakage and will increase the long-term maintenance burden. Don't re-invent the wheel; definitely use well established and tested libraries rather than roll your own, but carefully weigh each and every one as if you were on a code diet.

Making it an app it just so it's "an app" doesn't justify the overhead to me. Tools age, break compatibility, and die. It adds a learning curve for new contributors and even returning contributors that may have forgotten details. Cordova being open source is at least one positive for longevity/stability IMO. I haven't kept up with the state of the art on these "wrapper tools" so my past experience of them being dodgy and quirky colors my opinion as well.
I agree with pretty much everything you say here. To be honest I feel 90% of the apps out there would actually function better as web apps. You can even make an apps available offline these days, and as Lucas says, add it to your home screen and its just as good as an app.
 
Back
Top