Dygraphs: Better Time Series Graphs(danvk.org)
danvk.org
Dygraphs: Better Time Series Graphs
http://www.danvk.org/dygraphs/
12 comments
Very impressive. Drop kicking my flash charts in the next release. Between Dygraph, High Charts and Cartographer.js there's no reason to use Flash: http://bit.ly/8Yksg4 http://bit.ly/8kAgAu http://bit.ly/2quRUs
Actual links instead of <censored> redirection:
http://www.danvk.org/dygraphs/
http://www.highcharts.com/
http://cartographer.visualmotive.com/
http://www.danvk.org/dygraphs/
http://www.highcharts.com/
http://cartographer.visualmotive.com/
Ah, thanks - I pasted from a tweet.
Dygraph is very pretty but if you have a significant percentage of users on IE I'd definitely double and triple check the performance first.
As I mentioned below, the sample chart is very choppy on IE8 (although it's wonderful on Safari, FF and Chrome).
As I mentioned below, the sample chart is very choppy on IE8 (although it's wonderful on Safari, FF and Chrome).
I've actually been pleasantly surprised by the performance of dygraphs under excanvas. The zoom interaction looks a bit funky, but it does work. The highlighting is fairly smooth on the machines I've tested.
I'm using FF 3.5 on a Core 2 Duo laptop and running my mouse across the graph back and forth uses an entire core. Behold, the power of javascript!
And also don't forget Protovis: http://vis.stanford.edu/protovis/
Thanks, that shoulda been in the list.
Also check out http://raphaeljs.com and http://g.raphaeljs.com
I love this landing page. Excellent marketing for an open source project. Demos and documentation right up front. Lots of information on the home page, but it all loads quickly, easy to scan.
I've been using this for awhile for some non-public stuff, full disclosure: I also helped dan write a little bit of the code.
The error bars and the ability to adjust the moving average "period" are pretty useful features for some specific use cases, and I haven't seen these in other similar libraries.
The error bars and the ability to adjust the moving average "period" are pretty useful features for some specific use cases, and I haven't seen these in other similar libraries.
It's very nice!
An interface suggestion for you or Dan: make zoom in/out more discoverable. I've used other packages with this style of zoom interface, so I know there's precedent and some people will figure it out. But newcomers will be lost.
An interface suggestion for you or Dan: make zoom in/out more discoverable. I've used other packages with this style of zoom interface, so I know there's precedent and some people will figure it out. But newcomers will be lost.
Agreed -- I typically add a note about this above the dygraph, but this is not ideal. Most people skim right over this bit at the top of the page and look right at the chart: "(Mouse over to highlight individual values. Click and drag to zoom. Double-click to zoom back out. Change the number and hit enter to adjust the averaging period.)"
Dygraphs claims to work in IE, but I just tested the link with my IE6 test setup and got so many errors I had to kill the process. Perhaps it's just their page.. Anyone know if it really supports IE? (I'm aware excanvas is required).
[edit] As an addendum, it's nice to see this library hosted on github where myself and others have a chance to easily contribute changes and patches, mix/match/etc each others forks and such. I really wanted to see changes and contributions to the Flot library flow a bit faster (eg: there's a bug in series drop shadows that's had a patch on the mailing list for over a month with no interest from the maintainers in fixing it). I've asked the project owners if they'd be willing to move from Google Code to github to allow for more this, but got a reply implying that most users of Flot are not sophisticated enough to contribute. Darn..
[edit] As an addendum, it's nice to see this library hosted on github where myself and others have a chance to easily contribute changes and patches, mix/match/etc each others forks and such. I really wanted to see changes and contributions to the Flot library flow a bit faster (eg: there's a bug in series drop shadows that's had a patch on the mailing list for over a month with no interest from the maintainers in fixing it). I've asked the project owners if they'd be willing to move from Google Code to github to allow for more this, but got a reply implying that most users of Flot are not sophisticated enough to contribute. Darn..
I'm still not sold on Github being the actual solution here -I think that it happens to be where a great deal of functional communities have formed, but I've also seen a ton of projects that are a total disaster. When an "upstream" owner doesn't take patches, the usual result is that there's complete chaos and mutually incompatible forks with the same name and version information spring up.
Functional communities can and do exist without Github. In fact, I find patch review on maillists to still be a lot easier than on most of the new DVCS-centric hosting sites.
Also, perhaps the best thing is to be less shy about offering patches? I've had pretty good luck with just spamming someone with my patches and saying "here you go, thought you might like this." Some don't ever provide feedback or take the patch, but those are far and away the exception to the rule.
Functional communities can and do exist without Github. In fact, I find patch review on maillists to still be a lot easier than on most of the new DVCS-centric hosting sites.
Also, perhaps the best thing is to be less shy about offering patches? I've had pretty good luck with just spamming someone with my patches and saying "here you go, thought you might like this." Some don't ever provide feedback or take the patch, but those are far and away the exception to the rule.
When an "upstream" owner doesn't take patches, the usual result is that there's complete chaos and mutually incompatible forks with the same name and version information spring up.
If the upstream owner doesn't accept patches the project is hosed, regardless of how it's hosted.
The big difference with a DVCS is that those chaotic forks are public and can themselves accept patches. Developers can still pool their bug fixes, added features, etc., and perhaps the project can rise from the ashes.
If the project is hosted on a centralized VCS, all of those bug fixes and new features languish as one-off forks in private repositories. Instead of being a chaotic mess, it's moribund. You still have the same issue of having to maintain your own fork; you just don't have any help in doing so.
If the upstream owner doesn't accept patches the project is hosed, regardless of how it's hosted.
The big difference with a DVCS is that those chaotic forks are public and can themselves accept patches. Developers can still pool their bug fixes, added features, etc., and perhaps the project can rise from the ashes.
If the project is hosted on a centralized VCS, all of those bug fixes and new features languish as one-off forks in private repositories. Instead of being a chaotic mess, it's moribund. You still have the same issue of having to maintain your own fork; you just don't have any help in doing so.
Thanks for articulating it better than I could have.
This is exactly my sentiment. There's been over the last two years an occasional sense that the Flot guys have held the project hostage in some ways because for a long time it was the only viable library that did things the "jQuery way" with a sufficient number of fixes to remain stable on IE.
Late into the project (where they stand now), it sucks to see important patches languish because the maintainers aren't vigilant or have more important things to attend to. The fact remains, visualization is now a fairly important component for a fair number of people who are working on data/analytics applications. It's easy for people to bandy about anecdotes of other projects or maintainers which do well on mailing lists and non-DVCSes .. but in this case it's not working terribly well for the Flot guys.
So technical merits aside, this is why people might wander away from Flot and to projects like Dygraphs, beta warts and all, all because of issues not relating directly to code. Github may not be a panacea but when you see people like John Resig saying stuff like "I'm loving the influx of new contributors to jQuery core since moving to Github.", it must mean they're doing something incrementally better :)
It's time for project owners to ease up on the reigns a bit, and I'm pleased to see more and more interesting projects hosted on github for this reason.
This is exactly my sentiment. There's been over the last two years an occasional sense that the Flot guys have held the project hostage in some ways because for a long time it was the only viable library that did things the "jQuery way" with a sufficient number of fixes to remain stable on IE.
Late into the project (where they stand now), it sucks to see important patches languish because the maintainers aren't vigilant or have more important things to attend to. The fact remains, visualization is now a fairly important component for a fair number of people who are working on data/analytics applications. It's easy for people to bandy about anecdotes of other projects or maintainers which do well on mailing lists and non-DVCSes .. but in this case it's not working terribly well for the Flot guys.
So technical merits aside, this is why people might wander away from Flot and to projects like Dygraphs, beta warts and all, all because of issues not relating directly to code. Github may not be a panacea but when you see people like John Resig saying stuff like "I'm loving the influx of new contributors to jQuery core since moving to Github.", it must mean they're doing something incrementally better :)
It's time for project owners to ease up on the reigns a bit, and I'm pleased to see more and more interesting projects hosted on github for this reason.
That page did render correctly in IE6 as of a few days ago. I'll have to dig in and figure out where the bug is.
If you click on some of the links under "Gallery", you'll see that they do work in IE6. The main documentation page is particularly difficult to render, since it contains so many Dygraphs.
If you click on some of the links under "Gallery", you'll see that they do work in IE6. The main documentation page is particularly difficult to render, since it contains so many Dygraphs.
Flot is still my favorite JS charting library. http://code.google.com/p/flot/
A time series example - http://people.iola.dk/olau/flot/examples/time.html
A time series example - http://people.iola.dk/olau/flot/examples/time.html
This seems very impressive to me! I've been looking for something like this for a long time, but I'm a total idiot at javascript.
What are the competing libraries, and how do they compare?
What are the competing libraries, and how do they compare?
SIMILE Timeplot is the biggest one I know of
http://www.simile-widgets.org/timeplot/
We use it in our metrics site. Doesn't look quite as nice as this, and we had to hack in zooming / drag range selection and a few other things.
I'm certainly interested in evaluating replacing it with this.
The biggest thing we have with Timeplot that I don't see here are event markers. On the demo page linked above, if you click on one of those pink areas, you'll get a little popout that you can use to display useful information about a particular event point or range.
We use it in our metrics site. Doesn't look quite as nice as this, and we had to hack in zooming / drag range selection and a few other things.
I'm certainly interested in evaluating replacing it with this.
The biggest thing we have with Timeplot that I don't see here are event markers. On the demo page linked above, if you click on one of those pink areas, you'll get a little popout that you can use to display useful information about a particular event point or range.
Flot isn't really targeted to time series data but it works pretty well in our uses.
Another one that I recently saw (on hacker news) was http://www.highcharts.com/ - but dygraph renders much faster, you can actually watch the highcharts library draw as if it was animated.
Know of a good <canvas> implementation that runs at the server and generates an image resource? Otherwise this doesn't appear to be usable as a progressive enhancement. In fact the demo renders nothing whatsoever unless you trust their javascript.
this is excellent. i was immediately able to integrate dygraph with my firefox extension.
thx for the docs!! (i'm also using g.raphaeljs.com for pie and dot charts....could definitely use some docs there)
a couple features that would be cool, in order of priority:
* log scale * date format * pan (and more obvious zoom controls. cursor changes to pointer over graph...still not clear how to zoom out, though) * more than 2 lines (right? i can't make more than 2 lines show up)
keep it up!!
thx for the docs!! (i'm also using g.raphaeljs.com for pie and dot charts....could definitely use some docs there)
a couple features that would be cool, in order of priority:
* log scale * date format * pan (and more obvious zoom controls. cursor changes to pointer over graph...still not clear how to zoom out, though) * more than 2 lines (right? i can't make more than 2 lines show up)
keep it up!!
Thanks!
* log scale: agreed, there's an open feature request for this. Feel free to star it if you want to follow along: http://code.google.com/p/dygraphs/issues/detail?id=15
* date format: You can actually do this now via the "xValueFormatter" attribute. You pass in a function to format the date. It's undocumented, though. I should fix that.
* pan: agreed, see http://code.google.com/p/dygraphs/issues/detail?id=7
* more than two lines: dygraphs can certainly do this. I've tested it with at least 7 and there's no reason it couldn't handle more.
* log scale: agreed, there's an open feature request for this. Feel free to star it if you want to follow along: http://code.google.com/p/dygraphs/issues/detail?id=15
* date format: You can actually do this now via the "xValueFormatter" attribute. You pass in a function to format the date. It's undocumented, though. I should fix that.
* pan: agreed, see http://code.google.com/p/dygraphs/issues/detail?id=7
* more than two lines: dygraphs can certainly do this. I've tested it with at least 7 and there's no reason it couldn't handle more.
Very nice work. Good to see some graphs clearly presenting the data rather than obfuscating it with flash.
Google maps style mousewheel zooming in/out would be nice.
Double clicking to zoom out took me a while to discover.
Otherwise excellent
Double clicking to zoom out took me a while to discover.
Otherwise excellent
I am confused by this graph. It never gets warmer than 70 in San Francisco?
If you take the averaging period down to 1 (box in the lower left), then the center line is the average temperature for each day. The top of the shaded region is the high for that day. If you zoom in on, say, 2008-05-15, you can see that the high was over 100 degrees that day.
In general, though, temperatures in SF rarely go above 80. When they do, it's newsworthy.
In general, though, temperatures in SF rarely go above 80. When they do, it's newsworthy.
Ya I thought the same thing.
Using a 14-day moving average makes it clearer. A 100-day rolling period averages out nearly all the specifics from the data.
You can change the moving average - it's in the bottom left corner of the graph.
Using a 14-day moving average makes it clearer. A 100-day rolling period averages out nearly all the specifics from the data.
You can change the moving average - it's in the bottom left corner of the graph.
[deleted]
Periods of hot weather in SF typically last 3 days.
It's entirely feasible that it didn't go above 70 in SF for a year. SF is not LA.
The historical data presented in the graph shows more variance.
The historical data presented in the graph shows more variance.