1. 1CS 338: Graphical User Interfaces. Dario Salvucci, Drexel University. Lecture 16: Eliminating Errors

2. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Errors and Dialogs Dialog errors interrupt flow Do users want error messages? Users, when given choices, might want to avoid any error! – This isn't the same from wanting errors Users find it easier to blame themselves for problems coming up in the applications. – Is this the type of message you want to convey?

3. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 History of Error A history or error is important to understand why they are in such modal format today. 1950-1970: CPU cycles more expensive than Human cycles – CPUs were large, in gymnasium sized buildings, on university campuses ryhming with “ten”. 1970s: CPU cycles become just as expensive as a human cycle 1975 and later: CPU cycles much less expensive, but errors still remain.

4. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Is it an error? Most errors in dialog boxes really arent an error. Programmer: “I'll put this in a dialog box to ask or inform the user.” User thinks there is some serious problem when actually its just the program being inflexible. Users are human, and humans have emotions and feelings. Humans don't like modal error, makes them angry or embarassed.

5. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 People don't like being Wrong! Programmer: User should be informed that his action was wrong! Humans don't like being told their wrong. – They may blame many other entities before they think that they are wrong. Humans definitely don't like being embarrased! But whose mistake is it? Clearly computers may actually have user error some times, but is it always the human's fault?

6. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Lets play the blame game Computer: User's fault for having input in this manner. User should know how to use the application. User: The choices and effects were not clear to me. The computer should have made them so. Computer: You gave me the wrong validation code, stop right now and give me the right one. User: That wasn't a bad code, you didn't say you didn't want spaces!

7. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Compensating error, being flexible Instead of forcing modal error, consider: – User might not have all information – User might not have understood clearly Not all information at hand: – Guess intelligently, but indicate the guess. – Allow multiple entries for guesses. Not understanding the interface: – Its the interface design's fault, the process is suppose to give insight to the user. – Try for interface to ask for forgiveness and to have ample help to indicate what it really means.

8. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Error Messages, not errors! Error messages are really showing signs of inflexibility. Error messages can come and go, but they don't prevent the user from making an error. – How would modal “Error in stop bit 5.” help the user from making that error? Users make plenty of real user error without any of these windows existing.

9. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Eliminating Error Messages Real errors should be from serious error. Software must assume that the user is correct. – The user is simply more important! Don't reject the input if a certain module of code has it in improper format. Instead: Reconcile and Understand

10. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Make Error a Mission Impossible Don't give the user an opportunity to enter the wrong type of information. If you can: Make the user select the input. – We talked about proper selection methods! This means: user can not enter bad state. Error: “Invalid entry, You should type ABC.” – If program knows ABC, then put it in itself. This is much harder on the programmer, but who really is more important?

11. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Understanding Error Rationale Users don't care about programmers. Sorry, guys. If it works, then who cares. Users do care about programs not dealing with problems rationally. – Each successive choice in modal format brings despair to the user. – Modal dialogues might say, “Heres all this bad stuff that just happened, and hey all you can do is just acknowledge it. Sorry, have a nice day.”

12. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Positive Feedback If a program can report the bad so well, make it also report the good! This takes away from the negativity of the program's temperment. Users like it when they see approval in the software if they achieved a goal. – Acknowledgement – Reward? Helping people means positive response. Negative is punishment, reserved for discipline. Who likes being disciplined by a machine?

13. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Last Resorts Error Message boxes that MUST be given should have the following components: Polite: This is a user you're talking to. Don't say that the user caused the problem, ever. Protect the user from harming themselves. Illuminating: Program's responsibility to take a good stab as to what it thought was inappropriate, and confess. Helpful: Give possible solutions to what the error could possibly be. Give a path to that solution for the user to take.

14. CS 338: Graphical User Interfaces. Michael Czajkowski, Drexel University.1 Class Exercise Lets do a group exercise. Get into groups of 3 or 4. I will give you all a scenario to read and your job is to design the best possible error. The setting: Prexel University's administration office. Who the user is: A busy, underpaid accountant who balances the books of Prexel. Situation: The user needs to print a report out and deliver it by the end of the day. Problem: The printer goes down.