1. 1. GUI Control Bloopers
   1. Using the wrong GUI control
      1. Confusing checkboxes and radio buttons
         1. Radio buttons
            1. Radio buttons are for presenting one-from-N choices. They are best suited when two conditions hold:
            2. The number of options is fixed and small: between two and eight.
            3. Enough space is available on the panel to display all of the options.
            4. Radio buttons always occur in sets of at least two; a single radio button is not a valid control.
            5. avoid
            6. Dropdown menus are best suited when space is limited and the number of options either is greater than eight or changes at runtime.
            7. Scrolling list boxes is also a replacement, but consume significant space.
            8. Spin boxes and Cycle buttons are suited to presenting choices in limited space with few options.
            9. Radio buttons are always auto-sized. In localization leave enough space at the end of one radio button. Vertical radio button list is better than horizontal radio button list.
         2. Checkboxes
            1. Refuse to turn options ON when that would exceed the group maximum. Notify users by beeping, displaying an error message, or both.
            2. Allow users to turn any number of items ON, and inform them later that the number of selected options exceeds the maximum.
         3. avoid
            1. Treat checkboxes and radio buttons as distinct control types;
            2. Treat a group of radio buttons representing a choice as a single control;
            3. Treat radio button sets, dropdown menus, and scrolling lists as different presentations of a single one-from-N choice control type
      2. Using a checkbox for a non-ON/OFF setting
      3. Using command buttons as toggles
      4. Using tabs as radio buttons
         1. Tabs are purely navigation controls.
         2. progressive disclosure (for example: use radio buttons or dropdown menus to dynamic show/hide details)
      5. Too many tabs
         1. Wrong
            1. One false solution is to widen the panel to allow more tabs.
            2. A second false solution is to put tabs on more than one edge
            3. Short labels (It also cause hard to localize.)
            4. Break their labels into two lines
            5. Dancing tabs (people do not like multiple rows of tabs.)
         2. Right
            1. Keep the number of tabs small
            2. Use another control instead of tabs
            3. Widen panel slightly
            4. Never use dancing tabs
      6. Using input controls for display-only data
         1. Noneditable data should never be displayed in a control that looks editable or operable.
         2. Checkboxes, radio buttons, menus, sliders, and the like should never be used for noneditable data because they look operable.
         3. A necessary evil: scrolling text boxes for long noneditable texts
            1. received e-mail messages displayed by e-mail software;
            2. software license agreements displayed during installation of desktop software;
            3. usage policies, user agreements, contracts, and other legal documents displayed by membership and e-commerce Web sites.
      7. Overusing text fields for constrained input
         1. Use text fields sparingly
         2. Use validator to validate text
         3. Alternatives to text fields
         4. Another approach is to use multiple text fields and pay attention to the details (for example the Tab key and Backspace key)
   2. Using a control incorrectly
      1. Dynamic menus
         1. Dynamic activate and deactivate menu items
         2. Dynamic add and remove menus, not menu items
      2. Intolerant data fields
         1. Match field length to data
            1. long enough to hold data
            2. not a lot longer than that
         2. Accept common formats and your own formats
         3. Beware of rejecting legitimate data
         4. Make letter case irrelevant
         5. Provide a pattern
         6. Structure text fields
      3. Input fields and controls with no default
         1. Text and number fields
         2. Radio buttons with no initial value should be avoided. Use only if you have strong justification. Radio buttons in survey with unbiased default value.
         3. Dropdown menus
         4. When no default can be assumed, menus are better than radio buttons
      4. Poor defaults
         1. Common sense
         2. Business logic
         3. Experience and site data
         4. Individual users’ data
      5. Negative checkboxes
2. 2. Navigation Bloopers
3. 3. Textual Bloopers
4. 4. Graphic Design and Layout Bloopers
5. 5. Interaction Bloopers
6. 6. Responsiveness Bloopers
7. 7. Management Bloopers
8. 8. Color Bloopers
9. First Principles
   1. 1. Focus on the users and their tasks, not on the technology
      1. What does “focus on users and their tasks” mean?
         1. For whom is this software being designed? Who are the intended users? Who are the intended customers (not necessarily the users)?
         2. What is the software for? What activity is it intended to support? What problems will it help users solve? What value will it provide?
         3. What problems do the intended users have now? What do they like and dislike about the way they work now?
         4. What are the skills and knowledge of the intended users? Are they motivated to learn? How? Are there different classes of users, with different skills, knowledge, and motivation?
         5. How do users conceptualize the data that the software will manage?
         6. What are the intended users’ preferred ways of working? How will the software fit into those ways? How will it change them?
      2. Understand the users
         1. Decide who the intended users are
         2. Investigate characteristics of the intended users
         3. Users: Not Just novice vs. experienced
            1. General computer savvy
            2. Task knowledge
            3. Knowledge of the system
         4. Collaborate with the intended users to learn about them
         5. Bringing it all together
      3. Understand the tasks
         1. Decide what set of tasks to support
         2. Investigate the intended tasks
         3. Collaborate with users to learn about the tasks
         4. Bringing it all together
      4. Consider the context in which the software will function
   2. 2. Consider function first, presentation later
      1. What it does mean?
         1. What concepts will be visible to users?
         2. What data will users create, view, or manipulate with the software?
         3. What options, choices, settings, and controls will the application provide?
      2. Develop a conceptual model
      3. Task focused
      4. Perform an objects/actions analysis
      5. Example objects/actions analyses
      6. Object relationships
      7. Develop a lexicon
      8. Write task scenarios
      9. Base UI design on the conceptual model
      10. Objects/actions analysis can kick-start development
      11. Conceptual model focuses design process
   3. 3. Conform to the users’ view of the task
      1. Strive for naturalness
         1. Don’t make users commit unnatural acts
         2. Imposing arbitrary restrictions
      2. Use users’ vocabulary, not your own
      3. Keep program internals inside the program
      4. Find the correct point on the power/complexity trade-off
         1. Sensible defaults
         2. Templates or canned solutions
         3. Guided paths–wizards
         4. Progressive disclosure
         5. Generic commands
            1. Create
            2. Open
            3. Move
            4. Copy
            5. Save
            6. Delete
            7. Print
            8. Edit
            9. Update
            10. Find
            11. Show/Edit Properties
            12. Follow Link
            13. and so on...
         6. Task-specific design
         7. Customizability
   4. 4. Design for the common case
      1. Make common results easy to achieve
      2. Two types of “common”: “how many users?” vs. “how often?”
         1. How many users will need the feature?
         2. How often will users need the feature?
         3. The more frequently a feature will be used, the fewer clicks it should require
         4. The more users will use a feature, the more visible it should be
         5. Combinations: frequent by many, frequent by few, infrequent by many, infrequent by few
      3. Design for core cases; don’t sweat “edge” cases
         1. It takes development time and resources away from designing good UIs for the common cases.
         2. It burdens the entire UI with having to cover “edge” cases as well as common ones.
   5. 5. Don’t complicate the users’ task
      1. Don’t give users extra problems
      2. Don’t make users reason by elimination
         1. The functions of controls, commands, and settings in a user interface should be clear and obvious.
   6. 6. Facilitate learning
      1. Think “outside-in,” not “inside-out”
      2. Consistency, consistency, consistency
         1. Consistency avoids “gotchas”
         2. Dangers of naive consistency
            1. Difficult to define
            2. Multidimensional
            3. Subject to interpretation
         3. Consistency is good anyway
         4. Making consistency user-centered
      3. Provide a low-risk environment
   7. 7. Deliver information, not just data
      1. Design displays carefully; get professional help
         1. Visual order and user focus
         2. Scannability
         3. Match the medium
         4. Attention to detail
      2. The screen belongs to the user
         1. jump or “warp” the mouse pointer to new positions,
         2. move controls to the pointer,
         3. reposition, stretch, or shrink windows.
      3. Preserve display inertia
         1. foster users’ perception and comprehension of the changes
         2. minimize disruption to users’ ability to continue working
   8. 8. Design for responsiveness
      1. What is responsiveness?
      2. poor responsiveness
         1. Delayed feedback for button-presses, scrollbar movement, or object manipulations
         2. Time-consuming operations that block other activity and cannot be aborted
         3. Providing no clue as to how long lengthy operations will take
         4. Jerky, hard-to-follow animations
         5. Ignoring user input while performing “housekeeping” tasks users did not request
      3. Responsiveness on the Web: Poor but improving
      4. Designing for responsiveness
         1. acknowledge user actions instantly, even if returning the answer will take time;
         2. let users know when it is busy and when it isn’t;
         3. free users to do other things while waiting for a function to finish;
         4. animate movement smoothly and clearly;
         5. allow users to abort lengthy operations they don’t want;
         6. allow users to judge how much time operations will take;
         7. do its best to let users set their own work pace.
   9. 9. Try it out on users, then fix it!
      1. Test results can surprise even experienced designers
      2. Schedule time to correct problems found by tests
      3. Testing has two goals: Informational and social
      4. There are tests for every time and purpose
10. What is a GUI blooper?