JSF Central - Designing JSF Applications - A Storyboard Approach
JSF Central

 Articles & Books 
Designing JSF Applications - A Storyboard Approach
Designing JSF Applications - A Storyboard Approach
by Steven Murray
21 Oct 2008 02:00 EDT

Sometimes the best way to explain JSF to the business is through the design technique called Storyboarding. This series of articles explains how you can use Storyboarding to discuss JSF in terms of screens, compartments, and components as well as state transitions and navigation paths. In this first article, Steven provides an overview of this techique, and explains key elements such as use cases, the User Interface model, Screens, Operations, and Compartments.

  Figure 3. Input Form UI Model
Figure 3. Input Form UI Model


Input forms represent the state that needs to be persisted for both intra- and inter-screen transitions within a storyboard. The attributes that are shown in the user input class correspond to an <input> element from the screen and/or compartments with which it is associated. For simple screens the use of an input form is optional (implicit) and it is up to the designer to determine if and when to use them in a screen flow diagram.

Screen Flows

The next step in creating a UI model is to draw a navigation diagram for the use case. The diagram does not focus on any one flow of events but shows the relationships between all of the screens. A UI model contains one navigation diagram for each use case, as shown in figure 4. I recommend that you also produce a navigation diagram for the entire application.

  Figure 4. UI Screen Flow Model for taking an online exam
Figure 4. UI Screen Flow Model for taking an online exam

A directed association between two screens indicates that there is a flow from the "from" screen/form to the "to" screen initiated by an action performed by the user on the "from" screen/form. Flows can be shown to originate from a <screen> or, in more complex cases , the input <form>. Flows always terminate on a <screen>.

Each flow should be uniquely named and the name should be consistent with the name of the screen operation that originated the flow. You can use the association name of the "from" end to represent the name of the JSF navigation outcome that selects the flow.

User Interface Mockup

Creating User Interface (UI) Mockups is an important part of any storyboard. The term Mockup refers to any visual UI design ranging from a paper-napkins, wire-frame(s), to full click-stream prototypes. My recommendation is to use wireframes; they can be produced quickly and complement the UI Model by providing a visual layout (figure 5).

  Figure 5. UI Wireframe
Figure 5. UI Wireframe

One drawback of wireframes is that the inherent assumptions regarding the interface layout make it extremely difficult to revolutionize the user experience. Wireframes are not a piece of graphic design and they should not be considered a requirement; their purpose is to provide a content/functionality sketch. Wireframes prevent the team from getting bogged down in visual design but provide enough detail in your storyboard to get the implementation on its way.

UI State Model

A state model is associated with a storyboard screen to describe the behavior of the screen as it progresses through a use case. It is a diagram of the server-side controller and models the flow of events from the screen and the messages to the business domain required to carry out any action. A simple state model is illustrated in Figure 6.

  Figure 6. UI State Model
Figure 6. UI State Model

The UI State Model starts with the state of the controller when it is created, as shown by the arrow from "Start" to "State 1". A transition represents a rule that is evaluated by the state engine, in response to an event, which moves the controller from one state to another.

Each transition has three parts: trigger-signature [guard]/activity. All three parts are optional. The trigger signature is usually a single event that triggers a potential change of state. The guard, if present, is a Boolean condition that must be true for the transition to be taken. The activity is some behavior that is executed during the transition.

Transitions are indicated by an arrow connecting two states; think of a transition as an event that changes the composition of the screen without requiring a navigation event. States can also react to events using internal activities or self-transitions in which the composition of the screen is not significantly altered. The final state indicates that the state machine is completed, implying that you can delete the controller and any of the internal state information it might be holding.

Supplementary Documents

Part of the documentation package should include the creation of supplementary documents such as a User Interface Style Guide and/or Usability Guide. These documents should include topics such as the expected user experience, layouts, types of user experience elements, look & feel, navigation and standards such as language and accessibility. Having these guidelines at the start will help maintain consistency of design and construction, and are an aide towards helping you sell your project to the business. They will also insure that you have the right tools in place to meet the functional requirements before you commit to a technology.

Good examples of styles guides are hard to come by and most of the good ones were produced back in the early 2000's when we still had thick clients. Many of the new UI style guides produced for the web have good information but often lack concrete, project specific, guidance. This lack of specificity reflects the state of web design today, given the large number of web delivery frameworks and approaches. The goal of using the JSF component model is to eliminate all of this noise; insist on a style guide that is relevant to your project and presentation technology. Links to various style guide examples can be found here.

This point was captured in a recent blog entry by Cay Horstmann entitled Swing for the Web - Are we getting any Closer?. Key to success in JSF is the component suite you select. Like Cay, I don't want my projects to include developing JSF components and I don't want to be working directly with HTML and AJAX; I want someone else to work out the rendering. Look for an out-of-the-box component suite for your projects that matches the expectations set forth in the style guide. If you find yourself doing lots of AJAX and HTML, then you don't have the right set of components. If most of the ones you need don't exist, then you're using the wrong technology.

Unfortunately, as Cay points out, JSF is not quite at the point where many of us would like it to be, but we are getting much closer than we were. My recommendation is to stick with one of the three main choices; ADF/Trinidad, RichFaces, or Woodstock although there are other good third party implementations. You can go here to get a better idea of the suites available for your project. The goal is to know the requirements of your business sponsor, work with your UI team on the style guide, and select a component suite that will ensure the success of your project.


Creating storyboards creates a firm foundation for both the overall product concept and a strong information architecture. They are faster to develop than UI prototypes, and they facilitate communication between the UI and development teams. Designing your application right for JSF is key in both selling the technology and ensuring the success of your project.

In Part 1 we have established the ground work you need to create a good UI design for a JSF application. In Part 2, with our UI model in hand, we will begin to take an in-depth look at mapping these pieces into a JSF realization.


RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.