Family.Show – an excellent WPF demo app

Microsoft’s Tim Sneath drew my attention to Family.Show, which he describes as “our first end-to-end reference sample for WPF”. This genealogy application was made public three months ago, but I had not tried it before. Source code is available, and there is a white paper [XPS] about how it was developed.

The application feels a little unfinished, but nevertheless it is excellent. I started the application and without reading any documentation started entering my family details. I enjoyed the results and carried on longer than I had intended. It scales beautifully, both when you resize the main window, and when you use the zoom control. Another neat feature is the time slider, which lets you change the current year. As you go back in time, everyone’s age goes down and people not yet born fade into the background.

WFP applications are unlike what we know as Windows applications. This is partly because they don’t use standard Windows controls, and partly because WPF encourages a different approach. It is more like a Flash application, and requires design skills to build.

The paper is also a good read. Family.Show apparently uses XML Serialization to persist its genealogy files. I’m not sure this is wise, though I’m open to being convinced. I’d be inclined to use an old-fashioned relational database, which I suspect would perform better with large files. Another problem with XML Serialization is that it can be brittle when you want to revise the objects.

I am always interested in performance, and a tip from the paper is worth highlighting. This is the huge benefit of virtualizing the ListView control, which means it doesn’t bother instantiating elements that are not visible. The team found sorting 32 times faster, filtering 70 times faster, and memory use 75% less when using a virtual list.

Er, wow. This is fantastic. It’s even more amazing because as I am teaching myself WPF, I pondered how easy it would be to make a genealogy application (as my partner is getting into it in a major way).

Unfortunately not much scalable, the application rapidly collapses in different aspects when the amount of data increases:
– interface responsiveness (threads could solve that, or delayed update like for example in the filters)
– data processing (a more performant collection type and more optimized queries could probably alleviate the processing time)
– choice of WPF components (displaying large amount of data should be based on ContainerVisual descendants instead of heavy FrameworkElements, even if that means a little more coding).