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

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

 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.


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.

Our dynamic advertising has changed

Last month, we introduced you to our F&F Forecaster project. We’ve learnt lots since installing the screens at our Hammersmith Metro store and we’ve made some updates.

You can read our first instalment about this project here. The purpose of the very big, very bright screens was to tell a story to those who passed by:

“You know, you can purchase clothes online from F&F and collect them in store the next day.”

We decided it would be fun to achieve this by displaying a weather forecast for the following day, and presenting relevant clothing choices.

F&F Forecaster v1

Next we asked you, the public, what you thought. You told us you liked seeing the weather forecast. We get that – it’s useful, and we’re not asking you to buy anything. However our story, as described above, proved difficult to understand in the environment. Outside our Hammersmith Metro store is certainly a very busy place, but not many of you spend much time there as you’re usually on your way to or from the tube station nearby.

So in the spirit of iterative design, we changed it. We removed our Click & Collect message completely, and refocussed on the link between the weather forecast and clothing purchases.

F&F Forecaster v2

Our revised designs see the weather forecast visual duplicated on the first and third screens. We also redesigned it to make it even simpler to digest. Specifically, it includes a summary (e.g. “It’s going to be cloudy”), the felt temperature and the chance of rain. Each of these facets of the forecast appear sequentially, one at a time.

The clothing carousel visual remains on the middle screen, but we have also added a visual cue to look down toward the interaction points, as you suggested that they weren’t prominent enough:


Having made these changes, we spent the day in Hammersmith speaking to you again, and we learned some more, valuable lessons.

Our trial in Hammersmith has drawn to a close. We appreciate all of the feedback you’ve provided in Hammersmith, on Twitter and indeed on this blog. We’ll learn from all of our findings to make an even better proposition for you next time!

Blue sky thinking (with a % chance of rain)

We’ve been working with our F&F clothing team on a dynamic advertising concept.

These days, customers can order their F&F clothing online and collect it from their local Tesco store the next day. This service that many customers love is available in over 900 stores, but not everyone knows about it. That’s why Tesco Labs recently teamed up with F&F to find new, creative ways to spread the word.

The latest concept we’ve been experimenting with is the ‘F&F Forecaster’: a new approach to digital signage, where we dynamically display clothing options from F&F based on weather forecasts.

The F&F Forecaster at Hammersmith Tesco Metro

The design process for this product has been really interesting and a testament to the power of starting user testing at a very early stage.

In iteration 1, we ambitiously tried to communicate all of our core messages on one digital display. However, we soon found that the display was looking too busy and unclear as a result. So we settled on splitting the messaging across 3 screens as follows:

Screen 1: Tomorrow’s weather forecast (powered by

Screen 1: Tomorrow's Forecast

Screen 2: F&F clothing recommended for the forecast.

Screen 2: Recommended F&F Clothing

Screen 3: Click & Collect countdown – customers who order before the timer runs out can collect their items from store the next day.

Screen 3: Click & Collect Countdown

Communicating the messaging across multiple screens made the concept easier to understand. An alternative approach would have been to cut down the number of messages we were communicating. But as we were keen to learn which messages really resonated with customers, we decided to start broad with a view to later focusing in on the most compelling elements.

The findings from customer testing also drove the designs of each of these screens individually. For example, our original intent was to display a fairly comprehensive weather forecast on screen 1. However, our insight showed that this was too much information to digest quickly and that the weather facets that customers really cared about for clothing decisions were ‘temperature’ and ‘% chance of rain’.  We therefore simplified the design to make these points more prominent.

Screen 1: Early Iteration

Screen 2: Current Iteration

In addition to raising awareness, we wanted to give customers an easy way to order the clothing advertised on their mobile and try out the store’s Click & Collect service. We facilitated this by including a URL, QR code, and NFC tag below the screens, so customers can interact in the best way for them. It will be interesting to see the uptake of this shopping journey in an outdoor environment and which interaction method proves most popular.

NFC Interaction

3 Ways to Interact with Mobile

The ‘F&F Forecaster’ is now live in Hammersmith Tesco Metro (just outside Hammersmith underground) and we’re continuing to gather valuable insights which will shape further iterations of the design. This will help us ensure this product is as engaging and useful as possible to our customers.

We’ll let you know how we get on, but in the meantime if you have any thoughts on this project then we’d love to hear from you…

Help wanted with our grocery shopping experiment!

Making a more intuitive way for customers to shop their favourites.

At the 2014 Tesco Globe’athon (our first global Hackathon) we had the idea to make the ‘favourites’ ‘browse and shop’ experience more optimal by allowing customers to organise them in more personally intuitive groups, in ways that make sense for them.

Favourites on the website, actually refers to past purchases in store or online and, with wide palates and big families, can become a very long list for a regular Tesco shopper. I should know, I’ve got over 540 favourites!!

We already offer customers the ability to create ‘shopping lists’ on the Tesco grocery website, but we wanted to recognise the centrality these ‘favourite’ or ‘previously purchased’ products have to a weekly grocery shop and extend a similar feature just to them.

It is our hypothesis that if there were a way for customers to organise, browse and shop their ‘favourites’ more intuitively then customers may well become more satisfied with their overall order.

What we’ve done:
We’ve created Foodlisto which provides a stand-alone window into a customer’s grocery favourites.

Foodlisto allows customers to login with their existing grocery details and:

  • Create bespoke categories for their favourites
  • List sort those categories that are created
  • Edit and update the name and the contents of categories that are created

(*Customers can also add products to their actual basket using Foodlisto. But customers cannot check-out on Foodlisto itself.)

What we’d like to do now with Foodlisto:
We want to learn more about our customer’s appetite for organising their favourites this way and also which categories are created.

To achieve this we are currently looking for willing recruits to use Foodlisto and categorise their favourites for us.

Over a period of 6 weeks, from mid December 2014 to the end of January 2015, we will collect all category names that get created and the products within them.  We really want to know if this is useful and how you real people would use it.

All the data and insight generated from Foodlisto will be passed to the grocery development team to help them improve the  overall customer experience*

How you can help:
This experiment has now closed but we have created a short video below to show how categorising your favourites work with Foodlisto would work.

Please note: Foodlisto is a hack and works best on larger screens. We recommend you are on a laptop or desktop computer. Foodlisto will not currently work on smartphones or screens smaller than an iPad in landscape view.

Data Caveat: for more information on the security and privacy of your data, please see

but basically for the duration of our experiment please be aware that the names and contents of the food categories you create on Foodlisto will be recorded and shared internally at Tesco. This information will be recorded anonymously and will not be distributed with anyone outside of Tesco. If you would not like your category data used in this way then please don’t use Foodlisto. 

Project: Meal Deal Express

We’re running a live experiment in our Dean Street Metro store next week!

Background and Introduction

We’re working on a project with the London Format team which will ultimately achieve the goal of “I Don’t Queue”. Queuing is real issue in central Metro and Express London stores particularly at lunchtimes when customers are choosing the popular £3 Meal Deal and proceeding to the checkouts faster than the checkouts can process them.

The latest checkouts can process customers faster (as can ‘scan as you shop’) but checking-out at the end of the shop can still be improved. So our aim is to find a way where we completely eliminate checkouts. In our vision of a future customers walk into any Tesco, fill their basket or trolley, and walk straight out again.

Goals and Objectives

To start the first phase of this work, we’ve created a one week (Monday to Friday) experiment called “Meal Deal Express” where we have taken queuing and completely designed it out.

We have built a ‘Meal Deal Express’ zone in the centre of Dean Street Metro in Soho which consists of three adjacent ‘stations’. Customers move along the stations choosing one item from each. They then checkout by either tapping a contactless payment card on an NFC terminal constantly set to debit £3 from any card tapped on it, or by using a mobile payments app that makes them scan a QR code then tap ‘Pay’. These two options were chosen because it takes no more than 5 seconds to process the transaction. The entire checkout time is 5 seconds. The customer then happily walks out of the door.

The ’30 second challenge’ is on!

Summary (for those in a hurry)
• Tesco Labs are conducting an experiment to speed up the purchasing of popular Meal Deals.
• We are running the experiment for one week (13-17 Oct 12-2pm) in one store, Dean Street Metro, London
• We are working with innovative suppliers to see how fast customers can purchase their meals with new technology.
• Results of the week-long experiment will be fed in.

Project: Health Buddy

What role can Tesco play in promoting good health and wellbeing?

Background and Introduction

What we eat can contribute a huge amount to our general health and wellbeing. As the UK’s biggest supermarket, Tesco recognises the key role it can play in promoting good health and wellness.

The app and wearable tech market, in particular, has grown dramatically over the last 3-4 years. Health products from Nike, FitBit, JawBone and Pebble have emerged on the market as fantastic Health aids.

In the lab we wanted to see whether we could develop a product that would harness the excitement generated by this new app and wearables market, but put a Tesco spin on it.

Goals and Objectives

HealthBuddy is ostensibly research driven, we’ve had ‘fun’ exploring:

  • Alternative ways for customers to record their daily calorie consumption.
  • Utilising in-built android phone sensors to track customers daily activity.
  • Pairing an Android application with a wearable hear-rate monitoring device.
  • The latest Android UI patterns.
  • Activity based gamification mechanics.
  • How to build mobile apps using the Xamarin platform.

Our aim has not been to produce an application we would immediately give to customers.

Where We’re At Now

We have built and Android app that delivers on what we set out in our goals and objectives. Customers can use HealthBuddy to track their calorie consumption in multiple ways and monitor four variations of physical activity.

Customers can select an activity goal when they setup a profile. A simple overview screen is available to track progress. Rewards are released for achieving activity goals which can then be shared socially.

Our next step is to test HealthBuddy with a control group and gain feedback on potential uses for the prototype moving forward.