Designers aren't evil. Let me say that again for those developers out there: Designers aren't evil. Their job is hard just like yours. The problem is that designers and developers haven't had the tools to work together before. The rough answer to that problem for the past few years in Silverlight has been Microsoft Expression Blend. But that's only been part of the story.

A design starts with an idea that needs to be vetted, coaxed, and changed. Often it starts as something as simple as a cocktail napkin drawing. More drawings get passed around, and the idea takes shape. During this process of molding the idea, the drawings stay rough. Eventually the idea is agreed upon and some polish is added.

In traditional web development, at this point in the process, polished versions of the design are handed over to developers. What complicates this process is that the designs aren't complete; they're continually being massaged and fiddled with. These changes can be painful for developers as such changes tend to be interruptive and minor.

In Silverlight and more specifically, Blend, this story has been better. Once the polished designs were brought into Blend, changes could happen while the developers continued to work on the code. But the polished hand-over of the design continued to be a blocking point. Developers typically couldn't get involved until the design settled down. Or at least that's the way it used to work. With SketchFlow that can change, and I'll explain how.

What Is SketchFlow?

SketchFlow is a technology that ships as part of Microsoft Expression Blend 3. Blend has traditionally been a product for creating UIs for Windows Presentation Foundation (WPF) or Silverlight. SketchFlow extends Blend to allow UI design to start from the earliest parts of a design. SketchFlow lets you build on and polish a design through the entire development process. SketchFlow is not about development; instead it's about the design process. This specifically impacts you, as developers.

An Example

For example, let's take a simple quiz application I'm working on. Although I'm not a designer, I wanted to start out with a simple sketch and move onto a finished product. As Figure 1 shows, I sketched together a quick opening page to my Silverlight quiz-making application.

Figure 1: Cocktail napkin design sketch

Now that I have a sketch, I can start in Blend by creating a new SketchFlow application. The layout for a SketchFlow application is a little different than a typical Blend project. There are several windows that are accessible only in SketchFlow, as Figure 2 shows.

Figure 2: SketchFlow project

In Figure 2, you can see that our simple sketch of the opening page of the quiz application is also represented by an object on the SketchFlow map. Unlike a traditional Blend project, this map lets you show design reviewers the flow of your application through successive pages or trees of designs. This allows for quick iteration of the design. But the key to this iteration is the SketchFlow player. This player is a simple Silverlight application that can be used to share the designs with stakeholders to allow them to send feedback about a design. The SketchFlow player, which Figure 3 shows, can be hosted on a web page or delivered as a .zip package to share your design with key personnel.

Figure 3: SketchFlow player

The major benefit of the SketchFlow player is the ability to capture feedback. The Feedback pane lets viewers of the player add comments and other feedback to the design, as Figure 4 shows.

Figure 4: Feedback added to a design

This feedback can be shared with the designer/developer as a simple file. Then the feedback can be included directly in Blend by importing a feedback file. In Blend, you can see this in the feedback pane in Figure 5.

Figure 5: Feedback in Blend

This feedback loop lets you quickly iterate ideas and feedback to help determine the right design. The designer can then add annotations to communicate (and document) answers to the feedback. Design reviewers can see these annotations, so that the communication can be bi-directional.

Your hand-drawn designs don't need to be static. SketchFlow also supports a way to do simple animations. These are located in a special pane called SketchFlow Animation, shown in Figure 6; the animations are frame-based (different from standard timeline-based animations).

Figure 6: SketchFlow Animation

By using SketchFlow animation, you can create simple concept and flow diagrams to help your reviewers understand the overall flow and animations. These animations are meant to be fairly simple, but by enabling FluidLayout (the second arrow in Figure 6) Blend will implement simple tweening (i.e., generating intermediate frames between images) to help you make the animations move without the complexity of full timeline animations.

Moving to Prototype

At this stage, we're still working with hand-drawn sketches, but the real power of SketchFlow is shown once you start taking your sketches and turning them into prototypes. By starting with the hand-drawn sketches, you can use them to trace a prototype of your application. (See the sidebar "What Is a Prototype?" page XX, for a brief discussion about the value of prototypes.)

The danger of moving from hand-drawn to prototype is what I like to call the "blue button problem." When you're showing and reviewing an application prototype, the flow that you're trying to validate with the stakeholders often gets stuck in the minutiae of the details. Showing the flow between pages can get sidetracked with the stakeholder asking questions like, "Can you make the button bluer?" The solution to this problem is to continue to work with the designs as if they were still sketches. SketchFlow does that.

You can move from hand-drawn to a prototype in SketchFlow. For example, from the hand-drawn version in Figure 1, you can create a simple model of the Quiz Info page that looks like what you see in Figure 7.

Figure 7: A SketchFlow version

The benefit of this prototype is that it still has the essence of being hand-drawn, so it avoids the "blue button" problem entirely. It also avoids the prototype being thought of as a working concept, so that the stakeholders know it isn't a release-able version.

But why go to the trouble of creating a prototype with this style? This prototype is all XAML. This means that before the design is finished, developers can start to work with the XAML prototype to make it functional. This removes the usual roadblock of waiting for a design to be final or having to worry about an integration step to get the application working. So by going to the trouble of creating the prototype, you're enabling designers and developers to work concurrently.

The design in Figure 6 is still just XAML. For example, the first few controls in Figure 6 look like the XAML in Figure 8.

Figure 8: Partial prototype XAML
<TextBlock Margin="13,14,-31,27"
           Style="{StaticResource TitleLeft-Sketch}"
           Text="Quiz Info"
           TextWrapping="Wrap"
           HorizontalAlignment="Stretch" />
<TextBlock Margin="8"
           Style="{StaticResource TextBlock-Sketch}"
           Text="Name:"
           TextWrapping="Wrap"
           FontSize="24"
           Grid.Row="1" />
<TextBox Margin="8"
         Style="{StaticResource TextBox-Sketch}"
         Text="Pop Quiz for Math"
         TextWrapping="Wrap"
         Grid.Column="1"
         Grid.Row="1" />

The trick to showing the prototype in a hand-drawn fashion is the included SketchFlow styles that make the controls look and feel hand-drawn. That means that at a later date, when you remove (or replace) the styles, the hand-drawn look is converted into a standard application. Figure 9 shows this same page without the styles applied.

Figure 9: Unstyled prototype

Because the design is made up of XAML elements, a prototype can have data binding, code, behaviors, and animations all added to the design. It is just XAML, regardless of how it looks.

Improving the Prototype

Creating the SketchFlow prototype is usually only the first step. Since an application is made up of multiple pieces or page flows, being able to include that information in the prototype is incredibly useful. The fact that the prototype is now XAML makes it really easy to use behaviors to support this flow. A SketchFlow project has several of its own behaviors to help with this. The first of these is the NavigateToScreen behavior. You could enable this by dragging a behavior, but in SketchFlow this is available from the context menu. This behavior lets you decide that doing some action (like clicking a button) navigates you to a new page, as Figure 10 shows.

Figure 10: Using SketchFlow navigations

By using the Navigation behaviors, you can flow from one screen to another. These navigations are also shown in the SketchFlow Map pane in Figure 11. This means that any navigation between pages is documented as well (since the SketchFlow map shows up in the SketchFlow player as well).

Figure 11: Navigation in the SketchFlow map

In addition to navigations, you can also use Blend's Sample Data feature to create data to be shown in the SketchFlow. This lets you specify some data to represent the kinds of data that can be used in the application. For example, in Figure 12 you can see that you can specify sample data for the questions and use data binding (like any other XAML-based app).

Figure 12: Using Sample Data

Finally, you can also create SketchFlow component screens. Component screens are partial screens (or controls) that can be reused on different SketchFlow screens. They let you componentize your UI, if necessary. In Figure 13 you can see a component screen and the dotted line to the screen(s) that use the component screen.

Figure 13: Using a component screen

Getting Feedback

While the SketchFlow player will allow you to gather feedback, it isn't always useful to post the SketchFlow player on a website for users to give feedback. In SketchFlow there are other avenues for gathering feedback. SketchFlow lets you export your design as a .zip file containing an HTML page that will show the SketchFlow player locally on a user's machine. This means you can ship your design ideas just by sending a .zip file to a user.

Some users might not be comfortable with the technological approach to using the SketchFlow player. To accommodate those users, SketchFlow also lets you export your design as a Microsoft Word file, so that users can review the design using Word or simply on paper.

Working Iteratively

SketchFlow represents a fundamental change in the way that designers and developers can work on producing the best possible content for users. The SketchFlow facility in Blend 3 lets you go from paper, to idea, and finally to product. By following the approach of using the design iterations to further improve your ideas, you can move from idea to product in a much quicker fashion. In addition, since the artifacts in SketchFlow end up as XAML and possibly code, you can iteratively involve developers in a project well ahead of the finalization of the UI. This capability should shorten your development time as well.

Shawn Wildermuth is a Microsoft MVP (C#), member of the INETA Speakers Bureau, and an author of six books about .NET. He is involved a Silverlight Insider, Data Insider, and Connected Technology Advisor (WCF/Oslo/WF) with over 20 years of software development experience and blogs at wildermuth.com. Shawn currently teaches workshops through his training company AgiliTrain.

What is a Prototype?
There are a couple of differing opinions about what a prototype is and how reusable it should be. One line of thinking is that prototypes are always throw-away assets; the other view considers the prototype a reusable asset, but probably not 100 percent reusable. I agree with both considerations here. It all depends on your particular project as to whether the SketchFlow prototype will be the basis for your application or just a beginning point for creating your application.