Sparkle, development teams, and what ‘no code’ means

Microsoft Expression “Sparkle Interactive Designer” (Sparkle for short) was announced and demonstrated at the Professional Developers’ Conference in Los Angeles last month. To find out what this powerful tool is all about, see the Expression Home Page, the Sparkle Team on Channel9, and Eric Rudder’s PDC keynote.

 

So, what is the Sparkle tool good for and who will use it? Well first of all, if you’re evaluating the Windows Presentation Foundation (WPF) today, you’ll have noticed that Visual Studio currently has no design surface for XAML source code. In time, Visual Studio will have design support (codenamed ‘Cider’) for WPF suitable for the needs and wishes of software developers. What Sparkle will offer over and above Visual Studio’s WPF designer is a set of features aimed at professional user-experience designers.

 

The kind of designers I’m talking about have creative and technical skills including graphic design, usability design, and interaction design. The North Face demo (also shown at PDC) is a beautiful and striking example of how WPF brings the development of creative interactions within reach and obviates a specialization in 3D computer graphics.

 

Developers with design sensibilities will also use Sparkle, just like designers with programming sensibilities already use Visual Studio. These skill combinations are very common – what’s less common is to be excessively talented in both spheres. So Sparkle will not ‘turn developers into designers’ nor ‘require designers to be developers’ but it will give the members of large development teams the opportunity to specialize whilst preserving the MSBuild format of projects transferred between Sparkle and Visual Studio.

 

Clemens Vasters has written an excellent blog entry about subject-area specialization in which he discusses what he calls visualization developers. Visualization is a component of interaction and the members of this sector of the development team may equally well be called interaction designers and possibly, for the trickier coding, interaction developers.

 

Which brings me onto what code means and, more importantly, what no code means. The community regularly describes HTML, XAML, C#, VB.NET, etc as code which implies that any formalized, syntactically-constrained encoding is code (whether the logic is declarative or imperative). But often, in demonstrations of WPF and Sparkle, the speaker (myself included!) points out that no code was written and I think this deserves some clarification.

 

Typing XAML into Notepad or Visual Studio is, arguably, coding and the no code assertion is hard to support. Similarly, a Sparkle project with no code is an empty one. Rather, what’s compelling about WPF is that the semantics of the code is incredibly rich so you need less of it. What’s compelling about designing on a surface in Sparkle or Visual Studio is that the tool generates the code for you. It so happens that declarative code is more practical for tools to generate than imperative code and that a design surface is able, in real-time, to reflect edits to declarative source code whereas imperative source code is built before it is expressed. So it’s likely that great tool support, making XAML so friendly, is the reason we often overlook it as code.