Imran Hussain University of Management and Technology (UMT) Virtual University Human-Computer Interaction Lecture 42 Communicating with Users Imran Hussain University of Management and Technology (UMT) 1

In Last Lecture … How to ask user? How to ask experts? Asking users Interviews Questionnaires Asking experts Inspections walkthroughs

In Today’s Lecture … How to communicate with users? How to eliminate errors messages? Process of notification and confirmation Other communication with users

How we can eliminating errors?

Errors are abused Users never want error messages Users want to avoid consequences of making errors Users will often not complain about error messages

Why we have so many error messages Early days of computers, computers were operated by very technical minded people Early operators of computers were sympathetic to needs of CPU Didn’t mind error messages Abort, retry, fail? FU FU stands for file unavailable

What’s wrong with error messages What programmers think of error messages What users think of error messages Inability of a program to perform a certain function

People hate error messages Humans have emotions Get angry if they are told they are wrong Computers don’t have emotions Programmer’s therefore, have wrong assumption They think people like to be told when they do something wrong Software is interactive being

Whose mistake is it, anyway? What is conventional wisdom about error messages? They tell user when he has made a mistake What actually happens Example You are trying to enter in the date you don’t enter the date in the precise format that is required by the user What should be done then? Maybe the sequence of number is not valid Store and remind user later on – do not stop proceedings Clerk handed slightly incomplete form Error messages come from failure of software to behave reasonably Programmers don’t want to think of ways of accommodating imperfect human behaviors

Do the error messages really perform a useful task? Human makes mistakes Do the error messages really perform a useful task?

Error messages don’t work Error messages are not preventing human beings from getting into trouble They prevent program from getting into trouble

Making errors impossible Error messages are post facto reports of failure

Positive feedback Software should learn to give positive feedback

Improving error messages: The last resort Requirements for error message box Be polite Be illuminating Be helpful

2 3 4 5 6 7 1 Text in box 1 is not required, plz remove it Zoom 2 ,3,4,5,6,7 … 2,3,4,5,6 should be zoom enough to readable 7 1

Notifying and Confirming

Alert dialogs Confirmation dialogs

Alerts and confirmations notifies the user of the program’s action Confirmation gives user authority to override that action

Alerts: Announcing the obvious Alerts announce the obvious things Gives impression that they are not confident Also, makes user go to another place Example We delete a file Do we need to be told about it?

An example …

Alerts: flow-breaking behavior Alerts boxes exhibits flow-breaking behavior They causes interruptions in the flow of users tasks

1 2 Zoom 1, and then 2 ….2 should be readable

Why are alerts so common? They are easy to create Most programming languages offer a message box facility in a single line of code Building an animated status display into face of program might require thousands of line of code So, programmers have a conflict of interest

So what should be done? Software should have visual indicators

2 Data in box 1 is not required…2 should be readable 1

Confirmations Confirmation If program is not confident, it asks for approval with dialog box

Why do we get confirmations? Confirmations come from program, not user They are a reflection of implementation model

1 Zoom, it should be readable

The confirmation process Confirmations pass the buck User issues command to the computer Program detects command of the user Program doesn’t want to take responsibility for the actions and the command issued by the user Issues a confirmation

The dialog that cried, “wolf!” Users start dismissing confirmations as a matter of routine Some guidelines Should only be provided if user will click ‘no’ or ‘cancel’ Should never be provided if user will click ‘yes’ or ‘ok’

1 2 3 Zoom 1,2, 3 ….3 should be readable

Eliminating confirmation Three approaches Do, don’t ask Make all actions reversible Provide mode-less feedback to help users avoid mistakes

some examples …

2 1 Remove text in box 1 ….zoom 2 it should be readable---- zoom 3 it should also be readable 3

Replacing dialogs: Rich mode-less feedback Gives in-depth information about the status or attributes of a process or object in the current application Visual Making use of pixels on screen (often dynamically) Mode-less Information is always readily displayed, requiring no special action or mode shift on part of the user to view and make sense of feedback

1 Zoom point 1

Zoom point 1 1

Zoom point 1 1