Creamos una aplicaci贸n de voz usando el ejemplo del Asistente de Google

Cada quinto residente de los Estados Unidos posee un altavoz inteligente, y esto es 47 millones de personas. El asistente puede crear un recordatorio, una lista de quehaceres, un reloj despertador, un temporizador, leer noticias, encender m煤sica, hacer podcasts, entregar pedidos, comprar entradas para el cine y llamar a un taxi. Estas son todas las "habilidades" o "habilidades" de los asistentes. Tambi茅n se llaman aplicaciones de voz. Se han desarrollado 70,000 aplicaciones para Alexa y Google Assistant para 2018.

En 2017, Starbucks lanz贸 la funci贸n de pedido de caf茅 en casa para Amazon Alexa. Adem谩s de aumentar los pedidos de entrega, todos los medios de comunicaci贸n posibles escribieron al respecto, creando un PR genial. A Starbucks le siguieron Uber, Domino's, MacDonald's e incluso Tide Laundry Detergent desarroll贸 su propia habilidad Alexa.

Al igual que Starbucks, la aplicaci贸n de voz realiza una o dos funciones: ordena caf茅, activa una alarma o llama a un servicio de mensajer铆a. Para dise帽ar algo similar, no es necesario ser una corporaci贸n intercontinental. La idea, dise帽o, prueba, desarrollo y lanzamiento es similar a etapas similares en el mundo del desarrollo m贸vil, pero con caracter铆sticas para voz. Pavel Guay habl贸 en detalle sobre el proceso: desde una idea hasta la publicaci贸n, con ejemplos de un juego real, con inserciones hist贸ricas y un an谩lisis del mundo del desarrollo de la voz.



Sobre el orador : Pavel Gvay ( pavelgvay ) - dise帽a interfaces de voz en el estudio de desarrollo m贸vil KODE. El estudio est谩 desarrollando aplicaciones m贸viles, por ejemplo, para Utair, Pobeda, RosEuroBank, BlueOrange Bank y Whiskas, pero KODE tiene una divisi贸n que se ocupa de las aplicaciones de voz para Yandex.Alice y Google Assistant. Pavel particip贸 en varios proyectos reales, intercambia experiencias con desarrolladores y dise帽adores en este campo, incluidos los de EE. UU., Y habla en conferencias tem谩ticas. Adem谩s, Pavel es el fundador de la startup tortu.io , una herramienta para dise帽ar aplicaciones de voz.

驴Qu茅 es una aplicaci贸n de conversaci贸n?


En una aplicaci贸n de conversaci贸n, el canal de interacci贸n con el usuario se construye a trav茅s de una conversaci贸n : oral, con un altavoz inteligente, o por escrito, por ejemplo, con el Asistente de Google. Adem谩s de la columna, el dispositivo de interacci贸n puede ser una pantalla, por lo que las aplicaciones de conversaci贸n tambi茅n son gr谩ficas.

Es correcto hablar una aplicaci贸n hablada , no una aplicaci贸n de voz, pero este es un t茅rmino establecido, y lo usar茅 tambi茅n.

Las aplicaciones de voz tienen una ventaja importante sobre las m贸viles: no necesitan ser descargadas e instaladas. Es suficiente saber el nombre, y el asistente comenzar谩 todo por s铆 mismo.

Esto se debe a que no hay nada que descargar, tanto el reconocimiento de voz como la l贸gica empresarial, toda la aplicaci贸n vive en la nube. Esta es una gran ventaja sobre las aplicaciones m贸viles.

Un poco de historia


La historia de los asistentes de voz comenz贸 con Interactive Voice Response , un sistema interactivo de respuestas de voz grabadas. Quiz谩s nadie escuch贸 este t茅rmino, pero todos se encontraron cuando llamaron al soporte t茅cnico y escucharon al robot: 鈥淧resione 1 para acceder al men煤 principal. Haga clic en 2 para obtener m谩s informaci贸n 鈥: este es el sistema IVR . En parte, IVR puede llamarse la primera generaci贸n de aplicaciones de voz. Aunque ya son parte de la historia, pueden ense帽arnos algo.

La mayor铆a de las personas, cuando interact煤an con el sistema IVR, intentan contactar al operador. Esto se debe a una mala experiencia de usuario cuando la interacci贸n se basa en equipos duros, lo cual es un inconveniente.

Esto nos lleva a la regla b谩sica de una buena aplicaci贸n conversacional.

Una buena aplicaci贸n de conversaci贸n interact煤a con el usuario no a trav茅s de comandos estrictos, sino a trav茅s de una conversaci贸n viva y natural, similar a la comunicaci贸n entre personas.

Una conversaci贸n con la aplicaci贸n deber铆a ser m谩s como llamar a una pizzer铆a para pedir un pedido que comunicarse con un bot de chat por equipos. No ser谩 posible lograr la misma flexibilidad que en una conversaci贸n entre personas, pero hablar con la aplicaci贸n en un lenguaje c贸modo y natural es bastante.

Esta es tambi茅n la ventaja de las aplicaciones de voz sobre gr谩ficos: no es necesario aprender a usar . Mi abuela no sabe c贸mo ir a sitios o pedir pizza a trav茅s de la aplicaci贸n, pero puede llamar a la entrega a trav茅s de la columna. Deber铆amos usar esta ventaja y adaptarnos a la forma en que las personas hablan, y no ense帽arles a hablar con nuestra aplicaci贸n.

Pasemos de los sistemas IVR al presente, a los asistentes virtuales.

Asistentes virtuales


El mundo de las voces gira en torno a asistentes virtuales: Google Assistant , Amazon Alexa y Alice .

Todo est谩 organizado casi como en el mundo m贸vil, solo que en lugar de las plataformas iOS y Android hay Alice, Google Assistant y Alexa, en lugar de aplicaciones gr谩ficas: voz, con sus propios nombres o nombres, y cada asistente tiene su propia tienda de aplicaciones de voz. Nuevamente, decir "aplicaci贸n" est谩 mal, porque cada plataforma tiene su propio t茅rmino: Alice tiene "habilidades", Alexa tiene "habilidades" y Google tiene "acciones".

Para comenzar la habilidad, le pregunto al asistente: "隆Alexa, dile a Starbucks que quiero caf茅!", Alexa encontrar谩 la aplicaci贸n de cafeter铆a en su tienda y le dar谩 la conversaci贸n. Luego, la conversaci贸n no va entre Alex y el usuario, sino entre el usuario y la aplicaci贸n . Muchos est谩n confundidos y piensan que el asistente contin煤a hablando con ellos, aunque la aplicaci贸n tiene una voz diferente.

As铆 es como se ven las tiendas de aplicaciones. La interfaz se asemeja a la App Store y Google Play.


Pasos de desarrollo de aplicaciones conversacionales


Para el usuario, la aplicaci贸n no tiene una parte gr谩fica: todo parece un conjunto de di谩logo. Exteriormente, puede parecer que la aplicaci贸n es algo simple, es simple crearla, pero no lo es. Los pasos de desarrollo son los mismos que para las aplicaciones m贸viles.

  • Dise帽o. En el caso de la voz, no es la representaci贸n de pantallas, sino la elaboraci贸n de di谩logos.
  • El desarrollo se divide en dos partes: el desarrollo de un sistema de comprensi贸n del habla y la escritura de la l贸gica.
  • Pruebas
  • Publicaci贸n

Las dos primeras etapas son espec铆ficas, ya que las aplicaciones son conversacionales, y las dos 煤ltimas son est谩ndar.

Pasaremos por cada una de las etapas con el juego Adivina el precio , que se lanza bajo el Asistente de Google. La mec谩nica es simple: la aplicaci贸n muestra al usuario una tarjeta con los productos y debe adivinar el precio.

Comencemos la inmersi贸n desde la primera etapa: decidimos la idea, realizamos an谩lisis, nos dimos cuenta de que el usuario ten铆a una necesidad y procedimos a crear una aplicaci贸n de voz.

Dise帽o


El objetivo principal es dise帽ar la interacci贸n entre el usuario y la aplicaci贸n. En el mundo m贸vil, esta etapa se llama dise帽o. Si el dise帽ador de aplicaciones gr谩ficas dibuja mapas de pantallas, botones, formas y selecciona colores, entonces el dise帽ador de VUI elabora el di谩logo entre el usuario y la aplicaci贸n: prescribe varias ramas del di谩logo, piensa en tenedores y escenarios secundarios, selecciona opciones de frase.

El dise帽o se lleva a cabo en tres etapas.

  • Ejemplos de di谩logos.
  • Dibujar un diagrama de flujo.
  • Elaboraci贸n de listas de avisos.

Ejemplos de di谩logo


Lo primero que debe hacer es comprender c贸mo funcionar谩 la aplicaci贸n. La comprensi贸n y la visi贸n deber谩n transmitirse a todos los dem谩s, especialmente si usted es una empresa de outsourcing y debe explicarle al cliente lo que finalmente recibir谩.

Una herramienta poderosa para ayudar son ejemplos de di谩logos: una conversaci贸n entre un usuario y una aplicaci贸n sobre roles , como en una obra de teatro.

Un ejemplo de di谩logo para nuestro juego.



La aplicaci贸n saluda, le dice al usuario sobre las reglas, ofrece jugar y, si la persona est谩 de acuerdo, muestra una tarjeta con los productos para que el usuario adivine el precio.

El script ayuda a comprender r谩pidamente c贸mo funcionar谩 la aplicaci贸n, lo que puede hacer, pero, adem谩s, los ejemplos de di谩logos ayudan a eliminar el error principal en el mundo de las interfaces de voz: trabajar en scripts incorrectos .

Hay una regla simple: si no puedes imaginar c贸mo est谩s hablando el gui贸n con otra persona, entonces no deber铆as trabajar en ello.

La voz y los gr谩ficos son significativamente diferentes, y no todo lo que funciona en interfaces gr谩ficas funciona bien en la voz. Casi todas las aplicaciones m贸viles tienen un registro, pero no puedo imaginar c贸mo puede registrarse por voz. C贸mo dictar una contrase帽a para una columna inteligente: "Una letra may煤scula, una letra peque帽a, es como un d贸lar ...", y todo esto en voz alta. 驴Y si no estoy solo, sino en el trabajo? Este es un ejemplo de un escenario de error. Si comienza a desarrollar un script con un error, habr谩 problemas con 茅l: no entender谩 c贸mo ejecutarlo, los usuarios no entender谩n c贸mo usarlo.

Ejemplos de di谩logos ayudar谩n a encontrar momentos similares. Para encontrar errores en los escenarios, escriba el di谩logo, seleccione un colega, si茅ntese enfrente y desempe帽e los roles: usted es el usuario, el colega es la aplicaci贸n. Despu茅s de leer la funci贸n de di谩logo, quedar谩 claro si la aplicaci贸n suena o no, y si ser谩 conveniente para el usuario.

Tal problema aparecer谩 constantemente. Si tiene un desarrollo interno, entonces surgir谩 la tentaci贸n: "Ya tenemos un sitio web, 隆simplemente convi茅rtalo en voz y todo estar谩 bien!" O el cliente vendr谩 y dir谩: 鈥淎qu铆 hay una aplicaci贸n m贸vil. 隆Haz lo mismo, solo con la voz! Pero no puedes hacer eso. Usted, como especialista, debe encontrar r谩pidamente escenarios en los que no deber铆a trabajar y explicarle al cliente por qu茅. Ejemplos de di谩logos ayudar谩n aqu铆.

Absolutamente cualquier editor de texto al que est茅 acostumbrado es adecuado para prescribir di谩logos. Lo principal es escribir el texto y leerlo por roles.

Diagrama de flujo


Los ejemplos de di谩logo son una herramienta poderosa, r谩pida y barata, pero describen solo un desarrollo lineal de eventos, y las conversaciones son siempre no lineales . Por ejemplo, en nuestro juego "Adivina el precio", el usuario puede responder la pregunta correcta o incorrectamente: esta es la primera bifurcaci贸n del conjunto de las que ocurrir谩 m谩s adelante.

Para no confundirse en todas las ramas del di谩logo de su aplicaci贸n, haga un diagrama de bloques: visualizaci贸n del di谩logo. Consta de solo dos elementos:

  • Paso de di谩logo en nombre del usuario.
  • Paso de di谩logo en nombre de la aplicaci贸n.



El diagrama de flujo es un mapa de nuestra aplicaci贸n, pero con una propiedad desagradable: crece fuertemente, se vuelve ilegible y visualmente incomprensible. Aqu铆, por ejemplo, hay una captura de pantalla con una parte de un diagrama de flujo de un escenario en el que el usuario adivina el precio, con varios tenedores.



Varios tenedores no son el l铆mite, puede haber decenas o cientos de ellos. Nos hicimos preguntas: 鈥溌縌u茅 sucede si una persona responde correctamente? Y si no? 驴Qu茅 pasa si los intentos terminan? 驴Qu茅 pasa si las mercanc铆as se agotan? 驴Y si adivina el precio con seguridad? 驴Qu茅 pasa si Internet se cae en este paso u otro? Como resultado, creamos un enorme esquema ilegible.

No estamos solos en esto. Habl茅 con un dise帽ador de EE. UU. Que estaba trabajando en un proyecto serio. El proyecto ten铆a IVR, un banco y habilidades al mismo tiempo, y todo esto infl贸 un diagrama de bloques de hasta 600 hojas. Nadie entendi贸 el esquema hasta el final, y cuando la dise帽adora lo vio, simplemente se horroriz贸.

Tengo consejos sobre c贸mo prevenir esto. El esquema siempre crecer谩, pero nunca intente construir un diagrama de bloques grande para toda la aplicaci贸n ; ser谩 engorroso y nadie, excepto usted, lo comprender谩. Vaya desde el lado opuesto y divida el diagrama en partes l贸gicas : un escenario separado de adivinaci贸n de precios, un escenario separado de ayuda. Divide estos escenarios en subescenarios seg煤n sea necesario. El resultado no es un gran mapa con conexiones incomprensibles, sino muchos circuitos peque帽os, legibles y bien conectados en los que todos se sienten c贸modos para navegar.

Para diagramas de bloques, cualquier herramienta es adecuada. Sol铆a 鈥嬧媢sar RealtimeBoard , y tambi茅n hay Draw.io e incluso XMind . Como resultado, desarroll茅 el m铆o, porque es m谩s conveniente. En la imagen solo se presenta. Esta herramienta tambi茅n admite sub-scripting.

listas de avisos


El 煤ltimo artefacto que formaremos en la etapa de dise帽o. La lista de solicitudes es una lista de todas las frases posibles que la aplicaci贸n puede pronunciar.

Hay una sutileza. La conversaci贸n con la aplicaci贸n debe ser flexible y similar a una conversaci贸n con una persona. Esto significa no solo la capacidad de atravesar diferentes ramas, lo que hicimos en la etapa del diagrama de flujo, sino el sonido de la conversaci贸n en su conjunto. Una persona nunca responder谩 con la misma frase si hace la misma pregunta. La respuesta siempre ser谩 parafraseada y sonar谩 de alguna manera diferente. La aplicaci贸n debe hacer lo mismo, por lo que para cada paso del di谩logo en nombre de la aplicaci贸n, escriba no una opci贸n de respuesta, sino al menos cinco.



Seg煤n las hojas de instrucciones, hay otra cosa importante. La comunicaci贸n no solo debe ser viva y flexible, sino tambi茅n coherente en t茅rminos de estilo de discurso y el sentimiento general de interacci贸n del usuario con su aplicaci贸n. Para esto, los dise帽adores usan una t茅cnica excelente: crear un personaje . Cuando llamo a mi amigo, no lo veo, pero inconscientemente me imagino a mi interlocutor. El usuario tiene lo mismo cuando se comunica con un altavoz inteligente. Esto se llama pareidalia .

En la etapa de hojas de solicitud, crea un personaje en nombre de qui茅n hablar谩 la aplicaci贸n. Sus usuarios asociar谩n la marca y la aplicaci贸n con el personaje; puede ser una persona real o ficticia. Trabaje para 茅l apariencia, biograf铆a, personaje y humor, pero si no hay tiempo, simplemente traiga todas sus frases en las hojas de instrucciones a un solo estilo. Si comenz贸 a ponerse en contacto con el usuario en "Usted", no se ponga en contacto con otros lugares en "Usted". Si tiene un estilo informal de comunicaci贸n, mant茅ngalo en todas partes.

Por lo general, las hojas de c谩lculo de Excel o Google se utilizan para crear hojas de solicitud, pero con ellas hay grandes p茅rdidas temporales en el trabajo de rutina. El diagrama de flujo y la tableta con las frases no est谩n conectados entre s铆, los cambios deben transferirse manualmente, lo que se traduce en una rutina constante y larga.

No uso Excel, pero mi herramienta, porque en 茅l todas las frases est谩n escritas directamente en el diagrama de flujo, se asignan al paso de di谩logo. Esto elimina la rutina.

Al dise帽ar, elaboramos cada escenario: escribimos un ejemplo de di谩logo, buscamos ramificaciones laterales, errores, lo cubrimos con un diagrama de flujo y luego trabajamos en el estilo del discurso y las frases.

Parece que ahora todo est谩 listo y puede asignar la tarea a los desarrolladores y acceder al c贸digo, pero a煤n queda una etapa m谩s importante: las pruebas. Tenemos que asegurarnos de que, como dise帽adores, hagamos todo correctamente, que la aplicaci贸n funcione como queremos, que todas las frases tengan el mismo estilo, que hayamos cubierto todas las ramas laterales y procesado todos los errores.

Prueba


Las pruebas en esta etapa temprana son especialmente importantes para las aplicaciones de voz. En el mundo de las interfaces gr谩ficas, el usuario est谩 limitado por lo que el dise帽ador dibuj贸: no ir谩 m谩s all谩 de la pantalla, no encontrar谩 un bot贸n que no existe y solo har谩 clic en lo que est谩 ...

En el mundo de las voces, esto no es as铆: el usuario es libre de decir cualquier cosa y usted no sabe c贸mo comenzar谩 a trabajar con su aplicaci贸n hasta que la vea. Es mejor hacer esto en una etapa temprana de dise帽o y prepararse para lo inesperado hasta que el costoso desarrollo haya comenzado.



Las aplicaciones se prueban utilizando la metodolog铆a Wizard of Oz . Se utiliza en aplicaciones gr谩ficas, pero con menos frecuencia, y en voz es imprescindible. Este es un m茅todo cuando el usuario interact煤a con el sistema, suponiendo que existe y funciona por s铆 solo, pero usted controla todo el proceso.

Las pruebas se realizan utilizando prototipos interactivos. Por lo general, el dise帽ador tiene que pedirles a los desarrolladores que creen un prototipo, pero personalmente uso mi herramienta, porque todo se hace con un solo clic y no hay necesidad de esperar a nadie. Tambi茅n necesitamos un usuario. Llamamos a una persona que no est谩 involucrada en el desarrollo, que no sabe nada sobre la aplicaci贸n e, idealmente, est谩 incluida en su p煤blico objetivo. Invitas a una persona, explicas qu茅 tipo de aplicaci贸n es, c贸mo usarla, plantarla en una habitaci贸n, encender un prototipo interactivo y el usuario comienza a hablar con 茅l. El prototipo no reconoce el habla y escucha lo que dice la persona y elige la opci贸n de respuesta mediante la cual la aplicaci贸n responde a cada frase.

Si el usuario no ve la pantalla, le parece que la aplicaci贸n funciona por s铆 sola, pero usted controla el proceso. Esto est谩 probando al Mago de Oz. Con 茅l, no solo escuchar谩 c贸mo suena la aplicaci贸n, sino que tambi茅n ver谩 c贸mo las personas la usan. Le garantizo que encontrar谩 muchos escenarios descubiertos.

Cuando prob茅 el juego, llam茅 a mi amigo. Comenz贸 a adivinar el precio y dijo que alg煤n tipo de ung眉ento val铆a "cinco chozas". No esperaba tal palabra, pens茅 que habr铆a opciones de 500 rublos, mil rublos, y no una "choza de cinco" o "segar". Esto es un poco revelado durante las pruebas. La gente usa la aplicaci贸n de manera diferente a lo que imaginas, y las pruebas revelan tales bagatelas y escenarios inoperantes.

Pruebe mucho y durante mucho tiempo antes del desarrollo, hasta que est茅 seguro de que la aplicaci贸n funciona y los usuarios interact煤en con ella como espera.

En esta etapa, finaliza la fase de dise帽o y tenemos a mano ejemplos de di谩logos, un diagrama de bloques es una descripci贸n l贸gica de la aplicaci贸n, y las listas de avisos son lo que dice la aplicaci贸n. Le daremos todo esto a los desarrolladores. Antes de contarte c贸mo los desarrolladores crean aplicaciones, compartir茅 consejos de dise帽o.

Consejos


Use el lenguaje de marcado SSML , como HTML, solo para voz. SSML le permite pausar, establecer el nivel de empat铆a, estr茅s, registrar qu茅 leer y deletrear.



El discurso etiquetado suena mucho mejor que el robot, y cuanto mejor suena la aplicaci贸n, m谩s agradable es de usar. As铆 que use SSML, no es tan complicado.

Piense en los momentos en que los usuarios recurren a su aplicaci贸n para obtener ayuda. Para la voz, esto es especialmente importante. Una persona puede hablar con un orador solo en una habitaci贸n, o puede viajar en autob煤s y hablar con un tel茅fono inteligente. Estos son dos escenarios de comportamiento fundamentalmente diferentes para una aplicaci贸n de voz. Tuvimos una situaci贸n similar con una aplicaci贸n bancaria. Hab铆a un script en la aplicaci贸n cuando el usuario recibe informaci贸n sobre la cuenta, y esta es informaci贸n privada. Pens茅: si una persona est谩 hablando en casa, entonces todo est谩 bien, pero si viaja en un autob煤s y la aplicaci贸n comienza a expresar el saldo de la tarjeta en voz alta, ser谩 feo.

Pensando en esos momentos, puede determinar que si el usuario est谩 hablando con el tel茅fono inteligente, incluso con una voz, es mejor no leer la informaci贸n privada en voz alta, sino mostrarla en la pantalla.

Utilice dise帽o multimodal.

Este es un dise帽o para diferentes superficies y plataformas. Los dispositivos de voz son muy diferentes en textura. En el mundo m贸vil, los dispositivos difieren solo en plataforma y tama帽o de pantalla, factor de forma. Con una voz, todo es diferente. Por ejemplo, la columna no tiene una pantalla, solo una voz. El tel茅fono inteligente tiene una pantalla y puede tocarlo con el dedo. El televisor tiene una pantalla enorme, pero es in煤til tocarlo. Piense en c贸mo funcionar谩 su aplicaci贸n en cada una de estas superficies.

Por ejemplo, un usuario realiz贸 una compra y queremos mostrar el cheque. Leer el cheque en voz alta es una mala idea, porque hay mucha informaci贸n y nadie la recordar谩, ya que la informaci贸n de voz se percibe como dif铆cil y dif铆cil.



, , , , , . , .

. , 鈥 , . , , .



. , Amazon Alexa, Google Assistant.



, . - , .

  • intent , 鈥 , : , , webhook , . - webhook, , API.
  • .


Dialogflow , , , .

鈥 Natural Language Understanding 鈥 NLU.

Dialogflow




Dialogflow, , , . Dialogflow : 鈥 Google Assistant, -, Amazon Alexa Telegram . 鈥 API. , .

Dialogflow.

  • Agent 鈥 , , .
  • Intents 鈥 .
  • Entities 鈥 .
  • Contexts 鈥 , .

, 鈥 Intents.

Intents


, , . . , : 芦 禄, 芦, ?禄, 芦 鈥 禄 - . , Intent , , .

10 . , Dialogflow , 10 , , . , , .

Intent . Dialogflow , , webhook. , 鈥 : , .

芦禄 鈥 . , Google Assistant , , , . Google Assistant , .

Entities


Intent , - . 鈥 , , 鈥 Entities . , , , , . : .



. 芦 禄, . , 鈥 . , :

?
!

Dialogflow re-prompt 鈥 , , . . - : 芦 , ...禄

鈥 Entities. Dialogflow 鈥 , , . , , , , . Dialogflow 鈥 . ^ , , , . , , . : 芦禄, Dialogflow , 芦禄

Context


: context 鈥 , . , : 芦 ?禄 , . , . , : 芦 禄, . Google , 鈥 .



context芦 鈥 禄 , . Intent context , -, . context . : , 5 , .

context 鈥 : , . , Intent, context , Intent. .



webhook. Dialogflow , JS. Google Assistant webhook 鈥 , 5 , fallback. , 鈥 1,5 3 .

, webhook , QA, .





, , .

, . . , .

:

  • . ., . , 芦 禄, , .
  • , , .

Google Assistant , 鈥 芦, Google, ...禄. , , : 芦, Google, Uber禄 鈥 , . , : 芦, Google, Uber !禄 , .

, . , 鈥 . , 芦 禄 , 芦 禄 . , 芦禄 芦禄 Google Assistant. , , .

, . Google Assistant , , .

.

  • Alpha 鈥 20 .
  • Beta 鈥 200 .
  • Production- 鈥 store. Production, . Google , , . , . , , .

, , , 鈥 .



. , , 鈥 , , .

. , Dialogflow :

  • 鈥 .
  • 鈥 , , , .

, . - : 芦4 禄. 芦禄 , 芦禄 鈥 .



, , .

. , . , , - .



-
- .
Slack- Amazon Alexa
Slack- Google Assistant
Google Assistant
Amazon Alexa
芦Designing VUI禄 Cathy Pearl
芦VUX best practices, Voicebot禄
Medium
Google Assistant
Amazon Alexa
.
,

: Twitter Linkedin , Medium .

AppsConf 2019 se llevar谩 a cabo en el centro de Mosc煤, en Infospace, los d铆as 22 y 23 de abril. Prometemos a煤n m谩s utilidades de desarrollo m贸vil que el a帽o pasado, as铆 que reserve un boleto o deje una solicitud de informe .

Para mantenerse al tanto de las noticias y anuncios de informes, suscr铆base a nuestro bolet铆n y al canal de YouTube para el desarrollo m贸vil .

隆Solo AppsConf, solo hardcore!

Source: https://habr.com/ru/post/437586/


All Articles