interaction design process and heuristics n.
Skip this Video
Loading SlideShow in 5 Seconds..
Interaction Design Process and Heuristics PowerPoint Presentation
Download Presentation
Interaction Design Process and Heuristics

Interaction Design Process and Heuristics

258 Vues Download Presentation
Télécharger la présentation

Interaction Design Process and Heuristics

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Interaction Design Process and Heuristics

  2. Objectives • To present an overview of the interaction design process • To present alternative control styles and consider their strengths and weaknesses • To present interaction design heuristics

  3. Topics • Component and interaction co-design and outside-in design • Controllers and control styles • Centralized • Delegated • Dispersed • Interaction design heuristics • The Law of Demeter

  4. Component and Interaction Co-Design • Components cannot be designed alone because they may not support needed interactions. • Interactions cannot be designed alone because they may rely on missing features of components or missing components. • Components and interactions must be designed together iteratively.

  5. Outside-In Design • Interaction design should be mainly top-down (from most to least abstract interactions). • The most abstract interactions are specified in the SRS and use case models. • Starting with the interactions between the program and its environment (outside) and designing how interacting components can implement them (inside) is called outside-in design.

  6. Controllers Controller are important because they are the central figures in collaborations. A controller is a program component that makes decisions and directs other components.

  7. Control Styles A control style is a way that decision making is distributed among program components. • Centralized—A few controller make all significant decisions • Delegated—Decision making is distributed through the program with a few controllers making the main decisions • Dispersed—Decision making is spread widely through the program with few or no components making decisions on their own

  8. Centralized Control • Easy to find where decisions are made • Easy to see how decisions are made and to alter the decision-making process • Controllers may become bloated—large, complex, and hard to understand, maintain, test, etc. • Controller may treat other components as data repositories • Increases coupling • Destroys information hiding

  9. Centralized Control Form

  10. Less-Centralized Control Form

  11. Control Heuristics 1 • Avoid interaction designs where most messages originate from a single component. • Keep components small. • Make sure operational responsibilities are not all assigned to just a few components. • Make sure operational responsibilities are consistent with data responsibilities.

  12. Delegated Control • Controller are coupled to fewer components, reducing coupling. • Information is hidden better. • Programs are easier to divide into layers. • Delegated control is the preferred control style.

  13. Control Heuristics 2 • Have components delegate as many low-level tasks as possible.

  14. Dispersed Control Style • Characterized by having many components holding little data and having few responsibilities. • It is hard to understand the flow of control. • Components are unable to do much on their own, increasing coupling. • It is hard to hide information. • Cohesion is usually poor. • Few modularity principles can be satisfied.

  15. Control Heuristics 3 • Avoid interactions that require each component to send many messages.

  16. Law of Demeter An operation of an object obj should send messages only to the following entities: • The object obj; • The attributes of obj; • The arguments of the operation; • The elements of a collection that is an argument of the operation or an attribute of obj; • Objects created by the operation; and • Global classes or objects.

  17. Consequences of the Law of Demeter • Objects send messages only to objects “directly known” to them. • The Law of Demeter helps to • Hide information, • Keep coupling low, • Keep cohesion high, • Discourage an over-centralized control style, and • Encourage a delegated control style.

  18. Remarks on Control Styles and Heuristics • There is a continuum of control styles with centralized and dispersed on the ends and delegated in the middle. • Different levels of centralization may be more or less appropriate depending on the problem. • The control heuristics are in tension.

  19. Summary 1 • Interactions and components cannot be designed independently, so they must be designed together iteratively (component and interaction co-design). • Interaction design should proceed top-down (outside-in). • Controllers are important components in designing interactions. • We can distinguish various control styles on a continuum of centralization versus distribution.

  20. Summary 2 • A delegated control style in which a few controllers make important decisions but delegate other decisions to subordinates is usually best. • Various heuristics, including the Law of Demeter, encourage control styles that maximize information hiding and cohesion and minimize coupling.