User Interface Design 5. Analysis, visions and domain description

Fig 5.1 Visions for the hotel system Task list T1.Book room T2.Check in T3.Check out T4.Change room T5.Record services and breakfast list Data model D1.Guests D2.Rooms D3.Services Business goals: -Small hotel market -Much easier to use and install than current systems. -Interface to existing Web-booking systems. Requirements: R1:Store data according to data model. R2:Support tasks T1 to T5.... R7:Usable with 10 minutes of instruction.

Fig 5.2 Data model for the hotel system Stay Room State Room Service Received Service Type date, personCount, state (booked | occupied | repair) name, address1, address2, address3, phone passport roomID, bedCount, type price1, price2 name, price date, quantity Guest stayID, paymethod, state (booked | in | out | canceled)

Fig 5.3A Annotated task list for the hotel system Task list - annotated 1. Reception T1.1Book room. May involve many rooms. T1.2 Check in. Some guests have booked in advance, some not. T1.3 Check out. Review account, then invoice. Problem: Checkout queue in the morning. Solution? Self-service checkout. T1.4 Change room. Possible any time during the stay. T1.5 Record services and breakfast list. Breakfast list daily, service notes at any time. Clever: Special screen for breakfast list. 2. Staff scheduling T2.1 Record leave T Work area Possible future Present way Task: Domain-level: Human+computer Imperative language

Subtasks: 1.Find room. 1a.Guest has booked in advance. 1b.No suitable room. 2.Record guest data. 2a.Guest recorded at booking. 2b.Regular guest. 3.Record that guest is checked in. 4.Deliver key. Problem: Guest wants neighbor rooms; price bargain. Problem: Guest forgets to return the key; guest wants two keys. T1.2:Check in Start:A guest arrives. End:The guest has got room(s) and key. Accounting started. Frequency:Total: Around 0.5 check ins per room per night. Per user: Difficult:A bus with 50 guests arrives Missing subtask? Fig 5.3B Task description Past: Problems VariantsUndo? Domain-level: Human+computer. Imperative language Full reference to a subtask: T1.2-4

Problem: Guest wants neighbor rooms; price bargain. Problem: Guest forgets to return the key; guest wants two keys. Subtasks: 1.Find room. 1a.Guest has booked in advance. 1b.No suitable room. 2.Record guest data. 2a.Guest recorded at booking. 2b.Regular guest. 3.Record that guest is checked in. 4.Deliver key. T1.2:Check in Start:A guest arrives. End:The guest has got room(s) and key. Accounting started. Frequency:Total: Around 0.5 check ins per room per night. Per user: Difficult:A bus with 50 guests arrives Fig 5.3D Task & support approach Past: Problems Example solution: System shows free rooms on floor maps. System shows bargain prices, time and capacity dependent. (Simple data entry, see data model) (Search with many criteria, e.g. name, booking number, phone) System prints electronic keys. New key for each customer. Future: Computer part Explicit actor

5.3 Extra: Typical UML use-case Subtasks: 1.Select room type. 2.Select desired period. 3.Click Search. 4.System shows the first free room. Variant: No free rooms Use case 21:Find a free room Start:The receptionist wants to find a free room End:The receptionist has found a free room Used for what? Will user have to write it down? For what reason? Premature dialog

Fig 5.4 Work area and user profile Work area: 1. Reception Service guests - small and large issues. Normally standing, for instance facing the guest. Frequent interrupts. Often alone, e.g. during night. User profile: Novice. Often a temporary job. IT knowledge: Simple text processing. Younger persons have surfed a bit on the Web. IT attitude: Part of the job, but not fascinating in itself. Domain knowledge: Knows only the very basics, for instance what check in is in the simplest case. Domain attitude: OK but not the career of life. It is just a temporary job. Discretionary use: Mandatory. Physical abilities: Normal sight, hearing, size, etc. User profile: Experienced. Often a life-time job. IT knowledge: Simple text processing. Some know more, of course. IT attitude: Curious about how it works in the job. Domain knowledge: Knows all the procedures and the special cases. Domain attitude: Likes the job. Likes to be an expert.

Fig 5.5A Good and bad tasks Good tasks: Closed: From trigger to closure - “coffe break deserved” Session rule: Small, related "tasks" without breaks as one task Domain level: Hide who does what with imperative language Don’t program - “if the customer has booked then...” Examples: 1Manage rooms? 2Enter guest name and address? 3Book a guest? 4Check in a bus of tourists? More examples: 9Arrange a meeting? 10Monitor a power plant? 11Wonderland Web site? 12Computer game? 8Stay at the hotel? 5Change the guest’s address etc? 6Change booking? 7Cancel entire booking?

Fig 5.3C Session task: Related tasks without break T1.6:Change booking Start:Guest calls End: Subtasks: 1.Find booking 2.Modify guest data, e.g. address (optional) 3.Modify room data, e.g. two rooms (optional) 4.Cancel booking (optional) Separate tasks?

11. Extra: Task flow or high-level task High-level steps: 1.Select a hotel. Problem: We aren’t visible enough. 2.Booking. Problem: Language and time zones. Guest wants two neighbor rooms 3.Check in. Problem: Guests want two keys 4. Receive service 5. Check out Problem: Long queue in the morning 6. Reimburse expenses Problem: Private services on the bill Example solution: ? Web-booking. Choose rooms on web at a fee. Electronic keys. Use electronic key for self- checkout. Split into two invoices, e.g. through room TV. Flow 1:A stay at the hotel User:The guest Start:... From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002 Hierarchical decomposition? Only in simple cases

High-level step:Tasks: 1.Admit the patient 2.Make a diagnosis 3.Plan the treatment 4.Carry out the treatment 5.Assess the result 6.Discharge the patient 7. Follow-up at home 12. Extra: Complex tasks - not hierarchical Flow 2:Patient treatment Start:The patient is referred to the hospital from a practitioner or arrives in emergency. End:The patient is cured or... C1: Admit before arrival C2: Immediate admission C10: Clinical session C3: Discharge patient... ?

Subtasks and variants:Example solution: 1.Review the state of the patient Problem: Overview of dataOverview of diagnoses and results 2.Provide services on the spotRecord results on the spot 3.Follow up on planned servicesOverview of requested services 4.Adjust diagnosesRecord on the spot 5.Plan new servicesCheck with everybody's calendar... 6.Maybe discharge the patientRequest transport, message to... C10: Perform a clinical session Start:Contact with the patient, e.g. ward round or emergency ward. Or conference about the patient. End:When we cannot do more for the patient now. Data needs:See the data description in... (All subtasks are optional and repeatable. The sequence is arbitrary) 13. Extra: The true work task

Write marketing report Fig 5.5B High-level tasks and case management Arrange meeting Case to manage Participant 2: Able? unable? other time? Participant 1: Able? unable? other time? Coordinator: Who? when? where? High-level tasks Phone call session Ordinary tasks ReplyFileRetrieve Subtasks

Fig 5.6A Vivid scenario or user story Scenario: The evening duty Doug Larsson had studied all afternoon and was a bit exhausted when arriving 6 pm to start his turn in the reception. The first task was to prepare the arrival of the bus of tourists expected 7 pm. He printed out all the checkin sheets and put them on the desk with the appropriate room key on each sheet. In the middle of that a family arrived asking for rooms. They tried to bargain and Doug always felt uneasy about that. Should he give them a discount? Fortunately Jane came out from the back office and told them with her persuading smile that she could offer 10% discount on the kid’s room. They accepted, and Doug was left to assign them their rooms. They wanted a neighbor room for the kids, and as usual he couldn’t remember which rooms were neighbors. Around 10 pm, everything was quiet, and he tried to do some of his homework, but immediately became sleepy. Too bad - he wasn’t allowed to sleep at work until 1 AM. Fortunately the office computer allowed him to surf the net. That kept him awake and even helped him with some of his homework.

Hotel system Booking Checkin Checkout Receptionist Account system UML use case diagram: Transfer actor Human and computer separated: Hotel system... Booking Hotel system Booking... Task descriptions. Split postponed: Account system Transfer Fig 5.6B Use cases versus tasks Problems allowed

Fig 5.6C Human and computer separated Use case: Check in a booked guest User actionSystem action Enter booking number Show guest and booking details Edit details (optional) Store modifications Click checkin Allocate free room(s) Display room number(s) Give guest key(s)