Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021
The UK city of Bristol will play host later this month to a new digital project which allows members of the public to interact with and talk to objects all around them.
The project is the brainchild of the research and design studio PAN, and it’s their “Hello Lamp Post” that has won the first ever Watershed Arts Venue’s Playable City Award. The awards were launched by the venue and the council alongside universities and tech businesses to find ways in which the city could be explored by its residents, known as Bristolians, and visitors to the city in a more game-like fashion.
The creators say that the aim of their Hello Lamp Post project is to:
“invite [city-dwellers] to try a new way of communicating… to slow down, reflect and give themselves permission to play.”
Bristol residents will be able to interact with urban, everyday street furniture – such as lamp posts, post boxes and bus stops. These objects already have a unique code on them, so that the local council can identify an object when it needs fixing, but these codes are now used as IDs for the objects – you simply text the object’s ID to wake it up, and it will start talking to you.
When you wake an object it you start a conversation with it, answering questions about your surrounding and what you can see. When someone else comes along and speaks to that same object they’ll learn more about people that have been there before and what they’ve seen and said. The more people that interact with the objects, the more that stories of the hidden lives of Bristol’s residents will be opened up.
The Hello Lamp Post project runs in Bristol from July 19th through to September 8th 2013.
James Barnes, StatusCake.com
James Barnes
Share this
More from StatusCake
When Code Becomes Cheap: The New Reliability Constraint in Software Engineering
4 min read How AI Is Shifting Software Engineering’s Primary Constraint For most of the history of software engineering, the primary constraint was production. Code was expensive, skilled engineers were scarce, and shipping features required concentrated human effort. Velocity was limited by how fast people could reason, implement, test, and deploy. That constraint shaped everything from team size,
James Barnes
March 25, 2026
Buy vs Build in the Age of AI (Part 3)
5 min read Autonomous Code, Trust Boundaries, and Why Governance Now Matters More Than Ever In Part 1, we looked at how AI has reduced the cost of building monitoring tools. Then in Part 2, we explored the operational and economic burden of owning them. Now we need to talk about something deeper. Because the real shift isn’t
James Barnes
March 18, 2026
Buy vs Build in the Age of AI (Part 2)
6 min read The Real Cost of Owning Monitoring Isn’t Code — It’s Everything Else In Part 1, we explored how AI has dramatically reduced the cost of building monitoring tooling. That much is clear. You can scaffold uptime checks quickly, generate alert logic in minutes, and set-up dashboards faster than most teams used to schedule the kickoff
James Barnes
March 11, 2026
Buy vs Build in the Age of AI (Part 1)
5 min read AI Has Made Building Monitoring Easy. It Hasn’t Made Owning It Any Easier. A few months ago, I spoke to an engineering manager who proudly told me they had rebuilt their monitoring stack over a long weekend. They’d used AI to scaffold synthetic checks. They’d generated alert logic with dynamic thresholds. They’d then wired everything
James Barnes
March 4, 2026
Alerting Is a Socio-Technical System
3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting
James Barnes
February 25, 2026
Designing Alerts for Action
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
James Barnes
February 18, 2026