Subreption blog

Fri, 07 Dec 2007

CMS Series: Web charting and graphing libraries

We said we would roll out articles about our (Rails) Content Management System project and this is one of the very first, exposing our difficulties and decisions about deploying an usable, yet fancy charting functionality.

We won't spoil the surprise about the name of the project, yet. :)

The Quest

Finding a free, open source and (if possible) BSD or LGPL licensed library implementing chart and graphing functionality. We want to avoid licensing hell as much as we want to avoid bloated interfaces that obscure the statistical data more than abstracting it properly.

Requirements

Capable of displaying technically complex data sets.
Good performance: it must escalate well! (as much as we designed our product to do so).
1. Efficient cache and server-side solution or browser supported implementation (ie. SVG based).
Non-bloated, elegant code: we want to modify it and understand what's going on.
Usable, simplistic interface (API): we hate working with an over complicated API.
Nice, fancy, yet-not overly design-ish graphs:
1. Experience shows that complicated graphs do nothing to improve the visibility of statistical data: better divide by many, than squeeze many in a few.
2. Simple graphs and clean shapes are far more smooth and pleasing to the eye (Isn't the whole rounded corner spice about this anyway?).
3. The more complex the data-set, the more simple a graph should be. The density of data displayed will be high and adding unnecessary fuss will just get in way of interpreting it properly.
Non-hosted solution: we can't afford the risk of exposing customer or sensitive information to external hosts and services. We could do exceptions for publicly obtained data, but definitely not the internal information.

The Candidates

Google Chart API (recently seen at Ajaxian)
- Hosted solution :(
- Extremely efficient (and nice looking).
- Limited to 50000 calls to their API per-day.
Yahoo! UI (YUI) Charts control
- Component of the BSD licensed YUI library.
- Flash and JavaScript hybrid.
- Scales pretty well!
Dojo Charting Engine
- It's Dojo. That already turns heads.
- But the last time we used Dojo it was extremely memory hungry and a hell to scale for our particular needs. :(
PlotKit
- BSD Licensed, thanks to its author: Alastair Tse.
- Requires MochiKit.
- Can use either SVG or HTML CANVAS.
Plotr
- BSD Licensed, thanks to its author: Bas Wenneker.
- Partially based on PlotKit, except that it uses Prototype instead of MochiKit.
Flot
- Uses jQuery: we really like that library, it's feature-rich and it's used extensively.
- MIT licensed, draws some ideas and work from previously mentioned libraries.
- Clean, lean style!
Gruff: the Ruby way
- Depends on RMagick (which in turn depends on ImageMagick!)... we dislike adding further dependencies to our software.
- You can generate image blobs on demand, in the desired format (ie. PNG).
- For high performance, requires proper cache solution.
- Its author also developed Sparklines.

We haven't considered other commercial and open-source alternatives, simply because we didn't believe they fit our requirements upfront. But we might be wrong. Two of them are FusionCharts (commercial and Flash-based) and Open Flash Chart (Flash too, but open source). The latter seems nice but we don't have that much time to dive into its details. For PHP we have JpGraph, which is damn flexible.

Google Chart API

The quality of the charts is certainly good, with a clean API, easy to use and impressively fast response (it's evident that Google has resources to support it). The only problem we have is the limitation of 50000 API calls per-user. This might be tied to IP or accounts, and most likely using multiple ones to bypass the limit will get your access terminated. A solution to this problem is caching and limiting the requests, redirecting them to locally mirrored files if the information is recent enough or we have reached the API calls limit. While this works perfectly, it's not optimal for a commercial application.

PlotKit

The quick start guide shows a handful examples. The API makes use of a Layout and a Renderer that generates and inserts the chart in to the page content (using MochiKit), with a simplistic approach for introducing data-sets.

function drawGraph() {
    var layout = new PlotKit.Layout("bar", {});
    layout.addDataset("sqrt", [[0, 0], [1, 1], [2, 1.414], [3, 1.73], [4, 2]]);
    layout.evaluate();
    var canvas = MochiKit.DOM.getElement("graph");
    var plotter = new PlotKit.SweetCanvasRenderer(canvas, layout, {});
    plotter.render();
}
MochiKit.DOM.addLoadEvent(drawGraph);

The main disadvantage is that SVG and HTML CANVAS support have certain compatibility issues across different browsers and many still need to mature their support for such functionality. This leaves a huge surface of potential interoperability problems which might be a serious show-stopper when deploying PlotKit.

Dojo Charting

The feature-rich Dojo toolkit provides a neat charting library, supporting multiple charts per drawing area (or PlotArea). The data-set can be bound to a Store object (similar to the DataSource object of the YUI library), plus it supports all browsers except WebKit powered ones (those pesky Safari users! :) ). Some data analysis methods have been implemented too...

The usage is easy and documentation is very complete (something common with Dojo, probably due to its user base and support from several sponsors):

dojo.require("dojox.charting.widget.Chart2D");
dojo.require("dojox.charting.themes.PlotKit.orange");
dojo.require("dojox.charting.themes.PlotKit.blue");
dojo.require("dojox.charting.themes.PlotKit.green");
dojo.require("dojox.data.HtmlTableStore");

seriesB = [2.6, 1.8, 2, 1, 1.4, 0.7, 2];
dojo.require("dojo.parser");	// scan page for widgets and instantiate them

Note how HtmlTableStore is used and the Parser component. Within the HTML source:

<div dojoType="dojox.data.HtmlTableStore" tableId="tableExample" jsId="tableStore"></div>
<table id="tableExample" style="display: none;">
	<thead>
		<tr><th>value</th></tr>
	</thead>
	<tbody>
		<tr><td>6.3</td></tr>
		<tr><td>1.8</td></tr>

If there's something we appreciate from Dojo, it's the flexibility we enjoy from using it. You can certainly keep Dojo in mind for your charting (and several other UI) related needs. Regarding Internet Explorer support, as far as we know, several libraries make use of emulation for setting up HTML CANVAS support through VML.

Yahoo! UI (YUI) Charts Control

The amazing YUI library provides an experimental (as of version 2.4.0) Charts control with a nice API. The best thing about it: polling data from a DataSource object is supported. That means dynamic charts, easy interoperability and good performance. Rendering the charts is a piece of cake:

var mychart = new YAHOO.widget.LineChart( "chart", myDataSource,
{
	xField: "month",
	series: seriesDef,
	yAxis: currencyAxis,
	dataTipFunction: "getDataTipText"
});

YUI continues to impress us everyday. Since it uses Flash for rendering the charts, any browser with the Flash Player plugin will be able to render them. Also, the Flash charts can contain interactive labels and other useful details. This is clearly a winner in our books (and Dojo is always noteworthy too, but we can't afford using two toolkits since load times will skyrocket).

Published on: Fri, 07 Dec 2007. | Path: /web/libraries | Permalink

Thu, 06 Dec 2007

Annoyances of YUI when using custom styles

We've been coming across different annoyances in our quest of deploying YUI into one of our main products (a few more articles talking about its development coming soon), the Ruby on Rails content management system behind our almost-ready customer portal and corporate site. The problem comes mainly from the coexistence of our custom CSS and JavaScript code, and the YUI specific style-sheets and library files.

TabView control is rendering the tabs with an incorrect height: possibly caused by style conflicts, but we have confirmed this is not the case (at least our CSS is consistent and not conflicting with YUI).
Editor component is unable to adjust its size to a sensible default (in other words: it seems unable to match approximately the old size of the barebones textarea element).
YUILoader is not liking our layout and failed to expose the YAHOO.widget objects properly. Thus we couldn't make any real use of it without resorting to Event driven functions and slow transitions (as unpleasing as watching a textarea transform into the Editor UI in �real time� :( ).

The problems are really bugging us and we have considered moving to fully custom code, even if that means delaying the development of some other features that might be of higher priority. Hopefully we will solve the issues soon and keep YUI in place, since the functionality is really complete.

Rich Text Editor doesn�t readjust its size�

Published on: Thu, 06 Dec 2007. | Path: /web/libraries | Permalink

Wed, 05 Dec 2007

New Yahoo! UI (YUI) library release! (2.4.0)

Yahoo! released yesterday a new version of the feature-rich, BSD licensed YUI (the Yahoo! User Interface library) implementing several improvements, some new controls and other innovative functionality. The components that quickly turned heads over here, are namely:

The charts control: finally we get those infamous pie charts for free (requires Flash like most of the web chart and graphing tools, but its quality is certainly higher than some of the competitors)
Improved performance for the rich text editor: apparently now you can select its components in a fine-grained manner, avoiding load of unnecessary functions
New fanciness for the button control...
Hell of a load of fixes, ranging from browser specific issues and compatibility changes

Their change-log contains a complete overview of the fixes and the new features. We are integrating this new release for the (Ruby on Rails powered) content management system engine we have developed for our corporate site, and recommend YUI for any serious web developer seeking a library providing solid controls and functionality. Besides, it comes with no strings attached.

Published on: Wed, 05 Dec 2007. | Path: /web/libraries | Permalink