Somebody has to really manage to make d3 run on 7<=IE<10. This is a powerful technology for businesses, it may even replace Power Point (the famous software for torture) for some things (especially those that are updated often since you still do this manually in PP). But it needs to run decently and painlessly in IE.
It would be great to actually figure out the steps required to make this happen. I'm not familiar with D3's code at all, but I know that it renders to SVG. Would it be possible to easily "plug in" Raphael's SVG/VML abstraction?
The problem with this is it is an abstraction, while d3 uses the DOM directly. In principle SVGweb ought to work, but again there seem to be issues in actually getting it to work. Fundamentally all these methods are much harder than it appears they ought to be at first glance, and several people have tried one or other of them and given up after varying amounts of success (I didn't stay at it long).
IE9+ right now. I'd attempt to get IE8 working, but would likely hinder me from using more advanced features of SVG and JS... so not sure if I will be attempting to get and IE less than 9 to work
I have implemented IE support for Protovis, D3's predecessor (https://github.com/DataMarket/protovis-msie). I have also examined doing similar things for D3 but decided it is a dead end. D3 could be patched to work with VML just as it does with SVG but it would mean maintaining all chart drivers in duplicate.
Bob's currently capped on commenting at the moment so I'll relay what he'd like to say:
"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."
Does anyone have any other recommendations for other interesting JS charting frameworks to evaluate? I'm using flot at the moment, I'm really keen to have a dig around in this now.
(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.)
I recently evaluated lots of them for a dashboard project, and settled on flot. I built alternate working implementations in Flotr2 and Rickshaw, and less thoroughly evaluated Dygraphs, Envision, RGraph, elycharts, grafico, AwesomeChartJS, Morris.js, and Highcharts.
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.
We were using flot when I started. As soon as I found out about protovis I redid all our charts (and boy was everyone happy with that improvement). Shortly after that, d3 came out, in which case I ported all the protovis charts to d3. NVD3 is my second go at a collection of charts for d3.js... it was re-done from the ground up, and hopefully is much more true to d3's style than my previous attempt.
I might have used protovis for my first iteration, if not for the fact that I discovered it just as d3 was introduced :)
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.
Yes, this framework. You can do all those things and much, much more using the d3 toolkit this is built on. It's a complex and powerful framework (and relatively low-level, which is why this was meta-framework was built, apparently). But if you invest some time learning it, you'll be able to use mold these components any way you wish.
Yup, trying to stick to the "d3 way" as much as possible. I need to work on some better examples, and maybe a tutorial or two. But you can always check out all the information on d3js.org, most of it should be very relevant.
I have a few internal dashboards built with DyGraphs (http://dygraphs.com/). It's useful for quick timecharts, but can be kind of obnoxious for anything more complicated.
They look great and we can never have enough cool JavaScript graphing technologies.
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.
This must be something to do with the way they've set the transitions up (i.e. they've built in some delay). I've had no performance problems with d3. Do you mean when the tooltip fades in or something else?
Chrome (and any webkit) performs pretty good IMO. Working on getting Firefox and IE9 up to speed. I will be allowing transitions to be disabled, which should help out a bit.
Tell me about it -- I've been waiting more someone to build a higher-level framework on top of d3. It's not a whole lot more than can be found in the d3 examples at the moment, but I can see this growing into an incredible toolkit, and one that can be customized at will using d3's power.
Anyone got any examples using NVD3.js or d2.js to render charts from constantly updating data? Like reading a websocket stream or query a json source every 2s and updating chart.
OK, I should be allowed to post again (At least I hope so).
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.
Very nice, I'll be definitely looking into it closer.
[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.
There's no point in keeping all series disabled, though I can imagine it being useful as an intermediate step.
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. ;).
Understandable, but not something I'll be implementing (though would be pretty easy to fork and edit.. that piece of code is VERY straight forward).. but would be too much of a pain in the ass to me, when the user could easily in A (after just having B enabled) then disable B.
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.
I would argue this has nothing to do with being used to highcharts and in fact is how a user would think. A chart library that follows anything from Edward Tufte should allow a user to make the chart as simple as they require it.
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 found this counter-intuitive as well, for the little it's worth. My intuition was "Wow, there's a lot of lines on this graph. I'll clear everything off and then add things one at a time to see how they compare. Click, click, click wait, what happened there?"
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. :)
This is great work and it's still early days. Looking forward to seeing the code clean up and having more extensible options for things like legends and fewer properties tightly coupled to chart instances.
Will be adding more and more models as I go... right now just taking care of what I need immediately for work. Really a can't wait till I get a chance to implement some of the more unique charts.
Of course people are always welcome to contribute some new models, and I'll do my best to keep them consistent with everything else.
