GUI Design Principles

Transcription

1 GUI Design Principles

2 User Interfaces Are Hard to Design You are not the user Most software engineering is about communicating with other programmers UI is about communicating with users The user is always right Consistent problems are the system s fault but the user is not always right Users aren t designers

3 User Interfaces are Hard to Build User interface takes a lot of software development effort UI accounts for ~50% of: Design time Implementation time Maintenance time Code size

4 Usability Engineering Is a Process

5 Design Task analysis Know thy user Design guidelines Avoid bonehead mistakes May be vague or contradictory

6 Implement Prototyping Cheap, throw-away implementations Low-fidelity: paper Medium-fidelity: HTML, Visual Basic GUI implementation techniques Input/output models Toolkits UI builders

7 Evaluate Evaluation puts prototypes to the test Expert evaluation Heuristics and walkthroughs Predictive evaluation Testing against an engineering model (simulated user) Empirical evaluation Watching users do it

8 Iterative Design

9 Help and Documentation Users don t read manuals Prefer to spend time working toward their task goals, not learning about your system But manuals and online help are vital Usually when user is frustrated or in crisis Help should be: Searchable Context-sensitive Task-oriented Concrete Short

10 Visibility of System Status Keep user informed of system state Cursor change Selection highlight Status bar Don t overdo it Response time < 0.1 s: seems instantaneous s: user notices, but no feedback needed 1-5 s: display busy cursor > 1-5 s: display progress bar

11 Error Reporting, Diagnosis, Recovery Be precise; restate user s input Not Cannot open file, but Cannot open file named paper.doc Give constructive help why error occurred and how to fix it Be polite and nonblaming Not fatal error, not illegal Hide technical details (stack trace) until requested

12 Usability The term usable means it must do what the user wants (most important). quick to use relatively error-free. easy to learn (least important).

13 9 Principles #1: Focus on the users and their tasks, not on the technology #2: Consider function first, presentation later #3: Conform to users view of the task #4: Design for the common case #5: Don t distract users from their goals #6: Facilitate learning #7: Deliver information, not just data #8: Design for responsiveness #9: Try it out on users, then fix it

14 Basic Principle #1: Focus on the users and their tasks, not on the technology Understand the users Decide who the intended users are Investigate characteristics of the intended users Users: Not Just novice vs. experienced Collaborate with the intended users to learn about them Understand the tasks Decide what set of tasks to support Investigate the intended tasks Collaborate with users to learn about the tasks Consider the context in which the software will function

15 Basic Principle #2: Consider function first, presentation later does NOT mean design and implement the functionality first and worry about the UI later. don t jump right into GUI layout Develop a conceptual model

16 Basic Principle #2: Consider function first, presentation later Develop a conceptual model a conceptual model a model of an application that the designers want users to understand (as simple as possible, the fewer concepts the better) Task focused - The more direct the mapping between the system s operation and the tasks it serves, the greater the chance that your intended conceptual model will be adopted by the users Perform an objects/actions analysis - This specifies all the conceptual objects that an application will expose to users, the actions that users can perform on each object, the attributes (user visible settings) of each type of object, and the relationships between objects Object relationships - Conceptual objects may be related to each other in several ways Develop a lexicon - defining the terminology to be used throughout the software and its documentation Write task scenarios - developers can write use cases or task scenarios depicting people using the application, using only terminology from the conceptual model Base UI design on the conceptual model - The user interface should be based on the conceptual model. It translates the abstract concepts of the conceptual model into concrete presentations, controls, and user actions. Scenarios can then be rewritten at the level of the user interface design.

17 Basic Principle #3: Conform to the users view of the task Find the correct point on the power/complexity trade-off Strive for naturalness Use users vocabulary, not your own Keep program internals inside the program

18 Basic Principle #4: Design for the common case Make common results easy to achieve Two types of common : how many users? vs. how often? The more frequently a feature will be used, the fewer clicks it should require The more users will use a feature, the more visible it should be Combinations: frequent by many, frequent by few, infrequent by many, infrequent by few Design for core cases; don t sweat edge cases

19 Basic Principle #5: Don t distract users from their goals Don t give users extra problems Don t make users reason by elimination

20 Basic Principle #6: Facilitate learning Think outside-in, not inside-out Example: Textual ambiguity Example: Ambiguous button label Example: Graphical ambiguity Consistency, consistency, consistency Provide a low-risk environment

21 Basic Principle #7: Deliver information, not just data Design displays carefully; get professional help The screen belongs to the user Preserve display inertia

22 Basic Principle #8: Design for responsiveness What is responsiveness? Designing for responsiveness acknowledge user actions instantly, even if returning the answer will take time; let users know when it is busy and when it isn t; free users to do other things while waiting for a function to finish; animate movement smoothly and clearly; allow users to abort lengthy operations they don t want; allow users to judge how much time operations will take; do its best to let users set their own work pace.

23 Basic Principle #9: Try it out on users, then fix it! Test results can surprise even experienced designers Schedule time to correct problems found by tests Testing has two goals: Informational and social There are tests for every time and purpose

24 Usability Example The first clue that there might be a problem here is the long help message on the left side. Why so much help for a simple selection task? Because the interface is bizarre! The scrollbar is used to select an award template. Each position on the scrollbar represents a template, and moving the scrollbar back and forth changes the template shown. This is a cute but bad use of a scrollbar. Notice that the scrollbar doesn t have any marks on it. How many templates are there? How are they sorted? How far do you have to move the scrollbar to select the next one? You can t even guess from this interface.

25 Usability Example Here s one way it might be redesigned. The templates now fill a list box on the left; selecting a template shows its preview on the right. This interface suffers from none of the problems of its predecessor: list boxes clearly afford selection to new or infrequent users; random access is trivial for frequent users. And no help message is needed.

26 GUI Bloopers GUI Control Bloopers Navigation Bloopers Textual Bloopers Graphic Design and Layout Bloopers Interaction Bloopers Responsiveness Bloopers Management Bloopers

27 GUI Control Bloopers Blooper 1: Confusing checkboxes and radio buttons

28 Avoiding Blooper 1

29 Blooper 3: Using command buttons as toggles

30 Blooper 4: Using tabs as radio buttons

31 Blooper 5: Too many tabs

32 Avoiding Blooper 5 Keep the number of tabs small. If you have so many panels that their tabs won t fit into a single row, the real problem is that you have too many panels. Reorganize them into fewer panels, requiring fewer tabs. Use Another control instead of tabs

33 Avoiding Blooper 5 Never use dancing tabs

34 Blooper 6: Using input controls for display-only data

35 Avoiding Blooper 6

36 Avoiding Blooper 6

37 Blooper 7: Overusing text fields for constrained input Alternatives to text fields

38 Blooper 8: Dynamic menus

39 Navigation Bloopers successful navigation cues let people know: where they are, where they ve been, where they can go whether the goal is near or far.

40 Blooper 18: Too many levels of dialog boxes The general rule is: Avoid more than two levels of dialog boxes. A dialog box can bring up another one, but beyond that, users may lose their way

41 Textual Bloopers

42 Graphic Design and Layout Bloopers

43 Graphic Design and Layout Bloopers

44 Interaction Bloopers Deviating from task focus Requiring unnecessary steps Burdening users memory Taking control away from users

45 Deviating from task focus The first three interaction bloopers concern user interfaces that are poorly focused on the tasks the software is intended to support. Some UIs needlessly expose the implementation, impose unnecessary constraints, or present confusable concepts, distracting users from their goals and impeding their learning of the software.

46 Requiring unnecessary steps A UI should be designed so that the most common tasks that the software is intended to support are quick and easy to do (Basic Principle 4). That means minimizing the steps required to do those tasks. If users have to do unnecessary steps to accomplish their tasks, that is a blooper. This section describes three such bloopers.

47 Burdening users memory If an employee of your company offered a customer choices that were not really available, the customer would consider the employee, and your company, to be either misinformed and incompetent or deliberately lying and untrustworthy. When your software lists available products or services, they must be available. You can list out-of-stock items or booked-up dates so customers can see them, but they should be marked as unavailable so customers won t go to the effort of ordering them only to discover several steps later that they wasted their time.

48 Burdening users memory

49 Taking control away from users

50 Responsiveness Bloopers Responsiveness Principle 1: Responsiveness is not the same as performance Responsiveness Principle 2: Processing resources are always limited Responsiveness Principle 3: The user interface is a real-time interface Responsiveness Principle 4: All delays are not equal: software need not do everything immediately Responsiveness Principle 5: Software need not do tasks in the order in which they were requested Responsiveness Principle 7: Human users are not computer programs

51 References Jeff Johnson - GUI Bloopers 2.0. Common User Interface Design Don ts and Dos, Morgan Kaufmann Publishers, 2007