Hi Paul,

I'd like to make a few comments here. . .

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

Well, in this particular case I would say that you *DID* make the software harder to use. Whenever you 'change the rules' mid-stream (I know, the "rules" said the acceptable way to enter things, but unfortunately they weren't backed up by the code) you are going to get such a reaction.

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

My opinion is that there is no real relationship between 'enforcing business rules' and flexibility/ease-of-use. At least there shouldn't be (in the perefect world towards which we all are working). Alan Cooper has much to say on this (and it seems like you've read him) but there is some that he suggests that simply cxannot be done today because of 'Windows standards'.
My very first dBASE app, by the way, was a data entry app that kept a "Limbo" file of the clerk's entry when there were unresolvable errors. They could close out as normal and then simply go back to edit once they had the answer(s) needed to get a "clean" save. Based on key it simply check PROD file first, then "Limbo" file. Limbo entries were deleted once a PROD save was done. Users seemed to like that alot.

> 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'm one who vote for no prompting, on the basis that a clerk/user selecting SAVE knows that's what they want to do. Even better (but I have yet to write one myself) would be to 'save' as they go, making the user specifically hit a 'trash (cancel) to undo all that has been 'saved' (automatically) so far.

> 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?
>
If I can ever figure out a way to STOP menus (regular or popup) from disappearing on a click of an item, I will do so, standards be damned! Windows in general is far too fond of mousing!@#@! It seems more to be designed to enhance one's dexterity than with productive app usage. Have you had much need to go into Help, click on something, get a MODAL sub-list of related topics, click on one, find it isn't applicable and then find that the modal window is GONE so you have to start all over. Grrrrrr!
There are lots of Windows "standards" that really get in the way rather than help user productivity, but it seems like it will take lots to change even smaller ones.

> 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 ;-)

Those are some of my thoughts,

Cheers,

Jim N