 Hello, this is Get Started with Voice User Interfaces. My name is Amber Matz. I'm the production manager and a trainer at DrupalizeMe, and you can find me on Twitter, especially if you're nice, at Amberheim's Matz. At DrupalizeMe, we provide online tutorials in both written and video formats. Our goal is to be the number one source of Drupal 8 training anywhere. I just want to give a little plug because they're the reason that I'm able to come to events like this. In today's episode, first I'm going to start out with a survey of several voice UI platforms, which should give you a good idea of what opportunities exist for you as a developer and which platform you might want to start out learning. Next, I'll present some ideas you want to consider as you go through the voice UI design process. And even though there are multiple voice UI platforms out there, they share common concepts in their APIs. Specifically taking from api.ai and Alexa's implementations, we'll look at concepts and terminology in voice UI development that you'll want to know and understand. And I'll talk about endpoint fulfillment with a lean toward Drupal integration, since we are at Drupalcon. And finally, I've got a few quick fun demos to show you, and then we should have time for questions. By the end of this session, you should have some direction on which UI voice platform you want to start learning. And you'll have a head start on understanding the overall process and important concepts. Basically, getting over that hump when you are looking into documentation and tutorials and like, okay, what is this? And just getting over that initial kind of knowledge and understanding so that you can just dive right in. So you'll get a head start on the major concepts and process of voice UI implementation, no matter which platform you decide to learn. This talk is geared toward developers who want to know how to add voice to their applications. The actual implementation of a voice UI requires an intermediate web or app developer background, which here means the ability to copy and paste example code and modify it to your needs and follow directions in a tutorial. So it's not too hard to get started. Basically, in essence, you are standard nerds. So welcome and thank you for coming. The voice UI development is really quite an accessible process and the companies that are involved with this are eager to make it relatively easy for developers to add voice to their projects. So let's get started. I've got a lot to tell you about today. The emerging players in this space are Alexa, Google, API.ai, Cortana, and Siri, but that's not all of them. Those are just the major ones. Let's start out with Alexa. The purpose of Alexa, it lets you build custom voice skills, that's their word, for Alexa-enabled devices or integrate Alexa into your connected product. The company behind it is Amazon, and the hosting options include AWS Lambda or any Internet accessible endpoint. The devices that Alexa skills support are any device in the Echo family. The Kindle Fire is coming with Alexa-enabled and any other Alexa-enabled connected device, so one that you might build yourself or any other one. The custom-skilled app distribution happens in the Alexa store. The end user installs it via the Alexa app, so it's something that the end user needs to install and enable for their device. Localization and language support includes there are only three region and language combinations that are supported with Alexa, and that's English in the US, English in the UK, or German in Germany. The state of developer support, as I've experienced it, there's a very nice skill-building UI. There are docs, code samples, there's an Alexa GitHub account, an API reference. There are videos that will walk you through step-by-step how to use the UI as well as concepts that you should know about. There's a variety of SDKs in a variety of different languages, and overall I felt like it was a positive testing and publishing experience. You can find out more about building an Alexa skill at developer.amazon.com slash Alexa. There's also a new thing called the Alexa voice service, and so you can see the URL there if you want to learn more about Alexa's voice service. And that's adding Alexa to your connected device. So more, it's a different type of implementation. Next, we have the Google Assistant and Actions on Google, which are related in that Google Actions let you build apps for the Google Assistant. So the Google Assistant is going to hear the request from the user, and if the user requests to hear from a specific UI, they're going to pass that request to your app, and then your app will handle the conversation until they're done and it passes it back to the Google Assistant. Obviously, the company behind it is Google. The hosting options are cloud functions for Firebase, which, these first two, the Google Cloud and the Firebase are both kind of the easiest path to get started. That's what's included in the tutorials, but any internet accessibility endpoint, you'll see that is a common theme throughout all of these platforms. These apps will work with the Google Home device and any Google Assistant enabled device. So any device that has Google Assistant on it will, your app will potentially be available on it, depending on language and region configurations of the user. The app distribution is different than Alexis. It's automatically distributed to Google Assistant enabled devices. The user doesn't have to install or isn't even given the option of installing or enabling a specific app, so it's just automatically pushed out to any relevant user. The localization and language support is kind of hard to pin down. It's really dependent on the user's regional settings. There's a lot of complaining in the forums about not being able to use Google Assistant in more than one language and or region, so there's that kind of muddy water. But if you use api.ai to build your agent, then there are 15 languages supported, which are these listed here. So this is a lot, potentially a lot broader support than what you might have with Alexa. The state of developer support, they are eager to get developers on board with them, same with Amazon. They have an agent-building UI, which is through api.ai, which I will get to in a minute. And api.ai's console is excellent. As you might expect, they have docs, code samples, they also have a GitHub account with code examples, for your endpoint development, links to API references, and plenty of SDKs. There are video walkthroughs and concept tutorials. And like I said, a variety of SDKs, tools for building out your voice UI and hosting options. And via the api.ai console, there is in-app as you go testing, which is really nice, as well as endpoint fulfillment testing. So you can find out more at developers.google.com slash actions, which is where I would recommend that you start. And you can find out more about the Google Assistant SDKs at developers.google.com slash assistant slash SDK. But I would start with actions on Google, which looks like that. Right now, today, the other day, when I made that screenshot. All right, api.ai, its purpose is to build a unified API and UI to build conversational voice or chatbot apps and deploy that to one or many platforms. So they want to solve this problem of, okay, this space is emerging, there's lots of companies jumping in, let's build a platform companies jumping in, let's build a unified API that people can use, build their UI, their agent, as their term is, once, and then you could deploy that to any number of platforms. Google recently acquired them in 2016. So the tutorials on actions on Google are going to reference api.ai and vice versa. So you're going to find the easiest path to get started with actions on Google or api.ai is to use those two platforms in tandem, but you're not limited to that. That's a good way to get started. I would say it's just as easy to get started with actions on Google and api.ai as it is to get started with building an Alexa skill. Same kind of level of UI and tools and documentation. I would say if you want to get started, you can use those two. The hosting and app distribution depends on the integration, like what your final point is where you're going to push that out to. And the integrations are many. There is actions on Google, Facebook Messenger, Kick, Line, Skype, Slack, Cisco Spark, Telegram, Cisco, Tropo, Twilio, Twilio IP, Twitter and Viber. Half of these I've never even heard of before. There are lots of options, not just voice, but also chatbot. Api.ai says on their docs, voice interface is cross-platform. Your agent will understand your users no matter what device you're using. You design the interaction scenarios just once. Currently we have SDKs for all most popular platforms and more to come. So they're really looking to become the leader in voice UI development and really simplify the process of whether you're doing a chatbot implementation or you want to add voice to that. They're trying to make that a simpler process, more streamlined. And the localization and language support depends on your integration, but like I mentioned before on the actions on Google, 15 languages are supported and when you first create your agent, you'll select a language so you will need to create an agent for each language you want to support. So which is, it makes sense because if you had a multilingual site, for example, you can set up endpoints at the different languages that you're supporting for each of your agents. So all else being equal and you can also set up responses that are particular to a certain language. So there are 15 languages supported at this time. And from what I read, one of the areas multilingual support in voice, it's a really, like, of course there needs to be multilingual support. We're talking about conversational interfaces and people speak in many, many different languages, certainly not limited to these 15. And so this is just what the state is right now. And I think we can look to see this grow over the, you know, in the coming years here. The state of developer support there is a very good agent building UI. I even like it better than the Alexa UI. There's docs, samples and API reference. Sometimes that kicks back to the actions on Google, but they still have a good set of documentation just on their own and an excellent API reference. And there are videos, but that's again via Google Actions. And a variety of SDKs supporting a number of languages. So you don't have to be a node expert. There's even a PHP SDK which I'll talk about later. And as I mentioned, the in-app testing is really nice to have. Because you don't have to finish everything and then, you know, and wait until you're pretty much done before testing. You can test as you go and really that's an encouragement to do that. And they show you how to do that in the tutorials. So it just makes the process a lot easier and it helps you as you're testing understand what it is that you're actually doing. Because a lot of us haven't done voice UI building before and it's like, what am I doing here? How is this going to work? So the testing in the interface is really nice. So you can find out more at api.ai and go to slash docs slash SDKs to see which software is currently supported. And then you'll notice there is this relationship, this tight relationship between Google actions. And so you can also find tutorials on the actions on Google site that walk through the api.ai user interface. I wanted to also mention Cortana. Cortana's purpose is to add voice, i.e. Cortana. Whoa, stop. So weird. That is why I'm not buying their service. Add voice, Cortana and cognitive intelligence to, and this is the catch, an existing bot built on the Microsoft bot framework. Is anyone here building bots on the Microsoft bot framework? I didn't think so. Which is why I'm just going to keep moving on here. Hosting options are Azure, or if you're really fancy Azure, I don't really know how they're saying that. Or any Internet accessible endpoint. And the devices supported are Windows 10, Android, iOS and this new fancy thing called the Harman Cardon Invoke. So that's a new thing that's coming out like now, I guess. So it's another headless device and so that's going to be the Cortana one. App distribution is via Bing. I'm just going to leave it at that. And the localization and language support, they say Cortana is optimized for specific language and market pairings. She works best when your region and language settings are aligned, obviously. But I will say that there are, there's a nice combination of language and regions supported here and there's some outliers, you know, there's some differences between what's supported with API.ai even. So I think that you know, there might be a use case here. Client, you know, is in a certain market and you need to support Windows, then I feel like it's a valid thing. However, I will tell you that right now the state of developer support it's in public preview. So, which means it's very limited and it's limited to adding voice to a bot built on Microsoft's bot framework. So there's kind of yeah, I'm just going to leave it at that. So that's just an FYI for you and you can find out more in the developer Microsoft site. Finally, Siri. I just want to let you know about Siri. There's Siri kit which enables your iOS apps and watch OS apps to work with Siri. And then there's HomeKit because voice is really applicable especially to you know, in the home, right? It's the whole problem of someone is sitting on their couch and they don't want to get up and do something, they want to do something. So, really the HomeKit stuff is relevant for that. Obviously, Apple's behind it and the reason why I'm mentioning it to you today, just briefly, is that they've recently announced HomePod which is their headless device. So, HomePod will have more people querying Siri. Okay, so if you want to get into if you are an Apple developer or if you are thinking about getting into that sort of thing just know that there is Siri kit and HomeKit and there's going to be this HomePod device so there might be some opportunities there. I don't really know the extent of the localization and language support although I did find out that the HomePod is only supported in English, in the US, UK and Australia. So, there you go. If you want to find out more you can go there. There are some open source options and perhaps some remits in not talking more about them. Mycroft and Jasper sound like really interesting things to talk about and they sound like great topics for a future presentation but I'm not going to cover them today. Designing a voice user interface or a conversational app is a new experience for many of us. So, first let's take a look at what we can learn about normal human conversations with some conversation basics. We take turns in conversations based on subtle cues that often include non-verbal conversation. So, how can we design human computer conversation that makes it clear whose turn it is to talk? How do we program? No, you go. How do we do that? As we converse, we keep track and we weave together all elements of a conversation including the context. Taking words and phrases out of context is a classic way to introduce misunderstanding. So, how do we design a conversation that will keep track of what's being said without getting lost and without making people feel like what's being said is just over their head? Human conversation is naturally efficient. We often read between the lines and leave certain things unspoken. This is often dependent on trust and the nature of the relationship between the people talking. How do we compensate for our human tendency to leave things unspoken in code? We use different phrases to mean the same thing all of the time. The context and state of the conversation often influences our response. If we're talking to a person in authority and we're in trouble, we might give an affirmative response using more formal language such as yes, sir. Whereas if a co-worker asks us if we can do something or do a favor for them, we might reply, you bet. And they're saying the same thing, but we're saying it completely differently. So, how can our app learn about all the different ways our user might respond without getting confused? Humans can usually spot and repair mistakes or misunderstanding in a conversation. So, how can we allow for that and allow for and program for correction and conversation repair without returning a lazy, invalid response or other and graceful error? How can we design conversations that can get back on track? Like, is there an anyway function? A voice user interface should try and follow the rules of cooperative conversation. A set of principles popularized by linguistics professor Paul Grice and should try to follow these basic rules. Be truthful, be informative, be relevant, be as clear as possible. In short, develop a killer voice UI, just not literally. Well, it's fine to start out with a few contrived examples to learn the process, which I certainly have done. To become a really excellent voice UI designer, you want to choose projects where adding voice will make the task faster, easier, or more fun. We're not here to make people's lives more cumbersome, tedious, or downright miserable, are we? So what's faster? Setting a timer by walking over the microwave and setting it or saying Alexa, set a timer for three minutes from anywhere in the room. Thinking about making a task easier, think about how someone might usually perform a task with their hands and needing to view a screen. How might that task be made easier through a voice-free, voice-free request? Maybe even think in terms of how to make a task more accessible. For example, is it easier to control playback of a song with a voice command, or is it easier to play a song via screens and buttons and through apps? That's debatable. What's called single-turn dialogue is also an example of easy interaction. For example, asking for the weather or for a joke. The user makes a request, the agent returns a response, and the interaction is over. That's theoretically easy. If you're using multiple-turn dialogue, it still needs to be easy. This requires more design work and you'll need to explore interaction that can flow in various ways. When designing for fun, you also want to make it easy, but you don't want to make it so easy that it's boring and lame. Games, for example, can be interesting to design because in order for a game to be fun, it needs to present a challenge. Games that are easier are boring, so you want to design your game to be fun by making it easy to play but challenging at an appropriate level to win. You can also look for ways in your app to incorporate humor, surprise, or delight. And finally, think about how you can use to feel during and after interaction with your voice skill. How many times have you been on the phone with an automated voice machine and press one for this and press two for that or say your number and it just leaves you frustrated and you're swearing and they actually have people listening to you cursing and if you reach a critical mass of cursing, then they get on the phone to help you out. How often are we so frustrated dealing with voice UIs that it just leaves us just filming mad? That's not how you want your users to feel when they're interacting with your app. So be choosy. Be choosy, be particular about what aspects of your platform you want to expose to voice interaction. You don't have to do it all. You can pick a certain aspect of your platform to expose to voice. Ask yourself, will adding voice interaction make a certain task faster, easier, or more fun for your user? If the answer is a resounding no to all of those, you probably want to rethink your project idea. One of the first challenges is deciding what type of project is a good fit for voice interaction. Spend some time describing some scenarios that people would find your skill useful or desirable. Think about why people want to use your voice UI. Maybe think about what a person will be doing before, during, or after interacting with your skill, and that might help you envision the context in which a person using your skill, when that makes sense. And also think about what someone would get from their skill that they can't get any other way. Next, create a persona. We're talking about voice here. Think about what is your UI's personality? What kinds of phrases would they say? Are its expressions and responses in line with your brand's values? Or is it just coming out of your own head? Once you've picked out your project idea or have decided which part of your application you want to expose to a voice UI, and you've thought about your voice UI's persona, you've thought about some scripts. Start out with a simple script between the UI and the user. And at first, focus on the happy path where everything goes well. In the process, think about whether or not the dialogue is flowing naturally and the variations of dialogue that could result in the same outcome. Maybe practice with someone and see what kind of different phrases after you practice it over and over again get brought up. Keep the interactions brief and write for how people talk, not how they write. Indicate when the user needs to provide info. And ask for one piece of information at a time. Next, we want to represent our example dialogue with a flow diagram. So, reference the happy path script and map out all of the places where input is needed from the user. After you have diagrammed the flow for the happy path, start branching out. Cover additional logic and things where things don't go well. And remember, keep this maximum in your head that you don't want to say to the user that they've made an error. So think about how you can re-route and get the conversation back on track to have a successful conversation. So here's an example of a script. And this is one of the examples that I worked through on the developer Google site for Google actions on Google. And I want you to think about as I'm reading this the different ways, the different phrases that both the user and the UI are using, even though they're basically saying the same thing. Welcome to number genie. I'm thinking of a number between 0 and 100. What's your first guess? 50. It's lower than 50. Next guess, how about 9? Piping hot. Go lower. Okay, is it 8? Keep going. 7. Yes, it's 7. How about another round? No thanks. All right, talk to you later then. So basically, the UI is just saying no, you didn't get it right a bunch of different times, but they're saying it different ways, and they're saying it in a certain way that makes you think, yeah, this thing has personality and it's not just a machine. It's a little bit more than that, even though it is just a machine. The final step in the voice design process is to create and configure the interaction model. This is an actual implementation step and a key part of the process for creating a custom skill. In this step you want to take your flow diagram and ascertain what are the concrete things that can happen in this interaction. So these concrete things are called intents. What are the specific phrases that can be said to invoke these intents? These are our utterances or what the quote user says. And what data does your app need to fulfill the request? These are your slots or your entities. You can find out more about these concepts on these URLs and I'll have these slides available on the session node and you can so you don't have to worry about capturing these now, you can go back to the slides later. These are all resources that I took from in putting together these tips. Let's talk more about key concepts in voice UI creation. So how does the conversation start with activation? So this is a wake word or a phrase that activates the platform AI. Sometimes this is a physical button or other audible trigger like hand clapping. So this could be Hey Siri, Alexa or Google or pressing a button on the device. Invocation is what tells the platform which voice UI you want to talk to. So there's thousands of developers developing thousands of apps. How does whatever the AI that you're talking to, how does it know which skill to talk to? This is invocation. So think of it like an operator, like Alexa or Google is the operator and you're telling the operator who you want to talk to. So let's say the name of our voice UI is fish jokes. With Alexa you do this with a specific set of invocation keywords like ask, open or launch and then the name of the skill. So I could say open fish jokes or launch fish jokes or ask fish jokes. With Google it's a bit more natural. For example let me talk to fish jokes. So Alexa tends to be more command oriented and Google tends to be more naturally conversant. That brings up other issues that I'm not going to talk about today but these devices are in the home and they're being done in the context of families and with young children and I've had conversations with people who are like, yeah I don't really like how Alexa is so command oriented because it's kind of teaching my toddler how to boss around this device called Alexa. So there's just, it's interesting how, what kinds of things this is bringing into our societies. So I kind of like actually how the Google implementation is more conversant and it allows for more natural dialogue. Intents are what map, what the user says to specific functionality or actions of your UI. And these are, there are built in intents that your platform provides that can make it easier for you to get default welcome responses or help or ending the conversation. So each platform has some built in intents that can make your life easier. You're not going to have to reinvent those wheels. And so those kinds of built in intents can help you with specific responses depending on context. And then there's custom intents which are your voice UI special sauce. So that's really about the direct functionality that you want to provide. But you also need to throw in help and how do you, how does the user quit your UI and things like that. So, and you'll need to have those to pass the QA process. User says or utterances, and I'm using these two different phrases because in, in Alexa it's called utterances and api.ai it's called user says so that's why I've got both terms on there. And these are the phrases or words that your app recognizes. So, you also want to think about context because you want to have different sets of phrases for different intents and those intents in different contexts. So these phrases can contain slots or entities which ultimately feed arguments or parameters to your endpoint. You want to add as many variations as possible. You want to think about that context. When someone, after a conversation is started people respond differently because they know what has been said already. And so your app should know what has been said already too and take that into consideration. So, for example, here's an api.ai screen and we've got a list of phrases that user says and we want to build out as many as possible and the machine learning algorithm of api.ai will take that and learn from that and eventually your app will recognize even more phrases kind of based on what you've fed it already but you still want to feed it as many variations as possible to help that machine learning process. In Alexa's beta interaction model UI so as you go through the screens and building your Alexa screen you'll get to the interaction model and it'll say do you want to try out the beta interaction model and your answer should be yes I do because it's so much better than the first iteration that they have. So you add sample utterances here and this is in your intent. Slots or entities which I've mentioned are optional arguments. You define a type and then populate it with valid terms so you might want to think in terms of you define a vocabulary and then you give that vocabulary terms. It's a similar sort of thing. You'll then put these slots or entities into your sample phrases or your user says in your intent. So as you're saying like well they might ask for fish jokes that are silly and so silly is going to be your slot and silly is going to be your taxonomy term on your Drupal site that's going to get the silly joke returned back to the user. For example in this phrase I want to hear about Google's history. Google's history or history and I want to hear about history or I want to hear about Google's history. That's highlighted and it's mapped to the fact category entity. Then we configure the parameter down below which will be passed on to our end point. So we can even make that a required thing. So we're going to keep prompting the user for this information until they give it to us so we can return an appropriate response. The valid entity terms in this example are history or headquarters. So here's where I'm defining my entity. So I've got two terms, history or headquarters. Those are the two types of facts that I'm going to return. And I can also set a number of synonyms there which is really nice. In the Alexa interaction model UI you create a slot type and then slot values including any variations of the term. So you're just going to list those all out. And it's a different sort of way that you do that instead of doing synonyms you're just going to list out all of the different terms that will be valid responses. In the user says phrases you map certain words to entity parameters. If you configure your entities in terms before your user says phrases these words will be automatically mapped for you. So if I set up my entity already and set up my terms as I'm typing out the user says and if I use one of those terms that I've already added to my entity it's going to highlight it already. It's going to highlight it automatically. And otherwise if you haven't done that step already you can highlight the word that you know is going to be your entity and then you can map it to either a built in or a custom entity type. So you can kind of build it out as you go. And you can go back and forth between your entities and your intent to iron all those details. And it's a similar thing with Alexa's beta UI for the interaction model. You activate a slot though instead of with just highlighting a word you have to use a curly you open a curly brace and it's like oh I know you want an intent slot so which type do you want okay I want category. So in your utterances it's going to have curly brace category instead of like the actual word like the actual synonym or term. So you can stub out slot names in your sample utterances and then you can create your slot type and add the terms later. So in api.ai entities are highlighted in user says phrases for your intent so just enter given that the user is going to use one of these entity terms or synonyms into a variety of phrases that makes sense. Once you've started to figure out your interaction model you need to think about where the data will come from that will make up your UI's response. In api.ai on the fulfillment configuration screen you configure a web hook with a URL. You can also include any basic authorization or additional headers. The URL is the endpoint and the process is much the same for Alexa. You're going to enter in a URL that is the endpoint that's going to return the JSON for your response. So let's talk about some possibilities for those endpoints and there are many but I'm going to talk about several possibilities here. The easiest path that you probably want to start out with is to provide response values in a hard coded array. Both Alexa and actions on Google have GitHub repos with example code that uses static arrays. So with just a bit of JavaScript knowledge it's relatively easy to tweak out these blueprints with custom response values. This is a method that you'll likely use when you're setting out to learn a platform and you're going through the getting started tutorials. But to add more values to your responses after your app has been published you'll have to resubmit the version of your app. So that's kind of cumbersome. That's fine for learning, that's fine for once, but how is that sustainable in the real world? It's not very. So we can use the same hosting and endpoint configuration. So in that first example with the static array you'll host it on AWS Lambda or Firebase or Google Cloud and we can still do that. We can have some code script or some kind of JavaScript that has our static array and instead of that static array we can make a web services call to an external endpoint. For example if that endpoint was on a Drupal site we can configure for example a view using the rest export display which returns JSON at a certain path. And this is something that we did with our custom Alexa skill. So we're using a JSON endpoint provided by Drupal to draw from a larger library of material. So any content that we add to our Drupal site is now available in the response. We don't have to resubmit our app, we just have to update our Drupal site with new content. So this means that we can add possible responses without the need to resubmit our app. A third possibility is to get rid of the Lambda or the Google Cloud API and have the voice UI service talk directly to a Drupal site. But if we're tasked with parsing JSON that Alexa API.ai or Google actions sends to our Drupal site, that would be no easy task. But thankfully there are some modules for that. The modules that I've personally used to create endpoints for voice UI requests are listed here. So we have a REST export views display, the Alexa project, the chatbot API project in conjunction with the API.ai webhook project, which requires the PHP SDK for API.ai. So first, the views REST export. In the case where we make a web services call from a JavaScript hosted with a form cloud service like Firebase or AWS Lambda, we called an endpoint created by this REST export views display. This functionality ships with Drupal 8 core. No extra modules are required. If you're building a custom Alexa skill and you want to use data from your Drupal site in the response, take a look at the Alexa module. There, we had to add some custom functionality to get a card view to display, but it's pretty great out of the box. This module also optionally integrates with the chatbot API project. This project serves as a common layer to send data to a number of voice and chatbot UI services. It uses several different systems in Drupal, including the plugin system views, and it provides a way to export Drupal content to API.ai entities. Chatbot API provides a base plugin for chatbot intents. You create a plugin in your module that extends the intent plugin base. In the annotation, you provide an ID that's equal to the name of your intent in API.ai, for example. You can actually use Drupal console to generate this type of plugin, or you can copy and paste the example provided in the module and then modify it to fit your intent in your class name. The process method in this class is automatically called and is where all of your logic goes for the response. But there's also a views display provided by the module. This is the chatbot intent display, which will show up for you if you have the module enabled. The intent name should be the name of your intent in your platform UI. The implementation is still ongoing, but on a basic level, it works. I've tested it with API.ai agents integrating with actions on Google. You can also use API.ai webhook project with chatbot API. Instead of the plugin system, it uses the event system. It handles requests from API.ai agents to the webhook on your Drupal site, and it triggers a symphony event which modules can subscribe to in order to add their logic. It requires the API.ai which is in progress, but it's got a great start. These are all great modules and projects to look into, and I encourage you, if you're a developer, to see how you can help and support the maintainers of these modules in their respective issue queues. So here they are one last time. So check out those project pages and see how you can test them out, give them feedback, and make your developer help contribute because I think these all have a great start and they can make the process that much easier. Finally, let's talk about testing and publication of your voice UI. Both Alexa and actions on Google provide in-browser testing simulator, so you don't need to go out and buy a device necessarily to do this, and to even go through the entire process of even developing, testing, and publishing it. You don't need devices. It's fun to have them around, but you don't need them. They have a simulator. You can test both the headless audio responses as well as rich responses containing images and links by selecting a surface option as in this snippet of a screen. So here is the surface, so the Google home device is highlighted so it's going to return just what the voice UI would say, and if you have the speakers on on your computer then you can hear what it would say, but you can also just test it out with the keyboard, so you don't necessarily have to hold up somewhere where you it doesn't, you can test it just with keyboard, but if you switch to the screen, then it'll return a rich response, and that's part of the development process is making sure that you're providing a rich response as well as a voice response. For the Google assistant tester, you just type in talk to my test app, and you'll be able to test it out. After you've tested your app and entered in the appropriate metadata for it, like name, description, logo, etc., you can submit it for publication. It'll be thoroughly tested, and you can expect feedback within one to two days. Make sure you go to your developer account. Something that I didn't mention is a big part of this process is signing up for all these developer accounts. You might want to make that different than your normal personal account, especially since you're going to need to turn off a lot of privacy settings and data collection settings that you may not be comfortable with on your personal account, so I set up a separate email and a separate account for all my developer accounts, especially when we're talking about all of the data that is collected there, so just consider that. Address the feedback that they give you. Sometimes they're wrong, so I've encountered that, they were wrong, and I told them they were wrong, and why, and in a polite way, and they see your point, or they don't, or you're wrong, and just address the feedback and resubmit, and once approved, there's no extra step. It's published, it's out there. And for Alexa, that means it's going to show up in the Alexa store that users can browse through and enable. Finally, I just have a couple of demos to show you just for fun. These are some projects that I have done, so this is an example of Alexa. I like to tinker with hardware, and so I decided like, having an Echo Dot is okay, I guess, but it's like way more fun to take apart the motor and solder the input into an Arduino and write a little Arduino script and have this animatronic fish talk instead of Echo Dot, so. Alexa. Open fish jokes. Why don't fish play basketball? Because they're afraid of the net. These are like the worst jokes out of her, but they're great. Alexa. Ask fish jokes for a nerd joke. What Drupal module do you use to organize schools of fish? Organic grouper. Yeah? Drupal crowd? No. So in that example we had the slot, so ask fish jokes for a nerd joke. So on the Drupal site, we have a bunch of jokes and they're tagged with the term nerd, and so it returns a joke that is tagged with that term. So that's how that works together. And then finally, this is like totally different, this is not an action on Google, but this is, you can actually embed the Google Assistant into a DIY device. Google promoted this through providing this like cardboard build. All you needed was a Raspberry Pi 3 and it had a special voice hat, a little speaker and microphone, so I built this little DIY Google Home device and I embedded Google Assistant on it. So this is a terrible, the quality of this video is not great, but you can kind of see how you could do that. There's a terminal that's going to pop up, and so I'm activating the service. I actually turn this on automatically, so I'm typing this with one hand and filming with the other, so it's really shaky. So the service is happening. I press the button. So this is a speaker in Portland, Oregon. It's 79 and mostly cloudy there. Today it will be cloudy with a forecast in high of 79 and a low of 57. So the SDK for Google Assistant, it's all open source, so you can if you have a Linux, if you have an embedded system that uses Linux, you can embed the Google Assistant into your device and you can also build actions on Google to extend that. You can also use actions on Google to create an app that could turn on lights or you can hack certain things. So if you're into that sort of thing, there's also some possibilities there. I will say you can also do this with Alexa, but that was just me experimenting with Google Assistant. So to recap, I gave you an overview we talked about designing a voice interface and some voice UI concepts that are common across the board. And finally, we talked about some endpoint possibilities and how you might be able to integrate with Drupal. And certainly there's probably other ways that you can do that too, especially if you're really into decoupling an API first and that sort of thing, you probably can think of a lot of different ideas, but those are what are designed for you. This session was called Get Started with Voice User Interfaces, so you can go to the DrupalCon Vienna site and go to the session node and you'll find a link to an evaluation survey on the page for the session and I would love to have your feedback. I'm happy to answer any questions or you can find me in the hallway afterward or you can find me on Twitter. So if there's any questions, please feel free to use the mic in the center. Thank you. I was just wondering, you mentioned the testing, which was useful information to see that. Have you done any automated testing with any of the voice assistants? No. Have you considered it? And are you intending to? No. I just do this for fun. This is like my evening and weekend thing to keep me sane from doing Drupal. I'm pretty much dabbling just with the Home Assistant project. I've just recently integrated that so I can now use Google's Assistant to talk to my Home Assistant to turn my lights on or open the garage and so on. If I continue going down that route I'll probably get to a stage where I want the automated testing. That sounds like a really good idea. Do you know if the testing tool has an API just? I don't know. Thank you for your question because that's a good thing to consider. Thanks for bringing that up. Any other questions? Thank you very much. If something comes to mind, please come and find me. I'll be here all week.