Developing websites for data entry

Question

We are in the process of developing a website to replace an old green screen data entry application. The problem is that our users are accustomed to FLYING through the screens (i.e. blind typing ... they never need to look at the screen or their fingers). They are very nervous about moving to the web, and I was hoping to assuage this nervousness by showing them some examples of sites that handle data entry well.

Any suggestions?

Update

To clarify the "flying through screens" comment, here is the typical use:

• CSR logs in, has stack of customer bills sitting beside her
• User clicks E and enters custom name from top of bill
• User enters billing/invoice information from bill, this is stretched across 5 screens but user never needs to look up from bill
• All typing is "blind" (since they don't look at keyboard or screen) ... they are averaging over 50wpm throughout data entry (which is a VERY fast average) ... and experience no waiting
• There are many keyboard shortcuts along the way, i.e. for dates, user lookups, item lookups, etc. User has no need to look up from the screen when typing these
• Once done, user clicks P to preview and views invoice/statement on the screen to verify totals and items
• Error rates are below 1%, extremely good for manual data entry

Answer 1

if keyboard shortcuts are the most important part, then i would suggest showing google docs - them even overwriting cmd+s with their save action surely impressed me on first use.

Answer 2

I would suggest you do not go to Silverlight with this - while you can do cool things with it, the controls can be just a fraction of a second slower to respond than regular HTML controls, and even that small amount of delay is going to irritate the crap out of users who are used to an instant response. You only have to slow them down a little for their daily productivity to drop. Find out what their current rate of entry is, and do prototypes to see if you can come close to it. You also have to be careful about how you save the entered record - you don't want to introduce a delay there either.

You also need to think about validation - you need to do it, but you don't want to be obtrusive with it.

I don't want to be a party pooper for you, but i really doubt that you can get a web app to be anywhere near as fast as the terminal green screen that they are used to - you might want to also evaluate a desktop app for the data entry. You have a tough task ahead of you :)

Answer 3

I am not sure if you will find many good examples on a public website. Most sites are designed to help guide "newbies" to a site through the various forms rather than focusing on input speed and efficiency.

I would say with the right combination of javascript/JQuery and basic html, you could design a page for internal use that would be quick to enter information on. My company has some web screens that we used javascript to auto-skip to the next form field when the max length is hit. An example would be using 4 different textboxes to collect a credit card number. Once 4 digits are entered into box1, the cursor jumps to box2. Also, input fields can be set that they could tab to the next one in the correct order.

I have seen references to adding keyboard shortcuts to a webpage. I have never done it myself, so I am not sure exactly how it is done. But I think javascript can be used for that feature.

Answer 4

I would imagine you could just put together some forms that could handle this, but it would require a few extra considerations if you want users to be able to use it without looking at the screen:

• This means no drop downs, checkboxes, etc. Just textboxes, textareas,
• The jQuery AutoTab Plugin could be very helpful for this, so it would move them from field to field automatically
• if they are used to Keyboard shortcuts, I would include those as well. Once again, here's a jQuery plugin for that.

Answer 5

Unfortunately, fast data entry != web app.

If you must do this, then

• keep javascript to an absolute minimum. We're after entry speed after all and who knows which browser they will be running. If you decide to put something in there to automatically take them to the next field, make sure the green screens were already doing this AND that you mimic that logic exactly.
• Make sure the tab order of your elements are exactly what the green screens had Otherwise they'll hate it no matter what you do or how much "more efficient" you think it will make them.
• Make sure the pages have exactly the same fields as before.
• Basically, don't even think about reorganizing anything right now. The change from terminal to web is already going to be upsetting. However, if everything works EXACTLY like it did before then it will be minor grumbling instead of outright revolt.
• Skip any graphics. Use simple css for styling / coloring things. Any graphics will slow down page loads, sometimes just a little.

Just to iterate, keep it simple, do exactly what was there before, minimize both page size and page artifacts (css, js, images, etc), do NOT introduce anything else that is new. Change Management can be a difficult thing and no matter what you do bear in mind that you are changing their work, even by just a little. People who are attracted to data entry jobs never like change and will grumble. The only question will be in how much.

After it's deployed and starting to be used, wait a month or two before you start listening to feedback (other than outright bugs. Fix those immediately). This will give them time to get used to it and start making non-emotional suggestions.

Grow some thick skin. At some point a VP or high level manager is going to be campaigning to go back to the old way of doing things. That's fine and should be expected, they don't like change either even if they were the ones who asked for it.

Next, don't expect the data entry team to even look at your app until it's deployed. Sure having a couple people from their team look at it every now and then (even test it) sounds like a good idea. However, they will think they have "better things to do" and won't provide any usable feedback until they are forced to use it because they have no other option. Expect this.

Finally, make sure you have exec level support BEFORE starting down this path. At some point they are going to come face to face with data entry managers who are unhappy. It helps if they believe going back isn't even an option.