I'll add my 2 cents:

>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.

IMO, you didn't make the software harder to use. You are enforcing a situation where the people didn't do their job right in the first place.

>
> 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?

Paul Cooper makes a good point of this. Do you cater to the casual user or the power user? What makes the software easier for one makes it more difficult for the other.

>
> 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?

I make is customizable. I have an options screen where the user can change this. My plans for the future are to add my own dialog box and have the "Don't ask me this again" check box...but also tell them where they can turn it back on.


>
> 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?

That's more difficult. An intelligent help engine is the way to go here. MS had made some steps to improve this, but IMO, it's still a long way from being there.

>
> 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 try to enforce Windows standards where possible. While I don't agree with all of them, this is what users have become used to and it makes life easier for them. I recently added an MRU list to my file menu. It was a pain in the butt to make work properly...but it's just another added touch of professionalism, polish, and something the user has seen before.

>
> 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?

I agree.

>
>Lots of questions ;-)