1/27/2014

1

GUI Bloopers

Graphic Design, Layout, and Web Page/Style Design

Graphic Design and Layout Bloopers

• Once you have GUI controls appropriate for your software you have to decide on:– Layout– Colors– Fonts

• The following bloopers diminish software’s perceived quality – it only takes a few to look amateurish and untrustworthy

• Poor graphic design and layout can also decrease user’s ability and motivation to absorb the software’s content

1/27/2014

2

Blooper 32 : Easily missed information

• Software developers often assume that if information is displayed users will see it. Not so!

• Common flaw: not focusing user’s attention– People scan for information, left to right, top to

bottom– Should design for how human perception works– Examples users can miss:

• Status or mode indicators• Prompts for input• Results• Error or status messages• Controls

Blooper 32 Examples

• Information too small or not where the user is looking

1/27/2014

3

Avoiding Blooper 32

• Construct a visual hierarchy– Organize information displays in hierarchical

chunks; users ignore irrelevant chunks and find what they want much faster

• Make important information bigger

• Put important information where the user is looking– Center of field, not periphery

• Use color to highlight

Avoiding Blooper 32

• If necessary, use heavy artillery– Dialog boxes and pop-ups

• Impossible to ignore, but it better be important

– Sound• Simple beeps usually sufficient

– Vibration and animation• Peripheral vision for stationary objects is poor, but is very

good at noticing movement or changes

• Distracting if too much; have been abused by web advertisers

• Make sure animation stops quickly and can be stopped

1/27/2014

4

Blooper 33 : Mixing dialog box control buttons with content control buttons

• This happens when you add new buttons to the standard “OK”, “Apply”, “Close”, “Cancel” buttons

• Everything OK here?

Align Buttons To Controls

• It can be hard to see the connection between the new buttons and data

• Make functions clear by separating content control buttons from window control buttons

1/27/2014

5

Blooper 35: Radio Buttons too far apart

• Related radio buttons should be grouped closely together

Improved Spacing

1/27/2014

6

Blooper 35 Examples

Blooper 36 : Labels too far from data fields

• Sometimes GUI’s are developed where the label is placed too far from the control it describes

– Common in automatic layouts where size is dictated by the largest field or screen width

1/27/2014

7

Blooper 36 Example

Blooper 36 Example

• Variation: labels closer to other settings than their own

1/27/2014

8

Avoiding Blooper 36

• Don’t attach labels and data fields to opposite edges of a form or control panel

• Don’t allow a few long labels to dictate the alignment of the entire form

• Labels should be closer to their own field than to other fields

• Put labels above fields

Avoiding Blooper 36

1/27/2014

9

Blooper 38: Poor Window Location

• Where should an application’s windows first appear?

• Heuristics:

– On-screen

– Staggered

– No occlusion

Blooper 39: Tiny fonts

• Lots of people with impaired vision can’t read small fonts

– Includes old folks over 45

1/27/2014

10

Blooper 39 Example

Blooper Bonus: Un-Natural Order

• Avoid the “random” layout

Add proper tab stops, but also reorganize layout

1/27/2014

11

Top Ten Web Design Mistakes

• Jakob Nielsen’s top design mistakes

1. Using Frames 2. Gratuitous use of bleeding-edge technology 3. Scrolling text, marquees, and constantly running animations 4. Complex URLs 5. Orphan pages 6. Long, scrolling pages 7. Lack of navigation support 8. Non-standard link colors 9. Outdated information 10. Overly long download times

GUI Interaction Bloopers

• More important than GUI control, navigation, text, and graphic design/layout bloopers:

– Larger in scope, often generalizations of specific look-and-feel bloopers

– Harder to identify

– Harder to avoid

• Often a result of decisions made in the bowels of implementation

– Harder to correct

1/27/2014

12

Blooper 40: Exposing implementation to users

• Users should not be subjected to internal implementation details when they are contrary to their working model

• Examples:– Speed in a game a setting from 1 to 10

• Expect 10 to be fast and 1 to be slow, but it was the opposite• Delay loop for the setting’s number of times

– Limits on data sizes to “weird” numbers• 16, 32, 64, 128, etc. • Most people would prefer 10, 100, 1000, etc.

• Design for the convenience of users, not developers

Blooper 40 Example

• X values of graphs convenient for developers (intervals of max/10) but not for users

1/27/2014

13

Avoiding Blooper 40

• Focus the user interface strictly on the tasks

– Design the UI according to a conceptual model that includes only objects, actions, and attributes from the app’s target tasks

• Design for the convenience of users, not developers

– Requires extra work for the developers, but hopefully they take pride in making software that is easy to use!

Blooper 41: Needless restrictions

• Needless restrictions, like unnatural actions, are hard to learn, easy to forget, and annoying

Why is Rumpelstiltskintoo long? Probably some arbitrary database limitation, perhaps set to 10 characters.

More common limitations would be some power of 2; e.g. 32 or 64 char limit

1/27/2014

14

Blooper 41 Examples

Avoiding Blooper 41

• Don’t impose numerical limits, if possible

– Use dynamic allocation of storage

• Use powers of 10 not powers of 2

1/27/2014

15

Blooper 43 : Asking users for unneeded data

• This is a sure way to annoy users

• Variations:

– We forgot, tell us again

– Unnecessary questions

– Requiring data that should be optional

– Requiring repeated logins in a session

Blooper 43 Example

1/27/2014

16

Blooper 43 Example

Avoiding Blooper 43

• Make it a high priority NOT to require users to enter data repeatedly.

– Ask only for data you really need

– Stick to the current transaction

– Don’t make any data “required” unless you really can’t proceed without it

– Don’t require data some customers won’t have

– Deduce as much as you can from information given to you instead of adding additional fields

1/27/2014

17

Blooper 45 : Pointless choice

• A second special case of requiring users to enter unnecessary data is presenting data with unnecessary choices

– No difference between choices

– Users don’t know which to pick

– Obvious answer

– False choice

Blooper 45 Example

1/27/2014

18

Blooper 45 Example

Blooper 45 Example

1/27/2014

19

Avoiding Blooper 45

• If the choice makes no difference, don’t offer it

– How do you know? Test it!

– Watch people using your software

• If users won’t understand the question, don’t ask

• If there is an obvious option, choose it

• Don’t offer false choices

Blooper 47 : Mission Impossible Instructions

• Instructions that go away too soon

• Detailed instructions should remain on the screen while the user is carrying them out

– Latest Office apps display help in right hand pane

1/27/2014

20

Blooper 47 Example

Blooper 48: Unnecessary or poorly marked modes

• If your software has modes, users may not know which mode they are in and enter a command meant for the inactive mode

• Examples:– Try to drag a rectangle to select objects but end

up drawing a line instead

– Printer outputs in landscape instead of portrait

1/27/2014

21

Many harmless modes

• Word is teeming with modes– View: Normal, outline, page layout

– Auto correct: on, off

– Insert or overwrite text

– Auto save: on, off

– Smart cut-and-paste: on, off

– Etc.

• Most of these modes don’t cause errors because they are rarely changed from defaults– Many users may not even know of these modes

Toasters have modes

• The “darkness” control on a toaster is a mode that sometimes results in burnt toast when the last time you put in a frozen waffle

• How could you make a modeless toaster?

1/27/2014

22

Avoiding Blooper 48

• Remove or minimize mode settings

– E.g. for a photo application instead of a mode for “browse” and a mode for “edit” there might be separate windows for each

• Minimize the use of modal dialog boxes unless it is crucial the users not interact with things on the display

• Make modes visible and difficult to miss

Blooper 49: Unexpected Rearrangement of Display

• What if the OS constantly rearranged your icons for you?

• Example

1/27/2014

23

Blooper 50: Dialog Boxes that Trap Users

• Dialog boxes sometimes provide no way out other than a direction that users don’t want to go.

– No cancel

– All paths are wrong

– Required button is inactive

– Unclear choices

– No, not OK

Blooper 50 Example

• No Cancel

• No, Not OK!

1/27/2014

24

Click Back

Wrong paths in the dialog box

Required button is inactive

1/27/2014

25

Avoiding Blooper 50

• Provide users with alternatives so they don’t feel trapped

• Analyze goals users could have when the dialog box appears so you can provide the right options

• Test dialog boxes with users

• Don’t use “OK” for bad messages

– “Acknowledged”, “Understood”, “Sigh…not again”

Responsiveness Bloopers

• Responsiveness not the same as performance or speed

• Highly responsive software– Lets you know immediately that your keystrokes, mouse,

and clicks were received

– Estimates how long operations will take

– Frees you to do other things while waiting

– Manages queued events intelligently

– Performs housekeeping and low-priority tasks in the background

– Anticipates your requests

• Can be highly responsive but slow

1/27/2014

26

Responsiveness Bloopers

• Hard to show screenshots since responsiveness requires a time-lapse capture or movie

• Bloopers are closely related, so mostly some lists

Bloopers 52-55

• Blooper 52: Cursor doesn’t keep up with you; it jumps around and keeps moving after you stop the mouse

• Blooper 53: On-screen buttons acknowledge clicks too late or not at all

• Blooper 54: Menus, sliders, scrollbars lag behind actions, destroying hand-eye coordination for successful operation

• Blooper 55: Moving and sizing operations don’t keep up with your actions and don’t provide temporary “rubber-band” feedback

1/27/2014

27

Bloopers 56-59

• Blooper 56: Application doesn’t indicate that it is busy; it just ignores you

• Blooper 57: Application occasionally – and unpredictably – is unresponsive while it does internal housekeeping

• Blooper 58: Long operations don’t display progress

• Blooper 59: Long operations provide no way to cancel

Responsiveness Blooper Example : Waiting

• Let the user know when the system is busy

• Without it the user may think the application is locked up, submit data multiple times, kill it

1/27/2014

28

Phony Progress Bars

Reasons for poor responsiveness

• UI designers rarely consider responsiveness during design

• Programmers don’t know how important responsiveness is

• Programmers equate responsiveness with performance– e.g. better algorithms or data structures

• Programmers treat user input like machine input– Doesn’t always have to be processed in the order received

• Developers use simple implementations

1/27/2014

29

Reasons for poor responsiveness

• GUI software tools, components, and platforms are inadequate

– Normally not the default for a multi-threaded wait cursor

• Managers hire GUI programmers who lack the required skill

Avoiding Responsiveness Bloopers

• Principle 1: Responsiveness is not the same as performance

• Principle 2: Processing resources are always limited– Users try to do more as CPU speeds increase

– Customers probably have slower computers than developers

• Principle 3: The user interface is a real-time interface

1/27/2014

30

Avoiding Responsiveness Bloopers

• Principle 4: All delays are not equal: software need not do everything immediately

• Principle 5: Software need not do tasks in the order in which they were submitted

• Principle 6: Software need not do everything it was asked to do– Sometimes an operation is not necessary; e.g. if told

to save but nothing has changed there is no need to waste time re-saving it

– Queued task may become moot

Avoiding Responsiveness Bloopers

• Principle 7: Human users are not computer programs

– Cannot sustain high rates of input for very long; can keep the system busy for several seconds but then must pause to think or rest

– Can multi-task depending on tasks

– When buttons don’t acknowledge a click immediately, users assume they missed and click again

1/27/2014

31

Management Bloopers

Management Bloopers

• GUI bloopers are not always the programmers fault; sometimes management is to blame for creating adverse circumstances

• Example: Smooth over problem of the moment

– Call in a UI consultant with no mandate or resources to correct a flawed process and attitudes

– “Smearing lipstick on a bulldog”

1/27/2014

32

Blooper 64: Treating UI as a low priority

• Usability often has a lower priority over other tasks

• Variation A: Assuming that usability has low impact on market success by focusing on time to market, not time to profitability

Blooper 64

• Variation B: Assuming that the UI is only “fonts and color”

• Variation C: Assuming that users can adapt to anything– Just because people can doesn’t mean they will

• Variation D: Rationalizing– UI not a product feature that can be dropped to meet

a deadline

• Variation E: Assigning the GUI to junior programmers

1/27/2014

33

Avoiding Blooper 64

• Management should make it a high priority to develop products that have high-quality user interfaces– Usability has a powerful impact on the product’s

success– The UI is about “deep” issues not just fonts and colors– Users can adapt to bad UI’s but banking on that is

foolish– The UI can’t be dropped to meet a schedule or budget

constraint– Experience matters

Blooper 65 : Misunderstanding what user interface professionals do

• Many people don’t know what usability professionals actually do

• GUI programmers are GUI designers?– Programmers know how to write code using

controls, menus, etc. but not necessarily how to design the interface and in fact can produce bad GUI’s

• Graphic designers are GUI designers?– Appearance vs. usability

1/27/2014

34

Avoiding Blooper 65• Know the roles of different designers and programmers

Blooper 66: Discounting the value of testing and iterative design

• Some managers don’t see the need for usability testing or significant UI revisions

• Variation A: Agile/XP/Scrum in name only• Variation B: Good designers don’t need iteration

– Testing and revision best way to reduce risk

• Variation C: We don’t have the luxury of usability testing– Myths: expensive, skipping testing will save money

• Variation D: Allowing no time to fix usability problems

1/27/2014

35

Avoiding Blooper 66

• UI design is not a mystical art based on innate talent and flashes of creativity but a learned engineering discipline.– Industry standards, best practices

– Scientific basis in human perception, motivation, information processing

– Need for clear requirements

– Working with constraints and trade-offs

– Generation and consideration of design alternatives

– A need to test, evaluate, and revise

Blooper 67: Anarchic Development

• Anarchic: uncontrolled, unrepeatable, driven by individual whim and crisis of the moment rather than proven, repeatable practices

• Variation A: No design

– Fooling self that you’re doing Agile Methodology but not doing weekly scrums, discussing/testing designs for the next cycle, no quick tests, not getting feedback

• Variation B: No standards or guidelines

1/27/2014

36

Blooper 67: Anarchic Development

• Variation C: No oversight

– “Hire nerds, tell ‘em what you want, lock ‘em in their offices, and throw in pizza and t-shirts every few weeks”

Avoiding Blooper 67

• User-centered design and agile methods coexist

1/27/2014

37

Avoiding Blooper 67

• Quality UI’s require investment

– Training, hiring, developing UI style guides or standards, usability tests, etc.

• Give UI experts more clout

• Take responsibility

Blooper 68: No task expertise on the team

• Projects require someone with a solid understanding of the target task

• Developers may assume they are task-domain experts

• Developers sometimes discount users’ task knowledge

• Importing task expertise is hard

1/27/2014

38

Blooper 69: Using poor tools and building blocks

• If using a GUI toolkit, does it really include usability for the GUIs that can be built? Managers and developers focus on:– Ease of use

– How quickly GUIs can be developed

– How easy the resulting GUI is to maintain

– Compatibility with existing tools, development process

– Cost

– Prior experience with the tool or similar tools

Blooper 69

• Managers should also consider the usability list as factors in adoption of a tool:– How compliant are GUIs developed with the tool for

standards on the target platform?

– Are the GUIs developed sufficiently responsive?

– Does the tool allow appearance details to be fine-tuned to conform to an apps look and feel?

– How easy GUIs can be internationalized and localized?

– How accessible GUIs can be to various users such as the disabled?

1/27/2014

39

Blooper 70: Giving programmers the fastest computers

• A cause of responsiveness bloopers

• Programmers’ systems will be faster than those of most customers, giving the latest hardware and net connections gets them accustomed to frequent upgrades and view performance/response problems as temporary until “the next upgrade”

Net connections

• Most people finally have broadband but around 30% still have none

1/27/2014

40

Avoiding Blooper 70

• Don’t be too quick to upgrade programmers’ computers

• Test on slower computers

• Test on slow network connections

• Compromise: Get developers a fast development machine and a “slow” test machine