Virtual windows design

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

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

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

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

5. Basic Concepts • Create as few virtual windows as possible while ensuring that: • All data is visible somewhere • Important tasks need only few windows

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27. Discussion • Lets see how these rules apply to VWs that you have designed for your projects

28. End of Lecture

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

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

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

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

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

34. Cont’d • Reuse old data presentation • if suited of course • Use gestalt laws • Study other people’s designs

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

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

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

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

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

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

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

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

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

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

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

46. Stay window Data model vs. Virtual windows Guest Service Type Service Received Stay Room State Room Rooms window

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

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

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

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