Daniel O'Connor

1) It doesn't work well with Opera. Until I upgraded, I couldn't even type in the login box. It's still buggy.
2) The annoying sound the inbuilt chat client makes for new messages always interrupts my music.
3) It's bloated in firefox. I really notice it on my slower computer
4) It's so much of a walled garden. Why can't I import photos from flickr, or export them?
5) Photo upload in general sucks. The java applet is fail. The fix? Yahoo already made it for you.
6) My events: I finally worked out where the export-to-google-calendar link was, and they are published without a timezone. So now, I'm busy going to places at 3am.
7) You call it an API, but it's not an API to access data and remix it.
8) Where's my xmpp compatible chat, eh?

Basically, it irritates me that the developers they have working for them don't care about these things in the slightest.

Worse, it's sucking up and doing poorly all of the functionality I had in external services. My 2nd tier friends seem to use facebook chat over MSN or Google Talk.

On the other hand, LuckyCal almost promises to be useful.

Here are my two best tips around using Image_Graph for projects. They aren't necessarily right, but have worked fantastically for me.

Use it like Google Chart API (on demand)

Build a simple page which takes a number of arguments via GET variables, and serves up an image. You can then use simple commands to render whatever you like.

# Rendering code:
require_once 'Net/URL.php';
function make_graph_url($data) {

 $url = new Net_URL('graph.php');
 $url->gt;querystring['data'] = $data;
 $url->gt;querystring['type'] = 'pie';
 return $url->gt;getURL(); // "graph.php?type=pie&data[Cats]=1&data[Fish]=2";
}

# HTML / Presentation bit
<img src="%3C?php%20print%20make_graph_url%28$data%29;%20?%3E" alt="Graph of Cats and Fish" />

#Graph.php
require_once 'Image/Graph.php';

$graph = new Image_Graph();
// read in $_GET and construct your graph

$graph->gt;done();

Its worth thinking about maintaining a pretty similar approach to google's API, so that you can swap one for the other almost trivially.

Pre-rendering

Say you have a set of reports you must run. The amount of data is huge, so you really don't want to try and do things on the fly. You have to update the data periodically - ie, once a week or month.

Steps here:
1. Denormalize in the database - precalculate answers and render them into tables. It will save you loads of time.
2. When you have the data you need, pre-render the graphs and save them to disk. Do it with an easy naming scheme.

Now when someone hits your pages to look at information, you've got everything already there - its a matter of wiring it together.


These two things are pretty obvious and self explanatory, but worth keeping in mind. The last thing you want to do is build a page which assembles data, then realize Image_Graph renders in a different stream (ie, not inline), and resort to copy and paste coding.