Interactive generation of presentations for data visualization dashboard updates

Abstract

The present disclosure provides an interactive generation presentation method and system for data visualization dashboard update, relates to the technical field of data visualization interaction, and comprises the following steps: continuously acquiring a real-time data stream, triggering an update operation, and saving an independent data snapshot; extracting structured data facts from the data snapshot by using a fact extraction engine, performing comparison and matching on the structured data facts by using a cross-snapshot comparison mechanism, and generating a basic fact difference set; generating an update description text based on the basic fact difference set; presenting the update description text in the form of a list on a panel, and positioning all chart views affected by the data update; and for any view, superimposing and comparing the saved pre-update snapshot and the post-update snapshot in a local area covered by a lens in a pixel level or a primitive level by using an interactive floating layer. The present disclosure completely transparentizes, measurabilizes and backtracks the data evolution process in the dashboard.

Description

Technical Field

[0001] This disclosure relates to the field of data visualization interaction technology, specifically to an interactive generation and presentation method and system for updating data visualization dashboards. Background Technology

[0002] The statements in this section are merely background information relating to this disclosure and do not necessarily constitute prior art.

[0003] Data visualization dashboards provide users with a global overview of complex data through multi-view representations, and have become the de facto standard for monitoring and exploring dynamic data in various fields such as business intelligence, public health, finance, and industrial operations. Currently, when mainstream platforms continuously update underlying data and multiple views, these systems often fail to effectively communicate these changes to users. In real-world monitoring-oriented scenarios, the default mechanism for most current dashboards to handle data updates is simply to overwrite existing visualizations with abrupt visual refreshes.

[0004] This sudden refresh process triggers a serious "change blindness" problem at the human cognitive level. Change blindness refers to the phenomenon where users completely ignore large-scale visual changes occurring on the screen when their attention is not focused on a specific area that is changing, or when transient visual cues are disrupted.

[0005] Existing data visualization research has proposed techniques such as animated transitions, phased updates, trajectory-based representations, and visual highlighting to alleviate the problem of blindness to change in a single view. However, existing methods still have the following limitations: (1) Existing methods are mainly for scenarios where changes are limited to a single chart. In dashboard monitoring tasks, data updates are often frequent and distributed across multiple coordinated views. Directly applying animation or highlighting techniques from a single view to a multi-view dashboard greatly increases the cognitive load on users and makes cross-view comparisons extremely difficult.

[0006] (2) The existing system is severely lacking in timely perception support for data updates. Whether it is a pull update based on thresholds or schedules that rely on manual configuration by the user, or an automatic polling update based on direct data connection at the system's underlying layer, the system rarely provides clear data update signals. This causes users to rely on snapshots of the current state to guess whether an update has occurred, often missing key insights hidden in data updates.

[0007] (3) The existing system also lacks a guidance mechanism for location changes, because updates may be scattered in different views or may only be manifested as subtle differences in specific visual markers. Users can only rely on inefficient manual visual scanning to compare changes between multiple charts.

[0008] (4) Existing systems are difficult to support quantitative checks on the magnitude of changes. Most dashboards only display the current state value, forcing users to rely on short-term memory, psychological estimation, or repeatedly manually adjust the time axis to compare with historical data, which is prone to errors.

[0009] (5) After updating and overwriting old data, the existing dashboard lacks support for tracking and summarizing the continuous update history, making it difficult for users to reconstruct the historical trajectory of changes to analyze how an abnormal event spreads and evolves over time and across different chart dimensions. Summary of the Invention

[0010] To address the aforementioned issues, this disclosure proposes an interactive generation and presentation method and system for updating data visualization dashboards. By introducing an independent update detection proxy layer and an interactive visual overlay layer over the existing dashboard view between the existing underlying data stream input and visualization chart rendering, comprehensive data update monitoring and interactive analysis response can be achieved without modifying the original dashboard chart's internal rendering logic.

[0011] According to some embodiments, the present disclosure adopts the following technical solutions: Interactive generation and presentation methods for updating data visualization dashboards include: Continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot; Use a fact extraction engine to extract structured data facts from data snapshots; By using a cross-snapshot comparison mechanism with an introduced detection function, structured data facts are compared and matched, the overall difference magnitude of fact changes is calculated, and a basic fact difference set is generated. Based on the set of basic fact differences, each changing fact is quantitatively scored, format constraints are set, and the format constraints and quantitative scores are used as input to the large language model to generate updated descriptive text. The update description text is presented in the panel as a list. The underlying data fields and visual encoding mapping relationships corresponding to the update description text are parsed, and all chart views affected by the data update are located. For any given view, calculate the view change score. Based on the view change score, trigger the perception-driven view adaptive scaling interaction logic. Use an interactive floating layer to overlay and compare the saved snapshot before and after the update within the local area covered by the lens at the pixel level or the primitive level.

[0012] According to some embodiments, the present disclosure adopts the following technical solutions: An interactive generation and presentation system for updating data visualization dashboards, including: The data acquisition module is used to continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot. The fact extraction module is used to extract structured data facts from data snapshots using the fact extraction engine; The change fact extraction module is used to compare and match structured data facts using a cross-snapshot comparison mechanism with an introduced detection function, calculate the overall difference magnitude of fact changes, and generate a basic fact difference set. The updated description generation module is used to quantify and score each changed fact based on the basic fact difference set, set format constraints, and use the format constraints and quantification scores as input to the large language model to generate updated description text. The view positioning module is used to present the update description text in the panel as a list, parse the underlying data fields and visual encoding mapping relationships corresponding to the update description text, and locate all chart views affected by the data update. The rendering interaction module is used to calculate the view change score for any view, trigger the perception-driven view adaptive scaling interaction logic based on the view change score, and use an interactive floating layer to overlay and compare the saved snapshot before and after the update in the local area covered by the lens at the pixel level or the primitive level.

[0013] According to some embodiments, the present disclosure adopts the following technical solutions: A non-transitory computer-readable storage medium is provided for storing computer instructions, which, when executed by a processor, implement the interactive generation and presentation method for updating data visualization dashboards.

[0014] According to some embodiments, the present disclosure adopts the following technical solutions: An electronic device includes a processor, a memory, and a computer program; wherein the processor is connected to the memory, the computer program is stored in the memory, and when the electronic device is running, the processor executes the computer program stored in the memory to enable the electronic device to perform the interactive generation and presentation method for updating data visualization dashboards.

[0015] Compared with the prior art, the beneficial effects of this disclosure are as follows: This disclosed interactive generation and presentation method for data visualization dashboard updates significantly improves perception efficiency and effectively overcomes the "blindness to change" phenomenon that has long plagued the visualization field. By introducing semantic detection and fact reporting bread into the system, the silent and fleeting background data refresh process is transformed into an explicit and persistently viewable list of semantic events. Users do not need to constantly monitor every corner of the screen; they can quickly grasp the overall update situation through high-level text summaries when they intervene later, thus ensuring that no data anomalies with business implications are missed in high-value scenarios such as critical production monitoring, traffic scheduling, or epidemic tracking.

[0016] This disclosure presents an interactive generation and presentation method for updating data visualization dashboards, significantly reducing the visual search cost and cognitive load for users in complex view systems. Traditional dashboard analysis heavily relies on operators' visual scanning and personal experience to compare changes, while this disclosure constructs a direct linkage and highlighting mechanism between semantic-layer facts and visual-layer charts, and supplements it with a cross-view shared update propagation tracking link, shortening the analysis process from anomaly discovery to anomaly localization, freeing users to focus on causal reasoning about the business logic itself.

[0017] This disclosed interactive generation and presentation method for updating data visualization dashboards overcomes the limitations of manual psychological estimation, achieving precise quantitative assessment of subtle changes. Through an innovative hybrid scoring mechanism that integrates data factual bias with the "data ink ratio" of front-end charts, this system can not only calculate differences from the data but also assess the actual visual impact of those differences under specific chart types. The accompanying perception-driven view adaptive scaling and non-destructive review lens overlay interaction allow users to intuitively and quantitatively perceive minute fluctuations—such as slight color shifts or area adjustments—without disrupting the original global layout, using the system-rendered difference layers within a magnified area. This significantly improves the objectivity and accuracy of data judgment.

[0018] This disclosed interactive generation and presentation method for updating data visualization dashboards endows dashboards with powerful historical continuity and long-term pattern mining capabilities. In existing monitoring platforms, once new data overwrites old data, a break appears in the historical evolution process; however, the two-layer timeline mechanism provided in this disclosure, which includes both global and single-view levels, can reconnect massive fragmented update time points into a complete, traceable, and replayable evolutionary story. With this function, users can easily identify those systemic abnormal patterns that are not noticeable with a single screen refresh and evolve continuously over multiple rounds (such as how a traffic jam gradually spreads from one block to the entire city's road network through 20 consecutive data polls). Attached Figure Description

[0019] The accompanying drawings, which form part of this disclosure, are used to provide a further understanding of this disclosure. The illustrative embodiments of this disclosure and their descriptions are used to explain this disclosure and do not constitute an undue limitation of this disclosure.

[0020] Figure 1 This is a flowchart of an interactive generation and presentation method for updating a data visualization dashboard according to an embodiment of the present disclosure. Figure 2 This disclosure provides a feature classification architecture for data update attributes (numerical, structural, and temporal) to communication presentation modes (single-view, multi-view, and semantic). Figure 3 This is an internal logic flowchart of the data update detection and fact extraction engine in an embodiment of the present disclosure; Figure 4 This is a graphical representation of the interface interaction for implementing a global overview and specific view history review summary based on a timeline mechanism, as described in this embodiment of the disclosure. Detailed Implementation

[0021] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0022] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0023] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0024] Example 1 One embodiment of this disclosure provides an interactive generation and presentation method and system for updating data visualization dashboards, the method steps including: Step 1: Continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot; Step 2: Use the fact extraction engine to extract structured data facts from the data snapshot; Step 3: Use the cross-snapshot comparison mechanism with the introduction of a detection function to compare and match the structured data facts, calculate the overall difference magnitude of the fact changes, and generate a basic fact difference set; Step 4: Based on the basic fact difference set, quantify and score each changed fact, set format constraints, and use the format constraints and quantification scores as input to the large language model to generate updated descriptive text; Step 5: Present the update description text in the panel as a list, parse the underlying data fields and visual encoding mapping relationships corresponding to the update description text, and locate all chart views affected by the data update; Step Six: For any view, calculate the view change score, trigger the perception-driven view adaptive scaling interaction logic based on the view change score, and use an interactive floating layer to overlay and compare the saved snapshot before and after the update in the local area covered by the lens at the pixel level or the primitive level.

[0025] As one embodiment, this disclosure provides an interactive generation and presentation method and system for updating data visualization dashboards. This disclosure introduces an independent update detection proxy layer and an interactive visual overlay layer on top of the existing dashboard view between the existing underlying data stream input and visualization chart rendering. This achieves comprehensive data update monitoring and analysis response without modifying the original dashboard chart rendering logic. Specific implementation details are as follows: Step 1: Continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot; Specifically, the process begins with detecting data updates and extracting relevant changes. The system continuously receives real-time data streams.

[0026] The update operation is triggered, which is compatible with both the manual update mode triggered by user-preset conditions and the automatic polling mode where the system periodically fetches new data.

[0027] Whenever an update operation is triggered, not only is the new data directly passed to the front-end view for rendering, but the complete dataset state of the update is also saved as an independent data snapshot on the back-end.

[0028] Step 2: Use the fact extraction engine to extract structured data facts from the data snapshot; use a cross-snapshot comparison mechanism with an introduced detection function to compare and match the structured data facts, calculate the overall difference magnitude of the fact changes, and generate a basic fact difference set; First, after the data snapshot is built, the system's internal fact extraction engine extracts a set of structured data facts from the current snapshot. These data facts cover core numerical features such as the overall trend of the data, its statistical distribution, and local extrema.

[0029] Subsequently, the cross-snapshot comparison module is activated to rigorously compare and match the currently extracted structured data facts with the corresponding data facts in the previous historical state (i.e., the previous data snapshot). To ensure the accuracy and noise resistance of the comparison, a detection function is introduced to identify whether the facts have changed significantly, comprehensively considering the degree of abrupt changes in local extrema and the overall difference in the global data structure, thereby generating a basic set of fact differences containing change labels.

[0030] Specifically, the data facts of the current snapshot With historical snapshot facts A comparison is performed. The detection function quantifies both numerical and structural changes: (1) Value Change Detection: Extracting local extrema or key indicators from facts. Calculate the relative rate of change .like Exceeding the preset significance threshold If it is, then it is marked as a significant mutation.

[0031] (2) Structure Change Detection: Based on the data distribution or trend, the distribution distance algorithm of cosine similarity is used to calculate the distribution distance between two sets of fact vectors. .like > If it is, then it is marked as a significant structural drift.

[0032] The change entries filtered by the threshold are assembled into a basic Change Facts Set. Each record in the change set contains: a fact ID, a change type (numerical / structural / time), a quantified value of the change magnitude, and the underlying data fields involved.

[0033] Step 3: Based on the basic fact difference set, quantify and score each changed fact, set format constraints, and use the format constraints and quantification scores as input to the large language model to generate updated descriptive text. This includes the following steps: Step 31: Calculate the point value magnitude score, time effect score, distribution structure score, and confidence score respectively; among which, the distribution structure score is calculated separately according to field type, including numerical samples and logarithmic samples; finally, the point value magnitude score, time effect score, distribution structure score, and confidence score are weighted and fused to obtain the normalized comprehensive score.

[0034] Specifically, after generating the basic fact difference set, a normalized comprehensive score S∈[0,1] is calculated for each difference record.

[0035] (1) First, calculate the point value amplitude score M: if there is a relative rate of change (in , and These represent local extreme values ​​or key indicators in the facts before and after the change, respectively. ε To prevent zero values ​​from being counted, then M = clip[0,1]( r Otherwise, M is obtained by hyperbolic tangent mapping of the absolute change.

[0036] (2) Time effect score T By logarithmic rate of change λ calculate:

[0037] in, λ It is the natural logarithm of the ratio of the old to the new values ​​divided by the time interval.

[0038] (3) The distribution structure score D is calculated separately for each field type: For numerical samples, the Kolmogorov–Smirnov statistic (DKS) and Wasserstein distance are used. W After standard deviation normalization, the effect size η = W / σpooled is obtained, which is then fused into:

[0039] For categorized samples, the chi-square test and Cramér's V effect size were used. c and the population stability index PSI are combined into:

[0040] (4) The confidence score C is taken from the detection source or cross-type matching confidence, with the default being 0.9 for deterministic detection and 0.75 for cross-type assistance.

[0041] (5) The final normalized composite score is:

[0042] in, wt The fact type weights are calculated as follows: (1.10–1.15 for trend, difference, outlier, and distribution; 1.00 for extreme value and aggregation; and 0.95 for numerical and proportional facts). The system-level change intensity is further weighted by the average of the top 20% fact scores and the average of all fact scores.

[0043] Ultimately, it can be used for global change sorting and visual update decisions.

[0044] Step 32: Set format constraints, and use the format constraints and quantitative scores as input to the large language model to generate updated descriptive text.

[0045] The scoring mechanism quantifies and scores each identified change fact, taking into account both the absolute magnitude of the data change and its relative importance in the current business context. Simultaneously, strict format constraints are derived from the extracted fact structure attributes. These constraints, along with the quantified scores, are sent as input parameters to a ranking and description generation engine based on a large language model. This engine prioritizes processing the highest-scoring and most significant change facts, strictly adhering to the format constraints, ultimately generating a series of structured, easy-to-read natural language update description texts (Data Change Facts).

[0046] Semantic description generation is automatically triggered during the formatting stage (run_format_stage), with the prerequisite formatting constraint being that a non-empty list of differences in changes[] records has been generated during the comparison stage. After triggering, it is executed according to a two-level strategy: "deterministic draft priority, semantic model enhancement optional," specifically including the following steps: The first step is to pre-generate a deterministic summary. For each difference record, extract context from its change_metrics, including change type (keep / shift / emerge), fact type, metric field, subspace, old and new values, absolute change, and relative change rate. Then, assemble this context into a natural language draft according to a preset template.

[0047] The template rules are as follows: emerge type begins with "A new … emerged", keep type begins with "… held steady", and shift type begins with "… shifted". This is followed by "from {old value} to {new value}" and the relative percentage change. If a subspace constraint exists, "for {subspace}" is added. If cross-type matching occurs, "same pattern as the earlier …" is used. Drafts are truncated to ≤36 words and ≤220 characters before being written to the summary field. The source is marked as deterministic, and the confidence level is assigned by default according to the change type (emerge 0.92, shift 0.88, keep 0.80).

[0048] The second step is batch semantic enhancement (optional). When the system configuration allows large language model calls and the text generator is available, the structured context of all difference records (including fact type hints, display-friendly field names, subspaces, values, view bindings, deterministic drafts, etc.) is serialized into a JSON batch, and a unified prompt word is constructed and sent to the semantic generation module.

[0049] The prompt constraints are as follows: each prompt should output only one summary (14–28 words), strictly maintaining the semantics of keep / shift / emerge comparisons, and prohibiting the fabrication of metrics or causal relationships. If the draft is already accurate, only minor adjustments for fluency will be made. The model returns a JSON array [{fact_id, summary, confidence}], which is written back to the corresponding discrepancy record by fact_id, and the source is updated to llm_batch. If the model does not respond or parsing fails, the deterministic draft remains unchanged to ensure that the process is usable even in a downgraded manner.

[0050] The third step is chart-level description generation (optional, triggered independently). After the comprehensive score and view data change calculation are completed, if there is a non-empty view change mapping, the chart description generation module is further called. Taking the change intensity of each view, the differences in related facts, and the time window as input, a sentence-level change summary is generated for each affected chart for display in the dashboard component. This step runs in parallel and is independent of the fact-level summary, and also falls back to the rule template if the model is unavailable.

[0051] The generated update description text results are output to the front-end fact change list and historical comparison records along with the difference set. Users can directly read the meaning of the change for each fact without having to consult the original numerical fields.

[0052] Step 4: Present the update description text in the panel as a list, parse the underlying data fields and visual encoding mapping relationships corresponding to the update description text, and locate all chart views affected by the data update; Specifically, to establish an intuitive link between semantic understanding and visual positioning, this disclosure performs interactive processing of semantic-to-visual links. The system embeds a semantic report panel independent of the chart canvas within the user interface. This panel presents all data change fact texts generated in the preceding steps in a list format, proactively exposing the underlying, invisible update events as high-level semantic objects to analysts. When a user clicks or selects a specific data change fact in the semantic report panel, the system immediately parses the underlying data fields and visual encoding mapping relationships corresponding to that fact, and automatically locates and highlights all corresponding chart views affected by that data update within the complex layout of the dashboard, thus locating the chart views. The specific implementation process is as follows: A semantic reporting panel, independent of the chart rendering canvas, is embedded in the user interface and displayed alongside the main dashboard. This panel presents all data change facts generated by the preceding comparison steps in list form. Each record includes a change type label, fact type, comprehensive change score, and natural language summary, and is sorted by change priority and score. Duplicate items with the same semantics and fields are displayed after deduplication and merging, thereby abstracting the underlying, invisible data update events into high-level semantic objects for analysts to read.

[0053] When a user clicks on a fact item in the semantic report panel, the selection or deselection is toggled, and the fact's identifier, pre-computed view binding set, and change type are written to the global interface state. At the same time, other conflicting interactive selection states are cleared to ensure that the highlighted semantics are singular and clear.

[0054] The view binding set is not inferred temporarily when the user clicks, but is pre-built based on the "field-view" inverted index during the backend formatting difference set stage, as detailed below: First, a pre-defined static mapping table of normalized field names to chart view identifiers is loaded according to the operating mode and dataset. If a dashboard specification object exists, the actual data fields referenced by each view are further aggregated from the visualization specification. After field name normalization, the data fields are merged with the static mapping to form a complete field-to-view inverted index. Then, starting from the metric field and the inferred dimension field of the fact, all view identifiers referencing the corresponding fields are retrieved from the inverted index. These are then grouped and aggregated into bound records by view, and each field is labeled with its coded role (metric or dimension) in the view. Finally, a binding structure containing view identifiers, view paths, and field-role elements is formed and sent to the front end along with the difference set.

[0055] Furthermore, after the user selects a fact, the front end reads the bound collection from the global state, extracts all view identifiers to form the target view collection, and matches them one by one with the chart cards mounted on the corresponding DOM nodes in the dashboard's responsive grid layout. Views belonging to the target collection are highlighted and given semantic coloring according to the change type of the fact; the remaining unaffected views are given a weakened style, making related views visually stand out from the complex layout. If the user does not focus on a particular chart, the system automatically performs smooth scrolling positioning on the first view in the target collection, moving it to the center of the visible area. Simultaneously, the panel side applies a selection style to the selected item and a weakened style to the remaining items, creating a two-way visual correspondence between the semantic panel and the chart canvas.

[0056] The above-mentioned linkage process is implemented using pre-computation binding table lookup and set matching, with a time complexity of linear level. It does not require re-traversing the visualization specification or performing graph search at the moment of interaction, thus ensuring that cross-layer navigation from semantic facts to affected chart views is timely, accurate and interpretable.

[0057] This cross-modal highlighting mechanism establishes a fast channel from semantic description to visual view, completely eliminating the tedious process of manually scanning for changing areas in massive charts. Furthermore, for situations where multiple different views may share the same underlying data update, this disclosure generates and renders a guiding graphic called a visual linking indicator between these views. The specific implementation process is as follows: For scenarios where multiple different views share the same underlying data update field, the system automatically constructs a view relationship graph on the front end after data comparison. This graph uses the view identifiers of each chart as nodes, traverses all pre-calculated binding records of data changes, and summarizes the set of underlying data fields referenced by each view. Then, it performs intersection calculations on the field sets of any pair of views. If common fields exist, a relationship edge is established between the two nodes, with the edge weight determined by the number of common fields, and a list of common field names is recorded. This forms an undirected relationship graph reflecting the "shared data update" relationship, which can be used by subsequent visual link indicators.

[0058] When a user activates the visual link navigation, they must first focus on a source view chart. The chart card header displays a related link control, next to which is an indication of the number of edges associated with that view. After the user clicks this control, the system filters all related edges from the current view in the association graph. If link mode is not currently active, it enters link mode and selects the first related edge. If it is already in link mode and subsequent related edges still exist, it switches to the next edge in sequence to support navigation between the same source view and multiple shared field views. If all related edges have been traversed, it exits link mode. In the active state, the global interface records the source view identifier and the current related edge number. The source view and target view are highlighted at their respective ends, while other views not involved in the association are given a less prominent style, allowing users to clearly perceive "where to start and where to go" in complex layouts.

[0059] The visual link indicator itself is rendered by a vector graphics layer overlaid on the dashboard grid stage. This layer does not participate in pointer event capture to avoid interfering with chart interaction. The system reads the screen boundary rectangles of the source and target view chart cards in real time through the Document Object Model and converts them into local coordinates relative to the grid stage. Then, based on the card outline expansion and corner radius, it selects the optimal connection edge pair on the sides of each card facing the other. Candidate edge pairs must meet relative orientation constraints (such as vertical or horizontal), and the connecting line segment must not cross the interior of either card. The one with the shortest center distance among the valid candidates is selected as the connection position. The valid connection interval after removing the rounded corners is truncated on the selected edge segment. If necessary, the two ends are forced to maintain a minimum gap. Then, a concave Bézier curve is used to close the upper and lower connection intervals into a strip-shaped path. The curvature of the path is adaptively adjusted according to the weight of the associated edge. The greater the weight, the higher the visual intensity of the guide strip. The fill uses a semi-transparent color band that gradients along the connection direction and adds a projection to enhance the sense of layering. The names and weights of the associated public fields are displayed as graphic hints on this path.

[0060] Because the dashboard uses a responsive grid layout, card positions may change with window scaling, panel collapsing, or focus animations. The system registers size observers for the grid stage and related card elements, and continuously updates the connection geometry in a loop of animation frames during layout transitions. After the transition ends, the connection is fixed to the latest position, ensuring that the visual link indicator always accurately connects two cards. Users can repeatedly click the link control on the source view to cycle through multiple target views that share the same underlying data updates. Each jump synchronously updates the highlighted endpoints, the weakened range, and the start and end positions of the guide strip graphics, achieving semantic navigation across views.

[0061] Users can navigate and jump between related views by following these visual link indicators, thus clearly tracking how changes in a particular underlying data spread across different chart dimensions (such as from a geographic map to a time-series line chart).

[0062] Step 5: For any view, calculate the view change score, trigger the perception-driven view adaptive scaling interaction logic based on the view change score, and use an interactive floating layer to overlay and compare the saved snapshot before and after the update in the local area covered by the lens at the pixel level or the primitive level.

[0063] After completing the macro-level view positioning, this disclosure further implements an interactive process that supports fine-grained change inspection and adaptive adjustment. To help users quantitatively perceive the magnitude of view updates, it innovatively integrates the difference measurement at the underlying data level with the visual ink changes in the front-end chart rendering layer, thereby calculating a unified view change score, as follows: For any view in the dashboard, its data-ink ratio is first calculated. This visual ink change signal is then weighted and combined with the underlying actual numerical or distribution data change signal, and the weighting strategy is dynamically adjusted according to the type of chart being analyzed. For example, for line charts, which emphasize visual trends, the visual change signal is given higher weight, while for pie charts, which emphasize category ratios, the underlying data change signal of category differences is relied upon more, thus ensuring the scientific validity and consistency of the mixed score evaluation.

[0064] For any view in the dashboard v The system constructs the visualization specifications of the view under both the baseline snapshot and the current snapshot and completes off-screen rendering. Then, it traverses all graphic items in the rendered scenegraph. Each graphic element is first classified as "data ink" (i.e., visual marks that directly carry data information) or "non-data ink" (coordinate axes, grid lines, legends, titles, backgrounds, and other decorative elements) based on the chart type of the view (such as line chart, bar chart, scatter plot, pie chart / donut chart, radar chart, map, etc.), graphic mark type, semantic role, and data binding status.

[0065] The ink area for each graphic item is estimated according to the mark geometry: for rectangles, it is the sum of the fill area and the stroke perimeter; for circles / symbols, it is the sum of the fill area and the circumference stroke; for arcs, it is the sum of the sector fill and the arc length stroke; for polylines / paths / regions, it is the sum of the path length or the enclosing area and the stroke area; for text, it is the product of the font size and the character width, multiplied by the opacity of the corresponding channel.

[0066] The area accumulation of ink classified as data ink is summed to obtain Idata, and the area accumulation of non-data ink is summed to obtain Inon. Total ink: Itotal=Idata+Inon The data ink ratio is defined as R = Idata / (Itotal + ε), where ε is the amount of ink to prevent zeroing.

[0067] Calculate Rbase and Rcur for the base state and the current state respectively to obtain the change in ratio: ΔR=|Rcur Rbase | And the absolute change in ink volume: ΔI=∣Idata,cur Idata,base | Further, the view emphasis coefficient E=1+min(0.18,0.6×ΔR) is derived from ΔR, which is used for subsequent focus scaling and visual emphasis; the percentage change in ink density is ΔI%=100×ΔI / Idata,base (when the reference ink is greater than zero).

[0068] The differences in chart types are reflected in the data / non-data classification rules: for example, line charts count lines, paths, regions, and data point symbols as data ink; pie / donkey charts count arc sectors as data ink; and bar charts count rectangular bars as data ink. Axis elements, grids, and legends are uniformly counted as non-data ink, thus ensuring that the data ink ratios of different view types have comparable and semantically consistent statistical standards. The underlying data change signal Dv is calculated independently according to the view type and the bound data fields, and is generated in parallel with the visual ink signal. For time-series line charts, Dv is the sum of the absolute differences between the baseline record and the current record in the associated numerical fields; for funnel / stage bar charts, it is the sum of the absolute differences of the aggregated totals of each stage field; for category proportion charts (pie / donkey charts), Dv uses a share difference algorithm, including: Calculate the percentage of each category in the total, then sum the absolute values ​​of the differences between the percentages of each category to characterize the changes in category structure. For nested keyword-based typical category views (such as product category distribution), sum the absolute differences of each key after finding the union of the key sets of the category count mappings. For radar / ratio-based views, perform mapping differences on the transformed multi-dimensional ratio vectors. For scatter / brand momentum-based views, perform differences on the nested brand count mappings. For general views in manual mode, calculate the absolute value of the difference in the number of records with at least one valid value in the associated fields. All views (Dv) summarize the total global data change and write it to the comparison history for subsequent mixed evaluation.

[0069] After obtaining the visual ink change signal and the underlying data change signal, a normalized mixture score is calculated for each view (or each comparison in the historical sequence). Let the original data change be Dv and the original ink change be ΔIv. First, the maximum values ​​Dmax and ΔImax of each view (or each historical entry) within the current comparison window are taken as the normalization scale, and logarithmic compression normalization is applied.

[0070]

[0071] To mitigate the dominance of extreme values ​​on the overall ranking, the mixed score is defined as follows:

[0072] Where k represents the chart type, wdata(k) and wink(k) are type-adaptive weights that satisfy wdata(k) + wink(k) = 1. The default configuration uses wdata = 0.6 and wink = 0.4. For line charts that emphasize trend expression, the visual ink weight is increased, for example, wink = 0.55 and wdata = 0.45, so that changes in ratio and ink density have a greater weight in the overall evaluation. For pie charts / donut charts that emphasize classification ratios, the weight of the underlying data is increased, for example, wdata = 0.75 and wink = 0.25, so that the share difference signal dominates the mixed score. For bar charts, scatter plots, radar charts, etc., intermediate weights can be configured or the default ratios can be used. This strategy ensures that, under the same normalization framework, different types of charts achieve consistent and reasonable sensitivity allocation according to their analytical semantics.

[0073] The composite score further drives view-level interactive feedback. Focus intensity F is determined by both the emphasis coefficient and the ratio change.

[0074] Used to control the intensity of the card's highlight outline.

[0075] Focus scaling factor The relative change in the data ink ratio is used as the main scaling signal. The visual feature layer also outputs the direction of ΔR (increase / decrease / stable), intensity level (subtle / moderate / strong, with thresholds of 0.02 and 0.08 respectively), and ink density trend labels (more_data_ink / less_data_ink / stable), which are used for updating historical scatter plots, generating chart descriptions, and layout animations.

[0076] The above calculations are performed in the following order during the comparison process: After obtaining the baseline and current dashboard snapshot, the front end performs off-screen rendering of each view in parallel and calculates Rbase, Rcur, and ΔI; simultaneously, the metrics are submitted to the back end and written into viewDataInkChanges and totalDataInkChange in the comparison history; in the back end metrics stage, Dv is calculated according to the view type formula and written into viewDataChanges; when the user views a comparison point in the updated history panel, the Dv and ΔIv of that point are read, and after logarithmic normalization and type weighting, Sv is obtained as the comprehensive change intensity of that point in the scatter plot vertical axis or prompt information. Thus, the system respects both "visual data ink changes" and "underlying numerical / distribution changes" as evidence, and ensures the scientific nature and cross-viewability of the mixed score evaluation through chart type-aware weights and differentiated data algorithms. Figure 1 To the point of being responsive.

[0077] Based on the calculated uniform change score, trigger the awareness-driven view resizing interaction logic: When a user selects a candidate view for in-depth analysis, the system executes a smooth zoom animation, enlarging the selected view proportionally to its change score. Simultaneously, to maintain the integrity and non-destructive nature of the dashboard's overall layout, it proportionally compresses the space occupied by surrounding adjacent views. This strategy of allocating screen space based on the magnitude of change not only makes views with dramatic changes stand out more but also provides ample rendering area for subsequent detailed observation. After the view is zoomed in, this disclosure provides users with a View Lens tool independent of any specific visualization type. This lens, as an interactive floating layer, hovers above the current chart. It does not modify or disrupt the underlying visual encoding logic of the original chart (it does not reset color mapping or axes). Instead, it directly overlays and compares the system-saved pre-update and post-update snapshots within the local area covered by the lens at the pixel or element level. Through the lens, users can intuitively observe subtle differences at the element level, such as the color shift in map areas or the minute changes in the area ratio of pie chart sectors, thus satisfying the need for in-depth inspection of change details.

[0078] Step 6: Based on the timeline update summary and historical backtracking capabilities, support the mining of macro-level patterns in the time dimension.

[0079] This disclosure constructs a collapsible global update timeline panel that visualizes a series of historical update events as sequence nodes in chronological order. Each node on the timeline strictly corresponds to a previously constructed underlying data snapshot, and the height of this node on the vertical axis of the timeline directly encodes the magnitude of the overall change score calculated at the entire dashboard level for that data update. Specific details include: At the bottom of the dashboard, a collapsible global update history panel is provided. The ChangeScatterPlot component is embedded within the ChangeTrackingPanel, arranging the results of each data comparison as sequence nodes in chronological order. This supports macro-level pattern mining and historical backtracking over time. The panel is collapsible by default, and users can expand or collapse it using the toggle button in the title bar. When expanded, it presents a weighted change curve with a vertical axis scale. The horizontal axis represents time, and the vertical axis represents the intensity of change. Each historical update event falls on the curve as a scatter plot, and adjacent nodes are connected by a smooth cubic Bézier curve, forming a continuous time evolution trajectory.

[0080] After each successful data comparison, a comparison history record (ComparisonRecord) is automatically generated in the backend record_history_stage and appended to the session-level comparison history queue. This record is a structured encoding of a complete update process: the node identity is marked by a unique record identifier record_id, and the write time is marked by an ISO timestamp; old_date and new_date encode the upper bound of the baseline snapshot time window and the upper bound of the current snapshot time window covered by this comparison, respectively. The two together define the underlying data snapshot interval corresponding to this node—where new_date is the data cutoff time presented on the dashboard after this update, strictly corresponding to a data state that can be independently restored; at the same time, baseline_ref_date (global baseline anchor point) and previous_ref_date (the cutoff time of the last update of the same dataset) are recorded to form an update chain in manual / automatic mode. The record also persists a complete list of structured differences for this comparison, the set of affected fields and views, the underlying data change mapping for each view (view_data_changes), the total data change at the dashboard level (total_data_change), the factual weighted change ratio (incremental_change_ratio / cumulative_change_ratio), the composite factual change score (composite_fact_change_score), and chart-level semantic descriptions, constituting the complete semantic payload for that time point. After the front-end completes the calculation of the data ink index, it writes back the ink change (view_data_ink_changes) for each view and the total ink change at the dashboard level (total_data_ink_change) to the matching historical records through a dedicated interface, so that each node carries both visual and data-level change evidence.

[0081] The "overall change score" encoded by the vertical axis height of the timeline corresponds to the weighted mixed score Statotal of the Total sequence in the visualization layer. For the t-th update in the history queue, the total underlying data change Dt = totalDataChange and the total visual ink change It = totalDataInkChange (i.e., the sum of the absolute values ​​of the changes in the ink area of ​​each view) are taken. Within the currently visible history window, the maximum Dmax = maxtDt and Imax = maxtIt for all records are calculated respectively, and after logarithmic compression and normalization, we get:

[0082]

[0083] Then, weighted fusion is performed using the default weights wdata=0.6 and wink=0.4:

[0084] The score is mapped to screen coordinates using an adaptive scale on the vertical axis: first, calculate the padding nice scale interval [Smin, Smax] for all S values ​​in the visible sequence, then press:

[0085] Determine the vertical position of the node—the higher the score, the higher the node's position on the vertical axis. The horizontal axis positions are arranged in ascending order by record timestamp with equal spacing. (T is the total number of nodes).

[0086] The date labels at the bottom are taken from new_date (formatted as hour:minute in automatic mode, and month-day in manual mode), ensuring that the time encoding is consistent with the data snapshot cutoff time. In addition to Total, the system maintains independent sequences for each chart view, replacing Dt and It with viewDataChanges[viewId] and viewDataInkChanges[viewId] on the vertical axis, and displaying them overlaid on the same normalized scale, allowing users to switch between and view the evolution of a single view. The Total sequence is visible by default, while other sequences can be enabled as needed through the mini-dashboard control.

[0087] When a user clicks on a node on the timeline, historical backtracking is triggered: the selected record's record_id and optional view identifier are submitted to the restore_history_state interface. The backend uses this information to locate the target record, restores its new_date to the current data cutoff time, restores its baseline_ref_date (or old_date) to the comparison benchmark anchor point, and resets the dataset mode, field selection, and other context in the session state. Simultaneously, the frontend clears interactive states such as fact selection, chart focus, and visual links, writes the selected state (TimeTravelViewSelection), invalidates the cache, and re-fetches the dashboard snapshot and comparison results for the corresponding time, ensuring that the main canvas, semantic report panel, and timeline are consistent and revert to the data snapshot encoded at that historical node. If the user clicks on a node in a view sequence, the corresponding chart is highlighted in the dashboard with a sequence-specific color, and the updated chart-level semantic description is displayed. Clicking the same node again cancels the backtracking selection and returns to the current state.

[0088] In summary, this disclosure, through a closed loop of "comparison completion → structured historical record encoding → ink index write-back → timeline weighted scatter visualization → click node state restoration," compresses each underlying data update process into a measurable, interactive, and traceable semantic node on the timeline. The vertical axis directly carries the dashboard-level mixed change score, while the horizontal axis carries the time sequence, thus supporting analysts in identifying update intensity fluctuations, peak events, and evolutionary trends over long time spans. By simply clicking to select a node on the timeline, the system immediately retrieves the corresponding timestamp of historical snapshot data from the background and drives the entire dashboard interface to restore and re-render to its historical state at that time, thereby achieving direct global comparison across multiple discrete update events. In addition to the global perspective, the system also provides a dedicated view-level timeline for a single specific view in the dashboard. This view-level timeline is specifically designed to track and display the evolution trajectory of the change magnitude of this single chart across its own multiple update nodes. When a user clicks on a specific historical node on the view-level timeline, the system not only visually highlights and focuses on that view, but also simultaneously calls the Large Language Model (LLM). Based on the local data differences accumulated in that view during that time period, it dynamically generates a text summary describing the evolution of that specific chart structure, helping users to sort out structural changes or propagation patterns with long-term business value from the massive automatic refresh stream.

[0089] To ensure the efficient execution and cross-environment compatibility of the aforementioned complex technical solutions, this disclosure adopts a modern Web architecture with front-end and back-end separation. The overall system consists of five parts: browser-side interaction layer, HTTP service layer, analysis and orchestration layer, modular skills layer, and data state layer. Each layer is decoupled through stable data contracts, allowing it to evolve independently and be flexibly combined during development, testing, and deployment phases.

[0090] The browser-side interaction layer is built on React, TypeScript, and Vite to create a single-page application. Independent dashboard pages are mounted for both manual and automatic analysis modes, and client-side routing is implemented through React Router. Page-level components handle toolbars, dataset selection, comparison triggers, and layout control. Core visualization is driven by the Vega-Lite specification. `buildDashboardSpecs` converts backend snapshot data into the rendering specifications for each chart view, then embeds `ChartCard` and `DashboardGrid` to handle grid layout, focus zoom, lens inspection, fact highlighting, and visual link indicators. Global UI state is centrally managed by Zustand, including pattern / dataset, layout spacing, panel collapse, selected facts, time-backtracking selection, and visually associated source views. Server-side data retrieval and caching are handled by TanStackReactQuery, using custom hooks such as `useCompareFlow`, `useManualFlow`, and `useAutoFlow` to orchestrate snapshot fetching, comparison requests, history loading, and state restoration. The front-end has a separate protocol normalization layer (normalizeCompare, normalizeSnapshot) that deconstructs the back-end v2 unified response package into strongly typed domain objects, so that UI components do not need to be aware of the back-end's internal pipeline structure. Data ink ratio, view association graph, and timeline weighted score, which require browser-side geometry or scene graph analysis capabilities, are calculated locally after the front-end renders the Vega view off-screen, and the history is written back to the back-end through supplementary interfaces, achieving a clear division of responsibilities between the front-end and back-end.

[0091] The HTTP service layer is hosted by a Python Flask application, with a unified registration of the ` / api / *` routing blueprint. It exposes REST-style interfaces for health checks, dashboard snapshots, data comparison, dataset column metadata, historical comparison queries, historical state restoration, time window updates, and data ink metric write-back. The service enables cross-domain resource sharing to support front-end and back-end port-based integration in development mode. In production mode, front-end build artifacts (frontend / dist) can be statically hosted within the same Flask process, enabling single-port deployment and single-page application fallback routing. Upon request, the session identifier is parsed via cookies or request headers and bound to the in-process session store (SessionStore). Each user maintains an independent SessionState (including complete data caching, comparison history queues, baseline anchors, column selection states, etc.) to ensure state isolation under multi-user concurrency. All external responses are encapsulated in v2 protocol packets (including fields such as success, data, trace_id, and error code) and constrained by Pydantic / Zod-style validators to ensure stable front-end and back-end contracts and version consistency.

[0092] The analysis orchestration layer centers on a single control plane, DashboardAgent, exposing only three high-level operations: snapshot, compare, and update_range. Internally, it schedules three pipelines: run_snapshot_pipeline, responsible for loading data by time slice, filtering fields, and building dashboard snapshot payloads; run_compare_pipeline, responsible for the complete change detection and analysis loop; and update_range_pipeline, responsible for advancing the time window in manual / automatic modes. The orchestration layer uniformly handles input normalization (mode, dataset default values), anomaly capture, time consumption statistics, and degradation packaging. After the pipelines complete execution, map_snapshot_payload or map_compare_payload is called to map the internal results to a standard protocol structure that the front end can directly consume, thus supporting independent upgrades of backend skill modules without changing the front end.

[0093] The comparison pipeline is the core backend implementation path of this disclosed technical solution, and it is executed in a fixed phase sequence: data preparation and time window segmentation → parallel fact detection (run_detect_stage, including LLM planning and rule detector) → fact comparison and classification (run_compare_stage, producing Keep / Shift / Emerge) → difference formatting (run_format_stage, building field-view binding and deterministic summary, optional LLM semantic enhancement) → comprehensive scoring (run_score_stage, fusing point value amplitude, distribution offset and time effect) → metric calculation (run_manual_metrics_stage / run_auto_metrics_stage, including view-level data changes, weighting ratio and comprehensive fact score) → chart description generation (optional LLM) → historical record persistence (record_history_stage). Each stage is implemented using an independent Python module, with inputs and outputs being structured dictionaries or pandas DataFrames. There are no implicit global side effects between stages. When the LLM becomes unavailable or a stage malfunctions, the pipeline automatically degrades to a pure rule path and returns partial results with warnings, ensuring system availability. LLM integration is achieved through a configurable switch, an OpenAITextGen adapter, and API Key pass-through in request headers, supporting OpenAI-compatible endpoints and meeting compatibility requirements for different deployment environments.

[0094] The modular skills layer decouples specific algorithmic capabilities from the orchestration logic: skills / compare encapsulates fact detection, comparison, formatting, scoring, and metrics; skills / snapshot encapsulates snapshot loading and building; skills / narrative encapsulates fact summaries and chart description generation; skills / protocol encapsulates protocol mapping; and skills / compare / chart_contracts maintains static contracts for fields and views and dynamic aggregations of Vega specifications. The data layer loads raw data from CSV / JSON files through services / data / dataset_source and normalizes it into DataFrames or record lists. Downstream analysis logic relies only on a unified tabular intermediate representation, allowing it to be replaced with a database or data warehouse adapter without altering the front-end contracts and core pipeline. The configuration layer (config.py + .env) centrally manages service ports, data paths, LLM parameters, significance thresholds, and analysis budgets, facilitating rapid switching between different datasets and deployment scenarios.

[0095] The typical end-to-end interaction flow is as follows: After the user selects the mode and dataset and sets the baseline / current time on the front end, the front end requests the baseline and current snapshot in parallel; when the user triggers the comparison, the front end POSTs the time, column selection, dashboard specifications, and optional front-end visual features (data ink metrics) to / api / dashboard_compare; after the back end completes the pipeline, it maps the fact difference set, change metrics, historical preview, etc., into v2 packages and returns them; after normalization, the front end drives the semantic report panel, chart highlighting, and timeline refresh, and locally calculates the data ink change and writes it back to history; when the user clicks a timeline node, it calls / api / restore_history_state to restore the session time, invalidates the cache on the front end, and re-pulls the snapshot to achieve historical backtracking. This architecture, through the division of labor of "front end responsible for interaction and some visual metrics, back end responsible for data analysis and historical persistence, protocol layer responsible for contract alignment, and skill layer responsible for algorithm reuse," ensures the complete implementation of all the functions described in the invention while taking into account development efficiency, runtime performance, optional LLM degradation, and compatibility requirements for future data source expansion.

[0096] Example 2 One embodiment of this disclosure provides an interactive generation and presentation system for updating data visualization dashboards, including: The data acquisition module is used to continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot. The fact extraction module is used to extract structured data facts from data snapshots using the fact extraction engine; The change fact extraction module is used to compare and match structured data facts using a cross-snapshot comparison mechanism with an introduced detection function, calculate the overall difference magnitude of fact changes, and generate a basic fact difference set. The updated description generation module is used to quantify and score each changed fact based on the basic fact difference set, set format constraints, and use the format constraints and quantification scores as input to the large language model to generate updated description text. The view positioning module is used to present the update description text in the panel as a list, parse the underlying data fields and visual encoding mapping relationships corresponding to the update description text, and locate all chart views affected by the data update. The rendering interaction module is used to calculate the view change score for any view, trigger the perception-driven view adaptive scaling interaction logic based on the view change score, and use an interactive floating layer to overlay and compare the saved snapshot before and after the update in the local area covered by the lens at the pixel level or the primitive level.

[0097] Example 3 One embodiment of this disclosure provides a non-transitory computer-readable storage medium for storing computer instructions. When these computer instructions are executed by a processor, they implement the interactive generation and presentation method for updating data visualization dashboards.

[0098] Example 4 One embodiment of this disclosure provides an electronic device, including: a processor, a memory, and a computer program; wherein the processor is connected to the memory, the computer program is stored in the memory, and when the electronic device is running, the processor executes the computer program stored in the memory to enable the electronic device to execute the interactive generation and presentation method for updating data visualization dashboards.

[0099] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0100] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0101] While the specific embodiments of this disclosure have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of this disclosure. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of this disclosure are still within the scope of protection of this disclosure.

Claims

1. An interactive generation and presentation method for updating data visualization dashboards, characterized in that, include: Continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot; Use a fact extraction engine to extract structured data facts from data snapshots; By using a cross-snapshot comparison mechanism with an introduced detection function, structured data facts are compared and matched, the overall difference magnitude of fact changes is calculated, and a basic fact difference set is generated. Based on the set of basic fact differences, each changed fact is quantitatively scored, format constraints are set, and the format constraints and quantitative scores are used as input to the large language model to generate updated descriptive text. The update description text is presented in the panel as a list. The underlying data fields and visual encoding mapping relationships corresponding to the update description text are parsed, and all chart views affected by the data update are located. For any given view, calculate the view change score. Based on the view change score, trigger the perception-driven view adaptive scaling interaction logic. Use an interactive floating layer to overlay and compare the saved snapshot before and after the update within the local area covered by the lens at the pixel level or the primitive level.

2. The interactive generation and presentation method for updating data visualization dashboards as described in claim 1, characterized in that, The process involves continuously acquiring real-time data streams, triggering update operations, and passing the new data streams to the front-end view for rendering. The back-end saves the updated complete dataset state as an independent data snapshot, including: The system continuously accesses real-time data streams through a manual update mode triggered by user-preset conditions and an automatic polling mode that periodically captures new data. Whenever an update operation is triggered, the new data is directly passed to the front-end view for rendering, and the complete dataset state of the update is saved as an independent data snapshot on the back-end.

3. The interactive generation and presentation method for updating data visualization dashboards as described in claim 1, characterized in that, The process involves using a fact extraction engine to extract structured data facts from data snapshots, employing a cross-snapshot comparison mechanism with an introduced detection function to compare and match these structured data facts, calculating the overall magnitude of the differences in fact changes, and generating a basic fact difference set, including: The fact extraction engine extracts a set of structured data facts from the current data snapshot. These structured data facts include the overall trend of the data, the statistical distribution status, and the core numerical features of local extreme points. The cross-snapshot comparison mechanism is initiated to compare and match the currently extracted structured data facts with the corresponding data facts in the previous historical data snapshot. When the built-in detection function identifies whether the facts have changed significantly, it comprehensively considers the degree of mutation of local extreme values ​​and the overall difference of the global data structure to generate a basic fact difference set containing change labels.

4. The interactive generation and presentation method for updating data visualization dashboards as described in claim 1, characterized in that, The method of quantifying and scoring each changing fact based on the set of basic fact differences includes calculating a normalized comprehensive score for each difference record, as detailed below: Calculate the point value magnitude score, time effect score, distribution structure score, and confidence score respectively; The distribution structure score is calculated separately for each field type, which includes numerical samples and logarithmic samples. Finally, the point value magnitude score, time effect score, distribution structure score, and confidence score are weighted and fused to obtain the normalized comprehensive score.

5. The interactive generation and presentation method for updating data visualization dashboards as described in claim 1, characterized in that, The setting of format constraints, using the format constraints and quantitative scores as input to the large language model, generates updated descriptive text, including: The generation of updated description text is automatically triggered during the formatting stage, provided that a non-empty list of discrepancy records has been generated during the comparison and matching stage. After triggering, it is executed according to a two-level strategy: "deterministic draft priority, semantic model enhancement optional". First, iterate through each difference record, extract the change type, fact type, measurement field, subspace, old and new values, absolute change amount, and relative change rate context, and then concatenate them into a natural language draft according to a preset template; The structured context of all the difference records is serialized into a JSON batch, and a unified prompt word is constructed and sent to the large language model; Using the intensity of change in each view, the differences in related facts, and the time window as input, a sentence-level change summary is generated for each affected chart, resulting in updated descriptive text.

6. The interactive generation and presentation method for updating data visualization dashboards as described in claim 1, characterized in that, The update description text is presented in a list format on the panel. The underlying data fields and visual encoding mapping relationships corresponding to the update description text are parsed, and all chart views affected by the data update are located, including: Embed a semantic report panel independent of the chart rendering canvas in the user interface. This panel presents all data change facts in a list format. Each record includes a change type label, fact type, overall change score, and update description text, and is sorted by change priority and score. When a user clicks on a fact item in the semantic report panel, the selection or deselection is toggled, and the fact's identifier, pre-computed view binding set, and change type are written to the global interface state; at the same time, other conflicting interactive selection states are cleared. First, a pre-defined static mapping table of normalized field names to chart view identifiers is loaded according to the operating mode and dataset. If a dashboard specification object exists, the data fields actually referenced by each view are aggregated from the visualization specification. After field name normalization, the data fields are merged with the static mapping to form a complete field-to-view inverted index. Then, starting from the metric field of the fact and the inferred dimension field, all view identifiers referencing the corresponding fields are retrieved from the inverted index. These are then grouped and aggregated into bound records by view, and each field is labeled with its coded role in the view. Finally, a binding structure containing view identifiers, view paths, and field-role elements is formed and sent to the front end along with the difference set.

7. The interactive generation and presentation method for updating data visualization dashboards as described in claim 1, characterized in that, For any given view, a view change score is calculated. Based on this score, a perception-driven adaptive scaling interaction logic is triggered. An interactive floating layer is used to overlay and compare the saved pre-update and post-update snapshots within a local area covered by the lens, performing pixel-level or primitive-level rendering. This includes: Based on the view change score, the perception-driven view adaptive scaling interaction logic is triggered. When the user selects a candidate view, a smooth scaling animation is executed first, and the selected view is enlarged proportionally according to its change score. At the same time, the space occupied by other adjacent views around the selected view is compressed proportionally. The saved snapshot before the update and the snapshot after the update are overlaid and compared in a local area covered by the lens using an interactive floating layer at the pixel level or the primitive level.

8. An interactive generation and presentation system for updating data visualization dashboards, characterized in that, include: The data acquisition module is used to continuously acquire real-time data streams, trigger update operations, pass the new data streams to the front-end view for rendering, and the back-end saves the updated complete dataset state as an independent data snapshot. The fact extraction module is used to extract structured data facts from data snapshots using the fact extraction engine; The change fact extraction module is used to compare and match structured data facts using a cross-snapshot comparison mechanism with an introduced detection function, calculate the overall difference magnitude of fact changes, and generate a basic fact difference set. The updated description generation module is used to quantify and score each changed fact based on the basic fact difference set, set format constraints, and use the format constraints and quantification scores as input to the large language model to generate updated description text. The view positioning module is used to present the update description text in the panel as a list, parse the underlying data fields and visual encoding mapping relationships corresponding to the update description text, and locate all chart views affected by the data update. The rendering interaction module is used to calculate the view change score for any view, trigger the perception-driven view adaptive scaling interaction logic based on the view change score, and use an interactive floating layer to overlay and compare the saved snapshot before and after the update in the local area covered by the lens at the pixel level or the primitive level.

9. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium is used to store computer instructions, which, when executed by a processor, implement the interactive generation and presentation method for updating data visualization dashboards as described in any one of claims 1-7.

10. An electronic device, characterized in that, include: The device includes a processor, a memory, and a computer program; wherein the processor is connected to the memory, the computer program is stored in the memory, and when the electronic device is running, the processor executes the computer program stored in the memory to enable the electronic device to perform an interactive generation and presentation method for updating a data visualization dashboard as described in any one of claims 1-7.

Images