Data visualizations help people identify patterns, trends, and outliers in their data. However, creating a useful visual requires several decisions: which chart and data to use, how to map the data to visual properties such as color and position, and how the finished visual should look. AI-assisted development can reduce that complexity by letting developers describe the intended result in natural language while reusable visualization components handle common design and interaction requirements.
Deciding what visualization to create is one problem, while deciding how to create it is another. Power BI offers a convenient way to create reports and visualizations, but authors work within the chart types and formatting options that the product provides. AI coding agents another approach: developers can describe a visualization in natural language and optionally provide example images. Developers no longer have to start with a custom visual implementation or a visualization or graphics specification.
Hello! I’m Alper, a data visualization engineer who joined the Power BI Core Visuals team after completing my PhD at the University of Wisconsin-Madison in 2017. My academic research concentrated on the way we summarize data for visualization and how that affects the analysis tasks that viewers can perform with those visuals. At Microsoft, I have contributed to the development of visualization- and report-related features, as well as continued research in accessible representations of data visualizations. You can learn more about this work on my website. My goal is to ensure that people can realize the potential of visualizations to improve their understanding of data, democratizing access to data without requiring specialized development expertise. Agentic data app development with a generic visualization library advances this goal, and I’m happy to share the progress in this blog post.
Coding agents can now generate data visualization specifications from natural-language prompts. For example, a prompt such as “show me outliers in my sales data” can produce a scatter plot that reveals the overall trend while making unusual values easier to identify.
Figure: An example scatter plot generated from the query “show me outliers in my sales data”, plotting quantity in an order vs sales amount, broken down by country. Points in the top-right quadrant of the chart represent relatively expensive orders of a high quantity of items.
AI coding agents can generate visualizations from several types of specifications. For the analytics template we’ve released alongside Rayfin, our Fabric visuals library depends on the established Vega-Lite specification language. We chose Vega-Lite as our foundational specification because it has a strong research history (beginning with the initial IEEE VIS 2017 paper), a large collection of public examples, and a proven, stable ecosystem.
A Vega-Lite specification is pretty straightforward even for a human to read! A bar chart may look something like the following:
{
"$schema": "https://vega.github.io/schema/vega-lite/v6.json",
"title": "WW Gross by Studio",
"data": { "name": "movieStudioDataset" },
"mark": "bar",
"encoding": {
"y": {
"field": "Studio/Distributor",
"sort": "-x"
},
"x": {
"field": "WW Gross",
"aggregate": "sum"
}
}
}
When passed through the Vega-Lite library, the following visualization is rendered:
Figure: A bar chart generated from the Vega-Lite specification above. Bars show worldwide box office gross by a selection of production companies.You may notice from the JSON specification above that we bind columns of our dataset to visual channels, such as the x- and y-axis. This means that every row of data is evaluated against this binding to create visual marks representing that item. We can also bind data to other visual encodings, like color, angle, line, area, and repetition elements like row and column to make heatmap and small multiple visualizations. You can also see that the above spec uses an aggregate definition, which sums the measure against each unique category, rolling up and summing multiple data rows if they have the same category.
This approach is highly flexible because it represents repeated layouts of data-driven shapes in an abstract, graphics-independent specification. Instead of selecting only from predefined chart types such as pie or line charts, developers can compose a wider range of visual forms.
Our visualization libraries for AI-first workflows
We created reusable React components to help developers build analytics apps with Fabric data. The Fabric visuals package supports the creation of charts and the Fabric data grid supports tabular experiences. Both packages are available on npm and are designed to give developers and AI agents a consistent starting point instead of requiring a rebuild of core behavior for every app. We consider these packages to be in preview as we work to ensure best-in-class support for accessibility, functionality, and world readiness.
As part of the design and development process for this visualization library, our team wanted to ensure that the specifications generated by AI agents make sense for the visual that users want. It is relatively straightforward to ask an agent to generate a visualization. However, by making the design, construction, and layout of visualizations opinionated, we can push toward better visualization design with the features users expect from viewing and interacting with data visualizations. These opinions allow us to support features that users expect from visualizations. Features such as column format strings, app theming instructions, and a consistent design between multiple visuals and tables all become natively supported. This support circumvents the need for the AI agents (or humans!) to reinvent core functionality in every app generation.
Visuals generated entirely by AI agents can be isolated, noninteractive, and inconsistently styled. They may also fail to meet functional and regulatory requirements, including accessibility requirements. Power BI visuals already address many of these needs, but their implementation is too closely tied to the report infrastructure to be extracted directly as reusable components.
Our features and design motivation
When designing our components around Vega-Lite, we wanted to support behavior and design guardrails to improve specifications generated by both developers and AI agents. We found that adapting the Power BI visual style to a Vega configuration was not enough to produce a consistently clean experience. We therefore built these behaviors into the components so developers and AI agents do not have to implement them separately, reducing development time and cost.
From how we know people use visualizations in Power BI reports, we knew that we wanted rich support for data displayed in tables. Therefore, a primary focus is to ensure that many different types of data are supported in our data grid component. Specifically, we support visualizing data with data bars, images that can expand to fill the screen on click, and an extendable adapter to visualize rich text or other arbitrary data-driven item within grid cells. Our data grid implementation also supports filtering, reordering, sorting, and resizing columns out of the box.
Figure: Captured video showing functionality of the data grid component, demonstrating inline images, data in colored pills, hyperlinks, and row filtering based on original row data.
For the style of the visuals and data grid, we aimed to align with the appearance of Power BI visuals, adapting improvements as we iterated on the design. We wanted a consistent design language, so we adapted to Segoe UI text, 3-pixel lines, and Power BI data colors. We enforce a minimum distance between bars between categories, add some rounded bar ends, and customize the Vega-Lite’s axes to align more closely with the default Power BI style.
Figure: Illustrative comparison between Vega-Lite (left) and Fabric visuals (right). Shapes in Fabric visuals follow spacing and sizing similar to Power BI, while the axis more closely resembles Power BI visuals over Vega-Lite ones.In addition to style harmonization, we also wanted to enforce some good practices to ensure arbitrary visualization construction did not lead to messy or unreadable visuals. We apply some levels of truncation for long text labels, long legend entries, and overlapping axis labels, and augment stacked bar charts with data labels that show up centered within the bar.
For visualization clarity, we enforce a minimum bar size when the value of the bar is not zero, and implemented a version of the line chart tooltip crosshair to make it easier to recover values. To support bar charts with many, many categories, we also implemented categorical scrolling, similar to what you see on a categorical bar or column chart in Power BI reports!
Figure: Captured video showing functionality of scrolling Cartesian axes (left) and crosshair tooltip on a line chart (right). These both enhance the end-user experience of interacting with charts, allowing a bar chart to scroll to more categories and a tooltip to show information without requiring precise mouse movements to recover data.
By also linking these default styles with the theming object that changes foreground and background colors, a user or agent has a clear avenue to adapt the look of their data app to their aesthetic preferences. This theming object has both a ‘light’ and ‘dark’ mode, and the Fabric Apps analytics template provides sensible defaults for each.
Figure: Illustrative video showing an instantiated data app switching from light to dark mode without introducing readability issues.The architecture of our packages
The Fabric visuals and Fabric data grid React components beach focus on their own functionality. Both depend on the Fabric visuals core package, which defines shared input data, interaction messages, and theming. Standardizing input data through the DataTable type also lets column definitions carry format strings and semantic types, giving developers and AI agents a consistent contract across data-driven components.
Standardizing these core pieces of inputs (data, theming, and interaction) makes it easier for both software developers and AI agents to understand what is needed for each component in a data app. The result is a consistent design pattern to follow. This greatly simplifies data query lifecycle management, as the onus for executing and parsing data is pushed into the template, leaving just specification and query definition to the app developer.
Figure: Illustrative screenshot of the organization of specification, query, and component files in an instantiated data app project.The instantiation of the component then becomes straightforward in a React application:
<VegaVisual
spec={spec}
data={dataTable}
theme={theme}
onInteraction={handleInteraction}
style={{ height: 420, width: "100%" }}
/>
Because each component follows the same core input model, developers can add new components to a data app more easily. Every component requires data, and using a theme is strongly recommended. The specification and interaction handler depend on the component: VegaVisual requires a specification, while DataGrid does not.
What we hope this enables you to do
We are excited to introduce these components because we believe it enables flexibility to define what you want in your data app. By building the infrastructure to support functionality like formatting data, labeling data, grid-viewing functionality, and how interactions can bubble to other components, it saves you (and your AI agent) time and tokens in assembling the building blocks together to get the app you want.
These components provide clean, consistent interfaces that AI agents can interpret more easily. For visualizations, the Vega-Lite domain-specific language is widely represented in the material used to train AI systems and can be generated from a natural-language request. Its flexible specification model lets users create and combine a broad range of visualizations instead of being limited to the design and formatting options exposed by a fixed interface.
These libraries provide reusable building blocks for adding data visualization and associated data experiences to React applications. Although they are designed for Fabric App templates, developers can also use them in other React applications that need built-in support for formatting, labeling, theming, and interaction. Our continued development will focus on helping people uncover insights in their data through natural-language and low-code experiences.
Next Steps
We’re excited to see what you build with these components and the template. Try them in your next Fabric data app or React project, and share your experience in the Power BI Developer forum. Tell us what you built, what worked well, and where the components or template could make development easier. If you have an idea for a new capability, submit it through the Power BI Ideas forum, and learn more about using the template on Microsoft Learn.
Microsoft Employee