U.S. patent application number 14/683079 was filed with the patent office on 2016-04-14 for data visualization extensibility architecture.
This patent application is currently assigned to Microsoft Technology Licensing, LLC.. The applicant listed for this patent is Microsoft Technology Licensing, LLC.. Invention is credited to Barry Christopher Allyn, Peter H. Hufnagel, Qijin Zhou.
Application Number | 20160104307 14/683079 |
Document ID | / |
Family ID | 55655563 |
Filed Date | 2016-04-14 |
United States Patent
Application |
20160104307 |
Kind Code |
A1 |
Allyn; Barry Christopher ;
et al. |
April 14, 2016 |
DATA VISUALIZATION EXTENSIBILITY ARCHITECTURE
Abstract
An extensibility framework for enabling the creation of new
visualizations and the extension of existing visualizations is
provided to improve the functionality of a computer. According to
aspects, the architecture enables building data visualizations via
a one-directional chain of separate stages that have simple input
and output interfaces. The described extensibility architecture
enables quick and simple extensibility of visualization types via
series layouts that are independent of the rest of the
architecture. The extensibility architecture allows for the
compositing of features in such a way that allows clients to add
additional functionality and the build-out of visualization types
via a multiplicative behavior of chaining capabilities together.
Accordingly, series layouts can be plugged into the data
visualization platform in a generic way. The architecture is
operable to work in multiple environments, and is not biased toward
a single client.
Inventors: |
Allyn; Barry Christopher;
(Snohomish, WA) ; Zhou; Qijin; (Bellevue, WA)
; Hufnagel; Peter H.; (Seattle, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Technology Licensing, LLC. |
Redmond |
WA |
US |
|
|
Assignee: |
Microsoft Technology Licensing,
LLC.
Redmond
WA
|
Family ID: |
55655563 |
Appl. No.: |
14/683079 |
Filed: |
April 9, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62063741 |
Oct 14, 2014 |
|
|
|
Current U.S.
Class: |
345/440 |
Current CPC
Class: |
G06T 11/206 20130101;
G06T 2200/28 20130101; G06F 16/164 20190101; G06T 11/003 20130101;
G06T 2200/04 20130101; G06T 1/20 20130101; G06T 11/40 20130101;
G06K 9/52 20130101; G06T 2219/2024 20130101; G06T 15/08 20130101;
G06T 2219/004 20130101; G06T 11/60 20130101; G06T 15/40 20130101;
G06T 13/80 20130101; G06T 2210/36 20130101; G06T 13/20 20130101;
G06T 19/20 20130101; G06T 2219/2012 20130101; G06T 17/10 20130101;
G06T 2210/44 20130101 |
International
Class: |
G06T 11/20 20060101
G06T011/20; G06T 1/20 20060101 G06T001/20 |
Claims
1. A computer-executed method for improving the functionality of a
computer providing a data visualization according to an existing
architecture, comprising: managing a pipelined flow of information,
wherein the information is used to graphically represent data
including series via a visualization, by inserting a transform into
the pipelined flow to customize the visualization; receiving the
data and a surface description of the visualization; creating
geometry to graphically represent each series of the data within
the visualization based on the surface description, wherein the
transform customizes one or more of the geometry; and transmitting
the customized geometry to a client operable to render the
visualization in accordance with the transform.
2. The computer-executed method of claim 1, wherein the inserted
transform is a data transform, wherein the data transform modifies
a format of the received data, wherein the data according to the
modified format is operable to produce the customized geometry.
3. The computer-executed method of claim 1, wherein the inserted
transform is a geometry transform, wherein the geometry transform
modifies how the customized geometry is rendered by the client.
4. The computer-executed method of claim 1, wherein the inserted
transform is a series layout, wherein the series layout modifies
the created geometry to graphically represent at least one of the
series of the data within the visualization.
5. The computer-executed method of claim 1, wherein the client is
operable to present a plurality of transforms to be inserted that
are determined to be appropriate for the data based on features of
each transform of the plurality of transforms, wherein each
transform of the plurality of transforms includes annotations
operable to indicate its features to the client.
6. The computer-executed method of claim 5, wherein at least one of
the plurality of transforms is inserted.
7. The computer-executed method of claim 1, wherein the pipelined
flow of information is unidirectional, wherein the information
flows from the client, to a data visualization platform, operable
to create the geometry, and flows back to the client, where the
geometry is rendered within the visualization.
8. The computer-executed method of claim 1, wherein the pipelined
flow of information includes: a data transform stage, corresponding
to receiving the data and the surface description of the
visualization; a layout transform stage, corresponding to creating
the geometry; a geometry transform stage, corresponding to
rendering the visualization; and wherein the transform is operable
to be inserted at each of the stages.
9. A system for improving the functionality of a computer providing
a data visualization according to an existing architecture,
comprising: a processor; and a memory storage including
instructions, which when executed by the processor cause the
computing device to be operable to provide: a data visualization
platform, including: a series layout module, operable to create
geometry to graphically represent data series in a visualization;
and a core engine, operable to: receive the data series and surface
description of the visualization; transmit the data series and the
surface description to the series layout module to create the
geometry based on the surface description; and assemble the
visualization based on the geometry and the surface description;
and an extension module, operable to insert transforms into the
data visualization platform to customize the visualization, wherein
the transforms modify information used by the data visualization
platform to provide a customized visualization.
10. The system of claim 9, wherein the transforms are data
transforms, wherein the data transforms are operable to modify a
format of the received data.
11. The system of claim 9, wherein the transforms are geometry
transforms, wherein the geometry transforms are operable to modify
how the geometry are rendered.
12. The system of claim 9, wherein the transforms are layout
transforms, wherein the layout transforms are operable to modify
how the geometry are defined to graphically represent the data
series in the visualization.
13. The system of claim 12, wherein the layout transforms are
further operable to provide shared functionalities within the
visualization.
14. The system of claim 9, wherein the data visualization platform
comprises a unidirectional pipeline in which the information flows,
the unidirectional pipeline including: a data transform stage,
corresponding to receiving the data and the surface description of
the visualization; a layout transform stage, corresponding to
creating the geometry; a geometry transform stage, corresponding to
assembling the visualization; and wherein the extension module is
further operable to insert the transforms at each of the
stages.
15. The system of claim 9, wherein the transforms include series
layouts, wherein the series layouts include interfaces operable to
isolate the series layouts from the system and provide the series
layouts with only the data and a coordinate space from the surface
description, wherein the series layout are operable to produce the
geometry from the data and the coordinate space.
16. A computing device operable for improving the functionality of
a computer providing a data visualization according to an existing
architecture, comprising: a processor; and a memory storage
including instructions, which when executed by the processor cause
the computing device to be operable to: manage a unidirectional
pipelined flow of information, wherein the information is used to
graphically representing data via a visualization, by inserting a
transform into the pipelined flow to customize the visualization,
wherein the unidirectional pipelined flow includes a data transform
stage, a layout transform stage, and a geometry transform stage;
receive the data and a surface description of the visualization,
wherein the data includes data series, and wherein receiving the
data and the surface description corresponds to the data transform
stage; provide the data series of the data and the surface
description to a series layout to create geometry to graphically
represent each data series within the visualization, wherein
creating geometry corresponds to the layout transform stage;
transmit the geometry to a client operable to render the
visualization, wherein transmitting corresponds to the geometry
transform stage; and wherein the transform is inserted at one of
the stages to customize one or more of the geometry.
17. The computing device of claim 16, wherein the inserted
transform is a data transform, wherein the data transform is
inserted at the data transform stage and modifies a format of the
received data, wherein the data according to the modified format is
operable to produce the customized geometry.
18. The computing device of claim 16, wherein the inserted
transform is a layout transform, wherein the layout transform is
determined to be appropriate for the data based on annotations
included in the layout transform, wherein the layout transform is
inserted at the layout transform stage and modifies a definition
used to create the geometry to create the customized geometry.
19. The computing device of claim 16, wherein the inserted
transform is a geometry transform, wherein the geometry transform
is inserted at the geometry transform stage and modifies how the
customized geometry is rendered by the client.
20. The computing device of claim 16, wherein each stage produces
an output according to a normalized format, wherein the transform
is operable to produce a transform output according to the same
normalized format as the stage at which the transform is inserted.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Patent Application No. 62/063,741, titled "Data Visualization"
filed Oct. 14, 2014.
BACKGROUND
[0002] Data visualization is a process for graphically representing
data in a visualization, for example, a chart, an infographic, a
map, a gauge, etc. Typically, when providing extensions (e.g., new
visualization types) to a charting engine, large development costs
were entailed, for example, in authoring the visualization and in
the integration of the visualization by the client. Implementing
new visualization types or versioning existing visualization types
was therefore labor intensive and costly. Existing visualization
could become unwieldy as their functionalities expanded and may be
incompatible with newer or older data visualization clients, thus
limiting the functionality of the device running the client or
forcing the use of unwieldy workarounds.
[0003] It is with respect to these and other considerations that
examples will be made.
SUMMARY
[0004] This summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description section. This summary is not intended to
identify all features of the claimed subject matter, nor is it
intended as limiting the scope of the claimed subject matter.
[0005] An architecture for creating new visualizations and
extending existing visualizations within a data visualization
platform architecture is provided. According to an aspect, the
architecture enables building of a data visualization (e.g., a
chart, an infographic, a map, a gauge, etc) via a one-directional
chain of separate stages, each stage having a simple input
interface and output interface. Aspects of the present disclosure
provide an extensibility architecture that enables quick and simple
extensibility of visualization types via series layouts that are
independent of the rest of the architecture. The extensibility
architecture allows for the compositing of features to enable
clients to add additional functionality and build out of
visualization types via a multiplicative behavior of chaining
capabilities together. Accordingly, series layouts can be plugged
into the data visualization platform in a generic way.
[0006] The architecture of the data visualization platform isolates
the series layout logic from the rest of the system, such that each
part has a simplistic view of other parts and therefore cannot
become intertwined. According to several aspects, series layouts
take as input a set of data plus a surface description (e.g., axes,
coordinate space, resolution/dpi, etc.) and produce as output a
collection of annotated geometry. A benefit of this design is a
lower engineering cost per layout, enabling more visualization
types to be produced quicker and with higher quality. Another
benefit is the ability to version the series layouts to be forward
and backward compatible while delivering better-than-linear
scalability with respect to the size of the data set, as well as
minimizing rasterization costs. Each layout in the platform takes
into consideration the target surface dimension and axes to produce
the minimal output without assistance from the client.
[0007] Examples may be implemented as a computer process, a
computing system, or as an article of manufacture such as a
computer program product or computer readable media. The computer
program product may be a computer storage media readable by a
computer system and encoding a computer program of instructions for
executing a computer process.
[0008] The details of one or more aspects are set forth in the
accompanying drawings and description below. Other features and
advantages will be apparent from a reading of the following
detailed description and a review of the associated drawings. It is
to be understood that the following detailed description is
explanatory only and is not restrictive of other aspects of the
present disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The accompanying drawings, which are incorporated in and
constitute a part of this disclosure, illustrate various aspects of
the present disclosure. In the drawings:
[0010] FIG. 1 illustrates an extensible data visualization
framework leveraging an architecture having a unidirectional
pipeline in which information flows;
[0011] FIG. 2 illustrates a pipelined architecture in which data
flows in a single direction;
[0012] FIG. 3 is a flow chart showing general stages involved in a
method for implementing an extendable framework;
[0013] FIG. 4 is an example block diagram illustrating physical
components of a computing device;
[0014] FIGS. 5A and 5B are simplified block diagrams of a mobile
computing device; and
[0015] FIG. 6 is a simplified block diagram of a distributed
computing system.
DETAILED DESCRIPTION
[0016] The following detailed description refers to the
accompanying drawings. Wherever possible, the same reference
numbers are used in the drawings and the following description to
refer to the same or similar elements. While aspects of the
disclosure may be described, modifications, adaptations, and other
implementations are possible. For example, substitutions,
additions, or modifications may be made to the elements illustrated
in the drawings, and the methods described herein may be modified
by substituting, reordering, or adding stages to the disclosed
methods. Accordingly, the following detailed description does not
limit the present disclosure, but instead, the proper scope of the
disclosure is defined by the appended claims. Examples may take the
form of a hardware implementation, or an entirely software
implementation, or an implementation combining software and
hardware aspects. The following detailed description is, therefore,
not to be taken in a limiting sense.
[0017] An architecture for creating new visualizations and
extending existing visualizations within a data visualization
platform architecture is provided. According to an aspect, the
architecture enables building of a data visualization (e.g., a
chart, an infographic, a map, a gauge, etc.) via a one-directional
chain of separate stages, each stage having a simple input
interface and output interface. Aspects of the present disclosure
provide an extensibility architecture that enables quick and simple
extensibility of visualization types via series layouts that are
independent of the rest of the architecture. The extensibility
architecture enables the provision of extension (e.g., new
visualization types) to a charting engine without the large
development costs previously entailed in authoring and integrating
the visualization into the client. The extensibility architecture
allows for the compositing of features to enable clients to add
additional functionality and build out of visualization types via a
multiplicative behavior of chaining capabilities together.
Accordingly, series layouts can be plugged into the data
visualization platform in a generic way.
[0018] The data visualization platform is operable to work with
multiple environments, rendering stacks, and data back ends, and
therefore, is not biased toward a single client. Clients have their
own unique UI and personality requirements that are complimentary
to their environments. For scenarios where clients add object
oriented user interfaces (OOUI) to a visualization, placeholder
objects are supported, which have a fixed size and bound position
which can potentially affect layout.
[0019] The data visualization platform provides a collection of
layouts and the ability to easily add interactive experiences
around them. The centralization of the layouts enables a high
degree of visual fidelity, performance, and compatibility across
disparate clients and environments. Centralization also enables
broader and more rapid innovation through content delivered via
services and other means.
[0020] The architecture of the data visualization platform cleanly
isolates the series layout logic from the rest of the system, such
that each part has a simplistic view of other parts and therefore
cannot become intertwined.
[0021] Series layouts have a simple set of inputs and outputs.
According to several aspects, series layouts take as input a set of
data plus a surface description (e.g., axes, coordinate space,
resolution/dpi, etc.) and produce as output a collection of
annotated geometry. A benefit of this design is a lower engineering
cost per layout, enabling more visualization types to be produced
quicker and with higher quality. Another benefit is the ability to
version the series layouts to be forward and backward compatible
while delivering better-than-linear scalability with respect to the
size of the data set, as well as minimizing rasterization costs.
Each layout in the platform takes into consideration the target
surface dimension and axes to produce the minimal output without
assistance from the client.
[0022] A series layout is capable of describing its basic needs so
that the client and core engine can plug it in appropriately. Basic
needs of a series layout include required data dimensions and
coordinate systems (e.g. x/y/r+Cartesian, x/y+Radial,
x/y+Cartesian), and capability metadata, such as, for example, "I'm
a scientific chart," "I'm appropriate only for small data sets," or
"Goal seek doesn't make sense for me." The capabilities are best
communicated via property tags, thereby simplifying versioning. The
core engine will apply default behaviors in the absence of a
property.
[0023] As described above, the series layouts exposed by the
visualization platform are separated from the core engine and have
their own interfaces. These interfaces are forward and backward
compatible because they are commodities acquired to build dynamic
document content and therefore are expected to have the same level
of compatibility as the documents themselves. To support versioning
of the series layouts, the isolation of the layouts from the core
engine is leveraged; according to aspects, there are only a small
set of internal interfaces that need to be versioned. With only a
small set to worry about, the complexity of versioning is greatly
reduced. Versioning of interfaces may be done using the usual
design patterns: new interfaces inherit from old interfaces, and
interfaces expose a `version` property that may be queried to
ensure backward and forward compatibility between the core engine
and the series layouts. Several versions of a series layout may be
included within the data visualization platform, which are operable
to be chosen by the core engine based on its version or the version
of the client.
[0024] Pluggability is also possible with proper versioning.
Clients running an older version of the data visualization platform
are able to consume newer layouts installed to a central
repository. Knowledge of specific layouts is therefore not
hard-coded into each client, but rather a discovery step at boot
determines which layouts are currently installed that a client can
choose between.
[0025] FIG. 1 illustrates a pipelined architecture 100 in which
data flows in a single direction. As illustrated, the architecture
100 has a unidirectional pipeline 110. As is illustrated in the
unidirectional pipeline 110, information flows through several
stages, such as, for example, a data transform stage 120, a layout
transform stage 130, and a geometry transform stage 140, in which,
various extensibility features, functionalities, and modules can be
inserted in. According to aspects, at each stage in the pipeline
110, there is a well-defined input and output interface, which is
operable to output information according to a normalized format.
The combination of being unidirectional and the normalization of
input/output via interfaces provides extensibility, for example, by
enabling a device providing data visualizations to extend a
visualization's capabilities by inserting one or more transforms of
the appropriate type into the chain (i.e., the pipeline 110).
[0026] Generally, a transform changes information from a first
format into a second format. For example, transforms are operable
to modify data received according to transmitter format to a
receiver format, and vice versa. In another example, a transform is
operable to modify data for it to define geometry (e.g., a chart is
converted into definitional information of lines and Beziers to
graphically represent the chart's data) or to customize a
definition for geometry (e.g., to modify existing geometry to
create customized geometry). In a further example, geometry can be
modified by transforms to alter how it is rendered (e.g., a color
or visual theme is applied, the original definition of lines and
Beziers modified, etc.). According to aspects, transforms modify
information within the pipeline 110 used to create a visualization
160 to affect new and different functionalities in a system
providing data visualizations to create customized visualizations.
Several transforms can be chained together to affect advanced
functionalities and extend the operability of existing
architectures.
[0027] For example, an architecture is extended by inserting data
transforms 125, layout transforms 135, or geometry transforms 145.
As an example, a visualization plotter can be made operable to
receive data from arbitrary clients in arbitrary formats via an
appropriate data transform 125. As another example, a client can
plug in a feature, such as a "sketch effect" feature, where a
visualization 160 can be drawn such that it looks as though it were
hand drawn, wherein a geometry transform 145 takes the output of
the layout transform stage 130 (i.e., the geometry) and then
perturb the vectors and primitives comprising the geometry to look
hand drawn. As a further example, a new chart type can be added by
creating a new series layout 135B (e.g., in layout transform stage
130). Alternatively, an existing series layout 135B can be modified
by inserting a layout transform 135 (e.g., a shared functionality
135A, or series layout 135B) to alter the geometry definitions used
by the existing series layout 135B. Accordingly, a new charting
experience that is unique to the client application is introduced
that works with the rest of the pipeline 110, thereby extending the
pipelined architecture 100.
[0028] Transforms are inserted to extend the pipelined architecture
100 by accepting the output of a first stage (e.g., intercepting
the output of a first stage) and producing a customized output
according to an expected format for a second stage. For example,
when a second stage expects data according to a normalized format
produced by a first stage, a transform that accepts data according
to the normalized format and outputs data according to the
normalized output can be inserted to affect a new feature or
behavior in the second stage, without having to update the second
stage. In another example, a transform is operable to output a
customization according the second stage's expected normalized
format after receiving data organized according to an arbitrary
format. Accordingly, cross-version or cross-platform
interoperability can be realized by extending the pipelined
architecture 100.
[0029] The data transform stage 120 in the pipeline 110, is where
data transforms 125 are optionally applied. According to aspects,
the data transform stage 120 occurs as the client feeds data 150 to
a data visualization platform to create the visualization 160. Data
transforms 125A, 125B are illustrated as optional transforms that
may be implemented to transform raw user data 150 into a normalized
form ready for layout for the visualization 160. For example, data
transforms 125 may include sorting, filtering, or converting the
data 150 into a form that can be used a data visualization
platform. In aspects where the data 150 is already in normalized
form, data transforms 125 are not implemented, or a "pass-through"
transform is used.
[0030] As illustrated in FIG. 1, the layout transform stage 130 is
the next stage in the pipeline 110. According to aspects, the
layout transform stage 130 occurs when rendering, hit testing, or
other functions for which a layout of the visualization 160 is
needed are performed. During the layout transform stage 130,
objects within the visualization 160 are positioned, and their
geometries are built. According to an aspect, layout transforms 135
take normalized data and build a hierarchical scene graph of visual
elements comprised of annotated geometry or text. Layout transforms
135 include shared functionalities 135A (e.g., colorization, trend
lines, data labels, and other functionalities used in common by
data series within a visualization) and series layouts 135B, which
create the annotated geometry for individual data series. In
various examples, the annotated geometry is encoded with
meta-information such that any renderer can have semantic
understanding or context around the vectors. According to aspects,
the outputted annotated geometry is then cached.
[0031] The geometry transform stage 140 in the pipeline 110 is
where geometry transforms 145 are optionally applied. According to
aspects, when a client interrogates a data visualization platform
(e.g., to render the visualization 160, render animation, build
interactivities etc.), the client may optionally insert one or more
geometry transforms 145 to modify how the visualization 160 is
rendered. As illustrated, one or more geometry transforms 145A,
145B may be inserted to modify the styling of the visualization,
convert to pixel space, apply snapping, geometry culling, warp
effects, hand drawn effects, projections, three-dimensional surface
mapping, change the color of certain data points, etc. By inserting
one or more geometry transforms 145, the appearance of a
visualization 160 is altered, which, in some examples, effectively
produces a new visualization type. For example, consider a bubble
chart where a geometry transform 145 is injected that colorizes the
chart based on areas of density, and accordingly transforms the
bubble chart into a heat map visualization.
[0032] Because the data flow is segmented, a vast number of
visualizations can be assembled via pipeline 110. As described
above, the architecture 100 uses series layouts 135B (e.g.,
PieSeriesLayout, ScatterSeriesLayout, ColumnSeriesLayout, etc.)
rather than chart layouts, which are a broader feature. A series
layout 135B, lays out a series of data within the coordinate space
of a visualization 160 to create the geometry that represents the
data 150 in a series-by-series format. For example, a
PieSeriesLayout is operable to output individual wedges
representing an individual data series (i.e., the series-by-series
format), whereas a PieChartLayout would only be operable to output
an entire chart (i.e., all of the data series). The collection of
series layouts 135B is not fixed. Various data visualization
platforms and applications are enabled to determine which
extensions are available, and can have series layouts 135B that are
specific to their client.
[0033] According to an aspect, each series layout 135B is operable
to expose a static set of read-only properties (e.g., annotations)
that enable data visualization applications to intelligently
determine how best to integrate the series layout 135B with the
client's user interface (UI). For example, a data visualization
application can use the read-only properties to query capabilities,
recommended settings, and other contextual needs. For example, the
annotations can inform the data visualization application what
features are supported by the series layout 135B, what the
limitations of the series layout 135B are, etc. For example, a
series layout 135B may expose a property that describes what size
of dataset is appropriate for a given series layout 135B (e.g.,
<10 data points, <1,000 data points, <1,000,000 data
points, etc.). Accordingly, a UI that recommends chart types based
on data would be influenced by such a property. For example, when a
pie chart is designated as not an appropriate chart type for a
large dataset, an example property of the PieSeriesLayout exposes,
via annotations, that a pie chart is an inappropriate visualization
for datasets with greater than, for example, fifty data points.
Accordingly, the data visualization application is enabled to
filter out the PieSeriesLayout from a list of series layouts 135B
presented to a user to pick from if a dataset comprises more than
fifty data points.
[0034] Series layouts 135B are independent of the rest of the
visualization definition. According to an aspect, a series layout
135B is provided a limited view of the input information to only
the information it needs to produce geometry, including data 150
and a coordinate space for the visualization 160 (e.g., a surface
description, origin, directional axes, etc.). Each series layout
135B may be exposed and implemented via one interface. In turn, a
single contextual interface is exposed to the series layout 135B,
which comprises methods that tell the series layout 135B to build
its geometry from the data 150, enumerate the geometry it produces,
and provides methods to query meta-information, fetch data 150, and
map data values to a position within a coordinate space of the
visualization 160. The independence of series layouts 135B from the
rest of the chart behavior and definition (e.g., data transforms
125, shared functionalities 135A, etc.) enables series layouts 135B
to be delivered in a form that is forward and backward compatible
with other versions of the architecture 100. For example, when a
series layout 135B is incapable of interrogating a legend, a trend
line, or other shared objects, the processes that create those
objects can be updated independently of the series layouts 135B and
vice versa. In further aspects, isolation of the series layout 135B
from the shared functionalities 135A enables the addition of other
coordinate spaces in the future that will continue to work with
older series layouts 135B, and thus reduces the cost of versioning
series layouts 135B. Benefits of isolation also include enabling
the architecture 100 to add new features that `just work` with
pre-existing visualization layouts, which reduces the cost of
building or versioning layouts.
[0035] The limited and simplified tasks of series layouts 135B
enables the centralization of shared functionalities 135A (e.g.,
colorization, trend lines, data labels, and other functionalities
used in common by data series within a visualization 160) without
participation from the series layout 135B. Features added to the
shared functionalities 135A can be composited with all series
layouts 135B, and thus produce a vast number of visualization
types.
[0036] A shared interface may used by series layouts 135B for
inputs and settings shared in common, such as, for example,
required data dimensions. According to other aspects, when there
are settings that are specific to a particular series layout 135B
that cannot be modelled generically, a custom interface is exposed
via which custom inputs and settings can be configured. For
example, there may be exceptions or one-off behaviors to the
generic nature of the definitions used within the shared interface
of the series layouts 135B.
[0037] FIG. 2 is an example block diagram of a system 200 operable
to improve the functionality a computer providing data
visualization via a data visualization platform 220. According to
aspects, the system improves the functionality of a computer by
implementing an extendable framework for creating new
visualizations and extending existing visualization types. The data
visualization platform 220 is illustrated as communicating with
data 150, a client 210, and an output device 260. The data
visualization platform 220 is illustrated as comprising a core
engine 230, operable to build a visualization 160 from shared
objects and geometry representative of the data 150, a series
layout module 240, operable to create the geometry representative
of the data 150, and an extension module 250, operable to provide
additional transforms and functionalities to apply as the data 150
is processed.
[0038] The client 210 is operable to provided visualizations of
data to a user and interactivity between the user and the data 150
and the user and the visualization 160. As illustrated the client
210 is operable to write to and read from the data 150, which is
passed to the data visualization platform 220 with a surface
description to produce the geometry for a visualization 160.
According to aspects, the client 210 is further operable to query
the extension module 250 for transforms to modify the data sent to
the data visualization platform 220. In various examples, a data
transform 125 preserves the data 150, but provides the data
visualization with a normalized format of the data 150; only a
transmitted copy of the data 150 is affected. Data transforms 125
are operable to extend the functionality of the client 210 and data
visualization platform 220 and enable simpler versioning of
each.
[0039] As illustrated, the client 210 is operable to receive
geometry from the data visualization platform 220 and pass the
geometry received to an output device 260 such as a monitor,
screen, printer, or other display device to provide the
visualization 160. For example, the client 210 may pass the
geometry to the output device via an appropriate rendering
Application Programming Interface (API). According to additional
aspects, the client 210 is further operable to query the extension
module 250 for transforms to modify the geometry received from the
data visualization platform to extend the functionality of the core
engine 230 and series layout module 240.
[0040] The data visualization platform 220 positions objects within
the visualization and creates their geometries. In various aspects,
a series layout module 240 comprises series layouts 135B that draw
geometry for each series of data within a plot area in a specific
format (e.g., columns for column series, markers for scatter
series, bubbles for bubble series, etc.). According to aspects, the
series layout module 240 is operable to produce annotated geometry
from a limited and immutable view of the data 150 and surface
description. That is, the series layout module 240 takes a set of
data plus a surface description (e.g., visualization type,
visualization size, client resolution/dpi, etc.) as inputs, and
produces a collection of annotated geometry as output. In some
aspects, the annotated geometry is cached in a series object, and
the series layout module 240 is not invoked again unless layout is
required. The core engine 230 is operable process the annotated
geometry and to deliver shared functionalities (e.g., titles, axes,
legends, colors, etc.) of the series and data points without
assistance from the series layout module 240.
[0041] The input to the series layout module 240 comes in the form
of a set of layout interfaces that expose only the information
necessary to produce the annotated geometry (i.e., via the limited
and immutable view). These interfaces are disconnected from the
larger object model and therefore enforce strict isolation of the
series layout module 240 from the rest of the system. Benefits of
isolation include enabling the data visualization platform 220 to
add new features that `just work` with pre-existing visualization
layouts, which reduces the cost of building or versioning
layouts.
[0042] As discussed above, the extension module 250 is operable to
provide additional transforms to apply to the data 150 and the
geometry within the visualization 160. According to further
aspects, the data transforms 125 and geometry transforms 145
discussed above are executed via a unidirectional pipeline 110
during the creation of the visualization 160 or during the
presentation of the visualization 160. In various examples, the
extension module 250 is operable to provide rendering APIs and
communicate with output device 260 to present the visualization
160. According to further examples, extension module 250 is
operable to provide simple data storage and persistence tools for
data 150.
[0043] The extension module 250 may be inserted into an existing
system to enable extensibility. For example, a new version of an
extension module 250 can be added to replace a previous version or
be added as a new module within the system 200. In another example,
the extension module 250 includes several transforms, wherein each
transform is designed to extend communication between different
versions of the data visualization platform 220 and the client 210,
such that the version of each does not impact the presentation of a
visualization 160; appropriate transforms are provided to enable
backwards and forwards compatibility. According an example set of
transforms for enabling extensibility, a client 210 normally
operable to send and receive information for visualizations based
on chart layouts is enabled to communicate with a data
visualization platform 220 operable to receive and send information
based on series layouts via transforms; each component is enabled
to manipulate information natively, and the client 210 is enabled
to leverage the data visualization platform's 220 use of series
layouts.
[0044] Although illustrated in FIG. 2 as part of the data
visualization platform 220, in alternative aspects, the extension
module 250 may be part of the client 210 or a standalone
module.
[0045] FIG. 3 is a flow chart showing general stages involved in a
method 300 for implementing an extendable framework. Method 300
begins at START 301 and proceeds to OPERATION 310 where an
interface is exposed to receive input data 150. According to
aspects, the interface is implemented for a series layout module
240 to building geometry for a visualization 160 defined by the
data 150. An example interface exposes a limited and immutable view
of the input data 150 according to a normalized format so that a
series layout 135B operates only on those data which affect its
output. Several series layouts 135B may be chained together to
affect different portions of the data 150. In this way, new series
layouts 135B are added to the chain to affect an extension of the
data visualization platform 220 and its capabilities. Similarly,
older versions of series layouts 135B may be removed from the chain
and replaced by newer versions, which improves the versioning
process.
[0046] In examples where there are settings specific to a
particular series layout 135B (e.g., not included in the normalized
format), method 300 proceeds to optional OPERATION 320, where a
custom interface is exposed for custom settings to be
configured.
[0047] Method 300 then proceeds to OPERATION 330, where a single
contextual interface is exposed comprising methods to fetch data
and plot data values to a position within the coordinate space of
the visualization 160. As described above, the series layout 135B
may have a limited and isolated view of the input state to comprise
data and coordinate space. According to aspects, the contextual
interface provides a surface description, operable to provide
contextual information related to a client 210 providing a
visualization 160.
[0048] At optional OPERATION 340, one or more data transforms 125
are optionally inserted for extensibility. For example, a data
transform 125 that assembles or buckets/groups data 150 into
categories or series may be inserted. Accordingly, after the data
150 is transformed, the categorized data can be plotted through one
of the series layouts 135B that is appropriate for categorized
data. In another example, a data transform 125 changes the data 150
from a first format to a second format. As will be understood,
changing the format of the data 150 in some aspects does not affect
the underlying values, merely how those values are presented (e.g.,
rearranging an array), and in other aspects, affects the underlying
values to conform to the new format (e.g., the value of data
initially formatted as a DOUBLE type variable is truncated or
rounded when changed to an INTEGER type variable). The data
transforms 125 are operable produce a customization of the data
150, such that the data 150 is received according to a normalized
format.
[0049] At OPERATION 350 a set of annotated geometry is built.
According to aspects, the annotated geometry includes graphical
representations of the data 150, shared objects (axes, titles, data
labels, etc.), and contextual information about these elements of
the geometry. Several layout transforms 135 (e.g., shared
functionalities 135A and series layouts 135B) may be chained
together to create or modify the definitions of the graphical
representations of data 150, the shared objects, and their
annotations.
[0050] From OPERATION 350 the method 300 proceeds to OPERATION 360,
where the annotations of the geometry exposed. According to
aspects, the geometry is exposed via an interface that enables a
client 210 to determine how best to integrate the series layout
135B with the client UI. For example, a data visualization
application can use the annotations to query capabilities,
recommended settings, and other contextual needs for the extensible
framework, such as which geometry transforms 145 are available for
a given geometry. In another example, the exposed annotations
enable the assembly of the graphical representations of series of
the data 150 and the shared objects into a coherent visualization
160. For example, the annotations may indicate portions of the
geometry (e.g., lines, Beziers, figures, etc.) to which a data
label is to be affixed within the visualization 160.
[0051] At OPERATION 370, the annotated geometry is cached.
According to aspects, the annotated geometry is cached in
privatized storage so that it can be enumerated or retrieved upon
request. For example, the annotated geometry can be cached within
the visualization 160 or within series objects, which privatize the
storage of the geometry used to graphically represent a data series
and may be stored in contiguous blocks of memory to improve the
speed of retrieval.
[0052] At optional OPERATION 380, one or more geometry transforms
145 are optionally inserted for extensibility. For example,
geometry transform 145 of a drawing effect can be applied that
transforms the geometry to produce a new type of visualization 160.
For example, a geometry transform 145 applies a drawing effect to
convert a two-dimensional geometry for a column chart into a
three-dimensional geometry. As will be understood, multiple
geometry transforms 145 can be chained together to apply various
combined effects. For example, a first geometry transform 145A may
convert the geometry from two-dimensional to three-dimensional
geometry and a second geometry transform 145B may affect the
positioning of the three-dimensional columns within the coordinate
space of the map. In another example, the geometry transform 145
combines several series objects into a chart object so that a
rendering client 210 that is unable to process series objects can
still render a visualization 160 comprising series objects.
According to aspects, by adding and re-combining geometry
transforms 145, new visualization types are produced to extend the
architecture 100.
[0053] Geometry transforms 145 may leverage the exposed
annotations. For example, annotations may call out area of interest
to suggest styling cues, areas of interactivity, and data bindings.
Accordingly, a geometry transform 145 may be suggested to a user or
automatically implemented to change how an annotated area is
rendered.
[0054] At OPERATION 390 the annotated geometry is rendered to
provide the visualization 160. According to aspects, the annotated
geometry is transmitted to a rendering API and subsequently passed
to an output device 260 to provide the visualization 160. Method
300 ends at OPERATION 399.
[0055] While the present disclosure has been described in the
general context of program modules that execute in conjunction with
an application program that runs on an operating system on a
computer, those skilled in the art will recognize that the present
disclosure may also be implemented in combination with other
program modules. Generally, program modules include routines,
programs, components, data structures, and other types of
structures that perform particular tasks or implement particular
abstract data types.
[0056] The aspects and functionalities described herein may operate
via a multitude of computing systems including, without limitation,
desktop computer systems, wired and wireless computing systems,
mobile computing systems (e.g., mobile telephones, netbooks, tablet
or slate type computers, notebook computers, and laptop computers),
hand-held devices, multiprocessor systems, microprocessor-based or
programmable consumer electronics, minicomputers, and mainframe
computers.
[0057] In addition, the aspects and functionalities described
herein may operate over distributed systems (e.g., cloud-based
computing systems), where application functionality, memory, data
storage and retrieval and various processing functions may be
operated remotely from each other over a distributed computing
network, such as the Internet or an intranet. User interfaces and
information of various types may be displayed via on-board
computing device displays or via remote display units associated
with one or more computing devices. For example, user interfaces
and information of various types may be displayed and interacted
with on a wall surface onto which user interfaces and information
of various types are projected. Interaction with the multitude of
computing systems with which aspects of the disclosure may be
practiced include, keystroke entry, touch screen entry, voice or
other audio entry, gesture entry where an associated computing
device is equipped with detection (e.g., camera) functionality for
capturing and interpreting user gestures for controlling the
functionality of the computing device, and the like.
[0058] FIGS. 4-6 and the associated descriptions provide a
discussion of a variety of operating environments in which examples
of the disclosure may be practiced. However, the devices and
systems illustrated and discussed with respect to FIGS. 4-6 are for
purposes of example and illustration and are not limiting of a vast
number of computing device configurations that may be utilized for
practicing aspects of the disclosure, described herein.
[0059] FIG. 4 is a block diagram illustrating physical components
(i.e., hardware) of a computing device 400 with which examples of
the present disclosure may be practiced. The computing device
components described below may be suitable for the client device
described above. In a basic configuration, the computing device 400
may include at least one processing unit 402 and a system memory
404. Depending on the configuration and type of computing device,
the system memory 404 may comprise, but is not limited to, volatile
storage (e.g., random access memory), non-volatile storage (e.g.,
read-only memory), flash memory, or any combination of such
memories. The system memory 404 may include an operating system 405
and one or more program modules 406 suitable for running software
applications 450, such as client 210. According to an aspect, the
system memory 404 may include the data visualization platform 220.
The operating system 405, for example, may be suitable for
controlling the operation of the computing device 400. Furthermore,
aspects of the disclosure may be practiced in conjunction with a
graphics library, other operating systems, or any other application
program and is not limited to any particular application or system.
This basic configuration is illustrated in FIG. 4 by those
components within a dashed line 408. The computing device 400 may
have additional features or functionality. For example, the
computing device 400 may also include additional data storage
devices (removable and non-removable) such as, for example,
magnetic disks, optical disks, or tape. Such additional storage is
illustrated in FIG. 4 by a removable storage device 409 and a
non-removable storage device 410.
[0060] As stated above, a number of program modules and data files
may be stored in the system memory 404. While executing on the
processing unit 402, the program modules 406 (e.g., client 210,
data visualization platform 220) may perform processes including,
but not limited to, one or more of the stages of the method 300
illustrated in FIG. 3. Other program modules that may be used in
accordance with examples of the present disclosure and may include
applications such as electronic mail and contacts applications,
word processing applications, spreadsheet applications, database
applications, slide presentation applications, drawing or
computer-aided application programs, etc.
[0061] Furthermore, examples of the disclosure may be practiced in
an electrical circuit comprising discrete electronic elements,
packaged or integrated electronic chips containing logic gates, a
circuit utilizing a microprocessor, or on a single chip containing
electronic elements or microprocessors. For example, examples of
the disclosure may be practiced via a system-on-a-chip (SOC) where
each or many of the components illustrated in FIG. 4 may be
integrated onto a single integrated circuit. Such an SOC device may
include one or more processing units, graphics units,
communications units, system virtualization units and various
application functionality all of which are integrated (or "burned")
onto the chip substrate as a single integrated circuit. When
operating via an SOC, the functionality, described herein, may be
operated via application-specific logic integrated with other
components of the computing device 400 on the single integrated
circuit (chip). Examples of the present disclosure may also be
practiced using other technologies capable of performing logical
operations such as, for example, AND, OR, and NOT, including but
not limited to mechanical, optical, fluidic, and quantum
technologies. In addition, aspects of the disclosure may be
practiced within a general purpose computer or in any other
circuits or systems.
[0062] The computing device 400 may also have one or more input
device(s) 412 such as a keyboard, a mouse, a pen, a sound input
device, a touch input device, etc. The output device(s) 414 such as
a display, speakers, a printer, etc. may also be included. The
aforementioned devices are examples and others may be used. The
computing device 400 may include one or more communication
connections 416 allowing communications with other computing
devices 418. Examples of suitable communication connections 416
include, but are not limited to, RF transmitter, receiver, or
transceiver circuitry; universal serial bus (USB), parallel, or
serial ports.
[0063] The term computer readable media as used herein may include
computer storage media. Computer storage media may include volatile
and nonvolatile, removable and non-removable media implemented in
any method or technology for storage of information, such as
computer readable instructions, data structures, or program
modules. The system memory 404, the removable storage device 409,
and the non-removable storage device 410 are all computer storage
media examples (i.e., memory storage.) Computer storage media may
include RAM, ROM, electrically erasable programmable read-only
memory (EEPROM), flash memory or other memory technology, CD-ROM,
digital versatile disks (DVD) or other optical storage, magnetic
cassettes, magnetic tape, magnetic disk storage or other magnetic
storage devices, or any other article of manufacture which can be
used to store information and which can be accessed by the
computing device 400. Any such computer storage media may be part
of the computing device 400. Computer storage media does not
include a carrier wave or other propagated data signal.
[0064] Communication media may be embodied by computer readable
instructions, data structures, program modules, or other data in a
modulated data signal, such as a carrier wave or other transport
mechanism, and includes any information delivery media. The term
"modulated data signal" may describe a signal that has one or more
characteristics set or changed in such a manner as to encode
information in the signal. By way of example, and not limitation,
communication media may include wired media such as a wired network
or direct-wired connection, and wireless media such as acoustic,
radio frequency (RF), infrared, and other wireless media.
[0065] FIGS. 5A and 5B illustrate a mobile computing device 500,
for example, a mobile telephone, a smart phone, a tablet personal
computer, a laptop computer, and the like, with which aspects of
the disclosure may be practiced. With reference to FIG. 5A, an
example of a mobile computing device 500 for implementing the
aspects is illustrated. In a basic configuration, the mobile
computing device 500 is a handheld computer having both input
elements and output elements. The mobile computing device 500
typically includes a display 505 and one or more input buttons 510
that allow the user to enter information into the mobile computing
device 500. The display 505 of the mobile computing device 500 may
also function as an input device (e.g., a touch screen display). If
included, an optional side input element 515 allows further user
input. The side input element 515 may be a rotary switch, a button,
or any other type of manual input element. In alternative examples,
mobile computing device 500 may incorporate more or less input
elements. For example, the display 505 may not be a touch screen in
some examples. In alternative examples, the mobile computing device
500 is a portable phone system, such as a cellular phone. The
mobile computing device 500 may also include an optional keypad
535. Optional keypad 535 may be a physical keypad or a "soft"
keypad generated on the touch screen display. In various aspects,
the output elements include the display 505 for showing a graphical
user interface (GUI), a visual indicator 520 (e.g., a light
emitting diode), or an audio transducer 525 (e.g., a speaker). In
some examples, the mobile computing device 500 incorporates a
vibration transducer for providing the user with tactile feedback.
In yet another example, the mobile computing device 500
incorporates peripheral device ports 540, such as an audio input
(e.g., a microphone jack), an audio output (e.g., a headphone
jack), and a video output (e.g., a HDMI port) for sending signals
to or receiving signals from an external device.
[0066] FIG. 5B is a block diagram illustrating the architecture of
one example of a mobile computing device. That is, the mobile
computing device 500 can incorporate a system (i.e., an
architecture) 502 to implement some examples. In one example, the
system 502 is implemented as a "smart phone" capable of running one
or more applications (e.g., browser, e-mail, calendaring, contact
managers, messaging clients, games, and media clients/players). In
some examples, the system 502 is integrated as a computing device,
such as an integrated personal digital assistant (PDA) and wireless
phone.
[0067] One or more application programs 550, for example, client
210, may be loaded into the memory 562 and run on or in association
with the operating system 564. Examples of the application programs
include phone dialer programs, e-mail programs, personal
information management (PIM) programs, word processing programs,
spreadsheet programs, Internet browser programs, messaging
programs, and so forth. According to an aspect, the data
visualization platform 220 may be loaded into memory 562. The
system 502 also includes a non-volatile storage area 568 within the
memory 562. The non-volatile storage area 568 may be used to store
persistent information that should not be lost if the system 502 is
powered down. The application programs 550 may use and store
information in the non-volatile storage area 568, such as e-mail or
other messages used by an e-mail application, and the like. A
synchronization application (not shown) also resides on the system
502 and is programmed to interact with a corresponding
synchronization application resident on a host computer to keep the
information stored in the non-volatile storage area 568
synchronized with corresponding information stored at the host
computer. As should be appreciated, other applications may be
loaded into the memory 562 and run on the mobile computing device
500.
[0068] The system 502 has a power supply 570, which may be
implemented as one or more batteries. The power supply 570 might
further include an external power source, such as an AC adapter or
a powered docking cradle that supplements or recharges the
batteries.
[0069] The system 502 may also include a radio 572 that performs
the function of transmitting and receiving radio frequency
communications. The radio 572 facilitates wireless connectivity
between the system 502 and the "outside world," via a
communications carrier or service provider. Transmissions to and
from the radio 572 are conducted under control of the operating
system 564. In other words, communications received by the radio
572 may be disseminated to the application programs 550 via the
operating system 564, and vice versa.
[0070] The visual indicator 520 may be used to provide visual
notifications or an audio interface 574 may be used for producing
audible notifications via the audio transducer 525. In the
illustrated example, the visual indicator 520 is a light emitting
diode (LED) and the audio transducer 525 is a speaker. These
devices may be directly coupled to the power supply 570 so that
when activated, they remain on for a duration dictated by the
notification mechanism even though the processor 560 and other
components might shut down for conserving battery power. The LED
may be programmed to remain on indefinitely until the user takes
action to indicate the powered-on status of the device. The audio
interface 574 is used to provide audible signals to and receive
audible signals from the user. For example, in addition to being
coupled to the audio transducer 525, the audio interface 574 may
also be coupled to a microphone to receive audible input, such as
to facilitate a telephone conversation. The system 502 may further
include a video interface 576 that enables an operation of an
on-board camera 530 to record still images, video stream, and the
like.
[0071] A mobile computing device 500 implementing the system 502
may have additional features or functionality. For example, the
mobile computing device 500 may also include additional data
storage devices (removable and non-removable) such as, magnetic
disks, optical disks, or tape. Such additional storage is
illustrated in FIG. 5B by the non-volatile storage area 568.
[0072] Data/information generated or captured by the mobile
computing device 500 and stored via the system 502 may be stored
locally on the mobile computing device 500, as described above, or
the data may be stored on any number of storage media that may be
accessed by the device via the radio 572 or via a wired connection
between the mobile computing device 500 and a separate computing
device associated with the mobile computing device 500, for
example, a server computer in a distributed computing network, such
as the Internet. As should be appreciated such data/information may
be accessed via the mobile computing device 500 via the radio 572
or via a distributed computing network. Similarly, such
data/information may be readily transferred between computing
devices for storage and use according to well-known
data/information transfer and storage means, including electronic
mail and collaborative data/information sharing systems.
[0073] FIG. 6 illustrates one example of the architecture of a
system for providing data visualization as described above. Content
developed, interacted with, or edited in association with the
client 210 or data visualization platform 220 may be stored in
different communication channels or other storage types. For
example, various documents may be stored using a directory service
622, a web portal 624, a mailbox service 626, an instant messaging
store 628, or a social networking site 630. The client 210 or data
visualization platform 220 may use any of these types of systems or
the like for providing data visualization, as described herein. A
server 615 may provide the client 210 or data visualization
platform 220 to clients 605A-C. As one example, the server 615 may
be a web server providing the client 210 or data visualization
platform 220 over the web. The server 615 may provide the client
210 or data visualization platform 220 over the web to clients 605
through a network 610. By way of example, the client computing
device may be implemented and embodied in a personal computer 605A,
a tablet computing device 605B or a mobile computing device 605C
(e.g., a smart phone), or other computing device. Any of these
examples of the client computing device may obtain content from the
store 616.
[0074] Aspects of the present disclosure, for example, are
described above with reference to block diagrams or operational
illustrations of methods, systems, and computer program products
according to aspects of the disclosure. The functions/acts noted in
the blocks may occur out of the order as shown in any flowchart.
For example, two blocks shown in succession may in fact be executed
substantially concurrently or the blocks may sometimes be executed
in the reverse order, depending upon the functionality/acts
involved.
[0075] The description and illustration of one or more examples
provided in this application are not intended to limit or restrict
the scope of the present disclosure in any way. The aspects,
examples, and details provided in this application are considered
sufficient to convey possession and enable others to make and use
the best mode of present disclosure. The present disclosure should
not be construed as being limited to any aspect, example, or detail
provided in this application. Regardless of whether shown and
described in combination or separately, the various features (both
structural and methodological) are intended to be selectively
included or omitted to produce an example with a particular set of
features. Having been provided with the description and
illustration of the present application, one skilled in the art may
envision variations, modifications, and alternate examples falling
within the spirit of the broader aspects of the general inventive
concept embodied in this application that do not depart from the
broader scope of the present disclosure.
* * * * *