After almost one year of using Balsamiq I decided to give Blend SketchFlow a try. After using it in one project, I realized it’s not a sketching/mockup tool. And here I’m telling you why.
My definition of a sketching/mockup tool
I think a sketching/mockup tool should be a replacement for sketching on paper. It should allow you to “draw” lines, add a textbox and some text, without thinking too much about alignments and about how you will “implement” UI element in the real application. And must have a quick way to include common UI elements like windows, dropdown, tabs, grids and so on.
SketchFlow could be improved in many ways, but there is one main point that would probably need a more high-level rethinking: it’s not intuitive and forces you to think too much about how the design will be implemented. But let’s look at it in detail:
New Project window: SL or WPF?
First thing I didn’t like is the “New Project” window: why do I’ve to choose between a Silverlight and WPF application? What if I want to prototype a web application?
You have WPF/SL Controls
There is only a very small selection of sketch components and for most of the complex UI elements you either have to design them with lines and rectangles, or have to use the standard SL/WPF controls. For example you have to use a DataGrid if you want to display a table with data. Or the calendar, the canvas layout, the stack panel, the grid layout and so on. This is a problem because it forces you to think in terms of controls rather then in terms of sketches.
You need to understand data binding
If you want to add text to a list, a combo or the aforementioned data grid, you have to understand data binding: add a sample data source, bind it to the UI element and configure the visualization options.
Default style is not a sketching style
One last point is that I would have expected to have the sketch style (the wiggling stroke) by default. But the default style is the standard WPF/SL one. To get the correct style you have to click on the tiny little arrow button and choose from the big list of controls.
With SketchFlow you can do fancy animations or state transitions, but I don’t think this increased power will be used by interaction designers and by UI experts. And since these advanced features must be developed with code (or by dragging behaviors) I think they are just adding complexity if you all you want is a sketch of your application.
Probably I was using SketchFlow for the wrong purpose, but it seems to me like a tool for prototyping the UI of a WPF/SL application rather then a general purpose sketching application.
After using SketchFlow in this project I think I’ll never use it for sketching web applications again. Probably I’ll use it when I’ll need to design a WPF/SL app, but not for web apps. I’ll stick to Balsamiq for now.
What can Balsamiq learn from SketchFlow
But not everything that SketchFlow has is bad. It also has some interesting features that I’d love to see also in Balsamiq:
- the navigation tree that makes very easy to create the “flow” of the application (Peldi says they are working on it)
- the possibility to “componentize” some parts of the sketch, like a navigation bar that is the same in every screen (There is a lot of talking on this in Balsamiq forums)
Exporting a Balsamiq sketch to a player
Another feature of SketchFlow that I now I want so badly with Balsamiq is the possibility to export a “playable” version of the sketches for sharing with stakeholders. And you can do it now using Napkee, a very nice AIR application that can export Balsamiq projects to both Flex or HTML/CSS/JS. There are also other opensource tools to export to various other formats.