DEV Community

Joaquín Engelmo (a.k.a. Kini)
Joaquín Engelmo (a.k.a. Kini)

Posted on • Originally published at kinisoftware.com on

Creando un custom skill para Alexa (II): Alexa Developer Console & Interaction Model

Como comentaba en el anterior post, una vez que tuve la idea sobre qué hacer (un skill para conocer por los estrenos de cine de una fecha determinada) empecé con la parte "cliente" usando la Alexa Developer Console. Por cierto, este site no está traducido al español, no queda otra que usarlo en inglés.

Alexa Developer Console

Desde aquí podrás crear tus skills y verás listados todos los que tengas con info y acciones directas sobre algunas secciones como las analíticas o la gestión de la beta. Tienes un par de links sobre documentación de la consola, tanto en vídeo como en texto. Son bastante útiles para hacerte una idea del site. Una vez publicas una skill te aparecerá por partida doble pero con distinto estado, la de desarrollo y la que está en live en la "tienda de Alexa skills" de Amazon. Ya hablaré de esto en otro post.

Lo primero que nos pide para crear nuestro skill es: nombre, idioma del skill y de qué tipo es. Puedes consultar los distintos tipos aquí. Los tipos disponibles dependen del idioma por defecto que elijas. El tipo que casaba con mi idea de skill era un "custom skill".

Una vez creado llegarás a la ventana que te dará acceso a todo lo necesario para el desarrollo del skill. La mayoría del tiempo lo vas a pasar en la parte de "build" de la consola. Aquí tendrás a mano todo lo que necesitas para construir tu skill, configurarlo e irlo evolucionando.

Siguiendo el "Skill builder checklist" completarás lo mínimo necesario para tener un skill listo. Hay dos partes básicas: el interaction model del skill y el endpoint al server que gestionará las peticiones al skill. En este post sólo voy a hablar sobre lo primero.

Interaction Model

El interaction model del skill consta de, al menos, dos partes: el nombre de invocación de tu skill y el conjunto de intent (acciones) que deben corresponder con las peticiones de los clientes.

Nombre de invocación

El nombre de invocación será lo que el usuario use para comenzar a interactuar con tu skill y debe cumplir una serie de requisitos. Creo que es bastante importante la elección que se hace porque el usuario podrá invocar el skill y ejecutar un intent de una sola vez, one-shot invocation. Por ejemplo, "Alexa, pide a estrenos de cine las películas de esta semana" y tiene que tener sentido. El usuario también podría conseguir el mismo resultado con: "Alexa, abre estrenos de cine", el skill puede responder de alguna forma, y luego: "Dime las películas de esta semana". A mi me gusta bastante la forma de usarlo de one-shot invocation y me he querido centrar en eso al diseñar el modelo.

Intents

Un intent está compuesto por dos partes: los utterances (sentencias) que van a servir para invocarlo y los slots (argumentos), opcionales, que puede tener. Un par de cosas sobre los utterances:

  • Dentro de un mismo intent no puedes tener dos utterances repetidos. De esto te drás cuenta rápido sin usar slots, pero cuando uses slots puedes acabas creando utterance que son iguales y te saltará. A mi me pasó cuando empecé a extraer slots de distintos utterances. Esto te lo valida la propia consola.
  • Los utterance los usa Alexa para inferir qué intent corresponde a lo que quiere hacer el usuario. Vas a poder repetir el mismo utterance en dos intent distintos en la consola y no tendrás un mensaje de error, ni cuando hagas build del modelo. Pero, en el momento de tener que inferir el intent, Alexa tendrá problemas y, no he leído mucho sobre eso, el comportamiento no es determinista. De todas formas, en el proceso de certificación es una de las cosas que validan y tendrás que corregirlo (true story :))

Intents obligatorios

Al crear un skill nuevo hay algunos intents obligatorios, predefinidos ya por Alexa, que tienes que tener cubiertos y te los indica la consola debajo de "Built-in intents". Verás que son básicos, sin slots, y yo los he interpretado de la siguiente forma:

  • NavigateHome, que se usa para skill multimodal, los que tienen pantalla, y equivale a un exit
  • Cancel, se usaría para cancelar alguna interacción en proceso
  • Stop, para dejar de usar el skill
  • Help, se invocaría por el usuario para pedir ayuda a nuestro skill

Para cada una de estos tendrás que elegir utterances que vayan a invocarlo, no tiene más. Una vez que hagamos la parte server veremos cómo enlazamos los intent con sus handlers para responder al usuario.

Custom intents

Estos intents serán los que definan realmente los casos de uso que queremos cubrir en nuestro skill. En mi caso sólo necesitaba uno: pedir las películas que se estrenaban en un determinado momento. Yo para empezar lo simplifiqué al máximo asumiendo que eran siempre para "esta semana". De esta forma el intent no iba a tener slots de momento y me iba a centrar en tener un skill funcional aunque no tan completo como yo quería.

Al crear un intent tienes la opción de usar uno existente de la librería de Alexa, como los built-in intent que eran obligatorios, o uno custom. En mi caso no había uno ya existente que me valiera.

El nombre del intent debería ser explicativo de la acción correspondiente que se quiere cubrir. Yo le llamé "NewReleasesIntent" ya que sería para cubrir la petición de estrenos y seguí la convección de nombres que vi en los built-in.

Una vez creado, lo único que tenemos que añadir, por el momento, son los utterance para ser invocado.

Es todo un arte esto de crear utterance para el intent y mientras más se añadan mejor para la identificación correcta. Aquí os pongo una guía de buenas prácticas por idioma que ayuda bastante.

Build model

Y con esto ya tendríamos nuestra primera versión del modelo lista para ser creada. Tenemos que pulsar el botón de "Build Model" y lo generará. Yo no he tenido problemas con esto y no sé muy bien si hace validaciones al realizar este paso y cuáles, supongo que sí. Probablemente en la doc haya info al respecto.

El modelo que se genera no es más que un JSON con toda la información que hemos ido construyendo con la consola. Este JSON se puede ver una vez generado y modificar en vez de usar los input de utterance y todo eso que vimos antes.

Este fichero se puede descargar y, cuando hagamos el proyecto de la parte server, se podrá añadir y usando las herramientas de línea de comandos desplegar versiones de nuestro skill completo sin tener que usar el site. Esto lo veremos en otro post, pero yo empecé usando lo que he contado aquí. Así me fui familiarizando con los conceptos y partes de un skill, y luego pasé a usar línea de comandos.

En el siguiente post contaré cómo hacer la parte server usando AWS Lambda y la conectaremos con nuestro skill para poder hacer una primera prueba completa de su funcionamiento.

Gracias por llegar hasta el final porque ha sido un buen ladrillo ;)

Top comments (0)