What is Rich Data Visualization Anyways?
One of the things you hear over and over again with WPF is the ability to do Rich Data Visualization. It has always made me cringe, as it always seems like to fit into that category you need a 3D rotating panda, or some sort of alien chart form that would make Edward Tufte cringe.
The other day, I had a gestalt, with much thanks to Chris Anderson. Six years ago, I was doing a primitive form of “rich data visualization”, I just didn’t know it. In one of my first projects at Microsoft, I was building up a report viewer. I built up an XML data island, an XSLT, and using the magic that is the XSLT transform I created HTML that hydrated an office chart control.
Looking back, what I spent a lot of time on was really the shape of my data to make it easily accessible from XSLT. (…and then the other half of the time was negotiating the syntax of XSLT.) I started off with the data, came up with a primitive display, and I had a designer help me beef up the presentation. I had to, in effect, decide what data was important, then build my UI around that.
The problem with XSLT was that I had to spend a lot of time turning my SQL query into an XML data island that had the correct data that I wanted to bind to. I would frequently change the shape of my data so that it would make it easier to negotiate the syntax in XSLT. In WPF, there are some basic things that make some stuff easier to bind to, but pretty much I don’t have to fiddle with generating the right XML, I can just databind to my custom object – no worries.
Working with Windows Forms, the problem was totally the opposite. In order to build up an application, you need to first think about how you want to display the information, then pick the controls, then work with the data. This is mainly because of limitations with the common control set. If I wanted to show a treeview, that was totally simple. If I wanted to show each tree node with a mix of fonts – bold, followed by unbold text, I would have to move to owner draw. If I wanted to show a panel of information when the treeview was expanded, I had to throw out using the TreeView control altogether and build something up from scratch. In other words, to be successful with Windows Forms and common controls, you have to know roughly what you want your user interface to look like before you get started.
Working with WPF, you’ll quickly find that it is heavily based on composition. Pretty much anything can go into anything else – if you want your node in your TreeView to show a panel of information, just go ahead and slap in a list box, or grid or whatever you need. In WPF there isn’t a whole lot of “you picked the wrong control, back to square one!”.
In WPF the workflow is slightly different that you may be used to – for anything serious, you’ll find yourself being data driven. I have this piece of data, how can I generate controls on the fly to represent it? This is where data templates (sort of the analog to XSLT) come into play. I can say I have a list of folks that are working at my company. I want to display them by “who reports to who”, and when it’s expanded I can see information about their title, how long they’ve worked here, where their office is etc. So I’ll create a data template for an Employee – whenever I see one I’ll create a TreeViewItem, with a StackPanel of TextBlocks to display the information. With confidence I can pick a TreeView, knowing that I basically want to display it in a hierarchy – and later on when I want to make it “pretty” I likely wont have to start all over from square one with a different control.
I guess my key takeaway is that rich data visualization is for everyone, whether you are building up a fancy map or chart control, a rotating panda, or just displaying a fancy tree in a treeview. You’ll likely use it without even knowing you’re doing it.