Comment by NicuCalcea
7 hours ago
I'm sorry, but as someone who creates data visualisation as a big part of my job, I wouldn't say the charts on the website look good. Most aren't awful either, but by no means are they an improvement over what I'd get by telling any coding agent to make a chart with Vega-Lite or Observable Plot, and probably worse than if I had some decent instructions/skills.
I don't quite get what the goal of this is other than abstracting away a little bit of the complexity at the expense of flexibility. To me, the promise of LLMs is the opposite, I can get flexibility and customisation without the cost of complexity.
Some composite charts are quite annoying to be generated well (like bullet, waterfall etc), their Vega-Lite equivalent can be quite long if just starting from scratch.
The intention here is that Flint is a simpler abstraction to get basic setups right and any followup edits can be done on top of the first compiled outputs (thus not limiting expressiveness). It also makes it easier for user to manipulate (like swapping axes, click to change something, which can be very hard if LLM generates a complex chart spec upfront).
But for many basic stuff your intuition is completely right.
I strongly disagree ;-)
The paper's line of reasoning seems to continue the endless subjective loop of assuming your viz framework has the right abstractions & defaults , which the next person will rightfully disagree with for their slightly different eval set
We found in practice:
- LLM's generate charts fine
- LLM's tweak charts fine
- LLM's take user feedback to tweak them fine
In that sense, going higher-level for abstractions, as is being argued for here, is strictly worse: it's better to give controls so the LLM can go deep and customize
In practice, we found the choice of json config language X vs json config language Y to be pretty equivalent across different charting systems (vega, plotly, perspective, etc), LLM's do them all fine
The harder parts were deciding what a good chart is (model, reasoning, context), and opposite of this approach, giving lower-level facility for doing user change requests on tweaks, interactivity, and tricky in practice, when they have a lot of data on it.
You are absolutely right. But note that we are actually on the same point here.
This is exactly why this is an intermediate language designed to get 95% stuff right easily (for expressiveness and reliability purpose), while 5% of more advanced case where the agents need to revise chart for other purpose can be done easily on top of the compiled low-level spec (low in terms of Vega-Lite etc, not SVG). We are not really designing a higher abstraction to replace existing ones.
In the past, the split is like 50% good at first run for some common stuff, all other stuff requires agent-loop or user involvement.
Our goal is to make it easy for most case, not everything needs a full multi-round trip agentic workflow to solve. :)
We are kinda all advanced users in fact, for a lot of users, they are easily get confused with the first time result if that is not as good, and the interactivity cost / multi-round isn't an option.
That's fair, I generally make charts for publication, so I spend much more time and effort on the details. But I can understand this being useful for quick exploration for some people.
Generally speaking, I suggest anyone interested in learning to make charts get familiar with grammar of graphics [0] libraries like Vega-Lite, Observable Plot, ggplot2, Altair. There is a bit of a learning curve if you're used to selecting chart types like in Excel, but once it clicks, it gives you virtually unlimited choices in the kinds of charts you can make. And with ggplot or Observable Plot [1], it's about the same number of lines as something like Flint.
0: https://data.europa.eu/apps/data-visualisation-guide/why-you...
1: https://observablehq.com/@observablehq/plot-gallery
Grammar of graphics has been the foundation of a lot of stuff and definitely worth learning for everyone!
A challenge with GoG is that it assumes configurations as second-class stuff, which makes it quite difficult for users to deal with things like changing formatter, scale, annotations. Flint kinda want to hide this aways (so Flint sets them on behalf of the agent or the user). But yeah, GoG is still the foundation for expressivenss.
2 replies →