← The Naistro work02 / NAISTRO · CONTRIBUTION

The right notice for each player.

Deliver useful guidance to the appropriate devices.

Where this work fits

An operator might need to pause several players or change a venue’s volume. Some devices could be connected while another was unavailable. A dashboard needed to make that situation understandable.

MY CONTRIBUTION

I built targeted player-notification behavior for different platforms and software versions. This helped clients receive messages and actions appropriate to the device they were running.

THE IDEA, ILLUSTRATED

Schedule a tailored message across channels

TAILORED. SCHEDULED. DELIVERED.

9:41•••

YOUR INBOX

CUSTOMER UPDATE

Your notifications, in one place.

Delivered messages stay available to revisit.

Unread · saved in your inbox

Customer activity shapes the message and timing. Email and push deliver it, while the inbox keeps it available to revisit.

THE ENGINEERING DECISION

A group command can have mixed results.

One unavailable device should not erase successful sends to the others. I returned per-operation delivery results and worked on aging connection state so a disconnected player would not look active indefinitely. A sent command still needed to be distinguished from observed playback.

The skills behind the work

Version compatibility: Adapt behavior to the capabilities of different client versions.
Scheduled jobs: Run time-based work without waiting for a person to open the application.
Data modeling: Give different product concepts clear records and relationships so updates have predictable meaning.

THE WIDER RESULT

Operators could control players remotely and see more useful information about their availability. The backend supported venue-level actions without treating the entire fleet as one device.

READ THIS IN CONTEXTI connected dashboard controls to the players in each venue. →

Related contributions

Remote controls with per-device resultsI built WebSocket playback controls for individual players and groups of devices in a venue. A group operation could reach some devices while another was unavailable, so its result needed to preserve that distinction instead of returning one blanket success.Device status that ages with the connectionI worked on device heartbeats, reconnection state, and cleanup of stale connections. The fleet view needed to stop treating an old connection as an active player while retaining useful device context when it reconnected.A venue view shaped by responsibilityI worked on authentication and role-aware access to venue resources. Establishing who someone is and deciding which locations or devices they may access are related but different responsibilities.Product guides the team could maintainI built backend operations for ordered guide steps and editable content. Reordering used a transaction so related positions changed together, while loading defaults checked for existing steps to avoid adding them twice.