Data Entry battle scars (a follow up to Richard's Big Coding Challenge post)
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
You're singing to the choir, in my case. I've worked in a hardware store (Ace) and was convinced from that experience that not one of the people who worked for the software company that provided our retail and back office software had ever set foot in a hardware store, let alone worked in one. The actual job is hard enough without the support software actively trying to prevent the worker from doing it! Every developer should be required to do the target job for a year before being allowed to write a single line of code. In a similar vein, I signed on as a Jr Engineer at General Dynamics many moons ago. Much to my surprise, I was forced to join the Teamsters Union, then spend my time at a workbench building stuff other, more experienced engineers designed. I resented it a bit until I saw the garbage these idiots designed without any thought about whether they could actually be built. Even simple things like keeping the number of wires going to a single connector pin with a hole of limited size they got wrong. And placing screws and pins in places that cannot be reached by human hands was a common occurance. A year later when the put me on salary and in an office, I was a far better engineer than any of those who missed that experience!
Will Rogers never met me.
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
There's a fundamental rule for UI design: Consider your audience. This means you have to be able put yourself in the user's shoes and figure out how to best help them use what you're providing. It's interesting that this same rule applies to writing. I've spent most of my career doing UI for applications controlling complicated machinery. The attitude of the hardware people developing this machinery ranges from caveat emptor to open contempt. If I hear "Can't you just do a popup?" one more time, blood will spill.
Software Zen:
delete this; -
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
I have been preaching this exact same thing for 30+ years. IF you want something to work better. Force the programmers/tech people to actually do the job. Interestingly enough. The CEO or a local very large Grocery store got vilified for forcing his IT staff to do that exact same thing a few years ago. But it was the right idea! Make them use what they produce. They will then go make it better.
To err is human to really elephant it up you need a computer
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
I remember a contract where I was not allowed to talk to the end user and there was no such thing as a BA. All information came through a manager. Needless to say it was a total disaster and is the only time I ended up in court over a design :sigh:
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
"was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted." is elephanting legend. I have seen so many projects fail over the years, because everyone knew technically how to get the job done, but they were not the one doing the job.
Charlie Gilley “Microsoft is the virus..." "the problem with socialism is that eventually you run out of other people's money"
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
honey the codewitch wrote:
the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted.
Smartest thing I've read in a long time. And it should be obvious, but unfortunately some people need to be reminded of that.
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
-
I should note that this isn't exactly related to Richard's overarching project, but it made me think of all this, given his specific problem was one that very much seemed a data entry problem. This almost deserves an article or something, but I'm just not up to writing it, so I'll leave it as a very general, code free set of observations from directly working with people who needed to use my software to enter data. When I was building little apps for local small business (a taxi company) or at least local chapters of larger organizations (Boys and Girls Club) the first thing I always did was job shadow the person doing the job my software was either going to streamline or replace. I didn't write a line of code until I could do the job as well, if not as fast, as the operator doing the tasks my software targeted. Do this. For the love of everything that is right, do this. I can't stress enough how much better your product will be. As often as not you'll come up with something that breaks all kinds of UI guidelines you were taught, but provides a far better DIRECT EXPERIENCE in the context of that operator's workflow than Microsoft ever could have thought of when writing their style guides. It's priceless. If you can't do that for whatever reason, then at least get regular feedback from someone who is dogfooding your code (you're dogfooding during development, right?), but that's still not anything like learning the tasks yourself. From this experience, a few stupid observations: People that enter data like keyboards. Moving your fingers to the mouse means moving them off the home row. Every time you do that, it's productivity that could have been stored for making a sandwich You can type anything you can click, short of painting a picture. So the rest is just, what they type and what you accept. That's where the effort should really go - gentle enforcement of business rules, and make your software work like a good employee - if it has a problem, it also suggests a solution. something that can be quickly keypressed past. Autocomplete is your friend, as long as it's unobtrustive. Entry history for fields is usually worth its weight in gold. "BUT THAT'S SO 1990S!" you may scream. "What about all these fancy web style user interfaces that are all the rage these days?" No. There's a time and place for that - usually on a phone - for working people, your interface is work boots, not heels. AND FINALLY USE YOUR OWN STUFF. I stand by this stuff, and if I'm wrong about it, well being w
I'm part of a project that is replacing an oracle forms app with a web-based solution (javascript using React). We have the "keyboard-centric" UI requirement that you described. We have some interesting auto-completes - In a date field, if the user types an integer from 1-last day of month, and hits Tab, the date is automatically completed to include the current month and year. - On floating point numeric fields, if the user types a period on an empty field, a "0" is automatically pre-pended - We have LOV (list of values) field that allows the user to press F9 to get the list displayed where he can then select one of the values and press return. If he types a value that isn't in the list, and presses Tab, the list of values is displayed with the nearest matching value pre-selected. Curiously, we don't have hot-keys for button presses. I brought it up, citing the keep-them-on-the-keyboard paradigm, but was unceremoniously shot down. I don't make UI suggestions any more.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
