Nota: este artículo está basado en la documentación publicada por Amazon y en mi propia experiencia de desarrollo de Alexa skills y Actions on Google Assistant.
Paso 1: Diseñar el interfaz de voz
Para desarrollar una skill, lo primero que se necesita es tener una idea de la función que realizaría. Como (casi) todos tenemos un smartphone, seguro que tenemos ideas de apps. Ese puede ser un principio. Luego hay que pensar en las particularidades que tienen los SmartSpeakers como Alexa.
La interacción debe diseñarse exclusiva y específicamente para voz
En la pantalla de un móvil se puede mostrar mucha información y la usuaria tendrá tiempo para mirar, pensar y elegir qué hacer. Por voz, la situación es distinta, típicamente, se puede retener entre tres y cinco opciones en mente, pero si hay más, es probable que no se recuerden las anteriores y se tengan que repetir. Hay que estructurar bien las frases y tener muy en cuenta el contexto para excluir la información poco relevante.
Por otra parte, cuando se tiene una conversación con una persona, aunque las palabras aportan una buena parte del significado, la entonación y los gestos son claves. En una conversación con Alexa no habrá gestos y la entonación no se tiene en cuenta. Esto hace que las palabras deban ser muy precisas y que haya que pensar muy bien qué se va a decir y cómo.
El nivel de privacidad es distinto al de un móvil
Este tipo de dispositivo puede estar en el salón, en la cocina, en el coche, donde varias personas pueden oir los mensajes, no solo la usuaria. Creo que los bancos aún no han entrado en este sector y tengo curiosidad de ver como se manejan cosas como claves de acceso, saldos de cuentas bancarias, número de tarjeta de crédito, etc.
La búsqueda no es su fuerte
Imáginate que quieres poner una canción de Pablo Milanés pero no te acuerdas del título de la canción ni del disco. La conversación con Alexa sería una cosa así:
- Tú: Alexa, dime los álbumes de Pablo Milanes
- Alexa: La carrera discográfica de Pablo Milanés comenzó en 1968 con una colaboración en el álbum “Canción protesta. Casa de las Américas”. ¿Es este el disco que buscabas?
- Tú: No, sigue
- Alexa: En 1969 colaboró en otros cinco discos: “Vietnam canta a Cuba”. ¿Es este el disco que buscabas?
- Tú: No, sigue
- Alexa: “26 de Julio. Los nuevos héroes”. ¿Es este el disco que buscabas?
- Tú: Si, gracias. ¿Qué canciones hay en ese disco?
- Alexa: “Canción del elegido”. ¿Es esa la canción que buscabas?
- Tú: No, sigue
- Alexa: Hay un almanaque lleno de 26. ¿Es este el disco que buscabas?
Bueno, creo que el problema está claro. Si lo que quieres es buscar una canción o cualquier otro tipo de contenido, la pantalla táctil de tu móvil o, mejor aún, tu ordenador son herramientas mucho mejores que Alexa u otro SmartSpeaker/ Virtual Assistant.
Haces la búsqueda en Google o Spotify con los datos que recuerdes y luego, una vez identificada la canción, dices “Alexa, pon la canción Moncada de Pablo Milanés”.
Paso 2: Preparación del Interaction Model
Prefiero mantener los términos en inglés, al fin y al cabo la documentación no está en español y el portal de desarrollo tampoco (solo en inglés y japonés).
Salvando el tema del idioma, diseñar y preparar un interaction model no requiere conocimientos técnicos y está al alcance de cualquiera de vosotros. De hecho, os animo a intentarlo.
El interaction model es básicamente cómo Alexa va a estructurar lo que el usuario dice, es decir, las instrucciones que podemos darle dentro de este skill. Se ve mejor con un ejemplo, sea un skill (llamado Baúl de Noticias) que te puede dar las noticias de varios temas:
- Alexa, lee los titulares de Albacete
- Alexa, lee el primer artículo
- Alexa, siguiente
- Alexa, repite
- Alexa, para
Los intents en este caso serían
- Intent.ReadHeadline: “lee los titulares de” + <tema>
- Intent.ReadArticle: “lee el artículo de” + <tema>
- Intent.Next: “siguiente” | “adelante”
- Intent.Repeat: “repite” | “otra vez”
- Intent.Stop: “para” | “por favor, para” | “salir”
Donde <tema> puede ser, por ejemplo: “Albacete | Robótica| Euskadi | Sushi”. Una vez que el usuario elige el tema, se asume que se continúa con el mismo, para que no tenga que repetirse, hasta que se asigne otro.
Paso 3: Desarrollar la función de respuesta
Para esta parte sí que se necesitan ciertos conocimientos técnicos y de programación, pero si no los tenéis, os animo a que aprendáis Javascript, lleva algún tiempo, pero merece la pena.
En el apartado anterior se estructuraban las instrucciones del usuario, en éste se ve cómo preparar la respuesta para cada instrucción.
Hay dos modos de desarrollar esa función, uno es por tu cuenta y riesgo y otro es en aws.amazon.com (la nube de Amazon). Yo he optado por la segunda opción por varias razones: está muy bien pensada y diseñada, es gratis si tomas ciertas precauciones y así lo tienes todo con Amazon que se ocupará de que todo funcione bien para que su muy querida Alexa tenga éxito.
AWS proporciona muchos servicios, en este caso nos centramos en Lambda para implementar la función en node.js que reciba las instrucciones del usuario y construya la respuesta:
- Crear una función Lambda, tomando como ejemplo alguno de los blueprints que empiezan con “alexa-….”
- El tema de los permisos en AWS es tedioso y lioso, pero hay que hacerse con ello. Creas un custom role con acceso a CloudWatch y DynamoDB y le das “Create Function”
- Desde la parte izquierda, añades Alexa Skill Kit como trigger. Para que tu función solo sea llamada por tu skill, pon el Skill ID en Skill Verification y guarda los cambios. Puedes encontrar el Skill ID en la pantalla EndPoint de tu skill (en developer.amazon.com)
- En el index.js de la función, ya tienes código que puedes usar para desarrollar tu propio función. Borra lo que no te interese pero mantén la estructura del código, Amazon te asegura que ese código funciona.
- Arriba a la derecha verás un identificador que empieza por arn:aws:lambda: y que acaba con :function:nombre_de_tu_funcion. Eso es lo que tienes que poner en el tu skill, pantalla EndPoint como AWS Lambda ARN. Así es como se enlaza una parte con la otra.
Paso 4: Pruebas, certificación y publicación
Se puede hacer pruebas a varios niveles
Prueba unitaria de la función Lambda
Desde el propio editor de la función se pueden crear casos de prueba. Pincha en el drop-down de Test para crear eventos de prueba. Se debe tener, al menos, un evento por cada intent. Si la función considera estados, habrá que tenerlos en cuenta durante las pruebas.
A este nivel es suficiente con que la función devuelva una respuesta sin errores y con los mensajes correctos. Intentar probar secuencias de eventos aquí es muy complicado y no merece la pena.
Prueba integrada desde el simulador
En la consola de desarrollo cada skill tiene una pantalla de Test, desde ahí puedes simular las instrucciones del usuario y comprobar que las respuestas son las correctas.
También se puede probar que Alexa lee correctamente tus mensajes. Siempre hay cosas que leídas parece que están bien, pero luego al leerlas vemos que no, sobre todo con caracteres no alfanuméricos: “…” a veces lo lee como “punto, punto, punto”, “-“ lo puede leer como “menos”
Prueba end-to-end desde Amazon Echo
Si activas tu Amazon Echo con la misma cuenta que usas en el portal de desarrollo, podrás probar el skill antes de que esté aprobado.
Aquí la prueba será ya hablada, dando las instrucciones al Amazon Echo como el usuario las dará en su momento. Si todo te funciona bien aquí, puedes estar seguro que el skill está listo.
Si has llegado hasta aquí, primero, gracias por leerlo todo y segundo, entiendo que realmente te interesa el desarrollo de Alexa skills.
Hay otro post en este blog con una descripción de cómo desarrollar Alexa skills avanzados. Es decir, casos en los que además de la conversación en sí, hay funcionalidades complejas detrás. Todo está desarrollado en AWS.
