UX Modeling with UML


UX Modeling with UML

A screen is represented in a UML model with a «screen» stereotyped class. UML's extension mechanism also makes it possible to give this new stereotyped class its own icon (Figure 9-3). Naturally, a screen's name is used as the class name and the screen's description captured as the class description. Like all UML classifiers, «screen» stereotyped classes are organized in packages, usually along functional or domain-relevant boundaries and as such are subject to normal namespace constraints.

Figure 9-3. «Screen» class stereotype icon

graphics/09fig03.gif

Not all screen properties are appropriate to capture in the model, which is, after all, a simplification and an abstraction. Static content, such as label text and images, is not architecturally significant and so is not captured in the model. The structure, or content layout, also is not appropriate for the model and with the static content is completely within the domain of the UX team. Dynamic content, on the other hand, is an important element of the UX model. The UX team must incorporate dynamic content in the final presentation, and the engineering team must provide a mechanism to access it. The simplest way to identify dynamic content is by enumerating it as attributes of the stereotyped class (Figure 9-4). Strict data types are not necessary; that is better expressed in the detailed design models. In this model, it is sufficient to identify the dynamic content by name and, perhaps, with a short description if it is not obvious by the name.

Figure 9-4. Simple dynamic screen content

graphics/09fig04.gif

If it is expected that a content management system will be used in partnership with the application, it might be convenient to identify the type of dynamic content with the stereotypes «business logic» or «managed» or other stereotype (Figure 9-5). Depending on how managed content is handled in the architecture, the distinction of which type of dynamic content is part of a screen may or may not be important. For the remainder of this chapter, we'll focus on business logic content.

Figure 9-5. Screen with stereotyped attributes

graphics/09fig05.gif

Mapping dynamic content to attributes is fine when only one instance of the content field appears in the screen. But for a shopping cart, for example, with its potential for multiple line items, using attributes is not that easy. This problem is solved, however, in the same way Java or C++ classes model such relationships: with array notation or a multiplicity on an association. Figure 9-6 shows a shopping cart screen that contains dynamic content modeled with array notation.

Figure 9-6. Variable-instance dynamic content model with array notation

graphics/09fig06.gif

Not all screen content needs to be abstracted in a separate class; if there really is only one allowed instance of the content item in the screen, it's preferred to use the simplest mapping. In Figure 9-6, the content item for the total appears as a class attribute since there is only one occurrence of this value ever to be seen in the screen, whereas all the content in the line items is variable and changes with every user.

When the instances of content vary, it is often convenient to bundle them in discrete blocks, modeled as a class. Figure 9-7 shows how this same shopping cart page can be modeled with a containment association. This allows the modeler to assign the multiplicity of the items consistently, since it is hardly likely that a shopping cart page would ever display four product names, three quantities, and five prices.

Figure 9-7. Variable-instance dynamic content model with contained class

graphics/09fig07.gif

As with most objects, state is only half the picture. Screen behavior is the other important property of a screen captured in the model. The behavior of interest in the UX model is the behavior that the screen user can invoke. The behavior that went into creating the screen, like all behind-the-scene actions in the application, does not belong in the UX model but is best modeled in the analysis and design models. Of course, there are exceptions to every rule, and sometimes it may help the understandability of the model to include a few non-user-invoked behaviors of screens in the model.

Some behind-the-scenes operations in a screen are appropriate to capture and help make the expression of storyboards and, in particular, sequence diagrams of storyboards easier to understand. These operations can help quantify some of the creational things that go on. As a result, they are modeled as static operations—underlined in the diagram. For compartmentalized screens, behind-the-scene operations can be used to indicate which optional compartments are being created and hence available to the user or to indicate the preparation of special messages that are not typically in every instance of the screen.

One common "static" operation of a screen is navigate to(), which is called to create and to display a screen. Figure 9-8 shows a participants diagram for the storyboard (Figure 9-9) describing the checkout scenario. Storyboards are discussed later in this chapter.

Figure 9-8. Participants in checkout storyboard

graphics/09fig08.jpg

Figure 9-9. Checkout storyboard sequence diagram specifying static operations

graphics/09fig09.gif

Screen behaviors are captured as operations on the screen. For the most part, these are operations that the user would invoke on the screen to alter its state or the state of the system. From the user's point of view, it doesn't matter which; from the architectural point of view, however, the difference between the two is significant. In Figure 9-10, the shopping cart screen has two operations defined that the user can invoke: update quantity and delete line item. Note that the operations are written in plaintext, and no attempt is made to use design model operations; the design model has yet to be constructed. The convention is to express the operation as a simple imperative sentence, where the implied subject of the sentence is the screen.

Figure 9-10. Shopping cart screen with defined operations

graphics/09fig10.gif

Operations whose only result is to navigate to a different page should not be included in the operation list of the screen; they are better modeled as an association to the navigated screen.

Screen Flow

Most Web applications get their work done by navigation from one screen to the next. The paths through the screens that participate in the scenarios are a key architectural element. Expected navigational paths are modeled with associations between screens. Figure 9-11 shows how a user might navigate to a Product details page. Two principal paths could be followed: directly to a featured product or through the Catalog and Category Item screens. Of course, each of these screens contains dynamic content, as shown by the containment relationships to the Category Item and Product Item classes, and the state of any given screen instance depends on the current state of the business. Association names can be used to help explain the user's intent or action that resulted in the navigation to the next screen.

Figure 9-11. Navigational paths modeled with associations

graphics/09fig11.gif

User Input

User input in a Web application is typically managed with the standard HTML input controls. In the UX model, it is important to capture each named input field and, optionally, the type of control used to collect it. Input forms are modeled with a separate «input form» stereotyped class. Fields are captured as attributes and can be optionally typed with the type of input control they are.

An input form can appear as either an association class (Figure 9-12) or a contained class (Figure 9-13). Each has advantages and disadvantages. When modeled as an association class, the form is the relationship between one screen and another. Modeling input forms this way most closely matches what happens in the implementation, since values of the form itself make up part of the browser's request for the next screen. Modeling user input this way enables us to keep associations exclusively between screens. The big disadvantage is when the next screen is indeterminate. Often, the values supplied by the user will determine which screen is navigated to next. In Figure 9-14, the user supplies payment information and one of three screens is navigated to next.[2]

[2] Dynamic content and input fields attributes are suppressed to make Figure 9-14 easier to understand.

Figure 9-12. Input form modeled with an association class

graphics/09fig12.jpg

Figure 9-13. Input form modeled as a contained clas

graphics/09fig13.jpg

Figure 9-14. Navigational flow determined by user input

graphics/09fig14.jpg

Modeling user input forms as contained classes and drawing associations from the form to the next screen allows us to model those situations in which the user input determines the next navigated screen. In Figure 9-13, a search form is part of the main Catalog screen. This screen contains dynamic content: multiple category items, where each category includes an ID, a name, a description, and a string that points to an image URL.

It is tempting to combine input fields and dynamic content, especially when the dynamic content is used to prefill the input form. The problem arises when only a subset of the form's fields are prefilled or when some dynamic content is not editable. Figure 9-15 shows a user profile screen that allows the user to update personal profile information. As a convenience to the user, most of the screen is prefilled with some, but not all, the current information, if available. For security reasons, it is decided not to display password information. The user may update the password, so input fields are available to enter a new password, but this is not prefilled. This screen also has an additional piece of content, a read-only status message. It is important not to confuse the dynamic content with user input. In many situations, these two appear to overlap and to some might seem like a duplication, but when examined in detail, these two concepts are very different and when mapped to the design model, they have a significant impact on the implementation of the screen.

Figure 9-15. Input form with prefilled values

graphics/09fig15.jpg

Sometimes, a given screen contains multiple input forms. In these cases, each form is unique and designed with a completely different intent. In these situations, they are modeled with separate contained «input form» classes. Each input form defines the fields that are part of it and has a name that indicates its purpose. Figure 9-16 shows the shopping cart screen with an additional form embedded in it. This extra form allows users to enter search criteria and to execute a new product search without having to go back to the main home screen.

Figure 9-16. Multiple forms in the screen

graphics/09fig16.jpg

Screen Compartments

The idea of divide-and-conquer has been successfully extended to UX design, as well as to modeling, warfare, and pizza. It is becoming common for information architects to define screens—and the look-and-feel as a whole—in terms of screen compartments, or subscreens: visual regions, each with a dedicated purpose that is expected to be combined with other compartments to make a whole screen.

Architecturally, there are several ways to implement this. Using HTML frames is the most obvious; however, <table>, <div>, <span>, or other HTML tags and positioning commands can also provide a sufficient mechanism to assemble screens from discrete components. These details are best left to the UX team. What is important to capture in the UX model is the definition of the compartment and its content.

Screen compartments are, for the most part, subscreens that are intended to be combined with other compartments to form a single screen. The main advantage of compartments is reuse. A compartment is most likely contained, or shared, by multiple screens. They are modeled with a «screen compartment» stereotyped class (Figure 9-17) and have attribute and operation definitions exactly like those of «screen» classes. Semantically, the only difference between a screen and a screen compartment is that a screen compartment is always contained by one parent screen that defines the complete user experience. The compartment, on the other hand, is a way to define reusable chunks of the user experience. Figure 9-18 shows an example of a home screen that is made up of three compartments: a menu, a header and a footer. The header contains an input form, and the footer contains a copyright statement as dynamic content. The screen still defines some of its own content.

Figure 9-17. The «screen compartment» icon

graphics/09fig17.gif

Figure 9-18. Defining screens with compartments

graphics/09fig18.jpg

Storyboard Realizations

A storyboard is a way to tell a story through the use of discrete static pictures. Each picture is one part of the entire story. Storyboards came to prominence as a mechanism for understanding and structuring scenarios following Walt Disney's success in the first animated feature film, Snow White and the Seven Dwarfs.[3] The concept, used for comic books since the beginning of the twentieth century, allowed the animation team to visualize and to understand what they were about to create. One nifty feature of storyboards is that the scenario can be quickly restructured by simply moving the boards around.

[3] David M. Boje, "Stories of the Storytelling Organization: A Postmodern Analysis of Disney as 'Tamara-land,'" Academy of Management Journal 38 (4), 1995, 997–1035.

In a Web application, the screens are the individual boards that, when strung together, tell a story of the application. A UML storyboard is a collaboration and is best captured by collaboration diagrams. Collaboration diagrams are nearly identical to sequence diagrams semantically but represent time as a dimension in the diagram. Object instances can appear geographically anywhere in the diagram. Messages still connect one object to another. The advantage of using collaboration diagrams rather than sequence diagrams to express storyboards is that you can reposition the objects and organize them in a way that "looks" more like the traditional storyboards that Walt Disney might have used. Of course, the full expression of structured and static content is not evident in the UML storyboard. What is in the UML storyboard is a storyboard road map that is mapped to the use case model.

In Figure 9-19, the storyboard outlines the tale of browsing the online catalog for office supplies. It's preferred to use realistic names for object instances, especially when there are multiple instances of the same class. In this figure, the Category and Product pages are visited frequently, each time exhibiting new dynamic content. When convenient to do so, add notes to key screen instances to indicate special state information that might make the storyboard easier to understand.

Figure 9-19. Storyboard scenario expressed as a UML collaboration diagram

graphics/09fig19.gif

The semantically equivalent storyboard expressed as a sequence diagram is shown in Figure 9-20. The main advantage of using sequence diagrams is that it is easier to supply narrative text on the side.

Figure 9-20. Storyboard sequence for the Browse Catalog use case

graphics/09fig20.gif

An additional way to express navigational flow, especially when the paths are dynamic and state-dependent is with an activity diagram. Figure 9-21 shows the activities of the shopper and the system for browsing the catalog. It is also a good idea to link screen instances to the activities when appropriate to trace activities to UX screens.

Figure 9-21. Activity diagram describing the Browse Catalog use case

graphics/09fig21.gif

It is also a good idea to define a participants diagram for all storyboards. This type of diagram is simply a subset of the main navigation map, usually with many of the screen's details—attributes and operations—shown. Figure 9-22 shows the participants diagram for the Browse Catalog use case.

Figure 9-22. Participants diagram for Browse Catalog storyboard

graphics/09fig22.jpg

Navigational Map

I find it useful to produce a top-level navigational map for a Web application. If the application contains fewer that 50 screens, this can be accomplished, with the right tools, in a single diagram. For larger applications, it's best to divide the map into several diagrams, each focusing on related use cases. In the navigational map, do not show screen details; if appropriate, render the classes with icons. This gives the cleanest top-level view of the "site." Figure 9-23 shows a simple navigational map for an e-retail application.

Figure 9-23. Navigation map with adorned screens

graphics/09fig23.jpg

Adornments are visual notations that can be added to «screen» elements in the model to express special properties of a screen. For example, the screens in Figure 9-23 are color coded and use a special naming convention. A U.S. dollar sign ($) is appended to a screen name to indicate that the screen is navigable from any other page in the system, most likely from a common menu bar in the application user interface. Pages with a plus sign (+) appended to the name are "scrollable." These Web pages contain large lists of information that need to be paged through and have a limited number of items on any one page. Results from a search Web engine are an example of this type of mechanism.

Other notations can be used to express secure pages (SSL) or other types of project-specific information. A formal collection of these screen properties is not an official part of the UML profile; rather they are examples of local customizations that might be useful. The proper way to adorn screens with extra information like this would be to define tag values; however, it has been my experience that these are often hidden deep in the model and are easily overlooked if they are not shown by default in a diagram.

UX Model Stereotype Summary

The user experience model introduces two new class stereotypes: «screen» and «input form». The stereotyped classes can be rendered with the optional class icons in Table 9-1.

In addition to these class stereotypes, two optional attribute stereotypes—«business logic» and «managed»—can be used when a content management system is part of the architecture and it is important to distinguish between what the application manages and what the CMS manages.

Table 9-1. Optional Class Icons
Stereotype Icon Decoration Icon
«screen» graphics/icon.gif graphics/homepage.gif
«input form» graphics/input.gif graphics/payment.jpg
«screen compartment» graphics/screencompartment.gif graphics/footer.gif