“Implementing MVVM in Silverlight” – a UI perspective

During the course of our current project we have been through a few iterations of our development process, with one goal being to find the best way for us Designers to work in Expression Blend on data driven controls.  There has been a bit of pain involved along the way and we’re yet to find an ideal solution.  As a result, I’ve been interested in the discussion taking place on blogs and Twitter on the subject of ‘Blendability’ and the proposal of the Model-View-ViewModel pattern as a route to this goal.

This post began as a review of a great video from Tim Heuer and Craig Shoemaker on the title’s subject of Implementing Model-View-View Model in Silverlight.  On the whole it’s a great hands-on example of how to implement a simple Silverlight project following the MVVM pattern. I recommend checking it out - not least because the rest of this article will make more sense, but it’s also a great overview of some neat and efficient data binding techniques.  However, it was the process followed which made me take particular notice, and a couple of quotes which prompted me to write this article.

“Your Model would have to be pretty well defined for a designer to even
start working on the View.  How am I even going to know what elements to layout without that?”

“A developer can make it functional and someone else can go off and make it look pretty”

I’d like to say that this isn’t a criticism, and maybe an unfair quote to pick on - particularly as Tim stated he was thinking out loud, and still getting his own head around how this pattern could best be used. It’s more an observation of a common view of the designer-developer relationship, and where the lines are drawn in their workflow.

The process given as example in the video is in conflict with the UI led development practice I’m familiar with. From the first sketches on a whiteboard, through wireframes and into Photoshop mock-ups; the essence of our application is derived from the Interface, and the detail designed in collaboration with the development team.

Having the Model predefine the View, as in the video, also seems at odds with the ultimate aims of Silverlight as an RIA platform.  If all I wanted to do was expose some data, I could simply achieve this via data driven HTML. Certainly 9 months ago, when we were looking into Silverlight for our new project (just now approaching its first release); if our main focus was just in providing a view on information in the database, just using .NET and HTML would have saved us the steep learning curve and occasional pain of developing in an evolving Beta platform.

This is perhaps the key area we need to address in Silverlight development; facilitating user-centred design.

If I, as a designer, am provided with a set of XAML objects, be they pages in the traditional sense, a user control element or custom control template – I am only going to be able to work with what is there, and have little idea of what the alternative possibilities might be.

Whereas the RIA user experience should start with just that; the user’s interface with the application – what do they want to do, how best for them to achieve their goal, what data do they want and need to see in order to aid them on their way?

I’ll be looking more into MVVM in any case, I’m interested to see if it can help us achieve the smooth workflow we need to be more consistently productive. Hopefully a View-led process can help us acheive our goal.

Fortunately there’s some good reading and viewing available, and more appearing as the discussion continues…

• Hands-On Model-View-ViewModel (MVVM) for Silverlight and WPF
• Model-View-ViewModel In Silverlight 2 Apps
• Should I use the Model-View-ViewModel (MVVM) pattern in Silverlight projects?
• MVVM pattern in Silverlight using SLEextensions