Construye una app desde cero en Figma con Bravo Studio

En esta ocasión quiero hablar directamente a aquellos diseñadores UX-UI de la sala. A los de las esquinas también, acercaos. Esto os va a hacer explotar la cabeza.

Si no eres diseñador, pero te gusta hacer tus pinitos con esto de las interfaces, lo que vamos a ver aquí también te va a cambiar la vida. Literal.

Porque, ¿qué me dirías si te cuento que ese diseño de una app, que tenías guardado en el cajón, puedes llevarlo a la vida sin una sola línea de código? Sin plantillas, widgets, elementos predefenidos… Desde cero. Totalmente personalizado.

Las reglas del juego han cambiado y, seguramente, ya sepas qué es esto del NoCode. Pero hoy quiero hablaros de una herramienta brutal. Es Bravo Studio y, cuando la conozcas, va a pasar a liberar tu imaginación.

¿Quieres conocerla? Pues vamos allá.

‍

El funcionamiento de Bravo es sencillo. Tú tienes una idea de app. Diseñas la interfaz en Figma o Adobe XD y preparas el backend en Airtable, Xano, Backendless o Notion, entre otras.

Ambas cosas, diseño y backend, las metes en la coctelera que es Bravo y sale tu app. Lista para subir a las stores de Android e iOS.

¿Parece sencillo? Lo es. Pero claro, como todo en esta vida, dependerá de lo que quieras complicarte.

Vamos a ver ahora qué vas a aprender en este curso.

‍

Vamos a conocer cómo funciona Bravo. Será una aproximación completa a la herramienta. Desde la idea inicial, pasando por el diseño (que haremos en Figma), la elaboración de la base de datos en Airtable, las diferentes llamadas API y la conexión de todo en Bravo.

Lo haremos mediante el diseño de una app para un restaurante. Te cuento la premisa:

Imagina que eres el dueño de una cadena de restaurantes de hamburguesas de autor en tu localidad y cuentas con varios locales (ojo, ya aquí estaríamos hablando de palabras mayores, de negociazo en mayúsculas).

Resulta que quieres dar a conocer tu carta, quieres facilitar información sobre ingredientes y alérgenos y quieres mostrar tus datos de contacto. También te gustaría informar a tus clientes de promociones, novedades en la carta, horarios especiales… En definitiva, quieres llevar un paso más allá tu ficha de Google My Business.

Pues bien. Esto es lo que vamos a diseñar. Desde el primer icono, hasta una app que podría subirse, sin ningún problema, a las tiendas de aplicaciones de Apple y Google.

Para ello vamos a conocer:

• Cómo debemos diseñar en Figma. Spoiler: la casa, siempre bien ordenada; Figma, también.
• Qué es un container y cuáles son los diferentes niveles jerárquicos.
• Las etiquetas en Bravo y la magia que desencadenan
• Pasaremos nuestro diseño de Figma a Bravo Studio y probaremos la primera versión de la app en nuestro móvil.
• Definiremos la base de datos en Airtable
• Conectaremos nuestra base de datos con Bravo Studio y configuraremos las diferentes llamadas de listado de elementos y detalle.
• Enlazaremos los datos de nuestra base a los elementos del UI de nuestro diseño.
• Conectaremos notificaciones a la app para informar a nuestros usuarios.

Completo el tema, ¿no? Pues todo esto lo vamos a hacer, paso a paso, montando nuestra app para la cadena de restaurantes que regentamos.

Si tú eres dueño de una, estás de de enhorabuena. Cuando acabes este curso, podrás lanzar tu app y darle a tus clientes un servicio mucho más premium. Eres libre de calcar lo que vamos a ver aquí.

¿Empezamos?

‍

Vamos a dar por sentadas ciertas bases antes de comenzar. Si estás aquí, es, en cierto modo, porque ya sabes manejar Figma o XD. Al menos los fundamentos básicos.

Si no es así, no te preocupes. Vamos a ir viendo técnicas y herramientas a lo largo del curso y, para trabajar con Bravo, serán más que suficientes. Pero te aviso (y quien avisa no es traidor): esto no es un curso de Figma.

Sentados estos principios, lo primero que debemos entender es cómo se estructura la información en Figma para que el diseño se ejecute en Bravo. La base de todo son los container.

En Figma, estos container son frames y los hay de diferentes niveles. Vamos a verlos:

En el primer nivel, estaría el top-level container. Esto se refiere a un frame que representa la pantalla que estamos diseñando. Sería como el Body de una web. Dentro de este frame, que representa el tamaño de una pantalla (iPhone, Samsung…), iremos incorporando las diferentes secciones.

Estas secciones que están dentro del top-level son containers y en ellos vamos a ir introduciendo los diferentes elementos que conformarán nuestro diseño. Estos pueden ser:

⁃ Estáticos: tal como los vemos en el diseño se mostrarán en la app final. (Ej: títulos, botones, menús…

⁃ Dinámicos: estarán conectados con una base de datos y mostrarán un campo concreto relacionado. (Ej: textos, imágenes, títulos dinámicos…)

Tenemos cards donde mostrar información, títulos, imágenes, botones, mapas… Lo que queramos. Estos elementos irán dentro de estos containers para que Bravo pueda trabajar con ellos.

Ya sabemos cómo funcionan la organización que necesitamos. Ahora vamos a complicarlo un poco más con las etiquetas.

De momento no vamos a entrar en detalle con ellas, porque las vamos a ver a fondo en otra lección. Sólo quiero que aprendas la más importante de todas: [container]. Como ves, la etiqueta se compone de una palabra entre dos corchetes. Así será la estructura para todas las etiquetas de Bravo, aunque con variantes.

Dentro de los container tenemos, además, varios tipos. Vamos a verlos, de nuevo, con nuestro esquema.

En el primer nivel vemos un tipo de container, en este caso [container:top-bar] Esto quiere decir que todo lo que esté dentro de ese container se mantendrá fijo en la parte superior de la pantalla. Aquí podemos meter nuestros menús de hamburguesa, el logo de la app, un botón recurrente… Lo que quieras que se quede siempre quieto en la parte de arriba.

Más elementos. En este caso un slider. También, la sección lleva la etiqueta [container] pero ahora acompañada de :slider y el tipo de visualización que queremos, por ejemplo default.

El siguiente container lleva una etiqueta de [container] a secas y, como ves, no ocupa el ancho de la pantalla. Esto es porque este container va a mostrar un listado de elementos y queremos que lo haga a doble columna. Por ese motivo, sólo colocamos el primer elemento de ese listado, le otorgamos la etiqueta al container y, posteriormente en Bravo, indicaremos que ahí tiene que mostrar un listado de elementos sacados de nuestro backend. Lo veremos pronto, no nos anticipemos. Este listado, evidentemente, también puede ser a una columna y ocupar todo el ancho de la pantalla.

Como ves, dentro de cada container metemos los elementos que consideremos. Asegúrate bien  que en el índice de elementos que ves a la izquierda están todos dentro de ese container y que, además, están bien nombrados.

Consejo: todos los elementos deben tener nombres lo más descriptivos posibles, te dejo a tu elección la nomenclatura. Pero, ahora bien, es fundamental que marques de alguna manera qué elementos van a ser dinámicos, porque luego, a la hora de coserlo todo en Bravo, el lío puede ser monumental.

¿Y dónde colocamos estas etiquetas? Lo hacemos en el índice de elementos que tenemos a la izquierda.

Insisto. Para los del “en mi desorden mando yo” o “yo es que soy muy anárquico, pero trabajo solo y da igual”. No, no da igual. Trabajar en Figma te exige que seas lo más ordenado posible. Si vas a trabajar con Bravo, mucho más.

Puede ser, por ejemplo, que veas que un elemento está dentro de un container mientras trabajas en el canva y luego, cuando llegas a Bravo y quieres visualizar la app, ese elemento no aparece, da error o, simplemente, se ha ido de vacaciones a otro lugar de la pantalla. Este error, tremendamente común, es porque, a veces, cuando movemos los elementos, los sacamos de ese container dentro del índice de la izquierda. Mucho ojo con eso, puede ser un auténtico quebradero de cabeza.

Ya conocemos la organización de los elementos. Ahora vamos a empezar a diseñar.

‍

‍

Nos metemos en el ajo. Vamos a diseñar la primera pantalla de nuestra aplicación.

Recordamos. Queremos hacer una app de una cadena de restaurantes.

Lo primero que vamos a hacer es definir ciertas cosas que nos van a hacer la vida mucho más sencilla. Vamos marcar los tamaños de letra que vamos a usar, las tipografías, los colores y cualquier cosa que vayamos a reutilizar varias veces.

Por ejemplo. Si hago una card y esa card se va a replicar en varias pantallas, la agruparé, la convertiré en un componente y la podré usar varias veces, simplemente copiando y pegando. De hecho, al copiar y pegar, se genera una variante de ese componente que podremos editar, por ejemplo cambiándole el título, el color… si así lo deseamos, sin tocar el original. Útil, ¿verdad?

También será tremendamente útil que configures un grid para ubicar los elementos y alinearlos. A mí me gusta diseñar con grids de 6 columnas, con un margen de 16 px y un espaciado entre columns (gutter) de 8 px.

Cuando tengamos todos estos elementos diseñados y determinados, vamos a empezar con las pantallas. La primera, la Home.

‍

‍

Vale. Esto ya empieza a coger forma. Tenemos parte de las piezas del puzzle. Ahora las vamos a meter en sus correspondientes containers.

Empezamos creando un frame para nuestra pantalla. Lo haremos utilizando el icono o pulsando la tecla F. En la parte derecha nos van a salir diferentes tipos de pantalla. Nosotros vamos a elegir el tamaño de un iPhone 11 Pro/X.

Lo primero que vamos a hacer es la sección Hero de nuestra Home. El Hero es la parte superior de cualquier app o web.

Este Hero va a contener nuestro logo y el icono del menú de hamburguesa. Nada más. Colocaremos, por ejemplo, el logo a la izquierda y el menú hamburguesa a la derecha. ¿Por qué? Pues por una cuestión meramente estadística: hay menos zurdos que diestros (yo soy zurdo y esto me jode), pero si queremos facilitar la navegación, debe de ser así. De todas formas, te invito a que hagas pruebas de usabilidad de tu app con posibles usuarios. Vas a flipar con las conclusiones que puedes llegar a sacar cuando sales de tu cabeza y entras en la de otros.

El Hero queremos que sea una topbar, así que utilizamos en el container la etiqueta [container:top-bar].

Ojo. Cuando hagamos scroll, las diferentes secciones se mostrarán por debajo de esta topbar, por lo que te recomiendo que pongas un relleno de color a este container, en las opciones del frame en la parte derecha.

Seguimos. Después del Hero vamos a poner unos botones para que el usuario elija la carta del tipo de comida que quiere ver. Estos tres botones son elementos estáticos, y enlazan con cada una de las cartas de alimentos. Están formados por una imagen y un texto. Para que todo esté perfectamente alineado, utilizaremos el AutoLayout de Figma.

En este caso, te pregunto: ¿necesitamos poner la etiqueta [container] en el frame que va a albergar esos botones?

La respuesta es no. Al no contener elementos dinámicos, Bravo no necesita que le indiques. Si quieres hacerlo, puedes, lógicamente. De hecho es una buena práctica que te acostumbres a poner esta etiqueta. Pero en este caso, necesario no es.

Tampoco es necesario que lo hagamos en los títulos de cada una de las secciones. Mi recomendación es que, de hecho, separes los títulos de los container. En este caso, tenemos el título de “hamburguesas destacadas del mes” junto a un botón de “ver todas”. Ambos elementos conforman, ellos solos, un container al que no le pondremos la etiqueta porque tampoco vamos a conectarlo con nada.

Lo siguiente será precisamente, la sección con las hamburguesas destacadas del mes. Lo haremos con un slider y utilizaremos el tipo default [container:slider:default]. Sólo diseñamos el primer elemento de ese slider porque el resto lo vamos a sacar de un listado dentro de nuestro backend.

Cada una de las cards que contendrá este slider contiene una imagen de la hamburguesa, su nombre, una muy breve descripción y su precio.

Para insertar una imagen tenemos que hacerlo a través de un rectángulo al que le daremos el relleno de tipo imagen. Este rectángulo con imagen podemos escalarlo. También podemos usar una imagen con canal alfa, en png, para que aparezca sin fondo. No hay problema.

Tampoco hay problema para conectar esta imagen a un campo de nuestra base de datos. En el caso de este slider será así. La imagen vendrá determinada por el backend. Luego lo vemos.

Por último, vamos a hacer un listado con los restaurantes que tenemos en la ciudad. Lo haremos poniendo en un lado una imagen y en el otro el nombre del restaurante y su ubicación junto a un botón de reserva. De nuevo, utilizaremos el AutoLayout para que todo esté bien alineado.

El botón de reserva, al ser pulsado, nos abrirá el número de teléfono del local y nos dará la opción de llamar. Por que funcione, este elemento llevará la etiqueta [action:phone]

Ya tenemos nuestra primera pantalla, nuestra Home. Sencillo, ¿verdad? Vamos a meterle más chicha.

‍

Con la Home diseñada, ¿te gustaría ver lo que has hecho en el móvil? Vamos a empezar con el proceso de Bravorización de nuestra app.

Para ello, nos vamos a Bravo, y pulsamos en crear una nueva app. Nos pedirá el enlace de Figma, lo copiamos y lo pegamos aquí. Tras unos segundos, veremos nuestra pantalla en Bravo. Si hubiese algún tipo de error, la herramienta lo detectará y te ofrecerá un mensaje en la parte superior. Mola mucho porque, si pulsas en Fix, te va a llevar al elemento exacto de Figma que está dando la lata.

Lo siguiente que necesitamos es instalar la app de Bravo Vision en nuestro móvil. Hacemos login en nuestra cuenta y ya veremos la app en ella. Entramos y, desde ya, podremos ir viendo y probando los cambios que vamos metiendo a nuestro diseño.

Esto es brutal porque, cuando ya tengas más avanzada tu app, te va a permitir invitar a usuarios early adopters que te van a dar el primer feedback de tu trabajo. Ya sabes: idear, diseñar, probar e iterar.

‍

‍

Después de esta parte, lo mismo te entra el hambre. Espera un segundo antes de ir a picar algo a la nevera.

En este caso vamos a diseñar la pantalla en la que listaremos las hamburguesas que tenemos en la carta. Para ello, de nuevo, vamos a tener tres secciones claramente definidas: el Hero (Top-Bar), el título de la página (“Nuestras hamburguesas”) y un listado con todas las hamburguesas que tenemos en el menú.

Lo primero, la top-bar. En este caso no vamos a poner el logo. En su lugar pondremos un botón con una flecha hacia atrás para determinar que desde ahí retrocedemos. Este icono puedes hacerlo tú desde cero, si te sobra el tiempo. Si no es el caso, te recomiendo que utilices un plugin de Figma que se llama Iconify y en el que puedes encontrar miles de opciones. Al seleccionar el icono que quieres, lo introduces en el container que quieras y verás que está dentro de otro frame. Utiliza ese frame para escalar el icono y colocarlo donde quieres. Así todo estará más ordenado.

En este punto, entra en juego otra etiqueta [action:goback] Podemos ubicarla en ese frame que contiene todo el icono. Esta etiqueta nos llevará a la página que habíamos visitado justo antes. Pero ojo, y esto es un problema de Bravo, no siempre funciona bien. Hay veces que, de manera incomprensible, no te lleva hacia atrás y, simplemente, no pasa nada. Ante estos casos, debemos plantear la necesidad de conectar, en el prototipado, esta flecha con la página que consideremos. Pero, claro, esto no hará una navegación natural. Tenlo en cuenta.

Bien. Ahora vamos con otra de esas funciones que son todo un must: el buscador. Diseñaremos un cuadro con el icono de una lupa y un texto placeholder que indique la acción de buscar.

Para que funcione necesitamos poner estas etiquetas en la capa de texto[component:input-text][

action:filter] Verás que aquí tenemos dos etiquetas en una. Te explico. Lo que le indicamos a Bravo es que ese texto será sustituido por lo que busque el usuario y que, mientras escribimos, busque entre todos los elementos de la página y filtre. Repito: todos los elementos de la pantalla, dinámicos y estáticos. Es decir, lo que va a buscar es coincidencias entre lo que hemos escrito y todo lo que hay en la página. Por eso no es un buscador como tal, pero nos puede valer.

No es un buscador como tal porque no está haciendo la acción de buscar sobre nuestra base de datos. Para hacer esto nos tendríamos que ir a un nivel algo más avanzado. Lo explico en el proceso de creación de Safe Scooter.

Una última cosa y muy importante sobre este buscador. La etiqueta siempre debe ir en un container top-bar. Inapelablemente. Si lo ponéis en otro lado de la pantalla o en otro container que no sea top-bar, no va a funcionar.

Terminada esta top-bar, seguimos con el diseño. El siguiente container incluye el título. Ya hemos visto que aquí no necesitamos marcar nada, a no ser que el texto sea dinámico. No es el caso. Por tanto, seguimos.

La última parte de esta pantalla es el listado de las hamburguesas. En este caso, y a diferencia del listado que teníamos en la Home, vamos a hacerlo a dos columnas. ¿Cómo? Muy sencillo: el container no puede ocupar de ancho más que la mitad del ancho de la pantalla. En este caso, mucho ojo con los diferentes tamaños de pantallas para los diferentes dispositivos, pueden jugarte una mala pasada.

Bien,ahora colocamos los elementos. En este caso, la card llevará una imagen de la hamburguesa, su nombre y su precio.

Insisto. Debes de dejar un margen en el container para que no termine de tocar el centro de la pantalla. De este modo nos aseguramos que no va a descuadrarse el diseño cuando lo rellenemos con datos dinámicos.

‍

Vamos con otra página de lista. En este caso, mostraremos todos los restaurantes que tenemos. Para ello, lo de siempre: una sección como top-bar que contiene el botón de menú y de ir hacia atrás, un título de la sección y la propia sección de listado.

Aquí, antes del listado, vamos a poner un mapa en el que, en base a las coordenadas que le fijemos en el backend, nos va a mostrar los resultados con marcadores.

El listado de restaurantes ya hemos visto cómo se hacía en la Home. De hecho lo vamos a copiar y pegar desde ahí. Pero, ¿y el mapa?

¡Ah, amigo! Los mapas me flipan. Es un elemento visual tremendamente atractivo y que va a darle un plus a tu diseño. Sin duda.

¿Cómo se configura? Muy fácil. Hacemos un rectángulo y la damos la etiqueta de [component:map] Evidentemente lo metemos en un container con su correspondiente etiqueta [container]

A esta etiqueta podemos añadirle más cosas. Por ejemplo, si queremos que el usuario pueda mover el mapa y hacer zoom a través de él, la etiqueta pasaría a ser asi: [component:map:interactive]

Si además queremos que esté centrado en unas determinadas coordenadas fijas, debemos añadirle [component:map:40.417179575849254:-3.7031078792149326:16] El número del final, en este caso el 16, marcaría el nivel de zoom que queremos aplicar al mapa.

Mucho cuidado. A la hora de la usabilidad, debes pensar en facilitar el scroll del usuario. Si este hace scroll sobre una superficie del mapa y el mapa es interactive, lógicamente lo que se moverá es el mapa. Punto de dolor. Te lo digo porque todas estas cosas restan amigabilidad y crean fricción. Si quieres que el usuario haga scroll en la pantalla, plantéate si es necesario que el mapa sea interactive.

Por último, si queremos que nuestro mapa tenga un marcador determinado, podemos diseñarlo en una página aparte y utilizar la etiqueta [asset:marker:default] De este modo, siempre que no indiquemos lo contrario desde el backend, el marcador que se vea en el mapa será ese. Una cosa importante: las medidas de este marcador deben de ser pequeñas para que no se descuadre.

‍

Ojo, porque si has llegado hasta aquí, ya tienes unas bases muy sólidas para ir diseñando lo que quieras y necesites. Estás en el buen camino, mi pequeño o pequeña padawan.

Ahora vamos a conocer las páginas de detalle y un elemento que es una cucada: los modales.

Aquí no vamos a tener listados. Sólo necesitamos containers que van a albergar diferentes datos dinámicos.

Por ejemplo, vamos a hacer la pantalla de detalle de cada hamburguesa. Esta va a contener el top-bar correspondiente con la navegación y un container en el que vamos a poner parte de los datos del plato y la descripción. Esta descripción llevará la etiqueta de [flexo] Esta etiqueta sólo puede ir en un elemento de texto y sólo en el elemento texto que esté situado en la parte más inferior de un container. Lo que hará esta etiqueta es adaptar la extensión del container al texto que pongamos. Muy útil para textos largos.

Además, en otro container tendremos dos botones que mostrarán la información de ingredientes y de alérgenos. Estas dos cuestiones las vamos a abrir en modales.

Pero, ¿qué es un modal? Es una pantalla que se abre deslizándose y que ocupa un porcentaje X de la pantalla, manteniendo debajo la pantalla de la que veníamos. Ese modal se cierra deslizándolo hacia abajo.

¿Cómo lo haremos? Crearemos una página aparte y en ella, en el container top-level, le indicaremos la etiqueta [page:modal:50%] Como ves, en esa etiqueta hay un porcentaje. Este señala cuánto va a ocupar este modal en la pantalla.

En nuestro caso, el modal de los ingredientes ocupará un 50% y el de los alérgenos un poco menos, un 40%.

Dentro de cada modal pondremos un texto que se rellenará desde el backend.

Bueno, ya tenemos esto súper encarrilado.

Otra de las páginas que diseñaremos será el detalle de cada restaurante, donde incluiremos, por ejemplo, la imagen del mismo, su nombre, su dirección, los botones a las diferentes cartas de alimentos (que podemos copiar y pegar desde la Home) y un botón de reserva que nos marque el teléfono del restaurante, igual que en la Home.

‍

Vale. Ya tenemos prácticamente la app diseñada y nos ha servido para conocer un buen número de etiquetas, las más comunes. Pero, Bravo tiene muchísimas más etiquetas y ahora es un gran momento para aprenderlas.

A ver. Si te aprendes todas de memoria, escríbeme y hablamos de negocios, ¿vale? Esa cabeza no puede desaprovecharse.

Para el resto de los mortales, dos recursos:

⁃ La Bravo Tag Master List. O lo que es lo mismo, un directorio de Notion con todas las etiquetas agrupadas por tipos, la indicación del lugar donde debe ser colocada dentro del diseño, una descripción y, en algunos casos, ejemplos de templates de Figma para que las veas en acción (práctica muy recomendada)

⁃ Si ya has trasteado con las etiquetas y sabes lo quieres, en Figma hay un plugin que se llama Bravo Studio Tag Manager. Seleccionas el elemento, buscas la etiqueta que quieres y la aplicas. Es súper rápido y útil. Adoro Figma.

Antes de abandonar el diseño y meternos en el laboratorio, pueder ver en el vídeo anterior, grupo a grupo, qué hace cada una de las etiquetas.

También puedes bucear por la Bravo Tag Master List. Es un ejercicio tremendamente útil para dejar volar la imaginación.

‍

‍

A esta app tan sumamente bonita le falta algo. Y es una navegación adecuada. Ya pusimos el botón hamburguesa para acceder al menú. Ahora falta hacerlo.

En Bravo tenemos varios tipos de menús:

⁃ Tab menú: el menú se sitúa en la parte inferior de la pantalla. [menu:tabs]

⁃ Modal menú: el menú ocupa toda la pantalla [menu:modal]

⁃ Slide menú: el menú se desliza desde el lateral izquierdo y ocupa parte de la pantalla. Este es el que vamos a usar. [menu:slide]

Para ello, creamos un nuevo frame y dentro un container que vaya a toda la pantalla en lo alto y a la mitad a lo ancho. Dentro le daremos un fondo y pondremos los diferentes enlaces que queremos. En el top-level frame, le marcaremos la etiqueta [menu:slide], como veíamos anteriormente.

Ya lo tenemos. Ahora sólo necesitamos que todos los botones de menú hamburguesa apunten hacia aquí. Y lo haremos en el prototipado.

‍

‍

Si ya conoces Figma, esta parte puedes saltártela. Si no, vamos a pasar por ella rápido.

Ya tenemos el diseño hecho, ahora queremos que todo se conecte. Es decir, cuando yo pulso un botón, que este me lleve donde dice apuntar.

Esto se hace desde Figma y, en concreto, desde la opción de prototype que encontrarás en la parte superior derecha de la pantalla.

Lo que tenemos que hacer es ir seleccionando los elementos, irnos a la bolita que aparece en la parte lateral y arrastrar las flechas hacia donde apunta. Así con todas las partes del diseño que enlacen con otras.

Por último, verás que al dar a prototype aparece un cuadro azul con un triángulo en una de las pantallas, en la esquina superior izquierda. Ese cuadrado marca el inicio del flujo de navegación. Si no está en la Home, arrástalo hacia ella. Esto indicará a Bravo que ahí empieza la fiesta.

‍

¡Genial! Vamos ahora a comprobar el diseño en Bravo Vision. Hay que dejar siempre las cosas bien hechas.

‍

‍

‍

A estas alturas pensarás que se me ha ido la cabeza. No te preocupes, de momento no he perdido la cordura. La vergüenza sí, la cordura no.

Canciones, tarareos y chorradas varias aparte, vamos a meternos de lleno en una de las partes más interesantes de todo el proceso de Bravorización. Vamos a confeccionar nuestro Backend. El corazón, los pulmones, el hígado, los riñones e, incluso, el alma de nuestra app.

No exagero. Sin un buen backend, da igual lo que diseñes y lo bonito que te haya quedado.

Nosotros vamos a utilizar, en esta app, Airtable. ¿Por qué? Porque es una herramienta tremendamente versátil y porque se comunica a las mil maravillas con Bravo Studio.

Podemos usar otras herramientas como Xano, Backendless o, incluso, Notion. Algunas de ellas nos dejarán hacer funcionalidades más avanzadas que Airtable, pero pocas cuentan con su versatilidad, rapidez y facilidad de uso.

Vamos a tener dos bases de datos. La primera con los diferentes platos y la segunda con los restaurantes. Te la dejo aquí abajo:

https://airtable.com/shriNAvK6j3GSew2Q

Empezamos con la primera. Aquí vamos a necesitar los siguientes campos:

⁃ Nombre del plato (Single line Text)

⁃ Breve descripción (Long Text)

⁃ Descripción más extensa (Long Text)

⁃ Tipo de plato: hamburguesa, entrante o postre (Selector)

⁃ Precio (Single Line Text)

⁃ Imagen (Attachement) En este caso también podemos utilizar el enlace de una imagen en un campo de tipo texto.

⁃ Ingredientes (Long Text)

⁃ Alérgenos (Long Text)

⁃ Destacada del mes (checkbox)

⁃ Precio (text)

Como hemos visto en el diseño, tenemos una diferenciación por tipo de plato. Para que esta se refleje en la app, debemos utilizar diferentes vistas para la tabla filtradas por el campo “Tipo de plato”. De esta manera, tendremos las vistas de: “Todos”, “Hamburguesas”, “Entrantes” y “Postres” y, cuando lo configuremos en Bravo, listaremos sólo los elementos que correspondan a la consulta que estamos realizando.

También haremos otra vista filtrada por aquellas hamburguesas que lleven el check de destacadas y la llamaremos “Destacadas”, para no rompernos demasiado la cabeza.

Vamos con la tabla de restaurantes. Esta tendrá los siguientes campos:

⁃ Nombre del restaurante

⁃ Dirección

⁃ Imagen del restaurante

⁃ Teléfono de contacto

⁃ Longitud

⁃ Latitud

Podemos insertar muchísima más información. Todo lo que se nos ocurra. Pero, de momento, esto es suficiente. Los últimos campos son los que nos van a centrar el mapa y colocar los marcadores.

‍

‍

¡Larga vida a esta relación!

Como te digo, Airtable y Bravo son dos herramientas que se quieren y se respetan. Su relación es fuerte. Hay una sólida comunicación.

Tanto es así que, mediante un configurador y dos pasos, vamos a hacer las diferentes llamadas API para conectar ambas herramientas y que Bravo obtenga esos datos que luego colocará en el diseño de Figma.

Nos vamos a Bravo Studio y, en concreto, al apartado de API Collections. Allí vamos a crear una nueva colección. Nos aparecerá un mensaje con varias opciones. De momento, sólo vamos a centrarnos en la que indica Airtable. Esto nos abrirá un configurador que nos va a pedir sólo dos datos para conectarlo todo: la url de la base de Airtable y tu clave API.

La url de la base la sacaremos desde la opción “share”, en la parte superior derecha y dentro del cuadro de diálogo, en la opción “enable shared base link”. Esto nos va a ofrecer la url que buscamos.

La clave API la podemos encontrar en “account”, también en la parte superior. Ojo con compartir esta clave. La puedes liar.

Una vez le hemos dado estos datos, Bravo y Airtable se darán el SÍ Quiero y la magia empezará a materializarse. Y lo hará en forma de llamadas API que se conectan a la base de datos para pescar de ahí lo que necesitamos.

Lo primero que vamos a ver es que nos ha creado cuatro llamadas a la API, todas ellas GET.

• Inciso. Si no conoces el tema este de las API, te resumo brevemente. Una API nos permite conectar herramientas entre sí mediante llamadas. Hay varios tipos de llamadas: GET, para extraer datos; POST, para publicar datos; DELETE, para borrarlos; o PATCH para actualizarlos.

Tras esta pausa, sigo. Como digo, tenemos cuatro llamadas, dos que listan resultados y otras dos que extraen el detalle de uno de los elementos. Desde el propio configurador ya las nombra de esta manera.

¿Qué debemos saber aquí? Lo primero, una vez lanzamos la llamada, pulsando SEND, nos va a aparecer el listado de datos que está recibiendo Bravo Studio. Desde aquí podemos seleccionar cuáles nos interesan para conectar a nuestra app.

Otra cosa importante. Si nos vamos a cualquiera de las llamadas de detalle, veremos que, en la parte final de la url de llamada, tenemos algo como ${id} Esto quiere decir que ese elemento de detalle lo va a sacar de una variable. En Bravo las variables se muestran así y es vital que, este id se nombre igual (incluso en mayúsculas y minúsculas) que la variable que sacamos de la llamada List.

¿Dónde podemos ver esto? En Selected Data tenemos todo los elementos que vamos a extraer junto al nombre que recibirán dentro de Bravo como variables. Ahí deberemos comprobar que el id está escrito de igual manera en ambas llamadas.

Hasta aquí fácil ¿no? No hemos tenido que hacer mucho y ya tenemos los datos de nuestro backend conectados a Bravo. En esta pareja la comunicación es total.

Bien, pues vamos a complicarlo un poco. Nada del otro mundo. ¿Te acuerdas que hicimos varias vistas en la tabla de alimentos en función del tipo? Ha llegado la hora de que esta selección se muestre en Bravo.

¿Cómo lo haremos? Tremendamente sencillo. Duplicaremos la tabla de Listado de alimentos y, al final de la url, incluiremos lo siguiente ?view=Hamburguesas. Nada más. Repites el paso con el resto de vista que queremos, nombras las llamadas con un nombre identificativo y lo tenemos.

Ya tenemos prácticamente el 90% del trabajo hecho. ¿Cómo lo ves?

‍

Aquí vamos a necesitar algo. Una dosis de paciencia. Vamos a tener que ir, uno a uno, conectando todos los elementos del diseño con el correspondiente campo de nuestra base de datos.

Empezamos en la Home. Aquí vamos a conectar, en primer lugar, los elementos correspondientes al listado de restaurantes que hay en la parte de abajo de la pantalla. Bien. Lo que debemos hacer es seleccionar el container e indicarle que coja los datos de la tabla “Restaurantes - List” y, debajo, que obtenga los records. Con esto le estamos diciendo a Bravo que debe listar todos los elementos que tenemos esa tabla.

Después, debemos ir uno a uno con los elementos que queremos mapear. En este caso, la imagen, el nombre y el precio y con los correspondientes campos que vienen del backend.

¿Te parece sencillo? Realmente lo es.

Podrás comprobar que en el elemento que representa el botón para hacer una reserva tenemos un icono pequeño de un rayo. Esto quiere decir que está preparado para que se vincule con una acción. En este caso, llamar por teléfono al restaurante. Al pinchar sobre el elemento nos dejará la opción de mapear el teléfono desde un campo del backend.

Vamos con el slider. Importante: en este caso vamos a indicar que los records los muestre en el segundo nivel de container que tiene este slider, como puedes ver en la imagen.

Mucho ojo con esto, porque si lo pones arriba te hará un listado de elementos como el que teníamos antes, y eso no queremos.

Por último aquí, para que sólo nos muestre las hamburguesas destacadas, nos vamos a ir a visibilidad y le vamos a decir que la marque en función del campo “Destacada_mes”.

Como habrás podido comprobar, podemos hacer varias llamadas API diferentes dentro de la misma pantalla. Esta fue una de las grandes novedades que introdujo Bravo 3.0.

Si nos vamos a las pantallas de detalle, pues lo mismo. Salvo dos detalles: lógicamente, antes de mapear los elementos, debes elegir la llamada de detalle correspondiente; además, en este caso, no será necesario que indiquemos que queremos obtener records, porque aquí no habrá un listado.

¿Y qué pasa con los mapas? Cuando entramos en el elemento vemos que hay dos niveles. Un primer nivel que se refiere al punto en el que vamos a centrar el mapa. De momento, vamos a pasar de esto.

‍

El otro nivel nos va a solicitar varias cosas. En primer lugar, nos pide unos records. Esto permite mostrar un listado y Bravo quiere saber de dónde saca esa información. Al igual que en los listados anteriores, lo sacaremos de una llamada de lista, la de los restaurantes disponibles.

Pero tenemos más cosas aquí. Lo más importante, la latitud y longitud, que sacaremos de esa llamada que hemos configurado previamente. También qué información se va a mostrar en el mapa, en nuestro caso, el nombre del restaurante y, además, si tenemos iconos personalizados en el backend podemos también mapearlos desde la opción marker.

En el caso de que el mapa esté en una pantalla de detalle, como la del detalle de un restaurante, no hará falta indicarle a Bravo que muestre unos records, puesto que no queremos un listado, sólo el marcador de ese restaurante concreto. En este caso, bastará con rellenar la longitud y latitud del sitio y qué se mostrará en el marcador.

‍

El resto de pantallas responden al mismo patrón. Vamos a rellenarlas y ahora nos vemos.

‍

Ya tenemos todo cosido. Es momento de pulir ciertos detalles. El primero de ellos, el icono de la app.

Para hacerlo, nos volvemos a Figma y creamos un frame nuevo con unas dimensiones de 1024x1024 En ese frame insertaremos otro y le daremos la etiqueta de container. Dentro, ya podemos diseñar lo que queramos.

Por ejemplo, podemos reutilizar nuestro logo que teníamos en los assets y ponerle un fondo del color corporativo. Ten en cuenta que este icono se va a ver muy pequeñito, no te pases poniendo detalles porque no se van a apreciar.

También podemos hacer una pantalla splash screen que es la que se mostrará cuando arranque nuestra app después de un tiempo sin usarse. Esta página sólo la podremos ver cuando la app está publicada, no en Bravo Vision y lleva la etiqueta [asset:splash]

Otra de las opciones que tenemos es la de poner una página de intro, por si queremos hacer un onboarding, por ejemplo. La página llevaría la etiqueta [intro:once] si sólo se va a mostrar una vez, tras ser descargada o [intro:always], para mostrarla siempre que volvamos a abrir la app.

En este caso, deberemos configurar un botón para salir de ella, con la etiqueta [action:closeintro]. Por ejemplo, aquí podríamos poner un botón para permitir a los usuarios activar las notificaciones, aunque en nuestro caso vamos a ponerlo en el menú slide que tiene la app.

‍

Una de las cuestiones más atractivas de tener una app es la posibilidad de controlar, en todo momento, cuándo y cómo impactas en tu audiencia. Siempre y cuando, claro, que esta audiencia tenga activadas las notificaciones de nuestra app.

En el caso que nos compete, podemos utilizarlas para mandar promos, informar de novedades… Lo que queramos.

¿Y cómo se configuran? Lo primero que necesitamos es un botón que será el trigger que active estas notificaciones. Puedes ponerlo, como te dije anteriormente, en una pantalla de intro.

Pero, ¿por qué no lo pongo en este caso? Si lo pones en una pantalla de intro, este botón, en sí mismo, no va a cerrar esa pantalla. El usuario tendrá que darle luego a otro botón para hacer ese cierre y acceder a la app. Esta característica no me convence, porque creo que no liga bien con alguna de las leyes heurísticas del diseño UX/UI.

Por ello, yo te propongo ponerlo en el menú slide que tenemos. O también puedes hacer una pantalla a la que se acceda a través de un botón y dentro de la misma explicar bien para qué es conveniente activar las notificaciones y poner el botón que las ejecute.

Lo que necesitamos, en este punto, es un botón. Lo haremos con un texto “Activar notificaciones” y autolayout. A este botón le pondremos la etiqueta [action:enablenotifications]

Ahora vamos a configurar esto en Bravo para que podamos probar las notificaciones desde Bravo Vision para probar estas notificaciones desde un entorno de pruebas.

Para probar estas notificaciones, nos vamos a la parte superior de nuestra página de app en Bravo y pulsamos en Push Notifications.

Nos saldrán las opciones para configurar el mensaje. Estas incluyen:

• Título de la notificación
• Texto de la notificación
• Acción que ejecutaremos una vez se pulse esa notificación. En este punto nos centraremos en dos: show alert y go to page. La primera mostrará un mensaje y nos llevará directamente a la home de la app cuando pulsemos; la segunda abrirá una página concreto de la app.

¿Cómo sacamos la url de la pantalla que necesitamos? Lo haremos desde Bravo Vision. Manteniendo pulsada la pantalla en cualquier punto nos aparecerá un menú en el que pincharemos en copiar la url de la página. Una vez la tengamos, nos la mandamos a Bravo y la pegamos en la casilla correspondiente.

Ya podemos mandar la notificación y comprobar cómo queda. Sencillo, ¿verdad?

En este caso, llea el logo de Bravo porque estamos en Bravo Vision. Cuando lancemos la notificación en nuestra app real, llevará el nuestro.

Las notificaciones son realmente útiles para interactuar con nuestra audiencia y fomentar que realicen acciones concretas que queramos dentro de la app.

Con esto y un bizcocho…. Tenemos nuestra app lista. Ha sido un proceso chulo, ¿verdad? Desde ya os animo a probar esta herramienta y a hacer realidad vuestros diseños convirtiéndolos en app reales y funcionales.

Si tenéis alguna duda, nos vemos por la comunidad para resolverlas. Además tenéis el centro de ayuda de Bravo que es una maravilla y está todo muy bien documentado.

En próximas entregas veremos, paso a paso, cómo publicar nuestra app en las stores y configurar las notificaciones para que les lleguen a nuestros usuarios.

Hasta entonces, un placer haber llegado hasta aquí con vosotros. ¡Un saludo!

‍