Comments (21)
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.
Related Issues (20)
- Knowledge sharing for writing browser tests - with Protractor, to run in Sauce Labs, good docs and examples, etc HOT 1
- Automate every test which is possible to automate HOT 2
- Define what features and accessibility requirements to test. Automate them. HOT 1
- Make it easy to test quickly in browsers we say we support, so that we test all the browsers we claim to support! HOT 3
- When should we minify front-end assets? HOT 4
- ES6 Conventions HOT 5
- Polyfill approach HOT 1
- Standardize our supported browser list config format HOT 1
- Document browser usage from Google Analytics of key sites/apps HOT 7
- Audit and optimize gulp scripts and styles tasks in cfgov-refresh related to browser bundles HOT 1
- Create policy for exceptions to our browser support standards HOT 4
- Auto format CSS and JS syntax HOT 2
- Manual testing with Sauce Labs pairing sessions + getting started docs HOT 1
- Add link to browser testing checklist to Browser support guide
- Best practices for package-lock.json files on Travis HOT 5
- bring back gulp watch to cfgov-refresh HOT 1
- Spacing and issues with credit card regulation expression in git-secrets patterns
- Supported versions of Python and other dependencies in applications and libraries HOT 8
- Update from Capital Framework to Design System
- Work out use of underscore in JS in this repo and document in front-end standards
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from development.