Using D3, the MultiLevel pie chart is constructed from a hierarchical data (shown below). This could be achieved by modifying the original example of pie chart in mike’s blog. The implementation is a 2 step process. In the first step the hierarchical data is stored for each level and in the second step the corresponding […]
Tag Archives: D3
Since d3 can be a little inaccessible at times I thought I’d make things easier by starting with a basic skeleton force directed layout (Mike Bostock’s original example) and then giving you some blocks of code that can be plugged in to add various features that I have found useful.
The idea is that you can pick the features you want and slot in the code. In other words I’ve tried to make things sort of modular. The code I’ve taken from various places and adapted so thank you to everyone who has shared. I will try to provide the credits as far as I remember them!
via Diving Into D3 JS.
This article is all about the basics of D3.JS, not the full details but thorough enough to provide at least a feeling and fundamental understanding of it. In this article I am including a basic overview of this entire subject, an introductory part of D3.JS, some important features, the procedure for creating a chart and some other details too.
This is a blog post about an idea I had about using D3 style selections in THREE.js. What if you could work with WebGL and THREE.js, but write code in the style like you see below to make this data globe?
MetricsGraphics.js is a library built on top of D3 that is optimized for visualizing and laying out time-series data. It provides a simple way to produce common types of graphics in a principled and consistent way. The library supports line charts, scatterplots, histograms, barplots and data tables, as well as features like rug plots and basic linear regression.
The library elevates the layout and explanation of these graphics to the same level of priority as the graphics. The emergent philosophy is one of efficiency and practicality.
Hamilton Ulmer and I began building the library earlier this year, during which time we found ourselves copy-and-pasting bits of code in various projects. This led to errors and inconsistent features, and so we decided to develop a single library that provides common functionality and aesthetics to all of our internal projects.
Moreover, at the time, we were having limited success with our attempts to get casual programmers and non-programmers within the organization to use a library like D3 to create dashboards. The learning curve was proving a bit of an obstacle. So it seemed reasonable to create a level of indirection using well-established design patterns to try and bridge that chasm.
Our API is simple. All that’s needed to create a graphic is to specify a few default parameters and then, if desired, override one or more of the optional parameters on offer. We don’t maintain state. To update a graphic, one would call data_graphic on the same target element.
The library is also data-source agnostic. While it provides a number of convenience functions and options that allow for graphics to better handle things like missing observations, it doesn’t care where the data comes from.
In my role as a user experience designer, I need to understand the motivations of people using the products I help design. A well-designed user experience improves a product’s ability to compete in the field.
I thought I might learn about aspects of a given user base through social media. I decided to sample the tweets and profile biographies of users from a product’s Twitter account to find out how the followers describe themselves and to see if that could help me understand their motivations for following a product.
“Think about what people are doing on [social media] today … they’re building an image and identity for themselves, which in a sense is their brand. They’re connecting with the audience that they want to connect to”