Design Principlesfrom Don Norman’s Design of Everyday Thing.docx
- 1. Design Principles from Don Norman’s “Design of Everyday Things” and Preece, Rogers and Sharp’s “Beyond Interaction Design” Design of Everyday Things • Donald Norman - cognitive scientist and engineer who has pioneered many ideas surrounding user centred- design • worked for Apple, Hewlett Packard, Northwestern University, UCSD • critiques and examines many everyday items as examples of problematic designs • design principles a framework for discussing and thinking about everyday interactions • Norman, Donald A. (1988). The Design of Everyday Things. New York: Basic Books. Design Principles • Visibility- can is see it?
- 2. • Feedback - what is it doing now? • Affordance - how do I use it? • Mapping - where am 1 and where can I go? • Constraint - why can’t I do that? • Consistency - I think I have seen this before? Visibility • Can see the state of a device and possible actions • Car controls are positioned in a way that they can be easily found and used Visibility • Problems arise when we cannot “see” how to do use a device • Sensor technology like auto faucets - not sure how to use - guess where to put hands • Visible knobs, dials and buttons have been replaced by invisible and ambiguous “active zones” Visibility • Hiding certain functions can be
- 3. advantageous in interface design • Certain functions are kept invisible until needed; also contained within a group of similar types • Google search makes it clear where to enter text Visibility • Other examples of poor or good visibility in design? Feedback • what is it doing now? what action has been performed? • needs to be immediate and synchronized with user action Feedback • Sound works as feedback - examples? Feedback • Other examples of feedback in everyday design?
- 4. Affordance • Perceived and actual properties of an object that give clues to its operation Affordance • Perceived and actual properties of an object that give clues to its operation Affordance • Perceived and actual properties of an object that give clues to its operation Affordance • Other examples of affordances in everyday interactions? Mapping • Relationship to controls and their effect Mapping • Relationship to controls and their effect
- 5. Mapping • Relationship to controls and their effect Constraints • Restricting the kind of interactions that can take place Constraints • Restricting the kind of interactions that can take place • Reduce the chance of error • Can also work to focus user’s attention to needed task Constraints • Other examples of good and bad constraints? Consistency • designing interfaces to have similar operations and use similar elements for achieving similar task
- 6. • systems are usable and learnable when similar concepts are expresses in similar ways • enables people to quickly transfer prior knowledge to new contexts and focus on relevant tasks • Four types of consistency: • aesthetic • functional • internal • external Consistency Aesthetic • style and appearance is repeated to enhance recognition, communicates membership and sets emotional tone • Mercedes Benz vehicles are instantly recognizable because the company consistently feature its logo on all its vehicles • associated with quality and prestige; respected and admired; fine craftsmanship and reliable Consistency
- 7. Functional • meaning and action are consistent to improve learnability and understanding • consistent use of symbols to represent similar concepts, leverages prior knowledge and makes new things easier to use • traffic always turns yellow before red • cassette recorder control symbols used on a Consistency Internal • consistency with other elements in the system • cultivates a sense of orientation and trust • indicates system is well thought out and planned • eg. park and trail signage Consistency External • consistent with other elements in the environment
- 8. • extends the benefit of internal consistencies across multiple, independent systems • more difficult to achieve because different systems rarely observe the same design standards Guidance: 1. Purpose - this is just what the document is for, you don't need to modify this section in any way. 2. Goals and Philosophy - this is just what are the primary NFRs that the architecture addresses. For example, if reliability is a key concern you would say that the architecture addresses reliability issues. Its not really a 'philosophy', it just what you are trying to achieve with the architecture. 3. Assumptions and Dependencies - this is where you state some of your key assumptions - things like that the warehouse has a connection to the Internet, that the warehouse has a wireless network to connect the cranes - that the cranes have an independent processing node on them and aren't just a remote screen (for example). That the WMS is a separate system. Dependencies are things like the SOAP specification, the WAF specs, access to a TCP/IP network - external factors that you can't control and need to support/implement, or depend on. 4. Architecturally significant requirements - requirements that affect the architecture - like supporting access as a web service, the fact that the crane drivers consoles are mobile, if you have any reliability recoverability or performance requirements. Note : sections 2 through 4 are 'forward looking' - ie they spell out requirements that your architecture has to address. The following sections are 'backward looking' - ie they document things that you decide and do in the other parts (B,C, D) of the assignment. You should NOT get stuck trying to figure these later sections out before you have actually decided on what your architecture is going to be, and what software patterns you are
- 9. going to use. Come back and fill these sections in after you have worked out your architecture and detailed design. 5. Decisions, constraints, and justifications. Here is where you note down and explain/justify decisions you have made (note past tense). 6. Architectural mechanisms. Mechanism is sort of a synonym for 'pattern'. I relate it back to architectural 'tactics'. Tactics are a specific approach you are going to take to address a particular NFR. For example, we may have a reliability NFR, and we decide we are going to address that NFR using a 'hot spare'. 'Hot spare' is an 'architectural mechanism' we are going to use to address the reliability NFR. Refer to the lecture on 'Principles, Patterns, Tactics, and Views' for some idea of what tactics are. Otherwise, get hold of 'Software Architecture in Practice' (SWAiP) - or google 'software architecture tactics' and look at the articles published by the Carnegie SEI. I have also uploaded Chapter 5 from SWAiP into the Asg2 Resources section of the website. My take is - an 'architectural mechanism' is some software pattern by which we are going to implement some architectural tactic. IE a mechanism implements a tactic. Just note down what tactic you are going to employ to address some NFR, and then what pattern/arrangement of components you are going to use to implement that tactic. Once again this is best done after you have decided how you are going to address those issues. 7. Key Abstractions - for abstraction, read 'representation' or 'concept'. This section wants to know about the key concepts that are represented in the application - ie your domain model or entity classes. Also, if there is some really dominant pattern that helps explain how your whole system is going to function - like 'event driven interaction between components', or 'data access object encapsulate persistence system', then mention that here. 8. Architectural Framework - this where you typify your application by calling it 'basically a client-server model' (or
- 10. not) - or 'the architecture uses a layered style, separating user interfaces from business logic and persistence mechanisms. Also that it is partitioned into your functional components. Basically, here is where you say how you divided the system up into functional and technical components, and whether there is some overarching 'architectural style' that you can relate it to. 9. Architectural Views. OK there is a mismatch here between the template and what I really want - but you don't have to include anything here anyway - you only have to refer to the diagrams that are requested in other parts of the assignment. What we are producing as 'architectural views' corresponds to Kruchten's 4+1 Views as described in the Kruchten article in the Asg2 resources, and also that FCGSS_US_WP pdf - which tells you what UML 2 diagrams correspond with what views. Essentially its like this: Logical view - Class diagram - Asg2 Part B Section a. The logical view basically shows the class collaboration necessary to support the CCRD use case according to the architecture that you have designed. Its a bit like the summary analysis class diagram, except that it shows all the classes involved in supporting the use case, including the user interface, controller, and other 'infrastructure classes. The logical diagram shows everything you would need to implement that single CCRD use case according to your architecture - so it shows what would be necessary to support the NFRs, as well as just the functional requirements - so if there is some need to store things in a database, the logical diagram would show the classes necessary to support that. This is where any DAObjects start to show up. Process View - Sequence diagram - Asg2 Part B Section b. This is very similar to the sequence diagram we drew for Asg1, but it shows the details of how the control class is going to support the user interface you come up with for the crane driver in Part C, and as in the logical view, it shows how the NFRs are addressed as well as the functional requirements. So - as above , if you are going to store things in a database, we want to see when those DAObjects are told to update and save as part of the
- 11. message sequence that supports the use case. Basically, the message sequence we drew in Asg1 (that is provided to you for 'manual store pallet' in the Asg1 Solution s) forms a skeleton, which we now flesh out with specific information need to support the crane driver interface, and also to conform with and support the NFRs addressed by the architecture. The message sequence has to be consistent with the architecture. Implementation View - Component Diagram Asg2 Part A Section b. This is a 'high level' view that shows your functional and technical components. The other thing it has to do is identify any 3rd party components your application is going to rely on - like a database implementation, or a web server for example. The component diagram is for 'implementation' so it assumes you have actually identified the platform/language you are going to implement in. In terms of development this is an important diagram because it does things like identify what versions of what libraries you are going to need - and that the developers have to stick to. Deployment View - Deployment Diagram Asg2 Part A Section c. This is a complementary high level view that shows how your high level components are laid out on the actual hardware of the
- 12. deployment environment - its a pretty straight derivative of the component diagram with the addition of 'hardware nodes'. The trick is that your components have to respect hardware boundaries, and any 'inter-node' communication has to incorporate some sort of network communication - so there's another technical component you are going to need - probably on every node in the system. Use case View - not required for this assignment, but basically its job is to provide a context for the other views. Anyway the point here is that you don't have to duplicate all these diagrams in the architecture notebook - you just have to identify them, and reference the other parts of the assignment