Are entry slips that can be scanned and automatically imported into WER practical ?
A small example would be something like:



Where the match finished 2-1-1 for player 1 and player 2 dropped. Some additional columns may be added to inform the scorekeeper there are pending penalties on the back of the slip. Also missing, some corner ID like in QR codes that would allow the slip to be in any orientation and the table number. This would use just a webcam.
Do you think this is practical?

I have been working on something near that to implement in my LGS, but I've found some issues….

When I have something consistent will share.

Regards

Enviado do meu iPad

No dia 18/02/2015, às 12:29, Luís Guimarãis <forum-16335-93cd@apps.magicjudges.org> escreveu:

I suspect the biggest issue is likely to be the players. It's quite common for the match to end and one player to write 2-1 and sign it, and then they realise that they've filled it in backwards and the result is 1-2. So they scribble it out and correct it.

Originally posted by Mark Mc Govern:

I suspect the biggest issue is likely to be the players. It's quite common for the match to end and one player to write 2-1 and sign it, and then they realise that they've filled it in backwards and the result is 1-2. So they scribble it out and correct it.

Totally agree, this is what I thought the “bottleneck” would be. But who knows… with some education…

Even if you have to manually enter like 25% of match slips, you're still
saving time on the other 75%.

2015-02-18 8:00 GMT-05:00 Luís Guimarãis <

Also, honestly, I don't know how much time this would actually save as a
webcam implementation. I would look into using a scantron-like solution
with customised cards.

2015-02-18 8:48 GMT-05:00 Dominik Chlobowski <

Top end scorekeepers take less than a second to input a match result on traditional slips, good scorekeepers maybe take a second. How much time will you save by using the scanning method?

While I like the idea of automating, we would still need a second pass through for penalties as well. I'm not sure that automation would be time or cost effective in this case.

Edited Addison Miller (Feb. 18, 2015 03:41:28 PM)

DCI Reporter (the old software) had (and may still have) an option to print barcodes on the result slips. Judges would put the results in different boxes, based on the result (2-1, 1-2, 2-0, 0-2, other). Then, in DCIR, you'd set it to 2-1, and scan the barcode on all of those result slips.

It wasn't faster, and it introduced a whole new set of errors.

d:^D

Even if you could get it to work, it would be a solution looking for a problem. You'd have to be running a GP level event to justify dropping the coin on a scantron machine or similar equipment. Most GP's already have such a machine called Nick Fang(TM).

You can find CueCat barcode scanners on eBay for around $10, often less - make sure you get one that's been modified to work with on a USB port. Here's one example.

Note that I tried those with the DCI Number ID cards, that have the barcode, to cut down on entry errors & time. Didn't help; my ten-key skills are above average, and the barcodes just don't always register, or don't survive life in a pocket/wallet/binder/etc.

d:^D

I'm imagining how a 2/1/6 result might look. (maybe we both wanted to keep drawing games for that last one until we both had solid hands?)

If this is a problem that needs to be solved I have a feeling the
right solution is allowing results to be entered on the same website
players are using to receive their pairings (as that is a given if you
are looking at results entry as your lowest hanging fruit for event
streamlining).

It does have it's own laundry list of issues to be overcome, off the
top of my head:
Identity verification.
Player acceptance.
Conflict resolution (do you require both players to submit a result,
how do you resolve the players entering different results, how do you
resolve a paper slip conflicting with the digital submissions).
etc.

I hate it when paper is the best solution, but I'm pretty sure it is.
And nearly as much when manual data entry is too, but it also probably
is.

On Thu, Feb 19, 2015 at 6:40 AM, Chris Nowak
<forum-16335-5ba7@apps.magicjudges.org> wrote:
> I'm imagining how a 2/1/6 result might look. (maybe we both wanted to keep
> drawing games for that last one until we both had solid hands?)
>
> ——————————————————————————–
> If you want to respond to this thread, simply reply to this email. Or view
> and respond to this message on the web at
> http://apps.magicjudges.org/forum/post/104786/
>
> Disable all notifications for this topic:
> http://apps.magicjudges.org/forum/noemail/16335/
> Receive on-site notifications only for this topic:
> http://apps.magicjudges.org/forum/noemail/16335/?onsite=yes
>
> You can change your email notification settings at
> http://apps.magicjudges.org/notifications/settings/



–
Gareth Pye
Level 2 MTG Judge, Melbourne, Australia
“Dear God, I would like to file a bug report”

Originally posted by Chris Nowak:

I'm imagining how a 2/1/6 result might look. (maybe we both wanted to keep drawing games for that last one until we both had solid hands?)

Perhaps a row of numbers, the one appropriate to the number of draws to be bubbled in.

“Is this practical?” isn't the right question to be asking. There are plenty of things that can be practically done if you put enough resources into them, but that alone doesn't make them worth doing.

What problem are you trying to solve? In what way do you hope that this solution, if it is practical to implement, will improve upon the current techniques that address those problems?

It's more important to figure out what you're solving and why before you figure out how.