Resurrecting UI Prototypes (Without Creating Zombies) – Part 2: Prototyping with Expression Blend

Thomas Immich

May 26th, 2010

Keeping the background information of the previous article in mind, assume you want to make use of Blend to design a NUI based on Silverlight or WPF that lets you easily manipulate items on the screen. In the beginning, you won’t even touch the tool at all – you “invent” whatever gesture you think is intuitive to perform this operation. Most likely you do this in your head or on the whiteboard. You discuss and refine the design with your team mates or with potential users. At this stage everything is still low-fidelity and throwing away things isn’t costly yet. As soon as you have a good-enough feeling about the rough design, you start prototyping with higher fidelity. This is to be really sure your idea works. To provoke the intended interaction experience, caring about every single detail is exceptionally important in later prototyping stages.

Defining Behaviors

First of all, it is interesting to define how an item behaves during manipulation. In fact, Expression Blend allows you to attach such “behaviors” to an object, telling this object how to move, resize or in any other way change according to a certain user input. The nice thing about behaviors is that they are self-contained software objects that you can use out-of-the-box without needing to know exactly how they do their job. As there is a growing community of developers that code behaviors and publish them in the Web free of charge, it is a good idea to first search for an already existing behavior that comes close to what you want to achieve and go from there. In some cases, you may need to tweak the behavior so that it more accurately suits your needs – either you do this by yourself (if you are one of those rare “designer-developers”) or you ask another developer for quick assistance.

Caring about every single detail

As you really want to absorb users with your UI design, you may want to add stunning animations and other nice visual effects to the item being manipulated. Expression Blend offers a timeline to create an animation storyboard as well as a lot of properties to change the style of an item.

As for animation, for example, it feels way different if the object you manipulate lethargically follows the movement of your finger or if it organically increases or decreases speed according to physical constraints known from the real world.

Everyone owning an iPhone knows and loves the “elastic strap resistance” behavior when scrolling through a list. To arrive at such an immersive, engaging and to some extent natural experience, all parameters that you are in charge of altering (location, speed, size, color, shape etc.) need to be perfectly concerted. Hence, only if you go an extensive way of composing, tweaking, usability testing, tweaking again, animating, styling, usability re-testing, modifying styles etc. you can be sure that you provoke exactly the positive usage emotions you intended.

Usability testing, in this respect, does not always need to occur on a grand scale – playing around with ideas by involving only two or three people can also provide you with quick and valuable feedback. Still, you cannot do entirely without usability testing.

Getting real

As soon as the prototype is finished, of course you want it to be really implemented. Even though it took blood, sweat and tears to get it built: after all it’s still just a prototype, not a real application. You need developer support to get it realized.

So how do you manage to get your prototype implemented while keeping up all the nifty details that you put together with painstaking efforts? One way could be, talking to the developer and asking him: “Hey, could you please implement this part of the application, exactly as shown in this prototype? I mean, it should behave exactly like this. Exact behavior, same animation speed, same visual style…” Yet, one possible answer to this request could be: “What kind of idiot do you think I am? I should dumbly rewrite what’s already there? This isn’t challenging in any way, it just takes a lot of time. Go, ask a monkey.”

Getting a prototype implemented - Strategy #1

Large version

This, of course, lets you change your strategy: “Could you please just use my stuff as is and incorporate it into the production environment? You don’t need to change anything – everything’s already behaving exactly as required.” The developer again: “Are you crazy? This thing is cobbled together like Frankenstein’s Monster… no way I will put this into production env, it will screw the entire architecture.”

Getting a prototype implemented - Strategy #2

Large version

We may now see a large question mark above your head as it seems you cannot get it right for him either way and don’t even get why. Admittedly, we are exaggerating and oversimplifying things here – if you work as part of a managed team you will neither place the request yourself nor will the developer be that offensive against you. Still, the developer is right with both positions: he is right not to just rewrite everything you already did and he is right if he sees the system architecture being jeopardized. Here’s why.

Architecture – and its absence

Your prototype – impressing as it may look and feel from the outside – has gone through several change cycles and gained a correspondingly messy inner structure. It consists of copy-and-pasted spaghetti code from several different community programmers with different levels of expertise and different coding conventions (or, even worse, no coding conventions at all). All kinds of software artifacts have just been duplicated where needed, this way violating the expressively labeled DIE principle (Duplication Is Evil). In addition, the prototype itself would prove to be memory hungry and poor in performance if it would run with real data. To summarize it: the bad thing about your prototype’s inner architecture is that there is no inner architecture.

Yoder describes this kind of un-architecture as a big ball of mud – and this really is a good way of putting it, as joining a big ball of mud with clean stuff creates dirty stuff in return. And exactly the same happens when you pass your big ball of mud to the developer to integrate it into a cleanly organized architecture. Comparing it to Frankenstein’s Monster also is an analogy of charming plasticity: if you try to keep your prototype alive as is – with its “body parts” partially taken from somewhere else – it will bite you in the ass at some point in time.

Being prepared for the recycling process

So how can you reincarnate your prototype as a living part of the production environment, rather than letting it die disgracefully, without creating a zombie? Can this be achieved at all?

Short excursion: the packaging industry

To dig deeper into this, let’s have a look at the packaging industry. In packaging industry, most stuff that is thrown away is reused later again, either for the same or for a different purpose. This is what we commonly name recycling. In order for this to work effectively, products are initially created in different parts of different materials or layers. A yogurt cup, for instance, is made of plastic while its label may be made of cardboard. So after you finished your tasty dessert, each material can take its own way through the recycling process. Some of the materials are then processed into new products while some other materials are “really” thrown away. What’s important here, however, is the fact that the packaging industry splits a product into different layers beforehand to be able to reuse as much as possible afterwards.

Yogurt cup before being split into parts. Yogurt cup after being split into parts.

Now, how can this approach be transferred to the business of UI prototyping and software making? Directly translated, the introduced example would mean: splitting up a prototype into several different fragments during its creation so that later on some of these fragments can survive in the real system (either in the same or in modified form) while others are really thrown away. Let’s see how Blend supports us here.

Back again in Blend: fundamental concepts

If you operate Expression Blend, splitting your UI prototype into such different layers is easier than it may first sound like. Blend already provides you with all the bells and whistles necessary to do so, e.g. by introducing a bunch of clearly contoured complementary concepts, such as control templates, behaviors, converters, styles, dependency properties, data bindings, triggers etc. While a control template, for instance, allows a designer to completely redefine a control’s visual elements without changing its fundamental behavior, a behavior makes an object do things it would not do on its own, independently from how it looks like.

This large set of different orthogonal concepts has not been introduced to annoy designers – it supports them to make their work more organized and formal without restricting their creative freedom which in turn allows for a less painful collaboration between the design and the development team. After all, it’s the development team that finally needs to get the job finished, otherwise the design team is doomed to strand on a prototypical island.

In fact, whenever you as a designer follow Blend’s concepts strictly, you create a number of artifacts that developers can reuse. Take for example a control template: a UI designer who wants a UI not to look like standard stuff, at some point in time needs to create a control template. The good thing here is: as the essence of creating a control template is about defining its visual elements, a designer cannot do much wrong here – it is his business to define visual elements. In turn, each and every control template can likely be reused as is in the real application. In other words, the look layer can be separated from the other messy stuff below, and therefore survive without causing any damage.

An example: Why using value converters?

So, for control templates it is pretty apparent that (and why) they can survive. For other concepts it is not as apparent, however just as well possible. In this respect, let’s take a look at the converter concept. A converter is a simple software class that takes a value and spits out another value. What does this have to do with UI design?

A lot, because among other things, you will likely benefit from converters whenever you want a label to be cleanly formatted. To make this more concrete: think of displaying email messages in a table. Each row shows a single email message with all its details such as subject, sender, date and time the email has been received etc. In terms of formatting, the date and time aspect is the most interesting one, as modern mail applications such as Thunderbird or Apple Mail illustrate.

Formatting of dates in Email applications.

Thunderbird displays the date information only for messages that have not been received the day the user looks at them. Otherwise it just shows the time information. Apple Mail shows the text “Today” instead of a concrete date, if the email has been received right the day the user looks at it.

The intention is clear: get rid of any information that’s not absolutely necessary and by doing so strengthen the really important information through quicker scannability.

Good UI design is detail work – Mozilla’s Thunderbird omits the date information for emails that have been received the same date you look at them. To cut a long story short: among other things, converters can support you to improve how well a piece of information is perceived and understood. Of course, you could also just fill in the formatted information “by hand”, so that you just type “Today” for each cell where it is needed. However, in case you need to evaluate alternative designs and formats with users you are way quicker tweaking the converter rather than manually typing a differently formatted text into each table cell. What’s more, converters, just like behaviors, are self-contained and therefore are able to motivate community developers to write and share them with you, so that you can use them out-of-the-box.

Increasing your prototyping speed

As you see, if you align the internal structure of your prototype according to these different concepts, in the long run you will not only increase your prototyping speed you will also end up with different parts for each of which you can decide separately whether to throw it away or not.

If you look at the converter sample you might still face the problem of bad coding and naming conventions, though (which is the price of tapping resources from the community). In this case, you have something that you cannot use as is, because it would still violate the internal structure of the real system. However, the nice thing is, being separated concept, a converter it is pretty agnostic towards the rest of your prototype, which means it is clear where to focus in order to remove problems inside the converter’s structure.

In other words, the converter itself can be recycled rather than thrown away. More generally spoken, for every separated concept that you use to build your prototype you can decide separately whether to reuse it as is, recycle it or throw it away.

The recycling process itself (or “rise from the dead”)

While following Blend’s concepts when building a prototype is the business of the designer, the recycling part is the developer’s business. However, if you speak in terms of recycling in front of a developer, he may look puzzled. What you are referring to in developer terms is called “refactoring”.

Refactoring – the big spring-cleaning

Refactoring means “improving the internal structure of a system without changing its observable behavior”. This is no voodoo magic. It just says that the developer is going to change bad names into good names (following certain coding conventions) and that all the duplicated stuff that has its origin from several copy-and-paste orgies will be centralized at one single location.

Renaming objects sounds like a lot of tedious work, but it’s not. As the developer can open the same Expression Blend project that you worked on in Visual Studio, he can rename awkwardly named objects almost automatically without being afraid that he might actually break something.

Of course, the deeper the developer’s changes are, the riskier it is that he breaks something, so that he ends up with a nice internal structure but a UI that does not look and behave as you intended anymore. An example for a deeper change would be centralizing duplicated code. However, developers – especially those coming from Extreme Programming – do have a method to avoid such risks.

Avoiding risks of restructurig through test cases

First, they will likely write some test cases before touching your prototype’s structure. A test case asserts a certain output or reaction whenever a certain input or interaction occurs. If the assertion is correct, the test case is considered as being successful, if not it is considered as having failed. Exactly what output results from what input, the developer can tell by just using the prototype and in addition by discussing some of its details with you (e.g. what does not work as intended because you did not have the time or skills to realize it).

Once the test cases are written and all of them ran successfully the developer can start working on the refactoring process. Whenever a fundamental refactoring step has finished, he will likely check the test cases again to see if they are still running successfully. If not, he needs to undo his latest changes and perform this step again. In the end of the process, if all test cases run successful, you will likely have a real application that has both a clean internal structure and still looks and behaves as proposed by your prototype. After refactoring, the prototype itself can then really be thrown away – without shedding a tear, as every single piece of it lives on as part of the real system.

The next time you need to apply minor changes to your design, e.g. because of some requirements that have changed, you work on the real application – your former prototype is already dead. This implies that you profit from everything that the development team did so far (e.g. optimizing performance). Also your work and the developer’s work do not run out of sync as it would be the case if your prototype would still be separated from the real system.

Though the entire refactoring business sounds complex and time-consuming, it is common practice in most development projects. So don’t be vain about it – the developer does not do this just for you, he does it anyway from time to time for the sake of keeping the system maintainable and extensible.

Wrapping it up

If you want to create a good user interface design, you will need to prototype your concepts and evaluate them with real users. The more natural your user interface should feel, the more you have to take care of numerous details. This makes prototyping more challenging and time-consuming and is in contrast to the basic idea of prototyping, which is “building something rapidly and cheaply”.

For this reason, there is a certain temptation to just incorporate a high-fidelity prototype as is into the real system once it’s finished – throwing it away would be a shame. However, this approach is not recommendable as it jeopardizes the real system’s integrity – basically because of the messy internal structure of the prototype, which among other things results from the many changes that you needed to apply as a result to user feedback.

Fortunately, modern prototyping tools such as Expression Blend allow you to create prototypes along different orthogonal concepts. This way, it is possible to split the prototype into parts and decide separately for each part whether to throw it away or keep it.

For those parts that you cannot reuse as is, you can at least recycle or – to speak in developers’ terms – refactor them. During refactoring the messy structure of your prototype is cleaned up without changing anything regarding the prototype’s look and feel – test cases written by the developer ensure that everything is really kept as you intended.

So, if you are open to recycling prototypes, what do you get? You get a user interface that looks and behaves exactly as intended, however this time it’s for real. In addition, you and the developer both work on the same thing without conflicting each other. Both of you do what they are good at and arrive at something that they care about – you arrive at a nice UI, the developer arrives at a clean system architecture. Still it is worth mentioning that all this is just possible if the prototyping tool of your choice supports it. It’s not always “people over tools”, sometimes it’s the other way around: pick the right tools, use them correctly and watch how people of different disciplines can become a team.

Blog