Todo diseñador UI necesita aprender React. He aquí por qué

React es una librería JavaScript creada y mantenida por Facebook para construir interfaces de usuario Web y Mobile. Cualquiera con algún grado de familiaridad con el mundo front-end sabe que React está en boga y su uso ha explotado en los últimos meses; sin embargo, el frenesí hasta ahora sólo parece alcanzar a los desarrolladores, mientras que los diseñadores ni nos damos por enterados.

Y dado que React es una librería específicamente hecha para construir interfaces de usuario, debería al menos darnos un poco de curiosidad, ¿verdad?

Este artículo no es una guía ni un tutorial para usar React; es simplemente la argumentación de por qué los diseñadores UI modernos se verán enormemente beneficiados de aprender y familiarizarse con React, como me tocó a mí desde fines del 2015, cuando lo comenzamos a usar en Get on Board.

Ojo: Diseñadores UI, no UX

Lamentablemente la confusión entre UI y UX está lejos de desaparecer, así que me desviaré levemente del tema central para estar en la misma página sobre la distinción entre diseño UX y diseño UI:

  • Un diseñador UX explora todos los factores que influyen en una experiencia, incluyendo factores culturales y emocionales, y saca aprendizajes que luego decantarán en varios outputs tangibles (uno de los cuales podrían ser las interfaces de usuario).
  • Un diseñador UI, en cambio, se especializa en construir interfaces de usuario.

Un diseñador UI necesita meterse en código (si realmente quiere hacer interfaces)

Creo que muchos diseñadores UI no se detienen el tiempo suficiente a pensar qué significa realmente construir interfaces de usuario. Por eso es que vale la pena recordar ciertos puntos:

1) Un wireframe, mockup, etc., no es una interfaz; es una ilustración o una descripción de una interfaz, tal como el storyboard de una película no es la película.

2) Hay elementos de la interfaz de usuario que no pueden ser documentados fielmente mediante wireframes, mockups o software de prototipado estático. Por ejemplo:

  • Diseño responsivo o fluido;
  • Animaciones, transiciones y gestos touch (buena suerte intentando prototipar paged scrolling en InVision o Marvel 😉);
  • Reacciones en vivo de la interfaz a la interacción del usuario (por ejemplo, arrastrar un slider que cambia de valores, realizar una combinación de teclado, o encabezados que colapsan cuando pasan un cierto nivel de scroll);
  • Reacciones de la interfaz a los sensores de un dispositivo móvil (acelerómetro, brújula, giroscopio, etc);
  • Interfaces auditivas y hápticas, elementos de accesibilidad, etc.

Intentar ilustrar o describir dichos elementos en un wireframe o en una app de prototipado estático es tedioso e impreciso, y en el mejor de los casos termina siendo una versión “fotonovela” de la interfaz.

3) Por ende, un diseñador UI que sólo entrega mockups o wireframes no cumple a cabalidad con construir interfaces de usuario, sino que llega como máximo a documentar una parte de ella (la estrictamente visual y estática). Cuando un diseñador UI sólo entrega wireframes/prototipos estáticos, se restringe inevitablemente a producir interfaces igualmente estáticas, y evita explorar elementos dinámicos como los que menciono en el punto (2). Como dice el dicho, cuando todo lo que tienes es un martillo, a todo le ves cara de clavo.

La conclusión es más o menos obvia: un/a diseñador/a de interfaces necesita poder producir, en algún nivel, el código de su propia interfaz.Mientras menos código sepa el diseñador UI, más limitadas serán sus interfaces.

La distinción entre un diseñador UI y un diseñador UX vuelve a ser relevante acá, porque mientras un diseñador UX sólo requiere entender cómo funciona la construcción de interfaces, un diseñador UI necesita llegar lo más lejos que pueda en construir realmente dichas interfaces.

Aquí construir es equivalente a diseñar: si sólo llegas hasta el mockup (lo que se entiende típicamente por “diseñar”), estás construyendo únicamente la parte visual de la interfaz y omitiendo elementos cruciales de dicha interfaz, como el comportamiento, reacción y sentido del tiempo.

Desde luego, inevitablemente llega un punto en el desarrollo de interfaces donde el diseñador UI agota sus capacidades y necesita empalmarse con un desarrollador Front-End; sin embargo, cuando ese punto de empalme ocurre antes del código, lo que tenemos es un diseñador UI incompleto, que pierde visibilidad y control sobre aspectos cruciales de la interacción de sus usuarios.

Un diseñador UI actual necesita pensar en términos de componentes más que en pantallas

A medida que los productos digitales se multiplican y complejizan, el flujo de trabajo moderno de desarrollo de software ha cambiado un montón para optimizarse en torno a equipos numerosos trabajando en muchas funcionalidades a la vez.

Esto ha traído un cambio en lo que se necesita de un diseñador UI: antes, un diseñador UI producía pantallas específicas, las cuales luego eran implementadas o completadas al pie de la letra por el resto del equipo de desarrollo; ahora, un diseñador UI debe definir y documentar componentes de interfaz, los cuales serán usados por los desarrolladores en la construcción de funcionalidades que no necesariamente el diseñador controlará.

Dicho de otra forma: en un flujo moderno, el diseñador UI debe definir los bloques de Lego con los cuales los desarrolladores construirán lo que necesiten. Es responsabilidad del diseñador UI definir estos componentes de forma que los desarrolladores puedan usarlos con tranquilidad, confiando en que responderán adecuadamente y que no romperán el diseño.

Existen varios frameworks para otorgar un punto de partida consistente a esta construcción (como Material Design o Bootstrap), pero sólo son eso: puntos de partida. Tanto en look & feel como en comportamiento, un diseñador UI deberá trabajar por sobre dicha base para construir un sistema de componentes de interfaz que cumplan con dos objetivos clave: reutilización y consistencia.

Al mismo tiempo, tenemos que recordar una vez más que hace rato que ya no estamos jugando en la cancha del diseño Web; por ende, la necesidad de reutilización y consistencia no aplica solamente para un canal digital en particular, y debe trascender varios sistemas y dispositivos.

Y aquí es donde entra en juego React.

React permite crear componentes cross-device de UI semánticos y controlados

Yep. Yo sé que esa frase ☝️ está un poco enredada. Analicémosla:

  • Componentes, es decir elementos de interfaz (controles de interacción, layout, contenido, etc) que se pueden combinar de múltiples formas al construir una UI en particular;
  • Cross-device, lo cual implica que dichos elementos de UI pueden ser aplicados consistentemente no sólo a un dispositivo en particular (ej: Web), sino a varios, como dispositivos móviles;
  • Semánticos, es decir, componentes que tienen un propósito definido explícitamente. Por ejemplo, un dropdown es un menú desplegable que contiene un listado de opciones seleccionables por el usuario.
  • Controlados, lo cual implica que no es tan fácil romper el diseño. Tal como no podemos deformar un bloque de Lego a voluntad, los componentes tienden a comportarse siempre como fueron definidos originalmente.

React, como tal, es una librería de JavaScript pensada para construir interfaces interactivas, y hacerlo muy bien. Busca ser lo menos prescriptiva posible: no te dice cómo tienen que verse o comportarse tus componentes, ni cómo tienen que llamarse. Tú los defines como mejor te convenga. Esto es especialmente importante para definir componentes semánticos.

Por decirlo de alguna forma, React se superpone al código HTML al cual estamos acostumbrados; en lugar de hacer interfaces directamente en HTML, las hacemos en los archivos .js de React, y React se encarga de construir todo.

A diferencia de Haml, Jade y otros lenguajes de plantilla que facilitan o potencian la escritura de HTML, React usa lógica de programación. No se limita a “escupir” HTML, sino que incluye la lógica que reacciona a estímulos externos y que cambia en vivo y en directo ese HTML como resultado de esos estímulos.

(Nota: en los dos párrafos anteriores hablo de HTML para simplificar la explicación, pero React también funciona para apps móviles mediante React Native).

Por qué React (desde el punto de vista de un diseñador)

Hay muchas razones de performance y eficiencia por las cuales el uso de React ha crecido tan explosivamente en los últimos dos años. En lo que toca a los diseñadores UI, algunas ventajas de React por sobre escribir código a la antigua son:

  • React favorece componentes encapsulados, que no entran en conflicto entre sí. Aunque esto no es automático, y requiere ciertas decisiones deliberadas de CSS para que funcione bien, es mucho más fácil definir componentes “portátiles” que pueden ser usados y exportados con facilidad. Esto permite reutilizarlos con la confianza de que no estaremos rompiendo algo en otra parte. Asimismo, facilita que el CSS sea el mínimo indispensable; sólo se carga con los componentes que estamos realmente usando.
  • React permite documentar los diferentes estados de una interfaz con facilidad; por ejemplo, si construyes una tabla que carga datos dinámicamente, puedes definir cómo se ve esa tabla mientras está cargando datos, cuando ya los recibe, y cuando hay error en recibir los datos. Todos estos estados van empaquetados junto con el componente, y cualquiera que los use los tendrá a su disposición. El concepto de “estado” (state) es central en React y permite construir la interfaz planificando cómo ésta reaccionará — yup, de ahí el nombre — a diferentes situaciones.
  • React permite definir y restringir las opciones con las que los desarrolladores podrán configurar un componente. Desde el punto de vista del diseño, “restringir” es algo bueno; no queremos que un desarrollador, en un momento de creatividad, decida que Comic Sans en texto fucsia era la solución correcta de diseño. React te permite “exponer” al resto del equipo sólo las variables que desees para el componente; si no quieres que se pueda cambiar el color o el tamaño, no lo permites. Si sólo quieres ofrecer tres opciones de íconos a elegir, puedes hacerlo. Este encapsulamiento evita que los componentes se desvirtúen y terminen siendo usados improvisadamente para fines que no eran los originales.
  • React permite abstraer la interfaz del código que va por debajo. A React no le interesa tanto si lo que está por debajo es HTML o es código Swift de una aplicación iOS; por ende, desde el punto de vista de quien construye interfaces, el uso de componentes es muy similar, lo cual favorece la consistencia y permite mantener el mismo modelo mental independientemente del dispositivo. Lo cual significa que:
  • React le ofrece la primera oportunidad a los diseñadores UI de poder involucrarse en el front-end de aplicaciones móviles nativas, sin tener que saber programar para móviles. En este sentido, React permite relacionarte con las aplicaciones móviles de una manera similar a las aplicaciones Web.

La sintaxis de React es semántica y similar a HTML

Los archivos de React son JavaScript. Una de las innovaciones de React es JSX, una sintaxis muy similar a HTML que permite combinar elementos personalizados con etiquetas HTML clásicas. Esto es un ejemplo de sintaxis JSX:

<TopMenu color="red">
<Logo />
<Dropdown size="medium" animated align="right">
<a href="/profile">Profile</a>
<a href="/logout">Log out</a>
</Dropdown>
</TopMenu>

Familiar, ¿no? En este ejemplo, <TopMenu> , <Logo> y <Dropdown> (todos empiezan con mayúscula) son componentes que yo me inventé, y sus propiedades ( color, size, animated, align ) también las definí yo a mi pinta. La etiqueta <a>, y todas las etiquetas que no empiezan con mayúscula, corresponden a HTML puro.

Al interior de cada uno de estos componentes inventados, por supuesto, hay más código y lógica que me permite configurarlos. El ejemplo es bien básico, pero demuestra que armar una interfaz en React es sumamente claro de entender para un desarrollador, el cual puede simplemente incluir los componentes que desee sin preocuparse de qué tienen adentro o de romperlos por error.

Preguntas (probablemente) frecuentes

¿Por qué React y no Vue.js, o Angular, o <inserte su librería favorita aquí>?

La razón principal es que la lógica de React funciona tanto para Web como para Mobile, y ésa es una ventaja que ninguna otra librería ofrece al momento de escribir estas líneas (al menos no con la madurez de React, que es usado en Facebook, Instagram, Walmart, Airbnb, etc). Por ende, el tiempo invertido en aprender React es tiempo que te servirá para construir UIs en múltiples dispositivos y no sólo Web.

No tengo familiaridad con Vue.js, pero entiendo que tiene una lógica similar a React — orientada a componentes — , y en ese aspecto aprender Vue probablemente te traerá como diseñador/a ventajas muy parecidas a las de aprender React. Pero en lo que respecta a pensar y armar interfaces de manera cross-device, creo que React por ahora no tiene competencia.

¿Esto significa que tengo que convertirme en un/a experto/a en React?

No. Yo personalmente estoy muy lejos de ser experto en React y dependo de la ayuda de un desarrollador front-end para varias cosas, pero aún así ya percibo los beneficios de usarlo. Creo que el principal beneficio de salir de la zona de confort y entender cómo funciona React es que te cambia el paradigma de cómo construir interfaces de usuario de ahora en adelante.

Dicho cambio de paradigma (pasar de pensar en pantallas a pensar en componentes) es fundamental, porque es la forma en la que se construirán UIs en los años venideros. Si no es React, será alguna evolución de React; pero me parece que es una manera de construir interfaces que llegó para quedarse.

¿Por qué tengo tanto miedo de lo complejo que se está volviendo el desarrollo Front-End? Extraño mi Dreamweaver.

Sin duda que no necesitas aprender React para personalizar tu blog WordPress o para armarte un sitio de portafolio. Pero el ámbito profesional real en el que nos tendremos que mover de ahora en adelante es uno donde los productos digitales son cada vez más complejos, multifacéticos y escalables, y son desarrollados por equipos cada vez más grandes y con roles especializados, que necesitan trabajar coordinadamente; de ahí ha venido la búsqueda por automatizar y modularizar.

Asimismo, los estándares de seguridad, performance y buenas prácticas de código son mucho mayores que hace algunos años; la industria está madurando y nos movemos en un entorno mucho más riguroso, lo cual por intimidante que sea, es la mejor forma de producir software de calidad de manera consistente. Los diseñadores UI no son ninguna excepción a estas nuevas reglas.

¿Dónde empiezo a aprender React?

React requiere algo de familiaridad con programación orientada a objetos y bastante familiaridad con JavaScript (y con HTML/CSS, por supuesto). Esto es crucial, y si no tienes idea de JavaScript, mejor empieza por ahí. Es igualmente importante tener claro qué diablos es el DOM.

Ya para meterse más de lleno en React, sugiero empezar por la guía oficial, luego leer este artículo y esta guía larga.

Para comenzar con una aplicación React básica preconfigurada y saltarse la parte más latera inicial, recomiendo probar con Create React App de Facebook. Ahí mismo hay una guía de usuario con los pasos básicos para comenzar.

Gracias a Ernesto García

Old Continuum Blog Migration Test

oldcontinuumblogmigrationtest

)
Continuum's Old Blog

Written by

Old Continuum Blog Migration Test

oldcontinuumblogmigrationtest

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade