Imponer convenciones para la detección de objetos en wireframes

Muchas grandes ideas comienzan en una hoja de papel o en una pizarra. ¿Por qué? Porque dibujar a mano sigue siendo la forma más natural, intuitiva y eficiente de estructurar pensamientos abstractos o visuales. A pesar de sus esfuerzos por adaptarse al mundo digital, las personas suelen desenvolverse mejor en situaciones analógicas.

Teniendo esto en cuenta, decidimos centrarnos en un caso de uso específico: automatizar la generación de código listo para producción a partir de wireframes dibujados a mano. En esta etapa, creemos que obtener una prueba de concepto digital directamente de una reunión con accionistas ya no es un sueño lejano.

Como explicamos en este artículo anterior, buscamos utilizar inteligencia artificial (IA) y aprendizaje automático (AA) en distintos puntos de nuestra plataforma. Sin embargo, sabemos que, al menos por ahora, el AA no puede resolver todos los problemas. Nuestra API de visión forma parte de un ecosistema más amplio y se encarga «solo» de detectar cuadros delimitadores. Luego, esos cuadros delimitadores sin procesar deben convertirse en una representación de un lenguaje de definición de interfaces de usuario (UIDL). Después, nuestros generadores de código —y algunas capas propias de toma de decisiones— pueden encargarse de generar el código.

Captura de pantalla y wireframe de Stackoverflow.com

La necesidad de datos#

Sobre el papel, para un científico de datos, el problema parece muy sencillo: tenemos imágenes o escaneos de wireframes con anotaciones que indican dónde están elementos como imágenes, botones y textos. Parece fácil, así que busquemos algunas imágenes en Internet y las anotaremos más adelante.

Algunos wireframes que encontramos en la web

Para empezar, decidimos recopilar datos gratuitos de la web. Esto fue suficiente para hacernos una idea general de la naturaleza de los datos con los que íbamos a trabajar, pero también nos permitió darnos cuenta de que esta fuente no podía proporcionarnos suficientes imágenes para entrenar un modelo de AA. Después nos encontramos con otro problema: nadie seguía las mismas convenciones al dibujar wireframes... De hecho, más adelante, durante el proceso de recopilación de datos, descubrimos que a menudo cada organización tiene sus propias directrices específicas.

Para resolver estos primeros problemas, decidimos crear nuestras propias pautas y empezar a dibujar wireframes nosotros mismos. Cuando todos los miembros del equipo habían contribuido, decidimos recurrir a nuestros amigos para obtener datos y les pedimos a todos nuestros (¡increíbles!) amigos que también dibujaran wireframes. Sin duda, no es una estrategia viable a gran escala, ya que la cantidad de amigos es muy limitada, pero nos permitió reunir una colección inicial y coherente de wireframes dibujados a mano.

Nuestras pautas actuales para dibujar wireframes

Teníamos la X, pero aún necesitábamos la Y#

La intuición más sencilla sobre el aprendizaje automático es que la computadora aprende por sí sola una función para predecir Y a partir de X, observando una gran cantidad de ejemplos. En ese momento, ya teníamos unos cientos de imágenes, así que contábamos con la X. Sabíamos que serían suficientes para una prueba de concepto, así que pasamos al siguiente paso: las anotaciones para obtener la Y.

Empezamos a anotar manualmente cada wireframe dibujado para señalar dónde estaban ubicadas las imágenes, los botones y los textos. No hace falta decir que esta tarea no fue la parte más agradable de la iniciativa, pero nada es gratis en esta vida, así que nos armamos de valor y la hicimos.

En nuestro caso, el proceso fue bastante largo. Empezó con algunos experimentos improvisados con chatbots e interfaces conversacionales. En aquel momento, en 2015, la mayoría seguíamos trabajando en el departamento de JavaScript de Evozon. Ese trabajo nunca llegó a producción, pero todos seguimos entusiasmados: abrió muchas perspectivas nuevas sobre cómo podíamos crear experiencias de usuario.

La necesidad de contar con datos coherentes#

Una vez que tuvimos la X y la Y, por fin pudimos empezar con la parte divertida: entrenar el modelo. Esto llevó mucho menos tiempo que recopilar los datos y, por supuesto, la conclusión fue que necesitábamos más datos.

Aun así, conseguimos una prueba de concepto y una base muy sólida para mejorar. La precisión del modelo fue del 55 % en nuestro conjunto de prueba, lo que significa que detectó correctamente el 55 % de los elementos.

Además de la escasez de datos, fue entonces cuando nos dimos cuenta de que tendríamos que afrontar un nuevo reto: había muchas colisiones en las anotaciones. Algunas eran ambiguas, incluso para una persona:

• ¿Es una imagen o un botón?
• ¿Es un encabezado o un párrafo?
• ¿Es un campo de texto o un botón?

En algunos casos, como los encabezados y los párrafos, la estructura principal del wireframe podía ayudar a tomar una decisión. Sin embargo, en muchos otros casos, no había forma de distinguirlos. Y, por lo tanto, tampoco había forma de entrenar correctamente el modelo.

Un wireframe subido por un usuario, a la izquierda, junto a un wireframe de nuestro conjunto de datos de entrenamiento, a la derecha

Necesidad de pautas más estrictas#

Como ocurre con muchos problemas de ingeniería, la parte más difícil es establecer una primera base sólida a partir de la cual se pueda mejorar. El aprendizaje automático no es una excepción. En nuestro caso, una base sólida implicaba imponer restricciones claras sobre qué podía detectar el modelo y cómo podía interpretar la intención del usuario. Aunque más adelante planeamos ampliar nuestras capacidades, tanto en cuanto a la variedad de elementos como a la libertad de dibujo, por ahora nos limitaremos a las siguientes convenciones (muchas de ellas inspiradas en Markdown):

• Encabezado: como se confunde con un párrafo, proponemos anteponerle un signo de numeral
• Campo de texto: como se confunde con el elemento botón, proponemos usar únicamente un campo de texto vacío
• Enlace: lo rodearemos con corchetes
• Las etiquetas solo se detectarán como tales cuando estén asociadas a un campo de entrada.
• Párrafo: si el texto no es una etiqueta, un encabezado ni un enlace, es un párrafo.
• Imagen: solo puede ser un rectángulo o un círculo con una cruz en su interior.

Nuestras futuras pautas para dibujar wireframes

Fue una decisión difícil, pero creemos firmemente que las restricciones que añadimos ofrecerán importantes ventajas que compensarán las limitaciones, como por ejemplo:

• ¿Es un campo de texto o un botón?
• ¿Es una imagen o un botón?
• Haz que la anotación no sea ambigua

Conclusión#

Por ahora, nuestra API de visión sigue las pautas antiguas, pero en la próxima versión (que llegará pronto) usaremos las nuevas. Como siempre, queremos recordar a nuestros lectores que este trabajo está en curso y dista mucho de ser perfecto, pero estamos deseando recibir comentarios e ideas para mejorar nuestra API de visión. No dudes en escribirnos en nuestra cuenta de Twitter en cualquier momento y síguenos para estar al tanto de las próximas novedades.