Palm Beach Broadcasting, LLC
Marketing, Sports and Entertainment
Palm Beach Broadcasting, LLC owns and operates radio stations in Palm Beach County.
The company broadcasts music and entertainment, as well as information on local news, traffic, and weather.
It also offers listeners and advertisers with local marketing resources, as well as provides advertising and marketing opportunities.
The company was founded in 2002 and is based in West Palm Beach, Florida. Palm Beach Broadcasting, LLC operates as a subsidiary of Digity, LLC.
One thing all the radio stations owned by PBB does is event marketing; often in the parking lots of country music concerts and other similar type events.
The common thread among these venues is the volume of foot traffic, which often renders cell data useless.
This presented a problem for PBB which wanted to collect email addresses for marketing purposes electronically, but had no way to save them.
Instead, they reverted to pen and paper signup forms, which were difficult to read and required manual entry after the event; not to mention they were not environmentally friendly.
Gunner Technology rep encountered a PBB-owned station doing this at a concert and proposed a solution, which was to build an offline-capable app which could run on any Android or iOS device (phone or tablet).
The device would store the data on the physical device until it could get data reception and then it would sync the data to a central repository where all their marketing emails were kept.
Fortunately, AWS AppSync makes most of the nitty-gritty of this very easy. The one challenge was building the app so that it could be skinned by an administrator quickly and without an account.
At any given event, the promotion may be co-branded, so the radio station may need to re-skin the app to include the logo of the other company and potentially change the opt-in text.
This project was tailored for AWS AppSyc.
AWS AppSync automatically updates the data in web and mobile applications in real time, and updates data for offline users as soon as they reconnect. AWS AppSync makes it easy to build collaborative mobile and web applications that deliver responsive, collaborative user experiences.
AppSync let us specify the data requirements of the application with simple code statements and iterate quickly during the prototyping and development process.
AppSync uses GraphQL, an open standard query language that makes it easy for applications to request data from the cloud.
AppSync automatically manages all the data operations for offline users. The service supports an offline programming model where application data is not only available for users who are offline, but users can also add and update app data locally as well. This makes it easy to build apps that cache important data locally for offline use, and then synchronize with the cloud when the device reconnects.
The service integrates with Amazon Cognito and AWS Identity and Access Management, allowing us to set fine-grained permissions on GraphQL operations that put strict controls on who can access the data.
AppSync makes it easy to combine data from different sources. With AppSync, we could access data in Amazon DynamoDB, trigger AWS Lambda functions, or run Amazon Elasticsearch queries and combine data from these services to provide the exact data we needed.
We started out with nothing (no mocks, no wireframes, etc), so we started with two research sprints.
This was followed by two design sprints in which we mocked out the UI.
However, instead of using design tools like Photoshop, we did it using React with mock data.
After we had a UI we began our usual pattern:
1) One week function sprint where we added new functionality
2) One week QA sprint
3) One week bug fix sprint
Repeat until finished.
This was absolutely necessary due to the shifting requirements and scope mentioned in the challenges section.
Lisa Brignac – Project Manager
Keith Cohn – Designer
Cody Swann – Front-end Engineer
Dary Merckens – Backend Engineer
This was an extremely compressed deadline, so we learned the importance of streamlined deployments which is why this is the first project we integrated Fastlane with Fabric and Testflight for automated builds and deploys to QA.
PBB has deployed the app to all of their radio stations and has been able to save roughly 10 hours a week they previously spent on data entry.
Additionally, they save roughly $200 per event on print costs and have reduced their carbon footprint significantly.
PBB didn’t even know this was possible until Gunner suggested it, so we had a pretty good inside track to getting the gig.
That said, we had done similar work in marketing for Country Shore so we had some case studies to show PBB as illustrations
A component that runs the GraphQL engine for processing requests and mapping them to logical functions for data operations or triggers. The data resolution process performs a batching process (called the Data Loader) to your data sources. This component also manages conflict detection and resolution strategies.
AWS AppSync supports the three GraphQL operations: query (read-only fetch), mutation (write followed by a fetch), and subscription (long-lived requests that receive data in response to events).
There is one action that AWS AppSync defines. This action is a notification to connected subscribers, which is the result of a mutation. Clients become subscribers through a handshake process following a GraphQL subscription.
A persistent storage system or a trigger, along with credentials for accessing that system or trigger. Your application state is managed by the system or trigger defined in a data source.
A function that converts the GraphQL payload to the underlying storage system protocol and executes if the caller is authorized to invoke it. Resolvers are comprised of request and response mapping templates, which contain transformation and execution logic.
A representation of the caller based on a set of credentials, which must be sent along with every request to the GraphQL proxy. It includes permissions to invoke resolvers. Identity information is also passed as context to a resolver and the conflict handler to perform additional checks.
The location where GraphQL operations are defined. The client performs appropriate authorization wrapping of request statements before submitting to the GraphQL proxy. Responses are persisted in an offline store and mutations are made in a write-through pattern.