Tuesday, 31 March 2009

WiFi vs cellular customer access to Tesco service applications

I was intrigued by a response to my blog post about an idea to have customers with smart phones roam onto a Tesco WiFi network in our stores in order to try out various functions such as search for a product and be guided to it.

Andrew Grill of Marcom Professional wrote (see his original blog post here):

On the microsoft video post Adam Cohen-Rose also pointed me to a Tesco blog from Nick Lansley about using dual mode GSM/WiFi phones in store to get latest offers via WiFi.
The thing I think Nick misses in his post is that configuring WiFi access points in any handset is not for the faint hearted. I cringed slightly when Nick said in the post
"OK so the devil is in the detail. But it’s not a big devil. Let’s think of the customer experience here: "….and then he listed FIVE steps consumers had to take to get the offers. NO! Why not let consumers access these “special offers” via their standard mobile internet connection BEFORE they get to the store - and enjoy the full utility of the mobile in their journey and experience on the way to the Tesco store. It’s got to be something my mum could do or your standard Tesco shopper won’t even bother.

So you don't have to go and re-read my original post, the five suggested steps are:

  1. They arrive at the front of the store
  2. They see a sign that says:
    Use our wifi - start your browser and select 'Tesco' from your Wifi list'.
  3. They duly open their browser which causes the phone to list the available access points and they choose 'Tesco'.
  4. Their web browser tries to get to whatever home page the customer has set up - but is of course directed to a 'landing page' much the same way that you see a landing page when accessing the internet through a hotel wifi service, and you have to provide your credentials and possible payment details to proceed.
  5. The landing page offers services such as 'find a product' and, once marketing get this idea, a whole host of marketing messages.

The first thing I should point out is that the only actually 'teccie' thing that the customer has to do is select the 'Tesco' WiFi signal. Arriving at a store (step 1), reading a sign (step 2), and looking at a web landing page (step 5) are not exactly part of any technical problem! I would even argue that starting the web browser on the phone (step 4) is only slightly technical insofar as you have to select it from the applications on your phone.

As for step 3, if it's a phone such as an iPhone it automatically suggests connecting to unencrypted access points anyway, allowing for a simple Connect? Yes or No question to be answered. I note from a couple of colleagues that Blackberrys and a Nokia E61 do the same thing. It's actually so simple that I think Andrew's mum could do it!

Andrew does point to a question that I didn't answer, which is why is it that I didn't suggest using the cellular network and make the applications available on an internet website rather than an internal service requiring WiFi access?

There are two good reasons:
  1. Tesco have used building materials that have accidently turned many of our large stores into 'Faraday cages' which block radio signals. The latest style of our modern spacious Tesco Extra stores with sweeping metallic roofs and walls look inspirational - but unless the Tesco store is next to a cellular tower, the weaker the phone signal becomes as you walk deeper inside away from the entrance door and windows. I find it often peters out half way to the back wall. On the other hand, the WiFi signal is 'locked' inside the store by the same Faraday cage process, giving great coverage thanks to reflections from the structure.
  2. At this time, cellular internet access can be expensive with low downloads limits (excepting some contracts such O2/iPhone which is 'unlimited'). Although we can author lightweight web pages (bytes wise), we have to ensure that the customer thinks we are good value enough to use some of their bandwidth using our service. I accept that this sounds a little pedantic on my part but we build our brand on trust and I am quite sure that customers will prefer a free service using Wifi to one which costs them part of their monthly bandwidth.

So to summarise - I have recommended Wifi to offer customers a mobile web service in-store in a free and reliable way.

So don't cringe, Andrew: All I have to do is show your mum (and all our other customers) that is it easy, useful, and no hassle. (Actually, between you and me, we will likely offer both cellular and Wifi web-based services).

Wednesday, 25 March 2009

Tesco.com Grocery Accelerator for IE8 now live

If you have Microsoft's latest web browser, Internet Explorer 8, try out our new Tesco.com Grocery Accelerator.

Then, whenever you read a web page anywhere on the web that mentions food and drink, click the blue 'accelerator' icon that appears next to the word(s) you highlight on the page. When the accelerators menu appears, hover your mouse over 'Hover to search Tesco.com grocery' in your list of accelerators. A small window will appear which, after a few seconds, will list up to five Tesco.com products matching the highlighted text.

If you click the 'Hover..' message (rather than just hover over it), a new page opens with some extended search results.

The accelerator is actually an XML document which has commands to tell IE8 what do. You can see the XML itself (in any browser that renders XML) if you navigate straight to http://tesco.cloudapp.net/addTescoIE8Accelerator.xml

The accelerator XML points to page ie8.aspx (running at our space in the Microsoft Azure 'cloud') whose behaviour depends on parameters supplied in the page request, namely  'searchfor=' and 'preview=n'.

So, searching for highlighted text 'chocolate' becomes:
http://tesco.cloudapp.net/ie8.aspx?searchfor=chocolate  in preview mode, and
http://tesco.cloudapp.net/ie8.aspx?searchfor=chocolate&preview=n  in full-page mode.

The page ie8.aspx is, of course, using the Tesco.com grocery API to perform the search. The page does not have the actual credentials of the customer, so it calls the API with an account pointing to our Brent Cross store in north London, which has an average-sized product range.

Soon I intend to both improve performance and also update the service so that the customer can login to the service quickly, search their own store, and add the search results straight to their shopping basket - ideal if, for example,  they are on a recipe site and want to obtain the ingredients.

Monday, 23 March 2009

Tesco API now running in Microsoft Azure 'cloud'.

Well I'm delighted to say that the Tesco API is now running in Microsoft's Azure cloud computing service and it seems to be working just fine. This means that I can scale the service beyond my single server on which the API was hosted until now.

I have also made a change to a few of the methods available from the service so I have placed below a message sent to all API developers over this weekend. My boss also saw the message and declared that the way I have authored it as 'a roller coaster ride', since I am write it as 'good-point then bad-point then good-point', and so on.! Oh well, this ride is fun, but you must hold on....

Dear Tesco API Developer
This message is to tell you of a 'breaking change' being made to the Tesco API this weekend, and to let you know that the API is now being hosted in the new Microsoft Azure cloud computing service.
First of all, the 'breaking change' (where your app will have an error if it tries to use the API):
There are three methods that enable your application to receive product lists, namely:

ListProductsByCategory(), and

These now have an additional parameter added to the end of the list of parameters:
bool getRatings
You will need to update the API service end-point reference in order for your Integrated Development Environment to 'see' the new parameter and allow you to code it. In Visual Studio 2008, right-click the TescoAPI service reference you have set-up (visible in Solution Explorer window) and select 'Update Service Reference'.
You will need to supply a boolean 'true' or 'false' to this parameter, which will tell the API whether to get product ratings for each returned product, or just return the product objects without setting their Rating properties.
Setting the getRatings parameter to 'true' will continue to recreate the behaviour of these methods as before.
However, setting the parameter to 'false' will dramatically increase the speed at which the API returns the products - I have seen more than 400% decrease in wait time! The Rating property of returned product objects will always be zero if the parameter is false, regardless of the actual rating.
This change comes about as a result of feedback from several developers saying that the product search could be slow, with 'nothing to show the customer' for some seconds after launching their application. A good work-flow after this change will be to use the product searching methods with getRatings set to 'false', then populate individual product ratings on a separate thread by calling the search with getRatings set to 'true'. That way the customer gets to see products quickly, and ratings can be shown after a few more seconds, notwithstanding the feeling that it's a bit daft calling the same thing twice. Correct but community technical previews are all about identifying silly things, mais non?!
Even better, it may be that, as the customer focuses in on a smaller set of products, you call the GetProductRating() method on each product of that smaller set.
Or I go and think of a much better way! But for now at least the above ways will keep your app. going.
Ratings are a subjective feature at the moment and I will be interested in hearing what you think of them. I'm certainly not going to let them slow down core functionality.

Secondly, the Tesco API is now running in Azure, the Microsoft cloud computing service. This means I can offer a far more scalable API than on my single server solution.
However, Azure is still pre-beta and there is a complication: When you re-configure your Tesco API service end-point to point to the Azure URL, you are likely to get an error! This is because Azure is exposing internal machine names rather than external web addresses, which will upset Visual Studio 2008's "Configure service reference" wizard.
Fortunately, the workaround is simple. Just before you wish to change the end-point to point to Azure:
1) Configure/Update your service endpoint pointing to lansley.com to ensure it has the latest configuration (including the 'breaking change' above).
2) Open up your text find/replace facility in your IDE (in Visual Studio 2008 just press CTRL-H).
3) In the 'find' box enter the lansley.com end-point: http://www.lansley.com/TescoAPI/TescoAPI.svc
4) In the 'replace' box enter the Azure end-point: http://tesco.cloudapp.net/TescoAPI.svc
5) Ensure you have the 'replace all' scope set to 'everything in this project'.
6) Hit 'Replace All' (in VS 2008 client apps, I have found the 'replace' occurs more than 40 times).
7) Compile and test.

Unfortunately whenever I announce a new function or a 'breaking change' you will have to switch the service end-point back to lansley.com and then 'find and replace' back to Azure again. Microsoft are sorting out a fix and one day the problem will go away.
To overcome this pain, once I am happy the service is working without error on Azure, I will be releasing some of the constraints on the number of time you can use the API per day - and the product search limitations will removed completely. Give me a week to test all is well, first.
I have updated the documentation at http://www.lansleytech.com/tescoapiweb/reference.htm to reflect all this information.
Keep the feedback coming - we're sorting out a production team to carry the API forward into beta but we have no timescales on that just yet.

In the meantime, using the API on Azure means I can finish coding and testing a great new 'accelerator' for Internet Explorer 8 that will allow people to highlight food names on any web site and search for them at Tesco.com. They won't know but you will know the accelerator is using the Tesco API to work. You see? Code an API once and find a million uses!

Wednesday, 18 March 2009

Background to Tesco.com adopting ATG e-commerce platform

So many of you have written to me asking me for more information on the news that Tesco.com has picked ATG to provide their e-commerce software platform for our service.

First of all, you can read it here:

In a brief official announcement, Tesco and ATG have announced that "they have entered into a commercial agreement for ATG to provide Tesco its ecommerce
James McNulty, Tesco's head of group IT procurement, comments: "We are pleased to enter into a strategic partnership with ATG that will allow us to use this leading ecommerce solution in Tesco."

So what's going on?

Speaking as a 'founding father' of Tesco.com, for years we have differentiated ourselves from the competition by writing our own e-commerce software that fits in perfectly with our processes. We have no issue with the fact that for years this has work superbly well. We provide a great service to our customers and make a profit, what more can I say?

Competitors have tried to copy us but they have only seen the outside views of our software, such as the web site, the portable trolley computers used by our personal shoppers, and the handheld computer used by our drivers on which you sign for delivery. Their challenges have resulted from not understanding the many special algorithms that run deep below the visible surface that allow our staff to pick, pack and deliver efficiently.

However, recently we had to think about our business. What are we doing? Are we here to provide customers with a convenient home delivery service? Or are we a computer software company?

Completely: we're here to provide customers with a convenient home delivery service. Sure we write great software but wouldn't it be better to concentrate our IT staff on 'making the difference' rather than writing core systems?

ATG have been chosen because they have the e-commerce software that matches our core systems the closest. There were plenty of good competitors but with ATG we realised that we would have to re-develop our systems by the smallest amount and provide huge opportunities for growth and new ideas from our own business and IT staff going forward.

So we're about to lay off our own IT staff? Hands off! We in IT will be focussed on all the main business ideas that will make the difference. With the core already there, we can devote our people to designing and developing the 100+ pages of new business improvements and ideas that we want to pursue. For goodness sake, I am running 14 projects this year in R&D mode alone, let alone all the others that need developing!

If you think we've been successful when we've been writing core systems, imagine what we can do when we're freed from that job!

So where does Microsoft still fit in? As you may be aware our core systems have been written in Microsoft's .Net platform and we've have moved forward so very far this way. Microsoft will still continue to be our chosen partner for all the great experiences we are bringing - and wish to bring - the customer. They are fully aware of our decision and remain excited about the way we wish to use their technologies to provide a step-change in the customer experience (as I have illustrated in previous blog entries).

I'm also happy to say that excitement has come from many of our own developers - freed from the (shall I say) 'boring' core stuff, they will be able to concentrate on doing much more tech development to help customers and staff - and do it far more quickly. Yes I'll say it: once the ATG core is in place, our staff can do the 'sexy' stuff.

The has been some great analysis around this decision, by Richard Veryard of CBDI Forum.
take a look at:

Saturday, 7 March 2009

Azure moves time to UTC, and Tesco's place in the Azure cloud

I predicted in an earlier post that the Windows Azure platform team were going to have to have a serious think about what they do about time in the Azure cloud.

Well I've just come back from holiday to find in my inbox a message from the team saying that Azure is going to move from local time (Pacific, which happens to be the time zone where Microsoft HQ in Redmond is located) to Coordinated Universal Time (UTC) - that's Greenwich Mean Time (GMT ) to us in the UK.

In their message, the Azure team say:
Currently, the time zone within Windows Azure is Pacific Standard Time (PST). Soon, we will be migrating to Coordinated Universal Time (UTC). This is potentially a breaking change for applications which rely on local time.

When will we make the change?
We will start rolling out this change starting Sunday, March 8 at 10:00 AM GMT.

Why are we doing this?
Windows Azure is a global service. To ensure that applications behave the same way regardless of their physical location, it’s important that Windows Azure have a consistent time zone across all geographies. UTC is a natural choice given our global customer base, and UTC is not subject to potentially disruptive changes in Daylight Savings Time.

What’s the potential impact to you?
If your application running in Windows Azure relies on local time, you will be impacted by the migration to UTC. Here are a few examples of potential issues:
  • Gaps may occur in event logs if local timestamps are used.
  • User interfaces that depend on local timestamps may show different results.
  • Local timestamps stored by your application may be interpreted differently after the changeover.
Many applications have already been designed to rely only on UTC time. These applications should be unaffected.

The good news is that those of us thinking of the global nature of Azure will have been using the System.DateTime.UTCNow property to obtain time rather than using System.DateTime.Now if only because Pacific time was probably inappropriate to our applicatons unless coding for users located on the USA's Pacific coast.

The bad news is that of course we need to use time that is local to our user market, which means that we need to convert UTC to local time and then deal with summer/winter time within each application.

I'm still holding out for a setting in Web.Config that performs the equivalent of setting the local time zone on a Windows server and let it handle time moves just as happens today. Doing this at application level for Azure would mean that it would be flexible and easy to bring different time-zone versions of the same application to different countries.

Finally I'm happy to say that I've secured Tesco a place in the Azure cloud domain at http://tesco.cloudapp.net - I'll put something appropriate up there shortly (once my holiday completes tomorrow night!). The Tesco.com Grocery API will go up there shortly and I'll make sure that colleagues throughout Tesco wishing to try some 'R&D in the cloud' can get access - just contact me from your Tesco account to mine if you would like to do so.