Case study – Live tracking display, Oldham Athletic Community Trust & Fullcircle
Sophie Hunt is running from John o’ Groats to Land’s End. Around 900 miles, around 24 days, raising money for Oldham Athletic Community Trust and Fullcircle.
We built the screen that shows where she is.
THE ASK
A display in a venue that shows, without anyone touching it, where Sophie is right now, how far through she is, and how much has been raised.
Two thirds map, one third numbers. The route drawn across the country, the bit she has done marked out, and a dot where she is today. Alongside it: miles covered, miles left, percentage complete, the fundraising total, and a line saying which town she has got to.
It sounds like a small job. It is four different pieces of live information on one screen, updating on its own for three and a half weeks.
NOTHING TO RUN
We built it so there is nothing to run.
That needs explaining, because it is the whole design.
Most things like this need a computer somewhere, switched on, doing work in the background. Somebody has to own that computer. Somebody has to pay for it monthly, keep it updated, and be available when it stops.
A community trust should not inherit all of that because they asked for a screen.
So the tracker is just a web page. Ordinary files, sat on a website, the same as any other page. Nothing running in the background. Nothing to restart at 6am on a Sunday when nobody is around.
That one decision determined how we solved everything else.
DRAWING THE REAL ROUTE
To show how far through she is, the screen needs to know the actual route.
You cannot draw a straight line between the two ends. Straight across the country is about 600 miles. The roads and paths she is actually running are about 900. Use the straight line and every number on the screen is wrong, by a lot.
So we took her 23 real overnight stops, the actual campsites and towns she is staying at, and worked out the genuine road and path route between each one and the next.
Then we saved the finished route as a file and built it into the page.
That last bit matters more than it sounds. The screen already knows the whole route before it loads. It never has to go and ask anything. It cannot break because some other website is down or has changed, and it cannot start costing money.
The hard work happened once, on a laptop, before it went live.
KNOWING WHERE SHE IS
Sophie carries a phone. An app on it sends her position to a Google Sheet, automatically, as she runs. The screen reads from that sheet.
This is not the clever solution. It is the right one.
It is free. There is nothing to maintain. And the sheet is readable by a human being, so if anyone needs to check whether it is working, they open a spreadsheet and look, rather than ringing us.
Two things happen between the phone and the screen.
A phone’s position is never exactly on the route. It is somewhere near it, out by a few metres either way. So we snap it to the nearest point on the route line, and read the distance from there.
And the number never goes backwards. Phone positions wobble, which means a raw reading can make it look like she has gone into reverse. On a screen in front of a room of supporters, that reads as either a broken tracker or a runner going the wrong way. Neither is acceptable, so the furthest point she has reached stays the furthest point she has reached.
Small rule. It is most of the reason the screen looks trustworthy.
THE FUNDRAISING TOTAL
The total is read live from the JustGiving page every time the screen updates.
That is more awkward than it sounds. JustGiving does not let other websites read its pages directly, so getting the number out takes a workaround, and workarounds break.
So we planned for it breaking. If the total cannot be read, the screen shows the last known figure rather than a gap or a zero.
A slightly out-of-date total is fine. A screen in a venue announcing £0 raised is actively damaging.
PUTTING IT IN WORDS
“64.2% complete” tells you almost nothing if you are standing in a venue in Oldham.
“Just past Carlisle” tells you everything.
So we built a list of real towns along the route, each one tied to a point on the line, and the screen names the nearest one.
We wrote that list by hand rather than having the screen look place names up automatically. It keeps the page independent, and it means we choose which names appear rather than getting whatever a database offers.
That choice turned out to matter, in both directions.
NAMING THE RIGHT TOWN
Once the real positions started coming through, the screen named the wrong town.
The obvious explanations are all in the tracking. The phone. The snapping to the route. The distance calculation.
It was none of them.
Her position was right. The mileage was right. The percentage was right. The list of towns we had written simply did not include the one she was actually near, so the screen picked the closest one it did know.
The tracking was accurate. The information we had given it was incomplete.
That is the part worth holding onto. It looked like something was broken. Nothing was. The gap was in what we had told it about the country, not in how it worked.
It is also the price of writing the list ourselves, turning up exactly when you would expect it to. We would still write it by hand. But it means that list is something to keep an eye on during the run, not something finished on day one. We know that now, rather than finding out later.
REBUILDING THE ROUTE
The first version of the route was a reasonable path from one end of the country to the other. It was not her path.
So it was rebuilt to go through the real overnight stops, the actual places she is staying, and the town list was redone to match.
This was not tidying up.
Every number on that screen is measured against the route line. Miles done, miles left, percentage complete. If the line is not the route she is running, every figure on display is wrong, and wrong in a way that looks completely confident.
We checked the rebuilt version against her actual live position before calling it finished.
WHAT IT COSTS TO RUN
Nothing.
No hosting bill, no subscription, no server sat somewhere, no passwords to keep rotating.
The only ongoing job is keeping an eye on the list of towns, and a Google Sheet that fills itself in.
The effort went where it mattered instead: making sure the route is real, the numbers can be trusted, and every part that depends on somebody else’s website has a sensible answer for when that website is unavailable.
THE POINT
The most useful thing this project turned up was not a fault.
It was a list of towns that was slightly incomplete, and we only found it because someone compared where she actually was against what the screen was saying, and noticed they disagreed.
The design decisions are what keep a screen running unattended for three and a half weeks. Nothing to restart, nothing to pay for, numbers that never jump backwards, an answer ready for every part that could fail.
But none of that makes it correct. Correct came from checking it against the real world and fixing what did not match.
Those are two different jobs, and the second one is the one that usually gets skipped.
CREDIT WHERE IT BELONGS
Sophie is running 900 miles.
Everything described here is a screen. It reports on the work, it does not do any of it. The route, the stops, the distances, the days, all of it exists because someone decided to run the length of the country to raise money for two organisations in Oldham.
The least the technology can do is show that accurately, and not fall over on day nineteen.
WHAT WE TOOK FROM IT
- Do the difficult work once, up front, so the thing that runs every day has as little as possible to get wrong.
- Assume anything depending on someone else’s website will be unavailable at some point, and decide in advance what people should see when it is.
- A number being right does not mean the words next to it are right. Check both.
- Test it against reality before calling it finished. Not a rehearsal, the real thing.
- Handing an organisation something with nothing to maintain is worth more than handing them something clever.
Inclusive Bytes builds and supports technology for community organisations across Oldham. The aim has always been to help the people and organisations doing the difficult work make better use of tech.