Evolving the UI
When using agile methods, it is not uncommon for the contents of a release to
change dramatically. This can create problems for up-front user interface
design as it is created with the expectation that certain functionality will be
present in the released system. As UI design is created across features using
techniques such as scenarios, it is especially vulnerable to changes. A user interface
design also assumes that functionality will be implemented in an order that
makes navigating from one feature to another possible. However, if the
customer's priorities do not match the flow created by the UI designer then the
design may have to change substantially.
One option for dealing with this uncertainty is to delay creating the UI design
until later in the release, after the corresponding functionality is complete.
The developers start by implementing the simplest possible interface that
delivers the required functionality. This does tend to produce a pretty ugly
user interface, but I have found that most customers tend to be understanding as
long as they are getting their desired functionality. I have been on a large
project that used this approach quite successfully: interaction designers were
brought in halfway through the release and suggested a set of improvements that
were incorporated before the release. However, the scope of the suggested
changes were limited based on the time constraints of the release and the
overhead of making changes to the implemented system.
I have also been on a project where this approach failed dramatically. While
the team's immediate customer was prepared to sacrifice look-and-feel for
features, when she went to demo the developed functionality to her board, they
were put off by plainness of the user interface despite the fact that the
application worked perfectly well. As they had already been sold on a specific
user interface design up-front (which had been implemented in Flash and we
were building a standard web app), in their eyes the app looked unfinished and
we looked unprofessional for delivering something that looked so basic.
If the application is supposed to be in a releaseable state after each and every
iteration then (depending on the end-user requirements) user interface design
really can't be dropped from the iteration. It needs to be part of the
completion of each story.
By far the preferred option is to have the user interface designer as part of
the customer team. The designer can adapt the design as the stories change, and
the designer can work with the customer team to get them to understand the
importance of usability and aesthetics. The problem is: I think that this
situation is quite rare. I, at least, have never worked on a team with a
committed UI designer.
Regardless, of the approach, we, as developers, need to be prepared for the user
interface to evolve as we incrementally build the system. Web applications have
some pretty standard approaches for helping the UI evolve: stylesheets (CSS),
templating (eg. SiteMesh, Tiles) and a fairly clean separation between
presentation and logic (eg. JSP, ASP.NET). All of these technologies make it
easy to rapidly and consistently change the interface across the application.
This separation also makes it possible for non-developers to dynamically modify
and evolve the layout, look- and-feel and content for a site.
Fat clients, on the other hand, provide much less support. Formatting and
layout is generally embedded directly in code. User interface code tends to be
highly duplicated. Try, for example, changing the size or colour of buttons
globally across an application. Think about how many times you've seen a web
site completely overhaul its look versus how many times you've see a new release
of installed software do the same. Although skinning has been a part of some
client applications for awhile, none of the core language GUI frameworks (that I
aware of) support it directly. XAML/XUL is emerging as one potential option for
providing this separation between logic and presentation. However, I think that
we can start by just writing better GUI code: creating wrappers for standard
controls, using widget factories, assembling user interfaces through composition
of components, using external stylesheets. The key place to start is by
focussing on eliminating GUI code duplication. Wizards and designers are one
the worst culprits in creating an unmaintainable, non-agile user interface.
So the first step in building evolvable, maintainable fat client user interfaces
is to eliminate forms designers (this is an especially hard pill for .NET
developers to swallow). What do you give up by stopping to use a forms designer?
One, you can no longer view your UI. Well, there is a simple and far preferrable
approach to dealing with this: drive your user interface using unit tests (as I
mention in my earlier post). The other is that you lose the ability to rapidly
prototype a UI. However, this is not really the case. The amount of time that
I've watched developers dragging around widgets to try and get pixel-perfect
alignment only to see it destroy when resizing the screen is eliminated by using
panel-based layouts to dock and size components. Using composition to assemble
a complex set of well-factored GUI components can be much faster than trying to
do so with drag-and-drop.
Fat client UI frameworks still need a lot of work to get to the point where they
are as adaptable as web applications. The main argument in favour of fat
clients is the richness of interaction that you get from native client controls.
However, with the rise of GMail style applications and the rebirth of
Javascript, this may no longer be the case.