Digital signage can be a great way to extend your organization’s reach, moving your content and your brand beyond the typical website experience. Leveraging the strength of its full-featured CMS against the front-end possibilities of a client-side framework like Ember or AngularJS, Drupal's role in the evolving content ecosystem of the web is becoming more and more prominent. For organizations with an existing Drupal platform, the choice to build Drupal into new content-driven digital experiences is even more compelling.
In this tech talk, Brian Reese, Senior Developer at Acquia, will present a case study along with a few lightweight technical examples of decoupled Drupal and digital signage. We will cover:
-Some of the UI/UX challenges around adapting an existing body of content to a brand new medium
-A simple Drupal web service example
-How JSON API and other strategies can help standardize data from multiple sources
-How decoupled implementations are bringing new possibilities to Drupal applications
Digital Signage is a growing market, and for good reason:
Today’s consumers are more demanding, and their access to information is greater than it has ever been before.
At it’s most basic, the medium is cable of vibrant, dynamic content in prime locations
But the nature of digital signage allows for delivery of the most current and relevant information for a consumer, in ways other marketing experiences simply cannot compete with.
Targeted communication - Well placed (and well timed) messaging can influence buying decisions. Brands can meet consumers at the point of influence, which is often in store for retail
Great medium for increasing brand awareness
Generally represents a powerful communication tool - when used most effectively, it has the ability to not only inform, but engage a target audience.
(Next slide: nike & new balance)
-These kiosks from new balance and nike seek to provide more than just information. They seek to engage their customers, and provide a highly personal and memorable experience.
While digital signage, and the technology behind it, comes in many forms, it’s these types of high-engagement, highly personalized experiences, and how Drupal can help you get there
Agenda:
Brief case study
Where does Drupal fit in
An example (using json API and ember)
- Technical background notes – tie in to the larger idea of headless drupal? Pros/cons of a decoupled architecture?
Project background
My Wife, AF Band
I'm an ex-musician, do a lot of freelance work for musicians...
Project started as a POC that the Band really ended up liking
In some of our initial conversation on the project, we talked a bit about what they'd be looking for from the kiosk (advance)
Checklist
In this casePretty straight forward requirements, without a lot of constraints allowed me to begin with a design and determine the best technical approach afterward
The original POC actually didn’t involve drupal at all, but we quickly discovered the band’s legacy CMS would not be updated to provide the types of services the design required
Pivot to Drupal
The Kiosk’s services, at a high level
This graph attempts to show how and where the various content channels fit in to the kiosk’s design.
(CLICK FOR RED HIGHLIGHT)
Drupal was a drop-in solution to a content management problem
The content management tools Drupal provided out of the box were already a welcome improvement over the client’s own cms
The “content migration” aspect of the project, though initially not planned for, was still manageable and a relatively light lift, thanks in part to feeds
For this project, most of the work on the drupal end was configuration. There was a little bit of code to write to handle the content migration, and the rest was building the custom API
The move from AFPIMS to DRUPAL didn’t involve a lot of rework
In order to start working on the POC for the Kiosk UI, much of the API was already designed and stubbed out before the Drupal phase of the project began
The Drupal project had full control of its fulfillment of that API.
There are contributed modules that make it fairly easy to expose drupal’s content via a RESTful API (one we’ll look at in more detail shortly), but a custom implementation turned out to be a better fit for this project
Cloud-based architecture = easy replication
Originally intended to service a single location within the Concert Band’s performance space, the Band has been able to set up additional units, with very little overhead.
Since it runs in a web browser, there’s very little to configure for each physical machine they add
(TRIGGER ANIMATION) And content is easy to keep up to date and relevant. For the drupal platform, this is the Band’s ability to make personnel and ensemble updates in the CMS. But by and large, the other services the kiosk pulls from are key to keeping its content relevant – The band’s performance schedule, and it’s photos and videos, and social media
Most of the lessons learned were on the javascript application side. However, a few definitely stand out and network connectivity was one of the biggest hurdles faced after launch:
- The kiosk had a pre-determined home, predetermined hardware, and was tested pre-launch in the conditions it was intended for.
- However, given one of the kiosk’s success was it’s portability, it was eventually deployed on tour with members of the band, and one of the tour venues had poor wireless network connectivity, which led to a poor user experience. They were able to switch to a wired connection at the venue, which resolved the issue, but it was not a scenario considered during the kiosks design and development
While this can be true of anything leveraging web technology, it can be especially disruptive to the “app-like” feel we were aiming for.
As a long term solution, we’re looking into Implementing better offline asset management (html5 offline storage)
Demo time
Scenario:
Imagine a local grocery store with a large collection of recipes on its website wants to promote some its recipes in-store. Given the large amount of recipe data already maintained on the store’s drupal website, they’re looking for a solution to leverage their existing platform, while
What is JSON API?
1. The specification
JSON API is an emerging specification for REST APIs in JSON that dubs itself an “anti-bikeshedding tool,”
Using it for this example because of it’s compatibility with Ember and Ember Data (which provides a default jsonapi adapter)
2. The Drupal module
Exposes drupal entites as JSON API resources, with basically no configuration needed out of the box
The module is still in beta
Basic REST API provided out of the box, with the JSON API module gives us REST Resources for both config and content entities. Endpoints are
Basic REST API provided out of the box, with the JSON API module gives us REST Resources for both config and content entities. Endpoints are
Ember uses the handlebars templating engine.
Our route gives us access to our model as the property model, and the curly braces tell handlebars to evaluate our variable rather than print the string directly.
Configure the API endpoint with HOST and NAMESPACE values
We’re also adding the _format=api_json query that the jsonapi serializer requires
Also, since jsonapi represents resource names as type--bundle, and resource paths as type/bundle we make the replacement here whenever the pattern occurs. Likewise, the jsonapi specification calls for dashes instead of underscores (and we’re using underscores in our application), so we make that replacement too for api paths
Here, we’re making similar dash- and underscore_ replacements for model names and attribute keys.
Even though our route will not call them directly, the models for ingredient and file entites are necessary for the application to populate the relationship. Without them, our ingredient and image properties wouldn’t be accessible in our featured—recipe template
While the demo code hardcodes the recipe we want to feature, views could be use to determine featured recipes, based off of popularity on the site, availability of ingredients, or any number of other factors