Creating a Scalable Marketing Strategy for Motown Records 60th Anniversary

Featuring Contentful, a PWA, and a few Serverless functions

Image for post
Image for post
The Supremes

Universal Records approached me about helping with a year long campaign they were rolling out in support of Motown’s 60th anniversary. If you aren’t familiar, Motown is the storied home of many soul and pop mega stars from the 1960s, including Diana Ross, Stevie Wonder, Marvin Gaye, The Supremes, Smokey Robinson, and much much more. Their original Detroit headquarters was literally nicknamed “Hitsville U.S.A.” As you can imagine, a label with such rich history comes with an unbelievable amount of content to process but I was tasked with figuring out a simple digital avenue we could take and build off of. While pouring through deliverables, I latched on to a doc filled with daily facts about Motown’s history. After 60 years, there were enough interesting moments to fill out a calendar year. Twice. And someone on the Universal team went through and summarized each story into a single sentence or two for social media.

When we think about creating a truly scalable campaign on the web, one that should last the entire year, we must consider the simple foundation on which the campaign sits. It’s impossible to keep the web’s attention longer than a few minutes, let alone a year. However, these daily stories give Motown the opportunity to inject an interesting fact into their communication channels and bring interested users back into the ecosystem. From this solid foundation, Motown can choose to (and they have/will) run more targeted campaigns around major moments from their past.

In this case study, I will cover how we turned a doc full of text stories into an engine that powers some of our digital strategies including and an upcoming Alexa app.

Managing the Content

Image for post
Image for post

A doc full of stories is inspiring but not very useful. Our first task was to get the stories into a system that would allow the client to manage the content and me (a developer) to build digital experiences around them. I was marginally aware of the Headless CMS revolution happening due to my recent work on modern Javascript apps. In general, a Headless CMS is a content management system that is usually hosted by a 3rd party and creates a content repository which can be accessed by a developer via APIs. Sounds promising. One of the best examples of this type of solution is Contentful. Now I can’t remember how I found out about Contentful but I do remember it was their British Museum case study which convinced me to try it here. In a lot of ways, our Motown project was similar to a museum collection. A set of entries with rich associations that help give further context.

Rather than rewriting Contentful’s excellent Getting Started docs, I’ll just share how we approached getting our stories into the system. To do this, we simply created a new content model called Story and gave it two fields: Headline and Date. The headline field stores the story itself and the date field represents exactly when it occurred in Motown’s history. Rather than having someone reenter each of these stories into Contentful, I wrote a basic script that imported a CSV of the stories right into our system using the Contentful API. In just a few moments, all of our stories were in a system the client could manage and accessible via the Contentful Delivery API for any developer to use.

Looking closely at the stories, I decided that creating associations for each data model would allow us to add a richer context to these stories we were sharing. For example, if a story was about a song, wouldn’t it be nice to provide a Spotify and Apple Music link to that song? To do this, we created a new content model called Song and referenced it from the story. Initially, I thought I would simply add two URL fields to the song model for both Spotify and Apple Music. However, I was worried that this would require the client to painstakingly find song URLs from both services and I had a hunch Contentful could do better. As it turns out, I was able to extend Contentful’s UI to build both Apple Music and Spotify searches right into the Contentful interface, greatly increasing the productivity of the client. In addition, instead of storing these songs as URLs, we created a standardized JSON package which bolstered what we knew about each song from each service.

artist: "The Supremes"
artwork: ".../{w}x{h}bb.jpeg"
id: "5277758"
isrc: "USMO10300720"
name: "The Happening"
preview: ".../mzm.vjtspxnb.aac.p.m4a"
url: ".../5277794"

As we began developing solutions around our content, the model expanded to include artists, playlists, and even images. But we only added what we needed, when we needed it. Contentful made this dynamic evolution painless. Happy with our content infrastructure, it was time to put it to work.

Building a Web App

The client and I agreed that a basic start to using this content would be to create a simple web app which surfaced the stories from Motown’s past which happened on this day. A timehop app, if you will. My current web app setup utilizes Vue.js and the Nuxt.js framework. Nuxt has an excellent asyncData method which can integrate with Contentful nicely to pull in our stories.

Once you have the stories readily available, it then comes down to deciding on a user experience. I’m a huge proponent of building off of known interface components so the user immediately feels comfortable when they arrive. While it’s over use in apps has been scorned, Instagram’s fullscreen auto-playing story UX felt like a solid starting point.

Each story would be given it’s own panel and near the top of the screen an animated nav bar would display a clear duration of time between stories. The user can navigate between stories by simply touching the screen on the left or right side. If she needs more time to consume a particular story, she merely needs to touch the screen to pause the auto progress. I ended up using Anime.js and Hammer.js to pull this off.

Thanks to all the associations we created in our content model, each story panel also includes links to stream the song and share the story as an image (more on that later.) I even worked out a function which auto played clips of each song but that would involve breaking a cardinal sin of the web so I turned it off.

We also wanted to add the ability for users to jump to any day of the calendar year so I designed a very simple calendar based on an image the client sent me and then wired it up to the app to filter through the dates.

I love this app. I spent so much time tweaking little bits of the UX and animations so it feels great on your desktop as well as in the palm of your hand. I gotta say, there is something really interesting about a completely custom branded Stories experience and I will likely revisit this again in the future.

Generating Images

The last thing we added to the web app experience was a social image generator so the stories could be easily shared as branded images on Instagram, Twitter, and Facebook. Initially, I created these images using a sweet Serverless function but then decided to simply use HTML5 canvas to save on AWS costs. I’ve covered image generation a few times in the past but I quite like how I handled this solution: creating a dynamically generated image as a Vue component.

One major problem is that HTML5 canvas does not handle text wrapping well (at all) so I leaned on the 2d canvas library Konva to help alleviate this issue. The Vue component includes a single image tag in its template. The source of this image is powered by a dynamic method which uses Konva to create a brand new image using the story and a provided set of dimensions. The composition consists of a background, header text, footer text (and logo,) and then the story itself. Konva’s excellent Text method makes easy work of the wrapped text and ideal margins. Finally, we return the image as a Data URL using Konva’s toDataURL function. I worked out a basic version of the solution first on Codepen, so feel free to check that out if you’re curious about what the code looks like.

Extending to Alexa in Minutes

Happy with our web app solution, the client wondered if we might be able to use Contentful to create an application for Alexa. Now let’s think about this for a second. Neither the client or I had used a content infrastructure before. Nor had either of us built an Alexa app. However, the client immediately understood that now that their content was in Contentful, building something like an Alexa app should be possible, right? Not only is the client already comfortable with their content management system, they are inspired by it.

I quickly did some research on Alexa and was drawn to the Flash Briefing Skill API which connects to a user’s daily routine of asking Alexa for today’s news. How perfect would it be to inject our Motown stories into a user’s daily briefings? After reading the docs, it seemed that all that was required was simply getting our stories from Contentful into the JSON format Alexa expected. Given my familiarity with Serverless, it took minutes to create a new API endpoint which pulled today’s stories from Contentful and returned them in the format Alexa required for a text item.

uid: "3etRbDembv3Hrb3Bi5A0wR",
updateDate: "2019–03–27T14:41:36.651Z",
titleText: "This Day In Motown, March 27th",
mainText: "Taking over from the Beatles' "Eight Days A Week,"…",
redirectionUrl: ""

I then followed Amazon’s steps to create a flash briefing skill, crossed my fingers, spoke to Alexa, and sat back amazed as it recited what happened in Motown’s history today. We’ll be launching this skill to the Alexa marketplace soon so stay tuned.


Image for post
Image for post

Thanks again to the Universal team and Harold Gutierrez for bringing me in on this project. Standing in the face of content overload, I feel like we were able to step back and create a solid foundation for digital concepts which can evolve throughout the year. This is made possible by the incredible advances in content technologies from companies like Contentful and easily integrated thanks to efforts like Vue, Nuxt, and Serverless.

Enjoy the Hits.

Written by

I develop websites for rock 'n' roll bands and get paid in sex and drugs. Previously Silva Artist Management, SoundCloud, and Songkick. Currently: Available

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store