Fog Creek Software
Discussion Board

Bulk data entry

Hi folks,

I am embarking on a little tool that will be used daily to enter lots of info.  So, having assured myself that I can generate all the fancy reports required to wow management, I am focusing my thoughts on actually making it quick and easy to do data entry!

In my scenerio a form would be normal.  Only problem is, I've never personally found forms very straightforward to use.  As a user.

I was considering a more complex entry method: parsed text entry.  The screen looks like a word-processor, but underneath the data is parsed, with automatic formating so the user can see what is going on.  This has the advantage of closely mimicking the current way the users record their info: on paper.  Of course, in a computer system it is easy to have something like 'code completion' so they only need start typing the first few letters of an entry and they get speed-ups that way.

Would this be less intimidating for not-particularly-computer-literate users?  Thoughts?

i like i
Monday, October 13, 2003

Converting a manual process to a computer based process usually has some cost associated with it. In this case the cost might be a little bit of training. Train the users to make use of the form and any special extras like a smart tab layout (the tab key, not windows tabs), maybe auto-completion, and well positioned controls. If the reports and data storage have value, then usually the training cost is worth it. I mean you are spending all this money on computer systems, they don't work real well as notepads yet. I think users staring at a big text field might be more confusing in the long run anyway.

Monday, October 13, 2003

If you've fournd forms confusting it's because they are badly designed.

Remember nearly everybody who has worked with a computer knows how to work through the form to set up a hotmail account, so they can't be too offputting.

Stephen Jones
Monday, October 13, 2003

Isn't that a leak abstraction ?
You give a way how the user should type the data into the system. I guess you certainly have something like a language or structure. This language will be a logic one, not an intuitive one. So your user interface only pretends that one could write like on a note, but he or she simply can't. Forms don't pretend that.

Michael Bruckmeier
Monday, October 13, 2003

i like the idea of automated form parsing.

how many of you use google to find maps on yahoo? or telephone numbers? or the calculator?

why is it cool? because the computer parses your request. instead of going to yahoo maps (easy), then typing the address into component bits (street name here, city here, country here), you just type (or copy & paste) the whole thing into a single input area, and the computer figures it out.

error correction is the hard part. if you have a form, it needs to display what it thinks you typed. and you need to actually verify that. that may be difficult.

for bulk data entry of a set of existing alread-parsed forms, a good keyboard driven UI is still probably the right answer: set the fields up in order of the existing forms, then item1, tab, item2, tab becomes easy to do.

Monday, October 13, 2003

Two thoughts:

1. I get the impression the free form would involve more than one distinct piece of data, not just narrowing in on one topic.

2. It is cheaper to train a couple dozen people than build a google infrastructure.

Monday, October 13, 2003

Once upon a time, in a world far far away, I worked as a cashier for a lumber yard.  While many retail stores could get pretty far with scanners, a lumber yard was, and still is, pretty difficult to automate. 

The ancient NCR POS systems had pretty much reached the maximum potential and the management at HQ heard of this new wizbang concept called JIT inventory that would certainly save the company millions of dollars every year.

It was time to build a new state of the art POS system.  This was probably the only time in my life that I've been a customer of a major custom IT project, and it was a miserable failure.

The terminals had a windowing interface that was similar to Windows 3.1, but was really OS/2 2.x.  Very few have ever even seen the system used in production, but considering the alternatives it was far better than microsoft offerings of the day...

With that said, the interface was a flop.  Data entry was slowed to a crawl while cashiers looked for the tab key, closed modal dialog boxes, grabbed the mouse to complete the transaction, all while the 386 struggled to render the next screen.

I suspet the amount of money that was spent and lost on the project helped speed demise of the company.  The lesson I learned (at someone else's expense) was different interfaces make sense for different applications.  The windows desktop PC metaphor does not work for rapid fire data entry.

Full screen data entry used in conjunction with custom key devices or touch screens are the only way to go.  It seems most retail stores have learned this lesson, and few use a windowing system for terminal data entry.

I would check out the POS systems are your local grocery.  If you can, watch the cashiers make a few transactions.  This might give you some insight into your UI.

christopher baus (tahoe, nv)
Monday, October 13, 2003

I'm just helping a client through the process of installing a CRM system which also replaces most of the order processing of their existing accounting system.

Apart from nuisances like having to use a mouse and the tab key, one of their biggest stumbling blocks in data entry is that the CRM system is mixed case.

I've rehearsed before that in accounting and order processing applications its important that the eye and focus of attention should be at the same relative place and that new windows should overlap naturally and not pepper the screen and get hidden and such.

This CRM application sins worse than most I've come across in that regard.

And no they didn't consult me in the choosing of the software :-).

Simon Lucy
Tuesday, October 14, 2003

*  Recent Topics

*  Fog Creek Home