A phone full of sensors

A screen, or a box of instruments

A parent looking at a phone sees a screen: the thing your child's face is pointed at, and the thing you end up negotiating about. It is a poor description of what a phone actually is.

Underneath the screen sits a small collection of measuring instruments. One chip knows which way the phone is tilted. Another knows how fast it is turning. One knows where north is, one how bright the room is, one roughly where in the world it is. The cheap handset has the same parts, because a phone needs them to rotate the picture, dim the display and draw a map.

What matters for a child learning to code is that those instruments are readable. In a block-based environment such as Pocket Code, one block reports the tilt, the brightness or the speed of a turn, and that number can move something on screen. No mathematics, no wiring, no extra kit to buy.

• Accelerometer Which way the device is tilted, and how hard it is being moved or shaken
• Gyroscope How fast it is being turned, and around which axis
• Magnetic sensor Where north is, so a game can tell which way the player is facing
• Light detector How bright the surroundings are, so a game can react to a torch or a dark room
• GPS Roughly where the device is, and therefore whether it has moved
• Touch Where a finger is on the glass, and whether it is still there

Measured directly, or worked out afterwards

Not every sensor value a phone offers is a measurement. Some are; some are a calculation the software performs on top of several real ones. The Spanish pilot's evaluation draws that line explicitly: physical sensors measure something about the world directly (accelerometer, gyroscope, proximity), while virtual sensors are produced by software combining several hardware readings into one new value. On Android, the paper names linear acceleration and gravity.

It sounds like a technicality, and it explains a whole class of confusing moment. A phone lying flat on a table is not motionless as far as the accelerometer is concerned: gravity pulls on it, and the raw reading says so. Getting gravity back out is what a worked-out value does. So when a child announces the tilt block is broken, the block is usually fine and is measuring something slightly different from what they meant. That is one of the few places a non-coding parent can help: ask what number they expected.

Why this changes what a first project can be

On a laptop, a beginner's first game is nearly always the same shape: press a key, something on a flat screen moves. That works, but it happens inside a rectangle at arm's length, and the only connection between the child and the thing they made is a keyboard.

Sensors change the shape of the project. Tilting the device can steer something. Shaking it can set something off. Walking across a room can move a character. The physical world becomes an input, and the game becomes something you do with your body rather than something you operate.

Our own view, and this is a judgement from teaching rather than a finding from any study: it matters most for the child who has decided they are not a computer person. That decision usually follows typing something, waiting, and being told it was wrong. A sensor game reverses the timing. You tilt, it moves, now, and if it moves the wrong way you watch it go wrong instead of reading an error about it. The loop from doing something to seeing something happen is short, bodily and hard to misread. We have no evidence that it converts anyone permanently, only that it changes the first ten minutes.

What a child doing this well looks like

Tilt used for a reason. A marble rolling through a maze should be steered by tilting, because that is what a real marble does. A quiz whose answer buttons you pick by tilting is using tilt because tilt exists. Ask why the game is controlled the way it is; a child who has thought about it will have an answer.

Testing the edges. Watch for a child deliberately trying to break their own game: turning the phone all the way over, shaking it harder than any player would, covering the light sensor with a thumb, walking out of range. That is not messing about; it is finding out what the instrument does at the limit of what it can detect.

Arguing about a number. Sooner or later a sensor game forces a decision that cannot be dodged: how fast is “too fast”? A child has to pick an actual figure for the point at which a shake counts as a shake, watch it fire when someone breathes on the phone, and pick a different one. Turning a vague human word into a number you can test, then correcting it against what happens, is a large part of programming.

What to be sceptical of

Location deserves an outright question. A game that wants to know where your child is should have to justify it. Some genuinely need it; plenty ask because the permission is cheap to request and the data is worth something to somebody. Make your child explain what the game does with location before granting it, and say no when the answer is thin. That holds whether the game came from an app store or your child built it: a project that reports its own position and gets shared is sharing more than a game.

The rest is smaller. Sensor games flatten a battery faster than tapping games. A game that needs walking about needs somewhere safe to walk. Motion controls quietly exclude people: a child who builds tilt-only controls and hands the phone to a grandparent learns something about who can play. And a phone shaken in earnest gets dropped.

Where the evidence sits, and where it stops

The Spanish pilot's evaluation was published in a sensors journal, which is not an accident: the sensors were the point. It names accelerometer, gyroscope, magnetic sensor, light detector and GPS among the components a game could read, and argues that sensor data lets a game simulate a real physics or maths experiment. The concrete case the authors give is that accelerometer motion data combined with gyroscope orientation is what makes a racing-game template possible. Pupils in that pilot also linked their phone code to LEGO robots, covered in our LEGO League robot piece.

What the study does not show, and what we will not imply, is that sensor games teach physics better than another method would. It measured whether pupils and teachers found the tools practical, stimulating and appealing, not what anyone learned. The case here is about what a beginner can build, not about marks.

The tools section covers Pocket Code and what sits behind it, andfrom consumer to creator takes the wider question of using a device against building with it. The rest is on theat-home hub.