On Amazon, the cheapest available price is ~$55. For the second edition, which was printed in 2005 (and should be due to be free soon on Springer), it costs $132+
I'm often left frustrated with how much of the visualizations we make are simple in terms of graphical components yet because we mix their implementations unnecessarily in with the development environment (the DOM in d3's case). I think you are in the great position to be able to get consensus on something like that. I was thinking some more like a clean file format, runtime, and tooling for building reactive visualizations that can be reused, composed, and embedded into any environment by virtue of having a clean reference runtime that could be ported to many platforms: web, mobile, desktop, vr, and rich publishing/printing needs as well.
ps. I love how you've pulled out a smaller clean part here.
Also I think people greatly underestimate the synergy that comes from embracing (rather than abstracting) standards, in terms of the available documentation and tooling: the element inspector built-in to your browser, compatibility with external stylesheets, etc. D3’s success is likely due in part to its embracing web standards, for example using selections to manipulate the DOM (and SVG) rather than introducing a new graphical representation.
That said, for higher-level applications it might be desirable to abstract the representation. I just think people jump too quickly to generalize because they overlook the subtle features that make the underlying rendering systems good.
https://github.com/FormidableLabs/victory seems most promising, but isn't really d3, more "d3-like".
For example, you can use d3-scale to map from data to drawing coordinates, or straight to SVG path data (using d3-path/d3-shape). You can then easily render this to an inline SVG using React (or to some other backend using React libs like react-canvas and gl-react). Building the svg elements directly this way makes it easier to attach React event handlers to them, and gives you more fine grained control, rather than using off-the-shelf components.
Here's an example combining d3-shape and d3-scale with React and react-motion: https://jsbin.com/mehata/9/edit?js,output
I wired things up using a Flux-like architecture, where the Store would periodically signal a data change and the component would render it, transitions and all. It all worked out pretty much as I expected.
Do you know anybody who is working on this, English grammar visualization? And, if there are resources available on the web? What I need is an interactive tree visualization builder.
Any sentence can be parsed into its constituent parts. "You might find Stefanie Posavex's work inspiring" is a free standing grammatical sentence which is used as part of a larger sentence. It can be broken further conceptually into you might find something and Stefanie Posavex's work is inspiring. What I want to do is help students learn to take these last two sentences and mix them together with you and find into a meaningful larger sentence using interactive graphical visualizations.
A verb functioning as consider requiring two grammatical structures following it is one of a small number of ways a verb can behave. There are only a small handful of verbs that function as consider such as to think, to find, and to nickname.
I'm confused, why not? "English grammar visualization" is inherently an NLP problem. Both handwritten and statistically learned grammars are very large and therefore hard to visualize. I think it would be better to focus on a manageable language fragment. Some kind of interactive second language learning environment--but that probably already exists. What is it exactly that you want to do?
BTW: I wonder for how many people "graphing sentences" is an effective approach to language learning.
I reviewed the book a couple years ago and out of curiosity searched for one of the concepts online. There were only a small handful of search results and I think the author made up the word, the book is obscure. One of the results linked to an article on the IBM website written by one of the Watson engineers. I wrote him an email because I would imagine their engineers were using much more complicated concepts in linguistic research that a layman like my self would ever understand.
We were interested in two very different things. He is interested in helping a machine understand semantic meaning through grammatical structure while I'm interested in helping people understand semantic meaning through grammatical structure. Sure we are both using the same grammar book to parse a sentence. But how we are doing it is completely different. He is writing a program to do it and I'm writing a program to hold a child's hand while the child does it.
A sentence is a pattern of patterns. For the same reason Mike Bostock's work in visualization helps people understand patterns whether it is about the road to the White House or the road to the Super Bowl based on team salaries, visualization helps students with pattern recognition in their own writing.
d3-scale is just 18KB, great, but d3.min.js is 149KB and d3-scale relies on some more d3 addon JS files like d3-array, d3-color, etc. - so to sum up: 187KB minified JS for d3-scale including all dependecies, correct?
Tests have shown, the optimal goal is to keep a web app smaller than 300KB minified JS size.
So, yes. Making it easier for people to include only the code they are using is one of the motivations for breaking D3 up into separate modules (and adopting ES6 modules).
How is d3_scale different the scales included in vanilla d3? What is the motivation? Should I plan on trying to migrate my existing d3 apps to use these new modules?
First, it represents the 4.0 API, so it’s a preview of what “vanilla D3” will look like sometime next year when D3 4.0 is released.
Second, it’s a library you can use independently of the rest of D3. So if you don’t need the other parts of D3--for example you’re using React to manipulate the DOM, or you want to render charts to Canvas rather than SVG--then you can just use d3-scale (today).
Not all of the new D3 modules have been released; for example, I’m still working on layouts and selections. So for simplicity’s sake I would say that most people should keep using the default 3.x build of D3 and wait for the 4.0 release. But keep an eye on these new modules, and perhaps tinker with them, so that you’re ready when 4.0 comes out.
(For example, see ai2html for a simple workflow used by The New York Times to create static graphics at various resolutions: http://ai2html.org/)
For most #content today, it’s probably best to design for mobile first and then think about an enhanced (or “optimized”) display for desktop later. But there are plenty of visualization applications, such as systems monitoring, where you might want to design first (or even only) for a large desktop display.
It’s a lot easier to have rich interactive displays on desktop. Our tiny phones are powerful computers, but there’s only so much you can squeeze out of a tiny display that gets occluded by our fat, meatstick fingers. ;)
Great open source work. I've used d3 on many projects and, perhaps interesting to some, have used it often not as a charting library, but as a view/event model for DOM manipulation with advanced UI requirements (think dc.js and crossfiltering). This is after noticing that d3 works with large data sets very quickly - even those directly adding, removing, and editing DOM nodes & data.
My question for you is, broadly, where the speed of DOM manipulation comes from. Typically DOM interactions are very expensive in terms of execution time. I searched the docs and very briefly the source code to no avail.
Cheers, and thanks for open sourcing your work. It has been invaluable to my projects.
You've had the opportunity to monetize d3 in the beginning, yet didn't (paid model). When it garnered reputation, you didn't implement freemium or other cost-free models. (Ads, consulting, enterprise, etc)
At all stages you didn't monetize even when it'd be deemed fine. Why?
Also, I've noticed that d3-axis as a separate module isn't ready yet. D3 scale and axis I have found to be superb when crafting graphs with Angular - is the d3-axis module a low or high priority for you?
d3-axis depends on d3-selection and d3-transition, so it’ll be one of the last modules to be released, I expect. That said most of the functionality is in a sense already available in the scale’s ticks and tickFormat method.
There's obviously a place for both visualisations and art, though, and the line between the two is not always clearly defined.
Was posted recently. Comments: https://news.ycombinator.com/item?id=10737876
Hmm, a lot of projects floundered when they got that (meta/abstract)ambitious, and forgot the plainer beginnings that made them successful. Hope D3 can pull it off.
I'd love to hear your thoughts on how to make visualization more appealing for non-programming users who want to interact with data beyond the basic clicks and drops.
> D3 ... rejects the tyranny of charts
Let me share a couple of counter-examples that attempt to accomplish the opposite, albeit for the common good:
http://apps.axibase.com/chartlab/14cf1974/3/ - Basic
http://apps.axibase.com/chartlab/2111a2b7/2/ - Inheritance and Iterator
http://apps.axibase.com/chartlab/e8635882/10/ - Time series transformations
http://apps.axibase.com/chartlab/2ef08f32/1/ - Composite
I'd appreciate your critique of this approach in general, not necessarily our implementation of it :) Is this level of "tyranny" acceptable in your view?
Are people using D3 inside "enterprises" a lot for business intelligence stuff? I imagine that would be the kind of work that pays.
2. Do you regret the original .enter() .exit() functions? These were powerful, but were a barrier for entry because they were hard to grasp. Do you wish you'd gone full functional from the start?
3. How do you get paid? Are you sponsored? Are you looking for sponsors?
Thanks much for the great work!
2. Not at all; I still think the data-join is a powerful concept for transforming the DOM based on data, and the new work on non-DOM D3 modules does not reflect a shift in my opinion. I’m simply decoupling D3 so that people can use the parts independently. I’m still developing the new d3-selection and d3-transition modules, and those will be released soon, but I’m saving them for last because I want to let the design “bake” to make sure I’m happy with it before release.
3. I am not currently paid (other than a buck or two I make off stickers). My wife is currently my de facto sponsor. ;) I’d like to find a way to make this financially sustainable, but I don’t know yet exactly what that will entail, and I’d like to get 4.0 released first.
Mike, your work never fails to inspire. The cubism slides (http://bost.ocks.org/mike/cubism/intro/#0) read like a revelation. It astounded me how much data you manage to beautifully convey.
Re point 3: Please do thank your wife on behalf of the hackers community!
Perhaps you should consider a donate button in the docs for the time-being while you're going down this path with the project.
There are some basic table-like libraries, like datalib(https://github.com/vega/datalib) and datavore (https://github.com/uwdata/datavore), both from Jeff Heer's research group (which is where Mike first developed D3 as a grad student).
Have you toyed around with MathBox 2? It looks like it has a pretty interesting model.