I want to start off this blog post with saying that I love Expression Blend! I have only used Blend 2 SP 1 before today, but I love the idea, the interface and the program in general. But in Blend 2, there were a few things I missed. The most obvious flaw in Blend 2 is the missing intellisense. It also expected me to do ALL my coding in VS, which to be perfectly honest is a good thing. Coding should not be done in Blend. Blend is the tool for the interaction designer, or possibly the “devigner” and not for the developer.
But this is where I start getting a little ambivalent. I want to be a good developer and say that that is the way that I generally do my Silverlight problems. The developer doing the coding in VS and the designer doing the layout on Design and then the interaction designer/”devigner” putting it all together in Blend. Unfortunately that doesn’t add up in my world…sorry Microsoft…I love the idea, but in my world it doesn’t work, even though I wished it did.
In general, I would say that the interaction designer/”devigner” is not available. Either the designer handles Blend and does the work in there, which in general ends up with the developer having to do the bindings and binding converters, or the designer stays clear of all of that and the developer does the Blend work. I guess that is mostly because the industry hasn’t yet matured and got into the habit of hiring “devigners”.
I’ve been writing “devigner” over and over again as if this was well known word. For those of you who don’t know what a “devigner” is, it is a guy sitting between the developer and the designer. This is a role that will probably become pretty popular in the future. I guess an interaction designer does sort of the same thing, but still not really. I would say that the “devigner” knows a bit of development and understand how that part works, while also knowing design and being able to give the application the correct look and feel. The interaction designer is probably a bit more designer, focusing on animations and application feel. So I guess the “devigner” is probably a little bit of that as well.
Having that said, I want to object to the word “devigner”. I only use it due to lack of an alternative that I like. Why don’t I like it? Well, “devigner” sounds a lot like somebody who is or makes things divine. And to be honest, there is nothing divine about this person. If I were to be an ignorant idiot, I might even call him/her the opposite. The person probably can’t code for real, and not design for real either. So that would make it just a stupid link between the two work forces doing the real work. But, that is definitely not my opinion. I think that “devigners” have a bright future. They will be in demand, and they will be the difference between a smooth operating team, churning out good looking, nicely working applications, and a not so smooth teams, delivering applications that do the job, but without that extra refinement that makes the customer come back over and over again.
Anyhow…too much talk about a freaking word…lets look at the features in Blend that makes me wonder what Blend aims to be and what problems it is supposed to solve.
In Blend 3, we get one feature that I have missed a lot in version 2, interllisense. Blend now supports intellisense in Xaml, as well as when working with code…yeah…Blend 3 now has support for coding C# as well. That was NOT something I missed in 2. Doesn’t that sort of deviate from the idea that the developer uses VS and the “devigner” Blend…? I’m not saying that I don’t like it, it’s just that my gut feeling is saying that this is going to cause all sorts of problems in the future. Especially if you have a “devigner” that figures that he should just make that little code change that he needs without really knowing what he is doing…
Blend 3 also has support to integrate with Team Foundation Server for asset management. That is a sweet feature that makes the integration between the developer and “devigner” a lot better. Not having to have VS to check out files or having to have the developer check out the things and then hand them off to the “devigner”. A great step in the right direction. But to be perfectly honest, if I were a developer working only with Silverlight, is there any reason at all for me to get VS. Why not just get Blend? It has makes it possible to edit both Xaml and code, work with TFS as well as drag and drop support for design (missing in VS).
I’m not complaining at all, I’m just curious about Microsoft’s line here. First they are splitting the roles using specific software for specific roles, but then all of the sudden they release this software that is more or less one-size-fits-all. And as a side note I can mention that I was asked this exact question by another developer a couple of days ago. He couldn’t really figure out how he was supposed to use VS and Blend. But he decided to use Blend only, since this could do all he needed and looked better that VS 2008.
If we now set aside all the discussion about roles and software alignment and so on, is there anything that I specifically like or dislike in Blend? Well, yes there is. First off would be the UI. I find it slightly too dark and “fuzzy”. And yes, I know that you can switch theme, but the light theme is even worse. I like the dark, but it should be be a little “crisper” with a little bit more contrast. On the other hand I LOVE the UI. Since it is a WPF app, it isn’t stuck with the old “Windowsy” look. I wouldn’t mind if they actually took it a little further and made it a little less “techie” and square… But possibly the best UI feature they have is the feature that makes it possible to scale the UI. The UI is generally a little cluttered and a little too detailed in the information visible. It makes it hard to even get a decent workspace. Especially on my little 13 inch laptop with a 1280x800 resolution (yes, I could get a bigger screen, but scaling works pretty well and isn’t half as heavy as a larger screen).
What else? Well, I also LOVE the search box for the properties. It is completely invaluable. I find it really hard to find certain properties, especially since Blend has a tendency to minimize a bunch of panes, hiding a lot of the properties. One quick search and you are done. I would love that feature in more programs…
As you can see so far, I have a love/hate relationship with Blend. I guess most of my negative opinions so far has been regarding the features available in regard to the role that is supposed to use it. But I do have one thing in Blend that annoys me and that I wish that Microsoft would change in Blend 4. I even have sort of a technical solution for how I want it to work and not just complaints about how it works. It has to do with data bindings.
Blend has fantastic support for binding data. Making it as easy as possible for the user to bind more or less any property to…yes…to what…that’s my issue. My problem with Blend’s binding support has to do with the way that Blend handles the model that the view binds to.
The way to set up data binding “support” in Blend is by selecting the control and looking for the DataContext property in the “Properties” pane. When you find it, there is a “New” button. Clicking this makes it possible to set the data context of the control to an object in one of the referenced assemblies. After that, whenever you choose to bind a control’s property, you can just select the property on the data context that you want to bind to. Alternatively you can choose to bind against a “Data Field” or an “Element Property”. The actual binding dialog is great. It helps with the syntactical parts of the binding and shows you available converters and so on. In general it is great.
So why am I bitching about the binding support in Blend then. Well, my problem with this solution is that setting the DataContext property in Blend causes the following Xaml to be created
This is kind of obvious. Blend sets the DataContext to a new instance of the selected object. Which is what we normally do from code somehow. The downside to doing it in Xaml like this is that you have now removed all of that nice separation between layers that you get from MVVM. The view now know what type will the DataContext is and it has all of the sudden become a lot less flexible. How to solve this? Well, it isn’t hard. Let the “devigner” work with this, but then when he is happy, remove the 3 lines of Xaml and all of the suden the separation has been restored.
How to solve it in the long run? Well, I have a suggestion. And even though it is possible that it isn’t the best solution, it would make me a little more happy. And it would be pretty simple for Microsoft to implement…at least I think so.
Blend already uses its own namespace “http://schemas.openxmlformats.org/markup-compatibility/2006”. This namespace is used by Blend to modify certain aspects of the control while in Blend. Why not use this for the DataContext as well? Why not add support in that namespace to add a DataContext in a way that it will be removed when building the application? That way, the developer could stub out an object with design time data that the “devigner” can bind against, while not actually locking down the view to that type.
Another, more complicated solution to implement, would be to add support to set an interface that the DataContext must implement. This would give us strongly typed access to the values without coupling the view to the model as hard. I’m personally not that fond of this solution, but I would still consider it better than hard coding the DataContext in the Xaml.
But whatever I have said or written in this post, and whatever you think I think about Blend, it is still a great application and I feel sorry for anyone working with Silverlight or WPF without having access to it. Blend is an extremely valuable tool for UX developers working in the Microsoft space. So if that sounds like you, and you don’t have it on your computer, go and download a trial version and see why you need it…
And yeah…a final note…I will try to return to Blend really soon. But instead of bashing it, I want to dedicate some time to figure out a good way to get the designer-devigner-developer workflow to flow smoothly!
But this is it for now…Cheers