Charting library about development HOT 21 CLOSED

I was playing around with C3 a while back as a solution to quickly create charts/graphs. And to also allow anyone to do it fairly quickly.

The repo is here: [GHE]/awolfe76/charts

README links to some examples too.

The bigger idea here was that we have static type data live in one place along side the charts, along with any other info about the data itself (another README in the folder). And also to allow this to be just charts/graphs that can easily be iframed into a blog post or other content.

from development.

I love D3, but from a front-end management point of view, I really prefer Charts JS because it's nearly all hands off and does the majority of charts I've ever needed to produce. I'm all about reducing the amount of custom code we have to produce and keep up.

from development.

You should be able to use whatever charting library fits the needs of the project.

from development.

I agree with @sebworks. Attempts to standardize how diverse groups of really smart people work tend to fail. A lot of successful companies (Amazon, Netflix, Viasat) allow each team to choose the best tool for the job and as long as they can deliver the desired result in a reasonable amount of time, and/or meet certain basic standards, the tools they use are up to them.

Then organically, the best tool wins. If there are various great tools, why restrict yourself to just one?

from development.

I use Raphael (which is a vector-drawing library, not a charting library, per se) because I want to make the chart precisely to the designer's specifications. I'd use barebones SVG manipulation, but Raphael takes care of cross-browser nonsense, so it wins me over.

Plus, you can draw a tiger! 🐯 🐯 🐯 👍 🍰

I like to say, "We should use whatever we want!" because I'm a free-wheeling, cowboy-coder type... but we do need to make sure any library we pick is something someone else would have an easy time modifying or maintaining. Once again, it's a good idea for us to shop around what libraries we use so we can sanity-check their maintainability.

from development.

We're definitely going to run into the library surface area vs. file size issue. Sure it would be nice to have a fully-featured chart library with every type of chart and live updating &c but that comes at a cost in bytes... especially for the projects that just need simple charts but are paying in kb/load times for our standardized library.

With this in mind, I'd vote or something modular but that shares similar APIs/ conventions across chart types / functions. Having something based on D3 could be nice as it would allow these same conventions to bleed into more non-standard chart stuff, but that might be out of scope.

@sebworks @jonathanwcrane I'd say the idea of "standardizing" this is to speed up decisions of people on new projects ("which library should we use?... I'll compare them" becomes "let's use the one everyone else uses") and to allow devs to more easily switch projects/help others ("I know how to do this in Raphael, but not Highcharts..." --> "oh yeah, I've done this before").

from development.

I just don't think you can say D3, or any other charting library, is the right library for a project without knowing the requirements, team, and scope.

from development.

I just don't think you can say D3, or any other charting library, is the right library for a project without knowing the requirements, team, and scope.

I agree, but right now we're using at least two of these libraries (if not all three) to create charts that look nearly identical. That feels off to me and we should be sharing that code whenever possible. I'd favor having a standard go to library that we can then deviate from when a project calls for it.

from development.

We're definitely going to run into the library surface area vs. file size issue. Sure it would be nice to have a fully-featured chart library with every type of chart and live updating &c but that comes at a cost in bytes... especially for the projects that just need simple charts but are paying in kb/load times for our standardized library.

Yup, I think this is an issue right now with Highcharts, which is really easy to use but is definitely an everything but the kitchen sink approach.

from development.

@ascott1 Agreed re: sharing code with some necessary deviation. We could even end up suggesting several libraries for different use cases, which would still benefit teams by reducing R&D time

from development.

I think that's a completely reasonable approach @wpears. We could even outline scenarios where those libraries make the most sense and when someone may want to deviate... And we should always revisit that. To @sebworks and @jonathanwcrane's points, we certainly don't want to force anyone to use the wrong technology for a project.

from development.

I killed this conversation dead. 😦 Let's discuss this more at this week's meeting?

from development.

You didn't kill it. I just object to an attempt at a "Central Planning" type approach. Offering guidance, and more importantly, concrete evidence of what "product X" did for "use case Y" on "project Z" is as far as we should go.

from development.

Design Manual working on charts here: cfpb/design-manual#230

from development.

We discussed this in our front-end team meeting this afternoon. As @KimberlyMunoz is pointing out above, the design standards are still being created. Once design standards are solidified it may make sense to create a template for a standard library for our common chart types.

In short: We'll leave this open while design standards are discussed, but we're holding off on this for now.

from development.

We are starting to develop standards! (it's in the very early brainstorm stages of what they should encompass and how broad should they be)

My plan is to have some bureau wide standards that can and should be implemented across platforms like d3.js, r, tableau, word, raphael.js, and whatever other technology becomes popular in the future. What this means is that we will need help on the implementation side building out templates once the standards are more defined.

If any developers are interested in being involved, I'm setting up a big brainstorm meeting in DC on Feb 18th where we are going to talk about goals and an outline/plan. But, we will do a shorter recap meeting on the morning of Friday the 19th for stakeholders and champions to be involved in the process if you are interested.

from development.

That is exciting news @amycesal! I would think we'd want to turn some of those standards into a Capital Framework component so that we can easily spin out common chart formats.

from development.

@ascott1 @amycesal - I am seriously dying to do this. 💀 ❗

from development.

@ascott1 that's awesome! Do you have an example of a project where it would have been awesome to have this already in capital framework? One of the things we are going to be talking about is use cases, so the more examples I have, the more holistically we can think about things.

@mistergone don't die just yet.

from development.

Do you have an example of a project where it would have been awesome to have this already in capital framework?

Owning a Home's "explore interest rates" chart jumps out to me.

from development.

Let's close this in favor of building a cf component when the design team settles on standards for data viz.

from development.