UIDesign Group: What Microsoft Blend is Missing

Introduction

XAML/Blend technology promises interaction designers an improved level of control over the results of our work. This is great because it enables interaction designers to develop interfaces for the end product very close to the initial concept. However, this technology changes the habitual way of designers’ work and requires some additional skills.

Any experienced designer would inevitably have questions such as: What does this new approach really give? Are these innovations really worth changing habits? Does is take much effort to modify a user interface? Can several interaction designers work together on the same project? Does Microsoft Blend© allow for developing complex interfaces? Let’s consider these questions in more detail.

Classic approach

In order to give you a clear-cut demonstration of the new approach, I suggest recalling an established way of designing user interfaces.

Based on requirements of users, stakeholders and hardware restrictions designers create models of the future interface in the form of a wireframe. With a specific level of abstraction a wireframe is a graphic illustration of an interface. An integral part of a wireframe is a description of how the interface is behaving while users interact with a product. Normally we do either a text-based description or a wireframe that imitates the product's behavior; here we can speak about an interactive prototype.

Based on this specification designers create a graphical style of the product and developers implement it. Every party involved in development has its own area of responsibility and competence. The information is exchanged through deliverables by each specialist, which is done in the following way:

Interaction designers create a prototype in a way they are more comfortable with (for example, with Microsoft Visio); Based on the received prototypes graphic designers create interface graphic files that are then fed to developers.

The developers receive the prototypes and graphic files and implement the user interface using the most suitable framework.

The actual cooperation process is, of course, more complex but the main workflows are like this.

This approach works fine for regular web applications due to the limited means of expression. It also works pretty well with classic desktop applications with a number of widely acknowledged models of interaction that were formed from a fixed set of controls (entry fields, dropdown lists, radio buttons, etc.) However, this approach does not work with modern Ajax applications and especially RIA (Rich Internet Applications) applications.

In order to describe a complex behavior of such application an interaction designer needs to create heavy manuals that most developers would have trouble comprehending. It is also very tough and expensive to maintain lengthy texts. And if the designer misses some behavior subtleties, the developer will likely implement it the way most suitable from the perspective of development but not necessarily from the user’s perspective. The simple truth really works – a picture is worth a thousand words.

The issue can be solved by means of “designer supervision,” when an interaction designer monitors the whole process of implementation of the product’s interface. The supervision required intense communication between an interface designer and developers. In most cases the project deadlines are too tight and redundant communication becomes very timeconsuming. A lot of IT experts have been thinking for a long time: How can we take at least part of responsibility for creating user interfaces off programmers? What if interaction designers could implement complex interactions themselves?

New paradigm

Nowadays we face a rapid mutual assimilation of desktop (GUI) and web applications. Users got accustomed to “unique” design and behavior of interfaces, which are common in the world of web sites and web applications. It is quite customary with marketing people to request “an application with the unique design.”

Thanks to Ajax ideology it became possible to do flexible and most importantly fast web applications. Users now cannot tell MS .NET and Adobe Flex-based applications from native desktop software. It was quite natural that a new solution was found to separate an external appearance of an interface from the business logic of an application, though it was a complex one. The solution is based on special languages of interface description XAML by Microsoft, MXML by Adobe, ZUL by Mozilla, etc. These text-based languages describe an appearance of elements (in vector format) so that an interface can be created in any editor.

XAML language defines not only locations of elements on the screen (in vector format), but also all their transformations. For instance, an interaction designer can define a button's look, both when it is pressed, release or in an interim phase. Thus, it is possible now to have a full control over the behavior of any element. Another good example is an authorization form in Mac OS X. If a user enters a wrong password, the entry window shakes. “Shaking” effect is an excellent means of expression, that can be noticed even when looking at the keyboard. With the XAML code an interaction designer can easily create such interaction without developers’ help.

There is a special software for XAML editing – Microsoft Expression Blend or simply Blend. Editing can be done in a visual mode, i.e. an interaction designer can create elements, move them across the screen and describe their behavior. Sounds really good! Interaction designers create an interface, graphic designers polish it and developers implement it. But let’s take an indepth look at Blend.

The cooperation between the team members is done in the following way now:
An interaction designer creates a prototype. A prototype can be created in any environment that he or she is comfortable with just like in the classic approach but it is more convenient to do it directly in Blend. All the tools for creating a prototype are available here – drawing tools, standard control elements (when developing applications based on .NET or Silverlight 2 platform), and possibility to create patterns.

A graphic designer receives the XAML code and creates a completely new XAML file containing interface objects in their final look right in Blend or another XAML editor (e.g. in Microsoft Expression Design).

The interaction designer receives the XAML code back from the graphic designer and reworks it so that it can be easily maintained in the process of the application development. For example, they assign proper names to the on-screen objects. But most importantly – the interaction designer creates transformation scenarios for the objects, i.e. defines how the object will respond to the user’s actions.

A developer receives the XAML code from the interaction designer and “enlivens” it, i.e. links it to the business logic and connects all the transformations (bits-and-pieces of interactions). In case of highly iterative development process, which happens most of the time, the developer would feed the XAML code back to the interaction designer who would then need to do further changes in the appearance or behavior of the objects.

Fig. 2 illustrates the new framework of working on a project.

It all looks good at first sight, but then the second thought entails some questions:

Is it an interaction designer not a graphic designer, who needs to create a scenario of transformations (actual animations)? In order to have an object move in a natural way according to human perception we need to follow certain principles, for instance, the twelve principles of Walt Disney (http://en.wikipedia.org/wiki/12_basic_principles_of_animation). However, if the animation is given under full control of graphic designers, there is a chance that not all of the transformations will be implemented – only an interaction designer knows the behavior of the future product in detail.

The object namespace that seems handy for an interaction designer may seem inconvenient for a developer and vice versa. I.e. a developer might send back such an XAML code that an interface designer will have to sort it out over again.

How to track changes in XAML? Not all the changes are visual, therefore all the participants will spend much time documenting these changes in the external communication environment (for instance, via email).

How can we make in-depth changes of on-screen objects (or refactoring as programmers call it)? The iterative design always forces us to change the appearance and behavior of on-screen objects. All objects inside XAML are arranged in a strict hierarchy (due to XML syntax) and any transfer of an object will lead to a necessity of manual check of the results of this operation. In short, Blend does not have convenient tools for quick changes of objects.

There are a quite a lot of similar questions.

New requirements to interaction designers

Some of the problems result from the changes in the responsibility zones of the experts (see Figures above). Since all experts are now working in a single XAML environment, the editing tools need to support this new allocation of responsibilities.

But first we need to figure out new requirements to interaction designers. So an interaction designer has to:

Be fluent in XAML and Blend. Not all XAML features are realized in Blend, so it is necessary to know the language well. One should understand how the final product will be tied together. Understand and apply main principles of animation. This knowledge may prove useful even if all transformations will be done by graphic designers.

Ensure efficient management of teamwork with developers and designers - since all the work is done in a single environment every member of the team is in the boat that is easy to rock. One can easily put the blame on a teammate in case of failure. Before Blend starts supporting cooperation between the team members, all the changes and coordination questions need to be controlled by means of external tools.

So we can see that retraining of interaction designers is inevitable.

Unrealized requirements in Blend

Blend itself needs to duly support the new approach, as follows:
Improve a workflow and track changes. We have covered this topic already. Allow a flexible control over animation. Currently, in order to make some simple transformations one has to use a calculator or a spreadsheet to define interim values of object attributes (for example, object coordinates or transparency). Ideally, Blend is expected to contain some special language to enable interaction designers to define objects’ properties and calculate them automatically.

Provide a control over a large number of transformation scenarios. Even in a small project we end up with a vast number of scenarios and spend much time on finding the right one. To speed up the process it is advisory to introduce a grouping of scenarios and add a search tool. We also need a tool to build dependence of scenarios. At present, the list of scenarios has a flat structure and it is impossible to identify how they affect each other – which transformation scenario is initial (performed over the objects on the primary stage) and which is used at the interim stages. It can drive one crazy to predict what would happen if this or that scenario would take place in this or that state. It makes sense to add a tool such as a matrix of every object states with links to appropriate scenarios.

Support refactoring of XAML objects. One of the critical requirements to prototypes and to the systems of user interface editing is a support of iterative changes. In its current state Blend does not allow to do prompt changes and we have to manually control the correctness of each change, i.e. do refactoring. Have an ability to visually debug any scenario. There are cases when it is impossible to see finalized scenarios inside Blend, i.e. proper tools for monitoring the end results are missing. This happens because in order to see the result of transformation an object needs to be put in the required state, which can be done only by the developers.

Conclusions

Blend is not a prototyping tool in its traditional form. It makes no sense to design an interface inside Blend for any other platforms except Microsoft Silverlight © and .NET ©. However, interaction designers have now a better control of the end results under these platforms. Unfortunately, the existing version of Blend does not support the changed interface development paradigm properly. This shortcoming is less obvious in small projects of 3-4 participants, but for medium and large projects the interface development may require too much effort.

About author

Alexey Kopylov
CTO, UIDesign Group
Interests: conceptual design methods, mobile interactions, creative software