Studio design in hci
This presentation is the property of its rightful owner.
Sponsored Links
1 / 61

Studio Design in HCI PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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. Today in Class. Object-oriented modeling concepts Objects, views, relationships Class diagrams State tables

Download Presentation

Studio Design in HCI

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Studio design in hci

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


Today in class

Today in Class

  • Object-oriented modeling concepts

    • Objects, views, relationships

    • Class diagrams

    • State tables

  • Guidelines for phase 2 presentation and memo


Raw material for oo modeling

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


Oo modeling

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.


Objects

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.


Objects buddy in aim

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.


Views

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.


2 views of the buddy object in aim

2 Views of the Buddy Object in AIM

Buddy name, status in “buddy list”

Buddy attributes in “buddy info”


Common types of views

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?


2 views of the buddy list online setup

2 views of the buddy list: online & setup


Relationships

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


Hierarchy the buddy list buddies

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.


A convention for representing a has a relationship

A convention for representing a “has a” relationship

“Buddy list” has “buddies”

Buddy list

buddies

Denotes a “has a” relationship


Peer communication relationships

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.


A convention for representing a peer communication relationship

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


Object view instances

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.


Buddy list views two instances

Buddy list views, two instances

Time 1

Time 2


Object states

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…


User environments

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!


User environment 2 views of the buddy chat window

User environment: 2 views of the Buddy chat window

What accounts for these changes in the user environment?


Representing user environment designs with class diagrams

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


Use class diagrams to illustrate how system will support activity actions

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?


Use class diagrams to illustrate how system will support activity actions 2

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!


Class diagram conventions

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


Relationship conventions

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;


Class diagrams what are they for

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


Class diagrams what do they do

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


User environments search the web

User environments: search the web

How can we account for the similarities and differences among these two UIs?


Some things you need to know to design user environments

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?


Artifact and physical models help answer these questions

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


Exercise 3 artifact and physical models

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.


Objects as finite state machines

Objects as Finite State Machines

  • Object have life cycles

Hotel Room:

check in

Occupied

Free

check out

clean

Needs Cleaned


Object affordances change

Object Affordances Change

  • “Free” rooms allow check-in

  • “Occupied” rooms allow check-out

check in

Occupied

Free

check out

clean

Needs Cleaned


Affordances matter to users

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


State tables

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


Object states are the columns

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


The operations are the rows

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


In the table are the results of the operation

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


We highlight the typical lifecycle

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


We also identify invalid operations

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


Later we ll specify interface actions for invalid choices

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


Invalid actions in views

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


Confirm the normal task sequence

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


Affirm the non affordances

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


Identify the unexpected schedule a room that needs cleaned

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


Deliverables for conceptual design presentation

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!


Line of argument for conceptual design

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


Opening

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.


It s a good idea to remind us of the need for your product

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 ...


Present the designer s model

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!


Introduce us to the user environments and the interactions they support

Introduce us to the user environments and the interactions they support

  • walk us through key interactions using a combination of flow/sequence models and your class diagrams

  • summarize the relationships among objects in each environment

  • Use your research to give details about views, object states, etc.


The reservation task is supported as interactions among three objects

Guest Details

Planned Dates

Room Type

Reservation

Reservation View

Hotel

Guest Details View

plan to stay

Name

Address

Telephone #

Credit Details

Guest

“The Reservation Task is supported as interactions among three objects...


And one view

Guest Details

Planned Dates

Room Type

Reservation

Reservation View

Hotel

Guest Details View

plan to stay

Name

Address

Telephone #

Credit Details

Guest

“…and one view...


And one sub view

Guest Details

Planned Dates

Room Type

Reservation

Reservation View

Hotel

Guest Details View

plan to stay

Name

Address

Telephone #

Credit Details

Guest

“…and one sub-view.”


Clerk checks the reservation view

Guest Details

Planned Dates

Room Type

Reservation

Reservation View

Hotel

Guest Details View

plan to stay

Guest

Name

Address

Telephone #

Credit Details

“Clerk checks the Reservation View …”


For the desired date

Guest Details

Planned Dates

Room Type

Reservation

Reservation View

Hotel

Guest Details View

plan to stay

Guest

Name

Address

Telephone #

Credit Details

“... for the desired date …”


And the requested room type

Guest Details

Planned Dates

Room Type

Reservation

Reservation View

Hotel

Guest Details View

plan to stay

Guest

Name

Address

Telephone #

Credit Details

“... and the requested room type.”


My suggestion do this for 2 3 important actions

My suggestion: do this for 2-3 important actions

  • Pick interesting ones

  • Explain how this new way of doing things is a “transformation” of the existing practice… emphasize benefits, etc.


Recall your research all the way through

Recall your research…all the way through!

The key to building credibility is to base your claims on the research you have conducted.

  • The EMT’s told us….

  • When we watched shoppers, we saw…

  • This activity has developed and changed over time ...

  • Breakdowns occur when...


Talk about what s coming next

Talk about what’s coming next

  • Prototyping – show us which design ideas you are testing implementations for

  • Mention design issues the team is facing

  • Cue your reviewers and audience for feedback


For next time

For next time…

  • Share Exercise 3 results as a dry run for presentations

  • Presentation schedule

  • Prototyping

  • Guidelines for phase 2 memo


  • Login