I've previously written about embedded reporting in general and looked at Telerik Reporting in more detail. But one subject wasn't touched on these posts, that is, creating operative reports without a reporting engine. Reporting engines provide a lot of features, sure, but you don't always need these features. If the requirement is to embed charts directly to your web application's views, a heavy reporting engine is just getting in your way. Think for example the Google Finance Flash chart pictured below, which for all practical purposes represents the gold standard of interactive time-series plotting:

Would you like if that plot was rendered with an SSRS-style engine, with 'generating report' animation spinning between reloads. Neither would I. Using common report elements like chart controls directly in your web app makes operative reports more responsive and the overall experience more 'webby'. But you won't get a Google Finance chart experience with the current 3rd party chart controls. The high end seems to be more like the Google Analytics -style plot with data point highlighting, which is nice too.
There are two approaches to web reporting: client-side RIA controls and server-side web controls. The distinction between the two is increasingly difficult to define technically, and I won't go into it now. Let's just say that the developer experience is different enough when using a jQuery plugin compared to a ASP.NET AJAX control that you are inclined to contrast and compare the pros and cons of both.
The charts that I've been using as a an exercise are taken from a Campaing Monitor email tracking report, which itself is a shameless visual copy of Google Analytics reports. Kudos for both! There are two charts in this report: a time-series plot with data point highlighting and a pie chart with a legend.

Now, let's try different tools to imitate this report
jQuery Chart Plugins
Javascript source code is available to all users, which makes open source a natural model for javascript-based tools. But it also means that feature-rich and well-supported tools don't just drop out of the sky, they will evolve gradually. The state of the art today is that free jQuery plugins don't either have the features or the quality to substitute a commercial chart control suite. But they are useful enough for many purposes and are simple and fun to play with. They probably also represent the future of embedded reporting. Sooner or later, one such plugin is going have enough lift to really take off. This is simply because jQuery plugins are platform-independent and consequently have appeal to an enormous plugin user and plugin developer bases. But if you are interested in commecial-quality javascript charts today, you should take a look at Emprise Javascript Charts
Technology
The jQuery plugins I tried generally utilize the HTML5 canvas element. IE does not support canvas yet, but Google's ExplorerCanvas does a decent job of emulating its functionality.
Javascript basically has two alternative methods of data access. The most straightforward method is to print data directly to the response, usually as a JSON-formatted value to a javascript variable, or as an HTML table accessible via DOM. jQuery Visualize plugin has taken the HTML table approach while others rely on JSON. But scraping data out of tables is a handy trick you can use with all javascript charting tools. The other method is to remotely load data with XHR or using cross-domain JSON.
Whatever means the client uses in reading the data, it is ultimately generated in a server somewhere. From the server-side view, printing data directly to a response can be easier than serving it through an url, especially if the data is not meant to be public. For example, I get DotNetNuke portal's page-level security for free if I print data.
Developer experience
Aside from technical capabilities, I'm especially interested in the general developer experience. The key question is: Is it simple and reliable enough for your boss? Can you recommend this tool to someone who does not have much time but who is tightly involved with customers and would like to use this first-hand information do reports without delegating them to others?
For jQuery plugins in general, I would say that if your boss has done client-side web development and knows how to use firebug, then jQuery plugins are safe. It is best to set up the environment beforehand, checking that jQuery version and plugin references are correct, and seeing that data access is working. Server-side work involves querying the data and converting it to proper format. As mentioned before, this is not necessarily AJAX, if you just write to the response page. One thing to remember with time values is that javascript requires you to convert .NET ticks to Unix/Javascript ones. Not necessarily something your boss would like learn the hard way.
The best thing in developing with jQuery plugins is the rapid development cycle. 'Installing' and testing multiple plugins in a single page is fast and fun. It took about half a day to evaluate all the plugins in this review. I have grown up to expect increased levels of frustration when dealing with new ASP.NET controls, and finding less frustration in javascript development was a nice surprise. Charting is a good fit for javascript because codebase for a single chart shouldn't grow too big and hairy.
Oh, and one more thing before going to the plugins. If you are interested in Javascript charting, go check Steve Reynolds's reviews:
flot
Flot produces nice looking lines, filled ares and columns, but no pie charts so far. The samples are great, showcasing such features as zooming with overview and colored weekends in time-series plots. Interacting with data and point highlighting with tooltips are supported too. Values for undefined parameters like axis ranges are well-thought.
In my opinion, flot is the best jQuery plugin for the chart types it supports. Solid web development skills are required to use flot, and you shouldn't be afraid to learn from real-world examples.
jqPlot
jqPlot looks very polished for an open source project and has nice features like data point highlighting. But the good first impression fades somewhat when you try it with other browsers than Firefox.
Here's a jqPlot pie chart in FF 3.5, showing email tracking data. The labels are in Finnish and mean "Opened" and "Not opened".

In Chrome, the same chart looks like this:
As you can see, the colors are inverted. If you mistakenly input data as text without parseInt(), FF is ok but Chrome will render the shares wrong:IE8 with excanvas works like FF, but again, if you input text instead of numbers, the percentage shares start to look interesting, even more so than in Chrome:

Even with these inconsistencies, jqPlot pie charts would be my choice for a jQuery Google Analytics replica.
jgCharts
jgCharts uses the Google Chart API but does not support all features from it. You can't color a pie chart with jgCharts, for example. Yet, most of the shortcomings originate from the Google Chart API. First, jgCharts do not impress visually compared to flot or jqPlot, which is not surprising since the charts are intended to be loaded as ordinary HTML image elements. This means that the API is the only way to customize the charts as CSS and javascript are out of the question. Animations and interactions like drill-down urls are naturally missing too.
Others
jQuery Sparklines didn't impress visually and I couldn't do even basic customizations to a pie chart. There is a reason for that. A sparkline is a type of information graphic characterized by its small size and data density. This is probably the optimal use for Google Chart API too.
Visualize demo charts look nice, but the feature set is quite poor. Interactive features and animations are not supported, and there are only a handful of parameters. All data is scraped from a HTML table, which means that you'll have to explicitly hide the tables you don't want to show. With other controls, the problem is exactly the opposite: you need to do extra work to show data also in a HTML table. But every jQuery plugin can easily scrape data manually from a table once it is there, which is much more flexible than creating tables in the exact format that a plugin needs. For example, in the previous jqPlot and jgCharts pie charts data was scraped from an ASP.NET datagrid. Visualize couldn't use that table directly. In the picture below there is a HTML table in the upper left corner and a corresponding visualize chart with default settings, as seen in Firefox and Chrome:
With IE8, the outcome was not so good, but at least those black spots in percentage shares were gone:Flash
Flash is the technology of choice for professional web charts, as witnessed by Google Finance and Analytics. Silverlight certainly has potential too, but because of the relatively small install base I decided to drop Silverlight Toolkit from this review.
Technology
The worst part of Flash is the Flash development itself. ActionScript is not exactly known as the language of choice in software development. Developing Flash also requires Adobe Flash Professional or Flex. But if you don't intend to develop Flash chart controls yourself, none of this really matters. Right now and in the near future, Flash chart controls are the most sophisticated ones around, both in their visual outlook and in the features they support. But you should expect Javascript libraries to close the gap pretty soon, at least from an end user's point of view.
Data access methods in Flash are a superset of the methods available for Javascript. You can use Javascript to feed Flash objects and the Flash charting tools provide good Javascript APIs. In addition, you can use the Flash object's parameters for data access. The urls defined in the Flash object are subject to different rules than the urls inside Javascript. Authorized cross-domain data loading is available and is controlled with policy files. Second, some but not all Flash charts support printing data directly to a swf parameter.
Developer experience
If you can avoid Javascript, Flash charting is extremely simple. Well, it is just HTML objects then. Any developer should be able to use these kind of charts. If you cannot avoid Javascript, the experience is similar to jQuery development.
FusionCharts Free
FusionCharts Free (FCF) is a free older version of the popular FusionCharts, the market leader in Flash charting. First time I took notice of FusionCharts when they started to show up in popular web applications, especially RescueTime uses them heavily. Creating the example email tracking charts was no problem in FCF:
FCF has all the polish of a commercial product:
- example charts that look good
- compelling feature set, but these features are yet very easy to use
- high-quality documentation and support forums.
- support for multiple server-side technologies
FCF's .NET interface is extremely simple. You replace a literal with a Flash object:
litFC.Text = FusionCharts.RenderChartHTML("/FusionCharts/FCF_Line.swf", strUrl, strXML, chartID, width, height, False);
XML data and settings are provided via an url, or are embedded direcly to a HTML Flash object. Great thing is that .NET interface does not try to act as a wrapper to XML, you generate the xml yourself and pass it as a strXml parameter to the above FusionCharts.RenderChartHTML function. FCF reads xml settings liberally and does not mind if you use settings from different chart types in one setting xml.
Each FCF chart type has a separate swf file, which is a minor complication because you need to know multiple pathnames in using the API. I wrote a helper enumeration to get correct filenames using IntelliSense.
The only problem with FCF is that it is a legacy product. The actively developed product is Fusion Charts 3, and the differences between the two are substantial. Good thing is that you have an upgrade path, but don't expect any new features in the free version.
FCF is the easiest charting tool to work with, and even nontechnical people should be able to draft chart requirements with it.
Open Flash Chart
Open Flash Chart (OFC) is a popular open-source alternative to FusionCharts. OFC sample charts look good, they are definitely the best looking ones from the charts I've tested here. But this does not help too much if you won't get your charts to look good. And unfortunately OFC is not too easy to work with.

OFC documentation is PHP-centric. For other environments, there are support forums but not much more. To use .NET you can compile the shipped .NET library or use an alternative one.
Unlike FCF, OFC has only flash binary, open-flash-chart.swf. Chart type is defined in the JSON-formatted data file. Compared to jQuery plugins, this JSON it is quite complicated to create manually. Good thing is that there are server-side libraries to create OFC charts that handle the conversion to JSON. But you still need to use javascript to pass the data to the chart. This is not as simple as passing XML data directly to the flash object parameters, as in FCF. You need Firebug to debug things, tolerate Firebug/Firefox crashes etc.
The default .NET API acts as a JSON wrapper class and is not nearly as simple as in FCF. The bad thing is that this abstraction leaks, you can't control every setting in JSON with the .NET API, or at least you have to spend a lot of time finding out how to achieve this.
One particular annoyance was that OFC dates use PHP mktime() ticks, that are otherwise the same as Unix/Javascript ticks but are counted in seconds instead of milliseconds.
My first impression was that OFC is hard. I wouldn't let my boss use it.
ASP.NET
It should be noted that the RIA controls I tested are free or open source but the ASP.NET chart controls are commercial products, usually shipped inside a larger toolkit. The controls are well productized and strive for high user productivity while offering the maximum feature set. This is not easy to achieve, and therefore it is important to support the user when the inevitable troubles arise. Money does not buy you a solution to every business charting case, but it does buy you many well-supported scenarios.
Technology
ASP.NET charts are technically using the same client-side web platform as the jQuery charts. In practice, there are probably quite a few constraints in developing a generic .NET chart control that do not exist in pure Javascript development. I wouldn't expect ASP.NET charts to visually match the best Javascript ones. But at least it would be nice to have some interactive features and animations, which are mostly missing now.
Rich data access is the strongest point of ASP.NET controls. You can use native ADO.NET data structures directly instead of serializing to JSON or XML. Another .NET advantage is that the chart controls are usually built as generic all-in-one charting solution for both ASP.NET and WinForms. The same chart control is also used in the vendor's reporting solution which can be useful.
Developer experience
Visual Studio IDE and the .NET tooling support in general are great, sure, but the focus here is on the usability of chart controls. Commercial server-side chart controls typically have lots of features and the learning curve can be steep. In the best case you have decent Visual Studio design-time support, which is intended to work like WYSIWYG for UI programming. In practice this means property grids to make settings and some visual output on how these settings affect the chart. But if you can't get design-time support to work, you'll only see the IntelliSense code comments and external documentation while coding, and the final outcome is visible only in the browser.
Generally, getting an example chart up and running takes more effort in ASP.NET than with jQuery plugins or Flash charts, because you have to set up a IIS web application and prepare an aspx page, a code behind file and a web.config. Development and testing cycle is slowed down by the time it takes to compile the solution and reload the ASP.NET site. Reloading is particularly slow if you have lots of dlls in the /bin folder. But again, this same reload happens when using a Flash chart .NET API, or when doing server-side .NET data access with any front-end charting tool.
I don't like the ASP.NET heavy lifting needed to draw a few charts. But if your boss is an ASP.NET developer, and you provide the environment and a few samples, things should be ok.
XtraCharts
XtraCharts is a part of the DevXpress toolkit. Deployment requires 16mb of DLLs to be loaded in every application restart, only for charting. That's heavy and takes a few seconds in your dev machine.
Demos are nice, I liked the spline plot, but as you can see, the chart is a .png image, which prevents any cool animations or mouseover interactions inside the chart. Outside the chart image you can have tooltips as in the "Weather in London" chart.
For some reason, I couldn't get the Visual Studio designer support work in a DotNetNuke module project. The designer showed an error:

Probably some setting is wrong as I was developing in a Visual Basic project. Working manually with the code-behind file is fine with me, but the bad thing was that I already faced a problem after a few iterations of the pie chart. Below is the chart with labels but no legend:
Issues like this arise in every complex control, but debugging them makes you appreciate the fast develop/test cycle of the client-side tools.Telerik Charting
I have used Telerik RadChart previously with Telerik Reporting, and my perception was kind of lukewarm then. But I should have more perspective now.
First the good news. Designer support for Telerik Charting works pretty well, even though the property grid is hard to use when fine-tuning the chart. WYSIWYG works even in the data level: you can put data items in the aspx, and they show directly in the designer, as pictured below!
Having data in aspx also means that you need not to do anything in the code-behind to get a working report. But frankly, I don't find any use for data-in-aspx other than simple demos.
Compared to XtraCharts, some useful chart types are missing, or they don't look as good. For example, a line plot demo has labels but not visible data points. XtraChart demos are more complete, easier to navigate and better-looking than their Telerik counterparts, but the difference is not big. Both tools produce static image-based charts that support only image map interactivity, zooming support in Telerik line charts being an exception. It should be noted that Telerik also offers Silverlight charts that are on par with Flash with respect to pizzazz.
And then the bad news. I couldn't get the Telerik charts working at all in the browser. All that I got was an error message:
BC30560: 'ChartSeriesType' is ambiguous in the namespace 'Telerik.Charting'
Normally, I would debug for an undefined time to get some results. But this time I have to call it off. No more ASP.NET debugging today.
Final words
Programming is a profession of solving real-world problems with tools that are built to look great in demos. But you shouldn't blame the tool if you can't ever achieve the same results in the same time on your own, no matter how much you spend time debugging with the tool. This is the reality. But sometimes you do get positively surprised by a development tool that just works as promised. FusionCharts Free is such a product. The people who designed and implemented it five-to-ten years ago have done a hell of a job. Thank you!
I chose Fusion Charts Free for our company, and it is probable that we upgrade to the latest commercial version in the future. FCF has the looks, simplicity and support required for a business where charting is a nice-to-have but not a critical feature. A great thing is that FCF with inline dataXML data and no mandatory javascript is a fool-proof charting environment that is safe for your boss too.
Open Flash Charts was the runner-up, entirely because of its looks, but it is too complicated for occasional use. If I was doing serious charting I would compare OFC more carefully with the commercial version of Fusion Charts.
jQuery plugins are promising, but so far they are fit for only lightweight charting tasks, mostly because they lack features. Javascript is still not for everyone, but for javascript-savvy programmers the developer experience is extremely productive, until you hit any edge cases.
It makes sense to use .NET chart controls if you can piggyback some of the work you have done with the other controls in Telerik or DevXpress toolkits. Or if you are doing WinForms charts too. But as standalone web charting tool, RIA charts are better.
-mika-








