 |
The user interface (UI) is the
portion of software with which a user directly
interacts. An essential user interface prototype (Constantine
and Lockwood 1999), also known as an
abstract prototype or paper prototype, is a low-fidelity model, or
prototype, of the UI for your system. It represents the
general ideas behind the UI, but not the exact details.
Essential UI prototypes represent user interface
requirements in a technology independent manner, just as
essential use case models do for behavioral
requirements. An essential user interface prototype is
effectively the initial state¾the
beginning point¾of
the user interface prototype for your system. It models
user interface requirements, requirements that are
evolved through analysis and design to result in the
final user interface for your system, enabling you to
explore
usability aspects of your system. |
|
Two basic differences exist between
essential user interface prototyping and
traditional UI prototyping. First, with essential UI
modeling the goal is to focus on your users and their
usage of the system, not system features. This is one of
the reasons you want to perform essential use case
modeling and essential user interface prototyping in
tandem: they each focus on usage. Second, your
prototyping tools are simple, including whiteboards,
flip-chart paper, and sticky notes. The minute you
introduce electronic technology to your prototyping
efforts you have most likely made a design decision
about the implementation technology. If you use an HTML
development tool to build a user interface prototype,
then you may immediately narrow your design space to the
functionality supported within browsers. If you choose a
Java development environment, then you may narrow your
design space to Java, and if you choose a Windows-based
prototyping tool, you may narrow your design space to
whatever is supported on the Windows platform. Right
now, you should be focused on requirements, not design;
therefore, you don’t currently want to use
technology-based prototyping tools. Understand the
problem first, and then solve it.
So how do you use sticky notes and
flip-chart paper to create an essential user interface
prototype? Let’s start by defining several terms. A
major user interface element represents a large-grained
item, potentially a screen, HTML page, or report. A
minor user interface element represents a small-grained
item, widgets such as user input fields, menu items,
lists, or static text fields such as labels. When a team
is creating an essential user interface prototype, it
iterates between the following tasks:
-
Explore system usage. Your team will explore
system usage via several means. First, you will likely
work together on a
whiteboard to discuss ideas, work on initial
drawing together, and generally take advantage of the
dynamic nature of whiteboards to come to an
understanding quickly of the portion of the system you
are discussing. For example, with the university
system, you may gather around a whiteboard to make an
initial drawing of what a university transcript would
contain or what a seminar enrollment submission would
contain. Second, as you have seen,
essential use case modeling is an effective
technique for understanding the behavioral
requirements for your system.
-
Model major user interface elements. Major user
interface elements, such as potential screens and
reports, can be modeled using flip-chart paper. I say
potential because whether something is a screen or
printed report is a design decision¾a
university transcript could be implemented as an HTML
page your users view in a browser, as a paper report
that is printed and mailed to students, or as an
application screen. Each piece of flip-chart paper is
given a name, such as Student Transcript or Seminar Enrollment Request, and has the
appropriate minor user interface elements added to it
as needed. Pieces of flip-chart paper have several
advantages: they can be taped to a wall; they are good
for working in groups because they make it easier for
everyone to see and interact; they are large enough so
you can put many smaller items such as sticky notes on
them; you can draw on them; and they can be stored
away between modeling sessions.
-
Model minor user interface elements. Minor UI
elements, such as input fields, lists, and containers
(minor UI elements that aggregate other minor UI
elements) are modeled using sticky notes. Constantine
and Lockwood (1999) suggest using different color
notes for different types of components, for example,
bright colors (yellow or red) for active user
interface elements such as input fields versus subdued
colors (white or tan) for passive interface elements
such as containers. Figure 1
depicts an essential UI prototype to enroll students
in seminars. The Student name sticky note is a
container that includes four active elements: First
name, Surname, Middle, and Title.
The other sticky note represents a list of the
seminars a student has taken or is currently enrolled
in. Notice how each sticky note has a name that
describes its purpose, but not how it is implemented.
You can look at the sticky note and immediately know
how it is used. Different sizes of sticky notes are
used, indicating the relative size of each UI element.
Also notice how the relative order of the UI elements
are indicated by the order of the sticky notes: a
student’s title comes before his first name, then come
his initials and his surname. This ordering may change
during design but for now it is close enough.
Whenever you realize you may need a minor user
interface element, you simply take a sticky note,
label it appropriately, and place it in the general
area on a major user interface element where your
stakeholder believe it belongs. Sometimes you
identify a minor UI element that may not have a major
UI element on which to place it. Don’t worry. This is
an iterative process, so attempt to identify an
appropriate major UI element and continue. The very
fact that sticky notes do not look like a real GUI
widget is a constant visual reminder to your team that
you are building an abstract model of the user
interface and not the real thing. Each sticky note is,
effectively, a placeholder that says you need
something there, but you don’t yet know yet the best
way to implement it, so for now, you want to leave it
open.
-
Explore the usability of your user interface.
Highly usable systems are learnable, they enable user
productivity, their use is easy to remember, and they
are supportable.
Figure 1. Essential UI
prototype for enrolling in seminars.
Let’s examine
Figure 1 in greater detail. This prototype was
created using a standard piece of flip-chart paper; you
should use one piece of flip-chart paper per major user
interface element. The name, in this case Enroll in
Seminar, is typically written across the top. Notice
how there is two containers, which I drew on the paper
to help bound different sections of the UI. The pink
sticky notes, such as Student Number and
Student Name, represent input fields, whereas the
yellow ones are display only. Student Name is
interesting because it is a bit of a cheat, listing four
separate data elements on the one sticky note. I will
often do this when I know some thing always come in a
group and when I think I will need the room, which, as
you can see I do. The blue sticky notes, such as
Search and Help, represent actions items.
Action items are often implemented as push buttons,
function keys, or “hot key” combinations, such as
CTRL-SHIFT-S. All of the lists support selection of the
information within them, for lists that don’t support
selection, you should indicate this information.
I like to ask questions about how
your essential user interface prototypes would be used.
For example, what should happen if a student really
wants to enroll in a seminar that is currently full?
Should she be given the opportunity to add herself to a
waiting list? If so, how does that affect the user
interface? You likely need to support the capability to
indicate a waiting list of X number of people
already exists, as well as a way to request being added
to, or removed from, the waiting list. Should obtaining
detailed information about the professor teaching a
seminar be possible? Should obtaining detailed
information about the seminars in the prerequisite list
be possible? In Figure 1 you see
it is possible to search for a seminar by inputting its
number or name. Should searching by the department that
offers the seminar be possible? Or, by day of the week
on which it is offered (when I was a student I had a 1.5
hour commute, so I tried to enroll in seminars that all
were held on the same days)? Or, by the name of the
instructor teaching it? These are all interesting
questions, the answers for which could potentially
result in new requirements. However, always remember
that your project stakeholders are the official source
of requirements, not developers. If you identify some
new functionality that you think is required you need to
convince your stakeholder that it’s a good idea, have
them prioritize it, and add the new requirement to the
stack. When you’re following Agile Modeling’s practice
of
Active Stakeholder Participation this is very
easy to accomplish because your stakeholder(s) would
have been part of the modeling exercise to begin with.
We have been jumping through hoops
not indicating implementation decisions for the major
user interface elements. The reality is that you know
that the seminar enrollment prototype is going to be
implemented as either a screen or an HTML page, so why
not admit it? When a major user interface element
contains one or more minor user interface elements that
permit editing, then you know it’s going to be a screen
or a page. When it contains no editable elements, then
it will be a report. If you are going to a lot of
“unnatural” effort to make your major user interface
elements independent of implementation technology, then
you may want to loosen up a bit and distinguish between
reports and screens/pages. In fact, once the
architectural decision of how we’re going to deploy the
system has been made, I have a tendency to draw screen
sketches on a white board which enables me to get a more
accurate rendering of what the screen/report may look
like. However, as always my advice is always to choose
the most appropriate tools and techniques for your
situation.
This artifact description is excerpted from Chapter 6 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
This is the book to
read about essential modeling. |
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
|
|
|
Maturing Usability: Quality in Software, Interaction,
and Value contains a collection of
writings from various experts in the field of usability
and user interface development. It provides an
understanding of how current research and practice has
contributed towards improving quality issues in
software, interaction and value. I wrote chapter 4 which
describes how usability fits into the Agile SDLC.
Other chapters look at how using development tools can
enhance the usability of a system, and how methods and
models can be integrated into the process to help
develop effective user interfaces; theoretical
frameworks on the nature of interactions; techniques and
metrics for evaluation interaction quality; the transfer
of concepts and methods from research to practice;
assessments of the impact that a system has in the real
world; and how to focus on increasing the value of
usability practice for software development and on
increasing value for users. A balance between
theoretical and empirical approaches is maintained
throughout, and all those interested in exploring
usability issues in human-computer interaction will find
this a very useful book. |
Translations
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
|
