Carry the selection from a chart into the next answer
An interactive chart can become the input to a follow-up question. Carry the selected data, grouping and filters so the receiving analysis can answer for the same population.
Trace the interfaces between applications and records before changing a system.
An interactive chart can become the input to an analyst’s next question. A person selects a cluster of points and asks what those records have in common. The assistant needs a reliable account of the selection. A screenshot of a shaded area gives the reader a visual cue. The next computation needs the selected records and the rules that put them there.
Microsoft Research’s 22 October description of Flint-interactive shows a way to build this connection. The compiler maps a gesture to an event that identifies chart elements and data. An interaction specification then determines what to update. The examples include linking a selection across views and passing selected context into a follow-up turn. (Microsoft Research, sections “How to use” and “How it works”)
For an enterprise analytics owner, this makes interactive exploration a candidate for a repeatable workflow. The decision is what the receiving analysis should inherit when the person moves from the chart to the question.
Give the selection a meaning outside the chart
Consider a hypothetical service review. A scatterplot shows sites by request volume and average time to resolution. An analyst selects a cluster and asks for the most common reasons for delay. Each point represents a site aggregated over a month. The service desk records that explain the delays sit beneath those points.
The interaction should preserve which site and month combinations were selected and which filters applied when the chart was built. A selection of sites by monthly averages does not define a set of individually slow cases. If the assistant answers from only the cases above a chosen duration, it has changed the question. The chart should make that change visible and ask the analyst to confirm it.
Use durable identifiers for the selected data. A point’s display position changes with zoom, and its row number may change after sorting. At the boundary with the next analysis, send the keys and the chart’s data version, or a reproducible query representing the selection. For an aggregated point, name the grouping and the intended route to its underlying rows. In the proposed design, those details give the recipient a way to inspect and repeat the operation.
Trace the population from chart to answer
Explain delays for the selected site and month groups.
Swipe or scroll for the full diagram →
Report the population
The answer states which records were used and whether the source version changed.
- Select chart points
- The analyst selects aggregated site points within a period.
- Resolve group keys
- The chart passes site, month, filters and data version to the analysis.
- Check source access
- The receiving service resolves the contributing records under the requester's permissions.
- Report the population
- The answer states which records were used and whether the source version changed.
Hypothetical service review. Each step preserves or checks part of the analyst's selection.
A chart selection identifies site and month groups. The receiving query uses those groups and the original filters, checks access and reports the population it analysed.
Keep highlighting, filtering and analysis distinct
A highlight may keep all points visible and emphasise a subset. A filter may remove points and change the denominator of another chart. A follow-up query may fetch records that were never drawn. Define each effect separately. When the analyst selects three sites, a comparison chart can still show their positions relative to all sites. A table intended to explain that selection should state which cases it includes.
The Flint interaction documentation describes chart updates in terms of selected data and operations on the view. An application can choose how a semantic event affects another surface. The decision to retain a denominator or requery source records belongs to the application and data owners. It should be visible to a reviewer even when an agent wrote the chart specification.
Show the applied selection in the next answer. If underlying records have changed since the chart loaded, give the analyst a choice to refresh the view or to use the retained version where that is available. If a user shares an analysis, resolve the selection again under the recipient’s access permissions. Record where the permitted population differs, so a shared link does not promise an identical result to everyone.
Test the handover at the point of use
Pick a case where the same visible gesture can mean two different things. In the service review, a site may appear in both months. Select the point for one month, then ask for its contributing cases. Change the chart’s ordering and scale and repeat the selection by its label. Confirm that the same site and period arrive in the receiving analysis. Include an empty selection, an unavailable source version and an aggregate whose contributing records are restricted.
Ask reviewers to inspect the answer with the chart hidden. They should still be able to identify the population, the time window and whether the selection changed the measure. This proposed exercise tests the handover. The published demonstrations describe the authoring mechanism and examples, without measuring this workflow or establishing how access rules would operate in a buyer’s environment.
The analytics owner should approve the first generated interaction for a specific task whose selection and follow-up can be checked together. Where the application cannot explain which records the analyst selected, keep the visual exploration available and require a deliberate query before generating the next answer.