Working with and coding for the new Display Templates Amazon employs on the Show can seem pretty daunting at first, because it’s such a paradigm shift from the voice-only interactions we’re used to. Having learned from mistakes I’ve made while working on my own new skill, today I’d like to share the epiphany that led me to a much more simplified approach to coding skills for Echo Show.
I’m not gonna bury the lede on this. Here’s the big secret:
After you’ve got your concept nailed down and have a general idea of what the voice interaction model should look like, forget about the Display Templates and write your skill as if the Echo Show doesn’t exist.
It turns out that virtually any pre-existing skill can be updated / upgraded to add Display Templates, and that should tell you something. Specifically, that the presence or absence of Display Templates doesn’t have to—and generally shouldn’t—drive your development process.
For most skills, the Display Templates piece is a nice-to-have, bells and whistles layer that sits on top of your core skill functionality, and can be plugged into the code after you’ve created a high quality voice interactive skill.
Of course you’ll want to think in terms of what the visual element can add to the user experience when coming up with ideas for new skills, but the user who accesses your skill via an Echo or Dot shouldn’t be getting a noticeably inferior interaction for lack of a screen.
The ignore-the-Show take isn’t going to work for video-driven skills, but for every other type of skill it can save a lot of time, wheel-spinning and frustration.
What’s The Problem(s)?
I started out excessively focused on the screen interactions, working backward from my intended screen interactions to the code that would deliver the data to populate the screens. This created problems.
First, I was treating the voice-only user experience as an afterthought. I’d find I had my lovely Display Template pieces coded like elegant puzzle boxes, then have to figuratively rip them up and start over again because I’d neglected to account for something in the voice-only interaction that impacted on data or calculations, which in turn impacted on available content for the Display Templates.
Second, including the Display Template -related code blocks right from the start cluttered everything up. The presence of those optional blocks, which I could just as easily plug in later, made it harder for me to quickly and easily navigate my code and made the whole process much more error-prone. I was scrolling up and down so much, sometimes it seemed like sparks would start flying out of my mouse.
Finally, I was needlessly complicating my core functionality in service to the eventual Display Templates: creating special handlers and loops to populate the Templates, failing to see I could just use the output from functions I’d already created, or would be creating to deliver the voice interactivity.
Once I realized I could plug in the Display Template pieces later, I was freed up to focus on writing the best voice-only version of my skill possible. After that’s done, adding the Display Template support will only make it better.
Write your voice interactive skill first, and make it as good as it can possibly be. Then check out this Alexa Developer blog post from Paul Cutsinger for guidance on enhancing what you’ve already built by adding Display Templates.