1. Model the User Experience Today:  Detail some Use Cases  Develop a storyboard of the use cases  Sketch mock-ups of the use case's information requirements  Refine the user interface  Identify boundary classes for the use-case interface  Validate the Domain Model entity classes  Exercise the user interface model using sample data

2. Monday in OOAD -- Model the User Experience  What is an essential model? technology and implementation-independent. essential models make it easier to work out the "what" before becoming lost in the details of the "how." Core requirements, and the content and organization of user interfaces determined without the choice of GUI widgets.  http://foruse.com/articles/kaindl.pdf http://foruse.com/articles/kaindl.pdf  http://www.agilemodeling.com/artifacts/uiFlowDiagr am.htm http://www.agilemodeling.com/artifacts/uiFlowDiagr am.htm  http://www.cognetics.com/services/design_services/ ucd_docs/sample-storyboard.pdf http://www.cognetics.com/services/design_services/ ucd_docs/sample-storyboard.pdf  http://www.cognetics.com/services/design_services/ services_design1.html http://www.cognetics.com/services/design_services/ services_design1.html

3. 3 Model the User Experience  Of all software engineering, UI design is the most ‘art than science’.  However, a system's use cases provide an excellent vehicle for deriving the initial user interface models.

4. 4 Develop a storyboard of the use cases  A storyboard is a series of small, sketched cartoons that illustrate the major events to be covered in a film. Each cartoon is accompanied by a few written comments.  These enable modeling the high-level relationships between major user interface elements.  Storyboarding keeps us from getting bogged down.  The focus is on users and their usage of the system, not system features  The prototyping tools are simple – whiteboards, flip-chart paper, and sticky notes.  Why not use electronic technology?  See also Scott Ambler … on storyboards http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm

5. 5 Consider: a user interface-flow diagram for a university See also Fowler, Ch. 1 (UML is Not Enough), pp 14-16.

6. 6 Storyboard – Summary This high-level view of the system interface gives an understanding of how the system is expected to work. You can validate the overall flow of your application’s user interface. Ask: Does the flow make sense? Will the user interface be usable? What if many boxes and many connections? UML does not yet support this sort of diagram. What does that mean for you? See Boundary Class Guidelines….

7. 7  Earlier, we quoted Kruchten: "Use cases emerge when you focus on the things of value that a system provides to an actor." We focus on these ‘valued outputs’ by analyzing system’s Information Requirements, in two flavors: (1) the conceptual 'screens' the actor interacts with (2) the conceptual 'reports' produced when use cases invoked These provide the essential outputs needed from the system Information Requirements

8. 8 Sketch mock-ups of the use case's information requirements  For each use case:  With the actor, sketch out what its presentation might look like. first, the layout only then, develop some example values  Do this for both screen and report interfaces.  Discuss what the interface means. why is it important how it will be used  Use sticky notes and flip-chart paper to create an essential user interface prototype…How?

9. 9 Using sticky notes and flip-chart paper to create an essential user interface prototype  A major UI element – a large-grained item, potentially a screen, HTML page, or report.  A minor UI element – a small-grained item, widgets such as user input fields, menu items, lists, or static text fields such as labels.  Iterate :  Explore system usage using a whiteboard, etc. (the storyboard)  Model major UI elements using flip charts; give each a name.  Model minor UI elements using sticky notes.  Explore the usability of your UI

10. 10 A UI prototype to enroll students in seminars

11. 11  With the actor, discuss current data problems: Is any information not available now? o Is data missing? Are the data available but wrong? o In whole or in part?...which parts? Does it get to the actor too late? o Ask "When do you receive it? When do you need it?" Is the information available to others (other places) o but not to this actor? Is the actor getting too much data? o Is there data on an existing screen or report that is not referred. Are there data external to the business that would be helpful? o Can it be incorporated into the UI? For example, data for comparisons Information Requirements ~ understand other aspects

12. 12  Begin gathering any processing profile details that are known about the use case processing, such as:  frequency Is this:... daily?... monthly?... on-demand?  time-criticality When 'on-demand,' how long can the actor wait to see an answer:... a week?... overnight?... 3 seconds?  volumes Does this reflect:... one entity object?... the entire file?  number of users How many users need to access this use case? In how many geographic locations? Concurrently? Information Requirements ~ processing profile

13. 13 Refine the user interface  Consider what the actor has at hand vs. what the system needs to start processing….  We then evolve our initial mock-up sketch into a 'solution' version…. (Example in the Workshop for Accept Bid)

14. 14 Identify the boundary classes of the use-case interface  Analysis Class Stereotypes  Entity Classes  Boundary Classes -- used to model interaction between the system’s surroundings and its inner workings.  Control Classes  Describe the attributes of the boundary classes….