DevUI: poniendo orden en el front

0
1901

El DevUI puede ser la solución para la brecha que existe entre diseño UI y los desarrolladores en grandes empresas que ofrecen soluciones front.

Índice de contenidos

1. Entorno

Este tutorial está escrito usando el siguiente entorno:

  • Hardware: Slimbook Pro 2 13.3″ (Intel Core i7, 32GB RAM)
  • Linux Mint 19
  • StencilJS 0.15.2

2. Situación actual

En los últimos tiempos el front ha tomado una posición capital en la estrategia de transformación digital de muchos tipos de negocios ya que es la imagen y la experiencia de usuario que ofrecen a sus clientes aseguradoras, bancos, aerolíneas, etc…

Esto requiere que cada vez más, Negocio se centre en ofrecer más y más funcionalidades a través de dispositivos móviles y frontales web, que hacen que este tipo de aplicaciones cada vez sean más potentes y a la vez más complejas.

Lo que lleva a un cambio en la concepción de un equipo de desarrollo web donde antes se tenía más en cuenta la parte de back y ahora hay que formar equipos especializados en la parte front, no solo en desarrollo sino en roles de diseño UX y UI que antes no existían tanto.

En paralelo la web ha ido evolucionando hacia el empoderamiento del navegador ofreciendo APIs como los web components que permiten extender el HTML a nuestro antojo pudiendo crear etiquetas personalizadas que cumplan con una determinada funcionalidad y convivan e interactúen con otros web components.

Este tipo de aplicaciones requiere de un rol de desarrollo que se tiene que centrar más en ofrecer la funcionalidad que ha definido Negocio en el menor tiempo posible y con la máxima garantía de estabilidad y calidad, para aprovechar al máximo la ventana de ganancia abierta con la idea de Negocio.

También te habrás dado cuenta de que este tipo de aplicaciones del lado del cliente tienen un requisito de máxima usabilidad, vistosidad y en muchos casos, accesibilidad, que hace que sea necesario tener un rol de personas más creativas que puedan hacer un trabajo de experiencia de usuario y diseño de interfaces adecuadas al usuario, teniendo en cuenta los criterios y pautas de accesibilidad que se marcan para que la información pueda llegar al máximo número de usuarios.

Por lo tanto, tenemos de un lado los desarrolladores y del otro lado los diseñadores UI, los cuáles son perfiles con cualidades necesarias diferenciadas pero que están condenados a colaborar para poner un producto de Negocio en producción. No sé en vuestra experiencia, pero lo más común en las grandes empresas es encontrar desarrolladores sin gusto ni estilo y personal de diseño UI que no implementa.

Esta situación lleva a muchas empresas a crear dos silos separados por un muro de confusión: por un lado los desarrolladores y por el otro los diseñadores UI, mientras Negocio mete prisa a todos porque la ventana de oportunidad se acaba.

Por esta situación, en muchas empresas nos encontramos con la siguiente dinámica, pondremos un ejemplo de una empresa llamada ACME.

En la empresa ACME, cuando tienen que abordar un proyecto front, lo primero que hacen es encargarle al departamento de diseño UI/UX un estudio de experiencia de usuario y diseño de interfaces, el cual es imprescindible para que la aplicación se adapte perfectamente a los usuarios objetivo y que tiene que tener en cuenta aspectos como la usabilidad, la accesibilidad, creación de interfaces de usuario intuitivas, y sobre todo, un diseño que entre por los ojos en el primer vistazo haciendo que la experiencia de usuario sea lo más placentera posible para que quieran volver a nuestra aplicación una y otra vez.

El resultado del estudio suele ser una maqueta más o menos dinámica, en el mejor de los casos en HTML pero por lo general en Photoshop o una herramienta similar, que le pasan como un paquete con lazo al departamento de desarrollo para que se encargue de adaptarla a la aplicación real con la tecnología web que se vaya a utilizar.

Esta dinámica crea una brecha y unos conflictos muy fuertes entre los dos silos dado que tienen cualidades muy diferenciadas; las personas que desarrollan suelen ser menos creativas y les cuesta un mundo ajustar al «pixel perfect» lo que le han pedido con la tecnología web que se esté utilizando, y las personas que diseñan se frustran porque su trabajo no lo ven reflejado en la aplicación real.

Esto provoca bucles interminables y fricciones entre unos y otros, intentando encontrar un equilibrio entre lo que te permite la tecnología y lo que espera diseño UI, lo que lleva a retrasar la puesta en producción de la idea de Negocio y muchas veces perder la ventana de oportunidad por temas “técnicos” que es lo que más cabrea a Negocio en una empresa, ¿alguien se siente identificado?

3. ¿Cómo podemos solucionar esto?

Lo que se propone es aplicar la misma idea que está funcionando en muchas empresas (incluso en ACME) para reducir la brecha entre desarrolladores y operaciones: la cultura DevOps.

En el caso del front a esta idea la vamos a llamar DevUI y consiste en hacer que ambos silos puedan colaborar y empatizar para derribar el muro y reducir la brecha existente.

Esto requiere de una re-organización y cambio de hacer las cosas que consiste en que el rol de arquitecto de front y maquetador colaboren con el rol de diseñador UI para que el resultado del estudio no sea una maqueta que luego haya que adaptar sino una librería de componentes listos para utilizar en desarrollo que mantengan la experiencia e imagen de marca que la empresa quiera ofrecer a sus usuarios a través de la web o del dispositivo móvil con aplicaciones PWA y/o aplicaciones móviles híbridas.

De esta forma los aspectos de usabilidad, accesibilidad y vistosidad vienen determinados por la librería ganando en homogeneidad de imagen.

Por otro lado, ganamos en velocidad de desarrollo, ya que el rol de desarrollador se puede centrar más en ofrecer la funcionalidad que requiere Negocio, haciendo que la aplicación sea vistosa, usable y accesible directamente, sin invertir tiempo en “marear” la CSS o profundizar en el aprendizaje de técnicas de usabilidad y pautas de accesibilidad, con el uso de los componentes proporcionados por la librería corporativa.

Otra de las ventajas subyacentes es que podemos concentrar esfuerzos en hacer que nuestra librería cumpla con los criterios de accesibilidad para asegurarnos que haciendo uso de ella, las aplicaciones web que desarrollemos cada vez tengan menos barreras y podamos cumplir con el diseño universal; siendo ésta una mejor forma de asegurar la accesibilidad de nuestras webs que no pretender que los n desarrolladores de nuestra empresa sepan manejarse con los criterios de accesibilidad necesarios.

De esta forma, derribamos el muro de la confusión y podemos hacer que las ideas de Negocio lleguen cuanto antes a producción con las máximas garantías de vistosidad, usabilidad y accesibilidad; por lo menos por la parte del front, la guerra abierta entre front y back la dejamos para otro post 😉

4. No nos quedemos solo en la teoría

Llevando la idea al terreno práctico, lo ideal sería que arquitectura y diseño UI trabajen con una tecnología de web components nativos agnóstica al framework o librería web que Desarrollo esté utilizando y que le permita cierto grado de flexibilidad en el cambio de estilos cuando se tiene una empresa con imagen multimarca o si se quiere personalizar para un cliente en concreto.

Estos requisitos se pueden conseguir de una manera estructurada y estandarizada con el uso de la tecnología StencilJS (https://stenciljs.com) con su idea revolucionaria de no ser un nuevo framework o una nueva librería web, sino un compilador que facilita en gran medida la implementación de web components nativos gracias a una sintaxis muy parecida a Angular (actualmente el framework más utilizado a nivel corporativo) y aprovechando la velocidad de renderizado de React Fiber.

Aquí vemos un ejemplo para hacernos una idea de la estructura y la sintaxis de un componente con StencilJS:

import { Component, Prop, Event, 
    Listen EventEmitter } from '@stencil/core';

@Component({
    tag: 'tnt-hello',
    styleUrl: 'tnt-hello.scss'
})
export class TntHello {

    @Prop() name: string;
    @Event() select: EventEmitter;

    @Listen('click')
    onClick() {
        this.select.emit(this.name);
    }

    render() {
        return ( <h1>Hello {this.name}</h1>);
    } 
}

Este es un caso muy sencillo de un web component que admite un nombre como entrada y que al hacer click sobre el nombre, dispara un evento que permite a otro web component recogerlo para hacer algo con él.

Para utilizarlo en cualquier framework, librería o página web solo habría que colocar la etiqueta definida «tnt-hello» de esta forma:

<tnt-hello name="Rubén Aguilera"></tnt-hello>

Este es un ejemplo muy sencillo, simplemente para hacernos una idea de la sintaxis, pero puedes extrapolarlo al caso más complejo que necesites cubrir gracias a que este compilador tiene una API muy sencilla pero muy potente, que permite encapsular en pequeños componentes reutilizables las ideas de UI/UX y las interacciones con otros componentes de su entorno, en el ámbito del framework de turno o fuera de él.

Además, esta tecnología nos ofrece una forma automática de documentación de los web components ya que en el proceso de build genera ficheros readme.md por cada componente infiriendo el contenido a partir de los elementos del API usados, y pudiendo ampliar la documentación con comentarios JSDoc y comentarios en el CSS. Como podemos ver en este enlace: https://github.com/raguilera82/radh-ui/tree/master/src/components/radh-user

Y, por qué no, utilizarla para la creación de una librería de componentes reutilizables que respeten e implementen las técnicas y pautas de accesibilidad recomendada por el WCAG 2.1. https://github.com/raguilera82/acc-ui

Dada su universalidad también es la tecnología adecuada para evolucionar proyectos web antiguos. Un caso que se está dando en muchas empresas (también en ACME) es que tienen grandes desarrollos con AngularJS y se van a quedar sin soporte de esta tecnología a partir de Junio de 2021.

Esto hace que muchos departamentos de arquitectura estén buscando ya alternativas y formas de migración a otras tecnologías. Pues bien, desde aquí le digo que si adoptan StencilJS para la creación de web components, este problema no les volverá a pasar dado que genera componentes nativos 100% reutilizables por el resto de tecnologías, entre ellas AngularJS.

Es decir, pueden seguir evolucionando sus desarrollos creando componentes con StencilJS e ir migrando poco a poco los servicios y otros elementos que estén implementados con AngularJS, de forma que en poco tiempo y con poco esfuerzo, completar la migración a la nueva tecnología con el convencimiento de estar alineado con el estándar y que este problema no les vuelva a suceder a corto plazo.

5. La automatización es clave

Como pasa en el DevOps, en el DevUI también es completamente necesario aplicar técnicas de integración y despliegue continuo, que permitan cambios ágiles en la librería, que puedan ser utilizados por los desarrolladores en las aplicaciones corporativas.

Esto, básicamente, supone aprovechar o crear la infraestructura necesaria de herramientas de integración y despliegue de la empresa, que por lo general sí que están ya implantadas para proyectos back.

Un stack muy utilizado es el formado por GitLab como control de versiones, Jenkins para la ejecución del pipeline definido (aunque este rol también puede ser cubierto por GitLab), Sonarqube para el análisis de la calidad y Nexus como repositorio corporativo de Docker para el encapsulamiento de las aplicaciones web y de NPM para la distribución de las librerías corporativas como la creada con StencilJS o las propias de las aplicaciones web, hechas por ejemplo con Angular.

Si a todo esto le añadimos Docker y Kubernetes podemos también cubrir las necesidades de despliegue y entrega continua para garantizar que las ideas de Negocio están en producción realmente lo antes posible.

6. Conclusiones

Como se puede ver, el orden y concierto entre desarrolladores y diseñadores UI tiene solución pero hay que optimizar los procesos para que sea realmente efectiva.

De esta forma cada rol se dedica a lo que mejor sabe hacer en pro de rentabilizar cuanto antes y de la mejor forma posible las ideas de Negocio, se evitan las fricciones y todos los roles trabajamos en una misma dirección con un mismo objetivo: poner las ideas de Negocio en producción lo antes posible con la máximas garantías de funcionalidad, usabilidad, accesibilidad y vistosidad.

Cualquier duda o sugerencia en la zona de comentarios.

Saludos

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad