First Thoughts on Alexa Skill Flow Builder (SFB)

The Amazon team recently announced (at VOICE Summit, I believe) the release of a new tool for building flow-based skills, called the Skill Flow Builder (SFB). The SFB is both an application and a manner for building skills that follow a given flow. The prime use for the SFB is a story-based skill where a user will move from scene to scene. I’ve been using the SFB for a few weeks, and here are my initial thoughts.

From a Business Perspective

Before I used the SFB, I considered building a small framework to achieve the same purpose. I thought about a series of markdown files that non-devs could edit, and a build step that would assemble everything together. I thought about this because there are existing products unaffiliated with Amazon that provide a drag-and-drop builder, but are either hamstrung in a bid to be user-friendly or are outrageously expensive. (Or both.)

I can only wonder how much sleep the people at these companies have lost since checking out the SFB. Amazon has come in and built a competing product, giving it to everyone for free. True, (some) of the other products build cross-platform voice applications, but Alexa is still the platform that companies look at first unless they have a specific reason. (As an aside, don’t ignore how much “we don’t trust Amazon” is as a reason for companies in certain verticals.) If I’m a PM at a Fortune 500 company, why am I going through the procurement process to use one of these other providers, when Amazon will help me set up for free? If I’m a “person in a garage” with an idea, I couldn’t afford those tools anyway, but I won’t go looking at them when my idea takes off because I’m already comfortable with SFB.

How wise is Amazon for competing with third-party tools? A strong ecosystem of tool builders is necessary for any technology or platform to expand. Mobile apps would be nowhere without the pick-axe suppliers, and Facebook and Twitter really grew on the back of developers who built for those platforms. However, both of these are instructive. Apple and Google open up to third-party tool builders, but they also provide their own tooling where they think necessary. Third-party tools instead will slot into other areas. For example, the tool builders can solve needs that are incredibly important for some people, and completely unneccessary for others. Conversely, the tool builders can create tools that do the same thing as the first-party tools, but with a different approach. The creation of first-party tools does not necessarily shut the door to third-party builders entirely, especially in a dev-driven environment.

Twitter, meanwhile, has shut off API access for most of those same developers who helped grow the platform. Still, Twitter continues to grow now not because of a lack of apps built on top of the platform, but because of the content on it. I feel that voice apps are more like mobile apps than tweets, but we still need to remember that the platform lives or dies based on what users can consume. Third-party tools can make it easier or harder to create the content, but users aren’t coming to Alexa because Alexa has a vibrant dev community.

On the competitive side, Google is again lagging behind Alexa. Google did announce tooling to make the creation of certain Actions easier, such as How-Tos via Google sheets. Still, Google has no development environment like the SFB, and Dialogflow is not easy for novices to understand. I would expect Google to take this seriously, and I think you’ll see them release something similar to ease Action creation.

From a Dev Perspective

This blog is primarily for developers, and the SFB is primarily… not. The SFB is there for content creators and VUX designers. Nonetheless, there is a place for developers here, and there are areas where the SFB can go much, much beyond a simple flowchart builder that needs a developer to come in. (Again, this “much, much beyond” should be another lightning strike outside the windows of those third-party tools.)

I should get a small complaint out immediately: I wanted a Linux version of the SFB application, but it only works on Windows and Mac. There will be about three others of you that also have that complaint.

First, there are the areas where a team building a skill won’t need a developer. Thanks to the IDE, non-technical members of the team can easily add content, as if they were filling out a series of forms. This is probably the central piece of the SFB and where most non-technical people will be most often.

Yet the SFB also creates a simple language for technically inclined non-developers to do things that would have otherwise fallen to developers. For example, the SFB makes the creation of variables and the use of conditionals simple for non-devs. Take this example, from the official Amazon docs:

    *then
        if not enraged {
            increase fear by 2
        }
        if fear is greater than 10 {
            -> fear warning
        }
        -> next room

This is simple enough for nearly anyone to understand. fear is a variable and what happens is dependent on the value of that variable. Of course, there have been other “plain English” programming attempts that have failed and this one could, too. However, what I think is different here is that natural language isn’t required for everything. When things become too complex, developers can step in with extensions.

Extensions are a way for developers to write code that extend that the SFB can do. For example, there are built-in extensions that will roll a die to empower randomization, or will save the current time to a variable.

Developers can write three types of extensions:

ImporterExtension Those that run when the SFB imports the content
DriverExtension Those that run either before or after a request is handled
InstructionExtension Those that run from within the instructions (the content)

I haven’t yet had a need for the ImporterExtension. The SFB has localization and easy snippet creation, so I haven’t gotten to a situation where I need to edit either the source or output content.

My primary use for extensions so far has been for analytics. The SFB runs everything through a single intent, and as a result you are lacking a lot of analytics inside the Alexa dashboard. In order to still track how users are moving through the flow, I used an InstructionExtension that runs before every single step automatically (using a global append instruction). This approach works but has one major problem: I could find no way to get the user ID that comes in through the request. This is a huge oversight and something that I hope the SFB team adds soon.

I’m confident that most of the extensions I write will be of the InstructionExtension variety. The example that the Amazon team provides is an extension that returns the day of the week in natural language. This kind of behavior, or reaching out to an API, will be useful when the situation demands it.

Another small problem that follows the SFB from normal skill development is deployment. I was shocked to see that content creators were unable to deploy a skill from the SFB application. Instead, that deployment falls to developers and requires the same futzing around with AWS IAM permissions. Indeed, even building the skill from the flow chart must be done by a developer. That process also comes with its own annoyances, as I found it difficult (or perhaps impossible) to safely edit the code output that was built by the SFB. This got in my way a lot when I wanted to run some tests locally, especially due to how the SFB compiled some of the code inside the primary entry point.

Still, outside of compiling and deploying, content creators are going to be very happy with the SFB and how much they can do inside of it.

From a Content Creator Perspective

Content creators and VUX designers will enjoy the SFB, because it provides them with a tool to contribute directly to the skill creation. When developers are building the skill entirely and content creators are relegated to storing content in spreadsheets, teams become significantly less efficient. Instead, the SFB is saying that content creators can be responsible for the content, and devs can be responsible for the code.

The SFB helps collaboration, but with a significant caveat. Ultimately, the SFB editor creates text file, and those text files can be shared between team members. To share the files, though, the content creators need to be comfortable with version control (or share files via email back and forth, but…). Now, is git that difficult for people to pick up these days? No, not really. Should everyone who contribute to producing software learn at least how to use the git GUI? Yes. But it is still a limitation.

The SFB also benefits content creators focused on localization. The editor makes it easy to update strings based on locale. The hardest part of localization—having the experience with multiple languages and locales—still remains a challenge, the SFB reduces the friction of the practical applications.

Finally, I am interested in the SFB because of the paradigm it pushes: flow-chart based skills. This is interesting as a counter to what Paul Cutsinger of Amazon has recently been pushing, which is a move away from that approach, and a move toward situational design that lets users jump in and out of certain “frames” at any time. Amazon and Paul would probably say that you use either in diffierent situations, but it must be tough to push for situational design when your company is also pushing tools that do the opposite.

Overall, I’m very impressed with the SFB. I won’t use it for all of my skills, but for certain narrative-based projects I won’t use anything else.