Contents

Reader ROI

Readers of this Chapter will build upon the concepts
introduced in previous chapters, specifically focusing on the User Interaction
architectural capability.

Figure 1. Recurring Architectural
Capabilities

The User Interaction architectural
capability focuses on the improving the user experience (UX) associated with
applications and solutions.

Topics discussed in this Chapter include:

The impact of bad user experiences (UX)

Prioritizing UX design

Cognitive Friction

A Framework for UX

Acknowledgements

This Chapter is based upon presentations
and keynotes given by Simon Guest.

What is Architecture?

Someone once said “architecture is the
balance between art and engineering”. If we think about building architecture, such
as the Acropolis, you can see the blend of art and engineering there. It’s
beautiful, but a lot of engineering principles and concepts have gone into it.

Does the same apply to software
architecture? Is there a balance between the art and engineering here as well? The
engineering is obvious, most architects you talk to today all have different
engineering concerns whether SOA, ESB, or a database. A lot of architecture
today is focused on engineering and infrastructure. So the question isn’t “What
is Architecture”, the real question is “Where is the art in software
architecture?” Is there an art and does the analogy ring true?

Some people would say that the art is in
the beauty of the design, or the beauty of this particular Visio diagram. This
is incorrect - art should be about the user experience (UX). It should be the
interface we give to users and the applications we give to them. This brings up
the core problem: UX often comes last in most projects.

There are dedicated architects or teams that
will work for 80-90% of the project on solution infrastructure, making sure the
Web services are working well and the database is consistently available. Towards
the end of the project schedule there is a mad scramble to move the solution
into production when someone suddenly realizes the user interface still needs
to be developed. This results in another scramble knock together a simple user
experience (UX) in a week or so. The UX is the user facing component of the
solution – why shouldn’t more time be spent on it?

We have all seen good examples of bad UX. Bad
UX takes multiple forms - green on black, black on green, buttons that should
be links, links that should be buttons, dialogs that do not make any sense, and
confusing messages in error boxes. Figure 2 is a good example of a bad UX.

Figure 2. A good example of bad UX

Which button should one click? This type of
confusing dialog frequently appears in both off-the-shelf and custom solutions.
Error messages are problematic because reliability is key factor in UX - having
problems pop up at the wrong time can detrimentally impact the user’s opinion
of the solution.

Author and consultant Alan Cooper has
coined the term “Cognitive Friction” to explain this problem. By providing a
bad user experience we are introducing cognitive friction to the user’s work
day. We are making it harder for users to think about how they should be using
our applications - when they shouldn’t have to think about using them in the
first place.

Why is UX always a low priority on most
projects? Most organizations know their environment, their users and the hardware
and software deployed across the organization. Many organizations also have a
dedicated development staff. These are developers whose full time jobs are creating
applications that deliver value to the organization. Most organizations also have
stable business capabilities (e.g. the products being manufactured this week
will most likely continue to be manufactured next week, next month, even six
months down the line). These are typically not organizations that are
manufacturing products one week and morphing into a services organization the
next. Applications tend to mirror fairly standard, fairly stable business
capabilities.

Some of these organizations react to bad UX
by hiring designers. Unfortunately the designers are usually brought in late in
the project, long after major UI decisions have been made. Designers should be
added at the beginning of a project to maximize the impact they can have on the
UX.

In some organizations bad UX causes users
to become apologetic. Users feel the need to apologize for not understanding
how to use the applications that IT has delivered to them. If a user doesn’t
understand how to use an application, the most likely problem is the UX, not
the user.

Introducing a Framework
for UX

We need to fix this problem - we need a new
perspective. We need a new way of thinking not only for UX, but for UX when
talking to this architecture audience. The goal of this chapter is to introduce
a framework you can use when facing these problems. The UX Framework is
illustrated in Figure 3 below.

Figure 3. A framework for thinking about UX

One way to build a framework for UX is by asking
users questions about their problems and concerns. Last year we conducted an internal
study by asking users these types of questions – we received some fairly surprising
answers. Here is a couple of the responses we received:

“Is
this application designed for me or an engineer? I don’t understand how to use
this.”

“The
performance is horrible. This application is totally unusable.”

Let’s take a detailed look at the layers in
the UX framework.

Figure 4. The three aspects of the Interface layer

Interface

Many of the types of questions we were
asking could be categorized as “interface”. The Interface is the divide between
what people see on the screen and what users actually do. There are three
aspects to consider within the Interface category: Personas, Productivity and
Performance. We examine these aspects in greater detail below:

Personas

When an IT group is thinks about UX they
will stumble across the concept of a single, generic user (e.g. “The user
won’t do this, what the user really wants is this.”). This means that everyone
on the development team has their own idea about who this user is. The UX Framework
recommends using personas instead of a generic user. A persona is a fictitious
person that is based upon as many real-world characteristics as possible. Here
is a good example:

Sally is a “Road Warrior,” - here is a
summary of her persona:

38, Married

2 Children

5 years of computer experience

Mostly Windows/Office, experienced with
PowerPoint

Has between 10 and 20 clients – mix of
small and medium businesses

Engages in pre-sales

Relies on laptop and mobile phone device

Once a summary is developed it’s easy to
build up a picture of what your personas can and cannot do. By using personas
in your project you tend to focus upon the things that really matter to your
users. For example, if we are designing a call center application and we know Sally
spends most of the day with customers – we also know she needs to be connected
by a mobile phone or via Internet kiosks.

We can also develop other personas –
typically you will develop multiple personas for your solutions. Here are three
additional examples:

Derek is a call center operator – here is
a summary of his persona:

spends 8 hours/day talking on the phone
with mostly aggravated users

needs to be super-productive - If he can
access call records more quickly he can shave a few seconds off each
call, servicing more customers.

Jim is an executive. – here is a summary
of his persona:

spends 8 hours a day thinking about
customers, looking at the big picture

thinks a lot about what should be done
next, what kind of strategy the organization should take

needs an abstract view, providing top
level information as quickly as possible

Peter is a systems administrator – here
is a summary of his persona:

a member of the IT group

going to have to support our application

responsible for keeping everything up to
date

spends his entire day supporting users

needs to do very complex things using
the smallest amount of time (using scripts if possible)

Why not simply use real users? Unlike real
users, personas let you abstract a little, changing the personas profiles to
meet your application needs. It’s also important to realize that real users
often do not really know what they want. While this may sound somewhat pompous
it’s actually true – users are often not able to articulate their needs and do necessarily
not have a good grasp of what goes into a good UX. Personas enable us to be abstract
and think out of the box about UX. Personas let us move from conversations of
“Most users will have access to a printer on that screen,” to “Derek will have access
to a printer as he works in the call center, but Sally works on the road so may
need another option for printing.” Personas make you think about different
people differently. Personas enable us to move from conversations like “This
would be quicker to develop as a Web app.” to “For Sally and Peter, a Web
interface may make sense. But Derek has a lot of keyboard shortcuts he’s used
to, so maybe we should think about something different for him?”

Persona Recommendations

Defining Personas should be the first
step for any design experience.

Personas can help resolve arguments in
the development team and help influence which bugs should be fixed or which
features should be cut.

Productivity

When you deliver a new piece of software to a user you normally
see a productivity curve similar to the one shown in Figure 5. Initially,
productivity dips as the user adjusts to a new application. Eventually the user
becomes more familiar with the new application and their productive rises as a
result of using the application (preferably to a level higher than before the
application was deployed).

Figure 5. Productivity versus time for
the UX

This productivity curve in Figure 5 is
defined around three stages:

Discovery – playing around with the
features

Learning – getting comfortable with the
new application and integrating it with how you do your job

Mastery – increased productivity from new
application use

The productivity dip in Figure 6 can be
reduced by making applications more familiar to our users, thereby reducing the
level of Cognitive Friction. A well-designed UX can reduce the productivity dip
that typically occurs when a new application is deployed (Figure 6).

Figure 6. Reducing the productivity dip with familiar
elements

We can see evidence of reduced productivity dip by comparing
UX from unrelated websites. Many websites use tabs, search and shopping carts –
this makes it easier for a user to interact with a site, even if they have
never visited the site before. Listed below are a two such sites:

Figure 7. Numerous sites use familiar
elements

You don’t need to read a manual to use
these sites because the concepts they use are familiar. As architects we often
forget familiarity. We look for beautiful and obscure components and build
interfaces that no one has ever seen before. We need to address this problem and
figure out how to make things more familiar.

Figure 8 illustrates a typical scenario –
an organization using Seibel CRM was unhappy with the default Siebel client.

Figure 8. A typical application

The customer went through an internal project to move all of
the CRM data to the Web using a Web services layer in front of the Siebel
database. They then exposed their data using a custom ASP.net interface (Figure
9).

Figure 9. A first attempt at a better UX

Soon after the application was deployed the
customer learned that, despite being the latest technology (SOA, Web), nobody
was using it. The customer later learned that their traders were using an
entirely different approach to working with the CRM application. The traders would
take a call, and enter the information into Outlook instead of re-entering
information into the new Web application.

The project was redesigned to feed Web services
directly into Outlook. This initially presented some interesting technical challenges.
The Siebel CRM data was used to create a set of objects within Outlook. These objects
looked and acted like normal Outlook folders, contacts, and calendar items. The
end result was a CRM interface that was better integrated into how the traders actually
performed their work.

Figure 10. Refactoring the application
into a familiar interface

The new approach avoided the productivity
dip mentioned earlier because the UX was implemented using the familiar
environment of Outlook. Training time went from 1.5 days for the Siebel client
to 20 minutes for the new Outlook integrated UX. People already knew how to
make contact, they knew how to drag-and-drop calendar items around, so they did
not need training, they just needed to be given the application. All they
needed were the clients and they were good to go.

If we go back to personas for a moment, it
is worth noting that we can take the personas and map them to the productivity
curves. Consider the Sally persona. Sally has been using computers for five
years - she is going to experience an average drop in productivity for this
application because of her relatively low level of computer experience. The Derek
persona represents a much more experienced computer user. Derek is much more computer
proficient and will have a much smaller dip in productivity. The Jim persona
may experience a deeper dip in productivity depending up his familiarity with
Outlook. Jim may actually give up trying to use the new application - he is a very
busy guy with little time to learn new applications. Perhaps we can better help
Jim by taking a closer look at his profile and deliver a different, more
streamlined interface (such as a wizard, portal or similar UX that would be
more valuable to him).

Productivity Recommendations

Often the most productive user
experiences are not the most elegant or best looking. Mainframe green
screens were not very pretty but the keyboard shortcuts used by such
screens enabled users to be far more productive than a sleek, mouse-driven
GUI.

Define the personas that make sense for
your application and map productivity curves to your personas to help
determine any issues or UX problems you might experience.

Look at existing experiences to see if
there is anything you can extend. If people are already using Outlook, or
Office or another application, is there anything you can tie into there to
make them more productive rather than just starting from scratch?

Performance

The third and final aspect of the Interface
layer is performance. Performance is interesting because a lot of performance analysis
tends to focus on engineering (e.g. “we need this service and this client to
have a latency of x milliseconds” or “there is no way we could survive
having more than 1.2 seconds between these updates.”). While these types of service
level agreements (SLAs) may be true for industries such as financial, or
manufacturing, performance is often about tolerance, not latency. Tolerance in
this sense means focusing on what the users will or will not tolerate. There
are two types of user tolerances in most projects:

Domain-specific tolerance is when people know that something should happen quickly (or
quicker) and does not. Domain experience enables users to know how the
tools they use should work – if they do not work in an expected manner
they will begin asking why the application is so slow.

Non-domain specifictolerance is when a user does not really know what is
going on. Tolerance for non-specific domains is greater, causing users to
eventually start asking how long the application will take to respond.

When looking at performance and
applications, be sure to look at the numbers and see if there are service
levels that must be met. It’s also worth reviewing the application components
from a tolerance perspective. How tolerable is this user or persona going to be
for this particular function?

We can sometimes address tolerance issues on
the front end using technologies such as AJAX (asynchronous Javascript and
XML). AJAX is a set of Web techniques that enables more interactions and
granularity in the browser. Without AJAX web pages are rendered directly in the
browser – updates to the UX required expensive post-backs to the server. With AJAX, the page gets rendered to the browser, but behavior gets handled in the
background. We can give people more feedback and show them what is going on in
a much better way. It’s interesting to note here that Microsoft released the Microsoft
Remote Scripting Toolkit in 1999, effectively supporting the same technologies,
concepts and architectural approaches used by AJAX today.

Performance Recommendations

Avoid getting drawn into conversations
about “millisecond” response times. While “sub-millisecond” response times
may well be a valid SLA, UX perspectives are more about user tolerance
instead of application latency. There may be areas of the UX that can be
modified to enable greater user tolerance.

The principles behind AJAX stretch well
before 2004. The acronym is fairly new but the technology behind it is
not.

Figure 11. The three aspects of the Interaction layer

Interaction

Interaction is about not what the user
interacts with, but how they interact. The Interaction layer of the UX
framework focuses on the following types of questions:

“Why
doesn’t this application help me get my work done?”

“If
it wasn’t for this app, I would do this differently.” (forcing people to work a certain way)

“Okay,
something’s gone wrong, whom do I call?”

These types of problems fit into a middle
tier called Interaction. The Interaction layer focuses on three aspects Purpose,
Preference and Proactivity. We examine these aspects in greater detail below:

Purpose

Most applications and architects get confused
by differences between tasks and goals. I need to create a new
document, type some text, format some text, and send it to my editor. Is this a
task or a goal? It’s actually both. Each of those steps is a separate task, but
my ultimate goal is to send something to my editor.

Office XP provided dynamic menus which only
showed the most commonly used menu options, hiding all of the others. This was
bad UX because it filtered out the ability to do particular tasks based upon
how often these tasks might be performed. Office 2007 fixes this problem by
applying context between each task. For example, if you launch Word and start
typing some text the UI ribbon displays the text options for that particular
function (bold, styles, and so forth). If you then insert a diagram, the ribbon
automatically changes to display diagram formatting and editing options. Once
you start typing again the ribbon switches back to displaying font formatting options.

This is a good example of how you can
switch between contexts in the UI without hiding things from users. The UI ribbon
can also be customized or reused by ISVs, enabling anyone to handle contexts
and rules in customer applications.

Purpose Recommendations

Do not let customers confuse tasks and
goals in applications.

Focus on the entire application - think about
the context for each step. Check out the Office UI licensing and see if
ribbons are a good fit for your applications.

Preference

Preference is looking to see if there are
multiple ways to do the same thing; reaching the same goals using the right set
of tasks. If a goal has been established there are probably multiple ways of
getting there.

Microsoft’s internal invoicing system is
called MS Invoice. When you buy something from an external vendor you receive
an invoice and an e-mail. To research an invoice, users must open a new
instance of Internet Explorer and go into MS Market (Microsoft’s vendor
marketplace). Once in MS Market you must copy and paste the invoice number from
MS Invoice into MS Market, then navigate through several screens to find the
original order. The user must then Alt+Tab back over to MS Invoice, navigate through
several additional screens, and approve the invoice for payment. The entire
process typically takes 25 minutes or more.

A user’s goal in this scenario was is to
get more information about an invoice prior to approving or rejecting it. The
MS Invoice and MS Market applications force users to work in a specific manner.
If these applications did not exist users would probably simply use the phone,
Outlook, or send an instant message to the person that made the original order.

Instant messaging is becoming a favored means of communicating
within the enterprise. It may be possible to being the IM UX into another
context. For example, the Encarta bot is a “buddy” that you add to your IM list
in Windows Messenger. Encarta bot is a scripted front end that interacts with
the Encarta database. If you ask it some questions it will attempt to respond
to you using the Encarta database. For example, if you ask “Who is the
president?” it will ask me which country. If you reply with “USA” it will respond with “George Bush” (see below).

Figure 12. Interacting with the Encarta
bot

What the application can then do is offer
me more interaction, so it takes me to a Web page in the same context as the
Web client and shows me a picture of George Bush.

We could utilize a similar UX to make
invoice research and approvals easier for users. When a user checks e-mail an
Invoice bot could notify the user when a new invoice exists and ask how to
proceed. An example of this improved UX appears below:

Figure 13. Using a specialized bot for a contextual UX

This completely fits in with the context, completely fits in
what we are doing. This approach moves the hard work of doing all of the look
ups away from the user and into the back end (where it belongs). This is an
example of a UX that fits in with what we are already doing and what we want to
do.

Figure 14. The original MS Invoice
architecture

In the old system we had some services, a
Web server which exposed the MS Invoice site and an Exchange server which sent
out email reminders. If we move to a more natural IM solution, the architecture becomes much
simpler.

Figure 15. The contextual bot
architecture

Preference Recommendations

There are many ways of reaching the same
goals using a set of tasks. Instead of just diving into a set of tasks,
step back and say “What is this persona trying to do?”

Building a set of personas will help you
realize this efficiency. Thinking “This persona is not going to want to
dial in from this location too often,” gets you thinking about different
things.

Also look at applications that customers
are using to see how you can integrate. So if everyone in the organization
has MS Messenger installed, great! How can you use it? What can you do to
kind of plug in there instead of creating something that is taking people
out of their regular day?

Proactive

The third and final aspect of Interaction
is Proactive. We have all been through this, we release a rev of our
application and we feel really good about it. The application is a hit! Or at
least we think it was a hit. We did not hear anything from our customers so we
assume nothing is wrong. This scenario raises an interesting point because
reactive feedback is very common. When we hear from customers its usually bad
news about our applications (e.g. “this thing is broken” or “this thing wouldn’t
install”). No news is not necessarily good news – in scenarios like this one
must be proactive.

There are several ways you can be proactive
and open up feedback channels to your users. The first approach is actually quite
simple - a user rating scale for an application. Every screen in the application
has a 1-5 rating (similar to how you might rate a book on Amazon.com). This approach
enables users to provide immediate feedback (e.g. “I didn’t quite like this,
it’s a 1,” to “Really loved it, it’s a 5.”). An average of the rating score
across a several screens can be used to determine what should be improved in
the next version of the application.

When Microsoft sent Vista to a number of families for testing the
OS included an option called “send a smile.” This option displayed a red and
green smileys that appeared in the system tray. When users found something they
really liked, they clicked on a green smiley. When there was something they did
not like they clicked on the red smiley. Regardless of which color they clicked
on, a screen shot was created and automatically submitted back to Microsoft
with some explanatory text. This is a great example of a non-intrusive UX for
gathering feedback, and also coupled with the screen shot of the UX.

Another way of getting proactive feedback
is to have events and statuses that get logged back to a server for the support
staff. This avoids having users call the Help Desk and cutting-and-pasting stack
traces into an e-mail.

The third thing is thinking about effective
status updates. What can you do in your application to let users know what has
gone wrong? Things do go wrong. People will naturally accept that, but is there
something you can do above and beyond, to maybe send them an e-mail, or maybe
in another application actually give them some kind of status? You would not
believe the kind of positive feedback you will get from users who say “I
realize something has gone wrong, but now I have an expectation of when this
thing is going to be up.”

Proactive Recommendations

Think how users are going to provide
proactive feedback. Think about those types of channels that you can open
up.

Think about a strategy for when things go
wrong. Thinks will go wrong. What do you need to circumvent that?

Wherever possible provide a status. Let
people know what is good and bad and what their expectations should be.

Figure 17. The three aspects of infrastructure

Infrastructure

The final set of concerns focuses on the
infrastructure of the application. These are the types of user comments
typically associated with infrastructure:

“To
be honest, I couldn’t even get the darn thing installed.”

“It
crashed the first time I used it. I don’t think I’ll try that again.”

“This
thing is sure ugly.”

These types of problems fit into a foundational
tier called Infrastructure. Infrastructure focuses on three aspects: Platform,
Proven and People (developers and designers). We examine these aspects in
greater detail below:

Platform

Infrastructure begins with the platform. Once you have the
other areas covered, how should we create our application? There are a
phenomenal number of choices today: Win32, Windows Forms, Flash, Java Swing, and
Windows Presentation Foundation (WPF).

Figure 18. The WPF platform

WPF is interesting at the technical level,
but there are three aspects to it that are worth reviewing:

WPF adds a new engine – the evolution of
GDI and GDI plus. The new engine is built upon 3D piping.

WPF is a framework for both developers
and designers.

Integration: WPF is fully integrated into
the platform.

WPF supplies niceties that you can add to your current
applications – nimbus, halo, drag and drop and more. WPF also enables applications
that could not have been built before. For example, Zurich Airport mapped in WPF for traffic controllers so they can zoom in and get a view of the entire airport.
This is a very rich UX that you could not have been easily built by application
developers prior to the advent of WPF (see the Case Study in this Chapter for
more information).

Figure 19. WPF separation of style,
layout, and data

The separation of style, layout, and data
is an important concept. WPF uses an markup language named XAML. XAML has a two
way relationship with the underlying code – the XAML can be maintained as XML
or with code alone. XAML can also be loaded directly into the browser using
XBAP (XAML Browser APplication). XBAP is a new Windows technology used for
creating Rich Internet Applications.

There are two main ways of deploying a WPF
application: You can create a client executable that runs standalone or an XBAP
that runs within the context of a browser. Regardless of the technical implications
of selecting one over the other, there are a number of design implications associated
with each that should be considered.

Depending upon your application
requirements, an XBAP may offer the best end user experience since it is the
easiest way to deploy an app (although there are security tradeoffs when running
in a browser-based sandboxed environment). Deployment, however, is only one
aspect of an application. Moving from a WinForms application to a browser-based
XBAP raises several design considerations. For example, the original client
application may have relied upon "right click context menus". While
this feature is fairly simple to simulate in an XBAP, most users may realize
they can right click on a Web page and not get the standard browser right-click
menu.

Platform Recommendations

WPF is a declarative, vector-based, resolution independent platform for
building rich user experiences (browser-based via XBAPs or incorporated
into a traditional Windows application).

When thinking about deployment, think
about the underlying design elements and principles and make sure they go
across as well. Just because you can easily deliver a different experience
from a technical standpoint doesn't mean that you can rely on the same,
underlying user experience principles (e.g. right-click menus in a
browser-based application).

Proven

Infrastructure also contains a number of
elements that relates to proof. Proof comes down to reliability and how do you
make an application reliable. This is the type of question many of us get
everyday. The question instead should be: How can we make this application more
proven?

Ultimately, reliability is a bad proof. One
of the biggest hurdles for building trust or making your application proven is
time. You cannot deploy version 1, 2, or 3 of an application and say “Wow, this
is so reliable,” because it takes days, weeks, or months to build that proof
point. Once that trust is lost, once the application crashes, dies or does not
work as expected, it’s very difficult to recover.

For example, one of our architects got a
new laptop, with all of the latest BIOS, but no OS. He got a clean version of Vista, the installation went fine, but the machine blue-screened on first login. At this
point he lost trust in that machine. There were no third-party drivers, nothing
hanging out in the back. This was a vanilla machine. The analogy was that this
might not happen again, but he equated it to finding out his wife was a spy. He
would still love his wife, but he would never be sure if things in the future
were related to spying, or related to their relationship.

There are three things to do when thinking
about making stuff more proven, more reliable in the eyes of the users:
reliable installation, exception handling, and testing.

So first, think about the installation. Users
hate it when developers spend twelve months on the application process and only
two hours on the design. It’s like taking a beautifully expensive mobile phone,
and wrapping it in old news paper. The product may be great, but if the install
is problematic, that is the first impression we need to get over. It’s the only
feature all of the customers will always use, so if that install is bad, if it
dumps a load of stuff over your desktop, or if it Unzips and then closes and you
have to search to find it and run setup from there, it leaves a really bad
impression “right-out-of-the-box” so to speak.

Although it's not as bad as it used to be, many
people discount the importance of installation as part of the overall
experience. The installation is the first impression of a piece of software. It
should be elegant, flawless, simple, and should just work - and if it is not
going to work the feedback should be immediate

Here is a top ten list of things that to
consider when creating your own installable software:

Pre-requisites for the installation
software. Bad installation packages have many
pre-requisites (certain versions of controls, components, frameworks and
so on) - this can be bad - especially if you are forced to quit the installer
to install these pre-requisites first!

Requiring a restart. Sometimes you need a restart of the machine, especially if you
are changing part of the kernel that just cannot be stopped. There have been
many installers that require a reboot "just to be safe." Do not
make your installer require a reboot of the machine just because it's a
simple checkbox that you can enable - if you need dependant components to
restart after your install, then put in the time and work out how to do
this without a complete restart of the machine.

Annoying animations and/or menus. Few people will be impressed by how visually exciting the
installation menu is. Keep it simple, clean, and elegant.

Too many options. This is the killer mistake for most installers - option after
option after option. Good installers do discovery, make some basic
assumptions and keep the questions to a bare minimum. Do the majority of
your users really care whether where your application lives anyway? At
least customize the installation for the persona doing the install (such
as basic or advanced user).

Un-installation. We have all seen rogue files, registry settings, ini files,
icons, menus, and so forth get left behind by a bad installer. Make sure
that your installer cleans up after itself if people choose to remove your
software.

Working out permissions. If the installer requires admin permission (especially
important with the UAC changes in Vista) let the user know before you
start installing anything. Exiting half way through an installation (e.g.
a “2869 MSI message”) is not good installation karma.

Applications that need quitting. If an installer relies on an application being terminated
before installation can continue, give the user notice of this and, if
applicable, have the installer shut it down. Do not quit the installer
just because the user has a browser open. The installer should also not
tell the user to close the associated application.

Accurate account of time remaining. If you do provide a progress box in an installer, please do
not reset it or break into multiple unknown chunks. What good is a
progress bar if it doesn’t accurately illustrate the progress of the
installation?

Unpacking the installation. If you provide a package that has to unzip some temporary
files, please automatically run the "setup.exe" after you've completed
the unzip - don't just unzip files and let the user figure out what needs
to be run next. Make sure the installer cleans up these temporary files once
the installation is complete.

Do you really need an installer at
all? If you are creating something lightweight
– an add-in, or extension – why not creating a piece of standalone software
that figures out how to run and co-exist on the user’s machine without an install
routine?

Think about how exceptions are handled. Popping
up a system.NET Web exception is pretty easy to do, but what is there in
letting the value in the user seeing that? How difficult is it for us to trap
that?

Related to exceptions is thinking about how
you are going to retry things. If something does happen, is it worth just
retrying it again? Maybe a network connection was lost. Does your installer have
to be so fragile that it fails with exceptions at the first sign of an error? There
is probably an 80/20 rule where if we tried something else, we could probably
fix 80% of the problems quickly.

The third thing to think about is testing. Proof also comes
down to testing. If you are involved with customers they may be thinking about
how to test this application before releasing it to our customers. User testing
tends to be the same today as it always was. We get a room full of users for an
hour and maybe buy them some pizza, we give them some tests – they can be
sophisticated or basic – we collect the feedback and see what happens, and then
we make a modification. Great, we should definitely do that; it will make
things more reliable.

What they found with this methodology is
that they are using the same amount of users, and although the length between
tests is longer because they need to make the modifications, that the amount of
bugs they can fix is exponentially greater. The first person picks out all of
the low hanging fruit, then next person is at a level higher, and so on.

Proven Recommendations

Trust takes time. Do not risk it by
releasing a buggy version just to get things out of the door. If things go
wrong, it’s going to hurt you in the long term.

Treat install and uninstall as part of
the application. In fact, it’s more important, because if it doesn’t
install properly, you have no hope of people using it.

Look at the RITE methodology. If you
involved in user testing it’s a great and easy way of finding more bugs
quicker.

People

The last aspect of the Infrastructure layer is People. The People
aspect refers to everyone who designs and develops the application, essentially
the software development lifecycle (SDLC). A typical SDLC looks something like Figure
22:

Figure 22. The typical SDLC

A project typically follows the pattern illustrated in Figure
22. There are two fundamental problems in this example: one is that IT owns
most of the project. While IT should be involved, the owner/stakeholders are
unclear. The other problem is how late in the schedule the UI is created. UI
design and development is simply bolted onto the end of the project schedule. Many
organizations push version one of their UI out the door quickly, get user feedback,
and decide they have to fix it. A designer is brought in, but it’s too late to
add any value to the UX (as stated earlier). The designer’s hands are effectively
tied due to the state of the application. We need a new, more successful
methodology that recognizes UX as a first-class citizen in the SDLC. A more
successful UX scenario appears in Figure 23 below:

Figure 23. A better UX development
scenario

In Figure 23 the project begins by
developing the use cases, scenarios, and personas. At the prototyping stage, we
split the project into two pieces - an IT prototype for the Web services, and a
separate user prototype. The user prototype can utilize techniques such as paper
prototyping, wireframes and speaking with end users to ensure the UX will meet
their needs.

IT focuses on developing the service and the
infrastructure side while the designer works with users, business analysts and
IT to design the UX. In an agile methodology there would be points where we merge
these initiatives back together for review and user testing. Eventually the
project comes back together for completion.

Are all designers the same? Designers may have different
skills, but are their functions different? When it comes to design there are two
different personas. A graphic designer comes up with the correct shade of blue
or image for the interface. An Interaction Designer is the developer who thinks
about how the user will interact with the application. Microsoft Expression Blend
can be used by Designers to design various components of the UX. The real challenge
is sharing designer recommendations with developers.

Figure 24. Where does the boundary lie
between designer and developer

Expression stores designs in XAML which can
be shared with UX developers in Visual Studio, ensuring no loss of fidelity
between the design and the implementation. From an architect perspective we
need to think about the following design considerations up front:

Events and the functions in Blend are
going to require code-level understanding. A Designer might be able to use
Blend to mark up a page, but what if the design needs to be more
interactive? Are Designers expected to know how to write C# or VB code?

There are going to be arguments between Developers
and Designers about who owns the XAML artifacts. If both sides have to
work with the same piece of XAML who trumps whom when a change needs to be
made?

This type of design interaction will lead
to interface stubs for communication. Will patterns or guidance emerge
helping Developers and Designers to communicate better?

People Recommendations

Look at the SDLC and customer projects.
Normally, a great SDLC really enables great UX.

Understand what types of designers the
SDLC model is going to require and support.

Support interactions between developers
and designers.

Conclusion

This chapter proposed a UX Framework for
architects. The three main points to remember are:

If you are a practicing architect use the
Framework to better position UX for the customers you are involved with.

If you are an aspiring architect, use the
Framework to put UX into the larger context. As you are think about the architecture
for your solution think about the impact that UX will have upon your users.

Use the Framework to promote UX as a
first class citizen in the domain of software architecture.

Chapter 6 provides a detailed look at the Identity
and Access architectural capability.

SOA Case Study: Zurich Airport

In just a single day, more than 60,000
travelers will pass through the Zurich Airport. Annually, approximately 20
million tourists, diplomats, and residents will travel through this busy hub in
Switzerland. It takes an infrastructure of 24,000 employees and 180
businesses to support the Zurich Airport. Overseeing it all is Unique, a
private company contracted by the Swiss Federation to manage the entire
complex.

To ensure smooth, overall airport
operation, Unique teamed with Microsoft to build an integrated business
monitoring system. The goal was to provide a high-level visual overview of
everything going on at the airport at any time, on any day. WPF was used to develop
a fully interactive map capable of providing at-a-glance views of key
operational information in real-time, including passenger forecasts, plane
location, flight data, environmental conditions, baggage loads, management
summaries, and other live reports. Native support for advanced animation within
WPF enabled developers to write a few lines of code to illustrate the movements
of aircraft on the airport runways. Users can zoom in on the plane, move the
mouse pointer over it, and see a pop-up balloon containing information about
the flight.