31 Aug 2010 2259H

Prototyping with Microsoft Sketchflow

Well, bosses sprung for a copy of Expression Blend on my request — our software runs on Windows, we’re a Microsoft shop, so behooves us to find efficiencies and smooth transitions in the development lifecycle in any way possible — spent a few days last week picking it up and playing around with it. The copy of Dynamic Prototyping with Microsoft Sketchflow that I bought on my Kindle for iPhone was not so much helpful. I largely spent that time watching a bunch of very helpful videos on the Microsoft Design .toolbox and Expression website. It took a few days of wrasslin’ with the software to understand the capabilities and limitations came relatively late in the game, about day four or so.

Quickly evident, Expression is Microsoft’s answer to the Adobe creative suite juggernaut, but specifically for developing the front end layer, known as Windows Presentation Foundation, to the Microsoft .net platform that powers their desktop and the web platforms. The Expression package I got contains web, video, and vector graphics software, as well as the Sketchflow prototyping tool. Clearly the whole package is meant for driving Silverlight experiences across the web (I of course need not explain to the erudite followers of this pitiful blog what Silverlight is) and less so for desktop applications such as we design at Siemens, but still useful to a certain degree. Sketchflow comes with Expression Blend 4 and only in the Ultimate package, which is sad, because it really could be much more, like for instance if it was integrated with Visio. As I am writing this it is becoming more clear to me why Visio is being deprecated in favor of this tool, since Sketchflow generates actual code as well as UI, but I precede myself.

Sketchflow allows you to use a pre-skinned “sketch” style to plunk down user interface elements onto a workspace called the Artboard. After positioning and grouping the elements together in gestalt-y ways, you can create two types of screens with them: navigation and component screens, which can be linked together in various ways to simulate interactivity. The navigation screens are your main screens, such as one might envision using in Silverlight or laying out in Visio, and the components are parts of those screens that are used over and over again or that might have state changes and the like. You can control the different visual states of screens with built-in, pre-scripted behaviors relatively painlessly. It is rather easy to be overwhelmed by the sheer number of properties that a user can assign through the Windows Presentation Foundation to these Windows Forms, but fortunately, it is also easy to ignore the majority of these properties and focus solely on building your forms, navigation schemes, and how transitions and various visual effects might occur.

As I was saying previously, the bonus of working with Expression Blend 4 and Sketchflow, which is embedded in the Expression Blend vector graphics app, is that as you are designing in Sketchflow, you are generating XAML through the application, which allows you to create applications in Windows Presentation Foundation, so, this actually speeds up and eases the development and integration process between the UX and front end development efforts with the backend ones. Another very powerful feature of Sketchflow is that once you have your different states and layouts, it is easy to build the project and package it so it can be deployed to the web for quick remote u-testing or other feedback sessions, as there are built-in feedback tools that allow the reviewers to export their comments and visual guidance as files that can be sent back through email or the web. Also I like that you can keep building different levels of fidelity on the prototype all the way from the initial sketchy style, used to defuse potential misguided attention about the look and feel that sucks needed attention from the interaction and business logic, all the way to very polished software. As usual, it is pretty easy to do some basic things in Microsoft, but when you want to start doing some more, it starts getting more complex and you have to dig deeper into the Microsoft morass.

And that is where I left it, because I’m sure that somewhere, the business decision was made to support the development efforts of people working primarily on the web, which is where money still is being spent, as opposed to those folks who are doing desktop applications work, which is admittedly a minority these days. Sketchflow’s designers do not exactly support the desktop app designer as its very structure fundamentally assumes that most users are designing Silverlight apps to be deployed on the web or as rich media apps, so it’s disappointing at that level. Still, compared to the out-of-box experience of Adobe Flash, Sketchflow does more and more quickly. Palo Alto could take a hint from Sketchflow, except that Flash isn’t really used for developing desktop apps either.

However, as I also said previously, just the fact that there’s this possibility that you can speed along the effort towards tighter integration with backend development by passing them some working code is potentially a good thing if there is not too much rework. I remember, by the way, the days when FrontPage would generate so much bad code that as soon as we could, we abandoned it wholesale for Dreamweaver, and even then we still wrote our own code. But I leave that now to application developers, and I focus on interaction design.

Permanent link to Prototyping with Microsoft Sketchflow

Filed under Geekery, Interaction Design, Technology, Work

Respond »

Be the first to respond to "Prototyping with Microsoft Sketchflow"

RSS feed for comments on this post. TrackBack URL

No responses yet.

And now it's your turn.

Fire your weapon, soldier. Just be careful of friendly fire. NAME & EMAIL required.

Your response