From the ideas we've discussed here my wishlist for future API
development would be as follows (in order of priority):

1) Adding additional attributes to the project that include different
sized images

I've worked at a couple of book publishers in the past and they
provide distributors/retailers with data about their products using
the ONIX international standard (an XML feed). That standard includes
links to a selection of cover images in very specific sizes and
formats, if you go to http://assets.cambridge.org/ then search for
9780521195331 you'll see a sample of these cover images for a
Cambridge University Press title. There's thumbnails in GIF and JPG,
medium size 'Website covers' in GIF and JPG, and a large size JPG, and
these are the images that will get included in the XML feed and used
by booksellers such as Barnes & Noble
http://search.barnesandnoble.com/Networks-Crowds-and-Markets/David-Ea....

Now I'm not saying you need to copy exactly what book publishers do,
but it's a useful example and does underline the importance of having
a consistent image size when that image is being used by a large
number of third-parties. Given you've got images being submitted by
project leaders in different orientations (portrait/landscape) then
you won't be in a position to fix both the height and width of the
images you're providing without squashing them, but you could fix one
or the other. I don't have a lot of web design experience but a
designer could probably tell you if it's more desirable to fix the
height or width of an image when designing a page to display images of
varying orientations.

So my first priority would be for you to add an additional attribute
to the project for a medium sized image in addition to the thumbnail
(perhaps fixing the height or width at around 250-350 pixels?).

2) Adding additional attributes to the progress reports that include
links for attachments

The progress reports from projects are one of the most attractive
features about GlobalGiving's model, they offer a real sense of
transparency to donators so it could be frustrating for a donator to
see 'Attached is the Spring update...' or 'To read the rest of our
annual newsletter...' and not be able to see the relevant attachment
on my site. There seem to be two common types of attachments to
progress reports as you say, images and PDFs. The PDFs would be the
priority for me, and I could live without the images if that made this
development available sooner.

If these attributes weren't added to the API it would require me to
review every project prior to making it available from my own site, as
I would try to omit an projects uploading progress reports as
attachments. But this is far from ideal, as a project can start
uploading progress reports as attachments at any time making
administration of this a bit of a pain.

3) Adding additional attributes to the projects that include
additional photos

The photos of these projects are often really good and help engage
donators, so I would like to see them made available via the API, but
only if they were provided in different and consistent sizes as
discussed in point 1 above, and getting the default image available in
different and consistent sizes would be my priority, so I would list
this as a 'nice to have' rather than a 'must have' like points 1 & 2
above.

4) Adding additional attributes to the projects that include links for
attachments

This is similar to number 2, but I'm referring to the attachments
uploaded against the general project information rather than the
progress reports. This is a much lower priority for me, as I feel the
generic data that each project must provide (e.g. Summary, What is the
issue, problem, or challenge? How will this project solve this
problem?) is sufficiently detailed enough for a donator to assess a
project by. So displaying attachments uploaded against a project is
not essential, and again I would list this as a 'nice to have' rather
than a 'must have' like points 1 & 2 above.

If the ideas seem viable would it be possible to get a timeline on
points 1 or 2? The bulk of my site's development will be happening in
early-mid September with deployment in October so I'll need to get my
developers looking at interim workarounds to address points 1 or 2 if
they won't be in place by early September.

Thanks and best,

Joe