GUI Bloopers Chapter 5: Interaction Bloopers

1. GUI Bloopers Chapter 5: Interaction Bloopers By Matt Hepburn and Justin Kirk

2. Introduction • The bloopers covered in this section are very important, more so than the others so far. • They are larger in scope. • Harder to spot • Harder to avoid • And harder to correct

3. 5.1 Allowing Implementation to dictate GUI.

4. Blooper 43: Exposing the Implementation to Users

5. Variations of how programmers do this: • Forcing a user to think like a programmer. Truth is, most users don’t understand the programmer’s mind at all. • Imposing arbitrary implementation restrictions on users. • Avoiding the blooper. • Design for the convenience of users, not developers. • Avoid arbitrary limits.

6. Blooper 44: Asking users for random numbers.

7. Why don’t programmers ask for random numbers? • As a user, people aren’t very good at coming up with truly ‘random’ numbers. • Usually, an odd number will be given when getting input from the user because people don’t see even numbers as being random. • 37 is the most common number said when asked for a random number between 1 and 100.

8. Avoiding This Blooper Base the random seeds on variable time intervals. Give the users only the control that they need. Games often need random seeds, but don’t ask users for them.

9. Blooper 45: TTY GUIs

10. Problems: • A lot of things arise when programmers try to put the programs that were written when there was only command line to a GUI. • People often forget things that they type and don’t get to review them. • They can’t go back sometimes to make changes if they typed something wrong.

11. Avoiding The Blooper:GUI vs. TTY UI Who is driving? See and point vs. remember and type • Remember that the user is controlling the interface. • It needs to interact with them. Make changes easily. • The user can make whatever change they want and in whatever order they want. • Get the see and point because it’s much more user friendly. • The user doesn’t have to hit extra keys. • The mouse is easier to get around with for people that are used to it.

12. Wrong way and right way to implement a TTY conversion

13. 5.2 Presenting Information Poorly

14. Blooper 46: Overwhelming users with decisions and detail

15. There are 4 ways of getting this blooper. • Choices users don’t need or want • Little or no user input • Focus on the implementation • Inability to make decisions • Many Controls, all equally accessible • Controls and Choice Presented in an unnatural order • No defaults or wrong defaults. Users must set everything.

16. How to avoid this blooper • Emphasize important controls and deemphasize less important ones. • Allow users to refer to collections of settings • User progressive disclosure • Allow users to rely heavily on defaults. • Don’t make up settings, find out what users really need. • Test the design with a cognitive walkthrough.

17. Blooper 47: Easily Missed Information

18. Types of things that are commonly overlooked. • Status indicators • Mode indicators • Prompts for input • Results • Error and Status Messages • Controls

19. Why people miss things • The things that people want to show are too small and/or plain. • The buttons/text/picture/link is not where the user is looking. • It could be buried in sameness. • It changes too quickly. • Hard to understand.

20. Where could having graphics instead of text come in handy?

21. How to avoid this blooper • Remember that bigger is better. The more important, it needs to stick out. • Place important info close to where the user is looking. • Boldness, density, saturation. • Sound • Color • Vibration and animation. • Don’t bury the wheat in the chaff.

22. Blooper 48: Unexpected rearrangement of display

23. Examples of moving the display • Always trying to make a tree “look balanced” • Changing data doesn’t mean move a whole chart around after words. • Changing a graphic automatically puts it on the top. • Editing, deleting, and adding data rearranges everything, when it doesn’t need to do that.

24. This happens for 1 of 2 reasons • Either it was designed by some well-meaning naïve developers. • Or there was some very overly simple implementation.

25. What are some different errors that you can find in this pictures.

26. How can you avoid blooper 48: • By remembering that the screen belongs to the user. They think that they control the screen because they have the mouse. • You also have to preserve display inertia. • When the user changes an option, that should be the only thing that changes. Nothing else should move.

27. Blooper 49: Instructions that go away to soon.

28. This blooper is a pain if not taken care of properly. • One of the biggest examples of this could be a dialog box for directions that doesn’t stay up. You have to close it before you can go on. • This is a hassle because someone will not have a good enough memory to hold the steps in.

29. The easiest way to fix this: • Detailed instructions should remain displayed while the user is working on that particular thing.

30. Stumbling Blocks Setting For users

31. Blooper 50: Similar functions with inconsistent user interfaces

32. Shouldn’t similar functions work similarly? • Command Syntax matters! • Don’t use noun-verb syntax in some places if your going to use verb-noun syntax in other places • If you can delete some things in a certain way you should be able to delete all things that way

33. Discussion Question • Why is there a cancel button in one dialog box but the other one says to “Click elsewhere to cancel”? • Most likely poor communication • Perhaps a single programmer simply started hacking code rather than creating a conceptual design

34. How do we avoid this mishap? • Encourage programmers to communicate effectively with each other, and to communicate with a common goal • Provide oversight by project managers, architects, and user interface designers • Develop a conceptual model before starting to code the user interface • Examples of two highly consistent UI’s are Star and Lisa • They were expensive, slow, and didn’t really have a good marketing niche, but they are still the best examples of interface consistency

35. Blooper 51: Unnecessary or poorly marked modes

36. Isn’t it frustrating when a program doesn’t do what you want it to? • Being in the wrong mode when we want to edit something is a problem we’re all familiar with • These bloopers range from simple printing mistakes (landscape instead of portrait) to expensive mistakes when stocks are bought when the order is only meant to have been submitted • Too many modes detract from a products usability

37. Examples of bad moded software • Drilling up and down in tables controlled by a direction property • It is much easier to remember what mode you are in if each mode is achieved by pressing different keystrokes • Although it seems like a great idea to programmers, modes can be a great nuisance to the people who have to actually use the programs

38. Submit Order Mode Blooper Terrible ------------> Better, but a new button would really be best

39. Different degrees of “modalness” • There are three degrees of modalness that a dialog box can exhibit • Parent Modal • Block interaction with parent window, allow all other • Application Modal • Block interaction with the rest of the application • System Modal • Block interaction with everything

40. How should modes be properly used? • Eliminate extraneous modes by removing mode settings • Drill up and down • Assign separate keys to separate functions • Submit order mode • Create a new button rather than a mode changing checkbox • Good modal usage: • Modeless: Most of the time • Parent Modal: As necessary • Application modal: Occasionally • System Modal: Hardly Ever

41. How should modes be properly used? • Avoid forced sequences or temporary restrictions on user actions • Do this by: • Not requiring user actions to occur in a predetermined order • Don’t temporarily limit valid actions • Although modes can create problems, getting rid of them is not practical • Mode free interfaces are nearly impossible to create

42. Vs. Disadvantages Advantages • Terser control • Smaller command vocabularies • More guidance for users • Safety • Recognizing exceptional operations • Users Must • Preplan mode settings • Set modes • Remember current mode • Recover from mode errors • Yield to the software’s control

43. Make mode indicators extremely difficult to miss • Unless it is very obvious to a user what mode they are in, such as how they are viewing files in Windows Explorer, the mode needs to be clearly stated Having obscure icons in hard to see places does not count as “difficult to miss”

44. Blooper 52: Installation Nightmares

45. Installing things is easy…right? • Well… not always • We as programmers many times take for granted a certain level of comfort with technology • Many people will not use new software simply because they are unable to get it installed properly • Most people will give up after only 20 minutes of attempting to make software work on their machines • Labeled the shame of the computer industry

46. So how do we make installations easier? • The industry must give high priority to improving customers’ installation experiences • User interface professionals must take an interest in installation • Best changes to make: • Make installations a single file that can be executed and doesn’t require a lot of input from the user in order to correctly configure itself

47. Diabolical Dialog Boxes

48. Blooper 53: Too many levels of dialog boxes

49. Do you look at the bigger picture? • GUI developers many times focus on individual pieces of their software, not looking at the project in its entirety • This can lead to menu’s and options that can only be accessed through a string of several dialog boxes • This leads to confusion and the inability of users to fully utilize the software

50. Microsoft at it’s best I know it’s hard to believe that Windows 98 would betray us, but here it is, a string of dialog boxes that goes 5 levels deep