If you can't beat XAML, improve it

On my travels I get to speak to lots of developers who use (or want to use) WPF but feel slightly frustrated for one reason or another. Typically, it isn't obvious why they're frustrated at first but the conversation nearly always leads to them expressing their frustration with the tools. Typically, their feelings are:

Blend is too hard for developers
Cider (VS' WPF designer) is no good for building LoB apps

I guess Blend isn't really for developers, it's for designers. I began my career in IT as a web designer and so I'm pretty familiar with designer tools like Photoshop and Illustrator. I'm also pretty comfortable in Blend but I have to come clean and say I flat out find it doesn't get much use when it comes to much of my WPF development.

I wish I could say I use Cider instead, but I don't. As long term readers will remember I actually disable Cider and go for full screen XAML editing. There have been improvements made to Cider that will come in VS2010 but mostly they just bring the capabilities in line with Blend (improved Binding support, searching for properties etc).

So where does this leave us? For me, it leaves me in a very happy world of coding XAML angle brackets and using Blend for animations and re-templating controls.

Text isn't so bad

I heard Don Box talk about Oslo and modelling recently and something he said turned on a whole row of lights in my head: "Developers don't like visual tools, they like text". He was referring of course to early concepts for Oslo which only included visual design tools to create models and the poor reception they got. They eventually realised that developers liked to create their models in text - and I'm no different.

We have the same with UI - designers are just modelling tools to help us create the UI in a visual way. It just so happens, in this case, that the model is _very_ close to the end result, but the principle is just the same. If we look at ASP.NET - we have a very good design surface available and whenever I have a discussion about WPF and tooling I always ask this question:

"Do you use the designer for ASP.NET development or do you code against the source with angle brackets".

In the two or so years I've asked that question nobody has replied 'designer'; they always reply 'angle brackets'.

So what was different about Windows Forms? Everybody used the designer in this case - but you had no choice. The 'serialization format' of the Windows Forms designer was C# which, as excellent as it is, offers a horrible experience for describing object graphs when compared to XAML or HTML (and ASPX).

In short then, I'm very happy developing in XAML.

Having said that, there are problems, two of which I think are key:

Barrier to entry - having to code in XAML creates a large barrier preventing many from entering the WPF world - this simply wasn't the case for Windows Forms. For this reason, I think the existence of Cider and it's continued development is very important. I also think Cider needs a total rethink when it comes to layout but that's a topic for another day.
XAML's ease of authoring (or lack thereof) - XAML wasn't created with hand-crafting in mind and it's obvious, the verbosity on occasions becomes numbing. Specifically, XAML was designed with the idea in mind that it *shouldn't* be written by hand. This simply isn't the reality we find ourselves in.

XAML authoring continued

Charles Petzold discussed this in an article for MSDN Magazine: Let my people code:

"But in some people's minds, writing XAML is an aberration. XAML is not supposed to be hand-written. As one Microsoft blogger put it, "XAML is for Tools," and over the months prior to its release, some XAML features have been removed because they were strictly for the benefits of humans rather than tools.

If this is true, I think it's time we realised that this currently doesn't stand. More people are hand crafting XAML than are using tools so in my opinion we should have a parallel focus on making XAML more authorable. Imagine going from this:

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="Auto" />
        <ColumnDefinition Width="433" />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Height="*" />
        <RowDefinition Height="Auto" />
    </Grid.RowDefinitions>
</Grid>

to this

<Grid
    ColumnDefinitions="*,*,Auto,433"
    RowDefinitions="*,Auto" />

Or from this

<Border>
    <Border.RenderTransform>
        <ScaleTransform ScaleX="2" ScaleY="2" />
    </Border.RenderTransform>
</Border>

to this (which would be easily achievable with a custom MarkupExtension)

<Border RenderTransform="{ScaleTransform 2}" />

Of course, it's arguable that XAML, the markup language itself, isn't to blame for this verbosity - it's the object model within WPF. However, there's a blurry line between the two in most people's minds. Also, I suspect some changes to XAML might be necessary to really make a radical difference to XAML authoring.

Tags: WPF Xaml

Post By Josh Twist

Follow @joshtwist

6:21 AM
28 May 2009

» Next Post: GetHashCode and LINQ to objects
« Previous Post: ViewModels and CheckListBoxes

Comments are closed for this post.

Posted by Dr. WPF @ 28 May 2009 12:03 PM
I agree with most of your points, Josh! I rarely (if ever) have Blend installed and I always disable Cider in favor of the Source Code Editor in VS. I just prefer hand coding XAML. It forces me to be smart about UI composition, whereas tools often lead to bloat.

I've come to accept and even appreciate the verbosity of XAML because it very accurately reflects the code that is represented by the markup. In fact, when I am introducing developers to WPF, I really drive home the idea that XAML is just a serialization format for CLR objects. (This resonates well with developers... whereas designers tend to prefer thinking of XAML the way they do traditional markup.)

Having said that, I would love to have a few of the old mini languages back... especially around transforms and gradient brushes. And I like your idea for column and row definitions.

It also seems like there are a few classes where the framework could simply designate a Content attribute (Setter comes to mind... the default Content for a Setter should be its Value).

Way to beat the drums! I'll gladly jump on your bandwagon. :-D

Posted by Stefan Olson @ 28 May 2009 9:30 PM
You are absolutely right Josh! Unfortunately the situation is so much worse in Silverlight because of the visual state manager which turns code that would be 20 lines in WPF into 200 or 300 lines!

The whole defining columns thing is extremely frustrating wastes a lot of time.

...Stefan

Posted by Mark Rendle @ 28 May 2009 11:10 PM
I completely agree. In VS, I have the WPF design surface visible at abour 20% zoom as a thumbnail view of the Window/Control, but I code everything directly in XAML. Your row/column suggestion would be a huge improvement.

In fact, I wonder if it would be reasonably straightforward to introduce some kind of macro expansion loosely based on XSLT, with which developers could define their own extension markup attributes.

Posted by Ralph @ 29 May 2009 3:47 AM
XAML authors have definitely been neglected to date - it would be great to see some focus on improving this experience.

Posted by Charles Petzold @ 29 May 2009 8:59 AM
There was once a transform mini-language in XAML, but it was removed before the WPF release. However, you can still set RenderTransform and LayoutTransform to a string of six numbers corresponding to the six settable cells of the Matrix structure. For your example:
RenderTransform="2 0 0 2 0 0"
I use this technique all the time for scaling and translation, and even sometimes for simple rotations.
Recently I've been teaching some three-day courses on WPF and Silverlight, and I really emphasize the importance of learning to write XAML by hand.

Posted by Doron Assayas @ 31 May 2009 2:13 PM
I learned to become a hand-crafter the hard way: the tools didn't work as expected or the code they produced was too bloated, making it hard to port, restructure, expand, etc. Even worse, you can never know what subtle (and potentially unstable) changes will be inserted once you more an unrelated pixel on the other side of the screen. Most markup editing GUIs I tried to this date have suffered from the same problems, the XAML tools being no different.

But regardless, I think that readable and easy-to-write plain-text code is key to successful penetration of a new format:hand coding promotes better understanding of structure and functionality and ultimately leads to better code, less bugs and less frustration. (The fact that many things eventually need to be fine-tuned without the hassle of installing and/or loading up a heavy graphic environment is another issue that cannot be ignored). The overly verbose markup of XAML makes it hard and time consuming to work this way and makes HTML much more appealing despite its well-known RIA limitiations.

Posted by Bart Roozendaal @ 16 Jun 2009 12:14 AM
I am a very experienced programmer and have worked on a great number of languages (C, Basic, Smalltalk, Pascal, Fortran, Cobol, C++,, C#). Recently I started working on WPF. And I am one of those developers that is experiencing more difficulty grasping WPF than I did with other languages.

I don't think that it's because of XAML per se though. I don't mind typing in long XML element names and attributes. I don't mind writing all the end tags. I don't mind typing at all. Visual Studio / DevExpress' CodeRush offers me all the aide that I need for that. Code completion, templates, short cuts, et cetera make that real easy.

What I do have problems with is the actual concepts in WPF. One thing that I find really difficult to learn and to accept really is the fact that one must/can implement a lot of functionality in the XAML, which in my mental model represents the display part of the application, not the code. I seem to be that old fashion developer that wants to type a=b if I want to assign the value of b to a.

WPF/XAML drives me away from that mental model and I'm very much aware of that. It is beginning to win its place in my brains, but it's taking longer than I thought. Even being aware that another mental model is needed for WPF doesn't make it easier for me.

Maybe XAML *is* for designers. That is why I'm trying to work more closely with our visual designer (i.e. having him learn Blend) and leave more of the work to him.

But, it's really new and sometimes hard to go this way. I'm so much used to being able to do everything in our software. That is no longer the case. I will get used to it, but it may take me a bit more time.

My 2cts worth.

Bye,
Bart

Posted by Siderite @ 05 Jan 2010 10:14 PM
I haven't done much WPF work, but from what I have done, XAML text editing seemed the best, if not the only solution. Problems arise when I am trying to build some graphical vector image or gradients and such, and there I use KaXaml to do the work. Blend... I've installed it several times, never got it to work right with my projects and I saw no reason to actually buy it then. To this day ReSharper seems to be the tool that helps me most every single day, and they have great XAML support.

Posted by dgkimpton @ 11 May 2010 5:58 AM
I completely agree. The result of this is that I've put coding on hold and am going to go 'back to school' as it were to try and learn to think from a designers point of view.

Somewhere along the line someone lost sight of their target audience and instead got carried away by building for tools (which is daft... tools can consume human readable text much more easily than humans can consume machine readable text).

XAML has made a few decisions that have made it really hard to use in text mode and that is a great shame because I think we can all agree that something more than C# is really needed for construction of hierarchical structures.

And the really sad thing? The WPF model is pretty damn impressive once you get past the xaml.

Posted by pescuma @ 17 Nov 2010 5:11 PM
I just found this post. The funny thing is that I had the same idea a few days ago and built this: http://wpf-ex.googlecode.com

Welcome

Feeds

Archive

Editors