Old timey data entry GUI problem

Sun Jul 22 13:25:43 EDT 2012

Thanks for your thoughts, some interesting stuff. The game that is played is "Jassen" the (almost) official Swiss national card game: http://en.wikipedia.org/wiki/Jass

You asked why I need those exact four numbers. Yes, all 4 numbers need to be entered:

- I need to know the ID of the persons who gave us their points, because there's no use in entering points that are not associated with a person.

- I need the partner for historical reasons. I'm working at merging that into the table like I did with the two opponents, but the customer wants it that way, at least for now.

- I need to know the table at which the player sat on, to know whom they played with, because we need to know all 4 persons to do data validation against cheating. Note that seating is done in a certain non-computerised way, again because of historical reasons. It's done nonverbally, and they do not want to print and hang out a list where everyone crowds. Most importantly, player can opt out of rounds whenever they want, and organising "left overs" would be too time consuming.

- I need the points the person made.

You asked about how I am doing all this behind the scenes. First I wanted to have a SQLite db on a shared drive, but, the database file was always being locked by the file system. I assume that is because LC uses an ages old SQLite version. In addition, the SQLite documentation itself says that should not be done, so now I have a LC server that accepts either database queries or database commands. The clients connect to it on a local wired network (there will be no internet, but we don't need it anyway). This should work as long as none of the db-edits are on the same records, which can be avoided easily, as most edits are 'insert' and not 'update'.

As you can imagine, there's more to my app then just this one entry form, like various print outs, tallying, entry validation, cheat prevention, etc.

Changing the entry form to a table-based view sounds interesting. I'l think about it, especially considering that the typists could fix errors in the entries within the same view. I would need to redo some of the existing stuff from scratch for that. I can't use a non-LC tool for the tallying, mainly because only the top three rounds count towards being ranked.

I agree that using a button that needs the mouse is not the way to go. I just mentioned it because that's how it looks right now.

On 22.07.2012, at 16:29, Ken Corey wrote:

> 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
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

-- 

Use an alternative Dictionary viewer:
http://bjoernke.com/bvgdocu/

Chat with other RunRev developers:
http://bjoernke.com/chatrev/