Patent ID: 12210574

DETAILED DESCRIPTION

As briefly described above, embodiments of the present invention are directed to a data visualization tool. The data visualization tool may include, for example, guided visualization creation features as well as secure publication features which allow for automated publication of a visualization to users having differing roles or access rights. This has the function of simplifying creation of data visualizations, and can also allow users to automatically be presented with a data visualization according to that user's respective access rights.

In example embodiments, data visualizations within the present disclosure are generally constructed as dashboards that may be viewed by a plurality of users. The dashboards may include charts, tables, or other information that may quickly illustrate data to a user. Such dashboards may also be constructed from cards, each of which may include separate analyses of different data sets.

In accordance with the present disclosure, such a data visualization tool may be described in conjunction with business analytics that are presented to a user within a card or dashboard. The business analytics may be focused, in the examples described herein, on use within a retail organization. However, it is recognized that the applicability of such a data visualization tool is not so limited.

The term “user” in the present disclosure may relate to a user of the data visualization tool who acts as an editor of data visualizations. Such a user may have access rights to certain ones of the user interfaces described herein. Other users may act as consumers of the data visualizations that are created. Such users may be referred to as “viewing users” or “customer users” and may have fewer access or editing rights to a particular data visualization as compared to the editing user.

Referring first toFIG.1, an example environment10is illustrated in which a data visualization tool may be implemented. In the environment10, a computing system100is communicative we connected to a plurality of retail databases12, as well as other user devices14(shown as user devices14a-bfor different users, respectively). The retail databases12, user devices14, and computing system100maybe communicatively connected via a network16, such as the Internet.

In the embodiment shown, the computing system100includes a processor102communicatively connected to a memory104via an interface106. The processor102is further connected to a communication interface108and a display110. The communication interface108allows the computing system100to communicate with other devices via network16.

In the embodiment shown, the memory104stores a data visualization tool112. The data visualization tool112includes a card/dashboard builder114, a table rendering component116, a conditional formatting component118, an access rights component120, a tagging component122, and a time period selection component124. Other components may be included in the data visualization tool112as well, in various embodiments.

The card/dashboard builder114provides a plurality of selectable options to a user, for example in a builder menu, which may be selected to display additional screens with which a user may define parameters that are used to define a card that will be included in a data visualization. In example embodiments, and as discussed further below, the card/dashboard builder114provides a guided card building process in which a graphical user interface presents an untrained user a canvas and a guided set of options, with a set of selected decisions used for defining a card, including creation/modification of a card, defining a card dataset, defining a chart type for inclusion in the card, a time period for relevant data, sorting/filtering criteria, as well as a definition of additional card details and data access rights. The card may be built directly on a canvas to form a dashboard, rather than requiring cards to be built in a separate tab and referenced by a dashboard that is published to a user.

The table rendering component116can render data tables within a card or dashboard to present data to a user in a variety of ways. In some embodiments, the table rendering component116can cooperatively operate with the conditional formatting component118to generate, e.g. data visualizations that may be adjustable in response to user manipulation of graphical elements within the card or dashboard. For example, as noted below, in some embodiments, a user may be able to create a calculated field, which renders, within the data visualization tool, a visualization of a combination of existing data fields within a card without affecting underlying data sets (e.g., by performing a join or other operation on those data sets). For example, data fields that are combined in a particular analysis or visualization may be combined without first requiring that data to be staged in an intermediate table. Instead, the data is appended together or merged at the time a user selects to modify or merge two fields to form a new calculated field or at the time the card or dashboard is updated. Underlying data sources are not modified, and therefore underlying ETL processes do not need to be performed. Additionally, using the table rendering component116and/or conditional formatting component118, such calculated fields may include injected code (e.g., javascript) that allows a user to add significant additional modifications to a particular set of data or visualization.

An access rights component120allows users to view a dashboard that includes one or more cards. As discussed in further detail below, different users having different access rights may have different views of the dashboard or of one of the cards based on those different access rights. For example one user may lack access to one or more cards included in the dashboard while a second user they have access to all cards in the dashboard. A creator of a card may set access rights for the card, for example to expose the card to users internal to or external to an organization, with different data access levels. Additionally, some users may be designated as editing users, while other users may be designated as consumers of data visualizations who are not given all rights to, e.g., create and/or edit cards and/or dashboards.

The tagging component122allows creators of cards to tag those cards with specific topic of words. Additionally, dashboards may be created and tagged with specific topic words. Consumer users may subscribe to a tag to a mentally obtain access to content as that content is created. In this way, the consumer of a dashboard or card need not have previous knowledge of the card or dashboard to have that card or dashboard exposed to them.

The time period selection component124allows a user to select from among a plurality of different time periods for analysis. Although in some embodiments, the time period selection component124allows a user to select a date range for analysis, in other embodiments the time. Selection component124also allows the user to toggle between a predetermined time period calculated based on a standard calendar, and a time period that is based on a fiscal year calendar (e.g., starting on a different month or day of the week automatically). Examples of such a calendar toggle are provided below inFIG.14.

FIG.2illustrates an example architecture of a data visualization tool, according to an example embodiment. The architecture may be implemented at least in part on a computing system100as illustrated inFIG.1. In the embodiment shown, a computing system100is connected to a plurality of data sources12. The computing system100includes a user interface150, a query generation layer152, a query translation layer154, and the data querying engine156.

The user interface150is configured to generate one or more data visualizations in a data visualization user interface180. The data visualization user interface generally includes a canvas area in which data visualizations may be defined, and a dashboard or card builder menu that guides a user through the process of defining such data visualizations. The user interface150generally is hosted for remote viewing by users who either create or view data visualizations.

The query generation layer152translates user inputs received in the data visualization user interface180into a definition of a data visualization, which may include one or more queries of data sources12. The query generation layer152, in some embodiments, translates selection of data sources and data elements within those data sources as queries in a querying language. In some embodiments, the querying language can be a customized language similar to a structured query language (SQL).

The query translation layer154receives the query defined in the query language, and translates that query into a package capable of ingestion by the data querying engine156. In example embodiments, the query translation layer154translates the query language into a JSON object that is consumable by the data query engine156.

In example embodiments, the data query engine156can be, for example, implemented using the Druid open source distributed data store and ingestion platform. Use of Druid has the advantage of managing very large quantities of data in queries, with low latency. However, Druid is sometimes not used because it requires formatting of queries submitted to that software as JSON objects. Because traditional data visualizations are generated using structured queries which are significantly more readable to a user than JSON objects, it can sometimes be difficult to implement data visualization solutions via such a data query engine156. However, through the use of a customized query language implemented by the query generation layer152, as well as a query translation layer154that accurately translates those custom queries into appropriately formatted objects, the high quantity, low latency querying advantages of Druid may be realized in the data visualization tool described herein.

FIG.3illustrates an example user interface300of a data visualization tool according to an example embodiment. The user interface300represents an interface that may be presented to a user who either wishes to create cards or dashboards or has subscribed to cards or dashboards for viewing.

In the example shown, the user interface300includes a collection of cards in a cards section302and a collection of dashboards illustrated in a dashboards section304. The cards may be presented in either a whole or partial form, while the dashboards may be presented in a summary format. Upon selection of a card or dashboard, the user may be presented with a user interface in which the user may be able to view the entire card or dashboard, or edit the card or dashboard.

In the sample embodiments, a user may set one or more favorites or subscribe to one or more topics as “tags”. In such instances, if new cards or dashboards are made available by other users that have a shared topical tag those cards or dashboards may appear in the summary format in the user interface300.

FIG.4illustrates an example method400of using a card builder tool set within a data visualization tool to create a data visualization, in accordance with an example embodiment. The card builder tool set may be presented to the user within a user interface generated by a data visualization tool, for example as seen inFIGS.6-7.

In the embodiment shown, the method400includes displaying a user interface including a canvas and a builder menu (step402). The method includes receiving a card creation command (step404). Once a card creation command has been received, the all the data visualization tool may also receive a definition of a data set to be used in the card or dashboard (step406). The data visualization tool may further receive a definition of a chart style (step408), which represents the type of visualization that the user wishes to view for the selected data set.

In example embodiments, the data visualization tool may receive a definition of one or more time periods upon which to perform analysis (step410). This can include, for example, defining a start date and end date for the analysis, or selecting a predefined sliding window (e.g., last week, last month, last quarter). In still further implements, this can include receiving selection of a predefined last fiscal period (e.g., a last quarter as defined for the particular entity associated with the data visualization tool, or a last week defined to start on a different, specific day of the week for accounting purposes).

In further example embodiments, the data visualization tool may receive definition of one or more sorting more filtering features (step412). The filtering features can be defined by the user to allow viewers of the card or dashboard to filter data based on the data included in one or more columns within that visualization. An example of such a filter definition is provided below, discussed in conjunction withFIGS.12-13.

In still further example embodiments, the data visualization tool may receive a definition of card access rights for a given card or dashboard (step414). For example, the data visualization tool may receive part details including a setting of whether the card is intended for confidential or internal use only. If considered confidential, a card may be accessible to users outside of an organization who have adequate access rights. If considered internal use only, even those users having access rights to confidential information may not have access to information on the card, if those users are not within the organization. Examples of permission settings are provided in the user interface1000shown inFIGS.10-11.

In the example shown, the data visualization tool receives one or more dashboard or card settings, as well as one or more tags (step416). Such card or dashboard parameters may be defined in the builder menu, for example after selecting a card details selectable region as described below. The tags may be defined as one or more keywords associated with a dashboard or card that may describe the contents of that card. For example, a tag may be defined such as “quarterly sales” or “same store performance”. Another user may search for such a tag or may subscribe to such a tag in a user's home page (e.g., in a user interface analogous toFIG.3) to obtain access to such tagged cards or dashboards automatically once they are published and therefore accessible to the user.

FIG.5illustrates an example method500of publishing visualizations to different users based on tags, subscriptions, and access rights, according to an example embodiment. The method500may be performed, for example, using a data visualization tool as noted above, for distribution of dashboards and/or cards to various users14a-b.

In the example shown, the method500includes receiving tag definitions from a user who is a creator or editor of a card or dashboard (step502). As noted above, the tag definitions may be any keyword that would likely be searched or desired by users who wish to find the card or dashboard, such as “quarterly sales”, “trending sale items”, “same store performance”, or similar words/phrases. A tag subscription can then be received from two different users. For example, a first user internal to the organization whose data is used to create the data visualization may subscribe to any tags associated with “quarterly sales” and “trending sale items”, and a second user who is external to the organization but has at least some access rights to view data visualizations may subscribe to “trending sale items”. Once a dashboard or card is fully defined and therefore published for access by other users (step506), a notification regarding the card is populated to the different users who subscribed to the tag associated with that dashboard or card.

Continuing the above example, the “trending sale items” visualization may be a dashboard that has a plurality of associated cards. Some of those cards may be set to a confidentiality level of “internal only” while other cards may simply be set to a confidentiality level of “confidential”. Those “internal only” cards may only be presented within the “trending sale items” visualization to the first user and not to the second user, due to differences in data rights. However, both users would automatically be notified of the existence of the data visualization since both subscribed to data visualizations according to the associated keyword tag.

Referring now toFIGS.6-20, additional user interfaces are illustrated which highlight certain features of the data visualization tool described herein, and as briefly described above. The user interfaces may be generated by one or more aspects of a data visualization application, such as the data visualization application112ofFIG.1(e.g., using card/dashboard builder114).

FIG.6illustrates an example user interface600of a data visualization tool including a card builder region602and a canvas604, according to an example embodiment. The card builder region602includes a plurality of selectable regions, including an add card region606, a create new dashboard region608, a dataset region610, a chart region612, a time period region614, a sort region616, a dataset filter region618, a viewer filter region620, and a card details region (partially shown). Generally, a user wishing to define a card or dashboard within the canvas area604(in which six cards are currently shown, as well as a notes region).

In general, defining a card requires a user to select each of the selectable options to define parameters required to create a data visualization within a card. Similar parameters are required for definition of a dashboard as well.

As seen inFIG.6, and better seen in the portion of the user interface600shown inFIG.7, each of the selectable regions may include an indicator that indicates whether parameters associated with the selectable reaching have been set for a particular card or dashboard. In the example shown, a checkmark may be included in the selectable region to indicate that the selectable region has been selected and parameters associated with that selectable region has been set for the card that is currently selected. In some examples, when a card is not fully defined, indicia may be displayed (e.g., an “x” or other visible mark) indicating that a parameter must be defined that is associated with the selectable region prior to the card or dashboard being able to be completed and rendered.

As shown generally inFIG.6, use of the card builder region602in association with the canvas604allows a user to define cards directly on a canvas area that may also store dashboards. This has significant advantages in terms of time and effort required to create cards and dashboards, because a user will not be required to first create intermediate visualizations in a first workspace to import into a dashboard; all work may be performed concurrently.

FIGS.8-9illustrate a user interface800of a data visualization tool in which a calendar-based time period may be defined for analysis of data within a dashboard, according to an example embodiment. The user interface800represents an example dashboard showing a data visualization of daily sales. In the example shown the dashboard includes a date selector802and a calendar selection toggle switch804. The date selector802allows a user to define a date range for analysis, for example a prior day, proctor week, prior month, prior quarter, or prior year. In the example shown the calendar selection toggle switch804is activated, and therefore the periods of time shown in the date selector represent dates that correspond to a fiscal calendar of the organization. By way of comparison, inFIG.9, the calendar selection toggle switch804remains unselected. In that version of user interface800, the time periods (in this case, a next time period rather than previous time period) are set based on a traditional calendar, rather than on a fiscal calendar. Accordingly, in certain embodiments described herein, graphical elements may be provided that allow a user to quickly and conveniently swap between organization-relevant time periods and time periods typically used external to the organization.

FIGS.10-11illustrate an example user interface1000of a data visualization tool in which one or more calculated fields may be defined within a card or dashboard. Calculated fields, in accordance with the present disclosure, correspond to fields which may be generated based on other fields already included in the card or dashboard or defined as being included in data sources. In the example user interface1000as shown, a user may search for and select fields in previously-identified data sources in a field selection region1002, and define one or more functions to be applied to those fields from a function selection region1004. As seen inFIG.10, functions can include, for example, various Boolean and mathematical operations that may be performed on a plurality of data fields that are included in the card or dashboard. A calculated field definition sub-window1006allows the user to name the calculated field and manually edit a calculation to be performed across data fields. Additionally, permissions may be granted to the calculated field and to the card overall, as noted above (e.g., to define owners of a card who are allowed to edit the card or dashboard, as well as a privacy level which defines whether only internal users may view the card or dashboard or whether authorized external users may also have viewing rights).

As seen inFIG.11, a selection window1102allows a user to select a specific type of calculated field to filter among the calculations that may be performed. In the example shown, a variety of function, condition, and aggregate calculations are illustrated as being available to be performed on particular data sources; in alternative embodiments, other types or categorizations of data fields may be provided as well.

In example embodiments, the available types of calculated fields can be implemented as code embedded within a particular card or dashboard that allow certain fields to be formed at the time the card is displayed. The code may embed calculations into the definition of the card or dashboard such that, at the time of display of the card or dashboard, each of the underlying data sources can be accessed and, embedded within the card, various data manipulations may be performed prior to display of data. For example, embedded code (e.g., javascript) may be used to, e.g., join data fields by calculating a sum or other mathematical derivation of the underlying data fields, without requiring a join between two heterogeneous data sources to be performed prior to that calculation, and without making that calculation apparent/visible to a non-editing user of the card or dashboard. In example embodiments, such embedded code may automatically be added to the card or dashboard based on graphical user manipulations of data, e.g., to combine particular data fields to display predefined calculations from user-definable data sources.

As illustrated inFIGS.12-13, a further example user interface1200is shown which may be displayed upon selection of a filter option (e.g., viewer filter region620) of a builder region602, in the user interface600ofFIG.6. In the example shown, the user interface1200allows a user to define one or more data filters that can be applied to data within a dashboard that is created or edited by the user, via a filter definition tool1202. As seen inFIG.13, a further user interface1300can be displayed upon selecting to add a filter within the user interface1200. The user interface1300presents a further filter addition screen1302that allows a user to name a filter, and define a dataset and column to be filtered based on the selected filter. The filter may then be saved for use by other users who may elect to view the card or dashboard.

FIG.14illustrates an example column swap operation within a user interface1400of a data visualization tool, according to an example embodiment. In the example shown, the user interface1400depicts a dashboard having a plurality of data columns. A user may select a swap column option1402that can be activated by selecting a column, which leads to display of a swap screen1404. The swap screen1404allows a user to swap the selected column with another dimension for analysis. In the example shown, a column “division” can be swapped with various other dimensions to provide analysis along that other dimension such as, e.g., household income, ethnicity, primary market, fiscal week, family life stage, etc.

In example embodiments, the column swap can be performed, as with the calculated fields and the filters, without reconfiguration of underlying databases12, or performing additional ETL operations to modify underlying data.

Referring toFIGS.15-19, various additional user interfaces are illustrated that are useable by various users to define, navigate, and view drill-through visualizations using the data visualization tool described herein. In particular, the user interfaces disclosed herein allow an editing user to define drill-through visualizations quickly on large-scale data using a card-based interface, while also allowing an end user (e.g., a consumer of the analysis) to easily view up-to-date records across vast datasets in various ways. Accordingly, the tools described herein enable a display of a drill-through tool useable to define an interrelationship among a plurality of cards as an ordered sequence. Each of the cards may display a different different graphical depiction of data at a different level of detail.

FIG.15illustrates an example user interface1500of a data visualization tool in which a drill through tool1502is shown. In the drill-through tool1502, drill-through operation can be defined, according to an example embodiment. In general, a drill-through operation refers to a circumstance in which a user selects a particular data visualization or dataset, and rather than a drill-down, which leads to an underlying subdivision or sub-categorization (breakdown) of that visualization or dataset, other, predefined and related data may be provided to that user. For example, a report illustrating sales by region may be selected to show a related, relevant report such as a pictorial of a geographic region illustrating a heatmap of sales, or an analysis grid that is arranged based on some alternative breakdown (e.g., by type of item sold, or along some other metric). It is recognized that similar types of graphics could be used.

Specifically in the example shown, upon selection of the drill-through tool1502, a user interface1500is shown in which a user may be allowed to define a drill path for a particular card. Specifically, as shown the user may be allowed to either add an existing card (i.e., to add a new type of visualization to a drill path from an existing card), or add a new level to the current drill through sequence (e.g., adding a new card to the overall drill sequence). In the example shown, an editing user may elect to change filters that are used in each of the cards associated with the drill path, or otherwise can set card details for a currently selected card. In the example shown, the user interface1500displays a card sequence that may be manually reordered, for example by a drag and drop process.

In the particular example shown, a top level card “Ad Comp” allows a user to select the visualization to drill through to an “Ad Comp by Region” visualization. The “Ad Comp by Region” visualization permits drill through to a “Sales Units by Division” visualization, which may subsequently be drilled through to a “Sales Factors by Class” visualization. If each of these visualizations may have different visualization types, such as a heat map, bar, or tree table. An example drill through visualization sequence based on the defined sequence using the tool depicted in the user interface1500is seen inFIGS.17-20, below.

FIG.16illustrates an example user interface1600of a data visualization tool in which defined levels of a drill-through operation can be viewed and navigated during editing, according to an example embodiment. In the example shown, the user interface1600allows a user to select a particular card, and in particular a card summary card. In this example, each of the defined cards that are including a drill through sequence are listed, and the cards may be selected for patenting from the card a summary. By selection of one of the cards, the user may perform further editing operations on that card, for example to change an appearance or dataset associated with the card.

Referring now toFIGS.17-20, a sequence of user interfaces is shown that displays an example drill through sequence that may be defined, for example using the user interfaces ofFIGS.15-16.FIG.17illustrates an example user interface1700of a data visualization tool in which a user may conduct a predefined drill-through operation. In this example, an “Ad Comp” top level data set is displayed within a card. Upon user selection of the graphic within the user interface1700(e.g., by double clicking or otherwise selecting the graphic), a further user interface1800seen inFIG.18may be displayed. As seen in that Figure, while the top level data visualization showed only a single statistic, the first drill down illustrates the same general topic, but within a different type of visualization and broken down along particular characteristics (e.g., by region and item type).

Still further, inFIG.19, a further drill-through operation results in display of a user interface1900in which sales units by division are displayed after a particular region was selected in the user interface1800ofFIG.18. In this example, a bar chart is illustrated, after selection of a particular region on a heat map ofFIG.18. Furthermore, a user interface2000seen inFIG.20can display raw data for a selected division which may be selected from the user interface1900ofFIG.19.

Accordingly, referring toFIGS.15-20overall, it is seen that in accordance with the present disclosure, the card builder features of the data visualization tool described herein are useable not only to easily define cards in place, but to add drill through features linking cards together, either by newly-creating a visualization in a new card, or by linking to an existing card to establish a relationship therebetween. By way of these drill through visualizations, an editing user may easily define navigation paths among the cards that they or others create, to ensure other users (e.g., non-editor, consumer users) have the ability to view data of interest.

FIG.21illustrates an example system2100with which disclosed systems and methods can be used. In an example, the system2100can include a computing environment2110. The computing environment2110can be a physical computing environment, a virtualized computing environment, or a combination thereof. The computing environment2110can include memory2120, a communication medium2138, one or more processing units2140, a network interface2150, and an external component interface2160.

The memory2120can include a computer readable storage medium. The computer storage medium can be a device or article of manufacture that stores data and/or computer-executable instructions. The memory2120can include volatile and nonvolatile, transitory and non-transitory, removable and non-removable devices or articles of manufacture implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. By way of example, and not limitation, computer storage media may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), reduced latency DRAM, DDR2 SDRAM, DDR3 SDRAM, solid state memory, read-only memory (ROM), electrically-erasable programmable ROM, optical discs (e.g., CD-ROMs, DVDs, etc.), magnetic disks (e.g., hard disks, floppy disks, etc.), magnetic tapes, and other types of devices and/or articles of manufacture that store data.

The memory2120can store various types of data and software. For example, as illustrated, the memory2120includes data visualization instructions2122for implementing one or more aspects of the data visualization tool described herein, database2130, as well as other data2132. In some examples the memory2120can include instructions for generating a data visualizations for analysis of organizational data.

The communication medium2138can facilitate communication among the components of the computing environment2110. In an example, the communication medium2138can facilitate communication among the memory2120, the one or more processing units2140, the network interface2150, and the external component interface2160. The communications medium2138can be implemented in a variety of ways, including but not limited to a PCI bus, a PCI express bus accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing system interface (SCSI) interface, or another type of communications medium.

The one or more processing units2140can include physical or virtual units that selectively execute software instructions. In an example, the one or more processing units2140can be physical products comprising one or more integrated circuits. The one or more processing units2140can be implemented as one or more processing cores. In another example, one or more processing units2140are implemented as one or more separate microprocessors. In yet another example embodiment, the one or more processing units2140can include an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the one or more processing units2140provide specific functionality by using an ASIC and by executing computer-executable instructions.

The network interface2150enables the computing environment2110to send and receive data from a communication network (e.g., network16). The network interface2150can be implemented as an Ethernet interface, a token-ring network interface, a fiber optic network interface, a wireless network interface (e.g., WI-FI), or another type of network interface.

The external component interface2160enables the computing environment2110to communicate with external devices. For example, the external component interface2160can be a USB interface, Thunderbolt interface, a Lightning interface, a serial port interface, a parallel port interface, a PS/2 interface, and/or another type of interface that enables the computing environment2110to communicate with external devices. In various embodiments, the external component interface2160enables the computing environment2110to communicate with various external components, such as external storage devices, input devices, speakers, modems, media player docks, other computing devices, scanners, digital cameras, and fingerprint readers.

Although illustrated as being components of a single computing environment2110, the components of the computing environment2110can be spread across multiple computing environments2110. For example, one or more of instructions or data stored on the memory2120may be stored partially or entirely in a separate computing environment2110that is accessed over a network.

Referring toFIGS.1-21overall, it is noted that the methods and systems described herein have a number of advantages over existing systems with respect to generation of data visualizations. For example, the use of the present architecture allows for data visualizations to be generated significantly faster over very large data (billions of records) using the architecture described above. Still further, the graphical user features described herein, including a guided menu for building cards and dashboards, and secure distribution of those cards and dashboards to subscribing users, improve efficiency in both creation and distribution of data visualizations. Still further, the various calculated fields, filters, and column swapping operations described herein may be performed without underlying adjustments to underling data, which makes those operations significantly less time consuming for experienced users while also allowing inexperienced users to readily modify analyses without requiring those users to have familiarity with data structure modification techniques. Other improvements are apparently as well, and illustrated in the present disclosure.

This disclosure described some aspects of the present technology with reference to the accompanying drawings, in which only some of the possible aspects were shown. Other aspects can, however, be embodied in many different forms and should not be construed as limited to the aspects set forth herein. Rather, these aspects were provided so that this disclosure was thorough and complete and fully conveyed the scope of the possible aspects to those skilled in the art.

As should be appreciated, the various aspects (e.g., portions, components, etc.) described with respect to the figures herein are not intended to limit the systems and methods to the particular aspects described. Accordingly, additional configurations can be used to practice the methods and systems herein and/or some aspects described can be excluded without departing from the methods and systems disclosed herein.

Similarly, where steps of a process are disclosed, those steps are described for purposes of illustrating the present methods and systems and are not intended to limit the disclosure to a particular sequence of steps. For example, the steps can be performed in differing order, two or more steps can be performed concurrently, additional steps can be performed, and disclosed steps can be excluded without departing from the present disclosure.

Although specific aspects were described herein, the scope of the technology is not limited to those specific aspects. One skilled in the art will recognize other aspects or improvements that are within the scope of the present technology. Therefore, the specific structure, acts, or media are disclosed only as illustrative aspects. The scope of the technology is defined by the following claims and any equivalents therein.