Lou Franco's Software Business Blog : Programming

If Google Can’t Make a Great Mobile Web App, Can Anyone?

loufranco — Mon, 31 Aug 2009 11:45:45 GMT

I recently switched from NewsGator to Google Reader for reading RSS subscriptions, and along with that, I had to switch from a native iPhone app to using the iPhone version of Google Reader’s web application.

The full-size Google Reader is one of the best web applications that I use – it’s just as good as GMail or Google Maps in terms of usability, responsiveness, and feature-set. The mobile version is very similar. It’s been optimized for iPhone, of course, but it’s a comparable to the normal site – they haven’t compromised much.

Even so, on the iPhone, I wish they had made a native application instead.

Here are some of the reasons why:

On my iPhone, I don’t always have a great connection. I don’t feel the sluggishness of web applications on my PC, but on my iPhone, it’s pretty slow when I’m not on WiFi.
iPhone native apps have consistent GUIs, and Reader really stands out like a sore thumb. One simple example is that navigation buttons aren’t always visible. Good desktop applications are more usable than web applications as well, but the margin is much wider on a mobile device. The native controls and look-and-feel are designed to work well on a mobile device, and it's not easy to duplicate that with HTML.
Deployment and updating are not issues on the iPhone. I’d be annoyed if I had to keep upgrading a native Reader application on my PC, but on the iPhone, it’s not really an issue. It’s automatic and fast – so I don’t have a natural preference for web applications like I do on my PC.
Having Reader share state with Safari is annoying. This might just be me, but I have more than one GMail login (personal and work) and every time I log out, it logs me out of Reader. I don’t have this issue as much on a PC because I can use multiple browsers, and I don’t switch as much on a single computer.
No offline mode. I assume that they could do this if they want, since mobile Safari has an offline data store. With native applications, it’s just normal that they would still work offline. I think it’s reasonable to expect an RSS reader to have some caching.

I just switched, so I haven’t taken a look at the native RSS apps that support Google Reader. On first look, the Google mobile version looked like it would be good enough, but even the best mobile web applications don’t stand a chance against native applications.

Computational Information Design

loufranco — Wed, 06 May 2009 14:18:26 GMT

Last night, Atalasoft and Snowtide Informatics sponsored a meeting of the Western Mass Developers Group, which featured Ben Fry speaking about Computational Information Design and the Processing programming language. O’Reilly also pitched in by giving us a few copies of Ben’s book, Visualizing Data, to give away.

The talk was a fascinating journey through Computational Information Design, an interdisciplinary field that encompasses aspects of Computer Science, Mathematics, Statistics, Graphic Design, User Experience Design, and Human Factors Engineering. Visualizing Data goes into more depth, and you can see his early work describing this in his dissertation.

The main crux is that the process of data visualization has these steps:

acquire – the matter of obtaining the data, whether from a file
on a disk or from a source over a network.
parse – providing some structure around what the data means,
ordering it into categories.
filter – removing all but the data of interest.
mine – the application of methods from statistics or datamining, as a way to discern patterns or place the data in mathematical
context.
represent – determination of a simple representation, whether
the data takes one of many shapes such as a bar graph, list, or
tree.
refine – improvements to the basic representation to make it
clearer and more visually engaging.
interact – the addition of methods for manipulating the data or
controlling what features are visible.

Each of these steps require skills from traditionally different fields – and Computational Information Design unites them.

A key aspect of his work is the development of Processing, a programming language designed to be accessible to non-programmers, but powerful if needed. It has many simple abstractions to make graphics and interaction programming very simple, and can export to an Applet or Application for easy distribution. Much of his talk was dedicated to showing us some of the visualizations that have been created using it, including some that interact with the real-world in interesting ways. Works ranged from DNA visualizers, to book edition differencers and algorithmic art. OpenProcessing has many examples with full source code.

Code 39 Barcode Generation

loufranco — Mon, 24 Mar 2008 13:37:00 GMT

I read this kind of funny story about a kid who got himself into a little trouble reading and writing barcodes by hand. After reading it, I figured if he's going through the trouble of getting graph paper and markers to write Code 39, I can certainly provide the code to doing it with DotImage.

Code 39 is a simple barcode format -- it supports only capital letters, numbers, and seven other special characters (so 43 characters total). Each letter is encoded with nine alternating black and white bars, always starting and ending with black. Three of the nine bars will be wide, and the rest narrow (thus the name -- sometimes also called 3 of 9). Between each letter is a narrow white bar, and there is a start and stop code so you know that you are looking at a Code 39.

One nice thing about Code 39 is that you can calculate the size in pixels before encoding, since each letter is the same size (3 wide and 6 narrow).

Here's some code:

First I grabbed the table of encodings from the wikipedia page on Code 39 and put them into a hashtable:

private static Hashtable _encoding = new Hashtable();

static BarcodeCode39()
{
_encoding['*'] = "bWbwBwBwb";
_encoding['-'] = "bWbwbwBwB";

// rest of encodings removed

}

Here is how you calculate the width of the image (there are two extra characters added to the barcode, and I have a margin as well).

    public int ImageWidth
    {
        get
        {
            return (_data.Length + 2) * ((3 * _wideWidth) + (6 * _narrowWidth)) +
                (_data.Length+1) * _narrowWidth +
                2 * _margin;
         }
    }

To make the barcode, I create the image:

    int imageWidth = ImageWidth;

    AtalaImage barcodeImg = new AtalaImage(imageWidth, _imageHeight, pf, Color.White);
    Canvas barcodeCanvas = new Canvas(barcodeImg);
    Fill fill = new SolidFill(Color.Black);
    AtalaPen pen = new AtalaPen(Color.Black);

Then here is my main loop through the data to encode:

    // add start/stop
    string dataToEncode = "*" + _data + "*";
    int x = _margin;
    foreach (char c in dataToEncode)
    {
        string bars = (string)_encoding[c];
        if (bars == null)
        {
            throw new NotSupportedException("Invalid character in data: '"+c+"'");
        }

        foreach (char b in bars)
        {
            switch (b)
            {
                case 'B': // Wide Black
                    barcodeCanvas.DrawRectangle(new Rectangle(x, _margin, _wideWidth, _imageHeight-2*_margin), pen, fill);
                    x += _wideWidth;
                    break;
                case 'W': // Wide White
                    x += _wideWidth;
                    break;
                case 'b': // Narrow Black
                    barcodeCanvas.DrawRectangle(new Rectangle(x, _margin, _narrowWidth, _imageHeight-2*_margin), pen, fill);
                    x += _narrowWidth;
                    break;
                case 'w': // Narrow White
                    x += _narrowWidth;
                    break;
            }
        }
        x += _narrowWidth; // between characters
    }

I attached Assemblies built off of DotImage 6.0 -- if you have a maintenance release (you are reading this after 6.0a has been released), you can find a version of this in the Demo directories.

Here's how you use it:

    BarcodeCode39 bc39 = new BarcodeCode39(data);
    bc39.Margin = 1;
    AtalaImage img = bc39.CreateBarcodeImage(PixelFormat.Pixel24bppBgr);

Then, you can use the image to overlay onto another with OverlayCommand. There are properties to adjust the outcome (NarrowWidth, WideWidth, ImageHeight, Margin).

Here's how you recognize that barcode with the Atalasoft Barcode Reader:

    BarReader br = new BarReader(img);
    ReadOpts opts = new ReadOpts();
    opts.Symbology = Symbologies.Code39;
    BarCode[] bc = br.ReadBars(opts);

Clojure Presentation In Northampton

loufranco — Wed, 27 Feb 2008 15:13:00 GMT

On March 20th, the regular meeting of the Western Mass Developer's Group will feature Rich Hickey, the author of Clojure.

Clojure is a dialect of Lisp that compiles to Java Bytecode and runs on the JVM. It features persistent, immutable data structures and a model for creating multi-threaded designs. If you haven't seen clojure, please take a look at the site:

http://clojure.sourceforge.net/

The meeting will be at 243 King Street in Northampton and will start at 6:30.

And, if you have a chance, you might want to check out his talk at the Lisp NYC meeting:
http://lispnyc.org/wiki.clp?page=past-meetings

AJAX v. Flash: Another Datapoint

loufranco — Tue, 26 Feb 2008 02:27:00 GMT

Last week, I wondered why Scribd uses Flash instead of AJAX and mentioned that it wouldn't work on my iPhone. Today I read that Debian has removed flash from their distribution. Sure, the number of Debian installations won't even show up in the 3rd decimal place of Flash penetration, but it would be shocking to hear a similar story about AJAX on any platform.

Business of Software Conference

loufranco — Sun, 24 Feb 2008 14:15:00 GMT

The 2nd annual Business of Software Conference will be in Boston in the Fall. The conference is a off-shoot of the very popular BoS Forum on JoelOnSoftware.

The site has videos up from last year's conference. I found this one on measuring your code's (ahem) Change Risk Analysis and Predictions, to be particularly good.

Stream-Oriented Programming in PowerShell

loufranco — Mon, 18 Feb 2008 21:12:00 GMT

While preparing my PowerShell presentation a few weeks ago, I was reminded of this explanation of stream processing from the SICP lectures.

This concept is widely used in Unix shells, but is really taken to the next level in PowerShell. In fact, after using it for a while, Unix style text stream processing seems primitive in comparison.

In PowerShell, commands emit streams of objects. When you use a pipe to connect commands, each object on the output of the first command is sent to the next one -- not a string representation, but the object itself. Since PowerShell is essentially a .NET reflection-based object automator -- most of this happens in-process (no serializing).

And, writing commands in .NET is simple -- I used O'Reilly's PowerShell Cookbook, by Lee Holmes (highly recommended) to learn how -- but essentially, a cmdlet is a simple class that implements System.Management.Automation.Cmdlet. Your public properties are automatically turned into command-line arguments (with one, optionally coming from the pipe), and then all you need to do is implement ProcessRecord(), which will be called for each input object. PowerShell manages the pipeline -- you just need to worry about one object at a time.

It's a powerful concept, but to fully take advantage of it, you'll need to wrap your OO designed objects in Cmdlets.

Designing for Intellisense

loufranco — Fri, 09 Nov 2007 13:28:00 GMT

Atalasoft was at DevConnections this week, and I went to a some of the sessions including one on a deep dive of Linq, where I learned why Linq looks like this:

from ord in orders select ord.id, ord.amount

Instead of this:

select ord.id, ord.amount from ord in orders

The first example enables intellisense in the IDE to help you once you are finished with the from clause. I have to say, that I was a little shocked when he first said it. Up until then, I had filed this difference with SQL in the "Microsoft just has to be a little different" part of my brain that also knows when to use backslashes and where the menu bar is.

The other thing that shocked me, is that I had never heard of a language feature that was specifically designed to be IDE-friendly. Certainly, there are features in languages that turn out that way. Having curly-braces helps Visual Studio reformat your program, but C# doesn't have curly-braces for that reason (or maybe it does -- did K&R put curlies into C because of ed -- beats me). In any case, if there's a language feature that exists just for the editor, I hadn't thought of it that way.

It kind of got me thinking about method-calling syntax, which usually is

object.method( ... )

but, in Ada and some languages it's

method(object, ...)

Which, until now, seemed to me to be an arbitrary choice, but with advanced editors, the first can actually be quite helpful. I guess the second would be good if I were more familiar with operations I could do and wanted the IDE to tell me which objects I could do them to, but that doesn't seem like the usual case to me.

The idea of language features being designed for the IDE leads to the question of whether API's should be designed for the IDE as well. This comes up in DotImage when dealing with images and commands. In DotImage, we have an AtalaImage object that represents an image and an ImageCommand base class that image processing classes derive from. You use commands like this:

AtalaImage img = new AtalaImage("image.jpg"); ImageCommand cmd = new CropCommand(cropRect); ImageResults res = cmd.Apply(img);

But, if you're new to our API, and you're wondering how to crop an image, you might want to type "img." and let the IDE pop up all of the choices. If you did, Crop would not be there. This makes sense, because we have over 150 commands, and we would not want to pollute AtalaImage with all of them. Also, if we made them methods, it would not be easy for our users to extend the API with their own commands that behave just like ours, and they wouldn't be able to inherit from the ones we have already. There are other reasons, like undo support and other features that operate on commands, but you get the point -- commands themselves are interesting enough to be classes, not just methods on an image.

C# 3.0 adds another feature for just that situation, Extension Methods, and now I'm starting to think that they exist just for intellisense too. The basic idea is that you make static functions callable via dot syntax on an object if you make the first parameter the class of the object and mark it with "this". Continuing this example, a Crop method could be added to AtalaImage with this code:

public static class AtalaImageCommands { public static ImageResults Crop(this AtalaImage img, Rectangle r) { return new CropCommand(r).Apply(img); } }

Now, I can call img.Crop(...) as long as the namespace with this class is imported, and the IDE will show Crop as a method as well. The other nice thing is that anyone extending the library can add extension methods too (so their commands would work like the built-in ones).

I'm not saying that we'll definitely use this (150 methods would still show up in the IDE), but choosing the 10 most used ones might be a good idea. Also, since you can control it by putting the extension methods in different namespaces, you can let the programmer decide when they want them to show up. We could put extension methods for commonly used commands in the namespaces with the command classes, and put the rest in a sub-namespace.

Seven Tips for More Effective GUI Tests

loufranco — Mon, 31 Jul 2006 18:45:00 GMT

One of the things I did for our new 4.0 release was write some GUI tests with AutomatedQA's TestComplete for our new and improved AJAX Image Viewer and Thumbnail Viewer. Along the way I learned a lot about how to write and maintain automated GUI scripts that I'd like to share. This is not a review of TestComplete -- I'm sure these tips would be applicable to any GUI scripting solution.

For those not familiar with products like this, TestComplete allows you to record and playback GUI events and then compare screenshots against the original run. It's analogous to the role NUnit plays in unit testing, but with specific features to drive a GUI. We are using the web product which allows us to address the DOM inside a page shown in IE for fine grain access to the controls of the GUI.

"Write" tests rather than record them. When you are just getting started with the tool, you're going to record tests and play them back, just to see how it works. It's extremely important that you break yourself out of that habit as soon as possible and start writing scripts directly. Otherwise you'll have scripts that look like this:
function Test1() { var w1; var w2; w1 = Sys["Process"]("iexplore")["Window"]("IEFrame", "*"); w2 = w1["Window"]("Shell DocObject View")["Window"] ("Internet Explorer_Server"); w2["ToURL"]("http://localhost/ThinClientViewerTests/"); w2["Wait"](); w1 = w2["Page"] ("http://localhost/ThinClientViewerTests/")["document"]; w1["all"]["Item"]("DropDown_MouseTool") ["ClickItem"]("Selection"); w1["frames"]["frame"]("WebImageViewerMain_ov") ["document"]["all"]["Item"](6)["Drag"](77, 86, 354, 254); if(!Regions.Compare("AfterSelection.bmp", Sys["Process"]("iexplore")["Window"] ("IEFrame", "*")["Window"]("Shell DocObject View") ["Window"]("Internet Explorer_Server")["Page"] ("http://localhost/ThinClientViewerTests/") ["document"]["all"]["Item"]("WebImageViewerMain_om"))) Log.Error("The regions are not identical."); }
instead of this:

function TestSelection () { var w = GetIEProcess(); GotoTestPage(w); var doc = GetDocument(w, GetUrl()); ChooseMouseTool(doc, "Selection"); GetImage(doc)["Drag"](77, 86, 354, 254); AssertRegionIsEqual("AfterSelection.bmp", GetImageViewerControl(doc)); }
Granted, you're likely to want to rewrite the recorded code a little bit, but I'm advocating a full refactoring so that the scripts share as much code as possible. Once you've done this a few times, you will find yourself just writing the tests directly instead of recording them. Some of the following tips are only possible if you take this step.
Make tests resilient to change. One of the most frustrating aspects to GUI testing is that the look and components of the GUI are not stable until late in the development cycle. They are also more likely to change in a new version than software APIs, for which we have developed many practices and patterns to make them backwards compatible. Changes in a GUI, by their nature, are not compatible at the level we need for an automated test, so you must make your tests easy to update. There are two things you should do:
1. Take snapshots carefully. Do not take a full window screenshot to compare unless it is necessary -- instead take a snapshot of the relevant area. If this part of the window moves around, most tools will know how to find it (they poke into the underlying form, or in my case, DOM, to find its location on the screen). If your tool supports it, use its image comparison tolerance and masking features to compare just the important parts.
2. Access controls through accessor functions. Each piece of the GUI that you control or snapshot should be accessed via a function that you write. That way, if its name changes, or if something has to be done before accessing it, you have a hook. If you've refactored the recorded scripts, you're probably already doing this.
Make failures easy to figure out. The easiest way to do this is to log breadcrumbs along the way. Again this is easy to do if you've refactored code. In my case, AssertRegionIsEqual logs what it is comparing so that I know how to interpret any failures.
Make tests individually callable. In TestComplete, this means making each test function void and taking no arguments. This is the default when recording them, but when I was rewriting them, it was very tempting to try to make them OO or add arguments. This makes it hard to just right click on one and choose "Run" from the context menu, which I consider a must-have feature. So, even though the code could be better organized, I won't do it if the tests can't be called from the editor.
Have the tests put the GUI into known states. One thing I noticed early on is that I'd sometimes have an image comparison error because a control had the mouse over it or the control had focus when playing back, but not during the snapshot. This is because the snapshot tool requires you to move the mouse and take focus away, but playback does not. It's important to put the mouse exactly where you want it and give focus to a control or area that won't change it's look (by clicking the background, e.g.) before you take a snapshot. Once I realized this, I wrote a function to do it and called it in my snapshot comparison function.
Write focused tests. Do not have one giant function that exercises your entire GUI. Break it down into individual, stand-alone tests.
If you use a bug-tracker, write GUI tests to confirm a fix. While developing, it great to test-first and write an automated unit test that reproduces a bug before you fix it. While confirming those fixed bugs (in acceptance testing), it is equally important to write a repeatable test that confirms that the bug is fixed. Of course, you should comment the case number in the test script and the script name in your bug-tracker.

In general, I find it's harder to make a reliable repeatable GUI test than a Unit test. Having a maintainable code base makes it possible to add in code later that makes it more reliable. Also, it's easy for me to to change my code from a testing script to a snapshotting one, when I want to make a different snapshot repository for different initial conditions (in my case for when the image viewer is viewing a different test image). These things would be impossible if I didn't rewrite the recorded script, which I think is the key to making tools like these more useful.

Atalasoft in 3D

loufranco — Wed, 10 May 2006 20:52:00 GMT

Part of what I'm doing puts me knee-deep in Atalasoft ImageCommands. I was staring at some results of TintGrayscale and wondered how easy it would be to make the kind of 3D images that are a combined red and blue images with Atalasoft dotImage. Turns out, it's really easy.

Here is what you need to do:

1. Take two pictures of a subject with the camera shifted three inches horizontally.

2. Turn both images to grayscale

AtalaImage left = new AtalaImage(_leftName);
left = left.GetChangedPixelFormat(PixelFormat.Pixel8bppGrayscale);

AtalaImage right = new AtalaImage(_rightName);
right = right.GetChangedPixelFormat(PixelFormat.Pixel8bppGrayscale);

3. Make a third image that uses AtalaImage.CombineChannels where the left image is in channels one and two, and the right image is in channel three.

_combinedChannelsImg = AtalaImage.CombineChannels(
PixelFormat.Pixel24bppBgr, new AtalaImage[] { left, left, right });

4. Use ShiftChannelsCommand to correct for any offset errors that may have been introduced when the pictures were taken.

ShiftChannelsCommand lscc = new ShiftChannelsCommand(-hstep, -vstep,
         ChannelFlags.Channel3, 127);
ShiftChannelsCommand rscc = new ShiftChannelsCommand(hstep, vstep,
         ChannelFlags.Channel1 | ChannelFlags.Channel2, 127);         _combinedChannelsAndShiftedImg =
         lscc.ApplyToImage(_combinedChannelsImg);
_combinedChannelsAndShiftedImg =
         rscc.ApplyToImage(_combinedChannelsAndShiftedImg);

If you want to run an application built on this code, download the zip attached at the bottom of this post. I've included a left and right image of our lounge in the zip to play with (Now supports .NET 1.1).

Click in the top left box and pick your left image
Click the top right box and pick your right image.
Click the Combine button.
Use the sliders if adjust the position of the channels if your originals aren't aligned well (shouldn't be necessary for the lounge pictures).
Click on the combined image to save it.

You need 3D glasses to see the effect (right eye red, left eye blue).

Update: The resulting image

On Optimizing: Tips for the inner loop

loufranco — Fri, 28 Apr 2006 11:56:00 GMT

Everyone knows the first two rules of optimizing: (1) Don't pre-optimize, and (2) Use a profiling tool to make sure you spend time optimizing the right code. I mostly agree with (1) -- I'll get back to that in a bit, and nothing beats a good profiling tool. We use AQTime here, and it's .NET integration and seamless support of both managed and unmanaged code is a big help when you're writing fast algorithms in unmanged code with a managed wrapper.

Another pearl of wisdom is "blah blah blah is fast enough (unless you're in a large nested loop)." Well, here at Atalasoft, we do image processing, and practically everything you do is in a nested loop over all of the pixels of the image, so all of the sudden, nothing is "fast enough". All of the sudden, you find yourself counting operations and conditionals, removing all floating-point, any division and as much of anything else that you can.

Here are some tips if you find yourself needing to optimize an inner loop. These tips are for C/C++, because if you are even thinking of doing this, you want to be in unmanaged land (one of the reasons why not pre-optimizing can get you into trouble -- choosing the right technology for when you need speed, is an important first step).

Use integers. Modern instruction sets mean that naive compilation of C to machine code results in similar speed for ints and double (my quick tests show doubles as faster), but turn optimization on, and it's a different story. My double code improved slightly, but my int code was three times faster when optimized. A quick look at the assembly showed that the code for doubles was similar, but for ints, it was transformational. Biggest difference was in using shifts for multiply and divide by a constant (I did not use powers of 2, but it figured out tricks anyway). Optimizers are better at improving calculations with ints than with doubles.
Don't divide. A corollary to using integers is that you can't divide without losing precision -- that's ok, it was probably slow anyway. A common reason to want to divide in image manipulation is for calculating ratios. In line drawing and scaling algorithms, watching a ratio is a way to know when the error term is large enough to move onto the next row or column. It often looks something like this:

if ((xSrc+1)/wSrc > xDst/wDst) ++xSrc;

You can't do this with ints, so cross multiply.

if ((xSrc+1)*wDst > xDst*wSrc) ++xSrc;

We aren't going to keep this either, but this step helps with the next one.
Don't mulitply. Often, in a loop, we're multiplying by the index. This can be replaced by an accumulation. The code above gets turned into this:

xDst_Times_WSrc += wSrc;
if (xSrc_Times_wDst_Plus_wDst <= xDst_Times_WSrc) {
++xSrc;
xSrc_Times_wDst_Plus_wDst += wDst;
}
Don't recalculate on each iteration. The optimization above also gets a big boost from the fact that xSrc doesn't change every iteration (and therefore, (xSrc+1)*wDst doesn't either).
Use Table lookups to replace costly calculations. This is a common technique. Steve described it here.
Replace array indexing with pointer incrementing. Table lookups are a multiplication and an addition, so it's not necessarily faster than a calculation at this level. But, often we are indexing by the inner loop index (because a calculation is the same for every row). In that case, increment a pointer into the table, rather than indexing.
Look for repeating patterns. Often a calculation results in a repeating pattern as you loop. If so, you can precalculate the table of results (just the smaller repeating section) outside the loop and then use a table lookup in the inner loop. This will be slower if there is no pattern, because you have to detect the pattern with a conditional.

In my particular case, the biggest wins were with (4) and (7). The repeat size was often orders of magnitude smaller than the image width (and not a function of it), so the larger the image, the more the potential speedup, which meant my algorithm time grew much slower than the original. However, without rewriting the algorithm with (1), (2) and (3), it might not have been obvious how to apply them, and (7) without (6) would not have been as fast.

XAML vs. The Humble Dialog Box

loufranco — Thu, 06 Apr 2006 15:20:00 GMT

The Humble Dialog Box [pdf] is a pattern to separate UI behavior from code that deals with a specific view technology, like WPF. Essentially, for each window you have a UI data/behavior class, an abstract view class (or interface), and a concrete view for each different type of view you're supporting. The view class should have all view technology specific code and almost nothing else. Everything else should be routed to the behavior class.

Each concrete view is responsible for rendering the information in the behavior class on demand and routing all inputs (keyboard, mouse, etc) to it. The behavior class has no public getters, so it's hard for the view to handle most events itself anyway. Model View Presenter from Fowler's Patterns of Enterprise Application Architecture is essentially the same thing, and has a simple C# example.

The simple steps (from the end of the Humble Dialog Box article) are:

Create a class for the smart object, and an interface class for the view. Pass the view to the smart object
Develop commands against the smart object, test first. Write your tests against a mock view.
Create your dialog class and implement the view interface on it. Gestures on the dialog should delegate to commands on the smart object. Calls from the smart object to the dialog should resolve to simple setter methods.

One obvious reason to do this is to support different views that have the same underlying behavior (perhaps differing only in layout). The reason I usually use it is to support a mock view to use in unit testing.

This is not the same as the separation of behavior that you get with the XAML file and the code-behind (.xaml.cs) file, because the code file will still usually have some WPF specific code in it. That's ok, but it's not Humble Dialog Box. To get that you'd need to add an abstract superclass or interface to the code-behind file and a behavior class that you route all events to.

The interesting cases are how you handle simple events in the view without routing them through the behavior class. For instance, if you have a list box on your window, you wouldn't want to route the mouse click on an item back to the behavior class so that it could change the selected item. Usually, you let the list box handle the mouse click and then route a selection changed event if needed. If the views don't dynamically change with the list box selection, you can just send the selection to the behavior class when the OK button is clicked.

Sometimes the Humble Dialog Box is overkill, but if you have complex UI behavior that you want to unit test, it's pretty useful. It is with unit testing in mind that I want to explore some of the XAML features that deal with UI behavior, namely Triggers, Data Binding, and Animation.

Triggers allow you to put simple event handlers right in your XAML. Here's a simple example that changes a button's background to yellow when the mouse is over them.

      <Style TargetType="{x:Type Button}">
        <Style.Triggers>
          <Trigger Property="IsMouseOver" Value="True">
            <Setter Property="Background" Value="Yellow"/>
          </Trigger>
        </Style.Triggers>
      </Style>

Triggers are great for these simple single-control behaviors, especially if they have no impact on the data model. If they get much more complex than this, then it will be hard to unit test. Also, if the behavior needs to be supported for non-XAML views, then it would be better to handle it outside of XAML. Any trigger that affects controls other than the one with the trigger is definitely suspect -- I'm not even sure how you do that, since the setters don't take an object anyway, but even if you can, I would stay away from that.

Data Binding lets you automatically route events to a model object and propagate changes back to the view (by binding controls to events in the model). They are very close to the Humble Dialog, and perhaps good enough for most cases. The model classes are certainly testable, but in the simplest implementations, you will still handle the event in the XAML code-behind class and then call setters on the model object.

To be more like the Humble Dialog, the event handlers should just send the event to the model objects, which then calls setters on itself (raising PropertyChanged events to get the changes back to the view). Code in the xaml.cs file should refrain from calling the getters in the model class and operating on the results -- let the model's events tell you when to update.

Animation is a complex enough behavior to want to unit test. However, the alternative to using XAML is not pretty, and the sheer amount of code savings and simplification you get by using XAML might outweigh the benefits you'd get from controlling animation outside of XAML in another class. My approach to unit testing animation would be to read the XAML into a test class and make some assertions on its structure (for instance to check coordinated timings).

My first impression with WPF and XAML is that I would want to take advantage of its features, even if that meant making my UI's less testable--simplification is less error-prone, and code I don't need to write also doesn't need to be tested.

Data Binding certainly supports unit testing of the model classes and it's easy to get to Humble Dialog from it. Animation and Triggers can be somewhat tested by asserting the contents of the XAML file. I will blog more as I explore these methods.