Los entornos de desarrollo no-code buscan empoderar los usurios no técnicos para que puedan ellos mismos sus aplicaciones. Ya dijimos que en muchos casos, no serán los programador quienen van a crear las aplicaciones del futuro.
El concepto no-code se usa a menudo como una variación del concepto low-code, aunque para mí el low-code y el no-code son paradigmas de desarrollo diferentes. Sea como sea, está claro que todas las grandes empresas apuestan por esta revolución.
El paradigma no-code facilita la creación de aplicaciones sin que el usuario haya que escribir una sola línea de código. Esto tiene una clara contrapartida, y es la limitación del tipo de aplicaciones que se pueden llegar a desarrollar con los entornos no-code. Básicamente, estamos hablando de aplicaciones basadas en plantillas predefinidas o en la definición de workflows que conectan componentes disponibles en la plataforma (tipo Zapier) donde, como mucho, podrás configurar la conexión y el qué acciones harán que el workflow se ejecute.
Estas limitaciones son razonables si no quieres o no tienes tiempo para aprender a programar. Y el gran número de plataformas no-code disponibles te ayudará a encontrar alguna que te sea útil sea cuál sea el tipo de aplicación que tienes en mente (otra cosa es que el precio te guste). Pero sigues necesitando invertir tu tiempo en aprender la herramienta no-code y en utilizarla para definir la aplicación que quieres. ¿Se puede hacer algo mejor? La respuesta es que sí, hoy os quiero hablar de las herramientas no-learn y no-work.
Esta imagen ejemplifica la relación entre las herramientas no-code, no-learn y no-work.
Desarrollo No-Learn
Llamo herramientas no-learn al subconjunto de herramientas no-code que dejan al usuario utilizar las herramientas que ya conoce para definir la aplicación a generar.
En lugar de obligar al usuario a aprender la interfaz de la herramienta no-code y el lenguaje de modelado que hay detrás, una herramienta no-learn será capaz de importar la definición de la app de ficheros Word, Excel o cualquier otra herramienta que el usuario no conozca.
Un ejemplo sería nuestro servicio de Excel a chatbot. En lugar de forzar al diseñador de bots a aprender un nuevo lenguaje para definirlos, le ofrecemos una plantilla Excel donde puede describir fácilmente la lista de preguntas y respuestas del bot. No importa como de buena sea la herramienta no-code, si el usuario tiene que empezar por aprender a usarla, su productividad será mejor que si puede simplemente abrir Excel (o lo que sea) y ponerse a ello. Estamos eliminando una de las mayores barreras de entrada.
Una herramienta no-learn puede ser tan expresiva como una herramienta no-code. No estamos limitando lo que el usuario puede hacer, simplemente ofreciéndole una manera más amigable de expresar lo que quiere.
Desarrollo No-Work
No-work es un caso “extremo” de desarrollo no-code donde el usuario no hace absolutamente nada. Los usuarios no programan pero es que tampoco definen la aplicación que quieren. No hacen nada de nada. Una herramienta no-work coge la información que ya esté disponible en la empresa (documentos, archivos, bases de datos) y con eso genera automáticamente la aplicación que quiere el usuario. No le pide al usuario que pierda el tiempo diciendo lo que quiere de nuevo sino que lo “busca/entiende” mirando lo que ya existe.
Si seguimos con nuestro ejemplo de chatbots. En un entorno no-work, el usuario no definirá el bot de ninguna manera. No le pediremos que utilice ni una herramienta no-code, ni nuestra plantilla excel (no-learn). Simplemente cogeremos la página de FAQs que ya tenga en la web, algún tipo de Excel donde ya haya recogido preguntas de usuarios (por ejemplo para subcontratar a alguna empresa externa que utilice ese fichero para responder) o la lista de productos en al base de datos para crear un bot capaz de responder a las FAQs y otras preguntas “típicas” que se pueden derivar de la información de los productos. De hecho, en muchas de nuestras entrevistas con posibles clientes, hemos escuchado muchas veces alguna variación de la frase “ya tenemos un archivo Excel que usamos internamente, lo único que busco es darte ese archivo y que tu me crees un chatbot equivalente”.
Una herramienta no-work elimina completamente cualquier barrera de entrada. Como contrapartida, aquí sí que estamos limitando aún más la diversidad de aplicaciones que se pueden generar. Estamos hablando sobretodo de utilizar patrones y estrategias de tipo “convention over configuration” para poder generar aplicaciones completas sin intervención del usuario. De todas formas, no es ciencia ficción. Estrategias tipo no-work se utilizan parcialmente en muchos frameworks de programación. Piensa, por ejemplo, en todos los CRUD generators, capaces de generar formularios de consulta y modificación de datos para una base de datos existente. En el mundo no-work simplemente lo llevamos un poco más al extremo.
Las categorías No-code no son exclusivas
Cada una de las categorías es ideal para un tipo de usuario y escenario, todo depende de cuánto tiempo quiere invertir y hasta qué punto quiere configurar al detalle el resultado final.
Pero esto no implica que una herramienta no-code tenga que ofrecer sus servicios en sólo una de estas categorías. Como hacemos en Xatkit, una misma herramienta puede ofrecer diferentes interfaces sobre un mismo motor interno. E incluso puede ofrecer una API que permita a programadores acabar de pulir el desarrollo, complementando la parte no-code con una capa low-code por encima.
Imagen de cabecera por Kate Stone Matheson en Unsplash
Últimos comentarios