slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Virtual windows design PowerPoint Presentation
Download Presentation
Virtual windows design

Loading in 2 Seconds...

play fullscreen
1 / 58

Virtual windows design - PowerPoint PPT Presentation


  • 353 Views
  • Uploaded on

Virtual windows design © 200 5 , Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material. Stay name, address period booked rooms

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Virtual windows design' - jaden


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
slide1

Virtual windows design

© 2005, Pearson Education retains the copyright to the slides, but allows restricted copying for teaching purposes only. It is a condition that the source and copyright notice is preserved on all the material.

slide2

Stay

name, address

period

booked rooms

bednights, price

servings, price

bednights, price

servings, price

Breakfast list

date

room numbers

serving type, servings

Rooms

prices, types

status, dates

Virtual windows, plan

Tasks: Virtual windows:

Design rules

1. Few window templates

Book

Stay

name, address

period

booked rooms

Rooms

prices, types

status, dates

Checkin

Change room

2. Few window instances per task

3. Data in one instance only

Checkout

4. Rooted in one thing

5. Close to physical window size

6. Necessary overview

7. Things - not actions

8. All data accessible

Record

breakfast

& services

Price change

Service prices

types, prices

virtual windows
Virtual Windows
  • We have gone through basics of data presentation
    • Gestalt laws
    • Data presentation formats
      • Analog
      • Text
    • Multi-level presentation and relation to multi-sensory associations
  • We now go one step ahead- virtual windows
virtual windows4
Virtual Windows
  • A virtual window is a “user-oriented presentation of persistent data”
  • They show data but have no buttons or menus
  • Later, we will allocate functions to them
  • They will finally become actual screens
    • Web pages
    • Forms, etc.
basic concepts
Basic Concepts
  • Create as few virtual windows as possible while ensuring that:
    • All data is visible somewhere
    • Important tasks need only few windows
overall design procedure
Overall Design Procedure
  • Make a plan for what should be in each window
  • Make a detailed graphical design of the windows
  • Check with the users and make sure they understand everything
  • Check with task descriptions and makes sure they are all covered
  • Modify the design if necessary
planning the vws
Planning the VWs
  • This involves several steps
  • We need to look at important and frequent tasks:
    • This follows from the functional design process and evaluation of the scenarios and tasks
  • Group data into few VWs and outline contents of each group
cont d
Cont’d

3. Look at the next task and imagine the data user need to accomplish it

4. If the task reuses data that are already in planned VWs, consider reusing those windows

5. If a task uses other data logically related to those in a VW, consider expanding the window

cont d9
Cont’d

6. Repeat from step 4 until all tasks are covered

7. If the windows seem messy or complex, redo planning,

  • start with different tasks.
designing rules
Designing rules
  • To make it easier we’ll give some rules
  • These are guidelines rather than rules
  • In fact they are conflicting at times
    • Use engineering judgment
  • Designing a good interface requires a lot of “magic”
    • Rules are not replacements for magic!
rule 1 few templates
Rule 1- Few Templates
  • Use the smallest number of templates possible
  • Try to reuse templates across tasks
  • Makes it easier to grasp few window templates as a mental model
mental model
Mental Model
  • As discussed before, users develop their own model of how the system works
    • This is called the Mental Model
  • Their model might be different from our data model
    • We try to make sure users Mental Model is consistent with our data model.
mental model13
Mental Model
  • User’s mental model is shaped through their interaction with the software (including the use of help and manuals)
  • We want to make sure that:
    • (a) the mental model shapes as quickly as possible- it makes the user’s experience much better
    • (b) the mental model is consistent with the data model- enhances learning
rule 2 few windows per task
Rule 2- Few Windows Per Task
  • For each given task, the user must access only a few windows
    • Do not make the user wander around too many windows to get a task done
  • In other words, windows must be designed with tasks in mind
    • This improves the task support
    • Improves the user’s experience
rule 3 data in one window only
Rule 3- Data in One Window Only
  • The user should not see a data in more than window instance
    • Makes the mental model complex
  • In particular, avoid letting user edit a single data from more than one window
    • Causes confusion about the effect of changes
rule 4 rooted in one thing
Rule 4- Rooted in One Thing
  • A VW should ideally root in only one data object
    • It shows data about this particular object and perhaps other objects related to it
    • Don’t put unrelated data objects into one window
  • Example: A window can show information about all stays of a guest “John Smith” in the hotel
rule 5 overview of data
Rule 5- Overview of Data
  • The VW must provide and overview of many data
    • Even though the user might only need a few of them
  • The reason: people would like to see things in the context
    • Overview provides context for the detailed data
rule 6 things not actions
Rule 6- Things not actions
  • You can call a window “Breakfast List” but wrong to call it “Enter Breakfast List”
    • “Breakfast List” suggests the persistent data
    • “Enter Breakfast List” suggests a function or dialog to support user’s action
  • The problem: if the next task involved reviewing the breakfast list, we won’t reuse “Enter Breakfast List”
    • We will make a new window “Review BFast List”
rule 7 all data accessible
Rule 7- All Data Accessible
  • Usually, all data from the data model must be visible and modifiable through some VW
  • If not we are probably missing something
    • Need to add more windows
example room booking

name,

address1,

address2,

address3,

phone

passport

Guest

name, price

Service

Type

Service

Received

Stay

stayID,

paymethod,

state (booked | in |

out | canceled)

date, quantity

Room

State

date, personCount,

state (booked | occupied | repair)

Room

roomID,

bedCount, type

price1, price2

Example- Room Booking
  • Always start with your data model
two vws

Stay

name, address

period

booked rooms

bednights, price

servings, price

Rooms

prices, types

status, dates

Two VWs

Stay

name, address

period

booked rooms

bednights, price

servings, price

Rooms

prices, types

status, dates

slide22

Stay

name, address

period

booked rooms

bednights, price

servings, price

Stay

name, address

period

booked rooms

bednights, price

servings, price

Each stay has

its own name?

Stay

name, address

period

booked rooms

bednights, price

servings, price

Rooms

prices, types

status, dates

Rooms

prices, types

status, dates

Rooms

prices, types

status, dates

Each guest has

his own set of

free rooms?

Why or why not?

Design rules

1. Few window templates

2. Few window instances per task

3. Data in one instance only

4. Rooted in one thing

5. Close to physical window size

6. Necessary overview

7. Things - not actions

8. All data accessible

Stay

name, address

period

booked rooms

Regular guests?

Usability test !

checking against rules
Checking against rules
  • Rule 1: do we have too many templates?
    • Not really, “rooms” and “stays” seem to be the bare minimum
  • Rule 2: how many windows does the user access for booking
    • Two, the stays and rooms but we can merge them
cont d24
Cont’d
  • Rule 3: are we showing a single data multiple times
    • Maybe. If a user is regular, her name would appear on multiple stay windows
    • What if the user changed the address on one stay? Will it change the address on all?
    • Does it matter?
cont d25
Cont’d
  • Rule 4: All windows rooted in one object?
  • Rule 5: do we have the necessary overview of the data
  • Rule 6: Are window names nouns (things)
  • Rule 7: Is all data modifiable
other tasks
Other tasks
  • All these was only for one task, there are others
    • Check in and Change room
    • Extend stay
    • Check out
  • Do we need other windows? No.
    • We can extend current windows
    • How? (discuss)
discussion
Discussion
  • Lets see how these rules apply to VWs that you have designed for your projects
vws graphical version
VWs: Graphical Version
  • VWs look convincing
    • Designers may think they can leave the final design of screens to the time of implementation
    • They will find out there is not sufficient space or the user doesn’t get the overview
  • Result: a lot of redesign
    • Or sacrifice of usability
  • Therefore, design graphical look in connection with the VW planning.
design procedures
Design Procedures
  • For each VW, carefully make a detailed graphical design
    • Design only the data
    • Do not add buttons or menus
  • Fill the windows with realistic data
    • They may need more space than you think
design procedures31
Design Procedures

3. Fill the windows with extreme (but realistic) data

    • Extreme data must still be easy to see
  • If you can’t make the windows look right, you may have to redesign the plan
    • Although we hate to do it, we might have to split a window
slide32

Service prices

Breakf. rest. 4

Breakf. room 6

. . .

StayStay#: 714

Guest: John Simpson

Address: 456 Orange Grove

Victoria 3745

Payment: Visa

Breakfast 23/9

In In

Room rest room

11 2

12 1

13 1 1

Breakf. room

Breakf. rest. 4

Breakf. room 6

Sauna 3

Item persons

22/9 Room 12, sgl 1 60$

23/9 Breakf. rest 1 4$

23/9 Room 11, dbl 2 80$

24/9 Breakf. room 2 12$

24/9 Room 11, dbl 2 80$

Rooms Prices 22/9 23/9 24/9 25/9

11 Double Bath 80 60 O B

12 Single Toil 60 O O B B

13 Double Toil 60 50 B B B

Discussion:Virtual windows, graphical version

Sources

a. Reuse old presentations

b. Standard pre-sentation forms

c. Know platform

d. Gestalt laws

e. Realistic and extreme data

f. Study other designs

- their good points

- your bad points

Record breakfast

Book, checkin . . .

Price change

Book, checkin . . .

Price change

sources of graphical design
Sources of Graphical Design
  • Follow Platform
    • Use the forms already available in your platform unless you have very good reasons to do otherwise
  • Alternative presentations
    • Use consciously at alternative data presentation formats. We usually look only at a few
cont d34
Cont’d
  • Reuse old data presentation
    • if suited of course
  • Use gestalt laws
  • Study other people’s designs
virtual window in development
Virtual Window in Development
  • Work product
    • The developer term for an intemediate result during system development
  • 4 important works products in UI:
    • Task Description (out of function design)
    • Data Model (out of functional desing)
    • The virtual windows
    • A list of design defects, or things to find out
slide36

User names

Program names

Discount field

Tasks using it?

Usability test?

Work products to maintain

Virtual windows

Data model

Task descriptions

Design defects

D100. Understanding Breakfast window

vs. Stay window?

D101. Check credit card or get deposit.

D102. Understanding guest address across stays?

D103. Long stays, or with many rooms.

(evergrowing list of defects)

need for early graphics
Need for early graphics
  • The best practice:
    • Design the graphics hand in hand with designing the VW
  • You will get an idea of what is realistic and what is not
  • And also an idea of usability
  • Designing the graphics at the last step often requires a lot of re-design
typical problems
Typical Problems
  • Adding functionality too early
    • We tend to add some buttons and functions to windows
    • Problem: it makes us focus on windows as function-oriented entities
      • One window for data entry
      • One window for editing
    •  Too many windows
problem 2
Problem 2
  • Forgetting the VWs
    • Many designers put time to design VWs only to forget them when designing final screens
    • Developers get drawn into what is implementable with current GUI components
    • Usability and understandability are lost in the meantime
problem 3
Problem 3
  • Forgetting to update work products
    • We modify one work product but forget to update the changes in others
    • Example: while designing the VW, we see that we need a discount filed, we then need to update the data model
    • We might then forget to test understandability
problem 4
Problem 4
  • List of design defects
    • Designers see a problem and then later they forget about it
    • Very important to keep a list of design defects
    • Make it a habit!
    • Allow space for adding possible solutions
checking against tasks
Checking Against Tasks
  • We need to make sure we have covered all tasks
  • We use a simple table:
    • On one column the task
    • On next the data objects that the users should see
    • And the virtual window in which the data is
slide43

Tasks with data

T1.2: Checkin

Start: A guest arrives . . .

Sub-tasks: Visible data: Virtual windows:

1. Find room. Free rooms of Rooms.

type x, price. Crit: type, period.

Problem: neighbor rooms. Map. Map?

1a. Guest booked in advance. Guest and stay FindGuest, Stay.

Problem: Fuzzy guest ID details. Crit: soundex, ...

1b. No suitable room. All free rooms, Rooms. price, discount. Crit: period.

2. Record guest data. Guest detail. Stay.

2a. Guest recorded at booking. Guest detail. FindGuest, Stay.

Crit: soundex, ...

2b. Regular customer. Guest detail. FindGuest, ...

3. Record that guest is Guest and stay Stay.

checked in. details.

4. Deliver key. Room numbers. Stay.

checking procedure
Checking Procedure
  • For each task, go through its steps imagining that you are the user
  • Note down in column 2 which data the user need to see to carry out the subtasks
  • Note in column 3 the corresponding VW
  • Note down what is missing, e.g., necessary search criteria or other forms …
  • Put the missing things on the defect list
checking against data
Checking Against Data
  • We saw how we should check against tasks
  • We need to check against data model too
  • Usually, each VW relates to multiple data classes and entities
  • Our goal: makes sure each data object is handled by at least one VW:
    • CREDO Check
slide46

Stay window

Data model vs. Virtual windows

Guest

Service

Type

Service

Received

Stay

Room

State

Room

Rooms window

credo check
CREDO Check
  • We want to make sure that we can:
    • Create an entity in some window
    • Read (see) it in some other
    • Edit it
    • Delete it
    • Overview several of them in context
slide48

Guest

Stay

Room

RoomState

ServiceRec.

ServiceType

Missing

window data

CREDO check

Create, Read, Edit, Delete, Overview

Data model versus virtual windows:

Entity

Virt.

window

Stay CRE CRED r re O CREDO R

Rooms

Breakfast

Service charges

CREDO re O

r CReDO R

CREDO

roomID

Missing fncts DO O (C) D

Notes: RoomState: personCount editable through Stay, all states through Rooms.

Breakfast: roomId . . .

checking procedure49
Checking Procedure
  • For each entity, ask yourself:
    • Would some VW allow for the user to create such entity?
    • If yes put a C in the corresponding block.
    • Otherwise, put (C) in the bottom row
  • Continue with Reading, Editing, Deleting and Overview
checking procedure50
Checking Procedure
  • Then see if we miss any VW

4. Review the missing functions and data to see whether there is a good reason for that

    • E.g., if there another system must take care of the data
tasks vs data
Tasks vs. Data
  • We can do the same of course with Tasks and Data
  • Using the same procedure
slide52

Guest

Stay

Room

RoomState

ServiceRec.

ServiceType

Missing

task data

(Cont.)

Data model versus tasks:

Entity

Task

Book CRE O C O Re O

CheckinBooked RE E O O Re

CheckinNonbkd CRE O C O Re O

Checkout RE E O R e R

ChangeRoom R O Re O

RecordService O C O R

PriceChange C EDO CREDO

Missing tasks D D (C) e D ED

neighbor

neighbor

statistics

review and understandability test
Review and Understandability Test
  • We saw how the developers can check by means of logic and our general knowledge
  • We need to see if the user understands it
  • It is done in two steps:
    • Reviewing the users
    • Understandability test
review with users
Review with Users
  • Procedure:
    • Arrange a meeting with a few expert users
    • Give them the VW plans first
    • Listen to their comments
    • Ask if the windows show realistic situations
    • Show them alternative solutions, if you have
    • Write down essential usability defects and add them to the defect list
examples
Examples
  • Some users, for instance noticed
    • Seasonal prices were missing
    • What a guest really is? Is it ONE guest that moves to another room
    • Or is it really two guests
      • What if there are other guests in the same room?
slide56

Review and understandability test

Review:

Discuss virtual windows with expert user

Show and outline alternatives

Understandability test:

Show virtual windows one by one to ordinary users

Ask what they believe they show

You may explain and discuss after hearing their belief

User

believes ...

This shows ...

Designer

Records

problems

User

understandability test
Understandability Test
  • Now does this user understand the design?
  • Test procedure:
    • Arrange a meeting with ordinary users, give them the VWs at the meeting (not before that)
    • Show them the VW’s one by one. Tell them what the system is about and not what the VW shows
    • Ask the users what do you think this window shows? Is it a situation you recognize?
cont d58
Cont’d
  • Ask about things you are not certain the user understands
  • If user seems to have an overall understanding, put several windows on the table and ask them to carry out a task
  • Extract the essential defects