Sistemas de Diseño y UI en un Mundo Bidireccional

Hola, ¿qué tal, React Summit. Mi nombre es Matt Sikathian, y estoy aquí para hablar sobre interfaces de usuario en una web bidireccional. Pero primero, algunas cosas rápidas sobre mí. Soy un desarrollador front-end canadiense que vive en Berlín. Comencé como diseñador, lancé mi propio portafolio de productos con mi pareja, Fiona. Pasé seis intensos años en Shopify, y durante los últimos dos años, he estado trabajando en DeepL en el equipo de sistema de diseño.

Y para cualquiera que pueda no conocer DeepL, es una plataforma de IA de lenguaje que se destacó como una máquina de traducción de primera clase, bien conocida en Europa por capturar traducciones matizadas y con sonido humano, siendo la opción preferida por la mayoría. Y tengo que decir que DeepL fue una aplicación indispensable cuando Fiona y yo nos mudamos a Alemania sin hablar alemán. Y continúa siendo esencial para nuestra supervivencia aquí. Y esta fue una gran razón por la que quería trabajar allí.

Uno de mis primeros proyectos en DeepL fue transformar nuestras UIs para soportar diseños de derecha a izquierda mientras nos preparábamos para agregar árabe a la plataforma de ya 30 idiomas soportados. Y eso es lo que me califica para hablar aquí hoy. Les llevaré a través de por qué es importante apoyar de derecha a izquierda, nuestro enfoque estratégico, y los aprendizajes clave que pueden aplicar si se encuentran apoyando diseños de derecha a izquierda o árabe en su propia práctica de diseño y desarrollo. Pueden encontrar estas diapositivas y todos los recursos que mencionaré en buy.dai.ui.com, buy.directional.ui.com. Espero que esto se convierta en un recurso continuo y abierto para complementar esta charla. Así que con eso, comencemos con el por qué.

¿Por qué molestarse en apoyar de derecha a izquierda? Bueno, estos números deberían hablar por sí mismos. 313 millones de personas hablan árabe como su primer idioma. Tengo 10 millones de hablantes de hebreo y 130 millones de hablantes de persa. Y estás viendo a más de 400 millones de personas que leen y escriben de derecha a izquierda cada día. La oportunidad de mercado es bastante clara. Sin embargo, a pesar de esta audiencia masiva, es un hecho que el soporte de derecha a izquierda está constantemente roto en la web. Si sabes qué buscar, encontrarás errores en todas partes, incluso en sitios administrados por Microsoft y Google.

Y mira, lo entiendo. Este trabajo es realmente difícil y hemos sido condicionados a pensar en la derecha a izquierda como una ocurrencia tardía. Pero eso no lo hace aceptable. Recomiendo encarecidamente ver el video de Rami Ismail sobre este tema. Él articula cuán mal pueden sentirse estos errores para los hablantes nativos. También menciona notarabic.com, que cataloga innumerables ejemplos de escritura árabe mal hecha en películas importantes, en vallas publicitarias, en videojuegos, en todas partes. Es una charla divertida y reveladora. Y estos son exactamente los tipos de problemas que nos propusimos evitar en DeepL.

El árabe fue uno de los idiomas más solicitados en nuestra plataforma. Y este proyecto nos abriría a usuarios en 22 nuevos países y serviría a mercados que estaban en gran medida desatendidos por traducciones de calidad. Que es por lo que DeepL es conocido. Antes de comenzar, hicimos una investigación exhaustiva para comprender el modelo mental de las interfaces de derecha a izquierda. Y si íbamos a invertir en esto, íbamos a hacerlo bien. Así que seamos específicos. ¿Qué estamos haciendo realmente cuando hablamos de soporte de derecha a izquierda? Básicamente puedes pensar en ello como reflejar un diseño. Visualmente, imagina mirar tus manos y voltear todo de tu mano izquierda a tu mano derecha.

O, piénsalo como sostener un espejo frente al sitio web. Esto hace que nuestra UI se alinee con patrones cognitivos profundamente arraigados creados por los hábitos de lectura de toda la vida de nuestros usuarios. Ellos escanean, organizan y procesan información de manera natural y automática de derecha a izquierda. Incluso si esta información es solo visual y no lingüística. Esto no se trata del idioma específicamente, sino de la única cualidad de que está estructuralmente obligado a leerse en la dirección horizontal opuesta.

Forzar a alguien que ha pasado su vida consistentemente leyendo, escribiendo y, por lo tanto, pensando de derecha a izquierda en una UI de izquierda a derecha requiere que trabajen contra un sesgo mental conflictivo. Y esto va a sentirse muy extraño y antinatural. Puedes comparar esto con el japonés, que puede leerse horizontalmente incluso si tradicionalmente se lee verticalmente. Con el tiempo, el texto japonés horizontal se volvió dominante en la web junto con el texto vertical para otros medios de contenido. En este caso, el idioma fue lo suficientemente flexible como para adaptarse y nunca se formó un sesgo cognitivo direccional dominante entre los hablantes nativos de japonés.

Vale la pena mencionar, sin embargo, que hay un movimiento en Japón para promover el uso de texto vertical en la web. Y la nueva propiedad de CSS writing-mode se utiliza activamente para este propósito. Con esta propiedad, podemos cambiar el flujo de bloque de elementos específicos a vertical, donde antes necesitabas transformar y rotar el texto. Ahora es una línea, simple y semántica. Este es un buen ejemplo de la tecnología adaptándose a la codificación de diferentes idiomas. Y será interesante ver si tiene alguna implicación futura en la UI, pero de cualquier manera, es una característica nueva de CSS muy interesante para experimentar.

Pero volviendo al árabe. Y antes de profundizar más, quiero hacer una distinción importante. Lo que discutimos hasta ahora, reflejar diseños y revertir el flujo del documento, se aplica a todos los idiomas de derecha a izquierda, árabe, hebreo, persa y otros. Pero lo que voy a cubrir a continuación es específico de las cualidades del guion árabe, ya que eso es lo que estamos implementando en los DeepLUIs. Aunque algunas de las consideraciones aún podrían aplicarse a otros idiomas también.

Entonces, primero, el árabe es un guion cursivo. Las letras necesitan conectarse entre sí y tienen diferentes formas dependiendo de la posición en la palabra. Esta conectividad se rompe si el espaciado de letras es diferente de cero. Así que el primer paso es no usar espaciado de letras. Va a hacer que el texto sea ilegible. También necesitamos tratar las palabras árabes como unidades indivisibles. No puedes dividir palabras con guiones en varias líneas como puedes en inglés. Así que el segundo paso, no anular el salto de palabra o quizás mejor, es configurarlo en auto-phrase, lo que proporciona mejoras adicionales para todos los diferentes idiomas.

A continuación, el texto árabe es generalmente más compacto en inglés porque las palabras conectadas como y a menudo son solo una letra unida a la palabra siguiente. Aunque, su estructura rígida no siempre significa que va a ocupar menos espacio en general. A veces necesitas agregar min-width a botones y otros elementos para acomodar esta diferencia. Y los números, algo confusamente, siempre se escriben de izquierda a derecha. Y aunque hay números hindúes, los números arábigos son más utilizados, por lo que un número de teléfono aparecerá igual que en inglés. El árabe es un idioma más alto, por lo que cuando se trata de la altura de línea, disminuir la altura de línea puede causar que los diacríticos, que son los acentos y puntos que aparecen debajo y encima de los caracteres, se superpongan o se corten.

En general, necesitarás aumentar la altura de línea al menos un 25% para darles un espacio vertical adecuado. Hay un problema similar con los subrayados de texto, donde un subrayado puede interrumpir las formas de las letras de maneras que las hacen difíciles de leer. Esto también ocurre en inglés, pero a diferencia del inglés donde aún podemos distinguir la palabra, en árabe puede cubrir información visual crítica. Puedes resolver esto con text direction, skip, ink, all, pero los navegadores también están convergiendo en esto como el valor predeterminado.

También existen algunas diferencias de caracteres en la puntuación, que fue una adición moderna al árabe, donde las comas apuntan hacia arriba en lugar de hacia abajo y los signos de interrogación están invertidos. Necesitábamos acomodar esto eligiendo una fuente diferente. En Depot, usamos Noto, que es una elección muy común para el texto árabe. Así que ese fue el curso intensivo de árabe, suficiente para conocer las consecuencias en la UI y el contexto útil a medida que avanzamos en las siguientes secciones.

Así que lo más importante es establecer la dirección y el idioma, los atributos dir y lang en el HTML. El dir informará al navegador del flujo del documento. El valor predeterminado, ltr, que significa de izquierda a derecha, deberá establecerse explícitamente en rtl, de derecha a izquierda. También hay una opción automática, que te permite dejar que el navegador analice los caracteres y use la mejor suposición de la direccionalidad, pero generalmente no se recomienda. Puedes ver que el navegador hace mucho trabajo por nosotros. El texto y los elementos se reorganizan automáticamente y de forma gratuita. La alineación de texto predeterminada cambió a rt, lo mismo ocurre con los elementos de formulario como inputs, text areas y checkboxes y selects.

Y finalmente, los flujos inline, flex y grid se invertirán según la dirección de la página. Todo esto sucede porque cuando el atributo dir se incorporó por primera vez en HTML 4.0 a finales de los 90, cuando teníamos versiones de HTML, vino con una filosofía de diseño de que la dirección del diseño se consideraba una propiedad de contenido, no una preocupación de presentación. Así que, aunque puedes lograr los mismos efectos con la propiedad direction en CSS, nunca usamos esto en DeepL porque generalmente no se recomienda.

La idea es que esta información debe permanecer en el marcado, no en la hoja de estilo. Esto se complica más en DeepL porque tratamos con contenido mixto en la página. Un usuario podría estar usando la aplicación en un idioma mientras traduce texto a un idioma con la dirección opuesta. Hay al menos 4 estados diferentes, UI en inglés traduciendo al árabe, UI en inglés traduciendo desde árabe, UI en árabe traduciendo a otros idiomas y lo contrario. Así que confiamos en el atributo de dirección global tanto como sea posible, pero dado que este atributo se puede establecer en cualquier subconjunto de marcado en el documento HTML, podemos sobrescribirlo en nuestra interfaz para acomodar estos diferentes estados.

Esto refuerza la idea de que la dirección del texto no es solo una preferencia de hoja de estilo. Está integrado en la estructura fundamental de los sistemas de escritura que estamos mostrando en cualquier momento dado y está directamente en los caracteres Unicode. Nuestro objetivo era permitir a los desarrolladores escribir estilos agnósticos a la dirección que se adapten automáticamente según el atributo dir más cercano. Entonces, ¿cómo hacemos eso? Bueno, para empezar, floats, posiciones absolutas, fijas, margen y padding necesitan ser reescritos usando propiedades agnósticas a la dirección. Estas declaraciones no fueron diseñadas originalmente con la bidireccionalidad en mente, y usaron valores físicos, left, right, top y bottom, en lugar de valores lógicos, start, end, inline y block.

Si has estado escribiendo CSS desde el Zen Garden, puede llevar tiempo deshacer y reprogramar la memoria muscular de escribir left y right y en su lugar escribir start y end. Pero afortunadamente, la mayoría de las propiedades siguen este patrón. Left se convierte en start, right se convierte en end. Y cuando necesitas distinguir top y bottom, especificas inline start e inline end versus block start y block end. No perderé tiempo hablando demasiado sobre el soporte de los navegadores, ya que todos son diferentes y cada vez más modernos, pero siempre puedes usar primero propiedades físicas como respaldo, luego propiedades lógicas para mejora progresiva.

Los navegadores más antiguos simplemente ignorarán las propiedades no soportadas, pero en cualquier caso, con suerte, tu soporte de navegador es suficiente. Otro consejo aquí es que este principio de usar CSS lógico debería extenderse a tu convención de nombres CSS. En el ejemplo, en lugar de nombrar sidebar-left, usamos sidebar-start. Finalmente, en los casos donde queríamos dirigirnos a una dirección específicamente, como iconos, de los cuales hablaremos más adelante, usa el pseudo-selector dir para dirigir elementos basados en su dirección de texto. Veamos rápidamente algunos componentes de ejemplo para ver cómo se vuelven agnósticos a la dirección. Los botones con iconos son sencillos. La posición del icono se invierte al lado opuesto. Lo mismo ocurre con toast, pills, y así sucesivamente.

El texto y los iconos se invierten para mantener el flujo visual esperado. Aquí tenemos un input de búsqueda, con un icono al final. Necesitas padding en ambos lados, pero más en el final para evitar que el texto se deslice debajo del icono. Aquí es donde el valor de padding inline end se aplica a ambas direcciones, donde padding right no lo haría. Los interruptores también se invierten. El toggle se mueve al lado opuesto para mantener la consistencia con los checkboxes. Las tablas, breadcrumbs y tabs invierten toda su estructura. En cuanto a las tablas, las columnas fluyen de derecha a izquierda, con la primera columna apareciendo a la derecha. Los breadcrumbs y tabs siguen el mismo patrón. Los indicadores de progreso representan secuencias temporales, que se invertirán con el modelo mental. Algo como un indicador de plan de uso se malinterpretaría. Y cualquier proceso de varios pasos comenzará con el primer paso a la derecha y el último paso a la izquierda.

Hemos cubierto muchos problemas con CSS lógico, pero en nuestro código de React, tuvimos que hacer algunos refinamientos adicionales. Esto incluyó renombrar props para seguir las propiedades lógicas de CSS, como un punto de anclaje de un indicador de flecha, y manejar varios casos extremos en dropdowns, tooltips, etc. donde se necesitaba considerar la posición, alineación e incluso la dirección de la animación. Manejar esto con un valor de contexto y un hook en nuestro proveedor de sistema de diseño. Esto nos da una palanca para ajustar el soporte de derecha a izquierda en nuestros componentes de React.

Así que hablamos sobre el lenguaje, hablamos sobre estilos y hablamos sobre componentes. Ahora hablemos del ecosistema más amplio y los procesos que hicieron que este lanzamiento fuera exitoso. Lo primero que hicimos fue escribir un simple plugin de estilo con una función de autofix que convierte todas las propiedades físicas de CSS a sus contrapartes lógicas. Ya teníamos una biblioteca de estilo interna, así que esto fue una adición fácil a una herramienta que ya estaba integrada en el IDE y la base de código de todos. Sin embargo, la aplicación principal por defecto usa tailwind, por lo que no podíamos depender solo del estilo, sino que creamos una regla de ESLint que hace lo mismo pero cambia el CSS en línea y las clases de tailwind.

Así que puedes hacer esto fácilmente con una regex y un glop, o por supuesto con cualquier agente de IA en estos días. En ese momento, sin embargo, esto proporcionó beneficios secundarios importantes. Nos dio la oportunidad de educar al equipo personalizando la experiencia directamente en su IDE, en lugar de cambiar todo de un solo golpe. Como mencioné anteriormente, este es un cambio de modelo mental, y sentimos que era importante llevar esa comprensión y empatía a lo largo del trabajo, reforzando continuamente el hecho de que nosotros, como diseñadores y desarrolladores en DeepL, estamos construyendo para todos los usuarios.

Publicamos estos desde un monorepo de herramientas, bibliotecas y configuraciones relacionadas con UI, y de hecho pasamos más tiempo a este nivel que construyendo componentes para el sistema de diseño. Siempre hemos sentido que es importante encontrarse con los usuarios donde están y construir buenas herramientas y automatización para apoyarlos. El equipo del sistema de diseño somos solo yo y mi amigo Misha, dos personas, así que necesitamos ser ingeniosos y enfocar nuestro trabajo en esta capa conectiva entre componentes visuales, tokens de diseño y las personas, y menos en cualquiera de estas cosas individualmente.

Podrías llamarnos el pegamento o la tela, pero me gusta pensar en nuestro sistema de diseño como el micelio que conecta todos nuestros productos, y nosotros somos los mantenedores de este ecosistema. Esta capa no siempre visible que es necesaria para que todos estos elementos sobrevivan y se comuniquen. Así que no podemos hablar de derecha a izquierda sin hablar de iconos. Ciertos iconos necesitan espejarse, y saber cuándo puede ser complicado. El principio fundamental es separar los iconos direccionales de UI de los símbolos universales.

Los elementos de navegación se espejan porque su significado semántico depende de la dirección del flujo de contenido. En interfaces de izquierda a derecha, atrás apunta a la izquierda porque el contenido fluye de izquierda a derecha. En interfaces de derecha a izquierda, atrás apunta a la derecha porque el contenido fluye de derecha a izquierda. El significado de este botón permanece, ir al contenido anterior, mientras su dirección visual se adapta. Esto se aplica a cualquier flujo de movimiento o progreso, pero algo confusamente, un botón de reproducción, que también es como una flecha, no se voltea. Y eso es porque representa el mecanismo físico de la cinta que se mueve de izquierda a derecha independientemente de la dirección del texto.

Así es como funcionan las cintas. Esto hizo que nuestra ya desordenada implementación de iconos fuera aún más confusa. Teníamos una gran mezcla de archivos SVG, diferentes bibliotecas de React, y conjuntos de iconos inconsistentes, y ahora los desarrolladores no solo tenían que saber cuál usar, sino qué iconos se voltean y cuáles no. Así que pensando en este ecosistema nuevamente, aprovechamos la oportunidad para hacer una revisión.

Movimos todos nuestros iconos a un solo archivo de Figma donde podían ser anotados con una propiedad direccional, generalmente por el diseñador que agrega el icono, indicando si se voltean o no en derecha a izquierda. Tener esta configuración central justo al lado de la obra de arte hizo que la confusión sobre el volteo fuera mucho más fácil de entender. Luego tenemos una herramienta de construcción que utiliza la API de Figma para obtener todos los SVG de este archivo, combinar esos datos en un sprite SVG que almacenamos en el marcado de nuestra interfaz web. Esto también nos permite modificar la obra de arte según sea necesario y mantener todos los iconos, personalizados o no, en un solo lugar que los diseñadores gestionan como símbolos de Figma, manteniendo nuestros diseños y su desarrollo siempre sincronizados.

Para los desarrolladores, solo necesitan saber el nombre del icono, el mecanismo de volteo, CSS, accesibilidad, todo eso se maneja automáticamente por un componente web compartido. Hay una manera de anular la dirección si el contexto lo requiere, aunque esto se usa con moderación debido a lo específicos que podemos ser con los iconos. Lo genial es que con todos los iconos como datos y la direccionalidad incorporada, desbloqueamos toda una cadena de automatización. Cuando los diseñadores agregan un nuevo icono a Figma, nuestra herramienta de construcción genera automáticamente definiciones de TypeScript, actualiza la documentación, ejecuta pruebas de regresión visual en ambas direcciones, y cuando los equipos de iOS, Windows y Android escucharon que estábamos haciendo esto, simplemente agregamos otro paso en el proceso para generar un conjunto específico de plataforma para cada uno de ellos.