We all know the saying, “If you make your product idiotproof, they will build a better idiot.” So where do you draw the line? When does an error cross the line between being a bug and being user idiocy? I mean, sometimes you get a bug report where you think, “Man, they really had to work hard to screw that up!”
The trade-off I’m always making is between productivity and protection. The more flexible and powerful the app, the more productive the user can be, but it also allows more room for screwing up. If you make it easy for the user to correct his mistakes, you also have made it easy for the user to make additional mistakes.
For example, we had the situation where the users would enter a sales order and then realize when they’re almost done that they entered the wrong customer (they got “Costco - Portland OR” instead of “Costco - Portland ME” for example). So we made it easy for them to go back to the order header and correct the customer info, and when they save it silently corrects all the underlying data - line items, inventory history, etc. Big productivity gain. However, we occasionally get a report from a user who is bewildered that the order they just entered now has a different customer assigned. This is obviously a clumsy fingered data entry clerk who managed to trip through the customer field and change it by accident.
So do you lock it down to prevent the second user from hurting themself, but at the same time making it harder for the first user to get their job done?
What do you think? Where do you draw the line?
(In this particular case, I made it a preference option and provided an override mechanism, so they can have it wide open, full throttle or lock it down and do a little more work to override it. The question is intended to be a more general discussion.)
We’ve found no hard rule on this. It all depends on the client and their needs.
The one thing that’s been consistent though is deleting of data. It almost never happens. It can be marked as deleted but that data is still in the database. We just never list it. It makes queries a bit more complicated but the clients seem to like it.
I guess part of this may have come from multiple accounting applications in the past 10 years. If people can’t truly delete things it’s awful hard for people to cheat (like embezzle from the company - which not deleting data helped catch).
Audit trails help too. No matter the change, track the change so you know who, when, and what changed.
After 20 years of building software, I am now certain that users NEVER RTFM. You may build a detailed and comprehensive help system, but they will click and click for hours rather than consult that help system. Also, no matter how straightforward you believe your interface to be, someone will take a different approach and screw it up. Design your UI carefully, test thoroughly, and then be prepared for angry emails because the user wasted two hours trying to get A to B and “…it doesn’t work. What should I do?”
My wife is the best for this, she’s computer literate, but not a techie. She not only finds me problems with our software, she also finds interface issues. If she struggles with something, it’s time to redesign it. She never reads the help.
The only suggestion I have (if you haven’t already) is a confirm changes dialog, keep the text as simple as possible, but make them work to confirm the changes (not the default button), this will cause some reading to take place.
Our experience is that it varies wildly from client to client. Enterprise size clients (billions in annual revenue and thousands of employees) usually want a lot of structure, restrictions and security with audit trails of all activity and some undo/rollback functionality. They love automation and are very willing to pay for it since it reduces labor and minimizes errors. Small to mid-size clients (tens to hundreds of millions in annual revenue and tens to hundreds of employees) usually want flexibility and minimal security. They too would like automation but are generally less willing to pay for it despite what appears to be plenty of revenue and profit.
Bob mentioned this and there are a variety of ways to approach it but be sure to have some relatively easy means of restoring data that was accidentally, or purposely, deleted/purged and a way to answer the who, when and how questions that will follow. For our clients regulated by one or more federal government agencies, forensic work and restoration of specific subsets of data has been financially lucrative while gaining us additional larger contracts with those clients and competing businesses in the same industries.
During the design phase of each project, describe in great detail the various “bulletproof” options along with their timelines and pricing. If doing so does not lead to a bigger budget for the project, it will at least make clear that the client had the option and chose not to include it. Whatever their choice, follow up the meetings in writing so there is no question what they have chosen and what they have declined. Months or years later you’ll be rewarded again for pushing those options or save your business from any attack related to their data errors/loss and their choice not to better “bulletproof” the apps they contracted your firm to develop.
Quality assurance is a thing on its own. A lot of forum visitors here are companies with only one employee. Architect, developer, consultant, tester. No matter how thorough you act, users find a blind spot in seconds. Why? Because you missed it.
Who writes a test plan? Who have customers who demand testreports? Who uses automated testing? Who sends their software off to external testers? Who uses ‘real’ alpha and beta cycles?
I am curious. My experience is that I calculate test hours (and get paid for) but those hours are actually spend on resolving bugs.I always offerr clients alpha and beta stages, but they simply say ‘ship it when it is good’.
I do, and it’s driving me mad! Every time I fix a bug or I think I made a feature fool proof, he finds at least ten ways to break it. He’s not a “professional” tester, just a user who has taken an interest in helping me develop my app. Some bugs, weeks later turns out not to be actual bugs, but rather a different understanding of how to use specific features. Just goes to show how difficult designing a proper user interface can be.
My wife is the best for this, she’s computer literate, but not a techie. She not only finds me problems with our software, she also finds interface issues. If she struggles with something, it’s time to redesign it. She never reads the help.[/quote]
How wonderful it is to have a pro to discover bugs (to help you improve your software).
I have a client who asked me to add a password to avoid the trouble included in “every one can make changes”. He thinks it is a good way to not have wrongs in the Data Base file.
I do not think so: the only way to have good records is to be cool at record creation time, read carefully the data to write, write them carefully, etc. This is not a problem of “bad people” (some may use Troll instead of bad people). Another thing may help is to make multiple sorts and check what is in the data base:
No more CCCP / USSR,
Gaul and France are the same (different location in time, but “same” country name),
Byzantium, Constantinople, and Isntmbul are the name of the same city
Stop mixing First Name and Last Names
Stop telling that the client birth date is after its first bill,
and so on.
At my previous job made sure all users of the app had to log in to use the app.
One they were logged in they were assigned certain rights.
After that all actions to the db (other than select, so only data manipulation queries) were logged, with user name and time of the action. Deletes only happened after copying the data to be deleted to a shadow table (same structure but it only contained deleted data). I did the actual deletes on the main table(s) after successfully copying the data to their respective shadow table(s).
This was done to prevent the main table from being difficult to browse if necessary (due to excess data marked as deleted), since I was regularly asked to double check something straight in the database (which I did in pgadmin). Of course most of the time my program had done things right, but without the logging it was difficult to prove what the user had done. Hence the logging.
With the logging in place it also made it easy to find and correct if I had made a mistake.
[quote=100782:@Oliver Osswald]they think that they do not have to learn about computers. “It just has to work”
they are not interested in learning anything which goes even one step beyond the job that they are trying to do, right now.
they do not read manuals.
they call me and want guidance. After I guided them through a process, they immediately forget everything.
they call and ask the same questions again, which they asked on a previous call.
they cannot tell between application, operating system and hardware.
they call and say “HE is not working, I did not do anything”
they are lost as soon as a window does not appear in the habituated way
they do not read texts on message boxes.
they forget what they just wanted to do and start clicking around randomly
they write passwords on little stickers on their display
they do not understand the options in the preferences panel
they do never watch the first steps video coming with an app (no matter how short and idiot-proof it is)[/quote]
Sooooo true! I’ve seen people literally stuck because of the Word icon had moved from top to bottom. They couldn’t find it anymore… The whole concept of a desktop with files and so on was beyond their comprehension. And I think that counts for so many users.
To reflect on the OP’s original conundrum, I’ll say the unsayable: I’m not afraid to let the user screw up and suffer the consequences of their own actions. Look, I get the computers exactal tendency that can make up for human impreciseness - but the model in which you handle what the customer gives you is just as legitimate. It makes THEM better at what they do, which is a great long-term goal: just as valid - or even more desirable - than the short-term goal.
Another way to say that is if you go “auto-correct on steroids” the computers guessing gives them a false sense of security and then they have to manually correct those mistakes later, negating any efficiency gains. (However, if you you do produce THE MAGIC and your auto-correct is 100% correct all the time, tell the “bewildered user” to get a life and if they hassle you any further, you’ll recommend they be fired. =))
“Depends on your user”? Nah - everyone is the same. None of them read manuals et. al. But they have a responsibility - and it’s not necessarily your responsibility. Sure, be helpful, and do so - but you can be TOO helpful. It’s their job, after all.
In other words, don’t feel the need to do everything, it’s a “fortune hunt that’s far too fleet”.
Before retiring I worked as a programmer/analyst for the utility company that serves most of southeast Michigan. I had a cousin who was a lineman for the same company. Now, lineman hate having to come in to learn new software that they are going to be required to use and my cousin was one that really hated having to do so. His goal was to do his best to crash the system, or at least his terminal, requiring those running the meeting to either have to wait for the system to be brought back up or to get his terminal running again. His favorite trick once the terminals became active was to depress as many keys as possible at one time and then moves his hands back and forth. That worked like a champ for a couple of his trips in to learn new software. Took a while for the programming staff to come up with a scheme to counteract his shenanigans. He was a happy camper when he was successful. These systems were all running on IBM mainframes under TSO. It is darn difficult to think of everything the user will attempt to do.
For me, it all boils down to who the target audience is for the product. We, as developers are naturally more lenient toward imperfect software simply because we are more used to having it. Our end-users are of various level of expertise and tolerance. (I say “we” since I’m including you folks from Xojo and we are your user audience.)
Imagine the outcry from your bank or non-technical industry if their software was received with as many bugs as some of the Xojo (or Realbasic) releases had. They are not really capable of handling and working around the problems. We are (mostly). They demand a higher level of “foolproofness” than we do.
So I try to have code I write as foolproof as I can make it since I am usually the fool using my code and I get impatient with myself when I get it wrong. (Fortunately, I am much better at debugging and code maintenance than I ever was at writing new, original code.) For a product that I intend to release, I use the following mindset in testing a “completed” project: “Ok, fool, how can I break this?” I intentionally stay away from testing what the product can do and try to force it into things it shouldn’t be able to do, always keeping in mind the target audience.
No, products don’t have to be foolproof, but I believe that it is part of our job as developers to keep the users from seeing that we think of them that way when they use the product in ways we didn’t imaging. Remember, there is no such thing as bug-free code. But that doesn’t mean we can’t, or shouldn’t strive for it.
And if the end-user can’t use the product, they will look elsewhere for one they can use.
I use Xojo to build reports from the data produced by an emergency department information system. My reports have to negotiate data input errors. For example, one patient was discharged 11 years before they were triaged. That really made our length of stay reports look good until I filtered that out. Sometimes, patients were born in 1799 making their age 315 years. Almost all the reports are aggregates so I can filter out the bad data. The users can now run a report that shows the data errors and they can go in and fix them. The number of errors have diminished. I can’t do anything about the application but I can help the users find and correct input errors.
