Studio Design in HCI

1. Studio Design in HCI Spring 2004 Bill Hart-Davidson Session 8: object-oriented modeling, basic concepts; artifact and physical work models; guidelines for phase 2 presentation

2. Today in Class • Object-oriented modeling concepts • Objects, views, relationships • Class diagrams • State tables • Guidelines for phase 2 presentation and memo

3. Raw material for OO modeling… • Your consolidated work models! Use these to derive system features including • user roles • user environments (metaphors, screens) • actions • data objects & states

4. OO modeling Object-oriented modeling provides a way to coordinate design work with development work. We speak, in OO modeling, in terms of User Roles that do specific Actions through the use of Objects.

5. Objects An object is a coherent assemblage of data and/or functions that allows a user to do work. Within the context of an information system, objects may be abstractions, though users always interact with concrete instances/features of them.

6. Objects: “Buddy” in AIM Buddies are objects with attributes and, within AIM, several states: online & active, online & idle, offline. Buddies are related to another object, the buddy list.

7. Views A view is the way a given object appears to a user. Views can focus the user’s attention on a single object, or provide a way to see, understand, and interact with many objects at once.

8. 2 Views of the Buddy Object in AIM Buddy name, status in “buddy list” Buddy attributes in “buddy info”

9. Common types of views Detail view – “zooms” in on an objectto reveal it’s attributes Collapsed view – opposite of detail, hides attributes to present a simple representation of an object List view – places objects in relation to its peers and/or parents These can be combined too. Can you think of others?

10. 2 views of the buddy list: online & setup

11. Relationships Relationships among objects help to coordinate system behaviors with user expectations by mapping real-world affinities with normalized data structures. Hierarchical relationships are common, as are peer-communication relationships

12. Hierarchy: The Buddy List & Buddies User’s know that a buddy list “has” buddies. The existence of the buddy list object allows users to perform managing actions…add/delete buddies, monitor status of multiple buddies, etc.

13. A convention for representing a “has a” relationship “Buddy list” has “buddies” Buddy list buddies Denotes a “has a” relationship

14. Peer/Communication Relationships Objects within a system don’t have to be hierarchical. Because relationships represent real-world interactions first. Peer/communication relationships represent which objects interact with other objects.

15. A convention for representing a “peer/communication” relationship 1 to many? Many to many? Many to 1? “Buddies talk to each other, 1 to 1.” buddy talks to buddy

16. Object/View Instances Objects spawn “instances” of themselves that users interact with. This allows the same basic object to carry context-specific details. Views also have instances, which tend to be “sessions,” reflecting the time, place, and task conditions.

17. Buddy list views, two instances Time 1 Time 2

18. Object States Most objects a user interacts with have a lifecycle, a series of “states” it can go through. At any given time, an object is occupying some state and may be poised to move to another (usually as the result of something the user does). …more on this later…

19. User Environments User environments are collections of objects, arranged to reveal functionality and facilitate interaction. Be careful equating implementation choices made by designers with the real user environment…there is no necessary connection!

20. User environment: 2 views of the Buddy chat window What accounts for these changes in the user environment?

21. buddy buddy Representing user environment designs with Class Diagrams Environment: Chat Window Class diagrams show the objects, views & relationships that make up the user environment Message log message message an abstract, simple CD

22. buddy buddy Use Class Diagrams to illustrate how system will support activity/actions Buddies can compose messages, send messages, read messages sent by their buddy Environment: Chat Window Message log message message What’s missing from this CD?

23. buddy buddy Use Class Diagrams to illustrate how system will support activity/actions, 2 Buddies can compose messages, send messages, read messages sent by their buddy Environment: Chat Window Message log message message Message toolbar* * More than one object!

24. objects relationships Class Diagram Conventions I know there are formal modeling languages such as UML, and conventions of other sorts. We will use a vastly simplified set of conventions. notes views

25. relationships Relationship Conventions Let’s use dotted lines whenever there is a relationship that can be expressed as X “communicates with” Y; X “accesses” Y; etc. We’ll use solid lines to indicate hierarchical relationships of various sorts: X “has a” Y; X “creates” Y;

26. objects relationships Class Diagrams: What are they for? Representing the user environments of your proposed design to groups other than your team: users, reviewers, implementors, etc. notes views

27. objects relationships Class Diagrams: What do they do? They allow you to highlight the function of the user environment without locking down implementation choices. Consider the alternative… notes views

28. User environments: search the web How can we account for the similarities and differences among these two UIs?

29. Some things you need to know to design user environments What kinds of activity will the environment support? How is the activity structured ? (actions) What tools and information (objects) do users need? What do they look like? How do these objects work together? (relationships) How do they change over time? How are they arranged?

30. Artifact and Physical Models help answer these questions… What tools and information (objects) do users need? What do they look like? How do these objects work together? (relationships) How do they change over time? How are they arranged? Read about these in your CD book

31. Exercise 3 : Artifact and Physical Models Exercise 3, build a consolidated Artifact or Physical model based on your CD research...then use this to build a class diagram showing your design for a user environment.

32. Objects as Finite State Machines • Object have life cycles Hotel Room: check in Occupied Free check out clean Needs Cleaned

33. Object Affordances Change • “Free” rooms allow check-in • “Occupied” rooms allow check-out check in Occupied Free check out clean Needs Cleaned

34. Affordances Matter To Users • Can a room that needs cleaned be assigned? • Can I check in to an “occupied” room?” check in Occupied Free check out clean Needs Cleaned

35. State Tables Needs cleaned Free Occupied Begin stay; change to occupied Check In Complete stay; change to needs cleaned Check Out Change to free Clean

36. Object states are the columns Needs cleaned Free Occupied Start stay; change to occupied Check In Check Out Complete stay; change to needs cleaned Change to free Clean

37. The Operations are the Rows Needs cleaned Free Occupied Start stay; change to occupied Check In Check Out Complete stay; change to needs cleaned Change to free Clean

38. In the table are the results of the operation Needs cleaned Free Occupied Start stay; change to occupied Check In Check Out Complete stay; change to needs cleaned Change to free Clean

39. We highlight the typical lifecycle Needs cleaned Free Occupied Start stay; change to occupied Check In Check Out Complete stay; change to needs cleaned Change to free Clean

40. Needs cleaned Free Occupied We also identify invalid operations Start stay; change to occupied Not allowed Not allowed Check In Check Out Not allowed Complete stay; change to needs cleaned Not allowed Not allowed Not allowed Change to free Clean

41. Later, we’ll specify interface actions for invalid choices Free Start stay; change to occupied Check In “Check Out” and “Clean” options may be greyed-out on a menu of options Not allowed Check Out Not allowed Clean

42. Check Out Invalid Actions in Views Your design should make it easy to see what can and cannot be done in a given view • Check out from “free room”? • No “guest” icon to drag

43. Needs cleaned Free Occupied Confirm the Normal Task Sequence Start bill; change to occupied Check In Complete bill; change to needs cleaned Check Out Change to Free Clean

44. Needs cleaned Free Occupied Affirm the non-affordances Start bill; change to registered Not allowed Check In Not allowed Complete bill; change needs cleaned Not allowed Check Out Change to Free Clean

45. Needs cleaned Free Occupied Identify the unexpected..schedule a room that needs cleaned? Start bill; change to occupied Start bill; don’t change to occupied Check In Complete bill; change to Needs cleaned Check Out Move to top of Cleaning list Change to free Clean

46. Deliverables for Conceptual Design Presentation • Work models to explain current and transformed scenarios (sequence & flow diagrams, physical & artifact models) • Class diagrams to show designs for your user environments • State tables for principle objects 10 minutes!

47. Line of Argument for Conceptual Design I. Open with a Reminder and a Forecast II. Present your redesign of the work (not merely the system) III. Preview upcoming work the team is facing IV. Close with a summary

48. Opening • Remind us of your goal • Introduce your current work • Preview the contents • Forecast the outcome Remember, your reviewers are new to the project! Orient them, but move quickly to the discussion of work re-design.

49. It’s a good idea to remind us of the need for your product… Start with the need “More and more people today are interested in…. Then move us toward your solution Our HCI design project ...

50. Present the Designer’s Model • Show us the transformations you plan for the current activity using work models • Introduce us to the system design via user roles, activities…using work models, class diagrams & state tables • Make the links between the work and the system obvious!