Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

Using SketchFlow to Create Better Prototypes

All good developers and designers that I’ve run into do some kind of prototyping. For me, prototyping is about creating a communication channel with customers, sharing ideas with stakeholders, and receiving feedback so that changes can be made early on in the development lifecycle.

As you’ve likely seen, prototypes can come in all kind of forms, ranging from something drawn on the back of a napkin, through to something that looks very close to the original, designed in a professional software package. Despite this variation we commonly see two different types of prototypes: Low fidelity and high fidelity. A low fidelity prototype is as raw depiction; often a whiteboard drawing or sketch that outlines a particular piece of user interface, an example of which can be seen in Figure 1.

Related Sponsor

Figure 1 - An example of a Low Fidelity Prototype showing a sign in screen

This is known as a low fidelity prototype because the primary purpose is to show a piece of functionality in its simplest form without any of the icons, colors, font selection and so forth.

The opposite is a high fidelity prototype. A high fidelity prototype, such as the one shown in Figure 2, is still a prototype in that the functionality underneath is not complete or wired up to logic, but the look and feel is closer to the finished product.

Figure 2 - An example of a High Fidelity Prototype

Both low fidelity and high fidelity prototypes have their places in the development lifecycle.

Low fidelity prototypes are typically very effective at getting user feedback as they express the raw functionality of the application without losing the user on the details. As the prototype is nothing more than a sketch, users tend to assume that it will be easy to incorporate feedback and as a result are much more open about giving feedback. With that said, there are situations where low fidelity prototypes don’t work as well. An example I’ve found is when updating the executive team at the next board meeting. Because of the rough format of the low fidelity prototype, I’ve been greeted with looks of confusion when walking into the board meeting with nothing more than a flipchart; the executives thinking “Don’t we pay you to write software?”

As you might expect, high fidelity prototypes suffer from the opposite problem. While they work well in board meetings to show what a finished product could look like, the polish that has been applied can often be too overwhelming for many users. I’ve seen examples where users have been frightened to ask for major changes in a high fidelity prototype due to the amount of work that they feel may have to be done to make a change. The user believes that because the prototype looks so close to the finished product, too much work has already gone into the application, and they often are held back in suggesting such changes. In addition, high fidelity prototypes tend to draw users into a conversation about the finer aspects of the design, such as “Shouldn’t that blue be the same shade as our company logo?” rather than focusing on the overall design of the layout.

Moreover, taking a user through any type of prototype can be very tricky, especially those users based in remote locations. Often, we’ll put together a PowerPoint deck of screenshots and send it to the user without having the ability to share the context or interactively take them through the design.

To help address some of the issues with prototyping, at MIX09 in March 2009, Microsoft announced a new technology called SketchFlow, which will ship as part of Microsoft Expression 3. As described by Group Program Manager, Christian Schormann on his blog, SketchFlow is a fun, informal, flexible, quick and powerful way to sketch and prototype rich, dynamic interactivity with Expression Blend.

In this article we’ll be exploring the functionality within SketchFlow, covering how it works in a soon-to-be-released preview edition, and looking at how such a tool could make your prototypes more usable and effective.

If you’ve heard of the Expression Blend family of products, you’ll likely know that the Expression Blend tool is marketed toward the designer community. While interaction designers will likely make up the majority of the users of Blend, I believe that the SketchFlow functionality also makes for an attractive proposition for many developers – many of whom have been prototyping for some time, using whiteboards through to creating mockups of screens in Visual Basic or other tools.

SketchFlow – Getting into the Details

Expression Blend 3 supports two different types of SketchFlow projects. One for WPF (Windows Presentation Foundation) client based applications, and one for Silverlight applications hosted within the Web browser. Both project types offer the same prototyping functionality, however the asset library offered depends on the platform chosen.

After creating a new project in Expression Blend 3, the first component that you’ll likely run across is the “Application Flow”. The Application Flow panel in Blend enables you to create a simple layout and flow for your application.

Figure 3 - A simple application flow for an online store

As shown in the above diagram, the Application Flow is used to compose a simple workflow for the navigable screens of your prototype. In the above application flow we have five boxes representing a simple online store; a storefront screen, a browse screen, a checkout screen, a sign in screen, and a shipping confirmation screen. The navigation screens are interconnected with one way or bidirectional connection lines to indicate the path that the user will take within the application.

Creating this application flow diagram automatically generates a series of blank XAML pages within Expression Blend.

Figure 4 - Creating the application flow generates a series of XAML files in the editor

With the application flow in place we can now start to add controls to each of our prototype screens.

If you’ve used any previous versions of Expression Blend you could probably guess that we could drag and drop items from the asset library to start creating the user interface.

Figure 5 - Standard controls from the asset library

You would be right, however as you can see in Figure 5, by doing this we are already heading down the path of creating a high fidelity prototype.

To help convey a more low fidelity feel, SketchFlow introduces a new XAML style called “WigglyStyles”. As you can guess from the name, this new style imitates the raw form that you may get from a whiteboard or napkin style of sketch. To add to the effect, SketchFlow also comes with two new fonts depicting a handwriting style and an architect’s sketch style. Applying controls from the WigglyStyles style to the same controls gives quite a different effect.

Figure 6 - Controls using the WigglyStyles XAML style

What’s important to note here is that these are all valid and working controls, not simply images. Edit boxes can accept text, buttons can be clicked, scrollbars can be moved, resulting in a very functional screen yet one that adheres to low fidelity visible characteristics.

Adding Navigation

Now that we have an understanding of the application flow and the styles, let’s start designing our prototype. In this article we are going to be creating a prototype for a new “InfoQ store” designed to sell a range of products branded with the infamous InfoQ logo.

Although we have defined the flow of the screens, we haven’t yet added navigation behavior. For example, when I click on the “checkout” button, I naturally want to navigate to the checkout page.

In previous versions of Expression Blend, and this equally applies to many other UI development environments, wiring up navigation often requires setting an action or event and then having to write some code to handle the navigation. While this isn’t complex for most developers, it’s not necessarily that intuitive to designers or those without a development background and in addition, adds unnecessary code that slows down the development of the prototype.

Expression Blend 3 however, treats prototype navigation somewhat differently. Rick clicking on any control brings up a new “Navigate to” context menu, as shown in Figure 7.

Figure 7 - The “Navigate to” context menu in Expression Blend

Selecting the “navigate to” screen generates an activation trigger on the control. In XAML this looks similar to the following:

The XAML responsible for the navigation is the interaction trigger and contains an “EventName” to act as the trigger and “NavigateToScreenAction” containing the desired target screen. All of the XAML is auto-generated by the right click of the context menu and no code is required to wire this up.

Adding Composition Screens

Another area of navigation in SketchFlow is the concept of composition screens. If you have experience in Web development, you’ve probably come up against the need to have common controls on each screen. This might be a common set of tabs or buttons displayed at the top of the web page, or a common look and feel that all pages inherit.

In SketchFlow this is known as a composition screen. A composition screen is a collection of XAML objects that can be displayed in a consistent way on any navigation page. To create a composition screen, we first define a common set of controls.

Figure 8 - A common set of controls that we want to replicate on each page

As Figure 8 shows, this includes four buttons – one for returning to the home page, one for displaying the products page, one for showing the account page and one to display the shopping cart. To take these controls and add them to each page, we select all of the controls, right click and select “Make Into Composition Screen…” as shown in Figure 9.

Figure 9 - Turning these controls into a composition screen

After naming the composition screen (I’m going to call this one “TopBanner”) the controls are taken into a separate XAML file, and the composition screen is shown in the Application Flow.

Figure 10 - The composition screen as part of the application flow

As you can see in Figure 10, the TopBanner composition screen is now displayed in the application flow. (The green color differentiates the composition screen from the blue navigation screens). To bind the composition screen to the other XAML pages, we can create a relationship between the composition screen and the navigation screens.

Figure 11 - Binding the composition screen to other navigation screens that should display the common controls

Figure 11 shows how the composition screen will now be used by the storefront, browse, and checkout navigation screens.

Getting Feedback from Users

We’ve added some more controls to the InfoQ store and now feel ready to share with our users in order to get some feedback:

Figure 12 - A completed form that we’d like to share with our user for feedback

As you might imagine, hitting F5 will build and launch the application, but not as you expect. The application does launch but within the context of the SketchFlow Player, a Silverlight based navigation frame that allows the user to drive the application and add feedback during the process.

Figure 13 - The application running in the context of the SketchFlow Player

As depicted in Figure 13, the user has three ways to navigate through the prototype. The “navigate” tab to the left of the player shows the available screens in the workflow, buttons that were configured to navigate to other pages also work, and in the bottom left the user can also investigate the flow of the application by clicking on the flow tab. This displays the same representation as the application flow in the designer, as shown in Figure 14.

Figure 14 - The flow tab in the SketchFlow Player showing the application flow

While navigating through the prototype, the SketchFlow player gives the user the ability to add comments and feedback about the design in two ways: by entering feedback text into the feedback window (for example, asking questions or providing textual feedback on the prototype) and by actually drawing on the screen with an ink or highlighter control. Both text and ink feedback are shown in Figure 15.

This can be very useful for the user to share details on finer elements of the design such as placement of controls or windows. This feedback is saved as a “.feedback” file which can then be uploaded to a site or emailed to the original development team. When the development team receives this feedback, it can be imported back into Expression Blend 3 and used as an overlay within the project, allowing the team to have the exact user feedback and annotations as they relate to screens in the designer.

States and Transitions

We talked about screen navigation earlier, but how about if you want to display a message or another animation that didn’t warrant creating a new page? For example, in the InfoQ Store when the user clicks on the “add cart” button, we may want to display a message confirming that an item was successfully added to the shopping cart. This doesn’t necessitate a new screen, but we do need some action to handle the response in the prototype. In SketchFlow this is known as a change of state.

States are created using the States tab to create a group of elements on a page.

Figure 16 - Two states for showing and hiding the “added to cart” message for the user

In the above example, notice how I have created two states – ShowCartMessage and HideCartMessage. I can define what happens in each of these two states. For DialogBoxShow I create a simple dialog that contains a message to indicate that the item has been added and set the opacity of the dialog to 100%, similar to the one shown in Figure 17.

Figure 17 - A simple dialog to indicate the item has been added to the cart

Likewise, for the DialogBoxHide state I set the opacity of the dialog to 0% in order to give the effect that the dialog box has been removed.

Similar to how I wired up the navigation controls earlier, I can simply right click on each of the controls to bind them to a particular state. In this example, when the user clicks on the “add to cart” button, the ShowCartMessage state is activated and the dialog is shown.

Figure 18 - Binding a state to a button control

A similar action is added to the dialog so that when the user clicks anywhere on the window, the message disappears.

Similar to the form navigation, binding to the state adds a XAML code block for each control. The behavior controlling the state is the ActivateStateAction:

For added effect, states also support transitions and animations. For example, if our prototype mandated that the dialog box show fade or fly in then we could create a XAML storyboard that could accommodate this. As you’ve probably guessed, everything created by SketchFlow is correctly formed XAML – there are no proprietary switches or hidden options – this means that anything that can be done in XAML can also be reflected in the prototype, even if it’s not supported in the designer.

Adding Sample Data

Up to this point, we’ve covered adding controls and navigation, but a critical element to many prototypes is the need to pull in sample data – in our example this could be a list of products that we’ll be selling through the InfoQ store.

Previous versions of Expression Blend have supported connecting to external data sources through either a direct database connection or CLR object, but wiring this up can be time consuming especially in a prototype environment. It the prototype has a chance of being rejected, it can be cumbersome to create a database, schemas, and tables in a database to handle a few sample objects.

To help overcome this Expression Blend 3 supports the ability to create sample data directly within the designer. This is achieved by adding a new sample data source in the data tab:

Figure 19 - Sample data options within Expression Blend 3

Two options are supported in the current preview; defining a new set of sample data or importing sample data from XML. The second option can be especially useful if you have an XML data representation from an internal system, for example an export from a current line of business application or even a public RSS feed.

No XML data source exists for the prototype store, so I’ll choose to define some new sample data instead.

Figure 20 - Sample data collection for our store

For the sample demo store, a simple collection of types representing the products has been created. You’ll notice that the sample data collection supports multiple data types. SKU is represented here by a text field, but the image is actual a .PNG file from disk (a directory of images can be imported into the sample data collection).

Now that we have the data structure defined, we can define the sample data for the store:

Figure 21 - Editing sample data

Note that in addition to supporting fixed values entered into the sample value dialog box, Blend also supports “automatically generated” sample data for a number of types.

Figure 22 - Automatic sample data types

This option is especially useful if you are working on a prototype that has a need to display a list of fake telephone numbers, URLs, Email addresses, etc.

With the sample data complete, the next step is to drag and drop the data collection from the data panel to the object (in this case this is the search list box) to populate the item. When the application is run, all of the data imported is usable within the prototype.

Figure 23 - Dragging and dropping the data collection to the search list box to populate the items in the prototype

You can imagine creating a new state bound to the “Search” button in this form that populates the sample data.

Documentation

I’ve run into only a few people that actually find enjoyment when creating documentation for projects - yet documentation, especially for prototypes, can be critical as it provides a record for mapping out all of the elements assets, user feedback, and states for a prototype.

If you fall into the category of not liking documentation either, one of the features in Expression Blend 3 you’ll be pleased to see is the “Export to Microsoft Word” option from the file menu.

Figure 24 - The “Export to Microsoft Word…” option

Clicking on this option generates a new Word document based on all of the elements in your prototype file.

Figure 25 - Example output

This includes application flow, screen layouts, user feedback, transitions, and states, all wrapped up with a table of contents and list of applicable figures. All this information in Word format makes it easy to then apply a template and add your own comments before sending it to your user or client for review.

Moving from Prototype to Production

At the end of the day the success of a prototype can often be measured by the success of the resulting application, which raises the question, “How do I take these prototypes into production?” When working with customers I often see two approaches.

The first answer is to throw everything away, and with existing tools this is often the case today. Frequently, a designer will create a screen mockup of an application in a tool such as Adobe Photoshop, export the complete image to JPG files, and then rely on the developer to take those JPG files and create the real application. More often than not this can lead to different interpretations between the designer and developer, especially around some of the subtleties within the design.

The second answer is to keep as much of the prototype as possible in order to re-use the assets as you move into production. Using SketchFlow, a lot of the visual assets and controls can be kept, together with replacing the navigation and application flow with a more robust framework such as MVC, switching out the states into code, handling exceptions, and so forth. There is always a balance between how much of a prototype you keep into production and how much gets thrown away, but an interactive prototyping tool makes it much easier to make those kinds of tradeoffs.

Conclusion

I hope this article has been useful for walking through some of the early capabilities in SketchFlow. Microsoft is still very early on in the preview process for Expression Blend 3, so lots of things may well change before release, but I hope you’ll agree that this new set of tools has the opportunity to help designers and developers take prototyping to the next level.

Is this free ?

Re: Is this free ?

Your message is awaiting moderation. Thank you for participating in the discussion.

as in beer ?

I don't think so, Expression Blend is a paid for product so if it's part of that then I guess not.

If you work with Java then the "Napkin" look and feel for swing could help you produce screens with your normal GUI builder but provide the mockup look and feel. See napkinlaf.sourceforge.net/ for more info.

design a UI not develop it...

Your message is awaiting moderation. Thank you for participating in the discussion.

As a UI designer I have tried computer based UI layout apps (inc. Balsamiq, DENIM etc.) and I have always found having to set up configurations/behaviours for the UI components gets in the way.

My solution? a Pen and some A3 paper...

Work out the design and then produce an interactive prototype if needed...

It's v. quick and easy to revise. I'm not a Luddite I just find it easier for my particular situation. We use Ajax/JavaScript/Canvas not Adobe Air or Silverlight.

I spent ages getting Fireworks to output 'sketchy style' screen designs, then realised how silly it was - why not just draw them!

I use a more finished 'computer sketch' for presentation to clients, but don't do the initial design using this.

I can see the attraction of using the same 'base' for wireframing interactions and then 'flicking a switch' and the finished UI is generated, but for me the computer gets in the way of the early initial design work, although I do sometimes get:

"...different interpretations between the designer and developer, especially around some of the subtleties within the design..."

I just need to offer tighter UI designs for the development team.

Experiment/sketch/design/rapid/prototype then use the computer to work out the details and flesh out the interactions - don't start the design on the computer. I always follow this rule whatever I'm designing from a UI design or a new corporate image.