Using Expression Blend Sketchflow - Relevance To Silverlight Programming Implementation?

Question

I have recently been programming Web based applications using Silverlight & Ria Services. I have been made aware of the ability to incorporate the use of Expression Blend Sketchflow into my development cycle as a way of producing quick prototypes to show clients when using an agile methodology. I have found it hard to make use of sketchflow, as it seems that the idea behind it simply doesn't map to the idea of programming a silverlight application. In essence what I am trying to say, is that in order for me to produce a quick prototype for a client in sketchflow, i am required to do bits of programming to actually show the real functionality of the potential application - but isn't the whole point of sketchflow to skip out the programming phase and sort of "Design" the application to give to the client.....I'm finding it hard to say what I want to say, but I feel like i've missed something with the use of the sketchflow feature....

Scenario: Data driven application requires a few datagrids to display relational data. If I program this straight off it's fine and dandy and doesn't take ages. However If I use sketchflow, I cannot show the same amount of functionality (without doing some bits of coding) - catch my drift!!?

Opinions and comments/advice welcome.....

Answer 1

We use SketchFlow and have had a great response from management. Two things that come to mind are that SketchFlow is obviously better than a Word document since the customers can see an application in action. From the other side of things you make the point that it does require some programming, and that's true. The reason it's better than doing a prototype in Silverlight (and this might sound strange) is that the prototype comes out squiggly and comic looking. It looks nothing like a real application. Far too often in my experience management has seen a working prototype and somehow got the opinion that "the code is already 50% done, i've seen it!" As a dev you may know that prototype code is garbage and should be thrown away but management doesn't know that. I can think of a number of production applications I've worked on that are still running prototype code because management saw it and decided to rush the project along, SketchFlow helps to alleviate that while giving you the expressive power of a running application.

Answer 2

You can't think of a prototype in Sketchflow as an "application". Think of it as a series of storyboards that are connected through simple navigation. If you find yourself programming the code-behind in sketchflow, you're probably trying too hard to make it work like an application.

You have to think of sketchflow as a representation of a simple state machine where each screen is a state. I think the temptation of programmers is to dive into "how" instead of saying "what". Each screen represents what is to be done and how it should look, but it shouldn't describe the design/architecture of how that is accomplished. If you need to replace a collection of controls on a screen and replace them with different ones, don't program it, make a new screen!

For example, I wanted to create a sketchflow prototype that had a menu system similar to the main menu in the Zune software (menus within a menu). I spent a day spinning my wheels trying to program a component screen with states and animations that would reveal or hide the submenus. The next day it occurred to me to create a separate component screen for each item in the main menu and now I have 3 component screens which contain no programming except simple navigation.

As far as relational data, I think a reasonable amount of "hand waving" should be expected in a mock up. Requiring a sketchflow mockup to have rigorous datagrids that display "real" data feels like you're talking down to your audience as if they haven't enough imagination to understand the intent. But that's my 2 cents...