On Friday I posted a quick report on my impressions of the Silverlight Firestarter event, which included my expressing surprise at what appeared to be a fundamental shift in the way SketchFlow was being promoted.
Christian Schormann from the Blend team sent a detailed response to those comments, which I am happy to reproduce below. Unfortunately it is not obvious from this blog that you can easily comment to a blog entry by clicking on the "0 comments" (hidden) hyperlink at the end of a given blog entry (blame Google for the UX, me for the fact I haven't customised things from the basic templates they provide!), which is why I received the email rather than a comment directly on the blog itself.
In any event I think it makes more sense to post this response as a separate blog entry, rather than as a somewhat hidden comment to the original blog entry
"Hi Ian,
I wanted to respond to a few questions regarding SketchFlow you brought up on your blog. I am part of the Expression Blend team, where I am responsible for product design and strategy.
You write:
"One thing that did alarm me somewhat, was the seeming step-back by Microsoft from the whole 'Sketch your application and then make it real - don't throw all that hard work prototyping away' story. Suddenly the story was that we should be re-using assets used in SketchFlow applications and not turning 'sketch' controls into 'real' controls as documented in the Blend 'Help' feature. Given that most of these assets are produced in Adobe Photoshop and other tools outside of Blend it kind of begged the question 'So the real advantage of SketchFlow over Balsamiq is...what exactly?'."
Let me comment on the last point first.
Balsamiq creates static mockups of UI. It does so very fast and with minimal learning effort.
SketchFlow is meant to make it more cost effective to create, explore, evolve and communicate deep dynamic prototypes. In SketchFlow, designers can model high-level flow and composition (from a product design perspective) of a user experience. They can use animation to illustrate their design intent. They can model and experiment with states and state transitions. Using sample data and behaviors, they can create compelling prototypes of serious interactivity. With the SketchFlow player and feedback tools, other stakeholders in the process can evaluate prototypes effectively. SketchFlow thus has a very different goal than Balsamiq. SketchFlow certainly can be used to simply create static mockups, but it is much more special for prototyping dynamic interactivity.
We believe that both mockups and dynamic prototypes have their place in the design process – they are complementary. They are often not created by the same people, and they are usually artifacts of different stages in the design process.
Regarding prototype re-use, I don’t think our story has ever changed. We believe that the whole point of a prototyping process is to quickly generate and explore a multitude of ideas. Often, it is a good idea to not over-invest in such explorative prototypes, and to avoid getting attached to any given prototype: the longer one stays with a given idea, the harder it is to discard it when it fails. Introducing architectural or production constraints into the prototyping process too early risks reducing the productivity and effectiveness of prototyping. Also see Bill Buxton’s book on Sketching User Experiences for more on this argument.
Our general advice therefore is that in strict idea generation / verification scenarios, it is often better to not plan on re-using a prototype as the blue pause for an application. This is not an advice based on technical criteria or limitations of tool or platform, just a recommendation from a design process perspective.
However, we also recognize that SketchFlow is used in scenarios that are more RAD-style development than prototyping. Also, there are applications where the structure of a prototype naturally is similar enough for re-use in production. Because we know that there are certainly valuable cases for re-using prototypes as part of a production-oriented scenario, we enable conversion of prototypes into navigation applications. The process is currently not automatic, but it is feasible and documented in the manual.
In summary, our message is that if you want to prototype efficiently, we recommend that you focus on the design problem at hand, rather than trying to build architecture (or even think about architectural concerns) as part of the prototyping process. However, this decision is of course entirely up to you.
Should you, at the end of the design process, decide that either the prototype as a whole or individual assets are useful in production, we enable this re-use. It is a decision in the hands of a designer, based on the goals and complexity factors of the prototyping work actually undertaken. The tool enables re-use of projects and assets, but we believe it is not always a wise choice to expect to do so.
You also comment that most assets are created in Photoshop et al. There is of course no doubt about the prominence of Photoshop et al, but in many cases these assets undergo significant pre-processing . Visuals often need to be packaged into control templates, equipped with transitions, animations and behaviors, before they can be used efficiently. And there are many assets (for example UserControls or resource dictionaries) that are even more entirely “native”. In this sense we see a lot of asset re-use that would not easily be possible with pure artwork.
Finally, you write regarding a conversion problem with the metrics of the SketchControls. I will look into this – I have not heard about this so far. In practice, we have not heard that from many users, but then again, many SketchFlow users do not spend much time getting their layout to be very precise – SketchStyles are generally meant (and used) in the first place to convey the notion that the visual design (and the exact layout, as part of it) is just a sketch, and precision of layout is somewhat antithetical to this. That said, I still agree that the metrics should match, so I will look into the issue.
Christian Schorman"
No comments:
Post a Comment