I just read the first chapter of "The Inmates Are Running the Asylum" online at:

http://marketplace.devx.com/upload/excerpts/cooper/toc.asp

It got me thinking a bit about how software should interact with the user. One of the areas that seems like it would be at odds with the "Easy to Use" concept is enforcing business rules. Let me give an example:

I recently updated our main management program at all of our locations. The only changes I made had to do with enforcing and checking for user errors. We had been dealing with incredible mistakes that were just being swept under the rug because the software let them. My modifications simply checked their work before they could close a job (which is partially how they get paid). If it wasn't right, it would give them a reason why it failed but it wouldn't let them close it until it was fixed.

Of course, we've had a few of the locations screaming at us because the software is now "hard to use". In fact, we changed very little of the way the program worked. I'm sure a lot of this has to do with the bad habits they developed because the program wasn't checking for these things and letting them make mistakes in the first place. But I'm sure we've all run into situations where it's not always possible to account for every variation that a user might throw at the system.

There seems to be a very fine line in some areas where allowing them a lot of flexibility is at odds with enforcing the business rules. Or is flexibility even synonymous with easy to use?

Then there are the differing definitions of what is easy to use. Some people absolutely hate being asked if they really want to delete something. Other people will argue that it's a bad design if it allows you to delete something without a prompt. You can add code that lets the users customize this functionality, but where do you draw the line? When does making things customizable add too much complexity to a program?

Do you hide the options normally not used to make it easier? How are users then supposed to know how to "turn on" the advanced features? If you make it too accessible there is the chance users will accidentally turn it on and suddenly be overwhelmed by the number of new options - they may not know how or what they did to cause it. How do you deal with these grey areas?

What about interface standards? Do you use them or throw them out and create you're own new interface to make it easier? Or maybe use a hybrid approach? To be honest, I'm usually irritated by programs that don't follow the normal interface conventions. Am I the exception because I'm also a programmer?

I like my programs to be consistant. It makes them much easier for me to learn and use. I read an article about the dining habits of most people. People seem to prefer (and go more often to) restaurants that were consistant. Either consistantly good food or service, or consistantly bad. It didn't matter, as long as they were consistant. They'd actually stop going to restaurants where they couldn't predict how their meal/service was going to be. Wouldn't this also apply to software and software standards?

Lots of questions ;-)