Problem
Charts in nao have no way to export the underlying data as CSV. If a user wants the raw rows behind a chart, they have to ask the agent to re-run the query as a table, then export from there - a clunky detour for what should be a one-click action.
Tables already expose data export. Charts do not.
Open question - should table and chart objects be unified?
Today, table and chart appear to be distinct objects with separate behaviors and affordances. Worth considering before building the export button:
- Should every chart be backed by the same object as a table, so users can flip between chart view / data view / SQL view on a single artifact?
- Would unifying give us a single set of buttons (export CSV, view SQL, copy data) that works the same way regardless of how the result is currently rendered?
- Does this also help with discoverability - users learn one set of interactions instead of two?
If yes, the right fix isn't "add an export button to charts" - it's "every result is one object with multiple views, and export lives on the object."
If no (good reasons to keep them separate), then just add an export-CSV button on charts that mirrors the table one.
Expected behavior (minimum)
- Export-CSV button on every chart, exporting the data points used to render it
- Same filename / format conventions as the table export
Expected behavior (if unified)
- Each result artifact (table or chart) exposes: data view, chart view (when chartable), SQL view
- Single export-CSV button shared across views
- Toggling view does not re-query
Impact
Closes a common workflow gap (charts to spreadsheet) and is also a chance to simplify the data/chart object model before more divergence accumulates.
Problem
Charts in nao have no way to export the underlying data as CSV. If a user wants the raw rows behind a chart, they have to ask the agent to re-run the query as a table, then export from there - a clunky detour for what should be a one-click action.
Tables already expose data export. Charts do not.
Open question - should table and chart objects be unified?
Today, table and chart appear to be distinct objects with separate behaviors and affordances. Worth considering before building the export button:
If yes, the right fix isn't "add an export button to charts" - it's "every result is one object with multiple views, and export lives on the object."
If no (good reasons to keep them separate), then just add an export-CSV button on charts that mirrors the table one.
Expected behavior (minimum)
Expected behavior (if unified)
Impact
Closes a common workflow gap (charts to spreadsheet) and is also a chance to simplify the data/chart object model before more divergence accumulates.