One issue I experienced whilst developing the GPS functionality was how to reliably test it. The problem was how to test the GPS without borrowing our designer’s iPhone every five minutes. I knew Firefox supported the new w3c standard for geolocation. However, in my Firefox at least, Google appeared to have stopped serving the location details, which meant for all intents and purposes, the geolocation was broken.

Luckily, Firefox allows you to change the location service provider via the about:config geo.wifi.uri settings. This means that as long as the address you enter returns a JSON string, your location will be valid. A quick Google returns a number of addresses that will do this for you. One which is particularly interesting: https://www.dephormation.org.uk/geolocation/iamthepresident.php

For the purposes of testing I threw together a quick mash up that will take any location name/postcode and return the JSON string for Firefox to respond to geolocation requests.

This got me thinking about the various location-based web games and some searching online turned up a number of sites which had a mobile version that utilises the w3c standard. Cue Gowalla and Foursquare. I was able to fool them in to thinking I was at the White House. Give it ago.

Obviously that’s one use for it. However, the real use I had was for testing our new Google Maps driving directions GPS integration.

The launch of a new platform poses an obvious question for an agency like Atelier – when is the right time to jump? By that I mean, when should we start  dedicating resources and building experiences for the new devices. At Atelier we always assess whether it’s something we want to be there at the start of, or if we’d rather invest later after a solid user base has been established. There are valid reasons and risks involved with both. Should we invest early with the risk that the platform fizzles out with little market share (hello Palm Pre)? Or do we wait until there’s already a huge following (hello iPhone)?

Either way, it’s an interesting time for mobile development. There are already two very big players in the market who are growing by the day – Android is positively thriving and we needn’t mention the iPhone. But I for one hope that there is room for a third option in the form of Windows Phone 7. It’s a good time for Microsoft and they have the freedom to reinvent their mobile platform after they dropped the ball with Windows Mobile some 3 years ago.

Microsoft has a trump card when it comes to developers too. The tools you use for writing for the platform, such as C#, XNA & Silverlight, are ones we’re already used to. I’m willing to bet that if you gave a Windows developer the freedom to choose between Android, iPhone or Windows Phone 7 they would choose the platform they have some familiarity with. Coupled with this is the fact that Microsoft has made it clear that they’re 100% behind it.

We’re looking at ways to bring some of our experiences to the new Windows Phone 7 platform. For example, we’re excited about some of the possibilities with location-based services. Microsoft has demonstrated that there’s a market for these type of games and applications, having released ‘Kingdoms’, a tie-in with the Xbox 360 game, ‘Fable 3′. The mobile version sees you claiming virtual landmarks in exchange for currency in the main ‘Fable 3′ game. Whilst this isn’t available on the Windows Phone 7 just yet, it demonstrates just some of the possibilities.

At Atelier Studios we’re no strangers to mobile development, having developed a number of mobile sites and iPhone applications, and we’re excited about the possibilities of developing for the new Windows Phone 7 platform too. We always like to hear about new ideas, whether that be for mobiles or the web – if you’ve got one, please do get in touch!

Now, unfortunately Google seem to be spending 99.99999999% of their time in improving and enhancing current and new products and the remaining 0.00000001% providing minimum support on anything they currently have running. Don’t get me wrong, what they have up and running is awesome, but not so good when something goes wrong or you need to do something slightly differently from the masses.

The Scenario

So let me tell you the scenario – I have a client using PayPal Buy Now buttons (I wouldn’t normally even consider this route, but it’s a short term fix while their proper e-Commerce system is being developed). They have amazing products and a result in a period of 8 days got over 600 worldwide orders – amazing considering no promotional work had been done!

Suddenly PayPal, in their wisdom, decided to withhold payment. Normally, every 3 or 4 days you draw down payments from PayPal. PayPal made the assumption that the orders were fraudulent. They had absolutely nothing to back this up.

The company is reputable and established. The products are great, built well and are what they say they are. All the orders were genuine and checked. Due to the volume of orders (which is good for PayPay as they get their cut) PayPal simply made the decision that there had to be something dodgy going on – which there wasn’t.  So in their infinite wisdom, they simply stated that they would hold onto all money for 120 days – absolutely crazy.

So, while the lawyers battle it out, it was my task to find a very quick alternative.

The Initial Solution

I made the decision to go with Google Checkout as it was simplest short term solution and the most realistic to get implemented within the few hours I had – well at the time this is what I thought.

So, the Google Checkout account was set up and I merrily added all the Buy Now buttons to all the product pages – coded, uploaded and working.

The first problem I encountered was that the simplicity of Buy Now buttons meant unless it was coded on the page (which is simple enough to do) the user couldn’t order more than one product, or multiple quantities of the product

The solution here was to revert to the Google Shopping Cart – coded, uploaded and working.

The second problem was that by default Google (in their infinite wisdom) only allow orders to be delivered to the default country of the Google Merchant account owner , in this case, good old blighty. Dam I thought, well that’s useless, for my client anyway, where 90% of their orders come from outside of the UK!

In a moment of complete insanity I wondered whether choosing Google Checkout was the right option. PayPal wasn’t an option (because they are clearly stupid – stick to eBay transactions – it’s what you know best), WorldPay (I don’t think so – thanks RBS) and the majority of other options had  either ridiculously expensive transactions fees or required a fully scripted cart (bespoke or off the shelf) to implement.

I searched and searched for a solution. Google’s help was useless, and didn’t explain clearly enough what needed to be done. They also have conflicting advice on what should be such a simple solutions. I emailed Google support – now I know they are busy, but they take too long to respond and you simple get sent links to the useless articles. I get the impression that they are so busy that they simply don’t have time to read your emails, and make a response based upon the subject alone.

The solution though was very simple.

Firstly, implement the Google Buy Now buttons or the Google Checkout using their instructions. These instructions are actually correct!

I ended up using Google Checkout, so I’ll base my explanation on this.

I added the Google code to the footer of my page (just above the Google Analytics code in this case – yes they are taking over the world). The “mid” refers to the Merchant ID code, so the XXXXXXXXXXXXXXX’ should be replaced with your merchant code.

Change the currency if need be, change the weight unit if need be, and post-cart-to-sandbox should be true to use the Sandbox (testing) environment, flash if you are going live.

<script  id=’googlecart-script’ type=’text/javascript’ src=’https://checkout.google.com/seller/gsc/v2_2/cart.js?mid=XXXXXXXXXXXXXXX’ integration=’jscart-wizard’ post-cart-to-sandbox=’false’ currency=’GBP’ productWeightUnits=’KG’></script>

I used the tool at https://checkout.google.com/sell to generate the button code for each product page – easy as pie. Pasted the code into my page and off I went.

Now for the clever but (which isn’t actually that clever, but if would be useful for Google to tell you in a simple way!):

You would have pasted in your button code, something like this:

<div>
<input value=”PRODUCT NAME IN HERE “>
<select>
<option selected=”selected”>CHOOSE YOUR COLOUR:</option>
<option value=”Muted”>RED</option>
<option value=”Bright”> BLUE</option>
</select>
<input value=”9.99″ type=”hidden”>
<div title=”Add to cart” role=”button” tabindex=”0″ Add to Cart</div>
</div>

Incidentally I tweaked the code generated by the Google tool to add in:

<option selected=”selected”>CHOOSE YOUR COLOUR:</option>

So that the user knew what options they wanted to choose and I removed the default  =”selected” from the first product option which Google puts in all on its own – how clever of it(!), and added in the “CHOOSE YOUR COLOUR:” option.

Also, I wanted to make the “Add to Cart” button a bit more fancy so added some inline styles (naughty but time was against me).

International Delivery

Next was solving the international delivery problem. This solution was simply, but the way Google explains it makes is incredible overly complex.

Underneath the closing div for the div called product, add in this code:

<form>
<input value=”NAME OF THE DELIVERY METHOS”/>
<input value=”1.99″/>
<input value=”GBP”/>
<input name=”checkout-flow-support.merchant-checkout-flow-support.shipping-methods.flat-rate-shipping-1.shipping-restrictions.allowed-areas.world-area-1″ value=”true”/>
</form>

<script type=”text/javascript” src=”http://checkout.google.com/seller/gsc/v2_2/cart.js?mid=XXXXXXXXXXXXXXX” currency=”GBP” post-cart-to-sandbox=”false”></script>

Change the values of the following to the correct values:

ship_method_name_1 – Name of Shipping Method
ship_method_price_1 – Price of Shipping Method
ship_method_currency_1 – Currency

Copy the code, changing 1 to 2 etc for additional flat rate shipping methods.

The important bit in the above is “world-area-1” – simply turns on the ability to ship internationally!

To implement alternative shipping methods, an explanation is here:

http://www.paycircuit.com/gc_cookbook.aspx

This guy is great – he knows more than Google!

So this sorted out the international delivery option, but no, it want over.

Shipping based upon the Cart Sub Total

I didn’t want to use flat rate shipping.  I wanted the shipping price to be defined based upon the value of the shopping cart – something I thought would be relatively simply. I set up my pricing matrix using the settings with the Google Checkout merchant’s area, but no joy. The coding on my page was overwriting these settings. Dam…. If it’s not one thing it’s another!

After some hefty searching I found a better solution.

Using the Google Checkout JavaScript API, you can calculate the shipping on the page, sent the calculations to Google Checkout and bobs your uncle!

I needed to tweak what I did earlier. I was aware in the future that my client would change delivery prices based upon weight which I needed to consider, so this is what I did:

On all pages containing products I added the following JavaScript into the <head> tag:

<script>
function googlecartOnCheckoutClick() {
var orderweight = 0;
var subtot = googlecart.getSubtotal();
var items = googlecart.getItems();
for (var i = 0; i < items.length; i++) {
if (!items[i].isMarkedForRemoval()) {
orderweight += items[i].getWeight() * items[i].getQuantity();
}
}
var ship = document.getElementById(“royal_mail”);
if (subtot <= 9.99 ) {
ship.value = 1.99;
}
else if(subtot <= 49.99){
ship.value = 4.99;
} else {
ship.value = 9.99;
}
return true;
}
</script>

The above code is pretty simply. All I did was set the order weight to 0 as I didn’t want to use this for the time being, then define an if/else statement for the different values as follows:

if (subtot <= 9.99 ) {
ship.value = 1.99;
}

If the order sub total is £9.99 or less, the delivery price should be £1.99.

else if(subtot <= 49.99){
ship.value = 4.99;
}

If the order sub total is £49.99 or less, the delivery price should be £4.99.

else {
ship.value = 9.99;
}

Otherwise make the delivery price £9.99 – i.e. if it’s more than £49.99.

So this code was added to the header.

All I needed to do now was to add the following code to the product code. I added it below the definition of the price, so:

<input value=”24.99″ class=”product-price”>

Became:

<input value=”24.99″ class=”product-price”>
<input value=”1″ type=”hidden” />

Then what I wanted to do was to use my JavaScript function which I added in the head to overwrite the deliver price in my product code. You will notice in the JavaScript code “document.getElementById(“royal_mail”);”. This is in essence the ID that we will be using to replace with our correct delivery price.

So to have something to reference:

<input type=”hidden” value=”1.99″/>

Became:

<input name=”ship_method_price_1″ value=”1.99″/>

i.e. I simply added.

Code, upload, test – and that’s it.

I hope this helps someone somewhere!

By Matt Conrad

Twitter: radleey
Linked In: radleey