Great, two opinionated people meet on a touchy subject. This should get really good. :)


>[Warning: long reply} :-)
Ditto

>
>Sorry if I offend someone, but from what I've read (from your post) about Cooper, he doesn't know anything about the user world.
And ditto about the offense part to.
See the end for comments on Cooper.


Begin Reply--------------------------------------



Correction: He doesn't know anything about YOUR user group's world.



This discussion like many of it's type have a common misconception; The user is 'a' entity, like economist's 'Perfect Consumer'. The 'user' is a group of people that have different experiences and skill levels. They are not equal. What this means to the developer is that he must take his/her "target" subset of users into consideration when building an application.

If you were to write a program for a bunch of 3rd graders, your entire interface would change. Big colorful buttons. Big goofy cursors and icons. And maybe softer 'error messages' Now take it to another extreem build a program for just your mom. You know that she has her quirks like constantly thinking that 'Print Screen' should do just that. So you may write it so that pushing 'Print Screen' automaticly does a cut and paste into a OLE client like paintbrush and prints the screen. You might even personalize the error messages. "Mom, you already have this document open, your telling the computer to undo all your work and start over. Is this really what you want to do? [ :) No] [ :( Yes]"

I work with a team of developers on an Retail Point Of Sale application for Windows 9X & NT. Our target 'user' for the 'Register Screen' is a cashier. Usually the cashier has been working with a cash register. The may have worked with a computer (as a computer) before. But I will bet you a dollar that they know how a cash register works, and Cash Registers do not confirm correct entries. So neither do we. At the end of a sale, the register does not confirm the 'saving' of a sale into its logs (totals), so neither do we. We silently save all the transaction data and just keep on going. The computer becomes transparent.

Let assume that our target user group is a set of head down data entry people. Do they care that there data is saved? Yes. Do they wan't to be told on a line by line basis? Heck No. Streamline their task.

Now, you've got a software product that helps grandmothers design crossstich patterns. It lets them print it out so the can iron a pattern on to some cloth and create a nice banner for there son's 24th Birthday. Warnings about Saving? You Bet. Warnings about closing without saving? That to. Locked down tight. Confermations at everystep. Heck it might even secretly save their work in a backup directory.

Some of us write of user groups that have no intersection with the 'main stream' user group. Some of us write for the 'main stream'. It is up to us to determine 'what makes my user group tasks easier'. And what we do for each group is different.

For a mass use application like windows 95, there should be settings. I think that VFP's 'Confirm Form Designer Save' (or something like that) is a great step in the right direction. In the begining, when I am unsure of what I am doing, a request to save (or in my case, not to save) is perfect, but now that I am better at building a form, and I kinda know what I am doing (does a foxpro developer ever *know* what they are doing? :) ) I don't need to explicitly save my form everytime. So VFP gives the user a chance to *ACTIVELY* change the behavior of the application. IE4.0 has this to some extent; "Warning you are about to send text over an unsecure connection... [x] show me this again." This is great, let the user *ACTIVELY* tell the computer "I know, I know".

So there is no ONE TRUE ANSWER for all programs. Let the data and the interface model it asks for be your guide. Keep YOUR user group in mind when designing interfaces. And NEVER use an interface 'just because thats how does it' make sure its the right one for the long run.

Thats my inital 2 cents. For Bonus points there is more in the text below, but if your going to cut out now, thanks for reading.
Sam


>
>I didn't read the "Save or not" thread, so I will probably say things that have already been said...
>
>>A (beginning) user is making changes in a document (could be a table). When he's (or she's) finished, the user closes the document. Then the program aks the user if he wants to save the document or not. The user thinks WHAT THE HELL IS THIS ??? Why is the program asking me this. If i didn't want to save the changes i would have undo them before i closed the document (in the real world, Users don't write letters put them in envelopes and after that decide if they want to send them or not).
>
>Yes, but in real world, people who change idea in the middle of the letter won't erase (undo) what they've done, they'll just throw it to trash and move on.
>
>And no, beginners don't think "if I didn't want to save the changes I would have undo them". I have users who type something, realise they've entered data in the wrong record, and almost come to me crying until I tell them, "well, you haven't pressed Save yet, so just press Cancel and your changes won't be saved!" And they're releived as if their boss would have killed them! I sometimes make changes in a document to see the result (an Excel spreadsheet for example), but I don't want to save that information. How many undo do I have to press to put it back to it's original state? I'd rather make a copy, work on it and throw it to trash, but that's not a beginner's task!

After a beginner is shown this concept, how long does it take them to work it into there methods? I bet the user who you saved from the wrath of their boss will never forget that cancel is like a giant undo. Heck they may even come up with the scratch paper concept you describe on there own after that. So at what point in this learning curve did the user graduate from being a beginner?

>I think not informing the user that his data is about to be saved is even more confusing. For example, if someone changes data in a record, presses Next to see data in the second record, comes back to the first, make other changes, decides to undo, he will expect *all* his changes to be undone, but it has been saved when he changed record. Now the user has to know what saves his data, while an explicit save is obvious.
>
>Result: people would power off their computer if they entered the wrong data... Some already do!

The explicit save is obvious to a foxpro developer. This is a mistake of letting your development enviroment influence your user interface. I know its a record in a table, the user thinks its a notecard in an index file. I helped him think that, I built the form that way. Now its my job to protect him from my lie. Either I warn him that changing a card will permintaly save the current card. (Continue? Yes No) or I build a scheme that would allow him to undo all that changes. I built the metaphore, its up to me as a developer to protect the user from my metaphore.


>
>>a second argument not to use explicit save modes: If you prompt dialog boxes for every time there is something to save, the user don't read this messages anymore and presses ENTER or ESCAPE when he sees a dialog box. When a real important messagebox is showing the users will instinctivly press enter or escape without reading the messages.
>
>That is a Human problem, and no programming will solve it. If my program asks me if I want to delete my document and I stupidly tell him yes, how is he supposed to know I didn't want to? Maybe I shouldn't have pressed the delete key, but I don't look at my keyboard when I type, so maybe I wanted to press another nearby key, or maybe the cat jumped on my keyboard!

I disagree. If the message box is that important that the user has to read it, then the should have to read it to find out that Left Shift+End+9 will close the message box.

And if you simply escape away a messagebox after a cat hops on your keyboard, you should get what you deserve. (I am also a fan of user punishment, but thats a whole thread unto itself!)

>
>There are people that complain that there aren't enough confirmations when you try to delete a file!

And there are people that turn off all confirmation. Where do you draw the line? YOU don't. You let THE user decide.

>
>Thing is that users want the application to do what they want, not what they tell them. Sorry, but I still can't make a program that will read the user's mind.

So is this a defense that says, "The current interfaces are good enough, and if they don't work, its not my fault" Where is the responsibilty in that. Most of the developers I hang out with are not happy about most interfaces. And we are building new ones that work in completly different ways. (we do this for fun) Sometimes a concept sucks, but sometimes a concept makes its way into the main stream. (we didn't always have pageframes!)

>
>Okay, let's say we make a program that will adapt to the user: We ask questions first, then, after say, 10 times, we understand that the user always wants to save his document. Then one day, that user realizes that he doesn't want to save his document this time, but the program saves it, like every time. How mad do you think that user will be?

That would suck.
But's lets change one thing. One day the user finds an option that turns off the questions. We don't put this option on the toolbar, we hide this under two menues and a pageframe. He found it, he ACTIVELY changed it. His decision. How does that work out?

>
>>Another thing which is real popular, are the messages "Are u sure, you want to close the program ?" Yes of course i'm sure, i would not have pressed ALT+F4 if i didn't want to close this program.
>
>You'd be surprised at how many people close a program (or do an action) by accident, especially since the close button (X) in Windows 95 is so close to the Maximize button... And the mouse is nothing precise - far too easy to hit just next to your target, and produce an unwanted effect. I have sometimes selected "Save" instead of "Save As...", and I knocked my head on the wall each time!
>
>Not to speak about the times when I was thinking about something else when I selected the wrong option in a menu!

YES! That damn X button is much to close to the other two buttons. Move that baby away. Put it on the other side even :) But a "Your Closing this program, [x] Show me this again" box would work wounders.


>
>>Much of the thing we program seem so natural to us as a developer, but are really inherrited by older programming strategies which should not be used anymore. It is time to make our programs easy to use without hundreds of dialog boxes which only confuses users, let make them mistakes, and reduces productivity.
>
>... and help them realize they've made a mistake! *EVERY* error is human in origin, and the computer make those changes permanent faster than the human can realize he made a mistake.

I agree. (Most errors are human in origin though)
Rethink the user interface model from time to time.

>
>How much productivity have you gained when you just erased last month's financial transactions? Why do you think backups even exist?

This is a call for a rethinking of interfaces, not a step into idiotcy. An action that erases last months data should be protected. We could introduce the users company here, their needs out wheigh that of the user. But I am tired.

>
>>I think this book by ALAN COOPER is a real MUST for developpers who want to lear more about User Interfaces, develop strategies etc.
>
>Using Cooper's advice, there's no need for a safety belt in my car since I don't intend to crash! And there's no need for a safety lock on a firearm, since I won't press the trigger if I don't mean to shoot!

Read the book.

I would think that loosing my latest changes is not as perminate situation as death by car crash.

And I wounder how many lives have been lost to a safety lock on a gun. I imagine many a homeowner that draw their gun in defense and forget about that damn lock. I wounder how that figure compares to the number of accidental killings do to not having a lock. Maybe it really does not help?


>
>Such a philosophy makes computer far less accessible than they are. It would be: "if you don't know who to use it, don't touch it", and make exploring an application much more difficult. We've all been faced with a certain option that we couldn't figure out what it did just by the it's name, so we've tried it, and when it asked "are you sure you want to do blah blah blah?", we realized it's definitly not what we wanted, so we told him "No".

And on the 30th time we succesfully complete a task, we might choose to tell the computer "NO, I don't want to see this conformation again."

>
>Sorry, but I am certainly not going to read that book!

Then if you are not open to others opinions, why do you post on UT? Sharing ideas can only lead to better ideas.


Sylvain, I would love to carry on this debate. You have interesting viewpoints and ideas. Please, feel free to email me at srenkert@ecrsoft.com


And thats my final 2 cents.
Wow! A 4 cent post!

If you are reading this, thanks for sticking it out. Any comments and critism are welcomed.

And I have orderd the book ;)

If they have you asking the wrong questions,
they don't have to worry about the answers.
-proverbs for paranoids #3