NVD3.js: re-usable charts for d3.js
novus.github.com
novus.github.com
Chrome Frame works well though!
"As you guys can probably tell, I'm still in a very early stage of development. But, with that said, we're gonna be jumping the gun and making all of the models production ready very soon, so will be taking care of bugs left and right.
Still working out all the common features between the models. Will be making things more customize able as I go. Hopefully in the next day or two will implement a "values" accessor so you can use some slightly different data formats without issues.
I definitely want to hear what people are looking for and what they would do differently, I'll do my best to balance my needs with everyone else's."
(My particular sunny day wish list is for live & historical scientific strip chart style data logging: flexible date support, intuitive horizontal timeline dragging & zooming, live updating, line charts with gaps in them, rendering largish datasets (especially in a drill-down style), and logarithmic axes - especially if you can mix them with linear axes.)
Highcharts is very nice, but commercial (although there's a free license for non-commerical work available). I settled on flot eventually because it has a reasonably complete set of features, easy API, and there are lots of plugins available to complete all the features I wanted to have. A lot of the newer frameworks are less complete (for now, anway).
That said, I've admired D3 for a long time, it just didn't have a good basic time-series chart wrapper to help a JS newbie like me jump in. Rickshaw's a good start at that, but missing some features I need, like multiple Y-axes. A D3-based library is attractive, because I also want to integrate Cubism.js's horizon charts, and keeping them on the same rendering engine will cut down code size and be nicely consistent.
I did notice that browser performance at rendering SVG is still noticeably behind Canvas when you have lots of complex graphs on screen at once. The Rickshaw implementation of my dashboard (Rickshaw uses D3) slowed down considerably on my MacBook Air compaired to the flot version.
Cubism, D3, and now NVD3 are still very much in the running for v2 of my dashboard project.
I'm normally a server guy, but needed a good dashboard for our OpenTSDB metrics project, so I started diving into client-side JS -- going whole-hog on d3 without a good chart lib on top of it seemed to be a bit too steep of a learning curve. But I do love the possibility of open-ended charts, where we can dip into the power of d3 at will when we need something more custom.
Like DiabloD3 commented below, I feel like doing an end-zone victory dance :). Nice work.
However the performance of these graphs is currently too slow for me. When I hover my mouse over a line the response is very stuttery while flot and highcharts are smooth as silk.
All of these stutter sometimes, especially if you are moving your mouse to a point and happen to trigger a few other events on the way.
Firefox 13.0, Kubuntu 10.04 Intel Xeon CPU X3450 @ 2.67GHz 4 core 16GB RAM
Let me know if you guys have any questions and/or feature requests. If I like the feature, I will implement it right away.. or if its a very bug feature, I'll at least put it in the TODO list.
Also would love to hear things people don't like about the library... that will be much more useful than what people like. No promises that I'll listen.. but I'll try to.
[1] seems to have a bug. When you disable a particular line by clicking it on the graph legend, if you attempt to disable another line you end up re-enabling the first one.
Let's say I play around with some series A, B, C and D. I disable all except B and then realize that I want to see only A instead. So now I have two options, that IMO should lead to the same final state: I can either disable B and enable A, or enable A and disable B. In current implementation, the first option leads to re-enabling all series, while second option leads to desired state of having only series A visible. Now one of those two proposed actions may seem redundant until you realize that the choice between them depends on subconsciously analyzed things like mouse position ("is my mouse closer to series A or series B?") and having both available would, in my opinion, help in keeping user in the flow.
I understand it's only a minor issue. Current implemetation is more complex in philosophical sense that it does Surprising Magic instead of the Obvious Thing, and that bugs me just a little.
Or maybe I'm just whining because I got used to how HighCharts.js does this. ;).
Like you said, you're jsut used to high charts.... by no means was this project designed after high charts (in fact haven;t looked at high charts in over a year). Working off of d3 examples, Tufte principles, and whatever my gut decides makes sense at the time.
If a user has 10 series, and disables all but 1 to look at it and then decide to look at another in isolation, he would, in his naivety as a user, perhaps disable the one he's looking at before enabling the one he wishes to look at. After-all, he's looking at one at a time, so having two on at once could seem wrong to him for his current process. Disabling that one isn't disabled, nor does it blank the chart. Instead it does something completely unexpected, and is in no way predictable. It enables all 10 series again.
If you're designing a charting library that you want to be usable then it should follow user expectation. And no user will expect that turning off all series will in fact re-enable them all. It would make more sense to disable turning off all the series and requiring one on at any one time.
I get that it's just a demo though, not behaviour the end developer has to put in their app. It's a really nice set of demos overall. :)
Of course people are always welcome to contribute some new models, and I'll do my best to keep them consistent with everything else.