http://msdn.microsoft.com/en-us/library/bb833026.aspx

Chapter 5: User Interaction

0 out of 2 rated this helpful - Rate this topic

"Design is inevitable.

The alternative to good design

is bad design, not no design at all"

- Douglas Martin

Author

Contents

Reader ROI
Acknowledgements
What is Architecture?
Introducing a Framework for UX
Conclusion
SOA Case Study: Zurich Airport
References

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

1. Defining Personas should be the first step for any design experience.
2. 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

1. 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.
2. 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.
3. 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 specific tolerance 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

1. 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.
2. 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

1. Do not let customers confuse tasks and goals in applications.
2. 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

1. 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?"
2. 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.
3. 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.

Figure 16. A proactive approach to capturing feedback coupled with context

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

1. Think how users are going to provide proactive feedback. Think about those types of channels that you can open up.
2. Think about a strategy for when things go wrong. Thinks will go wrong. What do you need to circumvent that?
3. 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

1. 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).
2. 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:

1. 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!
2. 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.
3. Annoying animations and/or menus. Few people will be impressed by how visually exciting the installation menu is. Keep it simple, clean, and elegant.
4. 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).
5. 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.
6. 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.
7. 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.
8. 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?
9. 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.
10. 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.

Figure 20. Typical user testing

This is really the best way of doing testing. Game developers use a test technique known as RITE: rapid, iterative testing and evaluation (http://download.microsoft.com/download/5/c/c/5cc406a0-0f87-4b94-bf80-dbc707db4fe1/mgsut_MWTRF02.doc.doc). This is how RITE works: Take one user, put them through a test, collects the feedback, and then makes that modification. Then you take the modified version and give it to a second user. Repeat with a third, a fourth, and so on.

Figure 21. RITE user testing

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

1. 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.
2. 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.
3. 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

• 
  
• 1. Look at the SDLC and customer projects. Normally, a great SDLC really enables great UX.
  2. Understand what types of designers the SDLC model is going to require and support.
  3. Support interactions between developers and designers.

Conclusion

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

1. If you are a practicing architect use the Framework to better position UX for the customers you are involved with.
2. 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.
3. 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.

Figure 25. Red areas represent plane and passenger movement at Zurich Airport

The entire Case Study is available online at http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=200365

See other SOA case studies at http://www.microsoft.com/casestudies/search.aspx?Keywords=SOA

References

·         "User Experience for Enterprise Applications", presentation by Simon Guest, 2006. More information on UX is available at http://msdn2.microsoft.com/en-us/architecture/aa699447.aspx