Silverlight Lessons Learned

Designers at least in my world are all about design, sexy, hot UI. The Developer is all about making it real and functional (mostly ugly too). Together Designer and Developers when they work together create not just the dream of vapor ware but something hot and sexy, pleasant to the eyes and smooth to the touch, soft and that is easy to work with. That’s the kind of next generation User Experience we want to build into our web applications. In the WPF world this is a much farther along than the typical web application could dream of. With WPF in Vista and on Microsoft’s new Surface computing it’s like something out of a sci-fi movie. Using Silverlight we can bring a little bit of that to the web.

I talked about in the past how Silverlight really shines in the
ability for designers and developers to come together. Part of the basis of this is for developers to know Xaml enough to work with the bits coming from the designers. For the developer that is used to just looking at code all day this is a bit of a jump but the average ASP.NET web developer might be a bit more comfortable. Like ASP.NET you have a file with your look and feel (Xaml) and a code behind (cs or js file) and like ASP.NET the look and feel ‘file’ is a bunch of tags for the most part.

So getting back to our use case we had a bunch of guys working on different bits mostly new to Silverlight. There were a few guys that really already knew their stuff and built out the underlying structure of the site. It ended up being thousands of lines of Xaml and code but the story here was the fact that they had to bind it together. Being able to look at Xaml code even if you not a designers and understand what is happening is critical to being able to wire things up so that something actually happens. But on the designer side… please, please give objects reasonable names. When your Xaml is 1000 lines long and there are no names or worse, all the names are like x1 x2 etc. it makes it harder to wire things up.

Out of our little death march to get our site done there was one incident where poor communication between designers and developers really broken down and we spun hours clean up. Basically a developer, that thought he was all that, created a class or object that was probably a bit over complicated and it didn’t follow the structure that others were using. A dev in question checked in the class into source control and went home for the night. A designer tried to use it and in his frustration couldn’t figure out how it worked and after hours of rework completely reworked it and then found out with the help of others that it wasn’t the problem with the code but something else. The next morning this almost broke out into a fight…

Lessons learned, don’t through complex code over the fence for designers to have to wire up, it’s not their job for starters but generally we can’t leave each other high and dry. (In comes the integrator role) Communication is critical and being consistent even if it is not the best way to-do things is more important than this way or that way.

Oh we also learned that margaritas at 3 am do not improve productivity… amazingly enough this is true of designers and developers.