(X) Hide this Upcoming webinar on Feb 23rd, 10 am PST (see your local time): Building Line-of-business Applications with Silverlight & WCF Data Services
More webinar info | Register | Other webinars
Tweet @silverlightshow and win a SilverlightShow Tweet-shirt. Learn how >>
Skip Navigation LinksHome / Articles / View Article

SketchFlow from a developer point of view - Part II - Dev Stuff

+ Add to SilverlightShow Favorites
2 comments   /   posted by Braulio Diez on Aug 13, 2010
(4 votes)
Categories: Videos , Tutorials , QuickStarts

 This article is Part 2 of the series Sketchflow from a developer point of view:

  1. SketchFlow from a developer point of view - Part I - Basics 
  2. SketchFlow from a developer point of view - Part II - Dev Stuff


In the first part of this article we learnt why was so important to add to our lifecycle a quick and dirty prototyping stage, and learnt as well how to perform that basic sketch prototyping using Sketchflow.

So far so good… till now the sensation you can have can be something like: Ok, Sketchflow is just another prototyping toolin this second part of the series we are going to check what makes Sketchflow an advanced prototyping tool: sketching some static images or canned / styled controls with some basic navigation is not bad but not good enough !! We need to validate with the client animations, gestures, behaviors…. remember from the lessons learned and the final client feedback  we pointed out on our previous article:

  • That simple let the user drag a product from the list and drop it into his check out list, turned to be a 3D animation including surround effects, I know it’s our fault, for sure you clearly defined that at project startup when we were drinking beers in that noisy pub.
  • The user was not happy with the sketched coverflow control, he wanted to check how does it really worked.

Let’s start exploring the features that makes Sketchflow a unique prototyping tool.

Step 4: What about special animations

Defining mockups and navigation is quite important but another source of problems can be defining certain animations or behaviors.

Animations: Sketchflow has an easy to use and powerful animation window, it lets you define frames and change in each frame properties of controls (e.g. opacity, position, ...), it performs as well interpolation between the frames to allow you create smooth animations without having to define a big bunch of interim steps (e.g. you can place a rectangle at position 0,0 at frame zero, and move it to position 100,0 at frame one, if you click to play, it will perform an smooth animation, moving: 0,0 1,0 2,0… 100,0).

About our sample let’s see how to create an animation (opacity full to none) to display an Administration menu:

Video Creating Animations (low)

Video Creating Animations (high)

Sample Creating Animations

Step 5: Uh ! Do you want to see how does it work with a real custom control?

Let’s now refresh a bit our mind, we got some feedback from our client about the members coverflow sketched window:


The client is not happy with that, we need to provide something that could provide a  similar experience to the real app and sign off the behavior of that control: mouse gestures, animations… But how can we achieve this task? Good news is that a Sketchflow solution is a Silverlight app, so we can add DLL’s references (our own controls or third parties ones, or…).

In this case we have found an excellent coverflow control in Codeplex, let’s see how we can integrate it and add test data:

Video Custom control plus sample data (low)

Video Custom control plus sample data (high)

Sample Custom control plus sample data

After reviewing the control with the client, he asks us to implement an additional mouse gesture: let the carrousel photos to be moved by dragging and dropping with the mouse. After this we ask…Any other additional gesture you need? No? Sure? Really Sure? … Ok, let’s sign off this requirement.

Before jumping into the next topic just a warning, be careful using this “real control” approach, if you abuse of this option, you can fall into:

  • Loosing prototyping speed, not a good idea (finally you can end up more coding than prototyping).
  • User will tend to think that the project is almost done (press click the on the “setup my data and validations there” button).

Step 6: Test Data plus Behaviors

Today our client comes with a concern… Where is my send a message page? Ehh ummm… after reviewing the sketches and the prototype versions we sent by mail and he agreed / signed, he realizes that … Ouch sorry I forgot to mention that we need that page, what can we do? What we answer No prob, probably is a great functionality what you want to add, we are going to go through requirements gathering, build a quick prototype page and once agreed impact the cost of this change request.

We build a quick prototype using sketched styles control, but this time:

  • We want to let the user browse real test data.
  • We want the user to be able to perform a drag and drop operation.

Now we are going to check how to add a custom behavior to our page, in this case we are going to have a page that let us send a message to some members of the community, we are going to show two lists the full list of members and the To list, we will allow the user to  drag from one list to the other:

Video ObjectDataSource plus Behaviors (low)

Video ObjectDataSource plus Behaviors (high)

Sample ObjectDataSource plus Behaviors

After reviewing the prototyped page, and realizing that the change request means more budget + timeline, the client decides to postpone the implementation of this “important” functionality to a later release, no more Hey dude add a cool transition and a new page it’s just a 5 minutes tasks isn’t it?

Step 7: Do we agree? Let’s sign off a formal document

Lot of discussions with the client Emails back and forth with the prototype and feedback, but finally we’ve got client and developer on the same page, yahoo!!

It’s time to sign off some formal document, to refresh in the future:

  • The client’s mind… whenever he has some brilliant idea. Usually clients change their mind every week… but when they have to pay some additional money once per month ;-).
  • Our developers mind… when we realize something is a bit difficult we are tempted to say… why not implement that in another way, in our case this temptation gets higher and higher the sooner we are to the release date…

Well let’s start this doc from scratch … but wait, Sketchflow can provide us with the barebones structure, let’s see how it works:

Video Generating Documentation (low)

Video Generating Documentation (high)

Step 8: From Sketchflow to production

Ok, so finally seems that this time we have got clear requirements, even we have a live prototype!

Now comes the one million dollar question… if the prototype that we have created is a Silverlight App, why not take it as a base solution for our real implementation? The answer is NOOOOOOOOOOOOOOOOOO !!! and reasons why:

  • Prototyping is based on a quick and dirty process, the main goal is to capture client’s requirements, if we want to create a real application we should start from scratch setting up strong pillars.
  • Although we could reuse the XAML layout (sketched styled controls can be changed to normal ones), is not a good idea to do it so, we have created this UI just by dragging and dropping (playing with margin property), this means, the layout itself is weak, no grids, no reposition on resize, inserting new controls will become a dirty work… on the other hand Sketchflow allows us to create complex layouts but then we would loose speed building the prototypes.

More details about this topic in this link.

If any way you want to give a try, you can review this articles / posts:

  • Convert a prototype into a production project (WPF and Silverlight)
  • Sketchflow to production

But… is there something I can reuse? Well… you can:

  • Place a folder for shared assemblies, styles, behaviors, that you can use in your real project as well.
  • Create assemblies for entities and viewmodels (remember the objectDataSource sample we saw before), for sure this code will need some refactoring in the real app, but it can be a good startup. This approach can be quite useful to create a prototype with real validations.

Step 9: What about other tools?

Yes, prototyping tools is not something that Microsoft has recently invented, you can find other tools out there in the market:

  • Visio:
    • Very easy to use.
    • Very limited.
    • Just ok for static mocks.
    • Who hasn’t Visio installed in their machines?
  • Balsamiq:
    • High level of usability.
    • Very simple.
    • Multiplatform.
    • Trial version available, commercial version about 79 $.
    • Lack of master page / component concept.
    • Lack of animations / behaviors / interactions (you just generate a PNG).
  • Axure:
    • A bit more complex than balsamiq.
    • Includes the concept of master page.
    • Allow some interaction / custom actions.
    • Generates a HTML prototype.
    • Trial version available, commercial version about 589 $.
  • foreUI
    • In a similar line as Axure.
    • Trial version available, commercial version about 99 $.
  • GuiMags
    • Interesting approach sketch your screens using a physical white boards plus GUI mags.

One common topic that Sketchflow has and these tools not is that Sketchflow is targeted for Silverlight / WPF apps.

Which one to choose? depends on your prototyping needs, it’s worth to give a try and decide by yourself. In my case I’m a Silverlight geek, and I need to close with the client more than mockups, avoiding nasty surprises one week before going live is a high priority risk I have to mitigate the sooner the better.


In this article we have learned how important is to build prototypes at early stages of a project life cycle, and what powerful tools offers to us Expression Blend Sketchflow. Let’s summarized what we have learned:

  • Sketchflow provide us with a quick and dirty way to build a prototype using just hand drawn sketches.
  • We learn How to build a page by using sketched controls and reusable components.
  • How to simulate complex interactions (animations, behaviors…).
  • How to add real data to our prototype.
  • How to integrate custom controls.
  • Which other tools are available in the market and why Sketchflow can be the recommended one for Silverlight / WPF targeted developments.


Comments RSS RSS
  • RE: SketchFlow from a developer point of view - Part II - Dev Stuff  

    posted by Favio on Dec 31, 2010 04:47
    Thank you. Your post was the most useful to me in addressing all the issues I've had dealing with EB4 Sketchflow & final production Silverlight application. I understand the issues much better now. I only wish MS was more clear on what expectations we as developers/designers should have when using a prototyping application like this. I'm a fan of EB4+Sketchflow. I can only hope the next iteration will be even better when it comes to re-usability. Perfhaps not in its entirety. But at least a good portion of the animation, behaviors, and navigation.
  • RE: SketchFlow from a developer point of view - Part II - Dev Stuff  

    posted by Braulio Diez on Jan 02, 2011 09:00

    I think the nicest approach could be to expose like an object model, and let us developer implement extensions, e.g.: based on sketchflow navigation build a solution for the MVVM light framework, or Prism, we could even break it in modules based on the colors / grouping of the pages.

Add Comment


Please add 8 and 2 and type the answer here: