Data visualization analytical canvas with functionally independent visual containers

Abstract

In a computer system, a graphical user interface is displayed on a display. The graphical user interface includes: (a) a schema region displaying data field icons, each data field icon representing a corresponding data field from a user-selected data source; and (b) a canvas region. In response to receiving a user input selecting a data field icon from the schema region and arranging it on the canvas region, a block card is displayed on the canvas region. The block card includes user interface affordances indicating (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement; (ii) a mark type specifying a shape of a visual data mark; and (iii) one or more visual encodings. A data visualization of the data source is generated and displayed according to the layout type, mark type, and visual encodings specified in the block card.

Description

[Technical field]

[0001] (Related Applications) This application is a continuation of U.S. Provisional Patent Application No. 63 / 169,139, entitled "Blocks: Creating Expressive Chart Through Direct manipulation," filed on March 31, 2021, (2) U.S. Provisional Patent Application No. 63 / 291,335, entitled "Generating Expressive Data Visualization by Interacting With Data Fields Representations," filed on December 17, 2021, and (3) U.S. Provisional Patent Application No. 63 / 304,611, entitled "Data Visualization Analytical Canvas with Functionally Independent Visual Containers," filed on January 29, 2022, each of which is incorporated by reference in its entirety herein.

[0002] This application is related to U.S. patent application Ser. No. 17 / 589,696, filed Jan. 31, 2022, entitled “Generating Data Visualizations with Visual Data Marks Having Individually Calculated Grid Positions,” which is incorporated by reference in its entirety.

[0003] This application is related to U.S. Utility Patent Application No. 17 / 589,718, filed January 31, 2022, entitled “Generating Data Visualizations with Displayed Visual Data Marks Representing Aggregated Data at Multiple Levels of Detail,” which is incorporated herein by reference in its entirety.

[0004] FIELD OF THE DISCLOSURE Embodiments of the present disclosure relate generally to data visualization, and more particularly to systems, methods, and user interfaces that enable users to interact with data visualizations to analyze the data. [Background technology]

[0005] Data visualization applications enable users to visually understand data sets, including distributions, trends, outliers, and other factors important for business decision making. Some data sets are very large or complex, and include many data fields. The analytical workflow for analyzing large data sets typically involves iteratively exploring the data by progressively refining the data view, thereby discovering various trends and patterns within the data. There are a variety of visual analytics tools that can be used to help users represent and execute analytical workflows for visually exploring and analyzing data.

[0006] Even with the existence of such tools, creating expressive data visualizations is still a challenging task. For example, users must usually have a strong knowledge of data visualization and / or statistics. Most tools are difficult for non-experts to use. Some of these tools are expressive and allow users to create charts programmatically (e.g., declarative grammars allow developers to specify target visualizations using libraries and APIs), while others are easy to learn and more efficient to use for creating simple charts (e.g., chart pickers), but have limited expressiveness support or require tedious workarounds to build complex visualizations (e.g., the desired charts and / or analytical work flows may conflict with system defaults). Summary of the Invention

[0007] Thus, there is a need for visual data analysis tools that provide the ability to create expressive charts, yet are easily usable by non-experts through simple drag-and-drop techniques. For example, there is a need to analyze data at various levels of granularity while maintaining the ease of use of a direct manipulation model (e.g., drag-and-drop of user interface objects such as "pills" that represent data fields). As users seek to build richer visualizations, a need arises for more control over displaying information at multiple levels of detail, while at the same time maintaining the ease of use provided by a drag-and-drop interface. Additionally, there is a need for flexibility in layout and encoding.

[0008] The above identified needs associated with visual analysis tools for data are addressed by the devices, methods, and systems disclosed herein.

[0009] According to some embodiments, a method is performed on an electronic device having a display. For example, the electronic device may be a smartphone, a tablet, a notebook computer, or a desktop computer. The method includes displaying a graphical user interface on the display. The display includes (a) a schema region displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source, and (b) a canvas region. The method further includes receiving a first user input selecting a first data field icon from the schema region and placing the first data field icon on the canvas region. The method further includes, in response to receiving the first user input, displaying a block card on the canvas area, the block card including a plurality of user interface affordances indicating (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement, (ii) a mark type specifying a shape of the visual data marks, and (iii) one or more visual encodings specifying one or more of color, size, shape, text, x-axis, y-axis, ascending sort, descending sort, or level of detail according to a data value of the first data field represented by the first data field icon. The method further includes generating and displaying a data visualization of the data source according to the specified layout type, mark type, and visual encodings on the block card.

[0010] According to some embodiments, a method is performed on an electronic device having a display. The method includes displaying a graphical user interface on the display including: (a) a schema area displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source; and (b) a canvas area including a plurality of block cards, each block card specifying a respective layout type, the respective layout type being one of: (i) a row-based arrangement, (ii) a column-based arrangement, or (iii) an inline arrangement, each block card being generated in response to a user placing one or more of the respective data field icons on the canvas area. The method further includes generating and executing, for each block card, a respective database query to retrieve tuples of data for data fields associated with the respective block card. The method further includes calculating, for each retrieved tuple, a respective two-dimensional grid location including a respective row index and a respective column index. The method further includes generating and displaying a data visualization in which each retrieved tuple is represented as a visual mark displayed at the respective calculated grid location.

[0011] According to some embodiments, a method is performed in an electronic device having a display, the method including generating a plurality of interrelated block object specifications according to a user's arrangement of data field icons on a canvas area, each data field icon selected from a schema area displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source, each block object specification including: (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement; (ii) a mark type specifying a shape of a visual data mark; and (iii) one or more visual encodings specifying one or more of color, size, shape, text, x-axis, y-axis, ascending sort, descending sort, or level of detail according to a data value of the user-selected data field icon. The method further includes generating, for each block object specification, a respective query according to a user-selected data field icon that specifies a visual encoding for the respective block object specification, and executing the respective query to retrieve a respective set of tuples from the data source, each tuple including a data value for a data field that corresponds to the user-selected data field icon that specifies a visual encoding for the respective block object specification. The method further includes generating a data visualization according to a layout type, mark type, and visual encoding specified in each block object specification, wherein each tuple in each of the respective sets of tuples is represented in the data visualization as a visual mark.

[0012] According to some embodiments, an electronic device includes a display generating component (e.g., a touch screen, a display, a display of a head mounted device, etc.), one or more input devices, one or more processors, and a memory storing one or more programs, the one or more programs configured to be executed by the one or more processors, the one or more programs including instructions to perform or cause the performance of any of the operations of the methods described herein. According to some embodiments, a non-transitory computer readable storage medium has instructions stored thereon that, when executed by an electronic device having a display generating component (e.g., a display, a touch screen, a display of a head mounted device, etc.), cause the device to perform or cause the performance of any of the operations of the methods described herein. According to some embodiments, a graphical user interface on an electronic device comprising a display, a memory, and one or more processors executing one or more programs stored in the memory includes one or more of the elements displayed in any of the methods described herein, the elements being updated in response to an input as described in any of the methods described herein. According to some embodiments, an electronic device includes a display generating component (e.g., a display, a touch screen display, a display of a head mounted device, etc.), optionally a touch sensitive surface, and means for performing or causing the performance of any of the operations of the methods described herein. According to some embodiments, an information processing apparatus for use in an electronic device with a display generating component (e.g., a display, a touch screen, a display of a head mounted device, etc.) includes means for performing or causing the performance of any of the operations of the methods described herein.

[0013] Thus, a method, system and graphical user interface are disclosed that allows a user to easily interact with multiple related data visualizations. [Brief description of the drawings]

[0014] For a better understanding of the foregoing systems, methods, and graphical user interfaces, as well as additional systems, methods, and graphical user interfaces for providing data visualization analysis, please refer to the following detailed description in conjunction with the following drawings, in which like reference numerals refer to corresponding parts throughout the drawings, in which: [Figure 1A] 1 illustrates a graphical user interface for interactive data analysis and charting. [Figure 1B] 1 illustrates a block specification for a block object, according to some embodiments. [Figure 1C] 1 illustrates an example of two connected block objects and their respective block object specifications, according to some embodiments. [Diagram 2] FIG. 1 is a block diagram illustrating a computing device capable of displaying a block group graphical user interface including a generated data visualization, according to some embodiments. [Figure 3A] 1 illustrates an exemplary block group system, according to some embodiments. [Figure 3B] 1 illustrates an example block group user interface including connected block cards and corresponding partial output visualizations according to some embodiments. [Figure 3C] FIG. 1 illustrates a parent-child graph converted from an adjacency relationship, and row block trees and column block trees generated based on the parent-child graph, in accordance with some embodiments. [Figure 4A] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4B] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4C] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4D] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4E] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4F] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4G] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4H] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4I] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 4J] 1 illustrates an exemplary user interface for building and viewing data visualizations using an interactive graphical user interface, according to some embodiments. [Figure 5A] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5B] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5C] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5D] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5E] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5F] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5G] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5H] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5I] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 5J] 1 illustrates an exemplary user interface for building and displaying data visualizations in an interactive graphical user interface, including two or more data visualizations in the same user interface, according to some embodiments. [Figure 6A] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 6B] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 6C] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 6D] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 7A] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 7B] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 7C] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 8A]1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments. [Figure 8B] 1 is a flowchart of a system, method, and user interface for generating and displaying data visualizations, according to some embodiments.

[0015] Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] One tool for visual analysis is Tableau, provided by Tableau Software, Inc. Tableau provides VizQL™, a high-level formalism for specifying components and attributes of data visualizations. Tableau's graphical user interface for interactive analysis is shown in Figure 1A.

[0017] FIG. 1A illustrates a graphical user interface 100 for interactive data analysis and charting. According to some embodiments, the user interface 100 includes a data tab 114 and an analysis tab 116. When the data tab 114 is selected, the user interface 100 displays a schema information area 110, also referred to as a data pane. The schema information area 110 provides named data elements (e.g., field names) that can be selected and used to build a data visualization. In some embodiments, data fields included in the schema information area 110 default to one of measures or dimensions. For example, data fields that represent categorical data, such as string data fields, are treated as dimensions, and the various values ​​of the data field are used as categories. Also, data fields that represent numerical data, such as profit or sales, are treated by the system as measures, which are fields that are optionally aggregated using functions such as SUM, average, mean, etc. However, the user can also switch string fields, which usually default to dimensions, to measures and vice versa. For example, to analyze sales transactions within a range, a user may create categories for numeric ranges such as Under $1000, $1000-$10,000, $10,000-$20,000, ... and Over $50,000. A user may also treat each individual value as a category in itself. Another example of switching a data field to a measure is by modifying the string data field "Customer Name" by applying the function MIN to that field. Some embodiments also include a list of parameters. When the Analysis tab 116 is selected, the user interface displays a list of analysis functions rather than data elements (not shown).

[0018] The underlying formalism, VizQL™, supports the expression of charts through user interaction or direct manipulation of user interface objects in the graphical user interface 100, where the representation of the objects of interest (e.g., named data fields in the schema information area 110) is automatically transformed into a composite language syntax, thereby facilitating expressiveness and ease of use. For example, a user can build a chart by mapping the named data field representations in area 110 to visual attributes of a data visualization through drag-and-drop operations. As shown, the graphical user interface 100 includes a data visualization area 112, which has a large space for displaying visual graphics. Initially, there are no visual graphics in this space because no data elements have been selected yet.

[0019] The data visualization area 112 further includes a number of shelf areas, such as a column shelf area 120 and a row shelf area 122. In addition to the column shelf area 120 and the row shelf area 120, the graphical user interface 100 also includes shelves for visual encodings grouped into a marks card area 124. The visual encodings specify a mark type and encode data fields into the visual characteristics of the specified mark. Examples of such visual encodings include, but are not limited to, shape, size, color, hue, texture, and the like. Mark types include, but are not limited to, lines, bars, areas, squares, circles, text, maps, pies, Gantt bars, polygons, density marks, and other shapes that indicate tuples of retrieved data.

[0020] In the graphical user interface 100, a user selects user interface elements, e.g., "pills," that represent data fields and places them on one or more of shelf areas 120, 122, and mark area 124, which are particular targets within the graphical user interface 100. This process of user interaction is called direct manipulation. By selecting and placing various "pills" on shelf areas 120 and 121 and mark area 124, the data used (e.g., what data is retrieved from the data source) and the structure and visual attributes of the final visualization are controlled.

[0021] For data used in visualization, the underlying formalism VizQL™ uses the presence or absence of aggregations in generating queries based on the data fields selected and arranged on shelves 120 and 122 and the mark area 124. Data fields without aggregations are called dimensions (e.g., various categories), while measures are fields that are aggregated within groups defined by the set of all dimensions, also called levels of detail (LOD). For example, a measure is a quantitative value across all categories, such as profit or sales. In VizQL™, queries are defined using the arrangement of data fields on (1) the rows shelf 120 and (2) the columns shelf 122, and (3) all three of the marks area 124. For example, rather than determining the value of a measure at a level of detail that includes only dimensions from the rows shelf 122, the measure is aggregated within groups defined by all dimensions. Thus, there is a need to aggregate measures and apply visual encodings at different levels of detail for specific parts of a data visualization, rather than globally for the entire visualization. Thus, there is a need to display answers to queries that include aggregations at multiple levels of granularity within a single visualization, where multiple levels of granularity may require different visual encodings. Tableau and VizQL™ provide the ability to control the level of detail to which measures are aggregated via so-called LOD expressions. However, users must define LOD calculated fields using a calculation editor that forces users out of their analytical workflow. Using a calculation editor deviates from the direct manipulation model and also requires understanding of the formulas used in the calculation editor. Thus, there is a need to analyze data at various levels of granularity while retaining the ease of use of a direct manipulation model (e.g., drag-and-drop of user interface objects such as "pills" that represent data fields).

[0022] In terms of the structure of the data visualization, the rows shelf 120 and the columns shelf 122 are global. In other words, when a data field representation from the schema area 110 is placed on the rows shelf 122, a horizontal band is created across the entire visualization, and when a data field representation is placed on the columns shelf 120, a vertical band is created across the entire visualization. Such a formalism provides limited support for creating expressive visualizations with embedded microcharts that require nested relationships, such as rich tables with sparklines. Due to the global nature of the rows shelf 120 and the columns shelf 122, there is limited support for building nested relationships through direct manipulation (e.g., displaying sparklines within cells of a tabular data visualization).

[0023] Furthermore, with respect to the layout of the final visualization, the data fields placed on the row shelf area 120 and column shelf area 122 define "headers" in the final visualization if the data is discrete, or "axes" if the data is continuous. The marks card 124 specifies the type of marks for that visualization and the corresponding visual encoding, such as size, shape, and color. Although the headers define the overall layout of the visualization, they cannot be visually encoded in Tableau because only the fields placed on the marks card 124 are involved in creating the marks. However, in Tableau, the marks must be placed in a grid formed by the headers. For example, it is not possible to have a hierarchical table where the top level hierarchy is represented by a symbol rather than text (e.g., the headers are not marks and cannot be encoded into different shapes). Thus, flexibility in layout and encoding is needed, such as the ability to encode the headers and / or the ability to apply encoding at different levels of detail.

[0024] Thus, as explained above, the VizQL™ formalism allows users to create charts through direct manipulation, but what is needed is a way to create nested relationships, aggregate and encode at different levels of detail, and provide users with greater control over the layout of the final visualization (e.g., by creating charts that differ from the system defaults) while simultaneously maintaining the ease of use of the direct manipulation model that allows for the creation of interactive, iterative, and expressive charts. Currently, users implement workarounds that are inconvenient, cumbersome, and / or contrary to the direct manipulation model. These methods include, but are not limited to, (i) composing multiple visualizations on a dashboard to appear as one, (ii) writing complex calculations to determine the layout or format of elements in the final visualization, (iii) creating axes that have only a single value, and (iv) creating LOD expressions using the calculation editor. While LOD expressions provide users with more control to display answer questions with multiple levels of granularity in a single visualization, LOD calculated fields typically require users to define them in a calculation editor, requiring some understanding of Tableau expression syntax. This requires users to open menus, editors, and / or understand technical information that can be tedious and / or interrupt interactive, repetitive visual analysis through direct manipulation. As a result, users often spend a significant amount of time generating complex visualizations that contain rich tables. Although Tableau supports calculations that control the level of detail of measure aggregations, creating these calculations does not provide the ability to visually encode the results at any level of detail and takes users out of their analytical workflow. Thus, as users seek to build richer visualizations, a need arises for more control over displaying information at multiple levels of detail while simultaneously maintaining the ease of use provided by the drag-and-drop interface and data-driven flow.

[0025] The above mentioned limitations are addressed by a new system (called the Block Group System) that builds on top of VizQL and is based on a new formalism (called the Block Group formalism) that fits into the direct manipulation framework, where new analytical entities (called Block Objects or Blocks) are directly manipulated in the interface (e.g., data fields are selected and arranged on a canvas area, e.g., via drag-and-drop actions). Blocks are represented as Block Cards on the analytical canvas area of ​​the interactive user interface and are transformed into a representation according to the Block Group formalism.

[0026] The central unit of this formalism is an analysis entity called a block or block object. Figure 1B shows a block specification 150 of a block object 160, according to some embodiments. In some embodiments, each block object conforms to the block specification 150. In some embodiments, each block object includes the following attributes: block name 162, layout type 164, mark type 166, encoding 167, and optionally children 168. In some embodiments, optionally, a number of block objects are connected in a hierarchical structure (e.g., a tree structure formed by parent-child relationships between block objects). The connected block objects are converted to a local representation rather than the global row and column representation.

[0027] In some embodiments, a block object 160 is associated with a block name 162, a layout type value 164, a mark type value 166, one or more encodings 167, and optionally a child block object 168. The block name 162 is a unique identifier for the block object 160. In some embodiments, the block name 162 can include numbers, letters, or both numbers and letters and has any unique value. In some embodiments, the block object 160 is associated with an instance of one or more data fields that conform to a field instance description 170. For example, each field instance 109b conforms to the field instance description 170. Each field instance 109b used in an encoding 167 conforms to the encoding description 190 and is therefore associated with an encoding type 190a. The encoding type 190a conforms to the encoding type description 186.

[0028] In some embodiments, different instances of the same data field may be associated with different block objects or may be associated with the same block object. In some embodiments, multiple instances of the same data field may be associated with different encodings conforming to encoding specification 190. Each data field instance of block object 160 is associated with a particular field name 174 and, optionally, an aggregation 172. The value of field name 174 is based on the corresponding data field in the data source. The value of aggregation 172 is defined by or depends on an aggregation function supported by the data source for the respective data field. In some embodiments, data field instances for which an aggregation 172 is specified are used as measures. Other field instances without an aggregation are used as dimensions.

[0029] In some embodiments, a block object 160 represents a single query of its data source at a level of detail defined by the block object 160, and each query of the block object 160 results in a visual component being generated in the final data visualization. In some embodiments, the local level of detail of the block object 160 is defined by one or more encodings 167. Specifically, the local level of detail of the block object 160 is the union of the set of all dimensions used by the one or more encodings 167 of the block object 160. The full level of detail of the block object 160 is the union of the local LOD of the block object and the local LOD of all of its ancestors. Thus, the level of detail defined by the block object 160 is not defined globally for the entire visualization (e.g., based on the row and column shelves that apply to the entire visualization). In some embodiments, all of the measures used by the block object 160 are aggregated / evaluated at the full LOD of the particular block object 160 (e.g., not at a level of detail defined for the entire data visualization). This allows for greater flexibility in generating queries and visualizations at different levels of detail.

[0030] In some embodiments, the parent-child relationships between block objects form a directed acyclic graph (DAG). In some embodiments, a block object 160 can be a parent block object of one or more child block objects defined by an attribute "child block" 180. A child block object assigned to a child 168 conforms to a child specification 180 that specifies one or more child groups 180a to which the corresponding child block belongs. The particular group of child block objects to which each child object belongs conforms to a child group specification 182. Thus, the block group formalism defines a data visualization based on a single connected directed acyclic graph (DAG) of block objects, which allows nesting relationships between attributes within the visualization.

[0031] In some embodiments, in addition to defining the LOD of the block object 160, the one or more encodings 167 map the query results to visual and spatial encodings. Each field instance 109b encoded on a particular block may be mapped to one or more encodings of different types, such as color 186a, size 186b, shape 186c, text 186d, x-axis 186e, y-axis 186f, sort ascending 186g, sort descending 186h, and data detail 186i. In some embodiments, each encoding type 186a-186f appears at most once in the block object 160, except for the sort ascending 186g, sort descending 186h, and data detail 186i encoding types. In some embodiments, sort ascending 186g and sort descending 186h control the order of the query results of the block object 160, and ultimately the order in which the query results are rendered in the final visualization. Furthermore, by providing a means to encode measure data fields on the x-axis 186e and y-axis 186f at the level of the visualization component (e.g., not as part of a global tabular representation, as in VizQL), the block group formalism provides the ability to use visual encoding and evaluate measures at any level of detail (e.g., building sparklines and other microcharts within a table visualization without requiring workarounds that interrupt the analytical flow).

[0032] In some embodiments, a block object 160 renders one mark of its mark type 166 for each tuple in the corresponding query result set. The value of the mark type 166 conforms to the mark type specification 185. In some embodiments, the mark type includes various types such as text mark type 185a, shape mark type 185b, circle mark type 185c, line mark type 185d, and bar mark type 185e. In some embodiments, the mark type specifies the shape of the visual data mark.

[0033] In some embodiments, the layout type 164 determines how marks associated with the block object 160 are spatially laid out in the data visualization (e.g., the position of the marks in the data visualization). In some embodiments, the layout type 164 conforms to the layout type specification 175. Values ​​of the layout type 164 include row layout type 175a, column layout type 175b, and inline layout type 175c. In some embodiments, a block object 160 with row layout type 175a creates a row for each value in its region, with each row containing a single mark. For example, a block object with row layout type 175a and text mark type 185a generates rows that display text strings for each value in its associated region. In some embodiments, a block object 160 with column layout type 175b creates a column for each value in its region, with each column containing a single mark per column. In some embodiments, a block object 160 with inline layout type 175c renders its marks in a single shared space, such as a cell. In some embodiments, inline layout types 175 facilitate the creation of scatter plots, line graphs, area charts, maps, embedded microcharts, etc. In some embodiments, the block formalism is not limited to the creation of tabular charts, but can support other forms of complex visualizations such as Sankey diagrams and composite maps.

[0034] FIG. 1C illustrates an example of connected block objects “C” and “N” and their respective block specifications 1022 and 1024, according to some embodiments. Block objects “C” and “N” are represented by block cards 1012 and 1014 in an interactive user interface 1010, according to some embodiments. Block cards 1012 and 1014 are interactive graphical user interface objects that are generated in response to representations of data fields selected from a data pane being placed on the analysis canvas area 1010. A data visualization 1020 is generated based on the specified characteristics of block objects “C” and “N”. Block cards 1012 and 1014 visually represent the characteristics and encodings selected for block objects “C” and “N”. For example, block card 1012 indicates that block object “C” has a “row” layout type 1012b, and for example, in FIG. 1B, attribute “layout type” 164 is assigned the value “row” 175a. Thus, block object "C" generates visual component 1025 with a line-based arrangement as shown in data visualization 1020. Furthermore, block card 1012 indicates that block object "C" has a "text" mark type 1012a, e.g., attribute "mark type" 166 is assigned value "text" 185a in Figure 1B. Thus, one line of text string is displayed in data visualization 1020 for each value in the respective region of block object "C." For example, the dimension "Class" 1012d, representing the respective domains visually encoded on "Text" 1012c, includes three values ​​within the domain of data field "Class" 1012d, namely class values ​​"1", "2", and "3", and thus one row is generated for each class value (e.g., rows 1025a, 1025b, and 1025c), each representing each of the three marks extracted and containing the corresponding text string generated for block "C".

[0035] In some embodiments, arrow 1015 (or a chevron icon) between block card 1012 and block card 1014 represents a relationship between block "C" and block "N." For example, arrow 1015 represents that block object "C" is the parent of block object "N." Block description 1022 similarly indicates that block "C" is associated with one child block in a parent-child relationship, and that child block is block "N," e.g., block "N" is assigned to child 168.

[0036] In some embodiments, the block card 1014 visually represents attributes of the block "N". For example, the block card 1014 indicates that the block object "N" has an inline layout type 1014a, e.g., in FIG. 1B, the attribute "layout type" 164 is assigned a value "inline" 175c. In some embodiments, each block object generates a visual component, so the block object "N" generates a visual component 1026. Because block "N" is a child block of an inline layout type, the marks of block "N" are nested within rows 1025a-1025c, respectively. For example, because parent block "C" defines a row-based arrangement, the marks generated for block "N" follow the row-based arrangement. Additionally, the block card 1014 indicates that the block object "N" has a "bar" mark type 1014d, e.g., in FIG. 1B, the attribute "mark type" 166 is assigned a value "bar" 185e. Thus, a bar graph is created for each row 1025a-1025c. The data field "NumberSurvived" (e.g., number of people who survived), which is a measure, is encoded on the X-axis. In other words, instances of the field "NumberSurvived" are assigned the encoding type "X-axis" 186e, as shown in FIG. 1B. Because no additional dimensions have been added to the block object "N", the measure "NumberSurvived" is aggregated at the level of detail defined by the dimension "Class" 1012d, and a single bar is rendered per row, e.g., one bar for each class, e.g., one bar for each class value, as shown in the data visualization 1020.

[0037] In some embodiments, the layout of the block objects and their respective block cards in the interactive user interface (e.g., the positions of the block objects relative to each other) not only determines the relationships between the block objects, but also the layout of the visual components in the data visualization. For example, a block object "A" represented by a corresponding block card that is overlaid above another block card representing block object "B" generates and renders a visual component corresponding to block object "A" that is overlaid or displayed above another visual component generated based on block object "B". In some embodiments, a block object overlaid to the right or below a respective block object is automatically determined to be a child block of the respective block object. For example, block object "N" is determined to be a child of block "C" because block object "N" is overlaid to the right of block object "C". In some embodiments, a chevron icon or arrow 1015 displayed between block objects "C" and "N" indicates the direction of the nesting relationship between blocks "C" and "N". Additionally, visual component 1026 is displayed adjacent to the right of visual component 1025. In some embodiments, a block object with an inline layout type cannot have an associated block that is a child, and thus block objects that are arranged below or to the right of a block object with an inline layout type are defined or determined to be child blocks of the respective block object's parent block with an inline layout type.

[0038] In some embodiments, child block objects are laid out in the interface with respect to the position of their parent block. For example, when the parent block object of the respective block is a row-layout type, a set of child blocks that share the same row belong to the same child group (such as child group 182 in FIG. 1B). Similarly, when the parent block object of the respective block object is a column-layout type, a set of child blocks that share the same column belong to the same child group.

[0039] The block group formalism and methods described herein provide increased user control (e.g., expressiveness) and increased flexibility with layout and conditional formatting through direct manipulation of block objects in a user interface. Additionally, the block group system and block group formalism provide more granular control over the structure of the final visualization without having to interrupt the analytical workflow to, for example, open an editor to calculate fields.

[0040] 2 is a block diagram illustrating a computing device 200 capable of displaying a graphical user interface 2060, according to some embodiments. Various examples of computing devices 200 include desktop computers, laptop computers, tablet computers, and other computing devices having a display and a processor capable of executing a data visualization application 222. The computing device 200 typically includes one or more processing units / cores (CPUs) 202 for executing modules, programs, and / or instructions stored in memory 214 and thereby performing processing operations, one or more network or other communication interfaces 204, the memory 214, and one or more communication buses 212 for interconnecting these components. The communication bus 212 may include circuitry for interconnecting and controlling communication between the system components.

[0041] Computing device 200 includes a user interface 206 that comprises a display device 208 and one or more input devices or mechanisms 210. In some embodiments, the input device / mechanism comprises a keyboard. In some embodiments, the input device / mechanism comprises a "soft" keyboard that is optionally displayed on the display device 208, allowing a user to "press keys" that are displayed on the display 208. In some embodiments, the display 208 and input device / mechanism 310 comprise a touch screen display (also referred to as a touch-sensitive display).

[0042] In some embodiments, memory 214 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices. In some embodiments, memory 214 includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. In some embodiments, memory 214 includes one or more storage devices located remotely from CPU(s) 302. Memory 214, or alternatively the non-volatile memory device(s) within memory 214, includes a non-transitory computer-readable storage medium. In some embodiments, memory 214, or the computer-readable storage medium of memory 214, stores the following programs, modules, and data structures, or a subset thereof: · Operating System 216, which handles various basic system services and contains procedures for performing hardware-dependent tasks. · A communications module 218, used to connect the computing device 200 to other computers and devices via one or more communications network interfaces 204 (wired or wireless) and one or more communications networks, such as the Internet, other wide area networks, local area networks, metropolitan area networks, etc. · A web browser 220 (or other application capable of displaying web pages), allowing a user to communicate with remote computers or devices over a network. A data visualization application 222, which provides a graphical user interface 206 for a user to build a visual graphic. For example, a user selects one or more data sources 240 (which may be stored on the computing device 200 or may be stored remotely), selects data fields from the data source(s), and defines a visual graphic using the selected fields. In some embodiments, the information provided by the user is stored as a visual description 228. The data visualization application 222 includes a data visualization generation module 226, which receives user input (e.g., the visual description 228) and generates a corresponding visual graphic (also referred to as a "data visualization" or "data viz"). The data visualization application 222 then displays the generated visual graphic in the user interface 206. In some embodiments, the data visualization application 222 runs as a standalone application (e.g., a desktop application). In some embodiments, the data visualization application 222 runs within the web browser 20 or another application using web pages provided by a web server. Zero or more databases or data sources 240 (e.g., a first data source 240-1 and a second data source 240-2) for use by the data visualization application 222. In some embodiments, the data sources are stored as spreadsheet files, CSV files, XML files, flat files, or are stored in a relational database.

[0043] Each of the above identified executable modules, applications, or sets of procedures may be stored in one or more of the aforementioned memory devices and correspond to sets of instructions for performing the functions described above. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various embodiments. In some embodiments, memory 214 stores a subset of the modules and data structures identified above. Additionally, memory 214 may store additional modules or data structures not described above.

[0044] 2 illustrates a computing device 300, which is intended as a functional description of various features that may be present, rather than as a structural overview of the embodiments described herein, and in practice, items shown separately may be combined and some items may be separated, as will be recognized by those skilled in the art.

[0045] FIG. 3 illustrates a block group system 350 according to some embodiments. A front end 355 of the block group system 350 includes a block group interface 360 ​​(e.g., interactive graphical user interface 206) for constructing an analytical workflow based on connected block objects represented by block cards in the block group interface 360. In some embodiments, the block group system 450 creates block objects with corresponding block details represented by corresponding block cards, and provides an interface to the front end 355 for displaying (or viewing) the resulting data visualization, such as output visualization 370. In some embodiments, the block group interface 360 ​​and output visualization 370 are implemented using a React-based TypeScript module running in a web browser. In other embodiments, different libraries and programming languages ​​are used. In some embodiments, the front end 355 including the block group interface 360 ​​and output visualization 370 communicates with a back end 375 implementing a query execution process 380 and a row & column allocation process 390 via Hypertext Transfer Protocol Secure (HTTPS). In other embodiments, different communication protocols may be used for communication between the front end 355 and the back end 375. In some embodiments, the back end 375 is implemented using a data analytics library based on the Python programming framework. In other embodiments, different libraries and programming languages ​​may be used. In some embodiments, the back end 375 connects to Tableau Server data sources, thereby gaining access to rich data models.

[0046] In some embodiments, a user builds an analytical workflow by adding and connecting a number of block cards by arranging data field representations on an analytical canvas. For example, block interface 360 ​​includes an analytical canvas area that includes a number of block cards 362-368, each of which is converted to a respective block description, such as block description 150 of FIG. 1B. Block card 362 represents block object "R", block card 362 represents block object "S", block card 366 represents block object "C", and block card 362 represents block object "P". In some embodiments, multiple data field encodings are defined at a single level of detail (LOD) using each of block cards 362-368. In some embodiments, the block details include one or more measures aggregated by one or more dimensions and / or a level of detail determined by the respective block object (e.g., the union of the respective block object's local level of detail and the local levels of detail of all of the respective block object's ancestors), one or more visual encodings, a layout type specifying one of row-based arrangement, column-based arrangement, or inline arrangement, optionally one or more filters, and optionally a sort order.

[0047] In some embodiments, during a query execution phase 380 performed in backend 375, a query is issued for each block object based on the corresponding block specification. For example, a block query is issued for block object "R" represented by block card 362, a block query is issued for block object "C" represented by block card 366, and a block query is issued for block object "P" represented by block card 368. The block queries are executed on data sources 305, which may be remote or stored on the same computer system. The output of each block query is a block result set, which includes corresponding tuples retrieved from data source 305 and their respective encoded results. For example, a result table 362-1 is generated for block object "R", a result table 364-1 is generated for block object "S", a result table 366-1 is generated for block object "C", a result table 368-1 is generated for block object "P", etc., based on each query, tables with different schemas are generated.

[0048] In the next phase, according to some embodiments, the structure and layout of the final data visualization is determined by running a row & column assignment process 390 in the backend 375. The row & column assignment process 390 assigns each tuple in the result tables 362-1, 364-1, 366-1, and 368-1 a row index and a column index of a single grid. In some embodiments, the row indexes and column indexes form a grid (e.g., a collection of cells each having a unique position in the grid) that represents the layout of the data visualization. In some embodiments, there are two implicitly created root block objects that are not displayed in the block group interface 360, e.g., there are no block cards in the block group interface 360 ​​that visually represent the two root blocks. In some embodiments, the two root blocks are a row root block object (e.g., a root block object with a row layout type) and a column root block object (e.g., a root block object with a column layout type). In some embodiments, any block object that is of row-layout type and is not a child of an explicit block object (not implicit) is a child of the row root block object. Any block object that is of column-layout type and is not a child of an explicit block object is a child of the column root block object. In other words, any block object that does not have a parent is a child of the row root block object and the column root block object. In some embodiments, the implicitly created root block object is used as the starting point for calculating the row & column indexes.

[0049] An output visualization 370 is generated in which each tuple is represented as a visual mark according to its assigned row & column index. In some embodiments, grid row & column assignment process 390 distributes a number of marks corresponding to the tuples contained in tables 362-1, 364-1, 366-1, and 368-1. In some embodiments, output visualization 370 is displayed in the same user interface in front end 355, for example, adjacent to or near block group interface 360.

[0050] FIG. 3B illustrates an exemplary block group user interface 3010 including connected block cards 3002-3008 and corresponding partial output visualization 3020, according to some embodiments, which is generated according to the query execution process 380 and row & column assignment process 390 (described in connection with FIG. 3A). The block group system 350 performs the query execution process 380 before the row & column assignment process 390. In some embodiments, queries are first sorted by inherited LOD, so that all tuples with the same parent are kept together in the respective query results. Then, optionally, any sorting specified by the user is applied. In some embodiments, each returned tuple is assigned a global unique tuple identifier. The respective queries are generated based on the level of detail (local and inherited dimensions) and measures and sorting defined in each block description for each block card in the block group user interface. For example, Table 1 below shows the level of detail (local and inherited dimensions), as well as measures and sorts defined for each block card 3002-3008 in the blocks user interface 3010.

[0051] [Table 1]

[0052] In some embodiments, the tuples returned for each query generated based on block R (represented by block card 3002), block B (represented by block card 3004), block C (represented by block card 3006), and block G (represented by block card 3008), respectively, are shown in Tables 2, 3, 4, and 5 below. For example, Table 2 below represents the tuples returned based on a query generated for block R. The dimension "Region" is encoded with text, and the resulting tuples return text marks for each region in the dimension "Region" (e.g., "Europe and Central Asia", "America", "East Asia and Pacific", "Middle East and North Africa", "Sub-Saharan Africa", and "South Asia"), as shown in the data visualization 3020 shown in FIG. 3B. For example, a row is displayed for each region, such as a text mark 3022 for region "Europe and Central Asia", a text mark 3024 for region "Americas", and a text mark 3026 for region "East Asia and Pacific" (other regions listed in Table 2 are not shown in FIG. 3B for simplicity). In addition, since the user has applied a sorting order based on GDP per region, the GDP per region is calculated. For example, the resulting tuples (e.g., R1-R6) are sorted by GDP per region, e.g., Europe and Central Asia has the highest GDP (R1) and is first in the sorting order, and South Asia has the lowest GDP (R6) and is last in the sorting order, as shown in Table 2. In some embodiments, the resulting position of each tuple R1-R6 is determined according to a row & column assignment process 390.

[0053] [Table 2]

[0054] Table 3 below represents the tuples returned based on the query generated for block B, where the measure "GDP" is also aggregated (e.g., aggregated) by the dimension "region". The resulting tuples are encoded as bar graph marks, and a bar corresponding to each region is displayed in the data visualization 3020 of FIG. 3B. For example, a bar representing GDP by region is displayed for each region, such as bar 3028 representing GDP by region for region "Europe & Central Asia", bar 3030 representing GDP by region for "Americas", mark 3032 representing GDP by region for "East Asia & Pacific", and so on. Since block B, as a child of block R, inherits the number of dimensions of R, each bar is displayed for each row representing that region. Furthermore, since block B, as a child of block R, inherits the number of dimensions of block R, the sort order applied to block R is also the order in which each GDP by region bar is displayed in the data visualization 3020.

[0055] [Table 3]

[0056] Table 4 below represents the tuples returned based on the query generated for Block C, where the measure "GDP" is aggregated (e.g., aggregated) by country, the countries are text encoded, and the tuples are ordered by a user-defined sort that sorts all tuples based on the country's GDP for all countries in a given region. Since the dimension "country" is text encoded, the resulting tuples returned are represented as text marks for each country in a given region, as shown in the data visualization 3020 of FIG. 3B. For example, a column is displayed for each country, e.g., for the region "Europe & Central Asia", a text mark 3034 for country "Germany", a text mark 3036 for country "Italy", and a text mark 3038 for country "France" are displayed (the other countries listed in Table 4 are not shown in FIG. 3B for simplicity). Furthermore, the GDP of each country is calculated, since the user has applied a sort order based on the country's GDP. For example, the resulting tuples (e.g., C1-C50) are sorted by the GDP of each country within a given region, e.g., the United States has the highest GDP (C1) in the Americas and thus comes first in the sorting order for the Americas shown in Table 2, and Peru has the lowest GDP (C8) and thus comes last in the sorting order for the Americas (e.g., sorting of tuples C1-C8). Australia has the highest GDP (C9) in East Asia and Pacific and thus comes first in the sorting order for East Asia and Pacific shown in Table 2, and Myanmar has the lowest GDP (C18) and thus comes last in the sorting order for East Asia and Pacific (sorting of tuples C9-C18). In some embodiments, the resulting position of each tuple C1-C50 is determined according to a row & column assignment process 390.

[0057] [Table 4]

[0058] Table 5 below represents the tuples returned based on the query generated for block G, where the measure "GDP" is aggregated (e.g., aggregated) by country and the GDP by country is text encoded. Since the calculated measure "GDP" by country is text encoded, the resulting tuples are represented as text marks for each country in a given region, as shown in data visualization 3020 of FIG. 3B. For example, for each country represented by a column, the calculated GDP is displayed as a text mark, e.g., country "Germany" displays text mark 3040 ("36,953"), country "Italy" displays text mark 3042 ("36,073"), and country "France" displays text mark 3044 ("34,774") (GDPs of other countries listed in Table 5 are not shown in FIG. 3B for simplicity). In some embodiments, the resulting position of each tuple G1-G50 is determined according to row & column assignment process 390.

[0059] [Table 5]

[0060] In some embodiments, after the generated query for each block card is executed to return the resulting tables (e.g., Tables 2-5) with tuples, the block system assigns each tuple to its respective position in the final data visualization according to row & column assignment process 390.

[0061] In some embodiments, the block cards in the block group interface, such as the block cards 3002-3008 in FIG. 3B, form an adjacency graph. For example, adjacency graphs 3001 and 3001' represent the same adjacency graph for the block group user interface 3010, with 3001 being a graphical representation and 3001' being a textual representation. In some embodiments, the adjacency graph is used and converted into a parent-child graph that represents the relationships between the blocks in the block group user interface 3010, and is guaranteed to be a directed acyclic graph due to the implicit row root block and column root block implicitly created by the system. The parent-child graph is used in the row & column assignment process 390. For example, the adjacency graph 3001, determined based on the positions of the blocks 3002-3008 in the block group interface 3010, is converted into the parent-child graph 3050 shown in FIG. 3C. In some embodiments, creating the parent-child graph 3050 is a preliminary step of the row & column assignment process. In some embodiments, each block has a row and column parent. In some embodiments, if no user-defined parent exists, an implicit row block or column block is assigned as the respective parent. For example, block R has no parent, so the row root block and column root block are assigned as parents to block R. In some embodiments, children are ordered. In some embodiments, there are multiple children at the same ordinal position.

[0062] 3C shows a parent-child graph 3050 converted from the adjacency graph 3001 or 3001′. In some embodiments, the conversion starts from the top-left of the adjacency graph and proceeds in a breadth-first search. For example, the conversion algorithm starts by assigning block R as a child block of two implicitly created root blocks (not shown in the user interface), e.g., a row root block and a column root block, which are of row layout type and column layout type, respectively. The conversion algorithm proceeds to build the parent-child graph by performing the following steps: For a right-directed link (e.g., from left to right, if B1 is to the left of B2) between two blocks, a first block B1 and a second block B2, in the ordinal position after P, if block B1 is an inline block, add block B2 as a child of the row parent of the first block B1, and the second block B2 shares the ordinal position occupied by the first block B1, and also add the second block B1 as a child of the column parent of the first block B1. If block B1 is a row block, add the second block B2 as a child block of the first block B1, and also add the second block B1 as a child of the column parent of the first block B1, in the ordinal position after P. For a downward link between two blocks, i.e., the first block B1 and the second block B2, in the adjacency graph (e.g., B1 is above B2), add the second block B2 as a child of the row parent of the first block B1, and also add the second block B1 as a child of the column parent of the first block B1, in the ordinal position after P, if block B1 is an inline block. If block B1 is a column block, add the second block B2 as a child of the first block B1, and add the second block B1 as a child of the row parent of the first block B1, in the ordinal position after P.

[0063] In some embodiments, a textual description 3055 of the parent-child relationships of the parent-child graph 3050 is shown in FIG. 3C.

[0064] The row & column assignment process 390 begins by building a row tree and a column tree from the parent-child graph generated based on the blocks built in the block group user interface. For example, a row tree 3060 and a column tree 365 are built from the parent-child graph 3050 of the block group user interface 3010, which includes the block cards 3002-3008. In some embodiments, the row tree is built from the parent-child graph by considering only the links from the row blocks to their children and excluding other links. The block group interface 3010 ensures that this tree exists, is connected, and has a single root at the implicit row root block. For example, the root node of the row tree is the implicit root node, and the first link added is a link from the implicit root node to child block R. Next, child blocks B and C are added in the same ordinal position (e.g., tuples B and C each appear in the same row). Also, child block G is added as a child of block R. Since block G, being a row block, does not have a designated parent, block G is assigned the parent row block of block C, which is block R since block B is an inline block. In some embodiments, the column tree is constructed from the parent-child graph by considering only the links from the column blocks to their children and excluding other links. The block groups interface 3010 ensures that this tree exists, is connected, and has a single root at the implicit column root block. Block C is the only column block in the parent-child graph 3050. Blocks R, B, and C are child blocks of the implicit column root block. Since block C is the only column block, the only other child added to the column tree is the child of block C, which is block G.

[0065] In the next phase of the row & column allocation process, a row tuple tree and a column tuple tree are generated, where each tuple is a node. Since each block in the blocks user interface contains multiple tuples, dimensions are used to connect each tuple from a child block to a specific tuple in a parent block. For example, the process adds a tuple identifier for each tuple in the parent block in the row tree that has the same dimension value, and a tuple identifier for each tuple in the parent block in the column tree.

[0066] For example, Tables 6-9 below show how each tuple from a child block is connected to each tuple in a parent block based on row tree 3060 and column tree 3065 to generate row and column tuple trees according to some embodiments. For parent-child graph 3050, block R is a child of only the row root and column root, so every tuple has the row root and column root as its parent. Table 6 below shows connecting block R to the implicit (not shown) block, the root row, and the root column, which are parent blocks in row tree 3060 and column tree 3065, respectively.

[0067] [Table 6]

[0068] Table 7 below shows that block B is connected to block R, which is the row parent in row tree 3060, and to the root column (not shown) block, which is the column parent in column tree 3065. For example, in row tree 3060, block B is a child of block R. Thus, the row parent of each tuple from block B is the identifier of the tuple from block R that has the same value for region. In column tree 3065, block B is a child of the column root, and thus, all tuples have the column root as their parent, as shown in Table 7 below.

[0069] [Table 7]

[0070] Table 8 below shows that block C is connected to block R, which is its row parent in row tree 3060, and to the root column block (not shown), which is its column parent in column tree 3065. For example, in row tree 3060, block C is a child of row block R. Thus, the row parent of each tuple in block C is the identifier of the tuple from block R that has the same value for region. In column tree 3065, block C is a child of the column root, and therefore all tuples have the column root as their parent column block, as shown in Table 8 below.

[0071] [Table 8]

[0072] Table 9 below shows the connection of block G to row parent block R in row tree 3060 and column parent block C in column tree 3065. For example, in row tree 3060, block G is a child of block R. Thus, the row parent of each tuple in block G is the identifier of the tuple from block R that has the same value for region. In column tree 3065, block G is a child of block C. Thus, as shown in Table 9 below, the row parent of each tuple in block G is the identifier of the tuple from block C that has the same value for region and country.

[0073] [Table 9]

[0074] In some embodiments, the row & column assignment process 390 assigns a row index to each tuple by traversing the row tuple tree in depth-first order, and assigns a column index to each tuple by traversing the column tuple tree in depth-first order. Leaf tuples in the row or column tuple tree are assigned a single row index, and an interior node records the minimum and maximum row indexes of all leaves in the tuple. In some embodiments, a pre-sort is performed before the process assigns row and column indexes. For example, the row & column assignment process 390 sorts the children of each tuple first in the order in which their corresponding blocks appear as children in the row tree, and then, for each block, in the order of the row dimension and in the order of the user-specified sort, if any. Similarly, for the column tree, the process 390 sorts the children of each tuple first in the order in which their corresponding blocks appear as children in the column tree, and then, for each block, in the order of the column dimension and in the order of the user-specified sort, if any. In some embodiments, rather than pre-sorting, sorting is performed by controlling the order of depth-first traversal on the row and column tuple trees, respectively, i.e., sorting is performed in parallel with assigning row and column indexes.

[0075] For example, Table 10 shows pseudocode for a process of assigning row and column indexes to each tuple in the row tuple tree and column tuple tree when no pre-sorting is performed.

[0076] [Table 10]

[0077] Table 11 shows the indexes assigned to each tuple in the row tuple tree according to row & column assignment process 390 (e.g., according to the process of Table 10 above). For example, the "Min Row" and "Max Row" columns represent the indexes assigned to each tuple traversed using a depth-first search in the row tuple tree. For brevity, Table 11 includes data for "Europe and Central Asia" and "America" ​​and omits data for other regions.

[0078] [Table 11]

[0079] Table 12 shows the indexes assigned to each tuple in the column tuple tree according to row & column assignment process 390. For example, the "Min Row" and "Max Row" columns represent the indexes assigned to each tuple traversed using a depth-first search in the column tuple tree. For brevity, Table 12 includes data for "Europe and Central Asia" and "America" ​​and omits data for other regions.

[0080] [Table 12]

[0081] User Interface and Related Processes Attention is now directed to embodiments of user interfaces ("UI") and associated processes, which may be implemented on an electronic device, such as electronic device 200.

[0082] 4A-4J show example user interfaces for building and displaying data visualizations using an interactive user graphical user interface based on a block group formalism, according to some embodiments. FIGURES 5A-5G show example user interfaces for building and displaying two data visualizations on the same interactive user graphical user interface based on a block group formalism, according to some embodiments.

[0083] FIG. 4A illustrates an interactive graphical user interface 400 for interactive data analysis and charting through direct manipulation. Similar to Tableau, the graphical user interface 400 includes a data pane area 410 (or a schema area) that includes a number of data field representations of a selected data source. For example, the data pane area 410 includes a selected data source 412 and a collection 415 of data field representations (e.g., a name data field represented in the form of a selectable user interface element such as a pill). Each of the data field representations 421-429 is a user interface element or user interface affordance that can be selected and used to build a data visualization. In some embodiments, the data field representations 421-429 are also referred to as pills or data field icons. In some embodiments, the interactive graphical user interface 400 provides visual drag-and-drop techniques to encode the data fields, consistent with the direct manipulation model used in, for example, Tableau. In some embodiments, instead of the graphical user interface 100 being based on fixed shelves, such as the column shelf 120 and row shelf 122 of FIG. 1A, the interactive graphical user interface 400 has an analysis canvas area 440 that supports the creation of any number of connected block objects.

[0084] In some embodiments, the data field representations or pills included in the collection 415 are based on or derived from a data model from the connected data source 412. In some embodiments, similar to Tableau, the collection of data field representations 415 includes a number of data fields that are dimensions, e.g., data fields 421-434, 427, 428, 429, 430, 435, 437-439, and a number of data fields that are measures, e.g., data fields 425-426, 431-434, 436. The interactive user interface 400 further includes an analysis canvas area 440. One or more data field representations 421-439 are selected from the data pane area 410 and arranged on the analysis canvas area 440 to query the data source 412 and build a data visualization. In some embodiments, dimensions 421-434, 427, 428, 429, 430, 435, 437-439 can be used to define levels of detail (or groups to be aggregated), and measures 425-426, 431-434, and 236 can be calculated by aggregating at the levels of detail (also called LODs) defined by their respective dimensions. In some embodiments, dimensions 421-434, 427, 428, 429, 430, 435, 437-439 are visually distinct from measures 425-426, 431-434, for example using different colors, to indicate which data field representations are measures and which are dimensions.

[0085] In some embodiments, dragging out pill data 410 to an unoccupied location on the analysis canvas area 440 creates a block object on the graphical user interface 400, represented by a block card. In some embodiments, the computer system assigns default values ​​for the encoding, mark type, and layout type of the block object based on the metadata of the corresponding data field that the pill represents. For example, in FIG. 4A, a pill 421 representing a dimension named "Category" is selected and dragged across the analysis canvas area 440, as shown in FIG. 4B. FIG. 4B shows the pill 421 being dragged across the analysis canvas area 440 before the pill 421 is placed or dropped on the analysis canvas area 440.

[0086] In some embodiments, FIG. 4C shows that upon dropping pill 421, the computer system automatically (without further user input) generates block card 450, which is then converted into a block object specification that is used to generate and execute a query, and generate visual components 460 based on the results of the query. In some embodiments, the system generates a block object specification by default with a layout type of “row”, a mark type of “text”, and a data field “category” encoded in the text. In some embodiments, the layout type 442 and mark type 444 of the corresponding block object are displayed in the top band of block card 450. In some embodiments, layout type 442 is a user interface affordance that can be used to indicate a layout type including a row-based arrangement, a column-based arrangement, or an inline arrangement. In some embodiments, mark type 444 is a user interface affordance that can be used to indicate a mark type that specifies the shape of the visual data mark to be displayed in the final visualization. The respective encodings of the block objects are shown in block card 450. For example, a textual encoding of the data field "Category" is shown with a user interface element 446 (also called a user interface affordance) indicating that the encoding is to be textual, and pill 421 indicates the particular data field being encoded. Thus, a visual component 460 is generated that includes a row for each value in the domain "Category", where each value is represented by a textual description or string, e.g., values ​​"Furniture", "Office Supplies", and "Technology" are all discrete values ​​that belong to the domain "Category". In some embodiments, visual component 460 is generated substantially instantly as soon as the user places pill 421 on the analysis canvas. Block card 450 is included in block group user interface 445, and visual component is included in area 465 that contains the final data visualization.

[0087] In some embodiments, when an additional pill is dragged onto a blank (or unoccupied) space on the analysis canvas area 440, a new unrelated block object is created, e.g., a new block object unrelated to block C. In some embodiments, when an additional pill is dragged onto the block card 450, an additional encoding can be added to the block object C. In some embodiments, when an additional pill is dropped adjacent to the block card 450 (e.g., when the pill is dropped within the block group interface 445), a new block object related to the block object C is created. In some embodiments, the process of creating related block objects and adding further encodings to existing block objects is facilitated or assisted by displaying possible drop targets within the block group user interface. Thus, rather than forcing the user to decide which visualization type to create before exploring the data, the block group system and interface enables a data-driven experience by allowing the user to start with an empty analysis canvas and interact primarily with pills representing the user's data and block cards representing queries and visual encodings. Thus, the block group system enables a more interactive and iterative analysis flow.

[0088] 4D illustrates that, according to some embodiments, a number of drop targets are displayed when new pill 470 is dragged over block card 450. For example, when new pill 470 is hovered within block card 450, a number of icons 476a-476f are displayed that represent visual encodings, e.g., icons 476a-476f are shown in dashed lines within block card 450 and positioned below pill 470. For example, icon 476c represents a color encoding, icon 476d, icon 476d represents a shape encoding, icon 476e represents a text encoding, icon 476a represents an x-axis encoding, icon 476b represents a y-axis encoding, and icon 476f represents a level of detail. Additionally, drop targets 472 and 472 are also displayed to provide visual feedback that another block object can be created by dropping pill 470 adjacent to block card 450. In some embodiments, drop target 472 appears to the right of block card 450, and drop target 472 is below and represents a drop target for creating a child block object.

[0089] FIG 4D shows measure "discount" represented by pill 470 hovering over color encoding 476c (such as color encoding 186a in FIG 1B). FIG 4E shows updated block group interface 445 and updated data visualization area 465 in response to dropping pill 470 on color encoding 476c. For example, when pill 470 representing measure "discount" is dropped on color encoding 476c, visual component 460 is updated by displaying a different color for the aggregated "discount" measure at the "category" level. In other words, measure discounts are aggregated for each category, and the resulting aggregated values ​​are visually represented in a different color for each category, as shown in visual component 460.

[0090] In some embodiments, when the pill being dragged represents a dimension field, the system provides the option to create a new block object with either a row or column layout type. Dimension fields are encoded in text by default. In other embodiments, when the pill being dragged represents a measure field, the system provides the option to encode the measure in X-axis, Y-axis or text on a block object that defaults to an inline layout type. When a new associated block object is created, the layout type, mark type, and encoding can all be customized.

[0091] 4F illustrates a drop target 480 for creating a child block object that appears when the measure field "Profit" represented by pill 478 is being dragged over the analysis canvas area 440, according to some embodiments. Because pill 478 represents the measure "Profit," the system provides options to encode the measure "Profit" in the X-axis, Y-axis, or text on a block object defaulted to an inline layout type. Drop target 480 represents an optional block card (represented by dashed lines) with selected default encodings, such as encoding in the X-axis 482, encoding in the Y-axis 484, and encoding in text 486. Dropping pill 476 on drop target 480 creates a new child block of block "C."

[0092] FIG. 4G shows that as the user continues to drag the pill 478 over the analysis canvas area 440, the pill 478 is hovering over an encoding 482 on the X-axis within the drop target 480, according to some embodiments.

[0093] FIG. 4H illustrates an updated block group interface 445 and an updated data visualization area 465 in response to dropping a pill 478 onto the drop target 480 displayed in FIG. 4G, according to some embodiments. Dropping the pill 478 onto the x-axis encoding 482 creates a new block object "P", which is a child of the block object "C". A visual indicator 472a indicates the parent-child relationship between the two block cards 450 and 485. In some embodiments, the child block object "P" is represented by a block card 485. Since the pill 478 represents the data field "profit", which is a measure, by default the computer system assigns the inline layout type 488 to the block object "P". Furthermore, the computer system assigns the default mark type "bar" 489. For example, as shown in FIG. 1B, the computer system assigns the value 185e to the mark type 166 of the corresponding block description of the block object "P". Thus, the computer system creates a new visual component 462 that is displayed in the data visualization area 465. Because block object "P" is an inline block object that inherits the number of dimensions of block object "P", the system creates one bar for each row in visual component 460 defined by block object "C". Because no additional dimensions have been added to block object "P", the measure "Profit" is aggregated at the level of detail defined by the dimension "Category" and a single bar is rendered for each category value in visual component 462. In other words, profit is calculated for different categories and for each category, a single bar is displayed that represents the aggregated profit. Note that because no color encoding has been added to block object "P", each bar is represented in the same color.

[0094] FIG. 4I illustrates a user dragging a selected pill 492, which represents the jar data field "number of records," according to some embodiments. In some embodiments, in response to a user selecting a data field representation from the data pane 410 (or schema area), appropriate drop targets are displayed in the blocks user interface 445. For example, in response to selecting pill 492, a number of drop targets are displayed in block card 485. Each drop target in block card 485 represents a respective visual encoding that conforms to encoding type specification 186 shown in FIG. 1B. In addition, user interface elements 4002 and 4004 are displayed to indicate that a new block object can be added by placing selected pill 492 in the right or lower area of ​​block card 485. In addition, since pill 492 represents a measure data file, the computer system further displays drop target 495, which, upon selection, creates an inline layout type block object. For example, in response to placing pill 492 on drop target 495, an inline layout type block object is created. Additionally, because pill 478 represents the measure "record count," the system by default provides the option to encode the measure "record count" as X-axis, Y-axis, or text on block objects that are assigned the inline layout type by default.

[0095] FIG. 4I illustrates a pill 492 hovering over a color encoding (such as color encoding 186a in FIG. 1B) in a block card 485, according to some embodiments. As shown in FIG. 4J, in response to dropping or placing pill 492 over a color encoding in block card 485, visual component 462 is updated according to the selected color encoding. For example, visual component 462 is updated by displaying a different color for the measure "Record Count" aggregated at the "Category" level of detail. In other words, since block object "P" does not define further dimensions, the measure "Record Count" is aggregated by category defined by parent block "C" and the resulting aggregated values ​​are visually represented with a different color for each category.

[0096] 5A-5G illustrate building a second data visualization on the analysis canvas 440 according to some embodiments.

[0097] 5A illustrates a user dragging a pill 502 onto the analysis canvas 440 and the block outside interface 445, where the pill 502 represents a dimensional data field "Segment," according to some embodiments. In some embodiments, the pill 502 is dragged into blank (or unoccupied) space on the analysis canvas area 440, thus creating a new unrelated block object, e.g., a new block object unrelated to block object "C" and unrelated to block object "P."

[0098] 5B illustrates that in response to placing the pill 502 on the analysis canvas 440 and outside the block group interface 445, a new data visualization is constructed and displayed in the data visualization area 500, according to some embodiments. In response to placing the pill 502 in an unoccupied area of ​​the analysis canvas 440, a new block object "S" is created and a corresponding block card 504 is displayed. Furthermore, in response to placing the pill 502 in an unoccupied area of ​​the analysis canvas 440, a corresponding visual component 506 is constructed and displayed in the data visualization area 500. In some embodiments, the data visualization areas 456 and 500 display two unrelated data visualizations. In other words, the block object "S" does not form any parent-child relationship with the block objects "C" and "P", and therefore does not inherit any dimension number or encoding from the block objects "C" and "P". Thus, a user can use the same drag-and-drop techniques to build two data visualizations on the same analytical canvas without having to interrupt their analytical flow, for example by creating a new separate sheet or tab that would require the user to switch between the two sheets or tabs.

[0099] The computer system assigns default values ​​for encoding, mark type, and layout type for block object "S" based on metadata for the corresponding data field that pill 502 represents. For example, because pill 502 represents the dimension "Segment", the computer system automatically assigns a line layout type (e.g., line layout type 175a shown in FIG. 1B) to block object "S", as indicated by user interface element 508. Additionally, the computer system assigns text as the mark type (e.g., mark type, text 185a shown in FIG. 1B) because the data field "Segment" is a dimension with discrete values ​​(rather than continuous values), as indicated by icon 510. In some embodiments, values ​​already assigned to mark type and layout type can be modified by interacting with the block card displayed in the interactive user interface.

[0100] FIG. 5C illustrates a cursor selecting user interface element 508a to change the default layout type of block object "S" according to some embodiments. According to some embodiments, when user interface element 508a is selected, a drop-down menu displays a list of possible choices of layout types from which the user can select, including row, column, and inline layout types, as shown in FIG. 4D. FIG. 5D illustrates that a column layout type is selected as the new layout type for block object "S". In response to the layout type being changed from a row layout type to a column layout type, visual component 506 is updated accordingly to reflect the column layout type, as shown in FIG. 5E. For example, updated visual component 506 displays one column for each value in region "Segment".

[0101] 5F illustrates that a pill 514 representing the measure "profit" is selected and placed over the drop target 516, according to some embodiments. Upon placing the pill 514 over the drop target 516, a child block "P" is automatically created and a corresponding block card 518 representing the block object "P" is displayed in the blocks user interface 520. Because the pill 514 represents a measure and the layout type is column-based, the block object "P" defaults to a bar chart as the mark type, with the profit value for the particular segment defaulting to the Y-axis. In response to the block object "P" being constructed, a visual component 507 is added that displays the profit per segment as a bar chart mark type.

[0102] In some embodiments, the block group user interface 520 is different from the block group user interface 445, each of which is used to build a separate data visualization. In some embodiments, the block cards are automatically resized to accommodate the data field representations placed within them. Similarly, according to some embodiments, the data visualizations are automatically resized to accommodate additional block cards or additional data visualizations that are added to the analysis canvas.

[0103] FIG. 5H illustrates a rich table 530 showing data for Seattle Airbnb listings being created using the block group system and block group user interface, according to some embodiments. FIG. 5H illustrates various mark types and measures at several levels of detail combined into a single visualization displayed in the data visualization area 535. Each column 532-540 (or visual component) of the rich table 530 is defined by a block object with its own set of encodings and field mappings. For example, each block card 542-550 corresponds to a block object specification on which the visual components 532-540, respectively, are built. According to some embodiments, the columns 532-540 show, from left to right, rows for each neighborhood group sorted by average list price, a labeled bar graph showing average price color-coded by occupancy rate, rows for each neighborhood within each neighborhood group, the same labeled bar graphs but showing average price per neighborhood, and a sparkline showing average price over time.

[0104] While the block group system and block group formalism can be used to create complex rich tables, such as rich table 530, the block group formalism can also be extended with additional layout algorithms to support other visualizations, such as treemaps, bubble charts, and non-rectangular charts. Additionally, the block group formalism used to define rich tables at multiple LODs may be applied to support other visualization types, such as Sankey diagrams and composite maps.

[0105] 5I illustrates a composite map visualization 530 and respective block cards in a block user interface used to build the map visualization 530, according to some embodiments. The composite map visualization 530 shows multiple "state" polygons as parent blocks and nested therein a sparkline chart with sales by order date. According to some embodiments, the map visualization 530 is built using an inline layout type block object for map with a sparkline block object as a child block.

[0106] Sankey diagrams are a common type of chart created in Tableau, but their creation is a multi-step process involving splitting views, densifying data, indexing values ​​across different visual dimensions, and several table calculations. According to some embodiments, a block group system can be used to build n-level Sankey diagrams using 2n-1 block objects, as shown in FIG. 5J. For example, in FIG. 5J, nodes of Sankey diagram 570 are generated for attributes or data fields of "Region", "Category", and "Segment" using row type block objects represented by block cards 572, 576, and 580, and link type block objects represented by block objects 574 and 578 represent connections between levels. Link layout type block objects inherit LOD from neighboring block objects and render curved lines between pairs of marks. Links are encoded by color and size based on the sum of sales, for example, as indicated by the aggregation function SUM(Sales) applied to the measure "Sales".

[0107] 6A-6D are flow diagrams illustrating a method 600 for generating layouts and components of a data visualization by interacting with data field representations, according to some embodiments. Method 600 is performed on an electronic device (e.g., device 200 of FIG. 2). In some embodiments, the electronic device is a portable multifunction device comprising a display and, optionally, a touch-sensitive surface. In some embodiments, the display is a touchscreen display and the touch-sensitive surface is on or integrated with the display. In some embodiments, the display is separate from the touch-sensitive surface. Some operations of method 600 are optionally combined and / or the order of some operations is optionally changed.

[0108] As described herein, the method 600 allows for the construction of visualizations by specifying the layout, data relationships, and level of detail ("LOD") of specific parts of the visualization, rather than the entire data visualization. A user can create block objects by direct manipulation or interaction with data field representations, for example, by using drag-and-drop interaction. The method allows for control of LOD of data attributes for tabular visualizations. The method provides the ability to evaluate measures at any LOD using visual encoding and drag-and-drop interaction. The method allows for the creation of expressive and rich charts through drag-and-drop interaction. The method provides a visual analysis interface, allowing users to iteratively build analysis workflows without the need to learn grammar or low-level implementation details. Additionally, the method assists users by providing recommendations and various visual indicators while the user is creating a chart, while improving the efficiency and flexibility of the chart creation process.

[0109] A computer system having one or more processors, a display, and a memory storing one or more programs configured to be executed by the one or more processors displays on the display a graphical user interface (e.g., graphical user interface 400 of FIG. 4A and graphical user interface 206 of FIG. 2) including (a) a schema area (e.g., data pane or schema area 410 of FIG. 4A) displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source, and (b) a canvas area (e.g., canvas area 440 of FIGS. 4A-4B) (602). The computer system receives a first user input selecting a first data field icon from the schema area and placing the first data field icon on the canvas area (e.g., FIG. 4B shows a user-selected user interface element 421 representing a data field “category” that is a dimension) (604).In response to receiving the first user input, the computer system displays a block card (e.g., block card 450 of FIG. 4C ) on the canvas area (e.g., canvas area 440 of FIGS. 4A-4B ), where the block card includes (i) a layout type that specifies a row-based arrangement, a column-based arrangement, or an inline arrangement (e.g., user interface element or affordance 442 of FIG. 4C that is currently assigned a row-based arrangement), and (ii) a mark type that specifies a shape of the visual data mark (e.g., user interface element or affordance for specifying and displaying mark type 442 of FIG. 4C ). affordance 444) and (iii) one or more visual encodings specifying one or more of color (e.g., icon 476c of FIG. 4D ), size, shape (e.g., icon 476d of FIG. 4D ), text (e.g., icon 476e of FIG. 4D ), x-axis (e.g., icon 476a of FIG. 4D ), y-axis (e.g., icon 476b of FIG. 4D ), ascending sort, descending sort, or detail level (e.g., icon 476f of FIG. 4D ) according to the data value of the first data field represented by the first data field icon (608). In response to receiving the first user input, the computer system further generates and displays a data visualization of the data source (e.g., the data visualization displayed in area 465 of FIG. 4C-4J ) according to the layout type, mark type, and visual encodings specified on the block card (610).

[0110] In some embodiments, generating and displaying a data visualization of the data source according to the layout type, mark type, and visual encoding specified on the block card includes defining a level of detail according to the dimension data fields that specify the visual encoding on the block card, generating a query for the block card that specifies an aggregation of each measure data field according to the dimension data fields at that level of detail, executing the query to retrieve a set of tuples from the data source, where each tuple includes each of the data fields whose data field icons specify a visual encoding, and where each of the measure data fields is aggregated according to its level of detail, and generating a data visualization where each visual mark corresponds to one of the retrieved tuples (612).

[0111] In some embodiments, the block card is a first block card. The computer system receives a second user input selecting a second data field icon from the schema area (e.g., FIG. 4D shows cursor selection icon 470 representing the "Discount" measure) (614). In response to receiving the second user input, the computer system displays drop targets on the first block card (e.g., as shown in FIG. 4D, icons 476a-476f representing visual encodings are displayed to the user as options to be selected, e.g., as drop targets), each drop target on the first block card designating a respective visual encoding that may be selected for association with the second data field icon. In response to receiving the second user input, the computer system displays drop targets adjacent to the first block card (e.g., as shown in FIG. 4F, drop targets 480 for block objects in an inline-based arrangement are displayed in response to a user input selecting icon 478 representing the "Profit" measure), each adjacent drop target designating a separate option for creating a child block card or a parent block card related to the block card.In response to the user placing the second data field icon on (i) one of the drop targets of the first block card or (ii) one of the adjacent drop targets, the computer system generates and displays an updated data visualization (e.g., FIG. 4E shows the updated visualization displayed in area 465 of FIG. 4D after the user has encoded the measure “discount” into color, thereby making each row in visual component 460 a separate color), with the layout type, mark type, and visual encoding being determined according to the user's placement of the second data field icon (e.g., according to whether the user places the data field icon on a drop target in the block card or on an area adjacent to the block card that is not occupied for an independent data visualization, such as below or to the right for a child block, or above and to the left for a parent block, to visually encode the currently displayed visual component of the data visualization). In some embodiments, the second data field icon is placed on one of the drop targets of the first block card, and the visual encoding of the visual component corresponding to the first block card is updated (e.g., as shown in FIGS. 4G-4H, the second visual component 462 is created in FIG. 4H after the user places the data field icon 478 representing the measure "profit"). In some embodiments, when the second data field is placed on one of the adjacent drop targets, the second block card is created and a default layout type, mark type, and / or visual encoding is assigned according to the data value of the data field corresponding to the second data field icon (e.g., since the data field icon 478 represents the measure "profit", an inline layout type is automatically assigned). Providing drop targets, optionally within or adjacent to a particular block card, assists the user in building a data visualization.In some embodiments, the drop targets have default pre-selected values ​​for layout type and / or mark type based on whether the data field associated with the selected data field representation is a dimension or a measure. The drop targets assist the user in the iterative and interactive process of building a data visualization. In some embodiments, the drop targets appear immediately when the user drags (e.g., dynamically) a data field representation from the schema area, thereby providing the user with the ability to encode data fields at any level of detail and aggregate measures via drag-and-drop actions. The drop targets also provide a mechanism for the user to build relationships between block objects by placing data field representations on the proposed targets. In some embodiments, the user can manually change the system's default selection.

[0112] In some embodiments, the second data field icon is placed over one of the drop targets on the first block card, thereby adding a visual encoding based on the second data field corresponding to the second data field icon (616). In some embodiments, if the measure data field is color-encoded, aggregations of the values ​​of the measure data field according to the corresponding dimensions specified on the first block card are assigned different colors that indicate their respective aggregated values ​​for a particular level of detail determined by the dimension fields specified on the first block card. For example, if the dimension field "Category" is encoded on the first block card and the "Discount" measure is color-encoded, each aggregated value determined for each "Category" data field value is assigned a different color (e.g., FIG. 4E shows that if the measure "Discount" is color-encoded, a separate color is displayed for each of the aggregated discount values ​​for each "Category"). The method provides drop targets (e.g., drop targets for visual encodings 476a-476f that allow a user to visually encode a data field associated with a block object whose block card is displayed in the block group user interface. The drop targets assist the user by providing available encodings for a selected target data field representation. This method reduces the number of inputs required to encode a data field on a particular block card.

[0113] In some embodiments, the second data field icon is placed on one of the adjacent drop targets, thereby forming a second block card that is a parent or child of the first block card, and generating an updated data visualization includes generating a data visualization according to the layout type, mark type, and visual encoding specified on the first block card and the layout type, mark type, and visual encoding specified on the second block card (618). This method assists the user in building parent-child relationships between block objects. For example, to build a child block, the user is only required to place a selected data field representation on one of two drop targets used to build the child block object (drop targets for adjacent child block cards / objects, such as 472 and 474 in FIG. 4D, and drop target 480 for adjacent block object in FIG. 4F).

[0114] In some embodiments, the drop target displayed adjacent to the block card is determined based on whether the second data field icon represents a dimension data field or a measure data field (e.g., block card 480 displays the block card with an inline-based arrangement because the data field icon selected by the user represents the measure "profit") (620). Adjusting the drop target based on whether the selected data field is a dimension or a measure assists the user by providing pre-selected block details appropriate for the selected data field. The visual recommendations assist the user in the process of building the data visualization, reducing the number of entries and / or reducing the user's mistake of selecting an inappropriate block detail.

[0115] In some embodiments, pursuant to a determination that the second data field icon represents a dimension data field, the computer system includes adjacent drop targets to the block card, a first drop target that specifies a row layout type and a second drop target that specifies a column layout type (622). Upon determining that the selected data field is a dimension, the method 600 automatically provides the user with an appropriate layout type, such as one of a row layout type or a column layout type. Providing the user with an appropriate layout type assists the user in building the block card specification. The preselected recommendation for the layout type assists the user in the process of building the data visualization, reducing the number of inputs and / or reducing the user's mistake of selecting an inappropriate block specification.

[0116] In some embodiments, pursuant to a determination that the second data field icon represents a measure data field, the computer system displays a drop target specifying an inline layout type (624). When the method 600 determines that the selected data field is a dimension, it automatically provides the user with appropriate layout types, such as row layout and column layout types. Providing the user with appropriate layout types assists the user in building a block card description. The pre-selected recommendations for layout types assist the user in the process of building a data visualization, reducing the number of entries and / or reducing user mistakes of selecting an inappropriate block description.

[0117] In some embodiments, if the second block card is a child of the first block card, generating the updated data visualization includes (i) defining a first level of detail according to a dimension data field that specifies a visual encoding on the first block card (626). The method further includes defining a second level of detail according to (i) the dimension data field that specifies a visual encoding on the first block card and (ii) the dimension data field that specifies a visual encoding on the second block card. Further, the method includes generating a first query for the first block card that specifies an aggregation of each measure data field associated with the first block card according to the dimension data field at the first level of detail. Further, the method includes generating a second query for the second block card that specifies an aggregation of each measure data field associated with the second block card according to the dimension data field at the second level of detail. Further, the method includes executing the first query to retrieve a first set of tuples from the data source. The method further includes executing a second query to retrieve a second set of tuples from the data source, and generating an updated data visualization including a first visual mark representing each of the first set of tuples and a second visual mark representing each of the second set of tuples. The full LOD of a block object is the union of the local LOD of the block object and the local LODs of all of its ancestors. Inheriting the level of detail from a parent block object provides the ability to build nested relationships within the data visualization. The method provides a user with a visually expressive way to handle nested relationships during chart generation by using drag and drop as an interaction style.

[0118] In some embodiments, when the user places the second data field icon over one of the adjacent drop targets, the computer system displays a visual indicator that represents a hierarchical relationship between the first block card and the second block card (628). Displaying a visual indicator that represents a hierarchical relationship provides the user with visual feedback regarding the layout of the block cards and their relationships to each other, such as a parent-child relationship between the two block cards (and associated block objects) (e.g., visual indicator 472a in FIG. 4H indicates a parent-child relationship between the two block cards 450 and 485).

[0119] In some embodiments, the visual positioning of the first and second block cards relative to each other on the canvas area determines the relative placement of the visual markings of the first and second block cards in the data visualization (630). In some embodiments, the layout of the block cards in the canvas area directly determines the layout of the corresponding visual components in the data visualization (e.g., as shown in FIG. 4H, visual component 460 is displayed to the left of visual component 462 corresponding to block card 450, which is displayed to the left of block card 485). For example, when block A is placed above block B, the visual component of the data visualization corresponding to block A is displayed above the visual component corresponding to block B. This method allows users to build the layout and structure of the data visualization based on the placement of the block cards on the canvas area through direct interaction with drag-and-drop operations. This allows users to build more expressive charts while maintaining ease of use through the drag-and-drop interaction style.

[0120] In some embodiments, in response to a determination that the adjacent drop target on which the second data field icon is placed is located to the right of or below the first block card, the computer system automatically aggregates (632) major data fields associated with the second block card according to (i) the dimensional data fields associated with the first block card and (ii) the dimensional data fields associated with the second block card. For example, a level of detail of the second block card is defined according to (i) the dimensional data fields specifying the visual encoding on the first block card and (ii) the dimensional data fields specifying the visual encoding on the second block card, and a query for the second block card is generated, the query specifying an aggregation of each major data field associated with the second block card according to the dimensional data fields in the level of detail of the second block card. In some embodiments, when a data field icon is placed to the right or below a block card corresponding to a block object having an inline placement layout type, a new block object is generated that is a child block object of a parent block object of the block object having the inline placement layout type (e.g., the new block object is not a child of the block object having the inline layout type). By inheriting dimensions from a parent block card by a particular block and aggregating at the level of detail of both that particular block object and the parent block object of that particular block object, a user is able to aggregate at any level of detail within a data visualization.Using the claimed methods, a user can build visualizations of queries and aggregated data at various levels of granularity without having to build complex calculations.

[0121] In some embodiments, in response to a determination that the adjacent drop target on which the second data field is located is located to the left of the first block card or above the first block card, the computer system automatically aggregates (634) major data fields associated with the first block card according to (i) the dimensional data fields associated with the second block card and (ii) the dimensional data fields associated with the first block card. For example, a level of detail for the first block card is defined according to (i) the dimensional data fields specifying the visual encoding on the second block card and (ii) the dimensional data fields specifying the visual encoding on the first block card, and then a query for the first block card is generated, where the query specifies an aggregation of each major data field associated with the first block card according to the dimensional data fields at the level of detail for the first block card.

[0122] In some embodiments, the computer system generates an updated data visualization, including generating a first data visualization portion (e.g., visual component 460 of FIG. 4H ) based on the first block card (e.g., block card 450 of FIG. 4H ) and generating a second data visualization portion (e.g., visual component 462 of FIG. 4H ) based on the second block card (e.g., block card 485 of FIG. 4H ), where the updated data visualization includes a concatenation of the first data visualization portion and the second data visualization portion (e.g., the data visualization displayed in area 465 of FIG. 4H is a concatenation of visual components 460 and 462) (636). In some embodiments, each block card is associated with a different visual component that can be updated independently of other visual components in the data visualization according to user interactions with the block card that corresponds to that visual component (e.g., as shown in FIGS. 4A-4J, visual component 460 can be updated by modifying block card 450 without updating visual component 462, and visual component 462 can be updated by modifying block card 485 without updating visual component 460, respectively). This approach allows different parts in the data visualization to be updated separately, and allows users to set different LOD and encoding properties for each block card via drag-and-drop operations. The ability to provide different levels of detail and encoding properties at the level of the data visualization components rather than the entire data visualization provides users with greater expressiveness while maintaining ease of use through drag-and-drop operations.

[0123] In some embodiments, the first user input is a drag-and-drop gesture (638).

[0124] In some embodiments, the first user input includes a first portion and a second portion, the first portion selecting the first data field icon and the second portion placing the first data field icon on the canvas area (640).

[0125] In some embodiments, block cards are automatically assigned a default layout type, a default mark type, and one or more default visual encodings (642). In some embodiments, the layout type, mark type, and one or more visual encodings may be modified by a user. In some embodiments, the values ​​assigned by default to the layout type, mark type, and visual encodings are based on the data values ​​of the corresponding data fields being encoded, e.g., data fields that are measures are assigned an inline layout type by default, and data fields that are dimensions are assigned a row or column layout type by default. Automatically assigning layout types to block cards assists users in building data visualizations by providing defaults to the user while simultaneously allowing the user to modify the defaults.

[0126] In some embodiments, the plurality of user interface affordances includes a first user selectable user interface element indicating a layout type of the block card (e.g., user selectable element 442 indicating that the currently selected layout is a row-based arrangement, as shown in FIG. 4C), a second user selectable user interface element indicating a mark type of the block card (e.g., user selectable element 444 indicating that the currently selected mark is text, as shown in FIG. 4C), and a plurality of additional user interface elements (e.g., icons 476a-476f), each indicating a respective visual encoding (644). In some embodiments, the layout type and the mark type are displayed at the top of the block. In some embodiments, the layout is represented by text and the mark type is represented by a predefined symbol. In some embodiments, the one or more visual encodings are represented as a list of symbols or icons representing drop targets within the block card. Providing a user selectable element indicating the layout type provides the user with the ability to change the layout type and also provides the user with a visual indication of the current layout type. Additionally, by providing a user selectable element indicative of the mark type, the user is provided with the ability to change the mark type and is also provided with a visual indication of the current mark type, and by providing a user interface element indicative of the visual encoding, the user is provided with visual feedback of the currently selected encoding.

[0127] In some embodiments, if the block card is the first block card, the computer system receives (646) a third user input selecting a third data field icon from the schema area (e.g., an input selecting the data field icon 502 representing the dimension segment in FIG. 5A). In response to receiving the third user input, the computer system displays drop targets on the first block card, each drop target on the first block card designating a respective visual encoding that may be selected for association with the third data field icon. In response to receiving the third user input, the computer system displays drop targets adjacent to the first block card, each adjacent drop target designating a separate option for creating a child block card or a parent block card related to the block card. In response to a user placing a third data field icon on an unoccupied area on the canvas area outside of any of the displayed drop targets (as shown in FIG. 5A, in the canvas area 440 outside the block user interface 445 and outside the data visualization display area 465), the computer system generates a third block card (e.g., block card 504 in FIG. 5B) independent of the other block cards according to the data value of the third data field represented by the third data field icon. In some embodiments, when the third data field is a measure, the block card is assigned a layout type of inline arrangement, and when the third data field is a dimension, the block card is assigned a row-based or column-based arrangement.In response to the user placing the third data field icon on an unoccupied area on the canvas area outside any of the displayed drop targets, the computer system further generates and displays a second data visualization according to the layout type, mark type, and visual encoding specified on the third block card, the second data visualization being separate from and displayed simultaneously with the first data visualization. This method allows the user to build two or more separate and independent data visualizations on the same canvas area using the same data source and data fields without requiring workarounds such as configuring multiple visualizations on a dashboard, so that they appear as one, for example, without having to align multiple sheets together on a single dashboard to fit a desired format and layout. Generating two or modes of independent data visualizations on the same analysis canvas area reduces the number of user inputs required to build a composite data visualization and makes interaction with the block group user interface more efficient.

[0128] 7A-7C are flow diagrams illustrating a method 700 for calculating, for each retrieved tuple, its respective two-dimensional grid position within a data visualization according to a process of assigning row and column indices, according to some embodiments. Method 700 is performed in an electronic device (e.g., device 200 of FIG. 2). In some embodiments, the electronic device is a portable multifunction device comprising a display and, optionally, a touch-sensitive surface. In some embodiments, the display is a touchscreen display, and the touch-sensitive surface is on or integrated with the display. In some embodiments, the display is separate from the touch-sensitive surface. Some operations of method 700 are optionally combined and / or the order of some operations is optionally changed.

[0129] As described herein, according to some embodiments, method 700 assigns tuples taken from multiple queries generated based on multiple block object specifications to calculated grid positions in a data visualization. The method allows a user to build block object specifications in a user interface via simple drag-and-drop techniques. The method converts UI block cards into block object specifications that are used to build queries, with each block card generating a single query. Method 700 further calculates the position of each result (e.g., tuple) for each query in the final data visualization. Method 700 improves the process of creating charts via drag-and-drop interaction. Method 700 provides users with more flexibility to build different layouts and more formatting options through direct manipulation of block objects in the interface. Method 700 provides a visual analysis interface that allows users to iteratively build analysis workflows without having to learn grammar or low-level implementation details. Method 700 is illustrated in FIGS. 7A-7C according to some embodiments.

[0130] In some embodiments, a computer system having one or more processors, a display, and a memory storing one or more programs configured to be executed by the one or more processors displays a graphical user interface on the display (702). The graphical user interface includes: (a) a schema region displaying a plurality of data field icons, each representing a respective data field from a user-selected data source; and (b) a canvas region including a plurality of block cards, each specifying a respective layout type, each of which is one of (i) a row-based arrangement, (ii) a column-based arrangement, or (iii) an inline arrangement, each block card being generated in response to a user placing one or more respective data field icons on the canvas region. In some embodiments, a block description is created by the computer system as the user places the data fields on the canvas region. In some embodiments, based on the data fields placed on the canvas region, the data system assigns a default layout type, mark type, and / or visual encoding, which can be optionally later modified by the user via selection of one or more user interface elements (or affordances).

[0131] For each block card, the computer system generates and executes a respective database query to retrieve tuples of data for data fields associated with the respective block card (704). For each retrieved tuple, the computer system calculates a respective two-dimensional grid location including a respective row index and a respective column index (706). The computer system generates and displays a data visualization in which each retrieved tuple is represented as a visual mark displayed at its calculated grid location (708) (see FIG. 7B).

[0132] In some embodiments, the computer system calculates a respective two-dimensional grid position for each retrieved tuple, including forming a directed acyclic graph of block objects, where each block object corresponds to (i) a respective displayed block card, (ii) a root row object, or (iii) a root column object, and each link in the graph represents either a respective hierarchical relationship between a respective pair of block cards, or a relationship between a block card and a root row object or root column object, as determined by the spatial position of the respective pair of block cards on the canvas area (710). Using the spatial position of the block cards on the canvas area to determine the respective hierarchical relationships between the block objects allows the user to build nested relationships between attributes in the data visualization, which simplifies the process and at the same time increases the expressiveness of chart creation for the user.

[0133] In some embodiments, the computer system calculates a respective two-dimensional grid position for each retrieved tuple, which further includes generating a row block tree from the directed acyclic graph by removing the root column object and retaining only links from the root row object and links from block objects corresponding to the block cards having a row-based arrangement (712). In some embodiments, the root row block object is an implicitly created detail and is not visually represented in the data canvas area. The computer system further generates a row tuple tree, the nodes of which include a single root row node and respective nodes corresponding to each of the retrieved tuples, and forms respective links between each pair of nodes N1 and N2 in the row tuple tree if N1 is the root row node and N2 corresponds to a tuple retrieved for a block object that is a child of the root row object, or if N1 and N2 correspond to retrieved tuples T1 and T2, where tuples T1 and T2 are retrieved for block objects B1 and B2, where block object B1 is a parent of block object B2 in the row block tree, and tuples T1 and T2 have the same data value for each of their shared dimension data fields. In some embodiments, the parent-child relationship between the nodes is determined based on the row block tree, for example, by traversing the row block tree. The computer system further assigns a row index to each tuple by traversing the row tuple tree structure in a depth-first order. For example, each tuple may be assigned an index of 0, 1, 2, etc. for the header, first row, second row, etc. Automatically assigning a row index position in the grid to each retrieved tuple allows users to build data visualizations with simple drag-and-drop techniques, and the method calculates the exact position of each mark in the data visualization that corresponds to each tuple.The method automatically converts block cards into queries that retrieve tuples, which are automatically assigned positions in the final data visualization based on the parent-child relationships formed by the block cards in the block user interface. This method enables the construction of complex and rich data visualizations through simple drag-and-drop techniques, without the need to learn complex grammar or create functions and calculate aggregate values ​​separately from the regular drag-and-drop iterative work flow.

[0134] In some embodiments, traversing the row tuple tree in depth-first order further includes sorting the retrieved tuples according to an ordering of the block objects in the row block tree, an ordering of the data values ​​of the dimension data fields in each tuple, and any user-specified sort order (714).

[0135] In some embodiments, computing a respective two-dimensional grid location for each retrieved tuple further includes generating a column block tree from the directed acyclic graph by removing the root row object and retaining only links from the root column object and links from block objects that correspond to block cards having a column-based arrangement (716). In some embodiments, the root row block object is an implicitly created specification and is not visually represented in the data canvas area. and generating a column tuple tree whose nodes include a single root column node and a respective node corresponding to each of the retrieved tuples, forming a respective link between each pair of nodes N1 and N2 in the column tuple tree where N1 is the root column node and N2 corresponds to a tuple retrieved for a block object that is a child of the root column object, or where N1 and N2 correspond to retrieved tuples T1 and T2, where tuples T1 and T2 were retrieved for block objects B1 and B2, where block object B1 is a parent of block object B2 in the column block tree, and where tuples T1 and T2 have the same data value for each of their shared dimension data fields. Also included is assigning a column index to each tuple by traversing the column tuple tree in a depth-first order. For example, each tuple may be assigned an index of 0, 1, 2, etc. for the first column in the grid, the second column, etc. By automatically assigning a column index position in a grid to each retrieved tuple, the method allows a user to build a data visualization with simple drag-and-drop techniques, and calculates the exact position of each mark in the data visualization that corresponds to each tuple. The method automatically translates block cards into queries that retrieve tuples that are automatically assigned positions in the final data visualization based on the parent-child relationships formed by the block cards in the block user interface.This approach enables the building of complex and rich data visualizations through simple drag-and-drop techniques without the need to learn complex grammar or create functions and calculate aggregate values ​​separately from the regular drag-and-drop iterative work flow.

[0136] In some embodiments, traversing the column tuple tree in depth-first order further includes sorting the retrieved tuples according to an ordering of the block objects in the column block tree, an ordering of the data values ​​of the dimension data fields within each tuple, and any user-specified sort order (718).

[0137] In some embodiments, generating the data visualization in which each tuple is represented as a visual mark further includes, for each block card having a layout type of row-based arrangement or column-based arrangement, assigning each tuple retrieved for the respective block card to a different grid position (720). In some embodiments, generating the data visualization in which each tuple is represented as a visual mark further includes, for each block card having a layout type of inline arrangement, assigning all of the tuples retrieved for the respective block card to a respective single grid position (722). For example, all of the tuples are displayed within a single cell in the tabular data visualization, such as sparklines corresponding to the multiple tuples displayed within the single cell.

[0138] In some embodiments, each block card generates a query that retrieves data for one respective visual component of the data visualization (724). This method allows layout flexibility by providing different layout options for each block object that each determine the spatial layout of marks displayed in the final data visualization, with each mark corresponding to a respective tuple returned based on a respective query for the respective block object. Thus, users can control the layout of marks at the level of each individual component in a data visualization built based on a respective block object.

[0139] In some embodiments, the computer system receives user input to place the data field icons on the canvas area (e.g., by a drag-and-drop action), thereby updating or creating the first block card (726). Also, in response to the user input, executes the generated query corresponding to the first block card without executing queries corresponding to block cards other than the first block card. By executing queries for each block card, different visual portions in the data visualization can be updated without executing queries for other existing block cards in the user interface. This allows users to make changes to the data visualization more efficiently and also allows users to encode different visual characteristics and assign different marks to different components in the data visualization.

[0140] In some embodiments, in response to executing the generated query corresponding to the first block card, the computer system generates a new visual component in the data visualization or updates a visual component currently displayed in the data visualization without updating any previously generated visual components for block cards other than the first block card (728). In some embodiments, the data visualization components can be updated independently of each other. Generating a separate visual component for each executed query generated based on its respective block card description allows separate visual portions in the data visualization to be updated without updating other portions of the data visualization (e.g., a user can do this by simply updating the block card description in a user interface). This allows a user to make more efficient changes to the data visualization and allows different visual characteristics to be encoded to differentiate components and marks within the data visualization.

[0141] In some embodiments, the first block card specifies a mark type and one or more visual encodings that specify color (e.g., icon 476c of FIG. 4D ), size, shape (e.g., icon 476d of FIG. 4D ), text (e.g., icon 476e of FIG. 4D ), x-axis (e.g., icon 476a of FIG. 4D ), y-axis (e.g., icon 476b of FIG. 4D ), ascending sort, descending sort, or level of detail (e.g., icon 476f of FIG. 4D ), and each tuple retrieved for the first block card corresponds to a visual mark having the specified mark type (730). The mark type for each block object can be specified by simple drag-and-drop techniques. Furthermore, encoding different mark types for each separate visual portion in the data visualization allows the user more flexibility and expressiveness in the chart creation process, e.g., mark types can be specified at the level of each visual component by simple drag-and-drop techniques rather than applying the same type of mark for the entire visualization.

[0142] In some embodiments, for each block card of the plurality of block cards, the computer system determines a first level of detail (e.g., local LOD) for the block card according to dimensional data fields that specify one or more visual encodings in the block card, and the computer system determines a second level of detail (e.g., full LOD) for the block card according to (i) dimensional data fields that specify one or more visual encodings in the block card and (ii) dimensional data fields that specify visual encodings in any ancestor block cards of the block card (732). Inheriting the level of detail of the ancestor block object allows users to query data sources at different levels of detail and view measure aggregations at different levels of granularity within a single data visualization. Furthermore, users do not need to perform separate calculations or understand the complex syntactic structure of formulas, but instead can continue to use simple drag-and-drop techniques.

[0143] In some embodiments, for each block card, executing the respective database query includes aggregating (734) each measure data field associated with the respective block card according to a dimension data field at the second level of detail.

[0144] In some embodiments, the arrangement of the block cards relative to one another on the canvas determines hierarchical relationships between the block cards 736. In some embodiments, the arrangement of the block cards relative to one another on the canvas causes the computer system to form an adjacency graph, and a directed acyclic graph of the block objects is based on the adjacency graph 738.

[0145] 8A and 8B are flow diagrams illustrating a method 800 for generating layouts and components of a data visualization by interacting with data field representations, according to some embodiments. Method 800 is performed in an electronic device (e.g., device 200 of FIG. 2). In some embodiments, the electronic device is a portable multifunction device comprising a display and, optionally, a touch-sensitive surface. In some embodiments, the display is a touchscreen display and the touch-sensitive surface is on or integrated with the display. In some embodiments, the display is separate from the touch-sensitive surface. Some operations of method 900 are optionally combined and / or the order of some operations is optionally changed.

[0146] As described herein, the method 800 provides users with the ability to query and encode at different levels of granularity by providing the ability to aggregate measures according to both the level of detail of ancestor block objects and the local level of detail of that block object. By inheriting the level of detail of ancestor block objects, users are able to query data sources at different levels of detail and view measure aggregations at different levels of granularity within a single data visualization. Furthermore, users are not required to perform separate calculations or understand the complex syntactic structure of formulas, but instead can continue to use simple drag-and-drop techniques.

[0147] In some embodiments, in a computer system having one or more processors, a display, and a memory storing one or more programs configured to be executed by the one or more processors, a plurality of interrelated block object details are generated in accordance with a user's arrangement of data field icons on a canvas area, each data field icon selected from a schema area displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source, each block object detail including: (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement; (ii) a mark type specifying a shape of a visual data mark; and (iii) one or more visual encodings specifying one or more of color, size, shape, text, x-axis, y-axis, ascending sort, descending sort, or level of detail in accordance with a data value of the user-selected data field icon (802). For each block object specification, the computer system (1) generates a respective query according to the user-selected data field icons that specify a visual encoding for the respective block object specification, and (2) executes the respective query to retrieve a respective set of tuples from the data source, each tuple including data values ​​for the data fields that correspond to the user-selected data field icons that specify a visual encoding for the respective block object specification (804). Additionally, the computer system generates a data visualization according to the layout type, mark type, and visual encoding specified in each block object specification, and each tuple in each of the respective sets of tuples is represented in the data visualization as a visual mark (806).

[0148] In some embodiments, generating the respective queries includes defining levels of detail according to dimensional data fields associated with visual encodings in the respective block object descriptions, and executing the respective queries includes aggregating each measure data field in the respective block object descriptions according to the dimensional data fields at that level of detail (808).

[0149] In some embodiments, the first query corresponds to a first block object description. The second query corresponds to a second block object description. The first block object description corresponds to a first block object that is a parent block object of a second block object that corresponds to the second block object description. Generating a respective query for each of the first block object detail and the second block object detail includes defining a first level of detail according to dimensional data fields associated with the visual encoding in the first block object detail; defining a second level of detail according to (i) the dimensional data fields associated with the visual encoding in the first block object detail and (ii) the dimensional data fields associated with the visual encoding in the second block object detail; generating, for the first block object detail, a first query specifying an aggregation of each measure data field associated with the first block object detail according to the dimensional data fields at the first level of detail; and generating, for the second block object detail, a second query specifying an aggregation of each measure data field associated with the second block object detail according to the dimensional data fields at the second level of detail (810).

[0150] In some embodiments, generating the multiple interrelated block object details includes generating a first block object detail according to a user placing a first data field icon on the canvas area, where a layout type, a mark type, and one or more visual encodings specified for the first block object detail are initially determined by the computer system according to a value of a first data field associated with the first data field icon; and generating a second block object detail according to a user placing a second data field icon on the canvas area, where a layout type, a mark type, and one or more visual encodings specified for the second block object detail are initially determined by the computer system according to a value of a second data field associated with the second data field icon (812).

[0151] In some embodiments, each block object detail is represented by a respective user interface block card within the canvas area, and each user interface block card includes a selectable user interface element for indicating a layout type of the respective user interface block card, a selectable user interface element for indicating a mark type of the respective user interface block card, and / or a plurality of user interface elements that indicate one or more visual encodings of the respective block object detail (814).

[0152] In some embodiments, each block object specification determines a respective visual component in the data visualization, and each visualization component can be updated independently of other visual components in the data visualization (816). In some embodiments, each user interface block card in the canvas area is converted to a block object specification for which a respective query is generated, and a single visual component is determined according to the tuples and encodings retrieved in response to execution of the respective query. The block card specification can be updated by interacting with or manipulating the corresponding user interface block card, which updates the corresponding visual component in the data visualization.

[0153] In some embodiments, for each block object description, the computer system determines a first level of detail (e.g., a local LOD) for that block object description according to dimension data fields that specify one or more visual encodings within that block object description, and determines a second level of detail for that block object description according to (i) the dimension data fields that specify one or more visual encodings within that block object description and (ii) the dimension data fields that specify visual encodings in any ancestor block object descriptions (818).

[0154] In some embodiments, identifying each measure data field that specifies one or more visual encodings in the respective block object description and executing the respective queries includes aggregating each identified measure data field according to a dimension data field at a second level of detail (820). In some embodiments, the data visualization has a type selected from the group consisting of a table-based chart, a Sankey diagram, and a map-based diagram (822).

[0155] The terms used in the description of the invention herein are for the purpose of describing particular embodiments only and are not intended to be limiting of the invention. When used in the description of the invention and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms unless the context clearly indicates otherwise. As used herein, the term "and / or" will also be understood to refer to and include any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "comprises" and / or "comprising" when used herein specify the presence of stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0156] The foregoing description has been described with reference to specific embodiments for purposes of illustration. However, the exemplary discussion above is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments have been chosen and described in order to best explain the principles of the invention and its practical application, so that others skilled in the art can make best use of the present invention and its various embodiments with various modifications suited to the particular use contemplated.

Claims

1. 1. A method for visual exploration of data, comprising:

1. A computer system having one or more processors, a display, and a memory storing one or more programs configured to be executed by the one or more processors, displaying on the display a graphical user interface including: (a) a schema region displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source; and (b) a canvas region; receiving a first user input selecting a first data field icon from the schema area and placing the first data field icon on the canvas area; In response to receiving the first user input, displaying a block card on the canvas area, the block card including a plurality of user interface affordances indicating (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement; (ii) a mark type specifying a shape of a visual data mark; and (iii) one or more visual encodings specifying one or more of color, size, shape, text, x-axis, y-axis, ascending sort, descending sort, or level of detail according to a data value of a first data field represented by the first data field icon; generating and displaying a data visualization of the data source according to the layout type, the mark type, and the visual encoding specified on the block card; A method comprising:

2. generating and displaying the data visualization of the data source according to the layout type, the mark type, and the visual encoding specified on the block card; defining a level of detail according to dimensional data fields that specify the visual encoding on the block card; generating, for the block cards, a query that specifies an aggregation of each measure data field according to the dimension data fields at the level of detail; executing the query to retrieve a set of tuples from the data source, each tuple including each of the data fields for which a data field icon specifies a visual encoding, and each of the measure data fields being aggregated according to the level of detail; generating said data visualization, wherein each visual mark corresponds to one retrieved tuple; The method of claim 1 , comprising:

3. the block card is a first block card, and the method further comprises: receiving a second user input selecting a second data field icon from the schema section; In response to receiving the second user input, displaying drop targets on the first block card, each drop target on the first block card specifying a respective visual encoding that may be selected for association with the second data field icon; displaying drop targets adjacent to the first block card, each adjacent drop target designating a separate option for creating a child block card or a parent block card related to the block card; generating and displaying an updated data visualization in response to a user placing the second data field icon onto (i) one of the drop targets for the first block card, or (ii) one of the adjacent drop targets, wherein a layout type, a mark type, and a visual encoding are determined according to the user's placement of the second data field icon; The method of claim 1 or 2, further comprising:

4. 4. The method of claim 3, wherein the second data field icon is placed over one of the drop targets on the first block card, thereby adding a visual encoding based on a second data field corresponding to the second data field icon.

5. 4. The method of claim 3, wherein the second data field icon is placed on one of the adjacent drop targets, thereby forming a second block card that is a parent or child of the first block card, and generating the updated data visualization includes generating a data visualization according to the layout type, the mark type, and the visual encoding specified on the first block card and the layout type, the mark type, and the visual encoding specified on the second block card.

6. the second block card being a child of the first block card, and generating the updated data visualization includes: (i) defining a first level of detail according to a dimension data field that specifies the visual encoding on the first block card; Defining a second level of detail according to (i) a dimension data field specifying the visual encoding on the first block card and (ii) a dimension data field specifying the visual encoding on the second block card; generating, for the first block card, a first query specifying an aggregation of each measure data field associated with the first block card according to the dimension data fields at the first level of detail; generating, for the second block card, a second query specifying an aggregation of each measure data field associated with the second block card according to the dimension data fields at the second level of detail; executing the first query to retrieve a first set of tuples from the data source; executing the second query to retrieve a second set of tuples from the data source; generating the updated data visualization including a respective first visual mark representing each of the first set of tuples and a respective second visual mark representing each of the second set of tuples; The method of claim 5 , comprising:

7. 7. The method of claim 5 or 6, wherein generating the updated data visualization comprises generating a first data visualization portion based on the first block card and generating a second data visualization portion based on the second block card, and the updated data visualization comprises a concatenation of the first data visualization portion and the second data visualization portion.

8. When a user places the second data field icon over one of the adjacent drop targets, displaying a visual indicator representing a hierarchical relationship between the first block card and the second block card; The method of any one of claims 5 to 7, further comprising:

9. 9. The method of claim 5, wherein visual positioning of the first block card and the second block card relative to one another on the canvas area determines a relative placement of visual marks of the first block card and visual marks of the second block card in the data visualization.

10. automatically aggregating a major data field associated with the second block card according to (i) a dimensional data field associated with the first block card and (ii) a dimensional data field associated with the second block card in response to a determination that the adjacent drop target on which the second data field icon is positioned is located to the right of the first block card or below the first block card; The method according to any one of claims 5 to 9, comprising:

11. automatically aggregating a major data field associated with the first block card according to (i) a dimensional data field associated with the second block card and (ii) a dimensional data field associated with the first block card in response to a determination that the adjacent drop target on which the second data field icon is positioned is located to the left of the first block card or above the first block card; The method according to any one of claims 5 to 10, comprising:

12. 12. The method of claim 3, wherein the drop target displayed adjacent to the block card is determined based on whether the second data field icon represents a dimension data field or a major data field.

13. 13. The method of claim 3, wherein in accordance with a determination that the second data field icon represents a dimension data field, the drop targets adjacent to the block card include a first drop target that specifies a row layout type and a second drop target that specifies a column layout type.

14. The method of any one of claims 3 to 13, further comprising displaying a drop target that specifies an inline layout type in accordance with a determination that the second data field icon represents a major data field.

15. the block card is a first block card, the data visualization based on the first block card is a first data visualization, and the method further comprises: receiving a third user input selecting a third data field icon from the schema section; in response to receiving the third user input; displaying drop targets on the first block card, each drop target on the first block card specifying a respective visual encoding that may be selected for association with the third data field icon; displaying drop targets adjacent to the first block card, each adjacent drop target designating a separate option for creating a child block card or a parent block card related to the block card; in response to a user placing the third data field icon onto an unoccupied area on the canvas section outside any of the displayed drop targets; generating a third block card independent of other block cards including the first block card according to a data value of a third data field represented by the third data field icon; generating and displaying a second data visualization according to a layout type, mark type, and visual encoding specified on the third block card, the second data visualization being separate from the first data visualization and displayed simultaneously with the first data visualization; The method of any one of claims 1 to 14, further comprising:

16. The method of any one of claims 1 to 15, wherein the first user input is a drag-and-drop gesture.

17. 16. The method of claim 1, wherein the first user input includes a first portion and a second portion, the first portion selecting the first data field icon and the second portion placing the first data field icon on the canvas area.

18. The method of any one of claims 1 to 17, wherein the block cards are automatically assigned a default layout type, a default mark type, and one or more default visual encodings.

19. The plurality of user interface affordances: a first user selectable user interface element indicating the layout type of the block card; a second user selectable user interface element indicative of the mark type of the block card; a plurality of additional user interface elements, each of which exhibits a respective visual encoding; and The method according to any one of claims 1 to 18, comprising:

20. 1. A computer system comprising: a display generation component; one or more input devices; one or more processors; and a memory storing one or more programs, the one or more programs being configured to be executed by the one or more processors, the one or more programs comprising: displaying on the display generation component a graphical user interface including: (a) a schema region displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source; and (b) a canvas region; receiving a first user input selecting a first data field icon from the schema area and placing the first data field icon on the canvas area; In response to receiving the first user input, displaying a block card on the canvas area, the block card comprising a plurality of user interface affordances indicating: (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement; (ii) a mark type specifying a shape of a visual data mark; and (iii) one or more visual encodings specifying one or more of color, size, shape, text, x-axis, y-axis, ascending sort, descending sort, or level of detail according to a data value of a first data field represented by the first data field icon; generating and displaying a data visualization of the data source according to the layout type, the mark type, and the visual encoding specified on the block card; The computer system includes instructions for:

21. A computer-readable storage medium storing one or more programs, the one or more programs including instructions that, when executed by a computer system having a display generating component and one or more input devices, cause the computer system to: displaying on the display generation component a graphical user interface including: (a) a schema region displaying a plurality of data field icons, each data field icon representing a respective data field from a user-selected data source; and (b) a canvas region; receiving a first user input selecting a first data field icon from the schema area and placing the first data field icon on the canvas area; In response to receiving the first user input, displaying a block card on the canvas area, the block card comprising a plurality of user interface affordances indicating: (i) a layout type specifying a row-based arrangement, a column-based arrangement, or an inline arrangement; (ii) a mark type specifying a shape of a visual data mark; and (iii) one or more visual encodings specifying one or more of color, size, shape, text, x-axis, y-axis, ascending sort, descending sort, or level of detail according to a data value of a first data field represented by the first data field icon; generating and displaying a data visualization of the data source according to the layout type, the mark type, and the visual encoding specified on the block card; A computer-readable storage medium.

22. 1. A computer system comprising: a display generation component; one or more input devices; one or more processors; A computer system comprising: a memory for storing one or more programs, the one or more programs being configured to be executed by the one or more processors, the one or more programs comprising instructions for performing any of the methods according to claims 1 to 19.

23. A computer readable storage medium storing one or more programs, the one or more programs comprising instructions that, when executed by a computer system having a display generating component and one or more input devices, cause the computer system to perform any of the methods described in claims 1 to 19.

Images