Old timey data entry GUI problem

[Ken Corey]

I'm not sure what kind of tourney you've got there, but why in heaven's 
name do all 4 numbers have to be entered each time?

Surely the id is known before-hand...and likely the table and partner 
number too, otherwise how is this event scheduled?  All of this should 
be entered before the event happens, I'd have thought.

So really, the only thing that needs to be entered is the points.

Now I'm just thinking out loud here...but what's your point range? Is 
there a limited number of points that could be scored? Is there a chance 
this could be done on a slider?  Even if not, a single entry is not as 
painful as entering 4 numbers.

Further, why does it have to be a page per entry?  Why not a table 
format so that the data entry person doesn't have to leave a page?

Finally, with a table format I'd forgo the mouse altogether.  When the 
data entry person presses <enter> in any of the fields, that row of the 
table could be submitted or stored.

The bigger question in my mind though is how are all these tallied at 
the end?  4 people entering numbers means 4 computers, perhaps all 
reporting the results to a web server? Do the numbers need to be 
communicated between computers so that the data entry person on computer 
1 see what is entered on computer 2?

How were you thinking of tackling the data gathering once entered?

I know it's sacriledge to say so here, but what about the data entry 
people each entering the scores into an excel spreadsheet, and then the 
4 spreadsheets be joined at a single computer?  Lower tech than a 
custom-written solution, but all data entry folks know how to run Excel, 
and how to copy/paste from 4 sheets into one.

-Ken

On 22/07/2012 15:11, Björnke von Gierke wrote:
> Hi everyone
>
>
>
> Sorry for the wall of text, here's a short version:
>
> I am developing a software for a charity tourney. I need typists to enter 4 numbers about 200 times within 30 minutes (or so). See screenshot of what I got right now: http://i.imgur.com/G7Fgg.png
>
> I have no experience with such a situation at all. My question is: How can I enable the typists to be very quick, but also make sure that they won't accidentally submit a false or partial entry to the database?
>
>
>
> Much more details:
>
> There's about 200 players in the tourney, and rounds are between 30 and 45 minutes. Each of the player hands in a slip of paper as a tally after each round. Four numbers from these slips should then be entered into a database by typists. People cost money, so the less typists needed, the better. That means the form has to be geared towards fast data entry, because they need to finish in time for when the next round ends and new slips start to come in.
>
> In my current GUI, I have four fields, with some restrictions and so on. After the fields have been filled out, the typists have to press a "Save" button with the mouse. The problem with this is of course that changing a hand from the keyboard to the mouse is just generally slow.
>
> Some thoughts about how to approach this more efficiently:
>
> - Use the enter key on the numpad, but only when in the last field.
>     --   I fear this could lead to some accidental entries.
>
> - Use enter key and pop up a dialog, so that the enter key has to be pressed twice...
>     --   People would probably start to always hit twice automatically, making the entry take longer with no benefit.
>     --   But then, dialogs in LC can take variable time to pop up, making
>
> - Force them to press shift (or other key) and return at the same time.
>     --   "Smart" users could start to hold shift down all the time, because that is easier.
>
> - On a different note, maybe have a second person reads the numbers to a typist?
>     --   I feel that would make error checking after the entry too hard.
>     --   Several reader/typist pairs would confuse each other.
>
>
>
>
> I know that some of you guys worked with data entry for decades, and that text only interfaces used to be all the rave. So I'm sure there are best practices, or often used approaches for something like this?
>
> Thank you for reading
> Björnke
>
>
>
>