Hola Habr! Le presento a su atenci贸n una traducci贸n de
la publicaci贸n de Dan Abramov
"Los elementos de la ingenier铆a de la interfaz de usuario" sobre problemas y tareas contempor谩neas que deben resolverse en una buena interfaz. El autor examina los problemas fundamentales en el desarrollo de interfaces, cuya interpretaci贸n y soluci贸n por s铆 sola, sin usar bibliotecas y marcos prefabricados, puede proporcionar una comprensi贸n profunda de las soluciones en el campo del desarrollo frontend existente en el mercado.
Nota del traductorEl texto est谩 escrito y traducido en primera persona. El autor del original en ingl茅s es
Dan Abramov , el desarrollador de la biblioteca React para construir interfaces de usuario complejas.
En mi
煤ltima publicaci贸n, escrib铆 sobre lo importante que es poder reconocer las lagunas en el propio conocimiento. Podr铆a haber parecido que te estaba ofreciendo excusas para ser mediocridad. 隆Para nada! Pero, de hecho, nuestro conocimiento es un extenso tema de conversaci贸n.
Estoy convencido de que puede comenzar su conocimiento "de inmediato" y no hay necesidad de estudiar tecnolog铆a (pila tecnol贸gica para el desarrollo web - traductor aprox.) En un cierto orden. Pero tambi茅n creo que la acumulaci贸n de experiencia y habilidades profesionales en el campo elegido es de gran importancia. Personalmente, siempre he estado m谩s interesado en crear interfaces de usuario.
驴Y me preguntaba qu茅 entiendo y qu茅 encuentro importante? Por supuesto, estoy bien familiarizado con tecnolog铆as como Javascript y React. Sin embargo, las cosas m谩s importantes que vienen con la experiencia son evasivas y generalmente se escapan al tratar de articularlas con precisi贸n. Nunca intent茅 ponerlos en palabras. Este es mi primer intento de sistematizar y describir algunos de ellos.
Hoy en d铆a, hay muchas formas diferentes de aprender tecnolog铆a. 驴En qu茅 biblioteca apostar en 2019? 驴Y en 2020? 驴Debo aprender Vue o React? O angular? 驴Qu茅 pasa con Redux o Rx? 驴Necesito aprender Apolo? REST o GraphQL? 隆Es f谩cil perderse aqu铆! Adem谩s, el autor tambi茅n puede estar equivocado.
Mis mayores logros en cognici贸n no est谩n relacionados con ninguna tecnolog铆a en particular. Comenc茅 a entender m谩s cuando estaba resolviendo un problema espec铆fico de la interfaz de usuario (interfaz de usuario - traductor aprox.). Al mismo tiempo, a veces encontr茅 bibliotecas y patrones de otras personas que me ayudaron a resolver el problema. Y a veces escribi贸 sus propias decisiones (tanto buenas como terribles).
Esta combinaci贸n, que consiste en
comprender el problema , experimentar con
herramientas y aplicar varias
soluciones , me dio la experiencia y las habilidades m谩s valiosas.
Esta publicaci贸n se centra solo en los problemas que trat茅 en el desarrollo de interfaces de usuario.
Si estaba desarrollando interfaces de usuario, lo m谩s probable es que se haya encontrado con algunos de estos problemas, directamente o al usar bibliotecas. En ambos casos, le recomiendo que trabaje en una aplicaci贸n simple sin bibliotecas, intente reproducir y resolver estos problemas. No hay una soluci贸n verdadera para ninguno de ellos. La experiencia viene con conocer estos problemas y explorar posibles soluciones, dadas las fortalezas y debilidades de cada uno.
Consistencia
Le gust贸 la publicaci贸n y apareci贸 la inscripci贸n: "Usted y 3 amigos m谩s lo apreciaron". Has vuelto a hacer clic en el bot贸n Me gusta y la inscripci贸n desapareci贸. Suena f谩cil! Pero es posible que dicha inscripci贸n est茅 presente en varios lugares de la pantalla. Es posible que tambi茅n haya una indicaci贸n visual adicional para el me gusta (por ejemplo, el color de fondo del bot贸n), que tambi茅n deber铆a cambiar. Y la lista de "me gusta", que se recibi贸 previamente del servidor y se muestra cuando se pasa el mouse, ahora debe incluir su nombre. Y si fue a otra secci贸n o hizo clic en el bot贸n Atr谩s, entonces la publicaci贸n no debe "olvidar" que tiene su gusto. Como puede ver, incluso la integridad local para un solo usuario crea una serie de tareas dif铆ciles. Al mismo tiempo, otros usuarios tambi茅n pueden interactuar con los datos que se muestran en usted (por ejemplo, como la publicaci贸n que est谩 viendo). 驴C贸mo mantenemos los datos sincronizados en diferentes partes de la pantalla? 驴C贸mo y cu谩ndo debemos verificar los datos locales con el servidor y recibir / enviar cambios?
Capacidad de respuesta
Las personas permiten la falta de comentarios visuales para sus acciones solo por un tiempo muy limitado. Para acciones
continuas del usuario, como el desplazamiento, la falta de reacci贸n de la aplicaci贸n solo es posible durante el per铆odo m谩s corto. Incluso omitir un cuadro a 16 milisegundos ya parece defectuoso e inacabado. Para acciones
discretas (de una sola vez), como un clic, seg煤n algunos estudios, los usuarios normalmente perciben demoras en la respuesta de menos de 100 milisegundos. Si la acci贸n lleva m谩s tiempo, debe mostrar un indicador visual. Sin embargo, hay varias tareas contraintuitivas. Los indicadores que provocan un cambio en la plantilla de la p谩gina o que pasan por varias etapas alternas pueden hacer que la acci贸n tarde m谩s en "sentirse" de lo que realmente fue. Del mismo modo, la respuesta de una aplicaci贸n en 20 milisegundos al omitir un fotograma de la animaci贸n puede "sentirse" m谩s lenta que una animaci贸n completa en 30 milisegundos. Nuestra conciencia no funciona como puntos de referencia. 驴C贸mo mantenemos las aplicaciones receptivas?
Tiempo de respuesta (latencia)
La computaci贸n inform谩tica y la transmisi贸n de datos a trav茅s de una red lleva tiempo. A veces podemos ignorar el tiempo de c谩lculo si no afecta la capacidad de respuesta en los dispositivos de los usuarios (sin embargo, aseg煤rese de haber probado su c贸digo en dispositivos antiguos y de bajo presupuesto). Sin embargo, no se puede evitar procesar el tiempo de transmisi贸n de datos a trav茅s de la red, 隆se puede calcular en segundos! Una aplicaci贸n no puede simplemente "bloquearse" mientras esperamos que se carguen los datos o el c贸digo. Esto significa que cualquier acci贸n que requiera nuevos datos, c贸digo o activos es potencialmente as铆ncrona y debe manejar el estado de su carga. Esto es cierto para la gran mayor铆a de pantallas y elementos. 驴C贸mo manejar adecuadamente la demora en la transmisi贸n de datos sin mostrar una cascada de hiladores giratorios o "agujeros" vac铆os en la interfaz? 驴C贸mo evitar los cambios de dise帽o de p谩gina? 驴Y c贸mo cambiar las dependencias asincr贸nicas sin la necesidad de una reescritura de c贸digo constante?
La navegaci贸n
Esperamos que la interfaz sea "estable" al interactuar con ella. Los elementos no deber铆an desaparecer repentinamente. La navegaci贸n, tanto dentro de la aplicaci贸n (por ejemplo, enlaces) como externa (por ejemplo, el bot贸n Atr谩s en el navegador) tambi茅n debe cumplir con este principio. Por ejemplo, cambiar entre las pesta帽as
/profile/likes y
/profile/follows following en una secci贸n de usuario no deber铆a anular el contenido del campo de b煤squeda fuera de esta secci贸n. Incluso cambiar a otra pantalla deber铆a parecer un paseo a otra habitaci贸n. Las personas esperan que cuando regresen, encuentren todas las cosas donde las dejaron (y, tal vez, estar谩n felices con algunas cosas nuevas). Si estaba en el medio de su cinta, hizo clic en la pesta帽a de perfil y luego regres贸 a la cinta, entonces definitivamente no desea volver a desplazar la cinta desde el principio o esperar hasta que se cargue el estado pasado de la cinta. 驴C贸mo dise帽ar una aplicaci贸n para manejar la navegaci贸n arbitraria del usuario sin perder contexto importante?
Estancamiento
Podemos hacer que la implementaci贸n del bot贸n Atr谩s sea instant谩nea agregando un cach茅 local a la aplicaci贸n. Para hacer esto, almacenaremos los datos necesarios en el cach茅 (datos del estado anterior - aprox. Traductor). Incluso podemos actualizar te贸ricamente el cach茅 para mantener los datos actualizados. Sin embargo, la implementaci贸n del almacenamiento en cach茅 conlleva nuevos desaf铆os. El cach茅 puede estar desactualizado. Si cambi茅 el avatar, deber铆a actualizarse incluso en el cach茅. Si publiqu茅 una nueva publicaci贸n, deber铆a aparecer inmediatamente en la memoria cach茅; de lo contrario, la memoria cach茅 dejar谩 de ser v谩lida. Tal c贸digo puede eventualmente volverse demasiado complejo y dif铆cil de mantener. 驴Qu茅 pasa si el proceso de publicaci贸n falla? 驴Cu谩nto dura el cach茅 en la memoria? Cuando volvemos a obtener el conjunto de datos, 驴fusionamos los datos nuevos con los datos almacenados en cach茅 anteriormente, o nos deshacemos del cach茅 anterior y almacenamos todo el conjunto nuevamente? 驴C贸mo deben presentarse la paginaci贸n y la clasificaci贸n en el cach茅?
Entrop铆a
La segunda ley de la termodin谩mica dice aproximadamente lo siguiente: "Con el tiempo, todo se convierte en un completo desastre" (no literalmente, por supuesto). Esto tambi茅n es cierto para las interfaces de usuario. No podemos predecir las acciones de un usuario en particular y su secuencia. En cualquier momento, nuestra aplicaci贸n puede estar en uno de los enormes (隆gigantescos!) N煤mero de estados diferentes. Hacemos todo lo posible para que el resultado sea predecible y limitado de acuerdo con nuestro dise帽o. No queremos mirar la captura de pantalla con el error y pensar: "驴C贸mo sucedi贸 esto?" Para
N estados posibles, hay
N 脳 (N - 1) posibles transiciones entre ellos. Por ejemplo, si son posibles cinco estados diferentes para un bot贸n (normal, activo, desplazarse, resaltado e inhabilitado), entonces el c贸digo responsable de cambiar el bot贸n debe ser correcto para 5 脳 4 = 20 posibles transiciones, o prohibir expl铆citamente algunas de ellas. 驴C贸mo lidiamos con el aumento combinatorio en los posibles estados y creamos una salida visual predecible?
Prioridad
Algunas cosas son m谩s importantes que otras. Tal vez su interfaz de di谩logo deber铆a aparecer estrictamente "encima" del bot贸n con el que se llam贸 e ir m谩s all谩 del contenedor principal. O bien, una tarea reci茅n programada (es decir, el resultado de un clic) puede ser m谩s importante que una tarea de larga duraci贸n que ya ha comenzado. A medida que la aplicaci贸n se acerca, sus diferentes partes, escritas por diferentes personas o incluso equipos, comienzan a competir por recursos limitados, como la potencia de procesamiento del procesador, el tr谩fico de red, el espacio de la pantalla o el tama帽o del paquete. A veces puede distribuir elementos en una sola escala de "importancia", similar a la regla CSS del
z-index .
Pero generalmente no termina con nada bueno . Cualquier desarrollador considera sinceramente que su c贸digo es importante. Pero si todo es igualmente importante, significa que nada es importante. 驴C贸mo podemos hacer que las partes independientes de la aplicaci贸n
interact煤en en lugar de luchar por recursos limitados?
Accesibilidad
Los sitios que no est谩n adaptados para personas con discapacidad no son un problema altamente especializado. Por ejemplo, en Inglaterra cada quinto usuario enfrenta este problema (
aqu铆 hay una infograf铆a visual). Lo sent铆 en m铆 mismo. A pesar de que solo tengo 26 a帽os, apenas uso sitios con fuentes finas y un esquema de color opaco. Intento usar el trackpad con menos frecuencia, pero me da miedo el d铆a en que tenga que usar un sitio inadecuado para el teclado. No debemos convertir nuestras aplicaciones en una pesadilla para las personas con discapacidad, y la buena noticia es que no es tan dif铆cil. Debe comenzar explorando soluciones y herramientas. Adem谩s, debemos hacerlo simple y comprensible para que los dise帽adores y desarrolladores tomen las decisiones correctas. 驴Qu茅 podemos hacer para asegurarnos de que la disponibilidad de nuestras aplicaciones est茅 habilitada de manera predeterminada y no se realice una revisi贸n tard铆a?
Internacionalizacion
Nuestras aplicaciones deber铆an funcionar en todo el mundo. S铆, las personas hablan diferentes idiomas, pero adem谩s de esto, el soporte para la escritura es necesario de derecha a izquierda y con un m铆nimo esfuerzo por parte de los desarrolladores. 驴C贸mo podemos admitir diferentes idiomas y scripts sin perder la capacidad de respuesta de la aplicaci贸n y el tiempo de respuesta?
La entrega
Debemos entregar el c贸digo de la aplicaci贸n a la computadora del usuario final. 驴Qu茅 m茅todo de transmisi贸n y formato usaremos? En esta pregunta, cada respuesta ser谩 un compromiso con su propio conjunto de fortalezas y debilidades. Por ejemplo, las aplicaciones nativas tienen que descargar todo su c贸digo por adelantado debido a su gran tama帽o. Mientras que las aplicaciones web suelen tener tiempos de arranque mucho m谩s cortos, pero se ven obligadas a manejar una gran cantidad de latencia y descargas durante el uso. 驴C贸mo decidimos qu茅 tipo de retraso elegir entre estas dos opciones? 驴C贸mo optimizamos los tiempos de respuesta en funci贸n de las estad铆sticas de uso del usuario? 驴Qu茅 datos necesitamos para tomar la mejor decisi贸n?
Flexibilidad (Resiliencia)
A nadie le gusta encontrarse con errores en sus propios programas. Sin embargo, algunos errores llegar谩n inevitablemente a la producci贸n. Y es muy importante: lo que suceder谩 entonces. Algunos errores causan un comportamiento incorrecto, pero estrictamente definido y predefinido. Por ejemplo, su c贸digo muestra un estado inapropiado para una condici贸n dada. Pero, 驴qu茅 sucede si, como resultado de un error, la aplicaci贸n dej贸 de renderizarse por completo? En este caso, no podremos continuar con la ejecuci贸n significativa del programa, ya que no se determinar谩 la salida visual. Un error al procesar una publicaci贸n desde el feed no debe "interrumpir" el procesamiento de todo el feed o poner la aplicaci贸n en un estado inestable, lo que conducir谩 a m谩s errores. 驴C贸mo podemos escribir c贸digo que a铆sle los errores al representar o recibir datos en una de las partes y contin煤e el correcto funcionamiento del resto de la aplicaci贸n? 驴Qu茅 significa la tolerancia a fallos al crear interfaces de usuario?
Abstracci贸n
En una aplicaci贸n peque帽a, podemos codificar y resolver todos los problemas anteriores en la frente. Pero las aplicaciones tienden a crecer. Queremos poder
reutilizar, bifurcar y combinar diferentes partes de la aplicaci贸n y hacerlo junto con otras personas. Queremos definir l铆mites claros entre las partes del todo que ser谩n aceptadas por diferentes personas y al mismo tiempo evitar una l贸gica demasiado r铆gida, ya que a menudo cambia y evoluciona en el proceso de trabajo. 驴C贸mo creamos abstracciones que ocultan los detalles de la implementaci贸n de la interfaz de usuario? 驴C贸mo podemos evitar la recurrencia de estos problemas con el crecimiento de la aplicaci贸n?
Por supuesto, hay muchos m谩s problemas que no he mencionado. Esta lista no es de ninguna manera completa o exhaustiva. Por ejemplo, no toqu茅 el tema de la colaboraci贸n entre dise帽o y desarrollo, el tema de depuraci贸n o prueba. Quiz谩s volveremos a esto en otro momento.
Es tentador leer sobre estos problemas, teniendo en cuenta como soluci贸n un marco espec铆fico para mostrar datos o una biblioteca para recibir datos. Pero le recomiendo que imagine que estas soluciones no existen e intente leer nuevamente. 驴C贸mo tratar铆as de resolver estos problemas? Intenta realizar tus ideas en una aplicaci贸n simple. Estar茅 encantado de ver los resultados de tus experimentos en Github. (Solo etiquete a Dan Abramov en
Twitter y adjunte enlaces a los repositorios - aprox. Traductor).
Lo que es especialmente interesante en estos problemas es que la mayor铆a de ellos se manifiestan en cualquier escala. Puede encontrarlos cuando trabaje en un widget peque帽o, como informaci贸n sobre herramientas, y en aplicaciones enormes como Twitter o Facebook.
Piense en los elementos de la interfaz de usuario no triviales de la aplicaci贸n que le gusta usar y vuelva a ejecutar la lista de los problemas anteriores. 驴Puedes describir las compensaciones que hicieron los desarrolladores? 隆Intenta reproducir un comportamiento similar desde cero!
Me di cuenta mucho sobre el desarrollo de buenas interfaces de usuario, experimentando con estos problemas en peque帽as aplicaciones sin usar bibliotecas y marcos de terceros. Se lo recomiendo a cualquiera que quiera obtener una comprensi贸n profunda de las soluciones y las compensaciones al desarrollar interfaces complejas.