Christopher Bennage : UI

d:DesignInstance in Blend 4

Christopher Bennage — Mon, 29 Mar 2010 20:12:00 GMT

Let’s walk through an example of using d:DesignInstance for improving the design-time experience in Blend. For background, see my last post on the topic.

I’m going to be using the ContactManager sample from the Caliburn trunk. You can access the source of it here under: \trunk\samples\LOB Samples\Silverlight\ContactManager\

We’re only going to concern ourselves with one view/viewmodel pair:

ContactListView
ContactListPresenter

(This sample code still uses Caliburn’s old naming scheme that was influenced by the MVP pattern. “Presenter” here means “View Model” for all practical purposes.)

ContactListView displays a list of contacts in an ItemsControl on left side of the view. As you can see, there isn’t much visible in Blend.

On the corresponding viewmodel, we have a property named Contacts that we’ll bind to the ItemsControl.

(Note that Caliburn is binding to this property using naming conventions, but we’ll need to add an explicit binding in order to play nice with Blend.)

Here’s what my ItemsControl looks like:

<ItemsControl x:Name="Contacts" 
              ItemsSource="{Binding Contacts}">
<!-- omitted for brevity -->
</ItemsControl>

Let’s select the ItemsControl in Blend and examine the data binding for the ItemsSource.

It’s a sad, empty little dialogue that greets us.

Getting the Shape of Our Data Context

Let’s open up the XAML for ContactListView. In the root element, we’ll set the design-time data context using the d:DesignInstance markup extension. It looks like this:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Controls="clr-namespace:Caliburn.Silverlight.ApplicationFramework.Controls;assembly=Caliburn.Silverlight.ApplicationFramework"
             xmlns:rm="clr-namespace:Caliburn.PresentationFramework.RoutedMessaging;assembly=Caliburn.PresentationFramework"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             mc:Ignorable="d" x:Class="ContactManager.Views.ContactListView"
             xmlns:local="clr-namespace:ContactManager.Presenters"             
             Height="400"
             Width="750"
             d:DataContext="{d:DesignInstance local:ContactListPresenter}"
             rm:Message.Attach="[Event Loaded] = [Action LoadContacts]">

<!-- omitted for brevity -->
</UserControl>

Wow, that’s a lot of namespaces. We’re only concerned with two lines though. The first one is

    xmlns:local="clr-namespace:ContactManager.Presenters"

This also use to reference our local type in XAML.

The second is

    d:DataContext="{d:DesignInstance local:ContactListPresenter}"

This tells Blend that we want to use the ContactListPresenter for our design-time data context. However, this doesn’t create an instance of the type and we won’t see any data appear in Blend. Instead, this tells Blend what the “shape” of our data context is. In other words, Blend uses reflection to learn about the properties so that it can show us a lot more in the data binding editor.

Let’s open that up again.

Much less depressing. This also means that when I drill down and edit the ItemTemplate, Blend is aware of the data context and I get support for bindings there as well. Booya.

Getting Some Sample Data

I said earlier that d:DesignInstance does not create an instance of the specified type. You can make it create an instance though by setting the IsDesignTimeCreatable property to true. Now, we don’t want to do this with ContactListPresenter because it has a couple of dependencies injected into it’s constructor. So in order to provide a little sample data for the designer, I’ve created a new class to use as my design-time viewmodel:

public class SampleContactListPresenter
{
    public List<Contact> Contacts {get;set;}    
    
    public SampleContactListPresenter()
    {
        Contacts = new List<Contact>
        {
            new Contact{ FirstName="Ford", LastName="Prefect"},
            new Contact{ FirstName="Author", LastName="Dent"},
        };
    }
    
}

I could have derived this from ContactListPresenter, but that would have been a lot of unnecessary work. A better choice would be for my design-time viewmodel and my real viewmodel to implement a common interface. That would help them maintain the same shape. (An even better choice would be to use d:DesignData, but that’s another post).

In this case, I decided to keep it really simple.

After adding this class, I need to change the line in my XAML that creates the design-time data context to this:

d:DataContext="{d:DesignInstance local:SampleContactListPresenter, IsDesignTimeCreatable=True}"

and now I can see some sample data in Blend:

N.B. I discovered after I worked through this that the ContactListPresenter in the trunk doesn’t get along well with d:DesignInstance. I haven’t isolated the exact problem yet, but you’ll need to modify the class if you want to follow along with this tutorial. Change the class so that it is only inheriting from ScreenConductor<IContactDetailsPresenter>:

public class ContactListPresenter : ScreenConductor<IContactDetailsPresenter>, IContactListPresenter

Exploring Design-Time Data in Blend 4

Christopher Bennage — Fri, 26 Mar 2010 20:26:00 GMT

I’ve gleaned most of what I have learned about this topic from Unni, Karl, and Jack. I recommend checking out their posts for additional information.

d:DataContext

The d:DataContext attribute allows you to establish a data context that is only for design time. You can use it the same way (more or less) that you use the real DataContext. Two options are available for providing data for the design-time data context. They are the markup extensions d:DesignInstance and d:DesignData.

{d:DesignInstance}

This new markup extension has three properties:

Type	The type of the instance that we would like to use for design-time data context. This is the default property, so you can omit it and just provide the type value.
IsDesignTimeCreatable	True: create an instance of the type and use it for the design-time data. False: reflect over the type so that the data binding expression builder is aware of the members.
CreateList	Do we want a list of instances or a single instance?

This is mostly for giving you the shape of the data that you are binding to. Though you will see the actual property values at design-time, so you can create a new type with the same shape as your real viewmodel, but with data to use for design-time (perhaps by interface, perhaps by subclassing). This approach can be tedious though, especially in cases where you need lists in design-time data.

{d:DesignData}

This markup extension has a single property, Source, that points to a xaml file describing the design-time data. The best way to create this xaml file is using Blend. Blend can automatically generate Lorem Ipsum for your viewmodels (which is kinda cool). I’ll show you how to do that in a follow-up post.

N.B. While everything works brilliantly in Blend, I wasn’t able to get d:DesignData to work for Silverlight in Cider (Visual Studio 2010), it complained about the leading forward slash (/) but still didn’t work when I removed it. However, removing the forward slash broke it for Blend.

A Quick Example

<UserControl x:Class="DesignTimeTest.MyView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             mc:Ignorable="d"
             xmlns:local="clr-namespace:DesignTimeTest"
             d:DesignHeight="300"
             d:DesignWidth="400"
             d:DataContext="{d:DesignInstance local:MyViewModel, IsDesignTimeCreatable=True}" />

More on d:DesignInstance

Things I’d Like To Present

Christopher Bennage — Fri, 08 Jan 2010 11:32:00 GMT

In case you are not familiar with MIX, it is a conference from Microsoft focusing on the collaboration of design and development. Admittedly, the sessions tend to favor the developer, but there is always excellent design and UX content.

There was an open call for presentations this year and the community gets to choose which of the proposals will be selected. There are a number of excellent proposals and I encourage you to go check out the list and vote for the sessions that you are genuinely interested in. (Even if you won’t be attending, the sessions will be broadcast.)

Here are some sessions that I proposed for MIX10:

Cross Compiling Games for Silverlight & XNA

Our friend and Silverlight MVP, Bill Reiss, has created an incredible library that enables you to cross compile XNA games for Silverlight. The library is called SilverSprite and we feature it on Silver Arcade. (Wow, that’s a lot of ‘silvers’ in one paragraph.)

In this session, we’d write a simple game for XNA (discussing some of the basic of game dev along the way) and then port the game over to Silverlight.

This is an area where I wish I could spend more time. I love game development, but it’s always taking a back burner to other projects.
[vote for this]

LinqToSQL and EntityFramework Profilers: Case Study

If you aren’t already familiar with the UberProf suite of ORM profilers, you can read tales of the development on Ayende’s blog. Rob and I built the UI side of the application, and we learned a lot in the process. I’d like to do a talk were we discuss the challenges of the project, how we solved them, and what we did wrong.

Yes, NHProf will be included too. (I submitted a case study for it last year, and it didn’t get picked. I have to sneak it in).

A few interesting aspects:

we built this using MVVM, but well before Caliburn reached maturity.
the four separate apps (NHProf, EFProf, L2SProf, HProf) all use a single code base.
we’re about to port the project from WPF to Silverlight.

[vote for this]

Silver Arcade: Case Study

This is a presentation that Rob and I have made a couple of times. Most recently at the Orlando .NET Users Group. We walk through the actual code for Silver Arcade explaining the philosophy, design choices and mistakes we made along the way.

For MIX, we would focus more design and UX choices, such as the separation of the behaviors from the views. However, we like to have a lot of audience interaction and tend to follow where ever the questions led (especially those leading questions that Scott Densmore tends to ask).

Silver Arcade is also interesting because we deliberately used a number of newer hipper technologies; including Azure, ASP.NET MVC, jQuery, MEF, NHibernate and so on.
[vote for this]

Thanks!

Comparing Resource Dictionaries in Unit Tests

Christopher Bennage — Tue, 22 Dec 2009 16:37:00 GMT

Working on the ÜberProf has presented some interesting scenarios. As you might have picked up from Ayende’s blog, the vast majority of the source is shared between all the products. This is especially true in the UI layer.

Now, Ayende wanted to have a distinct color scheme for each application. That by itself wasn’t a big deal, switching out resource dictionary is well documented and very straight forward. The architecture we choose resulted in a resource dictionary for each application with a set of identical keys. Additionally, and because of our design choices, we have to reference everything using DynamicResource. I was concerned about the possibility of omitting a key from one of the dictionaries and consequently breaking the UI. (I know that some people feel the UI is already broken. Don’t be a hater. It will get better.)

I decided to write a test to compare the dictionaries and check for omitted keys. I designated the NHProf dictionary as the “master”. It is the standard that the others are compared against.

Here’s what one of the actual test looks like:

public class EnsureColorsAndBrushesAreConsistentFor
{
    [Fact]
    public void LinqToSql()
    {
        var master = GetMasterListOfKeys();

        var linq2sql = new Client.Resources.LinqToSql.ColorsAndBrushes();
        linq2sql.InitializeComponent();

        var missing = from resource in master
                      where !linq2sql.Contains(resource)
                      select resource;

        Assert.True(
            missing.Count() == 0,
            MissingMessage("LinqToSql", missing));
    }

    private static IEnumerable<object> keys;

    private static IEnumerable<object> GetMasterListOfKeys()
    {
        if (keys == null)
        {
            var master = new ColorsAndBrushes();
            master.InitializeComponent();
            keys = master.Keys.Cast<object>();
        }
        return keys;
    }

    private static string MissingMessage(string dictionaryName, IEnumerable<object> missing)
    {
        return missing.Aggregate(
            string.Format("ColorsAndBrushes.xaml for {0} is missing the following: ", dictionaryName),
            (seed, key) => seed + "\n" + key);
    }
}

In order for this to work, I had to turn each of the resource dictionaries into a class. This is very easy to do, you only need to add the x:Class attribute to the root.

<ResourceDictionary x:Class="HibernatingRhinos.Profiler.Client.Resources.LinqToSql.ColorsAndBrushes"
                    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

There are similar tests for each of the applications.

Are Value Converters Evil?

Christopher Bennage — Thu, 01 Oct 2009 05:17:00 GMT

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?”.

Seeking Abstractions

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).

Context

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.

Designer Wanted

Christopher Bennage — Tue, 22 Sep 2009 16:30:25 GMT

We need to contract a designer for our current project. I’m looking for one of those mythical beasts that has:

some real graphics design skill
understands (or at least cares about) usability
works with Silverlight

There is also a strong preference for someone in the NYC/NJ area.

If you are interested or know someone who qualifies, please contact me through the blog.

Answer the User’s Questions

Christopher Bennage — Sat, 22 Aug 2009 16:27:00 GMT

One little usability bit that I picked up from many of the Web 2.0 apps (in particular 37signals apps), is displaying date and times in a “how long since” format.

Take a look at the community page on Silver Arcade. I wanted to display when a user became a member of the community. Instead of displaying the actual date that they signed up, I choose to convert that date to “how long ago”.

At first I did this just because I liked it. Then it began to dawn on me that there are reasons that I like it.

Questions

One primary purpose of any UI is answering the user’s questions. “How much credit is left in this account?” “Is this customer currently active?” “How many days are left before this explodes?”

Frequently, when we are displaying dates and times we are really trying to answer questions that begin with “how long ago did …” or “how soon until …”.

When we display a simple date and time, such as “August 22, 2009 12:11 PM”, we are providing raw data to the user, but we really aren’t answering their question. We’re leaving the final step up to them. That’s translating that raw data into a meaningful answer for their ‘how long’ question. Every translation has a cognitive cost.

This may not seem like much, but the cognitive cost adds up very quickly. This can be one of those subtle points that makes two seemingly similar interfaces feel so different.

I’m not saying to display every date and time in your application in this format. Instead I am saying to ask “what question will my users have and am I really answering it”.

To be fair, this is purely anecdotal and is not backed up with any empirical evidence.

One day with Balsamiq Mockups: a review

Christopher Bennage — Fri, 19 Jun 2009 04:03:00 GMT

We’ve just started a new Silverlight project and since ~~our~~ the UI guy is not on site with us, I ended up with the task of producing screen mockups. Some interest was expressed in using Balsamiq Mockups, and this seemed like a good time to really take it for a test drive.

What does it do?

Balsamiq is a tool for quickly authoring mockups of applications and websites. My favorite tool for doing mockups is pencil and paper (turns out that it’s really, really good). However, we needed something that we could readily show during a review meeting and my sketches don’t photocopy well.

Nevertheless, I did my brainstorming on paper and I used it for my first round of reviews with the team. This left me with about a dozen pages storyboarding the core of our application.

After the first review, I began recreate it with Balsamiq.

In Balsamiq you start with a blank, gridded canvas and drag various UI elements from a library onto the canvas. It reminds me of Visio a bit, but without so much pain. All of the elements are styled to look like hand-drawn. This is important because it prevents anyone from assuming that the application is “done” when you’re just presenting mockups.

The elements in Balsamiq are impressively intelligent. Most elements allow you to type in some content and they react intuitively to that content. I was amazed a couple of time at how smartly they responded. Balsamiq ships with about 75 elements in its library and there are more being posted all the time. You cannot really extend the library yourself however, though you can incorporate your own images.

Each mockup screen is a single file. They are XML so it’s source control friendly. If you are mocking up an entire application (like I was) you can link the files together. Many of the elements have a link property that you can point to any other Balsamiq files in the same directory. Once you’ve linked up some files, you can “run” your mockups in presentation mode. This allows you to navigate around the application and toggle annotations (like the sticky note in my screen shot). The presentation mode is really cool.

Should you buy it?

I think that mocking up the UI is a very useful exercise. It helps to expose the behavior of the application that you are going to build and surfaces many insights into what it really needs to do. I still prefer to use paper and pencil for the initial pass. However, I found that following this up with Balsamiq forced me to think through the entire flow of my appplication. My paper storyboards had holes in them that I did not realize until I attempted to express them in Balsamiq.

The reviewers were really excited to see the Balsamiq mockups and being able to walk them through the application was a definite plus for them. The tool is easy to use. I would say that any ~~designer~~ developer doing UI work should be using a tool like Balsamiq.

What it offers for $79 is really hard to beat. Admittedly, I don’t know what other tools are out there and how they compare. By itself, I think it definitely worth it for anyone doing UI work.

Of course, there is SketchFlow. It is coming. I think that SketchFlow looks very promising, especially for us XAML guys, but it’s not available yet. I’ll let you know what I think about the overlap once I get a change to actually use SketchFlow.

Little Things

I had a couple of annoyances that are worth pointing out.

First, you cannot create reusable components. For example, I had certain elements of the application that appeared in several places. I had to clone these elements, but when I needed to change them, I had to make the change in each element. (Another reason to start with pencil).

I think that it would also be nice if there was a “back button” in presentation mode. Within my mockup I had a few screens that you could get too in multiple ways, however I did not have an easy way of returning the the previous screen.

I also get the impression that the community around Balsamiq likes to poke fun at us PC guys. I smile politely.

Finally, Balsamiq likes to keep all of the linked files open. You’ll notice an excessive number of tabs on the bottom of the screen shot. Those are all the screens within the application I was mocking. It became a little difficult to find that right one.

On the whole, Balsamiq is a smart application and I expect to see great things as it matures. Many of its features are intuitive and “just work”, and that’s how I like my software to roll.

:-P

Displaying Today’s Date with XAML

Christopher Bennage — Fri, 13 Mar 2009 22:06:11 GMT

This one is easy on the brain. Some quick WPF lovin’ 101.

I need to display the current date, and have it formatted like this:

Friday, March 13, 2009

In my opinion, this is purely a matter for the view and so I’m handling it entirely in the xaml. Here’s the markup:

<TextBlock Text="{Binding Source={x:Static sys:DateTime.Today},
           StringFormat='{}{0:dddd, MMMM dd, yyyy}'}"/>

And now for a quick analysis.

I wanted to use the builtin DateTime structure, because there is no need for me to expose the current time through my presentation/view model. In my root element, I create a namespace alias:

xmlns:sys="clr-namespace:System;assembly=mscorlib"

This allows me to reference DateTime in the markup. Since DateTime has a static property, I can get at it using StaticExtension. So far, that explains {x:Static sys:DateTime.Today}. I’m working from the inside out.

Inside the binding, I need to set the Source property because otherwise the binding is looking to the DataContext. We don’t care about the context, we just want to directly access the value of DateTime.Today.

Finally, we have StringFormat. It’s a tasty little bit that was introduced in 3.5sp1. You can pass it any of your standard formatting strings and it just works. Let’s say that I want to display this:

Today is Friday March 13.

I could used:

<TextBlock Text="{Binding Source={x:Static sys:DateTime.Today},
           StringFormat=Today is {0:dddd, MMMM dd}}"/>

Notice that my quotes from the first example were omitted. They are actually optional. I like to include them though for readability.

You might also have notice in the first example an extra set of angle brackets. If your formatting string starts off with an angle bracket, the Xaml parser gets confused. It thinks that it’s encountering another markup extension. We have to use an escape sequence and in Xaml it’s {}.

Once final note, DateTime doesn’t raise any change notification. So don’t expect the view to be update as the time changes.

Testing Bindings In WPF

Christopher Bennage — Fri, 20 Feb 2009 03:56:00 GMT

I was inspired to get off my duff and blog today by a tweet from Scott Hanselman. I didn’t really dig into the context of his tweet, but it was about TDD and WPF. In case you haven’t figured it out, I’m a big fan of WPF and TDD. Luckily, I’ve had the opportunity to work on a number of varied WPF projects (most using TDD) over the last couple of years. One problem I experienced over and over was incorrect bindings in my Xaml (as I alluded to in this post). Binding errors are silent. They sneak up on you ninja-like. If you are keeping an eye on your Output window you can catch them, but it is very easy for them to just slip by.

About two years ago, Rob and I were working on a student records application for the FSU College of Music. The system handled the entire lifecycle of a student, from application to graduation, and that involved lots of data. We had a number of screens in the app that were merely large data entry screens. Binding errors where a problem, and it seemed like a new batch showed up every time we made a release to the users.

The errors might have been the result of renaming a bound property, bad spelling, or some other such silliness. They were easy mistakes to make and thus I began to think that we really needed a way to automatically test them.

Well, I’m lazy and time passed (maybe a year) and then I mentioned it again to Rob. The next day he committed a prototype to the Caliburn trunk. (He’s like my own personal Ayende.)

Here’s an example test copied directly from Caliburn’s documentation:

public class TestBase
{
    static TestBase()
    {
        var app = new MyApplication();
        app.InitializeComponent();
    }
}

[TestFixture]
public class TestCase : TestBase
{
    [Test]
    public void Test()
    {
        var validator = Validator.For<MyUserControl, MyModel>();
        var result = validator.Validate();

        Assert.That(result.HasErrors, Is.False, result.ErrorSummary);
    }
}

In TestBase, we initialize the actual application so that we have access to application level resources. We need to this in a static constructor because we don’t want more than one instance of the application in the AppDomain.

Now, check out the Test() method. The static class Validator.For<T,K>() method returns an instance of BindingValidator<K>. The type T is some FrameworkElement that contains the bindings we’re interested in and K is the type that the FrameworkElement is bound to. Calling the Validate() method causes Caliburn to instantiate T, crawl it’s tree, and collect all the bindings. It then compares those bindings to the type K to see if they are valid. Validate() actually returns an instance of ValidationResult<K>, which is a summary of everything that Caliburn found while comparing the bindings against the actual type T.

The assertion in the test means that we expect Caliburn to find no errors, and if it does to provide us the summary. This is useful because there might be a number of binding errors and the ErrorSummary will give us the whole list.

At this point, I’m just repeat what’s stated in Caliburn’s documentation. NH Prof was the first project where we’ve actually used the Testability features of Caliburn. Let’s check out a real live test from it:

[TestFixture]
public class MessageBoxViewTextFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<MessagePresenter> bindings;

    public MessageBoxViewTextFixture()
    {
        bindings = Validator.For<MessageBoxView, MessagePresenter>()
            .Validate();
    }

    [Test]
    public void BindingsDoNotHaveErrors()
    {
        Assert.That(bindings.HasErrors, Is.False, bindings.ErrorSummary);
    }

    [Test]
    public void MessageIsBound()
    {
        Assert.That(bindings.WasBoundTo(x => x.Message));
    }
}

This test is for the view that displays a simple popup message. We have a simple presenter that backs the view and it has a message to display in its property Message. It’s tested independent of the view. (This is nice because we have a case in NH Prof where a single presenter might be bound to multiple views.)

The ViewTestFixtureBase is identical to TestBase from the example above. Since it’s expensive to have Caliburn instantiate and crawl the UI validating the bindings, we only want to do this once. (I’m not really sure why I used the constructor, instead of [TestFixtureSetUp], but I did.)

The first test covers 90% of what you typically need, catching spelling errors, etc. The second test however explicitly checks to see if we are bound to the Message property on the presenter. This is useful because that’s the core reason for this view. There may be other properties bound, but this is the one we definitely care about. (I think this affords liberty to designers while ensuring that a view delivers the business value that was intended.)

Now, let’s pretend that I have a bad binding in my markup. Here’s the core snippet for the view used in the test above, MessageBoxView:

<Grid MaxWidth="260">
    <StackPanel>
        <TextBlock Foreground="{StaticResource Text}" 
                   FontSize="14"
                   TextWrapping="Wrap"
                   Text="{Binding Messyage}" />
        <Button Content="OK"
                Margin="4 8 4 4"
                HorizontalAlignment="Center"
                IsCancel="True" />
    </StackPanel>    
</Grid>

Oops, I misspelled Message in the binding! When I execute my tests, they both fail. The first because there is a binding error and the second because it can’t find Message. Here’s the actual exception from the first test:

NUnit.Framework.AssertionException: [MessageBoxView.Grid.StackPanel.TextBlock] The property 'Messyage' was not found on 'MessagePresenter'.
Expected: False
But was: True

Notice that it actually gives you the path to the offending binding: MessageBoxView.Grid.StackPanel.TextBlock. Now that’s just cool! Thanks Rob!

I can’t explain how much pain it saves to be able to do this. If you are doing TDD with WPF, you really need to check this out.

I’ll post over the weekend some tests that are a bit more BDD in their styles.

Garbled Text in WPF

Christopher Bennage — Mon, 16 Feb 2009 21:41:18 GMT

We've had a number of rendering issues with NH Prof. I've been embarrassed about how frequently I have asked users to update their video drivers. It’s not surprising to encounter driver issues occasionally with WPF. It is built on top of DirectX you know. (In fact, all my WPF apps break horribly when I enable SLI mode.) However, too many people were reporting problems with NH Prof, and that led us to think that something else was going on.

During a shared coding session using Microsoft’s SharedView we noticed some of the graphical glitches that users were complaining about. This was important because we had not been able to reproduce any of these problems previously. Discovering this, I was able to create a sample application to help me isolate the problem. The symptom is garbled text. It’s interesting to point out that the text is only garbled when the window containing the text is over certain elements in other applications. Usually the culprit elements were the chrome bits of another window or control. Moving the offending window with garbled text would result in an effect that looked as if the text was transparent… Hmm…

Here is the Xaml sufficient to reproduce the issue:

<Window x:Class="GarbledTextTest.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Garbled Text Test"
        AllowsTransparency="True"
        WindowStyle="None"
        Height="300"
        Width="300">
    <Grid MouseLeftButtonDown="Grid_MouseLeftButtonDown"
          Background="Black">
        <TextBlock Text="Help me!"
                   FontSize="32"
                   Foreground="#cfff" />
    </Grid>
</Window>

(By the way, the event handler in the Xaml is just for me to drag the window around.)

But remember, I said that the developers were not experiencing the problem, so what else gives? I also mentioned that we noticed this while using SharedView. In fact, we fixed it in NH Prof during that same session. Something was special about SharedView. I recalled that SharedView used to tell me that it was disabling Aero when I started it (It doesn’t always do so, but I didn’t bother to find out why.) So I just disabled it myself by changing my theme back to Windows Classic.

Okay, so…

What does all this add up to? It seems that three different things stacked up to cause the rendering bug.

The first bit of wonkiness is the AllowTransparency property on the Window element. If I set this property to false, the problem goes away. This wasn’t really an option for NH Prof as we preferred the custom chrome and need the transparency.

Second, the brush used for the text had partial opacity. It might not jump out at you, but the value #cfff translates to white with 80% opacity. If I make the brush 100% opaque, the problem goes away. That’s actually how we fixed it.

Of course, the third way was the doozy, and I can only qualify it as an Unhappy Rendering Environment. It might be an out of date driver, a remote desktop, your pretty Vista theme being disabled, or a picture of an angry monkey.

By the way, if you find any more of these glitches in NH Prof, please post about it in the forums. Also, there are other issues around rendering that are not related to this.

UX Patterns (and not UI Architecture Patterns)

Christopher Bennage — Thu, 05 Feb 2009 19:19:00 GMT

Just when you think that you finally have an accurate label to describe something, you discover the true ambiguity of the term.

What is UX?

UX means User Experience. You might say that it is the ergonomics of an user interface, or possibly the level of intuitiveness. More plainly, good UX means that the users of the software are able to quickly understand how to use and don’t have to go out of their way to make things happen. This blurs a little bit into the concept Usability. But UX just sounds so much sexier, and there is this aspect of producing chemistry between the user and software that transcends mere Usability.

Why do I bring this up? Well, I’ve just started talking about UI Architecture patterns and I wanted to make sure the concepts were distinct. When I talk about UI architecture patterns I’m talking about the structure of the code that underlies a user interface. It’s all non-visual stuff. On the other hand, UX patterns deal with the rendered view that is presented to the user.

Infragistics just recently published a very cool (and Silverlight-based) catalog of UX Patterns called Quince.

You might be inclined to say, “Well, that’s nice for designers, but…”. Please don’t, this is really a useful for tool for anyone building user interfaces, even if those interfaces are basic and handed off to a design team. In the very least, this will help establish a common vocabulary for talking about user interfaces.

More Resources

If you are interested in know more about UX and usability, here’s a couple of resources:

Jakob Nielsen – very well know and full of good info, but he is definitely plain usability with none of the sizzle.

Don’t Make Me Think – one of the first books I read on the subject. (I probably need to reread it, it’s been so long…)