Its the same old question everytime you need some software. Do I buy it, build it myself, or find someone who’s already got it and convince them to share it?
Like any software developer, my first instinct is to build it – but then the business side of my brain kicks in and I start thinking about stuff like opportunity cost and cost/benefit.
We had this choice to make recently with charts and the answer was obviously to use one of the many great solutions out there. But, in the end it didn’t stack up and I was surprised that the right choice was just to build our own.
We were looking for something that …
- Could render to HTML, PDF, iPhone, iPad (rules out the great looking flash and javascript options)
- Could get 20 charts in a PDF with high enough resolution to show each chart full screen and without blowing out the size of the PDF (rules out using images)
- Would give us complete control over styling including being able to change style mid-series (rules out half the options)
- Is configurable via an XML template (rules out the other half of the options)
Actually, configuring any chart from XML is pretty standard when it comes to presentation, but not when it comes to the data. Charting solutions are generally not aware of the context of the report – they are only aware of the data values being plotted. We wanted a solution that could be aware of the full report, so that we could quickly change the data being charted. Like in Excel – when you have the data in one sheet and you can pivot/sum/group/etc and chart whatever you like.
So, our solution was to build a .NET SVG charting library that is report aware. SVG gives us full control over the style of each chart, series and data point. Instead of just outputting SVG, every aspect of the chart can be styled using SVG. It also allows us to render numerous scaleable charts to HTML and PDF without blowing out the file size. Most importantly though, the charts are aware of the report context – so a chart no longer plots points – it plots a formula over the data. For example, to show a conversion rate, the formula “SALES / VISITS” could be used in the chart (where sales and visits are two predefined metrics). This gives us a few advantages:
1. The chart can be customised via XML or a UI to show any visualisation of the available data. A quick update and we’re now showing SALES and VISITS as separate series and comparing them to last year, or filtering by region.
2. Charts can be synchronised across a report, ensuring a consistent use of colour and allowing some smarts for visualising the data best.
3. Charts can be interactive on the web. A user can drill into the conversion rate to see how it was calculated, or highlight an area of interest, or filter the report by a particular region, or pivot the chart. We borrowed the dimension/metric/date model from Google Analytics to give data as many dimensions and metrics as we needed and introduced a hierarchal subject, allowing data to be easily rolled up and summerised.
It turns out that drawing the charts is the easy bit and managing the styles and data behind the charts is the high value bit that is sorely lacking. The false ecomony in our case would have been to buy the bit that draws the charts and then to have our options severly limited for managing the styles and data.
We’ve already deployed these charts over three projects with more to come, so the investment is paying back fast too.
So having done this do you plan to sell/share it with other developers?
We’re exploring the potential to sell them. Charting is a fairly crowded market, but (like everyone) we think we’ve built something pretty special
Lots more work to do before we can call it a product though.
Customer support hero!!! Customer is always king.