At my talk at TechDays 09 here in Sweden, I was followed on stage by two guys from RTC Factory. They were there to talk about the workflow between the developer and designer. One of the big upsides to Xaml and Silverlight/WPF is that we can split the design and coding between the developer and the designer. No more mock-ups from the designer that the developer needs to implement. In the world of Xaml, the developer creates the functionality and the designer the design. Like it should be. We are all specialized within our area, which is natural. And hence it is also natural to split the responsibilities. So how does this work?
Well, the RTC Factory guys did it like you would expect it. The developer sits down and codes up the functionality and creates an “ugly” interface that works. He then saves the Xaml and tells the designer to take over. The designer takes the ugly interface into Blend and makes it beautiful. And then you are done. Well…it didn’t actually happen exactly like that, at least not in their demo. The developer already had most of the functionality in business objects, but what happened in their presentation was that he created the controls in Visual Studio (they did WPF so VS actually had drag and drop support), then handed it to the designer who took it into Blend and named the controls, gave them better looks and then saved it. It then returned to the developer who added databindings and eventhandlers to the buttons they were working with. He then added the functionality and the result was tested.
I do see a couple of things in this workflow that I would probably want to change. I’m not saying that I am better at this than they are, and I certainly have less experience of this workflow than they do, but I still have some thoughts so bear with me.
First of all I think there might be a lot of situations when the designer actually starts building the UI while the developer creates the business objects and backed parts. In that case I do think the team should sit down and agree on what type of main controls should be used. Unless the designer is in fact a so called devigner, the developer probably has better input on the choice of controls than the designer. So he/she should be involved. Hmmm…I just have to mention this….I HATE the word devigner…there is nothing devine about that person even though it sounds like it when you pronounce it…and also, from now on I will call them both “he”…the likelyhood of one of them being a female is unfortunately small, so it’s easier to write “he” than “he/she”. Anyhow… In the case that the designer starts with the layout first, the names of the controls should also be set by the designer. Why not, he is in there working with them and probably want to have them named in the Blend GUI anyway.
The biggest problem with the previous situation is that it screws up the databinding. I really want the designer to set the databindings. Blend can do that for you. There is great tool support for doing it, so I really want it to be done in Blend. It is actually better than doing it manually in VS since it is more error prone doing it by hand. (I don’t work with WPF, so I don’t know how it works there, but in Silverlight development there is no intellisense for databindings…) So if the workflow starts at the designer, the model/viewmodel interface has to be set and implemented in an object before being able to set the bindings from Blend in a good way. The model could be an empty mockup, as long as it has the right interface. If the interface of the model hasn’t been set, the workflow will have to flow back to the designer again as soon as that part is done. If the designer is a devigner and tusted by the team, he could of course make up the interface himself along the way so that it fits the design. In that case the developer will just have to implement the interface in the future.
The other way that the workflow starts, would be at the developer end. The developer creates all the backend objects, a model/viewmodel and an ugly interface that fits the purpose. So all the functionality is created befor the layout is taken care of. This can be useful since the customer can see and test the application before a lot of time is spent on the design. The functionality must be done before testing the app, so doing it before the design means potentially saving a lot of time. If the customer wants to change the functionality due to something, there is no need to make it nice just to redo it all. YAGNI…You Aint Gonna Need It… But if the designer has time left over or the design and functionality has been set, I guess there is no need to wait.
But what about this tooling support in Blend. I was really hoping that the RTC guys would have shown the designer doing the databinding as well. Why? Well, I hadn’t really firgured out how they expect us to do it. I initially tried it by going to the property I wanted to databind and clicking the little gray/white spot next to it. Then I went to “Data Field” and created a new CLR object. This makes it possible to databind it nicely. Unfortunately it adds a new CLR object to the resources, which felt very ugly for several reasons… It was possible to change the resource at runtime, but it felt REALLY off. But there is another way, which is a bit more “correct” but feels allmost as off the mark as the previous.
In Blend, open the control you’re working with. Then find the DataContext property in the property pane (the search functionality they added in there is great!). Then click “New” to select the type you intend to use as DataContext. When doing this, you get this nice interface where you can choose what type of DataContext you want. You get every single type available in your project, as well as system assemblies if you want to. You then just select the model/viewmodel you are going to use. Once again, this means that the model must have been implemented. Or at least the interface fthe class must be in place. Unfortunately it isn’t possible to set the DataContext to an interface. Why? Well…this isn’t just to get Blend to help me. Setting the DataContext like this, actually creates a new object in the Xaml that is set as DataContext. That’s just great! That means that the system will automatically create a brand new object of that type when the control is created, just so that we can overwrite that property with the “real” DataContext object.
I would really like to have been able to set the type of the DataContext, just so that Blend knows it and can give me tooling support. I would even like to be able to set it to an interface in case we don’t have a real class. Blend is already using things that are Blend specific and should be ignored…why in the world can’t we get that functionality when it comes to this. Or it could even be that we don’t set the DataContext at all, but make it possible from the DataBinding window to choose an object manually everytime and then work on that object properties just so that the designer gets some help.
There are of course a couple of things that will end up between the chairs. What comes to my mind first of all would be the converters. A lot of times we want to convert data types during the databinding. These converters are defenitely the developers job to create. A lot of them can probably be created inside a library that can be reused in different projects, but some of them will definitely be project specific. So those specific ones will have to be built, and I guess that a lot of these will actually come up along the way. But converters are generally not that complex to build. Still this point will have to be solved to get a good workflow.
Well…anyhow…that was my two cents. I am not that experienced in this at all, but this is how I imagine Microsoft thinking when they created the tools. And I guess that thought is somewhat supported by the fact that Blend 3 will (what I hear at least) support checking in and out files in the TFS. A feature that will make this a whole lot smoother. Sending MSN messages or e-mails to tell the developer/designer to take over is too much of an hassle. But as I mentioned, this is something that I’ve only heard mentioned briefly and I haven’t tested it at all. Unfortunately I haven’t been able to touch Blend 3 at all. But I would guess that we might hear a bit more about it REALLY soon, considering that there is a big conference for webdevelopers in the US the next couple of days. Sounds like a good place to drop some new products and betas.