SYSTEMS AND METHODS FOR REMOTE DASHBOARD IMAGE GENERATION

Systems and methods for generating a dashboard for access on a remote computing device. Systems may include a business database storing a plurality of business values; a dashboard generator; an image converter and a web page generator. The dashboard generator may derive a plurality of key performance indicator values from the database and generate first dashboard image data. The image converter may generate second dashboard image data corresponding to the first dashboard image data. The web page generator may generate a web page comprising the second dashboard image data. Methods may include: receiving a dashboard generation request from the remote computing device; deriving a plurality of key performance indicator values from a business database; determining first dashboard image data corresponding to the key performance indicator values; determining second dashboard image data corresponding to the first dashboard image data; and generating a dashboard web page comprising the second dashboard image data.

TECHNICAL FIELD

The described embodiments relate generally to the creation and distribution of dashboards, with common but by no means exclusive application to the display of such images on mobile communication devices or other computer devices operatively coupled to the Internet.

BACKGROUND

“Dashboards” present visualizations, for example, in graph or chart form, of key performance indicator (KPI) values, metric values, or information derived from business values or data stored in business databases. Such visualizations may be viewed (e.g., on a computer screen or other display device) by executives to obtain an overview of how a business is performing.

The inventors have recognized that it may be desirable to be able to view dashboard information on a computing device that is remote or otherwise separate from the server or system creating the dashboard. Such remote computing device may not have a software graphics platform.

Additionally, client devices such as smartphones may support only touch events natively. However, most websites have no concept of touch events and are designed to respond to mouse events only. Thus, web browsers on touch devices generally implement a compatibility/legacy layer that emulates mouse events by generating corresponding, emulated (fake) mouse events. This approach allows new touch devices to work with existing websites, but results in a delay/lag and other potential disadvantages.

The inventors have recognized a need for improved systems and methods for generating and displaying dashboards remotely. The embodiments described herein may address in whole or in part some or all of the above-noted challenges.

DETAILED DESCRIPTION

The embodiments described below relate generally to a dashboard creation and management system that lets users view data visualization dashboards. Dashboards may display graphical elements that contain visual representations of key performance indicators or metrics for a business. KPIs may be business metrics that assist a business to better understand the data it has collected relating to the operation of the business. By way of example only, a dashboard created for a retail business might illustrate in graph form the business' retail sales over a period of time. Such exemplary dashboard might also illustrate in a pie chart the retail sales by product category (eg. clothing, shoes, sporting equipment) over the same (or a different) period of time. As will be understood, the nature of the KPIs or metrics displayed will vary based on the nature of the business and the needs of the individual wishing to view and understand different business metrics.

For the purposes of the present disclosure such a dashboard creation and management system may typically include two types of dashboard viewing users (who are often business executives): those who are able to locally view and interact with a dashboard using a computer directly coupled to the dashboard generation system or network (ie. not via the internet) (referred to generally below as “local viewers”), and those who are able to view and interact with a dashboard using a remote computer (ie. via the internet) (referred to below generally as “remote viewers”).

Dashboards may be designed to be interactive in a number of different ways. For example, an interactive viewer may be able to configure the date ranges to be used for filtering the business data which is to be represented in the KPIs on the dashboard, Some dashboards may be configured to allow different categories of business data to be represented in the KPIs, such as product types sold or sales by selected stores. Any particular dashboard may provide a variety of interaction options appropriate for the application.

As will be understood, the software required to interact with a dashboard (which would typically be installed on a business' office computers) may not be available on all computing devices to which an executive has access (for example, a smartphone, a tablet, or a personal computer which has not been configured with the necessary software). While away from the fully configured computers available at a business' office, an executive may still desire to view and interact with a dashboard.

In order to “render” or display dashboards, the device or computer typically requires a specific graphics or user interface platform or sub-system to be installed or supported (e.g., Adobe Flash, Microsoft Silverlight, Microsoft Windows Presentation Foundation (WPF)). However, such graphics platforms may only be available for a small number of device types. For example, most mobile devices (e.g., smartphones and tablets) do not support Silverlight or WPF. This limitation prevents dashboards from being viewed or interacted with on most mobile devices.

A typical dashboard is rendered using a combination of generalized graphical controls (e.g., labels, rectangles, buttons) and more specialized graphical controls geared towards data visualization (e.g., charts, gauges, maps, data grids). These graphical controls may depend on graphics platforms (e.g., Silverlight, WPF) that provide support for user interaction and vector graphics, which allows the rendering of controls to scale well at different display or print resolutions. While the majority of mobile devices such as smartphones and tablets may not support such graphics platforms, they do in general provide built-in support for other web browser standards or formats such as HTML/HTML5 (HyperText Markup Language), CSS (Cascading Style Sheets), JavaScript, SVG (Scalable Vector Graphics) and bitmapped images. In combination, these and other web standards may allow interactive and scalable graphics to be rendered by the web browser of a mobile device.

One aspect of the technology described herein relates to a method for generating a dashboard for access on a remote computing device. The method may include; receiving a dashboard generation request from the remote computing device;

deriving a plurality of key performance indicator and/or metric values from a business database; determining first dashboard image data corresponding to the key performance indicator and/or metric values; determining second dashboard image data corresponding to the first dashboard image data; and generating a dashboard web page comprising the second dashboard image data.

In some implementations, the dashboard web page may be accessed by the remote computing device. As well, the dashboard generation request may be communicated via the Internet. In some instances, the dashboard generation request corresponds to a dashboard URL. In turn, the dashboard web page may also correspond to or be accessed via the dashboard URL.

The method may also include communicating a message corresponding to the dashboard generation request to the remote computing device. The message may be communicated via the Internet. In addition or in the alternative, the message may include a dashboard URL or other storage address.

As well, in some implementations, the dashboard generation request comprises at least one parameter and the first dashboard image data corresponds to the at least one parameter.

In some instances, the first dashboard image data corresponds to a graphics platform. By way of example, the graphics platform may be Microsoft Silverlight or WPF.

Additionally, the first dashboard image data may comprise at least one graphical object.

In some implementations, the second dashboard image data corresponds to a web browser format. For example, the web browser format may be HTML/HTML5, CSS, JavaScript or SVG. A combination of these formats may also be used.

One aspect of the technology described herein relates to a system for generating a dashboard for access on a remote computing device. The system may include a business database storing a plurality of business values; a dashboard generator; an image converter and a web page generator. The dashboard generator may be configured to derive a plurality of key performance indicator and/or metric values from the business database and generate first dashboard image data corresponding to the plurality of key performance indicator/metric values. The image converter may be operatively coupled to the dashboard generator and configured to generate second dashboard image data corresponding to the first dashboard image data. As well, the web page generator may be operatively coupled to the image converter and configured to generate a web page comprising the second dashboard image data.

In some implementations, the web page generator may be operatively coupled to the dashboard generator. Alternatively, the web page generator may form part of the dashboard generator. Similarly, in some implementations, the image converter may comprise part of the dashboard generator. The web page may be configured to receive a dashboard generation request from the remote computing device. Such a dashboard generation request may be communicated via the Internet. Sometimes, the dashboard generation request corresponds to a URL. The dashboard web page may correspond to the URL. For some configurations, the dashboard generation request includes at least one parameter and the dashboard image corresponds to the at least one parameter.

In some implementations, the dashboard generator is configured to communicate a message corresponding to the dashboard generation request to the remote computing device. The message may be communicated via the Internet.

As well, in some implementations, the dashboard generation request comprises at least one parameter and the first dashboard image data corresponds to the at least one parameter.

In some instances, the first dashboard image data corresponds to a graphics platform. By way of example, the graphics platform may be Microsoft Silverlight or WPF.

Additionally, the first dashboard image data may comprise at least one graphical object.

In some implementations, the second dashboard image data corresponds to a web browser format. For example, the web browser format may be HTML/HTML5, CSS, JavaScript or SVG or some combination thereof.

A further aspect of the technology described herein relates to a method for determining whether a browser is configured for touch events or mouse events. The method may include: accessing a web page via the browser; receiving from the web page at least one control (which may be a JavaScript control), wherein the control is configured to hook either a mouse event or a touch event; registering a callback for the control with a script manager; upon detecting a first event, determining the type of the first event, wherein the type corresponds to a mouse event or a touch event; and determining the configuration of the browser corresponding to the type. In some implementations, the method may further include: upon determining the type of the first event, registering the control corresponding to the type. For clarity, the control is only registered to one of a mouse event type and a touch event type, but not both.

Another aspect of the technology described herein relates to a system for determining whether a browser is configured for touch events or mouse events. The system may include a web page having at least one control (which may be a JavaScript control), together with a script manager. The control is configured to hook either a mouse event or a touch event. As well, the JavaScript control is configured to register a callback with the script manager. The script manager is configured to determine the type of a first event, wherein the type is either a mouse event or a touch event. Upon determining the type of the first event, the script manager is configured to register the control corresponding to the type. For clarity, the control is only registered to one of a mouse event type and a touch event type, but not both.

Referring toFIG. 1, illustrated there is a block diagram of one possible embodiment of a system for generating a dashboard for access (on a remote computing device), shown generally as100. The system100may include one or more fully enabled client terminals102, one or more remote terminals or computing devices104A,104B,104C, a server-side dashboard generator module106and an image converter108. Each of these components may be networked (in addition to being coupled to the Internet110) and be operable to communicate with each other. While connectivity is described herein throughout in relation to the Internet110, it should be understood that other types of networks, such as a local area network (LAN) may be used. Without intending to be limiting, the remote computing devices may, for example, be in the form of a personal computer104A, a smartphone140B, or a tablet104C configured with a web browser. For example, such browsers may be HTML5 and SVG-compliant. As will be understood, dashboards prepared in accordance with the present embodiment for display on such browsers may be scalable with the use of SVG graphics, and may also be interactive through the use of JavaScript (JS). The remote computing devices104A,104B,104C will also typically be configured with an email reader.

Further, while the generator module106and image converter108are illustrated as being separate components, it should be understood that in some implementations, the image converter108may be considered to comprise part of the dashboard generator module106and/or reside on the same server/computer. In some implementations, the converter108may be an in-memory converter or exporter that transforms Silverlight or WPF graphical objects to SVG graphical objects, for example. Briefly, as will be understood, rendering of dashboard controls may be performed on the server/computer on which the dashboard generator106resides, and then such controls may be converted to more accessible web standard formats such as HTML5 and SVG which may be viewed on a remote computer via a suitably configured web browser.

Complex data visualization controls such as charts may be rendered via a WPF-to-SVG converter. This avoids the need to re-implement such controls natively in HTML/HTML5/SVG/JavaScript/CSS and enables re-use of the code written for the original Silverlight version of the dashboard. The conversion may be performed on-demand and may be dynamic in order to handle changes made to the dashboard controls via script interactions with the browser.

The system100may also include a business database112. A business data server (not shown) may also be provided which executes software components that provide access to the business database112.

As will be discussed in greater detail below, the business database112may store business data120corresponding to a plurality of business values (e.g., sales, expenses, inventory or human resources data) that relate to the operation of a business. As an illustration, the business database112may be an accounting and inventory management database that stores transactional data for a sporting goods store. In some embodiments, the business database112may be stored on a separate computer or server accessible by the dashboard generator106.

As will be understood, all or a subset of business values may be selected from the business database112for the purpose of deriving (or calculating) KPI or metric values for visualization on the dashboard to be generated. For example, the KPUmetric values may be derived by performing a summation or other mathematical process on the business values.

Referring briefly toFIG. 2, shown there is an example dashboard200showing various different graphical KPI visualizations202. One exemplary type of KPI visualization illustrated in the dashboard200is the ‘Total Sales by Product Type’ KPI202a, depicting bar graph data corresponding to sales of specified products over a period of time.

Referring again toFIG. 1, exemplary client terminals102, remote computing devices104A,104B,104C, dashboard generator module106and image generator108may comprise a number of components (which have not all been illustrated), including microprocessors. In the exemplary configuration illustrated inFIG. 1, the microprocessor (which may be in the form of a server, for example) on which the software of the image generator108is run is referred to herein as the image creating computer114. As noted above, this microprocessor114may be the same as or different from the microprocessor(s) (which may be in the form of one or more servers, for example) on which the software of the dashboard generator module106runs.

Microprocessors typically control the overall operation of computer systems. Microprocessors interact with additional subcomponents such as memory storage (which may include random access memory (RAM) and read-only memory (ROM), and persistent storage such as flash memory), display, network adapter and input device(s), for example, such as a keyboard, mouse, touchscreen (which may form part of the display) or touchpad.

Network adapters allow connection to different types of networks (for example, Local Area Networks (LANs) as well as Wide Area Networks (WANs)), and may be wired (for example, through an Ethernet connection) or wireless (for example, through802.11Wireless Local Area Network (WLAN) or cellular standards). Operating system software used by a microprocessor is typically stored in a persistent store such as flash memory or read-only memory (ROM) or similar storage. Those skilled in the art will appreciate that the operating system, specific software components, or parts thereof, may be temporarily loaded into a volatile store such as RAM. Microprocessors, in addition to operating system functions, enable execution of software components.

In the exemplary embodiment inFIG. 1, it should be understood that the computers/microprocessors of the remote terminals or computing devices104A,104B,104C are separate from the image generating computer114. Reference herein to “remote” computing devices104A,104B,104C is intended to convey that such computing devices104A,104B,104C are remote from the dashboard generator106and indirectly coupled thereto via the Internet110—in this context, “remote” is not intended to refer to geographical distance. Such remote computing devices104A,104B,104C do not have graphical platforms installed, capable of recognizing and using the first dashboard data116, as will be discussed in greater detail below.

From a high level perspective, the dashboard generation module106provides interactive dashboard functionality and visualization for interactive viewers on the fully graphics-enabled client terminal102. While not illustrated, it will be understood that more than one client terminals102may access (simultaneously or otherwise) the interactive dashboard functionality provided by dashboard generation module106. The dashboard generation module106may generate first dashboard image data116which consists of data needed to render the desired dashboard on the client terminal102. This image data116may contain serialized definitions of dashboards and Silverlight or WPF-based graphical controls.

In contrast, users may be able to view and interact with a dashboard (such as dashboard200) on the remote computing device(s)104A,104B,104C via a web page. The dashboard URL (uniform resource locator)150address corresponding to the dashboard web page140is communicated to the remote computing device(s)104A,104B,104C typically via the Internet, such as via email. As will be discussed in greater detail, below, the dashboard image data116′ is generated by the image converter108upon request from the dashboard generation module106. The image converter108may transform, export or otherwise convert the first dashboard image data116to standard formats (eg. HTML/HTML5, SVG, CSS, JavaScript, bitmapped images) to generate the second dashboard image data116′. Such second dashboard image data116′ may be recognized and understood by a majority of web browsers on a wide range of device types.

As noted above, the business database112may store business data120. Such business data120may correspond to any data stored by a business organization in relation to the operation of its business. For example, this may include transactional sales data or inventory data. The dashboard generation module106may include a dashboard creation and management system for creating and managing executive business dashboards (such as exemplary dashboard200illustrated inFIG. 2) that show business metrics, typically in a graphical format. As noted above, such business metrics for the dashboard creation and management system may be derived from the business data120.

Dashboard generation module106may select certain business data120, generate corresponding KPIs/metrics and organize/present the KPIs/metrics in a dashboard200for interactive viewing by business executives using a client terminal102(for example, which may be in the form of a desktop or notebook PC). Such terminal102may be equipped with a graphics platform122such as Microsoft Silverlight™ or Windows Presentation Foundation (WPF). Specifically, the user may use a desktop software application (e.g., equipped with WPF) or a web browser (e.g., equipped with Silverlight™) available on terminal102to select and interactively view a dashboard200of interest.

A request to view a dashboard200may be made from the terminal102to the dashboard generation module106. The dashboard generator106returns data116which consists of information needed by the graphics platform122to render the desired dashboard200on the display of computer102. In this way, the client terminal102may be considered a client computer in the client-server software architecture known in the art.

As will be understood, the dashboard generation module106may further be configured to request that the image converter108convert image data for a specified dashboard200. By “specified”, it is meant that various parameters defining the type of data and the display preferences of the dashboard are determined by the dashboard generation module106(often as a result of input from the user of the terminal102). As will be understood in the context of the following discussion, the dashboard generation module106may be configured to create a dashboard URL150corresponding to the desired dashboard200and its preferences.

Referring again briefly toFIG. 2, by way of example only, preferences determined for the dashboard200may include the products to be included in the “Total Sales by Product Type” KPI202a(eg. “Ski”, “Skate”, “Bike”, “Kite”), the date range of the data to be displayed (January to June), as well as the choice to illustrate the data in a bar graph format. As will be understood, other types of preferences may be determined in order to specify the KPIs or metrics to be determined and displayed, as well as the configuration of the dashboard200. Once the first dashboard image data116corresponding to the dashboard200is created, the image converter108may generate and return corresponding second dashboard image data116′ back to the dashboard generator module106.

Referring again toFIG. 1, the generation module106may include a communication module134configured to include the dashboard URL150corresponding to the desired dashboard200in the form of a hyperlink in an email message136. Such email message136may then be communicated to a remote computing device104A,104B,104C.

The dashboard generator106may also be provided with a web page generator160configured to generate and host an Internet web page140that incorporates the generated second dashboard image data116′ and presents the dashboard200. As will be understood, in some implementations, the web page generator160may be a separate component from the dashboard generator106. The dashboard web page140is accessible to a remote computing device(s)104A,104B,104C which has been configured with a web browser and is coupled to the Internet110. As noted above, the remote computing device104A,104B,104C may be provided with the dashboard URL150from receipt of the email message136. Once in possession of the dashboard URL150, as will be understood, a remote computing device104A,104B,104C may access the dashboard web page140via the Internet110.

Typically, the web page140would comprise basic HTML coding in addition to the second dashboard image data116′ and be viewable by a standard web browser—as a result (as previously noted), no specialized graphics platform (similar to the graphics platform122the local terminal102may be equipped with) which would otherwise be required for viewing the dashboard (using the first dashboard image data116), is possessed by such remote computing device(s)104A,104B,104C.

Referring simultaneously toFIGS. 3 and 4, exemplary methodology and component configuration are discussed.FIG. 3illustrates the internal components of the image converter108in greater detail in one embodiment as may be implemented in accordance with the present disclosure.FIG. 4is a flow diagram of a method, shown generally as400, for generating a dashboard for access on a remote computing device, in accordance with one or more possible embodiments.

The “on-demand” generation of a dashboard200may be initiated by a computer, such as a remote computing device104A,104B,104C navigating to the dashboard image web page140(and which may be hosted by, and forms part of, the dashboard generator106) at the corresponding URL, in order to cause the generation of a specific dashboard request. A dashboard generation request is received by the dashboard generation module106from the remote computing device104A,104B,104C accessing the dashboard image web page140. (Block402)

As noted above, various parameters defining the type of data and the display preferences of the dashboard200may be specified within the dashboard URL150corresponding to the dashboard web page140. Such parameters may be communicated to the generation module106via URL query parameters. By way of further example, such parameters may include the information needed to identify the dashboard (such as its GUID (Globally Unique Identifier) and the state of its filters (if any), which are passed in to the web page140.

Upon receiving the query parameters necessary to identify and/or generate the desired dashboard200, the dashboard generator106is configured to access the business database112and derive one or more KPI or metric values from the business data120. (Block404)

When the dashboard generator106has finished determining or rendering the dashboard200(corresponding to the query parameters), it creates first dashboard image data116corresponding to the dashboard200. (Block406) As will be understood, the first dashboard image data116corresponds to or otherwise describes the derived KPI/metric value(s).

Referring specifically toFIG. 3, illustrated therein is a block diagram of one possible configuration of a deployed dashboard converter108. The first dashboard image data116is applied as input to the conversion system108. As discussed previously, the first dashboard image data116includes information needed to render a dashboard200on a display-capable device. Such information may include serialized definitions of dashboards, graphical controls or encapsulations of the data being visualized.

A deserialization module302deserializes the first dashboard image data116into in-memory dashboard objects310. (Block408) A data-binding module304receives the dashboard objects310as input and generates WPF controls or objects312which also exist in-memory. (Block410) The WPF objects312define the visual representation of a dashboard200which corresponds exactly to the first dashboard image data116. A rendering module306takes the set of WPF objects312as input and as described in greater detail below, renders the corresponding dashboard200in second dashboard image data116′ which adheres to web browser standards such as HTML/HTML5, SVG, CSS, JavaScript and bitmapped image formats. (Block412)

The rendering module306may render the set, or a subset, of the WPF controls or objects312in the form of a bitmapped image. This functionality can be described as taking a “snapshot” of the corresponding dashboard or set of controls.

In addition or in the alternative, the rendering module306may render certain types of WPF objects312(e.g., data visualization controls) in the SVG format, which provides support for vector graphics. In such cases, the rendering module306may use a

WPF-to-SVG converter308to transform, export or otherwise convert WPF objects312to SVG objects. The rendering module306uses the resulting SVG objects to embed corresponding SVG content (e.g., SVG markup tags) into the second dashboard image data116′.

As will be understood, certain types of WPF objects which require user interaction, such as input or selection controls, may be rendered as HTML/HTML5 elements rather than as SVG objects since SVG is primarily a presentation or graphics output format. HTML/HTML5 may also be used instead of SVG in cases where, for example, HTML/HTML5 elements exist that match the type of WPF object being converted more naturally.

Additionally, in some instances, the second dashboard image data116′ may also be generated to include JavaScript. Depending on the type of device104A,104B,104C and web browser, JavaScript may be used to facilitate user interaction with the rendered dashboard200. For example, JavaScript may be used to provide tooltips on mobile devices because most web browsers on mobile devices104A,104B,104C do not support tooltips natively.

The conversion process or steps described in relation toFIG. 4may be performed using separate threads (e.g., one thread per dashboard viewing request) in order to avoid performance bottlenecks which may occur when multiple requests to view dashboards are delivered simultaneously to the dashboard conversion system108.

FIG. 5is a schematic diagram illustrating the operation of the WPF-to-SVG converter308.FIG. 5illustrates the process of converting a single WPF control to SVG format. A serialized WPF control object (as may be stored in the first dashboard image data116) is stored in-memory as a tree of WPF objects504. For example, a “radial gauge” data visualization control in the WPF format may be represented as a tree of graphical primitive objects such as ellipses, rectangles or other types of geometry. The WPF object tree504is passed as input to the WPF-to-SVG converter308. The converter308visits each node or object in the WPF object tree504in a specific order and, for each object, creates one or more corresponding SVG objects. These SVG objects are then inserted into a SVG object tree508, which is the SVG representation of the WPF control502being converted.

The SVG object tree508may be used to generate or output corresponding SVG markup tags510, which may be written out in the form of an “SVG file” (e.g., with file extension “SVG”), or embedded directly into a raw HTML stream for display in a SVG-compliant web browser.

Since Silverlight can be considered in some ways to be a subset of WPF, the converter308inFIG. 5can be easily adapted to the conversion of Silverlight objects instead of WPF.

Optionally, as shown inFIG. 5, a Silverlight or WPF control that is described in a “XAML file”502, or described in the form of XAML (Extensible Application Markup Language) markup, can be deserialized into memory as a Silverlight / WPF object tree504and then applied as input to the converter308.

Example Conversion of a Silverlight or WPF Ellipse

FIGS. 6A-6Care charts containing exemplary data illustrating the conversion of an ellipse object (as may be stored in the first dashboard image data116) into the second dashboard image data116′ for incorporation into and display in the dashboard web page140. Referring now toFIG. 6A, illustrated therein is a table showing the properties (i.e., property names and values) of an example Silverlight/WPF “Ellipse” object shown generally as600which may exist in the WPF object tree504inFIG. 5,

Turning now toFIG. 6B, this is a table illustrating example SVG “ellipse” attributes610(i.e., attribute names and values) corresponding to the Silverlight WPF object600after conversion using the converter308inFIG. 5.

FIG. 6Cis a schematic illustration of an example SVG ellipse markup tag620corresponding to the SVG ellipse attributes610shown inFIG. 6B.

Referring simultaneously toFIGS. 7 and 8, exemplary methodology and component configuration are discussed.FIG. 7provides some additional detail of the dashboard generator106and the image converter108and their interaction with other components of the system100as may be implemented in accordance with the present disclosure.FIG. 8is a flow diagram of a method, shown generally as800, for generating a dashboard for access on a remote computing device, in accordance with one or more possible embodiments.

The “on-demand” generation of a dashboard200for viewing remotely may be initiated by a computer, such as a remote computing device104A,104B,104C navigating to the HtmlViewer.ashx URL/web handler708(which may be hosted by, and forms part of, the dashboard generator106) at the corresponding URL in order to generate a request to generate a specific dashboard200. A dashboard generation request is received by the dashboard generation module106from the remote computing device104A,104B,104C accessing the dashboard image web page140. (Block802)

As noted above, various parameters defining the type of data and the display preferences of the dashboard200may be specified within the dashboard URL150corresponding to the dashboard web page140. Such parameters may be communicated to the generation module106via URL query parameters. By way of further example, such parameters may include the information needed to identify the dashboard, such as its GUID (Globally Unique Identifier) and the state of its filters (if any), which are passed in to the web page140. An example URL comprising such parameters contained within the URL might look like the following: “http://dashsvr/HtmlViewer.ashx?param1=xx&param2=yy& . . . ”, with “xx” and “yy” representing dummy values for exemplary parameters represented by “param1” and “param2”, respectively.

Upon receiving the query parameters necessary to identify and/or generate the desired dashboard200, the dashboard generation module106is configured to access the business database112and derive one or more KPI/metric values from the business data120. (Block804)

The dashboard generation module106may generate the first dashboard image data116corresponding to the desired dashboard200(which in turn corresponds to the one or more KPI values). (Block806) As has previously been discussed, the first dashboard image data116corresponds to a graphics platform format (such as Silverlight and/or WPF).

The web handler708may then cause the image converter108to create second dashboard image data116′ corresponding to the first dashboard image data116. (Block808) Such conversion process is discussed in greater detail in relation toFIGS. 3, 4, 5 and 6A-6C.

The web page140incorporates the second dashboard image data116′ inline for display of the dashboard200, (Block810) This allows the requesting device, such as a remote computing device104A,104B,104C, to access the dashboard web page140and view (and interact with) the dashboard200in a web browser. (Block812)

As will be understood, in some embodiments remote computing device(s)104A,104B,104C may navigate to an HtmlExplorer.ashx web handler URL which is configured to present a user interface for browsing and selecting an available dashboard for HTML viewing. In such embodiments, there is no need to pass in URL query parameter(s) such as a dashboard ID because the dashboard parameter(s) may be chosen interactively.

Turning briefly toFIG. 9, illustrated therein is a schematic diagram illustrating the structure, shown generally as900, of the HTML content (of the second dashboard image data116′) representing a dashboard200. In the context ofFIG. 9, “HTML content” is intended to refer to HTML/HTML5, SVG, CSS, JavaScript collectively. As will be understood, SVG, CSS, and JavaScript are all standards which are different from the HTML standard. The HTML content900includes HTML page data902, SVG data904, CSS data906and JavaScript modules908. The CSS elements/data906may provide styling for the HTML elements/data902and SVG elements/data904.

The JavaScript modules/files908may provide a framework for making the “HTML dashboard” interactive. This includes handling events from the web browser (mouse, touch) and providing implementation of JavaScript-only controls such as datagrid, datepicker, slider, dropdownlist and a hierarchy explorer.

Referring now toFIG. 10, illustrated therein is a schematic diagram illustrating the various types of modules comprising the JavaScript framework908which follows a component service type of architecture. As illustrated, the JavaScript modules908may include a script manager1002, controls1004, services1006, behaviors1008and interactions1010.

The script manager1002is a singleton class which controls the whole page and is responsible for setting up the client side framework. Controls1004are script classes which are attached to browser DOM (Document Object Model) elements. Their purpose is to use JavaScript and the browser's DOM to add interactivity to their target elements and perform computations. For example: the datepicker control class recalculates its calendar as the user selects various years, months, and days. Controls1004have access to the script manager1002and can use it to make AJAX requests to the server (e.g., AJAX request to HtmlViewer.ashx708). For example, if you click a dropdownlist that is used to filter data appearing on the dashboard, the new selection must be sent back to the server (via AJAX request) so that it can render the updated dashboard, convert it, and send back the updated HTML content.

The services1006provide common functionality that can be accessed by anything on the web page140(shared services).

Behaviors1008represent the logic behind a complex event which has no native browser equivalent. For example: a hover behavior represents the sequence of events of the mouse entering an element, moving within it and becoming stationary for a set period of time. This logic is abstracted and made reusable by packaging it into a behavior. Script controls instantiate a hover behavior and listen for its ‘hover’ event. When and where the ‘hover’ event fires is abstracted by the behavior. When on touch browsers, the hover behavior can use different logic for determining what constitutes a hover without affecting the script controls.

Interactions1010are components that can be attached to DOM (Document Object Model) elements to respond to common dashboard interaction events (eg: click, hover). Interactions allow for handling of client-side events on any DOM element without having to define a script control for it. This saves development effort since script control classes do not have to be defined for static dashboard elements (e.g., Label) which have no client-side functionality besides responding to common events.

Dashboard with 1 Chart and 1 Dropdown List Filter:

The following outlines an exemplary sequence as may be carried out via the web browser of a remote computing device(s)104A,104B,104C when accessing the dashboard web page140for a dashboard200having 1 chart and 1 dropdown list control which can be used to filter data appearing on the dashboard200:

1. The dashboard200(specifically, the second dashboard data116′) is rendered to the browser via the HtmlViewer.ashx handler708.
2. The Script Manager1002is created and registers a handler for the DOMContentLoaded' event.
3. The browser fires the event and the Script Manager1002begins its initialization.
4. The Script Manager1002creates and initializes the script services.
5. The dashboard web page140contains inline JavaScript which hold information about the various script objects which must be created, their initialization parameters, and the DOM elements to which they should be attached.
6. The Script Manager1002creates and initializes each script object.
7. The onLoaded method is invoked for each object permitting it to initialize itself.
8. Once all objects have been created, the dashboard web page140is ready for use.
9. The user may select a value from the dropdown list control.
10. The ‘change’ event handler for the dropdown list script control1004class is invoked.
11. The script control1004gets the selected value and uses the Script Manager1002to trigger an AJAX (Asynchronous JavaScript and XML) call to update the dashboard200.
12. The Script Manager1002invokes the AJAX request. If the Script Manager1002has any server state information saved, it is sent along with the request.
13. The HtmlViewer.ashx handler708processes the request and renders a JSON (JavaScript Object Notation) response with the updated controls and script objects.
14. The Script Manager's1002request complete handler is invoked.
15. The Script Manager1002checks for any errors during the request and if none are found, begins the process of updating the dashboard200,
16. The controls1004which have been marked as updated by the server's response are overwritten with the updated markup. Any existing script objects bound to the controls1004are destroyed,
17. Any new script objects received from the server's response are created and bound to the updated controls1004.
18. The Script Manager1002stores any server state information received from the server.
19. The dashboard200is updated and ready for use.

Dashboard with 1 Chart and Supports Drilldown to Another Dashboard:

The following outlines an exemplary sequence as may be carried out via the web browser of a remote computing device(s)104A,104B,104C when accessing the dashboard web page140for a dashboard200having 1 chart and which supports a “drill down” to another dashboard200:

1. The Script Manager1002is initialized as in the steps outlined above (for a dashboard200having 1 chart and 1 dropdown list control).
2. User “clicks” on the chart.
3. The chart does not have an associated script control but instead has a click interaction.
4. The click interaction registers the click and uses the ScriptManager to trigger an AJAX call to update the dashboard200.
5. The Script Manager1002invokes the request.
6. The request is processed on the server as outlined above.
7. The server's response indicates that methods from the ScriptServices service should be invoked.
8. The Script Manager1002retrieves the ScriptManager service and tells it to invoke the methods.
9. The NavigateToDashboard ScriptService method is invoked with associated parameters.
10. The method creates a new URL to the dashboard with the given ID and with the given parameters.
11.The method sets the window, location property to the new URL.
12. The browser navigates to the new web page140.
13. The HtmlViewer.ashx handler708renders the new dashboard200(which may be the same as the previous one) with the given parameters thus creating a drilldown.
14. The new dashboard200is ready for viewing and interaction.

Mouse Versus Touch Event Handling

Client devices such as smartphones may support only touch events natively. However, most websites have no concept of touch events and are designed to respond to mouse events only. Thus, web browsers on touch devices generally implement a compatibility/legacy layer that emulates mouse events. For example, when a user touches their smartphone screen, the touch browser fires a TouchStart event. When the user releases their touch, a TouchEnd event is fired. The compatibility layer kicks in a short time after (possibly up to 500 milliseconds later) and fires off corresponding, emulated (fake) mouse events. This allows new touch devices to work with existing websites, albeit with a bit of a delay/lag.

This approach may result in three general types of disadvantage. First, a lag or delay may occur on the touch device which makes the website appear less responsive. Second, a noticeable flashing/highlighting effect may result. For example, on a touch device with certain browser (such as Safari) and the user tap's on something on the touch display, the browser may create a partially transparent rectangle over what was tapped and flashes it if the web page is configured to receive mouse events only (i.e. the browser flashes the target element to indicate a click). The flashing can be removed via CSS, but this is just masking the problem. Third, emulated mouse events can only have one point, whereas touch events can give you multiple simultaneous touches (multi-touch events) and support for gestures like swipe.

To solve the above problems (which happen when a website is configured to receive mouse events only), it is necessary to determine if the browser is configured for touch events or mouse events. However, it is not possible to determine this with absolute certainty. One approach (when designing a new website for both desktops and mobile) is to use browser detection in the JavaScript code. Such browser detection checks the userAgent or uses feature detection on browser objects.

Detection based on the userAgent is prone to inaccuracies. For example: Windows Phone uses IE (Internet Explorer) 9 with touch events, whereas regular IE 9 works with mouse events, but the userAgent would report both as IE 9. Another example is

Google Chrome which can switch to touch mode if its environment is touch-based (eg. a Windows desktop that has a touchscreen). Such browser detection is also not future proof (e.g., every time a new browser is released, it may be necessary to update the existing detection code).

Another approach is to configure the website to always handle both touch and mouse events. By handling both, the lag problem may be resolved but the flashing problem may not be. The flashing occurs wherever a mouse event is attached, regardless of whether the mouse event “fires” or not. This is because the browser detects that a mouse event handler is registered, and so it will go through its mouse compatibility/legacy pipeline.

The solution used in the present disclosure is to determine if the browser is configured for touch events or mouse events based on which type of event is received first in the web page140. Then either touch or mouse event handlers (based on which type of event is received first) are registered (but not both). This approach works because if the user is accessing the web page140via a touch device, touch events always arrive first.

Thus only one type of event (mouse or touch) is triggered by the browser, and not both. A corresponding event (or layer) is not triggered. The solution does not care about which type of browser is being used.

As further illustrated inFIG. 11, the following outlines an exemplary sequence shown generally as1100for determining whether the browser is configured for touch events or mouse events as may be carried out by a remote computing device(s)104A,104B,104C when accessing the dashboard web page140for a dashboard200:

1. The dashboard web page140(which incorporates Script Manager1002and control data) is accessed by the browser of a remote computing device(s)104A,104B,104C. (Block1102)
2. The Script Manager1002and control data are received by the web browser from the web page140. The web page140initiates an onload event which starts up the Script Manager1002(running on the web browser). The Script Manager1002is responsible for setting everything up such as creating JavaScript controls1004corresponding to the received control data. (Block1104)
3. If a created control1004needs to hook mouse/touch events, the control delays its event registration and instead registers a callback with the script manager1002. (Block1106)
4. As will be understood, the system waits for the user to interact with the web page140. When the first event is received by the page140as a result of user interaction (e.g., the user moves the mouse or touches a touchscreen), the Script Manager1002checks the type of the event (ie. touch or mouse event) and sets its own IsTouchBrowser boolean (ie. “yes” or “no”) value. (Block1108) The Script Manager1002then notifies each of the controls1004that registered a callback and causes each such control1004to register or configure itself for either mouse or touch operation (corresponding to the first detected event). (Block1110)

It will be understood that while the term databases are illustrated and used in the present disclosure, any suitable method of persistent storage (e.g., a fixed format file system) may be used in the role of the illustrated databases. It will also be understood by a person skilled in the art that data and/or databases illustrated and/or described separately herein can be stored together as separate files or data elements within the same or multiple databases both locally and/or remotely.

It will also be understood that other system arrangements and configurations may be possible. It will be understood by persons skilled in the art that variations are possible in variant implementations and embodiments. Such variations include, but are not limited to, variations in the connectivity amongst described components, the sequence of execution by described components and the organization of described components.

The steps of a method in accordance with any of the embodiments described herein may be provided as executable software instructions stored on computer-readable media, which may include transmission-type media. Such steps may not be required to be performed in any particular order, whether or not such steps are described in claims or otherwise in numbered or lettered paragraphs.

The invention has been described with regard to a number of embodiments.

However, it will be understood by persons skilled in the art that other variants and modifications may be made without departing from the scope of the invention as defined in the claims appended hereto.