Justin Angel (who is undoubtedly a Silverlight Rock Star) decided to stir things up a bit on Twitter the other night.
I was compelled to echo Ward Bell’s response that value converters can play legitimate role in the UI. Justin asked me to defend my position; a reasonable request. Now, I know that I am in the minority for maintaining this position. Many heavy hitters in the WPF community think MVVM does away with value converters. (I am not going to talk about the other bits here, just value converters.)
One of the early WPF examples that got my attention was a listbox that was styled to look like a map of the United States. What impressed me in this sample was the separation of Behavior from Feel. I’m using the word “feel” with a very specific meaning. We often talk about Look and Feel. I think Look is shallow and Feel is deep. You can change the look of a listbox by changing the colors, the borders, the thickness of the lines, the icon that activates the dropdown, and so on. However, even by changing all of those, it stills feels like a listbox. Now, once you’ve made that “listbox” into a map of a country you’ve done something deeper. You’ve changed the Feel. Pretty significantly too, I’d say.
But even with the radical feeling map-listbox, one thing you haven’t changed is the Behavior. The semantics of a listbox are still in effect. Show a list of items and allow one to be selected.
But alas, those primeval glories of WPF were drowned out in the drones of “where’s my datagrid?”.
Rob Eisenberg and I were early adopters of WPF. At the same time, we were also in the feverish rush of applying Design Patterns to everything. You know, that phase of adoption where you’ve learned how to hammer and everything’s a nail. Still, it was good for us. We were digging through Fowler’s and Gossman’s and Crevier’s blogs. These sources began to shape my conceptions of ViewModel (or Presentation Model or Your Mama Model), however I was still deeply influenced by my lingering notion about the separation of Behavior and Feel.
The result of this is that my idea of a ViewModel is a representation of the Behavior of the View. However, the ViewModel is agnostic about the Feel. This means I don’t build “formatting” and such into my ViewModel. I try to keep my ViewModels as “pure” and abstract as possible. This also means that I rarely take strong dependencies on WPF and Silverlight.
Why go to such extremes? What’s the benefit?
My Fantasy World
There’s a lot of talk about UX lately, and perhaps more fittinhly, Interaction Design (IxD). In reality, I fiind that there are few people are actually doing IxD. Although, I think that’s the audience that Expression Blend is targeted at (do you recall what Blend was originally named?). These chimerical Interaction Designers are the ones that would benefit the most from this proposed separation of Behavior and Feel.
Let’s imagine a we’re building a WPF application. Harkening back to that old, impressive sample of yesteryear, the behavior we need in our app is to “allow the user to select a state”. As a developer, we can create a ViewModel that embodies that behavior, we can test the ViewModel, and even build a simple, naive View (testing that the required bindings are present with Caliburn thank you). Then we can hand it over to an interaction designer. The designer can then radically alter the Feel without changing the Behavior. In fact, if we’re using something like Caliburn’s testability framework (not available in Silverlight unfortunately), these IxD peeps can exercise a great deal of liberty in establishing the most appropriate feel for the behavior.
Unfortunately, our typical approach to software development inhibits IxD’ers from working this way. The Feel is often deeply entangled in the presentation logic (or worse).
I’m sure that a large majority of WPF developers might see these distinction as useless. Especially, when building Line Of Business applications. That’s okay. Not everyone needs to do this. Many projects don’t need the additional complexity that might be introduced by thinking in this way. However, I think this is an emerging field and UX/IxD will be increasingly important. Soon it will be the distinguishing factor in commercial software.
Wait, Wasn’t This About Value Converters
Yes, and here is how they fit in. Let’s take my current favorite example of formatting dates. We have a behavior that requires communicating some date/time information to the user. Applying my philosophy to our ViewModel, the developer should expose the raw data (an actual DateTime property) on the ViewModel and leave the rest up to the IxD’er. After careful consideration, research and usability testing, the designer decides the dates need to be formatted as “[x time ago]”. (See the referenced post if that doesn’t make sense.) The designer, who can likely write a bit of code, creates a value converter to format the date value as the Feel demands.
Secondly, we could conceivably have multiple Views in an application for a single ViewModel. Each View would have a different Feel, and the application (or the user) could select the most appropriate (or comfortable one).
Incidentally, when I first learned about MVC it was in the context of writing a minesweeper game in Flash where the user could switch between an isometric and top-down view.
In the End
In real life, we’re not very close to this. There are few IxD’ers out there and most teams don’t need to be concerned about this. That means that for most practical purposes the Simplest Thing to Do might be to forego value converters and hard code formatting in the ViewModel. Value converters, just like anything else, can be abused.
Nevertheless, I definitely do not consider them a worse practice.
If you think I’m wrong, speak up. I am willing to listen. If you’ve been burned by the use of value converters, please share.
10-01-2009 1:17 AM