Christopher Bennage

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

The Influence of MVC on my WPF

Christopher Bennage — Wed, 06 May 2009 19:48:01 GMT

I was introduced to MVC as a pattern for Web development through Castle MonoRail. From there I studied a bit of Ruby on Rails (not enough) as well as the general philosophy of 37signals.

As I mentioned before, I thought I was moving away from Web development. However, the dive into ASP.NET MVC that Silver Arcade brought about has roped me back in.

My work during the day (and some nights too) is still WPF though. I’ve discovered that MVC thinking has seeped into my WPF development.

Convention Over Configuration

A characteristic of most MVC frameworks is Convention Over Configuration. In short, it means that your “environment” makes assumptions about what you want and that you only need to be explicit about the exceptions.

A practical example of this is the way that the View for an Action is inferred from the name of the Controller and Action. After creating your Action, you create a folder for the controller and and view that matches the name of the action. It just works. If you need to make exception, you can.

An Example in WPF

In our WPF development we employ a number of Separated Presentation patterns. One of the more common patterns we use is MVP (in particular, the flavor of MVP implemented in Caliburn, which is really Supervising Controller).

Imagine a simple contact manager application. We can add new contacts, view a list of all contacts, and open individual contacts for viewing or editing. We can open as many individual contacts as we like.

Let’s say that there are buttons to open up the “Add New” view and “All Contacts” view. We can open an existing contact by double-clicking on them in the “All Contacts” view.

My solution setup for this imaginary (and highly contrived) application might look like this.

ApplicationPresenter would be the root object of my UI. It would have an ObservableCollection of IPresenter that would be bound to a TabControl in Shell.xaml. Likewise, ApplicationPresenter will have a CurrentPresenter of IPresenter that will be bound to the SelectedItem on the TabControl.

Shell.xaml is my only window in this example. All of the other views are user controls. I named it “shell” because I think of it as the outermost level of the views. Shell’s data context is set to ApplicationPresenter.

I’m not going to dive too much deeper into this, because I want to get to my real point.

My presenters don’t know anything about their views. It’s up to data binding to render each presenter with the correct view. This means that I need to create data templates for each of the presenters. Not such a big deal in a small application, but it can get tedious as the application grows.

Hmmm… This structure is beginning to look a lot like an MVC app. Perhaps I can have it automatically infer my data templates for me?

Some Code

Yes we can. Here’s a very naiveté bit of code that will do just that. It makes some big assumptions:

all of your presenters implement IPresenter
all of your presenters are in a namespace containing “.Presenters”
all of your views are in an analogous namespace containing in “.Views”

Again, this is not production ready code, just my spike to prove the idea works. Please feel free to make suggestions.

public static class MvpConfiguration
{
    /// <summary>
    /// Creates a set of data templates pair to presenter classes based on naming conventions.
    /// </summary>
    /// <remarks>If a data template is already present in the resources, then it is skipped.</remarks>
    /// <param name="resources">The ResourceDictionary that the data templates for the views will be added to.</param>
    public static void InferViewsFromPresenters(ResourceDictionary resources)
    {
        var lookup = MatchPresentersToViews();

        foreach (var pair in lookup)
        {
            var template = CreateDataTemplate(pair.Value, pair.Key);
            if (resources.Contains(template.DataTemplateKey)) continue;
            resources.Add(template.DataTemplateKey, template);
        }
    }

    private static Dictionary<Type, Type> MatchPresentersToViews()
    {
        var presenters = from type in Assembly.GetExecutingAssembly().GetTypes()
                         where typeof (IPresenter).IsAssignableFrom(type)
                         select type;

        var first = presenters.FirstOrDefault();
        if (first == null) throw new Exception("I expected to find at least one presenters!");

        string viewNamespace = first.Namespace
            .Replace(".Presenters", ".Views");
        viewNamespace = viewNamespace.Substring(0, viewNamespace.IndexOf(".Views")+6);
        //yeah, that was hackish

        var views = from view in Assembly.GetExecutingAssembly().GetTypes()
                    where !string.IsNullOrEmpty(view.Namespace)
                          && view.Namespace.StartsWith(viewNamespace)
                    select view;

        var table = new Dictionary<Type, Type>();

        foreach (var view in views)
        {
            var presenter = GetPresenterForView(view, presenters);
            if(presenter == null) continue;

            table.Add(presenter,view);
        }

        return table;
    }

    private static Type GetPresenterForView(Type type, IEnumerable<Type> presenters)
    {
        string name = type.Name.Replace("View", "Presenter");
        var presenter =
            presenters.Where(p => p.Name == name).FirstOrDefault();
        return presenter;
    }

    private static DataTemplate CreateDataTemplate(Type viewType, Type dataType)
    {
        var template = new DataTemplate(dataType);

        var factory = new FrameworkElementFactory(viewType);
        template.VisualTree = factory;
        return template;
    }
}

To use this, in your App.xaml.cs within OnStartup() add:

MvpConfiguration.InferViewsFromPresenters(Resources);

What do you think? Am I totally nuts?

Oh, and I should also point out that FrameworkElementFactory is actually deprecated. :-( Caveat emptor.

JavaScript Gotcha in IE7

Christopher Bennage — Sun, 03 May 2009 22:10:22 GMT

I thought for a while that I was done with Web development. I mean the HTML, CSS, JavaScript stack specifically. WPF and Silverlight have just been so much more fun.

Well, despite that sentiment my weekends have been full for the last couple of months with HTML, CSS, and JavaScript work for Silver Arcade. Surprisingly, I have found it refreshing.

In fact, it’s even influenced my WPF development, but that’s another post.

Silver Arcade passes around a lot of data using JSON. I kept having problems with IE7 and spent too much time scratching my head.

Take a look at this little bit of jQuery that wires up the featured games rotator on the home page.

jQuery(function($) {
    $('#rotator-content').cycle({
        fx: 'scrollLeft',
        easing: 'easeOutQuad', 
        speed: 1000,
        timeout: 6000,
        next: '#next-feature',
        prev: '#prev-feature' ,
        pause:1,
    });
});

This code executes correctly in IE 8, Firefox 3, Safari 4, and Chrome. It breaks in IE 7. (It also works in Opera, but there are other problems there.)

The problem is the comma on the last line. IE 7 expects something more because of the comma. Specifically, the error is:

“Expected identifier, string or number”

Idealistic vs. Practical

Christopher Bennage — Tue, 24 Mar 2009 14:05:09 GMT

I often identify myself as an Agilist. When I first began to use the term, I was met with a great deal of trepidation. I remember the first few times I attended the local user group. “Oh, you’re one of those guys”. This hesitation has diminished considerably, but I still find that there are some interesting misconceptions about agile.

For example, people frequently contrast Agile with Pragmatic.

“Oh, I’ve heard about SOLID principles (or whatever), but I’m really more pragmatic.”

This has actually made me laugh out loud. You see, it was pragmatism that drove me towards the agile philosophy.

According to Meriam-Webster, pragmatic means:

relating to matters of fact or practical affairs often to the exclusion of intellectual or artistic matters : practical as opposed to idealistic

So here is the relevant contrast:

Idealistic vs. Practical

Is Agile idealistic or practical? Agile does embraces a set of principles (ideals) and I’ve seen many of its adherents become drunk with the beauty of it. I’ve been there a few times myself. So yes, it is idealistic in that respect. However, I think a better question is this:

Is Agile merely idealistic?

There is a strong idealistic streak in Agile, we will not deny it, however the ideal is actually “get work done”. In other words, Agile is the art of pragmatism.

I am motivated by success. I am motivated by accomplishing things. The quickest route to depressing me (or frustrating me) is to prevent me from getting work done. Because of this, when I first encountered the agile idea that change is expensive and therefore we should reduce the cost of change, I was listening. When I discovered that agile methodology offers a set of tools for reducing the cost of change, I was ecstatic.

In the interest of being brief, I’ll jump to my conclusion:

The application of the agile principles is about being successful in software development projects. It is not ars gratia artis. While some enthusiasts may forget that, it doesn’t change the nature of the underlying principles.

Agile is the art of being pragmatic.

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.

Mirroring Subversion from Windows

Christopher Bennage — Wed, 11 Mar 2009 20:08:00 GMT

We’ve been using Unfuddle for hosting our Subversion repositories (for almost two years I think). We’re a consulting shop and we move from project to project. It’s wonderful not having to worry about where the source is physically located or how it’s being backed.

One of our current clients wanted to have the repository for their project physically located at their facility. They gave me access to a couple of Windows 2003 boxes and asked me to get everything setup. I used VisualSVN Server and TeamCity and I had things running smoothly in almost no time. By the way, if you are not familiar with these products, you should be. They are both free (mostly) and very low friction.

Even though the repositories weren’t hosted, we were still using Unfuddle for general project management (such as tracking tickets).

Earlier this week, I was talking to our team lead and explained how Unfuddle integrates with their hosted repositories. For example, if I make comment when committing, such as “fixes and closes #147”, Unfuddle will update the status of ticket #147 as well as associate the changeset with the ticket. I can quickly jump to the committed code directly from the ticket. (Unfuddle is certainly not the only tool that does this, it’s just the one I’ve been using).

Anyway, the team lead was impressed and asked why we weren’t doing this. Well, because the customer wanted the source on site, and this feature of only works with the integrated repositories.

Mirroring a Repository

What we needed was a way to automatically propagate updates from an Unfuddle hosted repository to client’s onsite repository. The onsite repository could be read-only; that satisfies the client’s need. A couple of quick web searches revealed that Subversion includes a tool doing exactly this: svnsync.

Unfortunately, the directions that I found might be a little opaque to Windows users.

Here’s a step by step of what I did.

I created a new repository to be my destination repository. You have to have a fresh repository to be the destination. With VisualSVN Server, this is merely a right click Create New Repository.
Next, you have to edit the pre-revision property change hook for the destination repository. This hook allows you to execute some logic to determine if a revision property can be changed. By default, svn will say “no, sorry, you can’t change the revision property”. The hooks are located in the hooks directory in the actual folder for the repository. In our case, the hook will be a batch file named “pre-revprop-change.cmd”.

You can (and maybe should) perform some logic here to verify what’s happening. For example, you could verify that the user performing the change is the user that you expect.

In my case, I simply said “exit 0”. (If you want it to fail and not allow the change, then exit 1.)

Update: Ivan Zhakov made a comment that you should avoid exit 0, and verify the user's identity with something like this:
```
IF "%3" == "sync_user" exit 0 exit 1
```
Once again, in VisualSVN Server this was very easy:
- right-click Properties
- switch to Hooks tab
- select Pre-revision property change hook
- click Edit
- and type “exit 0”
Next you need to initialize the destination. This is a one time process that prepares the destination repository for the synchronization process.

Use the svnsync init command to do this. Mine looked something like this:
```
svnsync init %dst_repo% %src_repo% 
	--source-username buildserver --source-password 1234 
	--sync-username sync_user --sync-password 1234
```
I had the two repositories as environment variables
Now you need to call svnsync sync each time you want to mirroring to take place. If you had sufficient access to the source repository you could actually use another hook or two to trigger the mirroring process. In my case, I didn’t have that access. (Though I think Unfuddle might provide a callback url on commits). Instead, I chose to schedule the sync to execute once an hour during the most active development hours of the day.

My batch file that looked something like this:

svnsync sync %dst_repo% 
	--source-username buildserver --source-password 1234 
	--sync-username user --sync-password 1234

That’s all you need for your repository to be mirrored. However there is one more useful bit to know. It’s very easy to lock up the destination repository if you execute svnsync with bad arguements. In order to remove the bad locks, just run this
```
svn pdel --revprop -r 0 svn:sync-lock %dst_repo%
```

Be sure to use svnsync help if you run into problems. Here’s is a guide that helped me out as well.

P.S. There is some stuff in TortoiseSVN to work with hooks as well, but I’ve never explored it. Honestly, I was able to get the mirroring setup in well under an hour and I only looked at TortoiseSVN as an afterthought.

Update May 18, 2009: Andy Pook added:

You should also check "svnlook uuid" and "svnadmin setuuid". Getting the uuid's in sync will make it _much_ easier to switch your working copy if you need to use the mirror.

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

An Essential Tip for Working With XAML

Christopher Bennage — Wed, 04 Feb 2009 14:51:00 GMT

Most WPF and Silverlight devs already know to turn off the default design view for XAML. I don’t ever use the designer in Visual Studio for either Silverlight or WPF. My apologies to the team that worked on it, but it is a hindrance and not a help. When I give presentations, my audiences are often surprised to discover how much XAML I edit manually. Now, I do use both Blend and Kaxaml quite a bit, but never the builtin designer.

In case you don’t know how to disable the design view (the option is buried somewhat):

Tools > Options > Text Editor > XAML > Miscellaneous

Then check “Always open documents in full XAML view”

Other Troubles

I upgraded to 64-bit Vista a month or so back, and despite the positive experience overall, I had one very frustrating problem. Frequently, when I worked with a XAML file, Visual Studio would get all wonky. It only seemed to affect a single XAML file at a time, even if I had a dozen open. I could reset the troubled file by closing it and opening it again. The problem usually started with my scrollbar failing to repaint. At first I was fearful that it might be related to ReSharper (which has awesome XAML features BTW). Then I suspected my video drivers (which I still do actually). Nevertheless, I didn’t find a solution.

Fortunately, Fabrice Marquerie (of LINQ in Action fame) made this very useful post on his site a few days.

Fabrice discovered an excellent trick: using the Source Code Editor for XAML. It’s really fast and you have all of the same features as the default XAML editor. The only thing you lose it the Design tab at the bottom. And hey, if you really need it, it’s only a right-click away!

Here’s the instructions copied from his blog:

Right-click on a XAML file in the Solution Explorer

Select "Open With..."

Select "Source Code (Text) Editor"

Click on "Set as Default"

Click OK

You're done!

Trust me, if you work with XAML, you’ll want to do this.

UI Patterns for WPF

Christopher Bennage — Tue, 20 Jan 2009 03:19:00 GMT

There’s a lot of recent buzz about the Model-View-ViewModel or MVVM. (I pronounce it like it rhymes with Auntie Em.) Rather timely for me as a lot of my thinking about implementing UI patterns in WPF has begun to coalesce.

There’s has been a lot of thought given to UI patterns prior to the advent of WPF. Martin Fowler has a relatively succinct historical overview of GUI architectures. I’d like to start here by discussing how these established patterns are mapped to WPF. After that, I’d like to explore how WPF allows us to improve on these patterns. We’re probably in for a series of posts here.

Why Patterns?

One guiding principle, both for testability’s sake as well as for myriad other reasons, is Separated Presentation. This is a just a special case of the general principle Separation of Concerns. We separate the concerns because they are easier to test, maintain, and extend.

Let’s assume that you buy into the value of testability. The next problem is that UI code is notoriously difficult to test. This is a product of the way UI frameworks generally work. The common solution is to push as much behavior as possible into Plain Old CLR Objects (POCO). In other words, if a class is tied to the UI framework, and thus is difficult to test, it should have as little logic in it as possible; instead that logic should be delegated to classes that are easier to test.

The Patterns

There are number of standard approaches, er, patterns, that have been recognized. My influences for interpreting these patterns are Martin Fowler, Jeremy Miller, John Gossman, and Dan Crevier.

I want to show you have these patterns look in code, so let’s establish a quick (and highly contrived) scenario. We have a registration form that accepts an email address, a password, and a confirmation of the password. There’s a button to initiate the registration, but the form has to be in a valid state in order for the button to be enabled. The rules are:

The email address cannot be blank.
The password cannot be blank.
The confirmation must match the password.

Now for the patterns…

The Autonomous View

This is what we don’t want to do, but usually do. All of the logic is in the code-behind. Very little is delegated out to other classes, and when it is, it is typically delegated to concrete types so that hard dependencies exist. It’s impossible to test with this pattern because it is impossible to isolate the behavior that need to be tested. Here’s the xaml and the code-behind.

Model-View-Presenter

I’ve used the term MVP a lot. (Hey, I am one now!) Fowler has suggested that MVP subsumes two more specific patterns (and that the term MVP should be retired in favor of them). Both of the child patterns have the same elements: a model, a view, and a presenter. Generally, the model is data that you are interested in, the view renders the data on screen, and the presenter handles all the “presentation concerns”. What constitutes “presentation concerns” though is part of what distinguishes the two child patterns.

Supervising Controller

The first of the MVP patterns is the supervising controller, or supervising presenter. (The terms controller and presenter are somewhat ambiguous themselves and are frequently interchanged.) The presenter in the supervising presenter pattern has properties that interact with the view through data binding. Frequently, you’ll have simple event handlers (e.g., the click event for a button) that merely call methods on the presenter. (There is an alternative to the event handlers, but I’ll get to that later.)

This pattern is easy to test because the presenter has most of the behavior for the UI and it is POCO. The deficit is that the view still contains some logic in the form of bindings.

Notice here that we’ve introduced bindings into the xaml and that there is almost nothing in the code-behind. The real behavior is here in the presenter.

Passive View

This flavor of MVP squeezes out the remaining behavior out of the view. With this pattern you define an interface for the view that the presenter operates against. The implementation of the view interface has to be very simple, you want the absolute bare minimum in the view. The view is passive because it doesn’t know or do anything. The presenter handles all of the logic and manipulates the view. In WPF, you’ll end up with more code in the code-behind (because you are implementing the interface), but you can avoid bindings. Why do you want to avoid bindings? Because they are harder to tests… or are they? More on that later.

Here’s the view’s interface. Note that the code-behind is more involved, but the xaml no longer has bindings. Also, notice how the presenter has to know a lot more about the view.

A Warning

We all want patterns to be distinct and specific, but the reality is that they are blurry. Often you will be combining elements from various patterns in order to accomplish what you need to do. Don’t get hung up on implementing a pure pattern.

Presentation Model vs MVVM

Actually, I will pick up here next time. I need to give you a reason to come back, right? :-)

If you are interested in the playing with the code examples, I’m posting it on CodePlex.

Building a WPF Application: Part 6

Christopher Bennage — Tue, 13 Jan 2009 05:29:21 GMT

ChumChase Table of Contents

I opened up the ChumChase code this evening with the sad realization that my last commits were on November 14th. Ouch. In reading over the code, something jumped out at me immediately. In the code-behind for Shell.xaml, I had a lot of logic that didn't need to be there. It was clumsy and not tested, but at least I had left myself a comment to that effect.

The code handled switching from the default view to the 3D view. If you don't know what I'm talking about, go back and read the older posts. The important part of Shell.xaml looked like this:

<Grid>
    <ContentControl x:Name="MainView" />

    <Button Content="Toggle View"
            VerticalAlignment="Top"
            HorizontalAlignment="Right"
            Click="ToggleView_Click" />
</Grid>

and the handler for the click (along with a dependent method) looked like this:

private void ToggleView_Click(object sender, RoutedEventArgs e)
{
    if (MainView.Content is DefaultFeedView)
    {
        SetView(new _2Don3DView());
    }
    else
    {
        SetView(new DefaultFeedView());
    }
}

private void SetView(IFeedView view)
{
    MainView.Content = view;
    view.RefreshButton.Click += Refresh_Click;
}

Yes, _2Don3DView is not a good name. I'll fix it. Aside from the appalling appellation, this code is not very WPF-ish. What is it doing anyway?

ContentControl is really a place holder. It represents the area in the application's shell where we want to stick the main content. In the handler, we check to see what is currently in the placeholder and we switch it out. Since each view had it's own button for refreshing the feed we needed to wire it up each time we switched the view. (Remember this way is naughty-naughty.) Our views implemented IFeedView so we could access their respective Refresh buttons.

A More Excellent Way

My ApplicationController class should really be responsible for this behavior. In order to make that happen, I created a property on it called CurrentPresenter. This property is the presenter that will back the current view. (A presenter is a class that contains the logic for a portion of the UI, the corresponding view is the visual part used to render that presenter.) Since the data context for Shell.xaml is already set to an instance of ApplicationController (it's named _controller in the code-behind), I was able to changed the markup to look like this:

<Grid>
    <ContentControl Content="{Binding CurrentPresenter}" />

    <Button Content="Toggle View"
            VerticalAlignment="Top"
            HorizontalAlignment="Right"
            Click="ToggleView_Click" />
</Grid>

and then the event handler to this:

private void ToggleView_Click(object sender, RoutedEventArgs e)
{
    _controller.ToggleView();
}

And now, let's examine the tests for the desired behavior. I wanted ToggleView to alternate between an instance of DefaultFeedPresenter and an instance of _2Don3DPresenter. (Bad Christopher, bad!) I did not want ToggleView to create new instances, but to reuse existing ones.

[TestFixture]
public class The_application_controller
{
    [SetUp]
    public void given_a_context_of()
    {
        // stuff omitted for brevity //
        _controller = new ApplicationController();
    }

    [Test]
    public void raises_change_notification()
    {
        _controller
            .AssertThatAllProperties()
            .RaiseChangeNotification();
    }

    [Test]
    public void uses_the_expected_presenter_by_default()
    {
        Assert.That(_controller.CurrentPresenter, Is.InstanceOfType(typeof(DefaultFeedPresenter)));
    }

    [Test]
    public void toggles_to_the_3D_view_when_the_default_is_current()
    {
        _controller.ToggleView();
        Assert.That(_controller.CurrentPresenter, Is.InstanceOfType(typeof(_2Don3DPresenter)));
    }

    [Test]
    public void toggles_to_the_default_when_the_3D_view_is_current()
    {
        var default_presenter = _controller.CurrentPresenter;
        _controller.CurrentPresenter = new _2Don3DPresenter(_controller);
        _controller.ToggleView();

        Assert.That(_controller.CurrentPresenter, Is.EqualTo(default_presenter));
    }
}

Ooo, hey, what's that first test? That raises notification bit? Oh, that just some cool stuff in Caliburn, you can read more about that here.

I added the following lines to ApplicationController in order to pass these tests:

private readonly IList<IPresenter> _presenters = new List<IPresenter>();
private IPresenter _currentPresenter;

public IPresenter CurrentPresenter
{
    get { return _currentPresenter; }
    set
    {
        _currentPresenter = value;
        RaisePropertyChanged("CurrentPresenter");
    }
}

public void ToggleView()
{
    CurrentPresenter = (CurrentPresenter is DefaultFeedPresenter)
        ? _presenters[1]
        : _presenters[0];
}

I initialized _presenters in the constructor for ApplicationController with the instances of the presenters. (I was tempted here to introduce an IoC container, but I didn't. We'll talk more about that later.)

So now, when ToggleView is called, the CurrentPresenter property is updated and change notification is raised, but what happens in the UI? How does it render the presenter instances? Well, given the markup from Shell.xaml we listed above, it doesn't do anything.

I Love DataTemplates So Much, Why Don't I Marry Them?

We need to tell WPF how to render each presenter. We already have user controls that define each view. We can reuse those. I added the following to the Grid containing my ContentControl:

<Grid.Resources>
    <DataTemplate DataType="{x:Type Model:DefaultFeedPresenter}">
        <Views:DefaultFeedView />
    </DataTemplate>
    <DataTemplate DataType="{x:Type Model:_2Don3DPresenter}">
        <Views:_2Don3DView />
    </DataTemplate>
</Grid.Resources>

The DataType property tells WPF that anything bound to an instance of the given type should use the template. Since I placed these in the resources for the grid, it will affect any bindings inside the grid. Each data template simply contains the corresponding user control. I could have inlined the user controls, but I already had tests in place and I believe this makes the markup easier to read.

In making these changes, I did break something. Something that was not being tested... but it's time for bed so I'll leave that for another night.

More to come!

Tally UG Follow-up - Silverlight Game Dev

Christopher Bennage — Sun, 11 Jan 2009 02:19:00 GMT

I appreciate everyone who came out for my session on game development in Silverlight.

Here is the code we wrote during the session. It's not pretty, and if you weren't at the present, I expect it will be hard to follow. I hope to have a cleaner version published soon. (So much to do!)

Some resources that might be useful for your game development efforts:

Blue Rose Games - a blog about Silverlight game development in general
Andy Beaulieu on collision detection. Be sure to check out the rest of his blog, as there is lots more on Silverlight game dev.

You'll see the influence of both of those blogs in the code from the session.

Also, for the Flash crossover guys who were present,

Shine Draw does regular comparisons of Flash and Silverlight.
Project Rosetta is a set of Silverlight tutorials design for Flash guys.

TDD Firestarter in Tampa

Christopher Bennage — Wed, 07 Jan 2009 22:12:10 GMT

The new year has already gotten away from me and it's only 7 days old. (Come back, Baby Happy!)

In less than 2 weeks from now, we're going to a have full day of TDD in Tampa, FL. The event is designed so that everyone will find value, whether you are merely curious about methodology or a veteran practitioner.

We're starting off the day with introductory and intermediate session on TDD and following it up with some very focused sessions in the afternoon. (I'm going to be talking about doing TDD with WPF and I'll be using a little bit o' Caliburn as well.)

Saturday, January 17, 2009

9:00 AM–5:00PM

Click here to register or call (877) 673-8368 with event ID 1032397083.

Speakers include Cory Foy, Scott C. Reynolds, Sean Chambers, and Rob Eisenberg.

Please come out and join us! Did I mention it's free?

More information here...

a method to the madness?

Christopher Bennage — Sat, 13 Dec 2008 21:50:08 GMT

class Madness
 def method_missing(method, *args)
  nil
 end
end

In full disclosure, my ruby is all stinky bad. I solicited this joke from my good friend Jeremy Walworth (founder of the internationally renown website, hairforecast.com.)