Artifacts of the UX Model

Some of the artifacts the UX team is responsible for are

• Screens and content descriptions
• Storyboard scenarios
• Navigational paths through the screens

These artifacts are developed by the UX team (Figure 9-1) and are captured in the UX model of the system. The UX model is a separate model because it is a complete view of the system from a particular viewpoint; in this case, of the system through its screens. The architecturally significant properties of the screens and their navigational relationships are the principal elements in the UX model. Use case realizations, or UML collaborations, capture storyboard scenarios of the application in terms of the system's screens.

Figure 9-1. Artifacts developed by UX team: screens and storyboards

Capturing this information in a UML model is useful to the UX team; however, its real importance is for the other, "downstream" models of the system. The analysis/design model, implementation, and test models will all provide mappings to the UX model. The UX model's storyboards are themselves mappings to the use case model.

Screens

A screen is something that is presented to the user. A screen contains the standard user interface infrastructure, such as menus and controls, as well as business-relevant content. Content, a generic term for business information that appears in a Web page, is a combination of static contentfield names, titles, text, and images that are constant for each user of the systemand dynamic contentselected products, personal information, current status, and other computed information.

As defined in the UX model, the concept of a screen should not be confused with Web pages, which are the mechanisms that build and produce screens. The concept of a screen is strictly what is presented to the user. How it got there is not an inherent property of a screen. Usually, a screen is built and presented to the user by server-side mechanisms: Active Server Pages, JavaServer Pages, servlets, and so on. These mechanisms often interact with server-side components that produce the dynamic content in the screens. The static content is provided by templates and usually resides on the server's file system. This combination of template and dynamic content is what builds screens and is not the screen itself. It is also important to understand that whether a screen is produced as the result of a JSP's processing or dynamically assembled on the client from an XML document and style sheet, the resulting user interface experienced by the user is still a screen filled with content.

Overview of Screen Properties

A screen's properties (Figure 9-2) and its behavior with the user define the screen. These include

• Name and description
• Structure
• Static content
• Business logic content
• Managed content
• Input fields and controls that accept user input
• Description of user interactions with the screen

Figure 9-2. Screen properties

A screen's name and description should indicate its purpose and indicate to the rest of the team why it is important. The structure of a screen, best described by wire-frame prototypes, describes how the screen's information is laid out. Static, business logic, and managed content collectively represent the information that is presented to the user. Static content is all the embedded text and images that remain constant over time and with each user.

Dynamic contentbusiness logic and managedis described in the next section. The input fields and controls identify what information the users can provide to the system through the interface. Typically, these controls are a collection of the standard HTML-defined controls but in general can represent any customized control or user input element, such as Flash movie, applet, and so on.

Content Management

Dynamic content in a screen is a complex subject. In the last few years, the distinction between Web applications and Web sites has continued to blur. As a result, an entire new branch of software/information technology has emergedcontent managementas well as a new class of off-the-shelf software systems: content management systems (CMSs). These systems have evolved to meet a primary business need: how to manage the change of the information presented to the users of Web sites and applications.

In the short history of Web sites and applications, the general mechanism for updating information on a company's public Web site or intranet has been to call the IT department's person responsible for managing the Web server. For small organizations, this worked. But the industry soon understood that the real owner of the information on the Web site was not the IT department but the various departments supplying the content. It wasn't right for the IT department to own and to be responsible for updating this content. Its responsibilities should remain in the technology, not in the business content.

It was also realized that as the sites grew and mingled with Web applications, coordinating changes to content was no longer a trivial matter. Even today, plenty of public Web sites have broken links to pages on the same site and have out-of-sync content. Without the proper infrastructure, the complexity of owning and managing content changes is beyond the ability of nontechnical business groups. Content management systems were developed to give control of Web site and Web application content back to the various business departments that own it and, most important, to provide a single mechanism and process for coordinating the content changes.

Content management systems bring two key ingredients to the solution: a workflow engine and the technological infrastructure to implement the process of coordinated change. Exactly how the numerous vendors in this market supply this varies widely. Some simply provide a toolset and minimal middleware to Web development teams, which then have to design and to implement a lot of customized software. This solution is appropriate for companies with existing Web development teams and that need to provide tight integration with existing proprietary systems. On the other end, near turnkey systems provide all that is needed to manage the content in relatively static Web sites. These types of solutions are appropriate to companies with little Web development expertise and that have relatively noncomplicated and static Web sites.

The picture gets more complicated when managed content mingles with content delivered by a Web application. In this situation, some of the content is managed by business processes and departments and has a typical duty cycle of days, weeks, or months. Example of this type of content are

• Public copyright statements
• Banner ads
• Help and informational messages
• Press releases
• Company and application FAQs
• White papers

The rest of the dynamic content is managed and delivered by the application. It's the application's main job to own the life cycle of this content. Business logic content in screens is often user session dependent. Examples of business logic content are

• Search results
• Shopping cart line items
• User preferences

In general, application content is any business state that is presented to the users of its Web interface. It is the responsibility of the Web application itself and any connected back-office applications to manage this type of content. Which type of dynamic content depends on which systemCMS or applicationis responsible for managing its state.

Screens as Artifacts

Because it is so often referenced in use case specifications, the concept of a screen can be thought of as an artifact in the requirements set. However, many screens don't get fully described until analysis, and so it would seem natural for screen definitions to be in the analysis artifact set. In my opinion, exactly which artifact set it belongs to is academic. If the storyboards are used principally as a requirements artifactthe analysis and design teams are constrained to implement itthe screen belongs in the requirements set. As a requirements artifact, screens provide solid, concrete representations of the user interface that the analysis and design teams can support and that the stakeholders can immediately understand and comment on. If it evolves as a direct result of analyzing the use cases, a screen might best be thought of as an analysis artifact. In either case, the resulting UX model is the same. It's a complete view of the system from the viewpoint of the system's Web-based user interface.

Storyboards

When screens are combined and ordered, they can describe use case scenarios, or ministories of the behavior in an application, expressed in terms of sample screens. In any given "story," any screen may be visited many times, each time with a new set of dynamic data. Each scenario is an expression of a specific use of the system. There are no conditional expressions in scenarios, and real-life terms and names are typically used. The whole goal of a storyboard scenario is to express a typical use of the system through the eyes of the user.

Early in the elaboration phase, the screens might be simple hand-drawn diagrams or wire frames. As the process continues, these artifacts evolve into higher-fidelity mockups or HTML files. Eventually, these HTML files, or templates, make their way into the application's builds and are delivered by Web servers and contain static content and even dynamic content. Keeping and maintaining these scenarios throughout the development process is an excellent way for nontechnical stakeholders to keep in touch with the system's progress. On the flip side, it might also give these same stakeholders a false sense of completion, since these storyboards are almost always completed long before the rest of the system is ready.

Navigational Paths

One of the most architecturally important artifacts that the UX team produces is the navigational path map. These diagrams express the structure of an application's screens with their potential navigational pathways: a road map of the application's screens. An important characteristic of this diagram is that is expresses all the legal and expected paths through the system. The influence of the browser's Back button, or caching previously navigated pages, does not belong in this diagram. They are important issues to be considered when designing and architecting the system but do not belong in the navigational map.

When first thought of, the navigation path map seems like a good idea; even without UML, in fact, most Web developers produce some form of site map, which indicates all the application's screens and all the paths through them. In practice, only small or trivial applications produce nice and easy-to-read site maps that contain all possible navigational paths. This is why the navigational paths defined by the information architect are limited to the natural and expected paths, not every possible one. This is especially evident in menu-driven applications, in which the user is free to select any combination of menus and to roam in and out of any number of screens while trying to accomplish a task. On the other hand, wizard-driven applications often limit the ability of the user to roam through unnecessary pages when completing tasks and so are easier to develop path maps for.