Show HN: Vizzu – Open-source charting library focused on animating charts(lib.vizzuhq.com)
lib.vizzuhq.com
Show HN: Vizzu – Open-source charting library focused on animating charts
https://lib.vizzuhq.com/
8 comments
Just went through the examples -- I thought it was really neat!
Often times I want/need to display data in more than one format. Usually I just take up a bunch of page space by putting multiple charts.
Here's an example showing what I mean from actual project:
https://github.com/hasura/graphql-bench/raw/master/app/hasur...
If there was a solid and comprehensive charting library that could "tween" between the chart formats, only taking up the space of 1 chart, that would be a neat solution!
Have you found certain pairs/combinations of charts that expose hidden relationships when you display them by animating the data points between them?
Often times I want/need to display data in more than one format. Usually I just take up a bunch of page space by putting multiple charts.
Here's an example showing what I mean from actual project:
https://github.com/hasura/graphql-bench/raw/master/app/hasur...
If there was a solid and comprehensive charting library that could "tween" between the chart formats, only taking up the space of 1 chart, that would be a neat solution!
Have you found certain pairs/combinations of charts that expose hidden relationships when you display them by animating the data points between them?
Thanks! :)
This tweening and space saving is what we built Vizzu for! Do you think you could give it a try?
Regarding the combinations: it really depends on the data and the relationship you're looking for. We hope to make experimenting with such pairs or even series of charts easier with our lib.
Here are a couple of examples that worked well for us in certain settings: https://lib.vizzuhq.com/0.3.0/#example-1.1.12 https://lib.vizzuhq.com/0.3.0/#example-1.1.15 https://lib.vizzuhq.com/0.3.0/#example-1.1.3
Regarding the combinations: it really depends on the data and the relationship you're looking for. We hope to make experimenting with such pairs or even series of charts easier with our lib.
Here are a couple of examples that worked well for us in certain settings: https://lib.vizzuhq.com/0.3.0/#example-1.1.12 https://lib.vizzuhq.com/0.3.0/#example-1.1.15 https://lib.vizzuhq.com/0.3.0/#example-1.1.3
> made each parameter interpolable, turning our engine into a generic chart morpher that can continuously interpolate between any charts that can be described on its interface. After that, we analyzed these transitions and came up with rules that make them self-explanatory and easy to follow for the viewers, and finally, we embedded these rules into the engine.
Clever! An interesting approach. Lots of data vis lib builders (myself included) have added half-baked chart type transitions, but always as a tertiary concern. It usually comes out not so impressive. Your examples look lovely.
It seems like you are betting that there is demand for animated chart types if done much better, and so your focus on that as a first concern may lead you to some new primitives that others have missed.
Years ago I made a similar run but not as sophisticated, eventually dropping animations and building my own static charting lib (and then even dropping that, and making my focus the Studio/Language). I gave up on animations for 3 reasons:
1) The most immediate was during dev time staring at animating charts all day started to give me migraines. May have just been a coincidence, but there were definitely patterns of animation that you don't encounter in nature ever, so I wasn't sure if it was visually healthy.
2) Microsoft's SandDance (https://microsoft.github.io/SandDance/app/) blew me away. I was working from a similar first principle: always show all the data particles and higher level shapes (like bars/circles/etc) are just particles aggregating together. Mine was 2-D only though and much slower.
3) I figured if SandDance wasn't gaining too much traction, as amazing as it is, perhaps there wasn't so much demand for that approach. Maybe you'll discover something different.
Are there certain scenarios where you think your animations will allow telling a better story? Your example page is nice, but I don't see examples of the animations adding value to a story. Or do you think that animations are helpful mostly during EDA, and not at story telling time?
In my iterations I eventually realized making the data pipelines orthogonal to the visualization was the better architecture (basically copying dplyr in Javascript). This seems to be the way most of the JS data vis world is heading now, with Arquero and Observable heading that way. Is that possible with your lib, or do transforms have to be tightly coupled because of the animation component?
Clever! An interesting approach. Lots of data vis lib builders (myself included) have added half-baked chart type transitions, but always as a tertiary concern. It usually comes out not so impressive. Your examples look lovely.
It seems like you are betting that there is demand for animated chart types if done much better, and so your focus on that as a first concern may lead you to some new primitives that others have missed.
Years ago I made a similar run but not as sophisticated, eventually dropping animations and building my own static charting lib (and then even dropping that, and making my focus the Studio/Language). I gave up on animations for 3 reasons:
1) The most immediate was during dev time staring at animating charts all day started to give me migraines. May have just been a coincidence, but there were definitely patterns of animation that you don't encounter in nature ever, so I wasn't sure if it was visually healthy.
2) Microsoft's SandDance (https://microsoft.github.io/SandDance/app/) blew me away. I was working from a similar first principle: always show all the data particles and higher level shapes (like bars/circles/etc) are just particles aggregating together. Mine was 2-D only though and much slower.
3) I figured if SandDance wasn't gaining too much traction, as amazing as it is, perhaps there wasn't so much demand for that approach. Maybe you'll discover something different.
Are there certain scenarios where you think your animations will allow telling a better story? Your example page is nice, but I don't see examples of the animations adding value to a story. Or do you think that animations are helpful mostly during EDA, and not at story telling time?
In my iterations I eventually realized making the data pipelines orthogonal to the visualization was the better architecture (basically copying dplyr in Javascript). This seems to be the way most of the JS data vis world is heading now, with Arquero and Observable heading that way. Is that possible with your lib, or do transforms have to be tightly coupled because of the animation component?
Thanks!
We do think that Vizzu works really well for storytelling but you're absolutely right that more examples would be necessary on the site. Here are a couple of examples that we built with a previous version of our tool: https://vimeo.com/showcase/8920560
Using dplyr with Vizzu seems possible - at least at first sight we actually do very similar transformations of the data .
Using dplyr with Vizzu seems possible - at least at first sight we actually do very similar transformations of the data .
> Microsoft's SandDance
Thanks for telling us about this. Do you know what approach/libary do they use?
Is this just the matter of tagging the elements generated by a normal chart library, then, independently "magic move" (to borrow keynote terminology) them into places? I'm impressed with the number of elements and frame rate.
Thanks for telling us about this. Do you know what approach/libary do they use?
Is this just the matter of tagging the elements generated by a normal chart library, then, independently "magic move" (to borrow keynote terminology) them into places? I'm impressed with the number of elements and frame rate.
They wrote a great paper explaining their "Unit Visualization" concept/approach: https://www.microsoft.com/en-us/research/wp-content/uploads/...
IIRC their engine used to be their own in house WebGL code, but according to their GitHub ( https://github.com/Microsoft/SandDance) they are now using Deck.gl (https://deck.gl/) for rendering and Vega for chart logic. I do think it's not designed to be used as a library though but a complete studio like environment.
IIRC their engine used to be their own in house WebGL code, but according to their GitHub ( https://github.com/Microsoft/SandDance) they are now using Deck.gl (https://deck.gl/) for rendering and Vega for chart logic. I do think it's not designed to be used as a library though but a complete studio like environment.
Seems pretty straightforward to use. I got it working in Observable here https://observablehq.com/@triptych/hello-vizzu
We have added a markdown file in the repo to list 3rd party projects: https://github.com/vizzuhq/vizzu-lib/blob/main/PROJECTS.md
Feel free to add this there if you like.
WOW! That is so awesome! Thanks!
[deleted]
Slightly off topic but does anyone work with server generated charts at all? Or is there not much demand for pdf reports?
Last I checked, converting Javascript charts to PNG is still a hacky/convoluted process.
Last I checked, converting Javascript charts to PNG is still a hacky/convoluted process.
If it's pure Javascript and canvas (2D or WebGL) and no HTML/CSS (often the first thing you'll reach for when drawing and styling text) then it's pretty straightforward to render to JPG/PNG using node-canvas. WebGL on the server is a bit more cumbersome with setting up an X virtual frame buffer (xvfb).
SVG is a lot more finicky, but I've used React to generate SVG that imagemagick can then rasterize. If you limit yourself to primitives, you can have an interactive React UI and be able to render any state snapshot to .svg, .jpg, and/or .png.
I think things just get tricky if you want to use a browser-only library or something that mixes canvas, svg, and/or html+css.
SVG is a lot more finicky, but I've used React to generate SVG that imagemagick can then rasterize. If you limit yourself to primitives, you can have an interactive React UI and be able to render any state snapshot to .svg, .jpg, and/or .png.
I think things just get tricky if you want to use a browser-only library or something that mixes canvas, svg, and/or html+css.
I have a need for this as well. Many of the go-to packages from years ago seem abandoned.
Looks like an interesting library. It’s cool to see practical examples of C++ drawing via WebAssembly. This is how Figma works and is fast, but Figma isn’t open source. I’m saving a link so I can go read the source later.
My feedback: replace the gif on the front page with your library! I thought it was an actual example and thought “cool idea but the implementation is slow and blurry”. But it works much better in the JSFiddle! Why not have some real examples here? There should be three at least - with a button to toggle between states. Your example pages also aren’t very mobile-screen responsive, could use a bit more love. (Browsing on iPhone 12 Pro Max)
My feedback: replace the gif on the front page with your library! I thought it was an actual example and thought “cool idea but the implementation is slow and blurry”. But it works much better in the JSFiddle! Why not have some real examples here? There should be three at least - with a button to toggle between states. Your example pages also aren’t very mobile-screen responsive, could use a bit more love. (Browsing on iPhone 12 Pro Max)
The best example of WASM being used to render to canvas (it's also visualizations) I've seen is "Perspective":
https://perspective.finos.org/
https://perspective.finos.org/
"Perspective is an interactive analytics and data visualization component, which is especially well-suited for large and/or streaming datasets. Originally developed at J.P. Morgan and open-sourced through the Fintech Open Source Foundation (FINOS), Perspective makes it simple to build user-configurable analytics entirely in the browser, or in concert with Python and/or Jupyterlab. Use it to create reports, dashboards, notebooks and applications, with static data or streaming updates via Apache Arrow."
"A fast, memory efficient streaming query engine, written in C++ and compiled for both WebAssembly and Python. read/write/streaming for Apache Arrow, and a high-performance columnar expression language based on ExprTK."Firefox on iphone, buttons on perspective are not clickable.
Thanks! Really useful tips.
Congrats!
Any reasons I would use Vizzu apart from the alternatives? I am currently using Chart.js and I am happy with it.
Any reasons I would use Vizzu apart from the alternatives? I am currently using Chart.js and I am happy with it.
Thanks!
Chart.js is an excellent charting library and much more mature than Vizzu currently. The key advantage of Vizzu is the embedded animation capability. You set up two charts, and you can morph from one to the other and vice versa out-of-the-box. The automatic data aggregation & data filtering feature is pretty unique as well.
Interesting - with the focus on animations, Vizzu seems most similar to Gemini/Gemini2
https://github.com/uwdata/gemini
https://uwdata.github.io/gemini-editor/
https://uwdata.github.io/gemini2-editor/
https://github.com/uwdata/gemini
https://uwdata.github.io/gemini-editor/
https://uwdata.github.io/gemini2-editor/
This looks neat! We love the work of UW Interactive Data Lab but did not know about this one. Thanks for the suggestion.
It works similarly to other charting libs, but when users create a set of charts, Vizzu will automatically animate between them. Thus, we think it is suitable for storytelling and building interactive data explorers.
The library is dependency-free, written in C++ and compiled to WebAssembly. It has automatic data aggregation and filtering capabilities, and we set the defaults used based on dataviz guidelines.
A short summary of how we built Vizzu: First, we created an engine that provides a standard interface for several chart types. Then we looked at the parameter space of this engine and made each parameter interpolable, turning our engine into a generic chart morpher that can continuously interpolate between any charts that can be described on its interface. After that, we analyzed these transitions and came up with rules that make them self-explanatory and easy to follow for the viewers, and finally, we embedded these rules into the engine.
We've been working on Vizzu for quite some time and decided to go open-source because we want to make it easy for others to try it and build whatever they want while helping us figure out how the animation capability can be put to good use.
We created a step-by-step tutorial and examples that you can start playing with in JSFiddle by clicking on the "Edit" button on each example's page.
Tutorial: https://lib.vizzuhq.com/0.3.0/
Examples: https://lib.vizzuhq.com/0.3.0/#examples-1.1
All suggestions and criticism are very welcome.