C3 and Adoption Open Conversation

[photodow]

I was hoping to start an open conversation around our current use of C3, and the adoption of this library.

1. I’m concerned about our use of C3js because that project appears to be dead to me. There has not been any active development around it for nearly a year now. They also haven't added support for D3 v4 yet. I’ve reached out to their team to see how I could get involved with contributing back, and they never responded back to me.

2. I’ve also been trying to get some developers here and there to try and adopt the IBM-Charts line chart with no luck. A couple things they are concerned about is the fear it’s another Northstar, or it’s an extra dependency on top of not only D3, but C3 as well. Another problem I've heard is that they need say a line chart, and a pie chart. Since our project (at the moment) only has a line chart they are choosing other libraries that have both charts.

3. Another problem that I’m concerned with around adoption is that we’re building these out based on business needs. Once a business need has been identified it doesn’t seem like the developers have time to contribute to IBM-Charts to solve that business need or don't see the value in contributing back, so they find another more developed out tool that solves their problem faster. Sometimes that alternative is C3.

One thing I've thought about is we could look at is forking C3 (since it’s essentially dead). That in turn will give us a large set of charts to start with. We can work as we get time to refactor and make it more modular, upgrade it to support D3 v4, and apply the Design Language visuals/interactions (we are essentially doing this part already by adding another layer on top of D3 & C3) to the default styles. And then we would have control of adding new charts like radar which C3 has been saying they would add for 3 years now. I see this in turn providing more flexibility, and performance improvements. Maybe I'm wrong, but I also feel like applying our styles to the C3 framework may go faster, and provide a way for developers new to data visualization feel like they can contribute and help ignite and overcome that initial D3 learning curve.

Sorry for the book, but these were just some thoughts I've been having and wanted to get them off my chest. I'd love to hear if y'all have any alternative solutions. Thanks!

[seejamescode]

You're good! Thanks for writing this up.

I thought a lot on my time off about why adaption is so hard and why so many dev teams make custom charts. I think it comes from the hand-offs of their designers. If a designer makes a custom chart in the specs, the dev is going to feel forced to make the custom chart.

So I shared @winslet's Sketch files with @hchughes. I think the best strategy may be to distribute the IBM Charts Design Kit first. That way devs are being sent designs that have our charts at the start. Thoughts?

[photodow]

I see nothing wrong with that. It would also help to contribute to this project if we had those ourselves. Although, I don't think that alone will solve the adoption problem, or some of the other problems I addressed above.

[rodet]

Hey James, thanks for the feedback. You bring up valid points which we should definitely think about. Sorry for the delay, I had to think longer about this and was a lot on travel the last weeks.

1. You are right that, if C3 continues being inactive, we'll get in trouble in a year or more. So long term a change of direction appears necessary.

2. It's good to have your feedback on that. We plan to push the bar chart next, and pie chart could be something to put next on the backlog then (given we don't make big changes in direction, etc).

3. Indeed developer commitment is an issue. Speaking only for me, I should have more time in the coming months for that project. But that would still not be enough. The first thing that would be interesting is how fast developers can use another library and style it fast and good enough to the IBM Design Language. We took C3 because we found it to be the simplest and fastest to make graphs look like the design samples we had in hand. If another tool goes faster for that, then we should take this as a new tool (see back at 1.). Else, I'd suspect we provide some value to the developers, and we might then question more if our tooling is easy or robust enough for the problems at hand, and improve it as far as it goes.

Forking C3 is certainly one option, which also has some obvious drawbacks. First, we'd have to clear the forking with our legal folks. After that, we should ensure we have enough capacity to maintain it. I guess this would be more work than just build on top of C3 for now. In the future, if C3 starts showing some bigger gaps, this might turn to be the easier solution. From what I've seen about C3, it brings quite a simple sample styles and information, and much works over addition. As we handle charts for IBM Design Language right now, we already bring quite a number of assumptions, so forking C3, or either stepping into the project as active contributor, would help bring a strong basis, but it does not necessarily needs to be merged with the IBM Charts design language.