Graphics by Greg

Having put together a couple websites (Redstone Studios and Althea) that integrate with Paypal for providing checkout capabilities, I was very interested to look at Google Checkout when it was released this past week. My experience with the Paypal integration was not so good - while I eventually got it to work, it took a ton of experimentation, searching for documentation, and guessing why things weren't working (i.e. no meaningful error messages). Luckily, Google Checkout doesn't seem to suffer from these problems - I had it up and running in no time and it seems very solid for what it does. What does it do? Well, it's basically a checkout system where you can pass in a cart, users can pay by credit card, and then the money gets deposited in your bank account. Google charges 2% of the transaction amount plus twenty cents. The two percent covers the percent Google has to pay the credit card companies, and the twenty cents is some extra cash for Google. If you use Google Adwords, you get a free credit on Google Checkout - for every 1 dollar spent on Adwords you get 10 dollars of sales with no costs.

Google provides sample PHP code for getting the integration going, but unfortunately the code is PHP4 only, and it is ugly ugly ugly code. I decided to put together a simple class that allows simple integration with Google Checkout. The class is PHP5 only because it uses PHP5's DOM extension.

To use Google Checkout you need to create a Google Checkout account. From there, you can get your merchant id and merchant key, both of which are needed to communicate with Google Checkout. The Google Checkout API works by POSTING XML over HTTP. While Google's API is very flexible, I've chosen to implement a subset that I think would be useful for many people. Also, I've only implemented this class to support the creation of the cart and submission to Google, I haven't included any functionality for greater integration. This greater integration would involve creating web services that Google could call to update the website on changes to the order status, shipping, etc. The way I've set this up, all of that is skipped, and store owner would receive orders via email or Google's Checkout interface.

Limitations:

• No support for cart expiration
• No support for merchant calculations for tax/shipping/gift certificates as these require HTTPS and I don't have it and don't care to use it
• No support for requesting the buyers phone number because I didn't notice that field until just now!
• No support for shipping restrictions - i.e. shipping option 1 is only available in these zip codes/states/etc
• No support for complicated tax rules. Tax can be setup on a state by state basis. One alternative tax rule 'taxfree' is setup to allow certain items to be tax free. No support for other alternative tax rules.
• Currently doesn't support customization of the form and checkout image

In order to work around some of these limitations, I've provided a method called setDefaultXML which allows the developer to specify a default XML file to be used. The class will then fill in the items, do the encryption, and generate the form and checkout image. This allows much greater flexibility and support for all of Google's options, when needed.

Here's a simple example of how I might use it:

Now, for what's going on:

• Line 1 includes the class
• Lines 3 and 4 setup variables for the merchant id and merchant key
• Line 6 instantiates the class, passing in the merchant id and key
• Line 7 sets the class to use the Google Checkout Sandbox - this is a testing sandbox where you can setup fake accounts to use while creating your site. Paypal offerers a much richer sandbox functionality.
• Lines 8-11 add new line items to the cart, setting there name, description, price, quantity, notes, and special tax rules
• Lines 12 and 13 setup the URLs the user should be sent to if the choose to edit the cart or continue shopping
• Lines 14-16 setup various shipping options including their prices
• Lines 17 and 18 setup taxes for the users in specific states. Google Checkout supports much richer rules around taxation, but I kept it simple on a state-by-state level.
• Line 20 outputs the HTML form and checkout image that will send the cart to Google Checkout and bring the user to the Google Checkout page
• Line 21 shows the XML cart, for debugging purposes

View this example running on my site
View the API of Gregphoto_Service_Google_Checkout
Download the class and API docs
View Google's Develper Guide for Google Checkout

I love music, and I love the tools that make it easier and more convenient for me to listen to music. One of the advances that has made music so much more accessible over the past few years has been the advent of mp3s, digital music, and digital music players. I bought a first generation iPod the day they were released for Windows based computers, I’ve since upgraded to a non-Apple mp3 player, and I’ve got a mp3 CD player in my car. While some new technologies can be a burden on their users, digital music technology lets me listen to more music with more choice, and keeps me from listening to the same album over and over in my car due to my own laziness. I’m not a super audiophile, and I tend not to notice the slight degradation of music quality I get from digital music, and what I do notice in inferior sound quality is greatly outweighed by the convenience of it’s portability, searchability, and ease of use. Despite the great conveniences of digital music, there are a couple things that really bother me – they bother more than they should because I think they’re things that wouldn’t be all that hard to fix.

Before I get going on my rant, I should note that my only credentials on this topic are being both a music enthusiast and a computer enthusiast – I don’t know all the details about every digital music file format or player, I just know what I’ve seen in popular applications such as mp3 players, iTunes, and other digital music players…

And then there was silence…

At least there was silence for a couple of seconds. The biggest gripe I have with digital music is that there seems to be no reliable way to control the ‘gap’ between tracks. For many albums or types of music, I don’t particularly care about the gap. For other music, the gap can really take away from the enjoyment. This is most evident is albums where songs blend together with no gaps – this includes albums from The Beatles’ ‘Abbey Road’ to The Red Hot Chili Pepper’s ‘ Blood Sugar Sex Magik’, just about all classical music, and live music recordings. Some applications and mp3 players have settings to let the user control the time between tracks or even the cross-fade between tracks. This really isn’t enough, as the time between tracks changes from track to track. Sometimes I need no space between tracks, sometimes I need the standard 2 seconds, and sometimes I need more. The key is that this is all dependent on the album and how it was meant to be heard. Another important element is that the gap between tracks should be context-sensitive to the album. If a song typically has no gap between it and the next song, should it also have no gap when it is played on a playlist outside of the album? The problem is that there really is no concept of the ‘album’ in popular digital music, but we’ll get to that later.

From Abbey Road to the White Album

My other problem with digital music is that in mp3 players and digital music players, when I look at a list of albums from a band, I see them alphabetically. An alphabetical list of albums makes it easy to find one you’re looking for, but to me, is not the best way to look at albums. I would rather look at albums chronologically – so that when I’m looking at a list of Led Zeppelin albums I see ‘Led Zeppelin I’ before I see ‘Houses of the Holy’, or The Beatles’ ‘The White Album’ before ‘Abbey Road’. This is an unusual problem because our digital music has metadata, and one of those fields is for the year of the music. So why can’t that be used to show a chronological list of albums? I suppose it could, but it would present problems. Let’s say an album has 10 tracks – in the perfect metadata world, all of these will have the same year, so the application or music player could just look at one of the songs and pick the year. In a more complicated world, the songs could have different years marked, or incomplete data – what should the player do in this case? What if we’re looking at a compilation of songs all recorded in different years – should the file’s metadata list the year the song was recorded and released or the year the compilation was released. I would argue that attached to the song should be the year in which it was recorded, while another entity – ‘the album’ – should keep track of it’s own release date.

The Album – The Metadata that Went Missing

So the common thread here is the album. Right now, popular music systems have no real concept of the album – they infer the existence of an album based on metadata attached to each song – an artist name, an album, year, genre, track number, and whole bunch of other fields. As mentioned earlier, this becomes increasingly complex when songs start belonging to multiple albums or playlists, because the songs can only have one value for each of the aforementioned metadata fields. What we really need is a wrapper around all the files in an album that can store some of this information.

Let’s think about this from the technical perspective. If I were to develop a database-based application to store information about my music collection, how would I do it? I would need to create tables for songs, albums, and song/album mappings. Basically, one table would have all the basic information about each song, another table would have the basic information about each album (artist, release date, record company, producer, credits, etc), and another would connect the two other tables – mapping which songs are on which albums and the order in which they are on those albums. If I wanted to go an extra step further, I could add another table to track information about the artist, but that isn’t really essential for most purposes.

Obviously the files that make up the digital music of today are not databases, so the table concept doesn’t directly translate to what can be done in the real world. So if this had to be done in a file-based manner, we could add one small file that has album information and the album/track mapping – similar to a playlist file but with more information. The album’s year would solve my second issue of chronological sorting of albums, and the tracklist within the album file could have information about the space between tracks, solving the gap between tracks issue.

Overall I think this could add to the experience of digital music and make it easier for people to switch over from the physical realm of music to the digital realm. I still love my liner notes and opening up a new album, so I don’t think I’ll go all digital anytime soon, but making the experience of listing to music closer to what I get with a CD, record, or tape player, will certainly make it easier for me to get rid of that CD player in my living room…