I don't think the graphs look cheap on their own, but they do have a "look", which if overused could begin to look cheap - like the standard blogspot templates or an excel graph as examles. I don't think that is the case yet, nor may it ever be (you have to be a programmer to use these).

Here is another positive: the graphs are fast. Really Really fast. You get the multiple-hosts pipelining trick for free. You get the fact that Google hosts these graph servers local to wherever your customer is. Google buys better network connections than you can likely afford. Also, some engineer(s) at Google's job is to make sure that the rendering itself (server-side) is wicked fast which is more than you can say about your company or graph library you are using.

Speed is valuable and looks very professional.

They're not so bad and they're easy.

When working on charts for a site and you're looking for wicked ROI, why not toss in these until you have a little extra time to change them to something you prefer more?

I would say if you are showing the charts in your web-apps that means lot to the end user e.g. analytics data. It is one of the important aspect of application and that decides whether people like it or not. In such case it would be good to have in-house expertize on charts/some library e.g. JFreeChart for java or Flot(JQuery) JavaScript << good for minimal charting capability>>. That helps to keep control and plan ahead. I mean same applies for google charts too. But in that case you are loosing out control over some part of your application as you are delegating this important task to third party(google). If it is part of product/portal; I think lot of clients wont approve such decision.They will prefere custom-build/coded part for that in the application.

"Would it be seen as taking an unnecessary shortcut and a lack of technical skills in setting up a proper charting/graphing package?"

It would be seen as making the best use of available resources. I see two key benefits to using Google APIs

1.) It will establish a sense of familiarity with non-technical users. They see Google, they feel a bit more secure in the application's ability to perform and deliver

2.) It will show developers that you recognize effective solutions based on the depth of development, and how well you implement the system.

I think a pro company could very well make use of these technologies, even if they have the competence to create the solution themselves. If the idea is to deliver results in the highest manner possible, and they feel comfortable using Google APIs, go for it.

I don't think lacking technical prowess in setting a proper charting package to be a significant reason. That would be like saying you are cheap for using a web framework instead of writing your own would be cheap as well. Just this case, it's a "framework" (it's techinically and API, I know) for displaying charts.

They do look cheap though. You could maybe count on the fact that they would improve the chart's presentation without changing the API, but that could never happen.

If your app is simple and doesn't value presentation too much, you can go ahead and save the extra hours you'd spend on a charting package on some other features that people want.

They are too simple for me to use in my apps, though.

To me, it would look cheap. I would not use it as part of my offering, because a) it relies on Google's servers which have no guarantee of uptime and b) decent charting packages are already available for a reasonable price.

On the other hand, I doubt that most users would care as long as it works.

Google's servers are far more likely to be up than yours, that's just not a valid reason. Those charts are nice, there's nothing cheap looking about them, the real issue is load, will your load exceed what Google allows per day, if so, do your own charts, if not, nothing wrong with using Google.

You're right. I should rephrase. I meant uptime more in the control sense of the word. If Goog were to decide to stop allowing this API to run or in some way change their terms of use, there would be a problem. I guess it's the control freak in me.

Well, then you'd have to do something else.

isn't it limited to 10 000 requests a day? Assuming you build something that becomes popular, than that limit will be soon reached. What you going to do when that happens? Re-write it with something of your own?

If you are writing a small-ish webapp, then fine, but if you are building something that is going to be popular (or at least you are hoping it will), then using that API doesn't seem a good idea.

Java, Php, Python all have pretty decent chart generator apis that can do the same, or even more, so I really don't see the point of using the google api.

Basically, there is no 10,000 request limit. but, even if there was one, it would still be very easy to cache 10,000 unique graphs on the server, and then serve them up without making new requests to the chart API. Here's an excerpt from its Terms of use:

4.5 You acknowledge and agree that while Google may not currently have set a fixed upper limit on the number of transmissions you may send or receive through the Services or on the amount of storage space used for the provision of any Services, such fixed upper limits may be set by Google at any time, at Google's discretion.

Right on the front page:

Usage Policy

Use of the Google Chart API is subject to a query limit of 50,000 queries per user per day. If you go over this 24-hour limit, the Chart API may stop working for you temporarily. If you continue to exceed this limit, your access to the Chart API may be blocked.

the request to the chart's url will be made by the client browser, which is a unique ip for practically every visitor. so, maybe that's 50,000 charts per day per visitor? unfortunately they don't really clarify what they mean, as they could be tracking the request referrer.

According to a Google Group forum post by a Google Employee, the 50,000 limit refers to the webpage, not the person who visits the site: http://groups.google.com/group/google-chart-api/msg/b53c39a5...?