|
"Design and Construct" is a
phrase which has recently been adopted by the Civil Engineering
industry to reflect a project where the same contractor both
designs and constructs the same project. For many many years such
an arrangement wasn't permitted on large civil engineering
projects for safety and quality reasons. It shows how far ahead
civil engineering is from software engineering that the difference
between designing and construction as well as the importance of
having a separate design phase, was recognised over 100 years ago.
Today many software projects still suffer from a lack of distinct
design phase, and practioners often bluff through claiming they
are using and iterative methodology and design and construction
are never clearly distinguished.
This month we take a look at two
books from authors who clearly know the difference between design
and construction and who also clearly know their strengths and
have chosen to write about one or the other.
So two complimentary books, reviewed
in reverse order. The first tells you how to construct a
technically competant user interface and the second tells you how
to produce a design for that construction phase.
Constructing the User Interface with
Statecharts
by Ian Horrocks, Addison-Wesley, 1998
This is a thin and highly focused book at just
over 200 pages of text. My kind of book. If you're like me and
don't have a lot of time to wade through repitition in big thick
books then you appreciate a thin and focused book when it comes
along. I read it on a flight from Dallas to Tokyo, more or less
cover to cover. Definitely, my kind of book :-)
For more than 10 years I have sought a solution
to the problem of determining the current "state" of a
User Interface. I have never been satisfied with existing methods,
code samples, or books on the topic. Generally most windowing
environments lend themselves to messy and monolithic code which
can never quite tell you what state its in and where it came from.
This information would be useful as it makes determining where to
go next so much easier. Simple electronic machines rely on Finite
State Machine design to solve this problem, however, such a
solution has never been feasible with windowing UIs due to the
inifite complexity and exponential growth of the number of finite
states. So when I stumbled across a book which claimed to have
solved this problem I was keen to read it.
So this is a book which promises the "Holy
Grail" of a deterministic user interface in a windowing
environment. Finally an answer to questions like "If we are
in state 107 and OK Button Pressed, what next?". This is a
book for User Interface Architects - the people who have to figure
out how to wire all the code together to produce that beautiful
a-modal interaction design which the user is expecting. So does it
match up to expectations?
Definition of Scope
Horrocks starts the book with a super
introduction. It shows us that he clearly understands the
difference between the design of the screens and what goes on
them, from the design of the code which puts that information on
screen. He also defines the scope of the book and tells us where
the focus will be. So refreshing to know that we have a book with
depth and focus rather than a superficial scanning of a topic. He
goes on to give us a definition of his terms from screen design
and UI code design. He calls the screen design, "User
interaction design", which involves the graphic layout and
user interaction. Laura Arlov calls this the "Navigation
model" in her book. Personally, I prefer Horrocks definition.
Horrocks reserves the term "User Interface Design" for
the design of the UI Code. Personally I found this a little narrow
but its good that he makes it clear how he is using this term
throughout the rest of the book. His final section on "technique
or method" rather spoiled it. He is firmly in the camp where
he believes software is a "people" thing and process
can't really help. I think that he later contradicts the point
toward the end of the book but it left me wondering. Particularly
as this web site is dedicated to the notion that process can and
will make UI Design better and more reliable.
Sceptics
The second, third and fourth chapters presents
the case for the book. This is obviously aimed at the sceptics and
those who believe that all is well and no change is necessary. I
think that Horrocks has made a concious decision to avoid
political debate or align himself with any faction in the UI
world. He introduces the term Direct Manipulation which he uses to
refer to OO UI in general. Later when discussing his own technique
he carefully steers clear of introducing the term MVC and any of
its variants. It is clear that he wanted to put across his own
message and didn't want it lost in amongst some of these other
emotive issues in UI Design.
Its obvious that the author wasn't familiar
with Java 1.1 Event model but it detracts very little from the
book as a whole. He walks us through some different methods of
constructing a UI including a look at APIs, and visual tools then
gives us some background on the code bits that go together to make
up a User Interface. Chapter 3 presents the nub of the argument
and is compelling with 3 key examples Horrocks explains why a
better, more deterministic approach is needed. He clearly
demonstrates that current UI architectures can lead to poor code.
By the end of chapter 4 we have established
that the main premise of the book is a pure MVC architecture with
a separate controller layer is possible and will scale to large
systems by using the Statechart Notation and Design technique.
Statecharts
Chapters 5 through 9 then walk us through how
to use Statecharts. Chapter 5 takes a brief tour through why
Finite State Machine is not good enough. I was slightly perplexed
by the bizarre suggestion that one defines the User Interaction
Design with a natural language specification. To me this seemed
ridiculous, I would always build a paper prototype but I have
since learned that natural language is an often used technique.
Horrocks goes further and makes an attempt to debunk prototypes as
a suitable way for designing the User Interaction. Personally, I
would recommend that the experience UIDesign.Net reader skip the
first few pages of chapter 5. So with FSM out of the way, we are
free to make progress with Statecharts which as he points out are
already part of UML. Super!
Interesting, Horrocks advocates the Statechart
as a good way of communicating the system operation to the client
or users. This is often a claim made by Use Case advocates.
Horrocks avoids mention of Use Cases just like he steered around
MVC and other emotive terminology. I would be interested in trying
Statecharts as an alternative to Use Cases for such design
definition. I was completely sold on the Statechart technique by
the end of Horrocks argument, though I didn't wholely buy into the
concept that they could be used to write the requirement and
validate with the client or Users. Like Use Cases, I believe that
using a design technique to document requirements is fatally
flawed and leads to a design being written by non-skilled
designers when what they really wanted to do was define a
requirement. I wondered if this stuff had been added as an
afterthought.
Chapter 6 started in the same vein, many
apologies and I wondered if this had all been added to placate
reviewer feedback as it seemed irrelevant for the fresh reader. He
repeated his belief that design was an art rather than a
repeatable process and then went on to make a profound
observation. He had refused the idea of extending the existing
Statechart Notation as he wanted to keep it simple. I was left
thinking, "If only the UML people had thought the same way"!
The rest of chapter 6 through 8 explain how to use Statecharts
including explaining Concurrency and how to represent it. I got
the impression that the author was giving advice learned from hard
experience.
I found Chapter 9 particularly good. Horrocks
Design Heuristics are really good advice and he makes a number of
good observations often related to the quality of the original
systems analysis or the User Interaction design. There is a
particularly good section on how to avoid introducing dependencies
across concurrent parts of a design. I felt that this chapter
could be improved with some better visual communication of the
design hints that are presented.
Examples, Coding and Testing
Chapters 10 through 12 present three worked
examples in psuedo code, 13 is the real thing - what we all bought
the book for! How to code a Statechart UI. Again its presented in
psuedo code and this I'm afraid is the key area where I fault the
book. I do not feel that psuedo code presentation is good enough
for such a book. I would like to see real code examples and maybe
even a CD-Rom containing those real code examples. This would
greatly improve the value proposition of the book and ensure that
many more readers took up the technique. Currently, the difficult
part of how to use the technique in a real environment is left as
an exercise for the reader. How many readers will follow through
and adopt a proper implementation? Not so many, I fear!
Chapter 14 covers how to test a Statechart
implementation and finally Chapter 15 gives an overview and
evaluation of the technique. This final chapter seeled the book
nicely for me. It was obvious that Horrocks is an experienced
practioner and the book is written based on real project
experience. He makes the profound observation that a weak
development team will never buy-in to the technique and will never
understand why its necessary to have a deterministic User
Interface with a clear "state" at any given time. This
is so true. How many architects have had good work undone by
coders who simply didn't get the big picture?
Summary
250 pages, 1cm thick. An excellent book which
tackles a hitherto unsolved area in UI Design. It goes through the
background material clearly and then presents the new material
followed with a set of Case studies. The author is experienced and
the book is polished with little anecdotes from that experience.
For the me the book falls down with its psuedo code presentation
of the examples. If Addison-Wesley agree to a 2nd edition then the
author should seriously consider presenting the examples in real
code, in both Java JFC and Visual Basic, with the source on
CD-Rom.
Recommendation
4/5 - An important "must have" book
for serious UI Architects. |
