We have received a lot of questions about when SketchFlow would be available for you to play with. Thanks so much, all of you, for the enormous interest – we really appreciate it.
As of this morning (Friday, 10th), a version of Expression Blend 3 with SketchFlow is ready to download here.
I’ll use this post to talk about many new aspects of SketchFlow with you. This post is not a tutorial (I’ll do some of these later), but rather an overview of the concepts and ideas behind SketchFlow. Please feel free to let me know what you would like to learn more about, and I’ll try to blog about it in future installments.
First some references to other material:
I have posted an introduction to SketchFlow before, and there are several demo videos ready to watch online:
- Scott Guthrie’s keynote at Mix 2008 with a demo by Jon Harris (10 minutes at about 98 minutes into the keynote)
- Mix Session: The Future of Microsoft Expression Blend
- Mix Session: SketchFlow – From Concept to Production
- Qixing Zheng has just recently posted a few short tutorials
There are also a couple of samples that are included with the Expression Blend download.
As designers of software products, what we build every day has become much more complex, much richer and more dynamic over the years. Creating, describing and communicating design ideas and specifications for modern user experiences has accordingly become more involved.
In many ways, one of the earliest roots of SketchFlow grew out of frustration with the process of mocking up and evolving design ideas for dynamic interfaces. We also talked to other designers involved in various parts of the software sausage factory, and the pain points we heard of were similar to our own:
- It is too hard and time consuming to create compelling prototypes
- Communicating a design idea accurately and convincingly is hard
Part of the problem, we realized, was that almost all the tools for design work available were build with the needs of production tasks in mind: It was all about quality, polish, driving decisions, creating shiny finished assets. Our mindset during early stage design is usually quite different: We want to explore, expand the design space, be vague, tentative. Yet we still would like tools that “read our mind” – tools that understand our design intent and help us do a better job.
Early stage design of course is a wide field. With SketchFlow, we wanted to create a tool that would make it quick and easy to outline an experience, and to rapidly evolve it to represent as much of the dynamic aspects of interaction as cost-effectively as possible, so that we could try out more ideas before committing to a particular design.
We also wanted to help to communicate: a tool that would enable more stakeholders of the design process to be able to explore and evaluate the prototypes, and to provide feedback to the process.
We wanted to let you create living and breathing specs that bring your vision to life for all to see, helping us all to make more informed product decisions and end up with better products.
SketchFlow is the first product of this journey. Let’s go and explore…
The SketchFlow Map
In SketchFlow, you get the SketchFlow Map to model the flow, navigation and composition of your app.
What does that mean?
A SketchFlow prototype is made up from a collection of screens. You can think of a screen as Window, a Dialog, but especially in an early stage prototype I just like to think of a screen as a whiteboard that I can sketch on anything I like. Maybe I just start with a pencil drawing, a sticky note or a picture. As the prototype evolves, and I develop a clearer idea how the actual UI might look like, I replace the sketches with real UI. In the SketchFlow Map, a screen is represented by a colored rectangle.
Screens can be connected in the map to indicate that you can navigate from one screen to the next when the prototype runs. This is kind of like making a slide show in PowerPoint, except that the Map is not a flat list, but lets you connect your slides into any graph you like – one screen can navigate to multiple others and back. Navigation is represented by solid colored arrows that go from one screen to another.
One screen on the SketchFlow Map is always designated to be the Start Screen. This is the screen that your prototype begins with once you run it. You can make any screen on the Map the start screen.
Many times, when you think about UI you think about components. For example, as you think about a shopping page, you know your page has a catalog area, a menu and a shopping cart. It is often useful to show the existence of these logical components of your app in the “mind map” of your prototype.
This is what SketchFlow component screens are for. Component screens are just like other screens as far as their content is concerned, but they are never navigated to. Instead, they are inserted into normal screens, just in the same way as you would insert a menu on a page, or just like you would insert a table symbol in the floor plan of a dining room in an architectural home planning program. You can of course use the same component on multiple screens. Component screens are displayed as “oil tank” shapes on the SketchFlow Map.
Component insertion is represented in the map with a dashed arrow that goes from the component to the screen it is used on.
Did I mention, by the way, that you can import PowerPoint presentations to create a series of screens? Currently, this imports each slide as a picture only, but it makes it really easy to import existing click-through prototypes as templates for further work in SketchFlow.
Using drawing tools, sticky notes and pictures to begin a prototype is all good and well, but, hey!, we are building UI prototypes here… at some point you probably want to begin putting some UI controls on your screens.
Because SketchFlow lives in Blend, you can of course use any built-in WPF or Silverlight UI control or layout panel, and there are tons of external controls from third parties that you can use as well. You can also use WPF or Silverlight control libraries that you might already have.
The standard UI controls have a nice, polished look. This is good for a real application, but not always ideal for a prototype: If you show polished content too early, people evaluating the prototype easily focus on the wrong things, the details of the look in particular, even if the explicit purpose of the prototype is to look at the structure and concepts. It is just a human thing to do. Additionally, especially with customers, we often want to avoid giving the impression that we are further along than we really are – polished looks easily tempt customers into thinking they are seeing more than there is.
Because of this, SketchFlow comes with a set of Sketch Styles that give the built-in controls a look consistent with a prototype: wiggly lines and sketch fonts are used to create a sketchy look. But even with the sketch look, the controls are real functioning platform controls – the power of control templates lets us just replace the skin. You can of course at any point reset the control template to the original to get the platform look back.
Once you have any SketchFlow map, even the most simplistic one with just a couple of screens and a little drawing on each (well, even when you have one that is entirely empty, although that is not particularly useful), you can run your prototype.
You might ask yourself how you can interact with a prototype that you haven’t given any UI yet? This is what the SketchFlow player is for. Every prototype you build is running inside the SketchFlow player. If your prototype is WPF, the player is an app. If your prototype is Silverlight, the player is running in the browser.
Either way, the player is part of your prototype and you can distribute both together.
The SketchFlow player has two important functions:
Basically, the player adds “training wheels” to your prototype so that you can navigate and explore even if there is not a tiny bit of actual UI on the screens you have created yet. That allows you and other stakeholders to look at concepts, logical distribution, scope of screens and all the other important high-level decisions.
The player also allows anybody who explores the prototype to add feedback. You can type in text comments or use ink to draw right on the prototype. You can then export the feedback and send it back to the designer, who is then able to see it as an overlay on the Blend art board, making the feedback loop between designer and other stakeholders a bit tighter.
In the picture, the red & green markup was added in the player as feedback. There are also text comments to the left. The following screenshot shows that same feedback after importing it into Blend, right on the design surface:
Almost any design project needs design documentation. SketchFlow can export your prototype to a Microsoft Word document. What you get is a document that contains screenshots of the Map, as well as every screen and component screen you have in your project. You also get a table of contents and a table of figures. That can save a lot of work when preparing the paper trail that is often a project requirement.
SketchFlow by default uses the standard Microsoft Word template you have on your machine, but you can also specify a custom template.
In an early stage prototype, we often want to communicate a design idea really quickly and easily. Animation is a great technique to do so. SketchFlow of course offers a complete set of key frame-based animation tools that let you create as many animations for a screen as you need. You can set up your animations in such a way that they show up in the SketchFlow player helper UI for navigation, so that it is really easy to run and show animations as part of a prototype presentation.
For all its power, however, key frame animation is not always the most effective way to create walk-through-style animations. You simply have to create and manage too many key frames, slowing you down unnecessarily. Because of this, SketchFlow offers a special animation method called “SketchFlow Animation” just for these “show-what-this-UI does-step-by-step” animations. It pretty much works like clay animation: Add a story board frame, and arrange your screen to look the way you like. Repeat as often as desired.
For each storyboard frame, you can set a hold time (how long do you want to show this frame) and a transition time (how long does it take to transition from the previous screen to this one).
For those of you who have been using Blend before, you of course know that States are really not a new concept of SketchFlow, as they were introduced with Blend 2 SP1. However, states are so incredibly useful for prototyping that I want to mention them specifically in the context of SketchFlow.
States are very prevalent across almost all UI. We find them at various levels of hierarchy. For example, buttons have different visual states depending on if they are pressed, hovered or disabled. A web page might show itself slightly differently depending on if a user is logged in or out. Components on a screen might be collapsed or expanded.
In principle, we can model state in a prototype by using separate screens. For example, we have a screen that shows the web site in normal state, and one that shows the same web site when a user is logged in. This is quite possible, but not always the most convenient or efficient.
Visual States are often a better technique to use. Basically, think of a visual state as a snapshot of your screen. When you switch between states, you switch from one snapshot to another. States are really easy to create – just add one and then arrange the screen’s content as you please.
States are grouped into State Groups. This allows you to overlap multiple partial states on a screen, which is incredibly powerful As an example, you might have one state group that modifies UI elements that need to look different depending on if a user is logged in or out, and another that represents if the shopping cart is minimized or not.
States can also contain animations, which is a very nice bonus.
And to round the story out, we support smooth transitions between states that can be controlled in a flexible manner.
The following screenshot shows some pre-defined easing functions for transitions:
Wiring up Navigation and States
Using the SketchFlow player to explore a prototype is really helpful. But at some point, it is usually desired to wire up actual UI controls on the screens to cause navigation and state changes on your screens.
In SketchFlow, you can interactively wire up navigation, state changes and many other behaviors without any code. Because navigation and state changes are so common in prototyping, SketchFlow introduces special short-cut UI just for this purpose.
Blend 3 Concepts that REALLY help with Prototyping
Blend 3 introduces a whole set of features that give prototyping an extra dose of power and enable you to make it as real as it needs to be. In this post, there is no space to explain these in depth, but there are already other posts on my blog and the Expression blogs on most of these:
- Adobe Photoshop and Illustrator import. This does just what you would expect: Faithful import of Photoshop files, preserving layers, vector data, and text information. This makes it really easy to integrate Photoshop comps into a prototype. Also note that Blend 3 introduces a feature that lets you convert any graphics, including those coming from a PSD file, into a control skin.
- Data Binding & Sample Data. Many applications today are data-driven, and mocking up data-driven applications is traditionally a pain. Not so with Blend 3: Sample data lets you create meaningful sample data on the fly, and you can build working data-bound lists and master-details views just with drag and drop. You can even use a Photoshop comp as the visual template for your data binding. Watch the Mix keynote or the launch video for a sample of that.
- Behaviors. Behaviors are a mechanism that lets you add production-quality interactivity to your prototype with drag-and-drop. Behaviors are packaged, re-usable patterns of interactivity. We ship Blend 3 with some basic ones, but the mechanism is extremely extensible, and there are already several new libraries on our web site, including a set of physics behaviors. Behaviors and sample data together allow you to create deep interactivity in prototypes that would have required serious coding before. More on behaviors here.
- Workspaces. You can now create your own panel configurations in Blend and save them as custom workspaces. This allows you to adapt Blend to your tasks and needs. Especially when building early prototypes, for example, you don’t need most of Blend’s UI. You can easily hide it away by just making a custom workspace. Go here for a post that explains how…
So much for now… stay tuned for the next SketchFlow post…