the home of peter chng unitstep.net

The Google Chart API is a great way to dynamically create chart and graph images for any non-static data you might want to display to your visitors, such as stats for a runner’s training log.

Although you can use your own server-side solution for generating charts, using PHP’s GD Image Processing Library or even a fancy chart library like pChart, this can increase the drain on your server’s resources. Client-side solutions that utilize the canvas element and jQuery or Flash can be very nice and easy to use, but may slow down the browser if there are a lot of charts.

Google Charts offers a nice trade-off; by using their service you offload the processing and bandwidth and get back a simple PNG image, but you must learn to use the API. Additionally, there’s also the risk that the service may throttle you, even if there’s no current usage limit.

Problems specifying Axis Ranges – Data points are not changed!

The API for Google Charts essentially consists of passing different query string parameters and their values and getting back a PNG-format image. As a result of this, passing in parameters is a bit quirky, and information in the API guide is a bit sketchy in this respect.

Continued

On Thursday, Google rolled out an update to its personalized home page service, iGoogle. Among other UI updates, the major new features were increased flexibility in what “gadgets”, the personalized “chunks” that make up an iGoogle start page, can do. This, in turn, allows developers much more freedom with what they can provide to the user through an iGoogle gadget.

Previously, gadgets could only occupy a small box that took up only a third of the screen. While this was okay for reading headlines or perhaps glancing at stock prices, it limited the usefulness of gadgets and the information that could be provided. For more detail, users would often have to click a link in the gadget that would take them away from iGoogle. While this is perhaps the proper use of a “start page”, Google may now see things differently.

Continued

I’ve just starting playing around with the Google Static Maps API as a complement to the regular Google Maps API, which as you probably know, is for JavaScript. The Static Maps API, on the other hand, provides a way to display static map images. This is useful in situations where you just need a non-interactive map and don’t want the overhead of an Ajax/JavaScript-based one.

However, I ran into some minor problems related to the API key usage with the Static Maps. Basically, an API key is tied to a certain domain name so that Google can keep track of your site’s usage. This means that the API key is tied to the domain name of the web site where you’re using the Google Maps API.

Continued