Tesco.com API will be adopting 'OAuth' standard.

The Tesco.com API will be adopting the 'OAuth Core 1.0 Revision A' standard for third-party web access to customer accounts using the Tesco.com Grocery API Beta Edition from Phase 2 onwards.

OAuth, short for 'Open Authorization', is an open protocol to allow secure API authorisation in a simple and standard method from desktop and web applications.

Why is this good? Quite simply, customers will not have to give third party web sites their Tesco.com grocery login email address and password in order for that web site to have access to that customer's product range and basket. Instead, customers will give permission using a 'key' linked to their account. The key can be withdrawn at any time without the customer having to reset their password.

From the OAuth web site (http://www.oauth.com):
"The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.".

OAuth will be built into phase 2 of the forthcoming beta version of the Tesco.com API over the coming months. Until then, third party web sites wishing to use the forthcoming beta Tesco.com API (due for release at the end of August) can continue to use the current authorisation method of requesting username and password.

We will need to make sure that using OAuth is as painless for the customer as possible but there are several very good implementations out there so I'm confident that we can find the right balance between security and ease of use.

Third party web sites should keep in touch with the Tesco API Innovation Forum at http://www.techfortesco.com/forum for more information about switching over to the OAuth mechanism.
We will make sure that the implementation will require only a tiny change to third party web applications principally around use of the 'Login()' method (in the AccountClient class). Applications that call Login() get returned an instance of the Session class that is used as a token when calling all the other methods in the API for that customer. We'll make sure this behaves as it does today so you don't have to re-code your application beyond using Login() itself.

Client applications that are built for consumer devices can continue to use the current authorisation mechanism without having to make any changes to their applications and will not need to use OAuth (unless they wish to). This is because these apps will talk directly with the Tesco API and don't go via a third-party server.

We do reserve the right to provide new authorisation mechanisms and deprecate old methods as technology moves forward, but 'old and new' mechanisms will sit side-by-side for a while to give reasonable time for developers to update their sites to adopt the new service.

And if you didn't understand a word of this blog entry, relax;
I'll return to my usual higher-level writing shortly!

Tesco API TJAM - What happened and what's next?

Wednesday's TJAM event definitely falls into my 'unforgettable' category for two reasons above all others - the generation of 800 decent, coherent ideas from customers generated throughout the day, and the buzz of anticipation from developers as we showed some of our customer insight and explored the extra features of the forthcoming Beta addition of the Tesco API.

The day started at 8am for both ourselves and the innovation agency 'Happen' as the auditorium was prepared to meet customers, invited from our regular online grocery shoppers.

The customers themselves (numbering around 70) arrived for 11am and after some introductions they were invited to join one of six groups representing 'challenge briefs' for grocery, each group headed by a Tesco.com staff member to provided background to the brief, and a Happen 'agent' to work with the group to build and maintain mental energy levels, keep some focus to the brief and make sure group members were happy and enjoying the experience.

The challenge briefs were:

1. How to make the online shopping experience better than in store

2. How to help customers spend less on their weekly grocery shop

3. How to harness the potential of Mobile and emerging technologies such as smart phones, Internet TV, Set Top boxes etc

4. How to give customers inspiration for their weekly grocery shop

5. How to harness the power of social networking

6. How to help customers shop more quickly and easily

The first stage for each of the groups was 'sparking' - generation of ideas based around that group's challenge brief. This generated an astonishing 800 coherent ideas.

The next stage (after lunch) was to build one (or a group) of ideas into more coherent 'walkthrough' concepts such as an imagined way of using the service online or collaborating with family and friends when building an order. However the original ideas were not lost as some could be used in more than one concept.

The final stage was for customers to vote on the best concepts across all groups to find out the best of idea of the day. The winner was an imagined device called a "T-Scanner" that a customer could have on their keyring. The T-Scanner would contain a barcode scanner which would be used to 'collect' barcodes of grocery products they liked as they went about their daily lives. They would then insert the scanner into a USB slot on their computer and upload all the product ideas to a Tesco grocery list for final selection. There were plenty of other good ideas requiring applications rather than hardware, and amongst the favourites were a mobile phone app (for their mobile phone whatever make and model) and the desire for a 3D virtual Tesco grocery store.

The customers left at 4pm and we reset the auditorium for the developers even that started at 7pm. They took time out (over pizza and beer) to read the both concepts and individual ideas. At 8pm we took the developers through a learning curve on the types of customer who use our site so they could aim to make applications that would really be used.

They then learned about the new facilities of the forthcoming beta edition of the Tesco API - including the ability to search on nutrition and send 'ideas' to the customers 'ideas inbox'.

'Ideas' in the API's context are best described as 'media fragments' such as text, images, audio, video, or HTML snippets that the customer wishes to capture as they think of a product - but not yet linked to a particular grocery item. For example, an application could be used by a customer who is enjoying the wine they are drinking in a restaurant and they take a photo of it on the camera phone which is uploaded to their Ideas inbox. They might say the word 'carrots' into their mobile phone which becomes a compressed sound file which also gets uploaded. When it comes to place the order, the customer can examine their Ideas inbox and search for real grocery items - or allow the help of a 3rd party application which they give permission to plug-in to their inbox and use the specialist intelligence to suggest products based on media items. Examples might be a speech recgnition service or a site that specialises in deciphering wine labels or photographed barcodes.

Next, developers learned about the affiliates scheme, allowing them to earn awards based on attracting new customers and the contribution their application makes to a customer's checked-out grocery order.

Finally there was a Q&A session where developers asked questions covering such subjects as security, the interface syntax for our API (currently using SOAP but soon to have REST interface too), and how the business saw the future of the API.

AT 9pm we finished the conference!

Available for playing on throughout the day was a Microsoft Surface table computer, O2 Joggler and Wayve 'fourth-screen' devices - specialist hardware that customers might use now or in the future when it comes to online shopping.

So what's next? Mainly its us putting in the work to deliver the Beta API! Our timelines are:

1) Delivering the beta version of the Tesco API's SOAP interface by end of August.

2) Delivering the beta version of the Tesco API's REST interface by mid September.

3) Delivering phase 2 beta (the 'Ideas' system) around October - although this will be ongoing work.

4) Working with developers to improve the API for best practice for in terms of syntax, performance, security and more ongoing features.

5) Once everyone (developers and the our business) are 'happy' - lock down any changes to the API and deliver the blueprint to our production software developers during 2010 and finally deliver a working API to run on our main web site.

A caveat to this final point is simply one where we need to be sure that the business is happy. The Tesco API is a research project for good reason: this has not happened in grocery before and Tesco.com needs to be sure we don't have something that runs out of control in some way (financially, legally, security-wise). So this project will take slow, careful steps so we do not rush into the unknown.

Notwithstanding this, we feel we are going in a great direction and I am, by this message, stating publicly that we guarantee the Beta Tesco API's existence and performance levels for at least the next two years. That is of course our 'worst case scenario' - best case is that we get the API into permanent production during 2010 so that the beta API is retired for the best of reasons: it's then a reliable production application!

Finally, I have assumed from 'day-one' of our API project that our competitors will look into the API concept. After all, it's a natural extension of web services and I'm looking forward to seeing what API they offer developers. Perhaps they are watching our project to see what happens...

Two days until TJAM

With just two days to go to TJAM, I have emailed all the attendees with the following message. Since that message is now in the public domain I recreate it here.

I am getting quite a few bounce-backs from mail servers saying that some email addresses are not valid or that the mailbox is full. TJAM'ers please check your mailboxes!

I really could have filled TJAM at least twice over, so apologies to those who could not get an invite. I even did the 'airline' thing and and went 10% over in case there are some no-shows. So if you haven't received written confirmation from me then please don't try and gate-crash, or try and tag along with someone who has received confirmation. Next time we'll book Wembley...!

Dear TJAM'er

So there's only two days to go to TJAM and I hope you're as excited as we are to welcoming you to the evening event!

We're just putting the finishing touches to our presentations and confirmed everything with our affiliates team to welcome you aboard.

I’ve got some important items of news for you about:
1) The affiliates scheme and how it will work;
2) The fact we’re going to be unable to lift our ‘price comparison’ bar at the moment;
3) The opening of the Tesco API Developers Forum

Affiliate scheme
---------------------
We have now agreed the mechanics of operation of the affiliate scheme for Tesco API developers. To join the affiliates scheme you will need to join up at TJAM. You will need to bring proof of your ID (e.g. driving licence, passport, household bill) in order to sign up. You cannot sign up for anyone else, or sign up twice or more!

I’ll expand on the scheme greatly at TJAM, but you can see the full description in the Tesco API Developers Forum under 'The Affiliates System' entry. I will assume you have read this by the time you arrive at TJAM. Forum web address further down this message.


Price Comparison
------------------------
We’ve decided to delay lifting the bar on the terms and conditions for using the Tesco API for price-comparison for a few more months.

The reason is that, until our new ‘Project Martini’ grocery application reaches full-speed, we will still have to show guide prices for all our products.

Part of ‘Martini’s’ new strength is that it will be able to get the realtime price from our mainframe for every product - that is, the price it is right this moment. However the system to do that is still not quite ready, so we will have to show the highest possible price for that product for a few more months (that is, the highest it has been and could be for the foreseeable future). That way we won’t anger customers by making them pay a possible higher price - it will either be the same, or lower.

We accept we’re not doing ourselves any favours by showing products that might be more expensive than they actually are, but until we have tested and tested the realtime link for every eventuality - then tested some more - we just prefer it this way. Getting it wrong has serious consequences that starts with angry customers and ends with legal issues. At least with guide prices customers get pleasant surprises when they receive a delivery.

As soon as ‘Martini’s’ realtime link is working to the satisfaction of the most paranoid of us, then we’ll lift the bar. Then I’ll even put together a workshop for price comparison sites so we can work with them to get them the most current data. Until then, grocery price comparison sites will be barred from using the Tesco API.


Tesco API Developers Forum
---------------------------------------
The Tesco API Developers forum is now up and running. Do take a moment to register and go and meet with fellow developers. There will be support for the API so this is definitely your one-stop shop for help. The web site address is:

http://www.techfortesco.com/forum

See you at TJAM!

TJAM Daytime Event

You probably have a fair idea of what is happening at TJAM's evening developer's event.

However I've sorely underplayed the importance of the daytime event which will host Tesco.com grocery customers, plus 'creatives': people who can visualise a future idea, concept or even fully formed application in their minds.

It's the output from the daytime event - plus excellent insight from some recent ethnographic research we commissioned about customer grocery home shopping behaviour - that will feed into the evening. So if you've only heard about TJAM Evening until now, don't worry - you'll miss nothing. We won't have people coming to both events. In any case there is a maximum of about 70 people for the daytime event, all carefully vetted to ensure they match the customer mix who use our website.

EMC Consulting's Paul Dawson is working with our marketing team and a great creative innovation agency called Happen to make the daytime ... well... happen. Paul describes the TJAM daytime in this blog entry so have a read and see the source 'energy' that will create the materials that evening developers will absorb from 7pm.

I'll be there in the daytime helping to present, and spend time practising my live coding demo ready for the evening. Trying to write compilable C#/Java and make it work first time as 150 of my peer-group watch? Yes that's pressure. Think I'll stay off the provided free beer until 9pm.

Tesco API Forum now open

The Tesco API Forum is now up and running, designed for developers who are using - or thinking of using - the Tesco API for development work.

If you're wanting to get help and support for using the Tesco API, this is the best place to go. I'll be logged into the forum on a regular basis so I can answer questions (and dodge the brickbats as necessary).

Everyone is welcome although you'll need to register to access the service. Don't forget to read those terms and conditions for using the forum before you register. Don't worry, I try to make them interesting. The main point to digest is to keep the conversations about the Tesco API, programming and design, and TJAM; not about the wider subject of Tesco in general.

I will publish a regular digest of topics and conversations (positive and negative) from the forum in this blog so if you are not a developer you can still pick up a sense of the 'journey' we are taking with the API from here.

The forum software is SMF with a MySQL 5 back-end database, and uses a skin design called 'Anecdota' by Crip.

The forum web address is:

http://www.techfortesco.com/forum

See you there.

The Fourth Screen

Regular readers will know of my quest to bring Tesco grocery home shopping to every screen the customer owns (if they want us there) and our mission to engage a developer community to write applications for their favourite devices.

What has intrigued me over the last year is the adoption by many customers of what we geeks are calling the fourth screen.

Before I go any further I better count up the other three screens:

1. The first screen has been around since the late 1930s - it is of course the television set, evolved from a flickering display of the John Logie Baird mechanical device through to the high definition multi-input flat-screen of today - and soon a 3D immersive experience.
2. The second screen belongs to the computer, which came about in the 1970s when someone thought it might be a good idea to save printer paper by displaying the output on a TV instead. This screen is now your view of the connected world revealed through your desktop or laptop, and is probably your work tool too.
3. The third screen is the mobile phone, which has evolved from the dot matrix display on devices (literally) the size of bricks, into the iPhone’s internet-connected immersive touch-sensitive presentation.

So to the fourth screen: Specialist internet-connected devices such as photo frames that display digital images from your memory card or Flickr account through to the Chumby and O2 Joggler. They’re new on the market and tend to do a few specialist tasks really well.

Fourth screen devices intrigue me mostly because they tend to be installed at a single, static location in the home. They are small yet offer a point of focus. I own a Joggler and have placed it in the hallway where it spends most of the time displaying photos and occasionally sounding background music when I play audio around the house from a UPnP (Universal Plug and Play) server. It also offers me live traffic info - very useful just before leaving the house.

I’m also fascinated by the Wayve device - these are designed as instant media messaging focal points, where two or more Wayves can be joined up as a group using the internet as the backbone, and anything written on one Wayve can be sent to one - or all - the others, adding a ‘connected family’ feel. Importantly I see such a device as being located in the kitchen - for many the family ‘hub’.

Ah yes, the kitchen: As these fourth screen devices become common, I can see a great place for Tesco.com grocery ordering if the experience was right.

Getting the experience right is important - it’s probably too easy to take a potentially great device and develop a horridly labourious grocery shopping application. A good application for the fourth screen will be one that ‘lives the value’ of such a device: quick, easy, simple touch, ‘little and often’ usage, operating almost while walking by it rather than sitting down for a session in front of it.

I’ll certainly be encouraging ‘fourth screen thinking’ at TJAM and beyond.

N.B. Although I have mentioned specific products as examples of 'fourth screen' devices, this is for illustration only and should not be considered an endorsement of any such product either by myself or Tesco. However, if I mention any actual product I believe that it is fair to provide a link to that product's website.

Tesco API TJAM Event Now Full

Just a quick message to say that the T-JAM developers event on the 5th August is now full and registration has closed.

A big thank you to all the developers who registered to come along. You will all have received your confirmation (or apology for not being selected) email by now.

Do have a play with the community technical preview of the API if you haven't tried it yet. The developer access page is http://www.lansleytech.com/tescoapiweb