Primordial Ooze

Starting Off, from Code to Markup

I'm reading the Petzold book on WPF  (part of the .NET Framework 3.0), Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation, and one of the exercises I put myself through was taking one of his code-centric samples and making it more declarative. I do most of my programming at home in Microsoft’s free Visual C# Express Edition. It’s a simple clean interface and I find that I don’t generally need all of the features of Visual Studio 2005 Professional.

Back to Petzold. In his book, he has a piece of sample code that declares a minimal display tree in the XML markup language XAML, and does the rest in code. The XAML looks like this:

<Grid>
</Grid>

He then adds a Canvas child and a Polyline object as children to the grid in code. Grid is defined in markup, and the children are defined at runtime in code. He has a C# method which loops through 20 revolutions of a spiral. Not rocket science.

Adding the canvas and polyline was done in code in Petzold's book, as follows:

// Make Canvas content of window.
Canvas canv = new Canvas();
canv.SizeChanged += CanvasOnSizeChanged;
Content = canv;

// Make Polyline child of Canvas.
poly = new Polyline();
poly.Stroke = SystemColors.WindowTextBrush;
canv.Children.Add(poly);

While I'll be the first to admit that I love code, this is the kind of thing that separates the "old" way (Win32, OSX) of constructing UI's from the new way (XAML). I wanted to do more delaratively, so I added as much as I could into the XAML, like so:

<Grid>
    <Canvas x:Name="_canvas" HorizontalAlignment="Center" VerticalAlignment="Center">
        <src:SpiralData x:Name="data1"/>
        <Polyline x:Name="_poly" Stroke="Black" Points="{Binding ElementName=data1, Path=Points}"/>
    </Canvas>
</Grid>

Now, notice that the points of the spiral are defined elsewhere, via databinding. Consider the "SpiralData" markup; this instantiates a C# class I wrote which supplies the points needed for the spiral as a PointCollection (Path=Points).  Now *that* is what code is for.

So fine, no big deal. Here is the running app:

Programming XAML by hand in this way feels like programming HTML by hand. It’s easy and precise, but can get time consuming. It also can get tedious and downright impossible to manage as the complexity of the scene increases. Ideally, you would set properties like stroke, fills, and alignment in a visual editor of some kind.

The Awesome Part

Now comes the AWESOME part. Yes, I said that already. Microsoft has a tool called Expression Blend, which used to be called the Expression Interactive Designer. It’s free now, but I guess that it will cost between $150 and $250 bucks when it’s released. Blend is a tool like Shockwave/Flash, allowing you to build vector assets and animate them. Microsoft is also coming out with a tool called Expression Designer which will be analogous to Adobe Illustrator; concentrating on providing an optimal toolset for vector art creation, leaving animation workflows to Blend.

Blend is tightly integrated with C# project files. You can even load a C# project, build it and even launch it as an EXE (just like you would build and run in VS).

However, ...I'm giddy here so bear with me, the visual designer was able to honor my databinding and showed me the spiral in the designer!

Read that again, Blend showed me the spiral in the designer! It looked like this:

I could click on the spiral, which was immutable and read-only in it's shape, but I could translate it, scale it, and modify the presentation (like the stroke), all using the designer! There is a complete integration between arbitrarily complex object shapes defined in code and the rich design user interface!

The Designer / Developer Work in Harmony

This is truly the holy grail of app development. Designers can work directly with the code and hopefully a much more rapid feedback loop will be possible.

What About Illustrator?

If I wanted to accomplish a similar feat in Adobe Illustrator, I’d have to learn their complex plugin API and be able to manipulate their internal data structures. Granted, Adobe provides a nice automation interface to do this, an interface exploited by my colleague Pavan Podila in his XAML Exporter for Illustrator. However, it’s not THIS simple. I can’t use C#, my preferred programming language, and I absolutely can’t get this kind of tight intergration between the development and design tools.

I must admit, I can’t imagine that Microsoft will ever (and I mean ever) create a tool as powerful and intuitive as Adobe Illustrator and I can’t see any serious designer using anything but Illustrator. Perhaps Microsoft’s Expression tools will become “good enough” over time to bring some designers on board. Perhaps not. What I think is most likely is that tools like Pavan’s XAML Exporter will mature and get backed by real companies that will provide very robust integration between Illustrator and XAML, Illustrator and Expression, or some other combination.

So, What’s Possible Now?

In a later post, I’ll explore some of the editing features of Blend and how changes in Blend can be realized within your running C# projects based on the .NET Framework 3.0.