Digital Signage Demo - Dashboard & SDK
- 1 Overview
- 2 Gumband for Operators
- 2.1 Exhibit Health
- 2.1.1 Connection Status
- 2.1.2 Operating Mode
- 2.1.3 Statuses, Controls, and Logs
- 2.2 Exhibit Content
- 2.2.1 Settings and File Management
- 2.2.2 Scheduling
- 2.3 Exhibit Analytics
- 2.3.1 Reporting
- 2.1 Exhibit Health
- 3 Gumband for Developers
- 3.1 Developer Benefit
- 3.2 Example Files
- 3.3 System Architecture
- 3.4 SDK Integration
- 3.4.1 Authentication
- 3.4.2 Manifest
- 3.4.3 Real-time Callbacks
Overview
The Digital Signage Demo simulates retail or office signage developed as a custom web application. It cycles through an interface of three screens, each with customizable copy and images through Gumband. The signage demo also leverages Gumband’s real-time signals, analytics, and logging.
View the out-of-the-box experience below:
Gumband for Operators
Exhibit operators can use the Gumband web dashboard to manage the exhibit without a deep technical understanding of the custom application. The platform exposes the custom app’s health, content, and metrics to allow for simple long-term management and updatability without developer involvement.
Operators can work with their development teams to run the example project linked below to try the digital signage demo live. Contact support@gumband.com for platform access.
To access the web dashboard, open https://app.gumband.com in a web browser and log in. Users can either sign in via a Google account (which will automatically create an account if necessary), or use the “Create an account” link to sign up with other email addresses.
Exhibit Health
It’s critical to exhibit success to understand if the system is functional on a day-to-day basis. Gumband surfaces real-time notifications when it detects an outage from the exhibit, and offers basic control and debugging capabilities to get the exhibit back into a functional state.
Connection Status
Gumband monitors a system's critical components to understand its overall health. If the exhibit goes offline at any point, Gumband will notify the operators to begin triaging. The following videos show an exhibit coming online and offline, both causing an email notification - notice the change in the online and offline indicators ( → ).
Operating Mode
The exhibit operating mode is used to toggle exhibits “on” and “off” - the definition of which changes depending on the specific custom application. Developers are able to use this signal to put the exhibits into standby - increasing operational understanding of the exhibits while also increasing energy efficiency and reducing noise pollution (among other benefits).
For the digital signage demo, the operating mode is used to toggle the exhibit between display-on and display-off.
Statuses, Controls, and Logs
Gumband offers other tools to interact with an exhibit and understand how it is functioning. These tools allow operators a layer of visibility and control into the custom applications in order to maintain the exhibits and debug issues without developer involvement.
Statuses
The exhibit can push signals to the UI, known as statuses, to surface pertinent system information to operators. These appear on the “Overview” tab for an exhibit within the “Status” section. For the digital signage demo, the following statuses are exposed:
Last Server Start - The date/time that the digital signage custom application was last started
Access URL- A link to the digital signage UI
Note: this only works when a developer is running the exhibit locally
Exhibit Docs - A link to the exhibit documentation for easy operator access (especially in the case where documentation links vary exhibit-by-exhibit)
Active Pages Open - The number of web pages actively displaying the digital signage UI
Note: this status will display “0 (warning!)” when there are no active connections, meaning that the signage is not showing anywhere)
Controls
The developer can also expose “hooks” into the exhibit systems, known as controls, for the operator to trigger various actions via the product UI. For the digital signage demo, the following controls are exposed:
Reboot Exhibit - Reboot the computer that the application is running on
Note: this is a placeholder and would need to be implemented by the developed depending on the specific setup of that system
Reload Pages - Reload any active frontend web browsers
Toggle Takeover - Toggle the active takeover mode (which is itself an exhibit setting)
Logging
Developers can use the Gumband logging utility to forward select application logs to the product which can be used to better understand typical exhibit operation and in debugging scenarios. The digital signage demo includes logging when the server is started, and when pages are connected and load the UI.
Exhibit Content
Over time, exhibit content can get stale or irrelevant to the new initiatives of the brand. Gumband offers real-time and scheduled content management capabilities to ensure an exhibit can be managed long-term without needed code updates to the system. Content updates can scale with the number of exhibits in an organization, so you’re able to make a single update in the web UI and apply to a fleet of exhibits.
Settings and File Management
Gumband exposes the copy and media assets through a simple web UI to allow operators to update the user experience over time.
Settings
Exhibits will have a number of pre-configured settings which can be adjusted over the life of the exhibit to alter visual or functional aspects of an exhibit. These settings have details and constraints to allow operators to manage the state of the exhibit long-term. These appear on the “Settings” tab within the Gumband exhibit interface. For the digital signage demo, the following statuses are exposed:
Gumband exposes the interface and underlying infrastructure to enable settings, however the actual implementation of that setting is left to developers - meaning that settings need to be clearly defined and properly implemented to expose the most value.
For the digital signage demo, the following settings are exposed:
Slide X: Header Copy - (type: Text) - The displayed header copy for slide X; will not wrap
Note: A design decision was made during development to use vertical pipes (“|”) across the slide Text settings to allow for line breaks; this could have been implemented in a number of different ways
Slide X: Page Copy - (type: Text) - The displayed page copy for slide X; will wrap
Note: The string “break” can be used to create line breaks within page copy (in addition to the vertical pipes noted above)
Slide X: Image - (type: File) - The displayed image asset for slide X; displayed at the bottom at full screen width
Note: These options are driven based on available files in the “Files” tab of exhibit interface
Takeover Enabled - (type: Toggle) - Whether or not the signage should display a fullscreen takeover image
Takeover Image - (type: File) - The displayed image asset for when the fullscreen takeover is enabled
File Management
Operators can manage file assets that are synced with the exhibit, which are leveraged in the custom application to change visual or operational parts of the exhibit.
Scheduling
Gumband offers a calendar where settings and controls can be scheduled to manage planned updates to an exhibit over time. Events can either be created on a one-off or recurring basis. When an a scheduled event runs, it will apply only the selected real-time signals from the event configuration and will leave the others as they are currently set.
Exhibit Analytics
Exhibit engagement and operational measurement is typically difficult to gather across the breadth and depth of these kinds of custom software and hardware systems. Gumband offers hooks at all layers in the system to surface analytics which allow the operational to make informed decisions around future content updates and investment in these types of initiatives.
Reporting
Gumband has been configured to display operational analytics for the digital signage demo - such as “Server Starts” and “Reloads”. For an exhibit with active user interactions, those data points could also be reported to analyze analytics like session duration, content choice popularity, and exhibit UX attrition.
Gumband for Developers
Developer Benefit
Gumband makes it easy to expose select parts of a complex technical system to non-technical operators in order to increase exhibit serviceability and maintenance (reducing support headaches 🙂). Gumband also offers tools for developers to increase development velocity and improve system testing and insights.
Example Files
Attached is the Digital Signage Demo project files. It contains a React.js frontend which can be loaded in a web browser and a Node.js backend that is integrated with the Gumband SDK.
System Architecture
Note: Gumband Hardware is not demonstrated in this project.
SDK Integration
Developers can leverage the publicly available Gumband SDKs and APIs to integrate the platform modules - health, content, and analytics - into their custom projects. The Gumband Node.js SDK is available through npm, and the digital signage demo leverages it to offer the outlined functionality in this guide.
The Gumband SDK is concentrated in the file gb-backend/GumbandSdk.js
. The SDK is initialized on line 22
, setting the API params and file sync content location, and disabling hardware communication.
this.gb = new Gumband(token, id, 'manifest.json', {
endpoint: env,
version: 'v1',
contentLocation,
gbttEnabled: false,
});
Authentication
The SDK uses an exhibit ID and token to authenticate with the Gumband platform. Notice the ID and token passed into the SDK constructor above.
You can view the exhibit ID and generate new tokens on the “Auth” tab of the exhibit. Auth tokens are only shown once in the dashboard to ensure exhibit security. Ensure you keep your tokens private.
Manifest
The SDK uses a JSON configuration file called the manifest to identify the real-time signals (statuses, settings, and controls) that are available for an exhibit. Notice the filename manifest.json
is passed into the SDK constructor above.
The manifest.json
file is structured as follows, and can include any number of real-time signals.
{
"manifest": {
"statuses": [],
"controls": [],
"settings": []
}
}
For all real-time signals, the id
of each signal is used to associate them in code to implement the desired action.
Statuses
Statuses are used to surface relevant details of the system to operators. These are shown as strings (potentially links) in the dashboard. Notice that you can set the display
copy and order
for the label in the dashboard and a default
value. All statuses have type String
.
The statuses for the digital signage are as follows:
{
"id": "last_server_start",
"type": "String",
"display": "Last Server Start",
"default": "(not set)",
"order": 0
},
{
"id": "access_url",
"type": "String",
"display": "Access URL",
"order": 1
},
{
"id": "docs",
"type": "String",
"display": "Exhibit Docs",
"order": 2,
"default": "https://deeplocal.atlassian.net/wiki/spaces/GUM/pages/92995599/Gumband+Digital+Signage+Demo"
},
{
"id": "num_ws_connections",
"type": "String",
"display": "Active Pages Open",
"order": 3,
"default": "0 (warning!)"
}
Controls
Controls are hooks into the exhibit that are exposed on the dashboard to allow operators to trigger actions on the system. These actions can include reboots/restarts/resets, advancing the UX for testing, or other things tailored to the specific experience. Notice that you can set the display
copy and order
for the label in the dashboard. Controls can have a few types
, view the options in the Node.js SDK README.
The controls for the digital signage are as follows:
Settings
Settings are the configurable state of an exhibit that operators can use to manipulate the system in the desired ways. These settings are always tailored to the specific experience, and can include things like active in-UX content and system volume or timeout duration. Notice that you can set the display
copy and order
for the label in the dashboard and a default
value. Settings can have a many types
, view the options in the Node.js SDK README.
The settings for the digital signage are as follows:
Real-time Callbacks
The SDK automatically manages the connection with the Gumband platform and exposes real-time callbacks for the developer to respond actions performed by operators or automatically through the platform. The callbacks use the signal id
to determine what action to perform, and then the developer implements the relevant functionality. You can see the full list of the callbacks in the Node.js SDK README.
The callbacks are registered in the SDK constructor on line 29
.
A simplified version of the control callback is as follows:
A simplified version of the setting callback is as follows: