There are multiple approaches with which a developer can work with the Visualization API, so it is helpful to give an architectural overview of various workflows. This chapter describes the common high-level architecture that underlies the most common methods of working with the Visualization API. In this chapter, we will also discuss the integration of various aspects of Visualization (Chart), Maps, and Fusion Tables. These three APIs often work together to allow developers varying in expertise to build complex, dynamic visualizations with relatively little effort. The final section of this chapter is dedicated to outlining the types of visualizations.
In this chapter we will cover the following:
- API architecture overview
- Interaction with other APIs
- Visualization types
At its core, the Visualization API acts as a bridge between a data source that contains data and an HTML page displaying the data. Regardless of platform, the Visualization API follows the same architecture as other Google API products. Methods to use for Google APIs consequently also follow the same general structure as APIs from other application providers such as Flickr or Facebook. For most APIs, including the Google APIs, the JavaScript namespace structure is as follows:
application.category.function(variables)
For example, to create a new pie chart with the Google Visualization API, the corresponding code would be as follows:
new google.visualization.PieChart(document.getElementById('visualization'));For non-code based platforms, such as Spreadsheets and Fusion Tables, the user interface that encapsulates the Visualization API is designed to enhance the strengths of a particular tool set for a wide spectrum of users. For example, Fusion Tables is primarily focused on map visualization by inclusion of geocoding capabilities, as well as specific format standards to simplify map overlay deployment. Similarly, Spreadsheets primarily functions as a spreadsheet application, but is capable of some chart visualizations through an integrated graphic user interface. The integration of the Visualization API in these cases is primarily for the enhancement of the capabilities of the parent application. On the other hand, developing applications directly with the Visualization API affords the developer a higher level of freedom in design than either Spreadsheets or Fusion Tables.
Spreadsheets integrates much of the Visualization API into an easy-to-use graphic user interface within the Spreadsheets application itself. Data manipulation and data input can be done programmatically through the Spreadsheets Forms feature, Apps Script, or even the Spreadsheet API. Each method is likely to affect chart renderings, as they offer opportunities to collect, move, format, and delete data in methodical, repeatable ways.
Note
You can find more information about Google Spreadsheets Documentation at http://www.google.com/google-d-s/spreadsheets/.
Chart rendering is one of the many uses of Google's scripting platform, Apps Script. Initially it was included only within Google Spreadsheets and Documents. Apps Script has since been elevated to a standalone filetype in Google Drive. The purpose of Apps Script is to allow a user to programmatically manipulate data, or even the Google document interface itself in Google Drive. Apps Script projects created in Google Drive documents can also be launched as applications through the Apps Script development platform. Introducing the creation of web forms, filter controls, and other web interfaces outside the Google Drive environment enhances the interactive, data-driven chart potential.
Note
You can find more information about Google Apps Script Documentation at https://developers.google.com/apps-script/.
Another method available to input data into Spreadsheets is through the Forms functionality. Launch the Forms configuration tool by selecting Insert | Form from the Spreadsheet menu tabs. The resulting survey-style form can then be embedded into a website iFrame, or can be a standalone web page hosted by Google. Forms are not intended to facilitate two-way interaction with data, but are only a method of inputting data into spreadsheets. Note that when a form is created to bring data into a spreadsheet, the format of the spreadsheet is automatically configured to collect the timestamp of each entry submission in the first column. Form question responses are collected in the order they are asked and stored in subsequent columns. When the form is deleted, the first column returns to its default state and the Form tab disappears.
Note
You can find more information about Google Forms Documentation at http://www.google.com/google-d-s/forms/.
The combined result of Spreadsheets and its compatible technologies is a simplified yet capable web platform. A developer may choose to interact with visualization tools through the Spreadsheets GUI, Apps Script, or JavaScript (most often inside the <script> tags). Multiple methods of data manipulation can also be programmatically invoked. These methods include using Forms, Apps Script, Visualization API, or the Spreadsheets API itself. The charts created in Spreadsheets can be displayed as embedded in an iFrame, standalone App Engine web application, or custom application.
Similar to Spreadsheets, Fusion Tables creates an easy-to-use environment in which visualizations can be created without writing code. However, Fusion Tables is primarily focused on visualization of map data and integrates the map and chart API functionalities with a table optimized for map data. Maps rendered in Fusion Tables can be displayed in an embedded iFrame, standalone HTML link, or as part of a larger custom application.
Note
You can find more information about Google Fusion Tables Documentation at http://www.google.com/fusiontables.
Writing applications wrapped in HTML and directly manipulating the Visualization API is the most versatile method of chart creation. Consequently, this method can often be the most labor intensive and will require some HTML and JavaScript programming experience. The following diagram depicts the HTML page residing in Google App Engine. While this is a possible hosting location, it is not a requirement to publish code that references the Google APIs in Google App Engine. A key difference between the Spreadsheets or Fusion Tables approach and scripting custom code is that the data resides outside of the development platform. Both Spreadsheets and Fusion Tables encapsulate their data within the development platform, where a custom application using the Visualization API must interact with the data through various API methods. The Visualization API itself contains a simple set of programmatic data manipulation and retrieval calls using google.visualization.dataclass of functions. Other APIs may also be leveraged to manage data if the hosting application also has an API. For example, Spreadsheets API or Fusion Tables API can be used along side the Visualization API in the same application. One method of using Spreadsheets and Fusion Tables data programmatically within the Visualization API framework is to use the SQL-like language provided in the Visualization API. This SQL-like language is named Query and functions from its class can be called by the method google.visualization.query.
Note
You can find more information about Google Chart Tools API Documentation at https://developers.google.com/chart/.
The API use is not limited to just one section of the HTML document. For the purposes of the instructions in this book, Chart API visualizations will be included within the <script> tags of HTML code. As expected in HTML, the <script> tags are included inside the <head> tags. To place the code on an HTML page, a <div> tag names the ID in the <body> tag, which the visualization uses to create the chart on the page. General HTML styles for the browser window and visualization frame can be provided in the <body> tag definition by following normal HTML practices. The generalized structure of an application using the visualization API, including its HTML framework, is as follows:
<html>
<head>
<script>
API code goes here, including any libraries to be loaded.
</script>
</head>
<body>
<div id="chart_name_goes_here"</div>
</body>
</html>Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
In the code inside the <script> tags, there are three primary methods in which the Visualization API can be invoked to draw charts. The most versatile of the three is chart.draw(). However, a drawback of using chart.draw() is that it requires explicit loading of the directories required for the particular visualization. Alternatively, ChartWrapper is an easier method to use, but trades ease of use for less flexibility when working with event handling. With almost the same functionality, Draw.Chart() is an even more compact version of ChartWrapper, and requires less code. However, Draw.Chart() further trades functionality for ease of use as Draw.Chart() is not capable of handling events.
Tip
Drawing techniques: chart.draw() versus ChartWrapper versus Draw.Chart()
You can find information about this at https://developers.google.com/chart/interactive/docs/drawing_charts.
The following table compares the three drawing techniques:
|
Feature | |||
|---|---|---|---|
|
Explicit control: Loading visualization libraries required |
 |
 |
|
|
Explicit control: Callback function needed for event handling and queries |
|
|
|
|
Functionality: Handles events |
|
 |
|
|
Automated: Load visualization libraries |
|
|
|
|
Automated: Event handling and queries |
|
|
|
In general, the ChartWrapper method will suffice for most projects. Draw.Chart() can be used on projects that do not require event handling. A developer may choose to use the chart.draw() method, and will generally tend to do so if verbose event handling is required.