User interface prototypes are an excellent means of
exploring your user interface, but unfortunately it is
easy to quickly become bogged down in the details of the
user interface and not see the bigger picture.
Consequently, you often miss high-level relationships
and interactions within your system's UI. User
interface-flow diagrams - also called storyboards,
interface-flow diagrams, windows navigation diagrams,
and context-navigation maps - enable you to model the
high-level relationships between major user interface
elements and thereby ask fundamental
usability questions.
In Figure 1
you see the start at a user interface-flow diagram,
called a Navigation diagram in RUP, for
the university system. The boxes represent major user
interface elements, modeled as you would
instances/objects, and the arrows represent the possible
flow between them, modeled as you would transitions in
activity diagrams. For example, when you are on the
Desktop screen, you can use the Students Icon
to take you to the Search for Students screen.
Once you are there, you can either go back to the
desktop (going back is always assumed) or go to the
Student Profile screen.
Figure 1. A UI flow
diagram.
|
User interface-flow diagrams are
typically used for one of two purposes. First, they are
used to model the interactions that users have with your
software, as defined in a single use case. For example,
a
use case can refer to several screens and provides
insight into how they are used. Based on this
information, you can develop a user interface-flow
diagram that reflects the behavioral view of the single
use case. Second, as you see in
Figure 1 they enable you to gain a high-level
overview of the user interface for your application.
This overview is effectively the combination of all the
behavioral views derived from your use cases, the result
being called the architectural view of your user
interface (Constantine
and Lockwood 1999). I prefer to take the high-level
overview approach, also referred to as the
architectural
approach, because it enables me to understand the
complete user interface for a system.
Because user interface-flow
diagrams offer a high-level view of the interface of a
system, you can quickly gain an understanding of how the
system is expected to work. It puts you in a position
where you can validate the overall flow of your
application's user interface. For example, does the flow
make sense? I am not so sure. Why can't I get from
Seminar Details to Professor Information? When
you are viewing the information for a seminar, isn't it
possible you might want to view the information for the
instructor of that seminar? Furthermore, user
interface-flow diagrams can be used to determine if the
user interface will be
usable. If there are many boxes
and many connections, it may be a signal to you that
your system is too large for people to learn and
understand. |
 |
Unfortunately the UML does not yet
support this sort of diagram. In the past I have used a
modified version of a UML collaboration/communication
diagram whereas others have suggested modified UML
activity diagrams or even UML state machine diagrams for
this. Our solutions all look something like what you
see in Figure 1, albeit using
slightly different notations. Because the UML is not
yet complete we find ourselves in exactly the situation
that the UML is meant to avoid - people using different
notations to model the software that they're building.
My hope is that the Object Management Group (OMG) will
eventually define a profile for UI flow modeling.
In fact, I'd really appreciate it if you could send them
an
email to that effect.
This artifact description is excerpted from Chapter 6 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
Translations
