Every large information firm has to grapple with a fancy difficulty: how you can ship information to customers in a approach that’s intuitive to make use of, simply comprehended, and aesthetically pleasing. This downside could be notably vexing at fast-moving startups, as a result of the engineering group should assist the evolving wants of consumers.

Starting With Flexibility

Like most startups, Pixability initially opted for flexibility in our visualization library.

We may create customized, compelling visualizations that represented the information in unconventional methods, and model these to appear to be the remainder of our software. The visualizations mirrored the precise want on the time, and minor particulars may very well be adjusted rapidly. Plus, the one prices had been extra useful resource hours.

All of those are necessary when making an attempt to construct attention-grabbing and useful visualizations in your customers. However, this strategy had some important drawbacks as properly: we fell prey to a vicious cycle of scope creep, unpredictable code, and improvement churn. Over time, our customized visualizations turned fragile and bloated, and had been too particular to be repurposed throughout our expertise.

Switching to a structured, proprietary visualization library appeared like a step backward — however we discovered it was important. As our firm grew, and we elevated the complexity and amount of visualizations that spanned a number of purposes, it turned evident we had been nearing a tipping level.

Developers had been spending prolonged cycles refactoring easy charts. Only just a few members of the UI group knew how we structured our visualizations, and there was a excessive barrier to entry if one other group member wished to construct or borrow parts for an additional venture.

How many extra man-hours had been we keen to put money into these customized options earlier than choosing a extra inflexible strategy, however elevated developer productiveness? Here’s a easy (if contrived) cost-benefit evaluation operate that underscores our choices:

Switching Gears

Knowing we had been losing sources, we despatched the front-end group on a quest to search out probably the most appropriate charting library. They assessed and in contrast a number of of the most typical libraries, from the open and versatile D3.js with its steep learning-curve, to commercially-licensed libraries like Hicharts.js. To do any job appropriately, you need to decide the best software for the job — and although our engineering group loves free and open-source instruments, the software that made probably the most sense for us was Anychart.js.


  • A large, out-of-the-box set of compelling charts to choose from
  • An API that enables anyone to find out how you can use the software, which promotes standardized patterns for reusability
  • The potential to rapidly learn to implement a chart for quick turnarounds
  • Developer-friendliness and the power for a brand new engineer to dive in and create visualizations with out important information of the corporate’s codebase


  • Licensing charges, since even open-source options might value cash
  • Ramp up time for studying a brand new library as a substitute of ramping up in your codebase
  • Adds one other layer of complexity to your tech stack
  • Loss of absolute management over model and designs

We nonetheless wanted to get the product and design groups on board with this determination, although. We needed to talk that every group can be including one other workflow, that they’d see their creativity considerably contained, and would wish to put aside sources to grasp the bounds of the library. Not solely does the product group should be well-versed within the library’s boundaries, however the improvement group wants a holistic understanding of the library to flag options that aren’t possible. Without purchase in from all groups, you open your self as much as extra design cycles and wasted time making an attempt to construct one thing that isn’t attainable,

Fortunately, Pixability’s groups are top-notch at cross-team collaboration and dialogue. Our groups all understood the library’s limitations, and the product/design groups had been keen to make compromises for wants that weren’t explicitly lined by the library.

What’d We Learn?

With all this in thoughts, you possibly can see that there are advantages and disadvantages to both possibility. We made due with our in-house parts for so long as attainable, however as soon as we surpassed that time, we noticed diminishing returns on our customized visualization funding.

Are there components we are able to’t do in addition to we may, if in any respect? Absolutely.

Do these components affect the performance, usability, maintainability, or total high quality of the visualizations we ship? Not within the slightest.

Our group made a smart move in switching to licensed charting software program, because the useful resource hours we saved had been even increased than anticipated. That’s to not say customized visualizations aren’t a viable possibility — however by spending time rigorously planning our strategy, Pixability made the best alternative in switching to a 3rd celebration visualization library.

The publish Why We Switched To A Third Party Visualization Library appeared first on .

This article sources info from Tech Blog