Lecture 24 – Chapter 12 continued Human-Computer Interaction

1. Lecture 24 –Chapter 12 continuedHuman-Computer Interaction

2. Dialogs and Storyboards • Dialog designs can be developed in many ways • Often evolve from descriptions of scenarios • Can proceed from written descriptions of steps, describing what the user and the computer are to do at each step (ie. Scenarios) • Format of these steps may have already been obtained during analysis when we described the flow of events model for scenarios (also called in use case scenarios) • See next slide for example of such written descriptions of use scenarios (this example was given in chpt. 7 on OO analysis, when we documented use cases)

4. Can go from the use scenarios, like one on last slide and break it down further into a sequence of user actions, Eg.: • Customer calls RMO and talks to order clerk • Order clerk verifies the customer information • If this is a new customer a new customer record is created ETC. • Other ways of describing dialogs include: • Writing out a dialog like the one presented earlier in chapter 12 • See next slide for example we saw last week of dialog in tabular form

6. Storyboarding • Can go from written description of user interactions, as shown in examples on previous slides to sketching out various series of screens that the make the design clear • Storyboarding • A technique used to document dialog design by showing a sequence of sketches of the display screen • These sketches can be made using a prototyping tool (like Visual Basic) or can even just be drawn out on paper (each page showing one screen of the dialog) • Can make the screen drawings based on steps from the written scenarios (or written versions of dialogs) • See next 2 slides for an example of a written description of the dialog representing the event Customer rents videos (a written scenario) • See slide after that for the corresponding storyboard showing drawings of potential screens for each step (note - screen numbers in written description refer to screens in this slide)

7. System: What Downtown Videos option do you want? (screen 1) User: I need to rent some videos System: Okay, what is the customer’s ID number for this rental? (screen 2) User: It is 201564 System: Fine, your customer is Nancy Wells as 1122 Silicon Avenue. Note that she has two kids, Bob and Sally, who can only rent PG-13 videos. Correct? (screen 3)

8. User: Yes. System: What’s the ID number of the first video she wants to rent? (screen 4) User: It is 5312. (screen 5) System: Fine, that Titanic (the 1953 with Barbara Stanwyck) with a rental charge of $1.00 for three days, rated PG. What’s the ID number of the next video or is that it? User: It is 8645. (screen 6) System: Fine, that is Titanic (the 1998 version) with a rental charge of $3.00 for three days …..

10. Notes on the Storyboarding Example on previous slides • The designer thinks through the sequence of screens that the user would need to carry on the dialog with the user (see last slide for example of screens) • E.g. as shown on last slide the user needs to enter a customer ID and several video IDS and the computer would have to look up and display information on the customer and each video rented etc. • Note that the system has a menu hierarchy based on the dialog and user needs • The dialog uses one form and a few dialog boxes • Note that on the previous slide, the questions the computer asks are shown in the prompt area at the bottom of the form (matching almost identically the phrases in the written dialog) • The user would have the option of either scanning or typing the few IDS that must be entered • As working prototypes are produced, many further details may still need to be worked out

11. Evaluating storyboards and emerging design • As the design progresses, reviewing the golden rules and other guidelines will keep focus on usability • Note – you can even do usability testing with screen mockups of interface/system (from our storyboard) but can even still do using paper screens • Give user a task and ask to “think aloud” or comment on the screens and their sequencing • Can video tape users doing this (ie. work with the prototype) • Can analyze and use this information to feedback iteratively into screen design and redesign • As design progresses you will end up doing this usability testing on the actual working computer prototype of the system, or early on can even make and show a video “dramatization” of what the system will look like)

12. Dialog Documentation with UML Diagrams • OO approach provides specific UML diagrams useful for modeling user-computer dialogs • Objects send messages back and forth listening to and responding to each other in sequence • People also send messages to objects and receive messages back from objects • The sequence diagram shows a user (actor) sending messages to objects • OO approach involves adding interface objects to class diagrams (see chapter 9) • Show more detail about dialog between user and computer • A collaboration diagram can also show another view of the dialog design

13. OO Approach to Dialog Documentation • Determine what forms are required for the dialog based on the techniques described above • The sequence diagram for the scenario is expanded to show the user interacting with the forms • The user-interface classes that make up the forms can be modeled using a class diagram • Finally, the sequence diagram is further expanded to show the user interacting with specific objects that make up the form

14. Example • The next slide shows the sequence diagram for the RMO use case Look up item availability • The slide after that shows the expanded version of the sequence diagram that includes a form object (or window) with which the user interacts • The form has been inserted between the actor and problem domain objects • The actor interacts with the interface objects on the form to talk to the problem domain objects, which reply through the interface objects on the form • Note that the analysis model of the interaction just shows the messages between the actor and the problem domain objects • Note that the design model inserts the interface to create a physical model of the interaction

17. Class Diagram showing interface classes making up the item search form • Next slide shows a class diagram with the interface classes used to make up the form • The Frame class represents the basic structure that contains other interface objects (using whole-part or aggregation relationships) • A menu bar is attached to the Frame • The menu bar contains Menus • A menu contains Menu Items etc. • List, Button and Label are also parts of the frame • The example is based on Java and enables the frame to “listen” for events that occur to interface objects, e.g. clicking a menu or choosing a button • The frame’s actionListner() method is invoked when the frame “hears” that an event has occurred

19. Expanding the Sequence Diagram to include interface design • A sequence diagram can be used to model the messages between the user and the specific objects making up the forms • Can make an expanded sequence diagram that emphasizes the details of the form’s design (so problem domain details can be omitted) • See next slide for Look up item availability • Nothing has changed in part of sequence diagram where problem domain objects interact with themselves • The interface objects have simply been plugged in between them and the actor

21. In the previous slide the user interacting with the Look up item availability form selects an item to look up in the list and then clicks the search button • The frame “hears” the click , asks the list for the selected item, and uses the selected item in the message to query the catalog object, which then interacts with the other domain objects • When the catalog object returns the information, the frame tells the label to display the information to the user • The next slide shows a collaboration diagram containing the same information as the sequence diagram • Emphasizes messages between objects but it shows sequence

23. Notes on OO approach • System analyst needs to think through the natural sequence of interaction early on and create a sequence diagram for each scenario of the use case • The basic dialog is then extended to include user-interface objects for the user and computer when they interact • Since the same diagrams are used during analysis and design (with design adding more detail) the object-oriented approach lends itself to iteration

24. Guidelines for Designing Windows Forms • Each dialog might require several windows forms • Each form must be carefully tested for usability • Most business systems today are developed for • Microsoft Windows • X-Windows (UNIX) • Macintosh • Form design is similar for these • Need to distinguish between standard input and browser input

25. Standard input forms vs. Browser forms • Standard input forms • Programmed in a language like Visual Basic or Java • Extremely flexible and can access data directly on a workstation • Browser forms • Programmed in HTML and XML and follow Internet conventions • Can be displayed using a markup language browser (e.g. Netscape or Explorer) • Currently do not permit the same level of design flexibility as standard input forms but next generation markup languages may support all the desired features • E-commerce is growing so some companies are designing their user interfaces on all new systems based on HTML or XML

26. Use of Prototyping Tools • After identifying the objective of the input form and its associated data fields, the system developer can develop the form using prototyping tools • More efficient than laying out on paper – in past spent larger amount of time to create and layout forms on paper • Can design the look and feel of the form at the same time • Permits the user to be heavily involved in development (provides a strong sense of ownership and acceptance)

27. Types of Forms • Input forms • Used to record a transaction or enter data • Some portion of the form may contain information for the user • Like the example of forms we saw above for the DownTown Videos storyboard example (fig. 12-9) • Input/Output forms • Generally used to update existing data • Display information about a single entity, e.g. customer • Allows for update by typing in over displayed data • Output forms • Used primarily for displaying data • Design based on same principles as report design

28. Form Layout and Formatting • Concerned with the general look and feel of the form • One method to ensure that forms are well laid out is to prototype various alternatives and the user test them • In designing input forms you should consider • Consistency • Headings, labels and logos • Distribution and order of data-entry fields and buttons • Font sizes, highlighting and colors

29. Some systems require large teams of programmers and all forms within a system need to have the same look and feel • Consistent use of function keys, short cuts, control buttons and color and layout make a system professionally looking • The headings, labels and logos of the form convey the purpose of the form • The designer should also place data entry fields carefully • Related fields should be placed near each other • If input is from a paper form, the tab order should follow the reading of the paper • Use blank space where needed • De facto traditions for placement of buttons should be considered

30. Font size, highlighting and color can be used to make the form easy to read • Careful mix of large and small fonts, bold and normal • Too much variation can cause the form to be cluttered • Column headings and totals should be larger or boldfaced • Example of form on next slide • Used to look up information about a product and to add it to an order • The title and labels make it easy to read • Natural flow of the form is top to bottom • Related fields are placed together • Navigation and close buttons are easily found

32. Data Keying and Entry for Standard Windows • Text box • An input control that accepts keyboard data entry • A text box consists of a rectangular box that accepts keyboard data • It is a good idea to add a descriptive label to identify what should be typed in • Can be designed to limit the entry to a specific length on a single line or permit scrolling with multiple lines

33. List box • An input control that contains a list of acceptable entries the user can select • Usually consists of a list of predefined list of data values and user can select one from the list • The list can be presented either within the box or as a drop-down list • Spin box • A variation of the list box that presents multiple entries in the text box itself from which the user can select • Two spinner arrows let the user scroll through all values

34. Combo box • Another variation of the list box that permits the user to enter a new value or select from the entries • Radio buttons (option buttons) • Input controls that enable the user to select one option from a group • The system automatically turns off all the other buttons in the group when one is selected • Check boxes • Input controls that enable the user to select more than one option from a group

36. Navigation and Support Controls • Standard Windows interfaces provide several controls for navigation and window manipulation • For Microsoft applications these controls are • Minimize, Maximize and Close buttons on top-right corner • Horizontal and vertical scroll bars • The selection bar • Good to be consistent • You should place buttons on the screen that allow users to move to other relevant screens, to search and find data

37. Data Keying and Entry for the Browser Interface • Browser interfaces (e.g. Netscape, Explorer) are dependent on the capabilities in the markup languages such as HTML and XML • A difference between standard windows input forms and browser input forms • The windows form can easily perform edits field by field as the data are entered • In a browser input form, the edits are not performed until the entire form is transmitted to the server • However with increase in use of Web, future developments will lead to browser forms and input forms that have similar capabilities

38. Help Support • Three types of help are available in current systems • A tutorial that walks you through the use of the form • Can be organized by task • Generally includes one dialog and set of forms for one task • An indexed list of help topics • The list can be invoked through a keyword search or help wizard (a program that does an automatic keyword search based on words found in a question or sentence) • Context-sensitive help • Automatically displays the appropriate help topic based on what the user is doing