A visit to Tesco Labs

We’re delighted to publish a guest blog post from our lucky Tesco Labs tour competition winner, Janis Wong.

Originally published on the Code First:Girls blog

“As the winner of the Code First: Girls’ competition, I won the amazing opportunity to visit Tesco Labs in Welwyn Garden City to find out more about how the historic company is transforming itself as an innovator within the industry.

Led by Sophie Caley, a product manager at Tesco Labs, she gave me a tour around the space and explained how technology has transformed in the past decade. From mock supermarket shelves to the latest virtual reality headset, the Lab was fully stocked with equipment to help Tesco find out how to best serve its customers through technology.

Although the Lab was established less than a decade ago, it has become a core part of the supermarket giant’s work. When speaking to Sophie, I was most interested by the human element of her work. Whether it is running a crazy brainstorm session with her team or collaborating closely with family testers for product trials, I appreciate how the company wants to put out high quality, tried-and-tested tools that truly benefit its customers.

Particularly for companies such as Tesco, where customers interact with them on a daily basis, it is often easy for us to forget about the whole operation and infrastructure that is used to run its stores. Behind the shelves are people from all disciplines who come together to ensure that everyone’s needs are satisfied as far as possible. From the technology perspective, this means figuring out where new products should be placed on shelves, how the website software can be made more accessible, and what new accessories can be developed to make the customer shopping experience more enjoyable.

Whilst people may be wary of adopting new technology, Tesco Labs firmly believe that new innovations can make our lives easier and more interesting. For me personally, it was an incredible experience to be able to better understand the direction that Tesco Labs is going and to learn more about how the company works with third parties to create exciting, new products. Instead of trying to replace the well-functioning mechanisms we currently have, Tesco prides itself in filling in the gaps to build creations both big and small, making our shopping, homes, and our lives more connected.

Once again, thank you to Code First: Girls and Tesco Labs for giving me this opportunity to see how the company is transforming how people use technology for the better!”

GoT summit: Taking retail everywhere with connected commerce

Tesco Labs’ Paul Wilkinson was invited to speak at the IBM Genius of Things summit, introducing the audience to the IoT work that we’ve been doing.

February 16, 2017
Steve Laughlin, General Manager, Consumer Industries, IBM and Paul Wilkinson, Head of Technology Research, Tesco Labs, explore how connected commerce is changing the face of retail.

The original post by Jen Clark can be found here.

Changing customer expectations
While 85% of consumers still prefer to shop in-store, their expectations are shifting. Now, they are demanding experiences that transcend physical and digital boundaries.

The retail industry landscape reflects this emerging need: margin pressure is increasing, with a 1.9% profit decline despite a 4% spending increase this holiday season. Technology is advancing dramatically, and 52% of retail CEOs are concerned about the pace of technological change. The competitive landscape is shifting too, and 60% of CEOs now expect more competition from other industries.

With the help of the IoT, retail is expanding beyond simple online transactions and in-store shopper experiences. Let’s look now at some of the top areas of IoT value creation.

Top areas of IoT value creation in retail
Retail operations:
Predictive maintenance: instrumented devices in-store can monitor the health of physical assets
Inventory management: a real-time picture of stock levels
Staff optimization: using staff members’ time more effectively
Customer experience:
Individual engagement: via personal devices
Associate clienteling
Automated checkout: no more waiting in line
Business model transformation:
IoT commerce
Fulfilment innovation
Data monetization

The future of retail
A connected world brings retail experiences to the individual wherever they are. Connected appliances such as smart washing machines can automatically order detergent when you run out. Developing infotainment systems in vehicles mean customers can shop from their cars, or receive reminders to pop by the store on their way home. Items can be delivered by drone.

The bricks and mortar store still matters, but it needs rethinking. A store instrumented with IoT devices can impact:
Food freshness
Energy use management
Foot traffic monitoring
Shopper insights
Real-time stock-out monitoring
Item location tracking
Smart signage / pricing
Security
Assortment optimization

 
How do you get started?
The IoT has a lot to offer the world of retail, but how do you get started? Here are three key suggestions:
Partner to innovate
Pilot in store
Scale based on real ROI

Getting results

Stores that have implemented IoT capabilities report clear positive outcomes. At Tesco, real customer pilots around food freshness and shopper insights have led to up to a 40% cost reduction and up to 5% productivity improvements.

There is no spoon

The definition of a pixel is straightforward. Isn’t it?

Introduction – the real world

The definition of a pixel is straightforward. It lives in the physical world and is the smallest addressable component of any digital screen. Its job is to emit light – specifically, colour. Screens are made up of thousands of these dots of light and each can be individually assigned a different colour such that when viewed together, the screen displays something that makes sense. A photo, or video for example.

An inch is a similarly simple concept to understand. A standard physical unit of measurement. So standard in fact that you can actually see it using a ruler, in exactly the same way as anybody else with a ruler can.

The challenge – pixel density

So why is it that when I define the length of an on-screen element in pixels using CSS, it doesn’t match the number of aforementioned physical pixels? And why is it that if I define a length in inches and then measure the result with a ruler, that doesn’t match either? The reason is pixel density.

First things first, a pixel resolution is the number of pixels that a display comprises. It’s usually expressed as two numbers – the number of pixels on the horizontal axis, and the number of pixels on the vertical axis. For example, 1920 x 1080 is 2,073,600 pixels. This happens to be the industry accepted number of pixels required for high definition (HD) content. The more pixels a screen has the better its definition, or clarity, will be.

Pixel density refers to the number of pixels that fit into a physical inch of a display. It’s (shockingly) measured in pixels per inch (ppi). As you might infer, all pixels are therefore not the same physical size – otherwise the measure would be redundant. The number of pixels that fit inside one inch would always be the same. In recent years, smartphone manufacturers have fit increasingly large numbers of pixels into devices that aren’t physically too much bigger. The pixel density has increased without the form factor changing a great deal.

Devices of the same size with different pixel densities pose a problem for designers and developers. This is because 200 pixels (or any other number) will look visibly much smaller on a device with a higher pixel density than that of one with a lower pixel density. The difference is so stark in fact that it would render text illegible on newer devices where it was perfectly acceptable on older ones. So, what to do?

A solution – the CSS reference pixel

The World Wide Web Consortium (W3C) identified this challenge very early on. In 1996 in fact (+100 points for forward thinking). For this reason, it recommends in its CSS specification that one CSS pixel does not automatically map directly to one physical pixel, but in fact represents an entirely abstract unit of measurement. When declaring a length in pixels in CSS you are in fact using the CSS pixel unit (px), which might as well be called a yazoo, yellowberry or any other random word. It isn’t directly related to physical pixels at all.

The idea behind the CSS pixel unit is to create consistency across devices with different pixel densities, to solve the 200-pixel problem outlined earlier in this post. The aim is that creating an object of length 200px will just look right on any screen it encounters. How it achieves that is very clever, and hinges on the CSS reference pixel. As you might expect, it has to take into account the physical properties of the display – i.e. how large it is, and in this case also how close to the eye it is held.

It’s beautifully relative – relative to you. Which is ironic considering it’s arguably the primary so-called “absolute” unit of measurement in CSS. The reference pixel is based on a 96ppi display held at arm’s length, assumed to be 28 inches (about the same size as a Flemish Ell – I know you were wondering). This is adjusted for the device you’re using at the time. For example, a computer screen will typically be larger, have a lower pixel density, and be viewed from a further distance than a smartphone will. This makes the reference pixel on the monitor visibly bigger. The illustration below visualises this well.

Pixels_image 1

(Taken from creativepro.com)

If you held the smartphone directly next to the monitor, you would see for yourself that the same number of pixels appears larger on the latter. For those who yearn for a more in-depth understanding, read the next paragraph. If you’re content, feel free to gloss over it.

The CSS reference pixel is actually an angular measurement (see picture below). Specifically, it’s the visual angle of one pixel under the aforementioned conditions – a 96ppi display, at a distance of 28 inches away from the eye.

Pixels_image 2

(Taken from www.w3.org)

 A tangent – defining CSS units

So why is a pixel called an absolute measurement in CSS? Well, it is anchored to a fixed reference defined using real world constraints – the reference pixel. Just as inches would be anchored to real world inches, if that’s how they were implemented (you can sense another explanation coming later). In contrast, relative units in CSS are meaningless without another dimension being given. 90% has to be 90% of something to meaning anything. One em has to be based on a font size to mean anything, even if that font size is the default one defined by the browser.

An example – implementing the CSS pixel

But back to pixels. Now we have the CSS reference pixel, we have an anchor for the CSS pixel unit. In reality it means that for devices with higher pixel densities, one CSS pixel maps to multiple physical pixels – and exactly how many is governed by a scaling factor called the device pixel ratio.

By means of an example, I use a OnePlus 2 smartphone. It has a physical pixel resolution of 1080 x 1920. However, if I put this to the test, I see a report of 360 x 640. The device pixel ratio is therefore 3. (360 x 3 = 1080 and 640 x 3 = 1920). My resolution has been scaled by this ratio to implement the CSS reference pixel ideal most closely. And thus, 200 pixels will look correct on my device in just that same way as they would for a device of a much lesser pixel density. Brilliant.

Physical measurements – not what you might think

So what about inches? Well, it turns out that inches aren’t (usually) inches either in CSS. Now, you’d be forgiven for thinking at this point that whoever is naming these things is being intentionally irritating, but things will become clearer in the points that follow.

W3C has specified that if you are viewing your CSS inches on a sufficiently high resolution display (meaning high quality printed output as far as I can prove) then they should indeed reflect reality. And they do – print your web page including a measurement in inches and get that ruler out again. However, if your display is not sufficiently high resolution (meaning anything else including screens, as far as I can tell) then they will not. Instead, one inch will equal 96 pixels. 96 CSS pixel units, that is. Exactly what that magic “high” resolution is doesn’t appear to be openly revealed.

In fact, all physical measurements in CSS are defined in relation to each other, in a fixed ratio. 96 pixels is equal to one inch, which is equal to 2.54cm and so on. For a full rundown have a look at the W3C specification itself.

Another way – density independent pixels

Before we end, it’s worth harnessing this new understanding to examine density independent pixels (dp). This is a different mechanism to the CSS reference pixel, designed for the Android operating system, to solve exactly the same problem – achieving consistency on screens of different pixel densities. It’s simply a different abstraction.

In this case, one dp is defined as looking visually the same as one physical pixel on a screen with a density of 160ppi. A simpler definition, but using exactly the same logic. I.e. set a reference pixel based on constant real world measurements, and then scale displays appropriately to most closely imitate this ideal.

Because the definition is simpler, the implications are a little simpler to understand. For example, 160ppi is considered the baseline (and is called mdpi*). At 240ppi (i.e. 1.5 times the baseline – called hdpi) the scaling factor is 1.5. At 320ppi (i.e. two times the baseline – called xhdpi) the scaling factor is two.

*“mdpi” stands for “medium dpi”, “hdpi” for “high dpi”, “xhdpi” for “extra high dpi” and so on until “xxxhdpi” at the point of writing. Surely not the most sensible naming convention in hindsight. But infinitely scalable in theory I suppose.

Again, this system is put in place to enable Android developers to go about their business without worrying about the hundreds of different pixel density screens their applications may be used on. Android’s very own design guidelines use this same system to provide context.

Conclusion

We’re at the end of our meandering tale of pixels at this point (many congratulations for getting this far). Hopefully its cleared up to some extent why pixels are often not pixels, and in fact the reality that you don’t have to worry about it too much. The sooner you stop worrying the sooner your head will stop hurting. I promise.

Adding Multiple Products via IFTTT

An update for our IFTTT channel users – new and old.

When we launched the Tesco channel on If This Then That, we were keen to hear how it was being used, and if there was anything that you – the user –  would change, or like to be added, to improve the functionality. We were delighted that so many of you got in touch via twitter and email to let us know that you would value an amend to the “Add Product to Basket” action – allowing you to add multiple products at a time, rather than just one.

IFTTT Tweet

We’re pleased to confirm that this development has now been completed, with the Add Products to Basket action triggered by IFTTT in the same way as before. This allows a list of products to be easily generated by searching for keywords, brands or products and adding or removing them from your list; which can then be copied and pasted back into the IFTTT action. For ease of use, existing product lists in IFTTT can also be copied into the Tesco Search page and amended there.

We think that the potential benefits of using this multi-product function are almost endless, but here are a few of our favourite ways to use this update which you may wish to try to get you started:

  • If you know that there are items you need regularly, but not with every shop, why not set up a recurring action to add all the items you need at a suitable frequency. For example, add all household cleaning products every 8 weeks, or baked beans every fortnight.
  • By associating products with a special calendar event (for example, parties, birthdays or barbeques), you can ensure that you never forget these items again.
  • Why not create product lists associated with specific meal plans or recipes? You will then have the ability to add products to your basket based on your meal planning for the week.

IFTTT is now also compatible with Amazon’s Alexa, so you can employ voice activated assistance via the Echo or Dot. Here at Labs, we think that Conversational Interfaces in general are hugely exciting, as they provide the ultimate convenience experience. As a food retailers, our first goal is to understand how our customers would use such technology and for what purpose. We’ve already seen mCommerce accelerate ‘little and often’ – the concept of adding grocery items to their basket every now and then (rather than sitting down to place one big order), so the question is whether this tech will enhance that experience or change it completely.Watch this space for news on future Labs experiments and learnings!

As ever, we look forward to hearing about how you’re using this new development – let us know your feedback via email or on twitter.

Meet Mewbase – our first open source project

Many of us are already familiar with Open Source.

It grew in popularity with the rise of the Internet and a need for retooling  of computing source code. However not many are aware that it’s something which is becoming more and more popular with corporate businesses. Generally, open source refers to a computer program in which the source code is available to the general public for use and/or modification, something which has several key advantages. In particular, as a typically collaborative effort, it generates positive technical mindshare.

With a view to remaining innovative, and wanting to collaborate with the best in technology, we have begun work in this area and in November announced the release of our first Open Source project – “Mewbase”.

Developed by Tim Fox from Tesco Technology, Mewbase provides a way for our services and applications to manage their events and data, eliminating the need for them to communicate with other databases and event stores. Moving forward, our aim is to provide tools so our teams can generate a new working service from scratch in seconds from metadata.

This follows work which has identified that our services and applications are spending significant time re-implementing eventing, messaging and communications logic in similar but somewhat different ways from service to service. Using a consistent approach through Mewbase will allow our development teams to get services and apps to market faster thus freeing them up to push the boundaries of development, without being bogged down in building already “solved” problems. The knock on effect of this will be that our operations are faster and more effective, allowing us to work more efficiently.

If you would like to get involved with Mewbase, please visit our Google group, or come and chat with us on our irc channel #mewbase on freenode.net.