I was particularly pleased with the way nvd3 supports sliding data off line charts without any extra work.
D3.js is an excellent, low level visualization library. But you will find yourself spending days to a couple weeks with custom styling, tooltips, legends, etc. Many high level charting libraries are nice because they have this out of the box.
However, I want a library that lets me make visualizations that I can run on my monitor for 10 days straight without running into obscure bugs. Rickshaw failed me in this regard. I have a caching scheme in my client-side application. Rickshaw has its own local copy of data which requires the developer to write custom, messy javascript to evict. I found that rickshaw actually has some custom 'sliding window' logic. I was unhappy because I had to go to stackoverflow to discover that feature rather than using the documentation.
nvd3.js simply worked for me.
> rickshaw actually has some custom 'sliding window' logic.
> I was unhappy because I had to go to stackoverflow to
> discover that feature
The rickshaw docs are heavy on usage, light on specification. That's a style I very much appreciate, but I also appreciate that it's not for everyone.
I also appreciate that its API doesn't make you take the range slider with you, if you don't want it. It's all additive, and you can go both directions (keep adding bits and blobs to the interface via plugins, or reach down into the D3 and SVG bits, or your data. Nothing is opaque there.)
What was your obscure bug with a long running Rickshaw? I have long running sliding window time series stuff that I typically run for as long as a Chrome release lasts, and it stays snappy.
0: http://code.shutterstock.com/rickshaw/examples/extensions.ht...
I like how cubism visualizes streams of data where each needs its own Y-axis but they are related on the X axis (usually a time domain.) However cubism's mechanism of updating is sort of weird, and each value needs to be one pixel. I tried to use d3's "streams" example but quickly got lost there.
On another note, I've had good luck using Rickshaw and updating the `graph.series[i].data` array using shift and push then re-calling `graph.render()`. This is what Rickshaw's `FixedDuration` appears to do under the covers (see source of this example http://code.shutterstock.com/rickshaw/examples/fixed.html) - but I don't actually use FixedDuration, just update the data array.
Default bar/column chart settings occasionally give mystifying results, like the highest value in the chart plotting above the highest axis value (e.g. 23,600 plots above 22,000 instead of between 22-24k).
I'm sure we'll solve these issues, but they are eating up a bit of developer time for things we're used to having work out-of-the-box in something like Excel.
Here's an example from a Datadog dashboard: https://cloud.githubusercontent.com/assets/1189716/4064956/6...
I wish such a chart style was more common, it's so much more useful than a typical line chart of the median/p9x. Unfortunately, I'm not familiar enough with D3 and such to write my own; it would likely be crap.
http://bl.ocks.org/mbostock/4060606 http://www.trulia.com/trends/2011/09/house-hunter-by-day-not... http://prcweb.co.uk/circularheatchart/ http://bl.ocks.org/tjdecke/5558084
Heck if you point me to a stock dataset I could probably code up a simple example that you could tweak. (no promises though ;)
We also have the notion of "interactors" which allow you to add draggable widgets to a plot: http://ncnr.nist.gov/instruments/magik/calculators/calcR_wf....
To see the heatmap in action, you can look at: http://ncnr.nist.gov/ipeek/singleplotwindow.html?instrument=...
There are of course glitches, but hopefully you find some of this useful!
I think it's d3.scale.color to automatically set up a gradient you plug a value into and get a color out.
http://bost.ocks.org/mike/chart/
"To sum up: implement charts as closures with getter-setter methods. Conveniently, this is the same pattern used by D3’s other reusable objects, including scales, layouts, shapes, axes, etc."
You get none of that with C3.js...
I have been watching closely different library, and felt that most of the library are just providing default value to d3.js, plus adding some nice plug-in (such as tooltips). If we are looking for a bar chart, then it's very fast to use a bar chart library to build what we want. Yet some problems may occur:
1. Control, we thought that we need bar chart, but we actually need bar chart’. In my process of developing effective visual, I often need to access different part of the API.
2. Choice, currents charts provided by most of the library are available in Google Charts and Excel. This might a question of time: these library are fairly new, and maybe in the near future these library will provide all visualization available in the d3.js page. But maybe it’s not because of time, but of complexity. If these library were providing better abstraction, it should be easier to develop more complex charts.
3. Extendability: We probably don't just need the bar-chart as a stand alone visual, but as building block that can interact with other component (texts or maps).
An interesting question is to ask why d3.js was designed so “low level”, why not directly releasing a “high level library”? My hypothesis is that maybe this is the right level of abstraction. When you tried to get “higher”, you actually lose power/control over your visual. Maybe that’s the reason why people are sharing a lot of their work on http://bost.ocks.org/, doing some small experiments, laying down some building block, perhaps currently that is the most efficient way of building re-usable chart.
I shared my thought on the issue, in hope that people challenge my hypothesis: my current work depends on it.
It is nice to have tool tips and other bells and whistles outbid the box though. I wonder if anybody has tried to do a more complex visualization (hierarchical bar chart for example) in one of these wrappers?
First find attempt I got 85 seconds Second 23 seconds Third 185
It was part of my initiative 30 days of d3.js, a pretty solid way to learn d3.js by the way.
If you (people in general) are using d3 for simple charts you are doing it wrong.
d3 is a visualization library. It excels at helping you make non-trivial things. For the trivial there are some great chart libraries such as Highcharts. I build visualizations at work and for those I use d3. Whenever I need something as simple as a stacked area chart I simply use Excel or Highcharts. Everytime I've tried to use Highcharts for a complex viz, or d3 for a simple chart, it's been a waste of time. I've used NVD3 as well as some other D3 based charting packages. None of them are as simple as Excel or Highcharts IMHO.
But they do have a lot of examples, a lot more than eg. nvd3.
I've been evaluating HighCharts, Vega, Rickshaw, NVD3, C3, but the one I've been impressed with in terms of performance thus far is Epoch: http://fastly.github.io/epoch/
My usual go to library: Flot http://www.flotcharts.org/
A charts library that has no dependecies (no d3, no jquery, etc), has a filesize of less than 100kb and still looks great and offers useful features would be awesome. SVG vs. Canvas2D is another hot topic.
Also, C3 is MIT licensed. I'm sure there are other differences as well.
Taking a quick search shows that it is actually called C2[1], from Keming Labs.
Since we wanted the set of charts to be driven by dynamic data, we were looking at either implementing functions to take a configuration object and translate that into a series of DC API calls, or switching to a charting library that already took configuration objects and hooking the charts together with Crossfilter ourselves.
The latter approach won out, largely because the C3 default look and feel was closer to what we wanted as well, compared to the DC defaults.
You can see it in action at: http://ncnr.nist.gov/ipeek/
We developed this to allow people to monitor experiments from the comfort of their hotel room. Our rates are relatively slow on most instruments (no faster than 1 pt/sec, where a pt may be effectively an image, or just a single datapoint).
Right now, we're not running, but it's fun to watch when it's updating.
If you want your reusable library to be adopted widely, you have to write good docs. I was hoping I could replace NVD3.js with C3.js but the docs are on par.
