Patent Application
20140040805
Embodiments of the inventive subject matter generally relate to the field of computers, and, more particularly, to generation of charts based on user control inferences.
Accessing different types of data to view and analyze in a meaningful way can be time consuming and onerous. Typically, a user is required to enter input multiple times regarding data to be presented to them by maps, lists, reports, charts, etc. Conventional systems retrieve the requested data for viewing and analysis based on the input from the user.
In some example embodiments, a computer-implemented method includes receiving, for each of a number of user interface controls, selections by a user of at least one of exactly one value, a subset of values, all values, and no values. The selections by the user define non-chart-related settings. The method includes inferring intent of the user of at least one attribute of a chart based on the selections by the user via the number of user interface controls. The method includes defining at least one characteristic of the chart for displaying the chart based on the intent.
The present embodiments may be better understood, and numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. However, it is understood that the described embodiments may be practiced without these specific details. In other instances, well-known instruction instances, protocols, structures and techniques have not been shown in detail in order not to obfuscate the description.
Some example embodiments enable a user to delegate decisions about the different characteristics for charts provided to them based on inferences that are derived from user input regarding settings or parameters providing for data queries that are not for charts (i.e., non-chart based settings). Some example embodiments can be performed by a data query module and a chart module. The data query module and the chart module can be software, firmware, hardware or a combination thereof to perform the operations described below. For example, the data query module and the chart module can be software executing on a processor. An example of such a configuration is depicted in
In some example embodiments, a chart is defined to include any type of report, table, graph, diagram, etc. that is derived from user inputs for data queries. The user can specify one or more settings for a data query, wherein the results provide an indication of the user's interest. In response, the data query module can retrieve and display this results set. Additionally, based on the state of these non-chart, based settings (the data query inputs by the user), the chart module makes inferences to determine the charts that would provide additional insight to the user. Along with the results set, the chart module can return a chart befitting the results set. Some example embodiments alleviate the need for a user to specify their interests multiple times for different types of charts and information about requested data. For example, a user is not required to both complete a user interface dialog to return results for a map and list about a set of data and make additional or separate decisions about charts related to the data. In some example embodiments, the user can be given the option to have charts generated by the chart module or to manually define the characteristics of the chart.
Some example embodiments enable a user to delegate charting decisions to the chart module. The chart module can infer a reasonable set of chart characteristics from the user's other user interface input that is not specific to chart-based settings. The chart characteristics delegated to the chart module can include a type of graph (bar, stacked bar, pie chart, etc.), a title for the chart, the second variable represented in each bar for a stacked bar graph, what is being compared (e.g., variables represented by each bar in a bar graph), etc.
Accordingly, as described, a user can receive a large amount of information about the data they are requesting with relatively little interaction. Also, the user is not bogged down by making a number of chart decisions. In particular, some example embodiments allows the user to focus on the “what” of their data and not the “how” relative to presenting the data. Additionally, some example embodiments prevent errors in the creation of the charts. In particular, some example embodiments help a user avoid selecting charting options that are incompatible or merely inadvisable given their data of interest.
During operation, the user specifies one or more settings that provides to the data query module a results set of data that the user is requesting from the system. In response, the data query module can retrieve and display this results set to the user. These settings specified by the user are non-charting-related settings. Based on these settings, the chart module can make inferences to determine the chart(s) that would provide insight to the user regarding the results set. Accordingly, along with the results set, the chart module can return chart(s) befitting the results set.
To further illustrate, conventional operations as compared to operations according to some example embodiments are now described. Conventional operations for receiving a chart by a user are first described. In a first operation, a user enters a data query that specifies what data the user wants. For example, the user can request data for work orders for any of 20 asset types, four work types, any problem or priority. In a second operation, the user defines the data set for the chart. In particular, the user specifies the results set that matches the data query. For example, the user can select cells in a spreadsheet. In a third operation, the user defines the type of chart. In particular, the user specifies the focus of the query about this data set. For example, the user can specify a type of chart that provides work orders by asset type, work orders by priority, etc. In a fourth operation, the user defines the layout and specifics of the chart. In particular, the user defines how to present the graphical part of the chart. Examples of such details include type of chart (e.g., bar, pie, etc), x-axis units and labels, y-axis units and labels, etc. In a fifth operation, the user defines what to do with the chart after the chart is generated. In particular, the user defines whether to modify, reuse, repurpose, aggregate with other charts, etc. For example, the user can request that a new chart type be shown, aggregate charts related to this data set, etc. In contrast to these conventional operations, for operations according to some example embodiments, the user is only required to perform the first and the fifth operations. The user is not required to perform the second, third, and fourth operations.
In the section 102, a user interface control 124 allows the user to identify one or more asset types 110 that the user wants to view as part of a data query. Also in the section 102, a user interface control 126 allows the user to identify one or more work types 112 that the user wants to view as part of a data query. In the section 104, a user interface control 128 allows the user to identify one or more problems 114 that the user wants to view as part of a data query. In the section 106, a user interface control 130 allows the user to identify one or more statuses 116 that the user wants to view as part of a data query. Also in the section 106, a user interface control 132 allows the user to identify one or more work priorities that the user wants to view as part of a data query. In the section 108, a user interface control 136 allows the user to select a chart type 122. In particular, the user can define their own chart or allow the chart module to create a chart derived from inferences that are based on the inputs from the other user interface controls in the GUI 100.
Each of the sections 102-106 include user interface controls wherein the user can select one, all, none or some (but less than all) of the options to create a data query. Assuming that the user enables the chart module to create a chart, the chart module can create a chart derived from inferences based on the different selections across the different user interface controls. For example, assuming the user has selected exactly one value from a user interface control (e.g., Asset A from the user interface control 124 for the asset types 110), the chart module can infer that the user wants to create a chart that is filtered by this characteristic (asset types). In another example, assuming the user has selected a subset of values from a user interface control (e.g., Abandonment and Administrative Support from the user interface control 126 for the work types 112), the chart module can infer that the user wants to sort or compare by this characteristic (work types). In another example, assuming that the user has selected all or none of the values from a user interface control (e.g., no selection of problems from the user interface control 128 for the problems 114), the chart module can infer that the user does not consider this characteristic (problems) a differentiating factor in creating the chart.
In addition to providing the requested data as a result of the data query (via the work order list and the work order map), the GUI 200 displays a chart 206. The chart module can derive the chart 206 from inferences of the user based on the user input controls for the data query (see examples described in reference to
Therefore, as shown, the chart module creates a two-dimensional bar chart with the y-axis providing a quantity of work orders for the three different problems and with the x-axis providing years for the three different problems. Also, note the chart module has created a title for the chart 206—“Selected Work Orders by Problem.” If the user has selected all problems for a particular asset type, the chart module can create a different title for the chart 206—“All Work Orders.” As shown, the chart 206 includes a bar 260 representing the missing covers for 2008; a bar 262 representing the loose covers for 2008; and a bar 262 representing the damaged covers for 2008. The chart 206 also includes a bar 266 representing the missing covers for 2009; a bar 268 representing the loose covers for 2009; and a bar 270 representing the damaged covers for 2009. The chart 206 also includes a bar 272 representing the missing covers for 2010; a bar 274 representing the loose covers for 2010; and a bar 276 representing the damaged covers for 2010.
At block 302, the data query module receives, for each of a number of user interface controls, selections by a user of at least one of: exactly one value, a subset of values, all values, and no values. For example with reference to
At block 304, the data query module determines whether the user has delegated decisions for creating a chart to the system. For example with reference to
At block 306, the data query module determines whether the user's chart decisions are incompatible or inadvisable. For example, the user may select a chart type, wherein the number of variables to be viewed are too many in comparison to the chart selected. To illustrate with reference to
At block 308, the data query module notifies the user of the chart decision effects. For example, the data query module can display on window over the GUI 100 that notifies the user that their chart decisions would be incompatible or inadvisable with the selection of values for the other user interface controls. Operations of the flowchart 300 continue at block 310.
At block 310, the data query module determines whether there is confirmation to proceed. For example, the window displayed over the GUI 100 can include a button to proceed and a button to cancel, thereby allowing the user to confirm proceeding with the selection of values for the different user interface controls. If there is not a confirmation to proceed, operations of the flowchart return to block 302. For example, the user can adjust the different selections of the user interface controls in the GUI 100. This can include allowing the system to perform the chart decisions and/or adjusting selections of values for one or more of the user interface controls 124-132. If there is a confirmation to proceed, operations of the flowchart 300 continue at block 314.
At block 312, the chart module infers intent of the user of at least one attribute of a chart based on the selections by the user via the number of user interface controls. In particular, the chart module can infer intent of the user based on the data query inputs by the user (the state of non-chart based settings). The chart module makes inferences to determine the charts that would provide additional insight to the user. With reference to
To further illustrate inferring user intent, an example for creating a bar chart is now described. The chart module makes a number of assumptions. The chart module distills each of the selections by the user of the user interface controls into a number of states—1) exactly one value selected; 2) a subset of values selected, and 3) all or no values selected. Each of these states can imply a certain intent on behalf of the user. In some example embodiments, the chart module does not chart more than two variables on the y-axis and uses start and end times on the x-axis. In some situations, the chart module cannot reflect all of the user selections for a particularly intricate user data query.
In some example embodiments, the chart module sets precedence rules for the chart decisions. For example, the chart module can set precedence rules for displaying certain variables in the chart when multiple variables include a subset of values. To illustrate with reference to
Returning to the example for creating a bar chart, operations are further described. The chart module first applies any filter dialog that reduces the universe of the data (e.g., assume data related to work orders). If the user's selections did not reduce the universe of work orders, the title of the chart begins with “All Work Orders.” If the user's selections did reduce the universe of work orders, the title of the chart begins with “Selected Work Orders.” Next, the chart module determines the number of user interface controls that are in the state—“subset of values selected.” The chart module then sets asides those user interface controls for these group of user interface controls, where the user has selected greater than a threshold (e.g., six). The chart module then counts the remaining user interface controls having this state (“subset of values selected”). If there are zero, the chart module uses a bar chart and appends “by Asset Type” to the title. If there is only one, the chart module uses a bar chart and appends “by X”, wherein X is the characteristic (e.g., “Problem”) for the only one user interface control. If there are between two and five, the chart module uses a stacked bar chart and applies a following set of precedence rules for the stacked bar chart.
A first precedence rule defines the primary variable in the stacked bar chart. The primary variable will be represented by N groups of one to five bars each. A second precedence rule defines the secondary variable in the stacked bar chart. The secondary variable will segment each bar into five or fewer parts of the whole. Next, the chart module determines the time units for the x-axis and the bars (analysis frequency). The chart module then finalizes setting the variables needed to be viewed (see precedence rules described above for the characteristics to be included in the bar chart). Returning to the flowchart 300 of
At block 314, the chart module displays the chart in the user interface. In particular, the chart module displays the chart that was based on user selection or the chart that was created based on the user's intent. Operations of the flowchart 300 are complete.
As will be appreciated by one skilled in the art, aspects of the present inventive subject matter may be embodied as a system, method or computer program product. Accordingly, aspects of the present inventive subject matter may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present inventive subject matter may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present inventive subject matter may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present inventive subject matter are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the inventive subject matter. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The computer system 400 includes a data query module 425 and a chart module 426 that can perform the operations (as described herein). Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processor 401. For example, the functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor 401, in a co-processor on a peripheral device or card, etc.
Further, realizations may include fewer or additional components not illustrated in
While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the inventive subject matter is not limited to them. In general, techniques for chart generation based on user control inferences as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.
Plural instances may be provided for components, operations or structures described herein as a single instance. Finally, boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the inventive subject matter. In general, structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the inventive subject matter.
