- El nivel de acabado de una UI no mejora justo después de implementarla, sino mediante un proceso iterativo de seguir haciendo clic una y otra vez; el artículo lo compara con lijar madera
- Las transiciones de página y la navegación deben probarse mediante múltiples rutas de entrada, como clics, el botón Atrás del navegador, “Back” con clic derecho, la navegación hacia atrás dentro de la app y atajos de teclado
- Al alinear un
labely uninput type="radio"con flexbox y agregargap, se reveló una zona muerta entre el botón de radio y la etiqueta donde no se podía hacer clic - La solución fue quitar el
gapy agregar padding allabel, manteniendo el espaciado visual mientras se ampliaba el área clicable - Incluso pequeños defectos de interacción, acumulados, perjudican la experiencia de uso, por lo que hay que usar la UI de forma repetida y pulirla hasta que ya no se sientan “astillas”
Encontrar las asperezas de la UI haciendo clic repetidamente
- El trabajo de UI se parece a crear algo, hacer muchos clics, corregirlo y volver a hacer clic una y otra vez
- En las transiciones de página no alcanza con comprobar un solo flujo; hay que volver atrás de varias formas y revisarlas
- Usar el botón Atrás del navegador después de hacer clic
- Usar “Back” en el menú contextual con clic derecho después de hacer clic
- Usar la navegación hacia atrás dentro de la app
- Usar un atajo de teclado para volver atrás
- Este proceso se parece a “hacer clic para intentar romperlo”, como en QA, pero se acerca más a la sensación de encontrar asperezas y astillas al lijar madera
- Una UI de software puede tener demasiados estados y variables, así que se va puliendo con el uso repetido hasta que ya no se sientan “astillas”
La zona muerta de clics creada por el gap de flexbox
- En una lista de opciones de radio, se colocaron en la misma fila un
<label>y un<input type="radio">asociado - El CSS era una estructura simple con
display: flex,flex-direction: row,align-items: centerygap: .5remaplicados al contenedor - Al hacer clic repetidamente, se descubrió un punto muerto donde el control no se alternaba al presionar el espacio entre el botón de radio y la etiqueta
- La causa era el
gapde flexboxgapfacilita crear separación visual- pero no forma parte del área clicable de la etiqueta ni del input, por lo que se convierte en un espacio vacío para la interacción
- La solución fue eliminar el
gapy agregar padding allabel- Se mantiene la separación
- El área clicable de la etiqueta se amplía y la zona muerta desaparece
- Un pequeño defecto puede parecer insignificante, pero si se acumulan muchas de estas “pequeñas astillas”, la experiencia de la UI puede volverse dolorosa
1 comentarios
Opiniones en Hacker News
Si eres un desarrollador que también es un usuario que usa mucho directamente el producto que estás creando, tienes una gran ventaja para encontrar estos pequeños problemas.
Porque el desarrollador puede detectar personalmente esas pequeñas molestias antes de que el usuario se tropiece con ellas, y además está justo en posición de corregirlas.
Por eso parece que los equipos pequeños con un fuerte sentido de propiedad son efectivos. Cuando se siente el producto como propio, incluso las incomodidades menores que sufre el usuario se sienten como asunto de uno, y hacer que la UX sea lo más fluida posible se vuelve una cuestión de orgullo.
Salvo en casos donde es difícil usarlos internamente, como los productos empresariales, aunque la propiedad directa sea más débil, sí se genera un interés en el éxito del producto.
Me da curiosidad cuál será la UI más pulida.
Uno pensaría que en FAANG, con tanto dinero, la UI/UX debería ser bastante buena, pero cualquiera que haya usado Amazon.com o AWS, GCP, Azure probablemente sienta otra cosa.
Personalmente, considero que mcmaster.com tiene la UI/UX mejor pulida. Puedes encontrar lo que necesitas en pocos minutos.
En cambio, en sitios de grandes tiendas como Home Depot o Lowe’s, encontrar cosas como tornillos o madera en el tamaño exacto toma 10 a 15 minutos, y en móvil es peor.
Es increíblemente simple y práctico, pero aun así bastante potente. Puedes acotar piezas paso a paso o buscarlas, la comparación de precios se hace automáticamente, y las categorías de precio/calidad también están agrupadas de forma útil.
Cuando encuentras un número de parte, puedes ver la compatibilidad por año/fabricante/modelo, una descripción breve, fotos y si se envía desde el mismo almacén que otras piezas del carrito. Todo eso funciona en una sola página, sin fricción, y muy rápido en cualquier plataforma.
Responde extremadamente rápido y nunca vi bugs mientras la usaba. Me elevó el estándar de lo que creo que puede llegar a ser una app web.
De hecho, incluso tuvo un periodo dedicado únicamente a corregir problemas de usabilidad.
https://linear.app/changelog/2022-12-01-polishing-season-202...
https://web.archive.org/web/20231003205004/https://linear.ap...
En especial, la foto de perfil temporal es lo más molesto. Desde hace casi un año no funciona bien y no vuelve a la foto original.
Parece que ahí nadie está puliendo nada.
https://littlebigdetails.com es exactamente un lugar así.
La solución básica para este problema específico es poner el elemento de entrada dentro de la etiqueta.
Me preguntaba por qué, y probablemente sea porque simplifica la aplicación de temas al ajustar la posición o el padding de la etiqueta o del elemento de entrada.
[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
for/id: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...En radios o checkboxes, no debería alternarse solo al tocar la caja y el padding, sino también al tocar toda la etiqueta de texto.
Flexbox me parece un poco excesivo. Incluso con una sintaxis sin anidamiento se colocaría en línea, y creo que bastaría con agregar padding de la misma manera.
Para mitigarlo, hay que envolver
Fooen un elemento separado.Este tipo de cosas desapareció demasiado con Agile
Los ingenieros deberían tener tiempo para pulir el producto, pero en la práctica no lo tienen. Si QA no crea un ticket por un problema de espaciado, nunca se corrige
El cliente probablemente note estas cosas, pero que las reporte ya es un milagro; que eso termine convertido en un ticket también es un milagro; y que alguien le dé prioridad y lo arregle es otro milagro más
En realidad, la mayoría de los tableros de issues de las empresas son demasiado opacos desde el punto de vista del cliente, así que cuando uno encuentra un problema pequeño o un bug, es frustrante tener que ir y venir 50 horas para demostrar que es un bug y meter un ticket en el tracker
¿Crees que el modelo en cascada daba explícitamente tiempo para probar y pulir la UI?
Esto suele ser un proceso que debe priorizar el product manager y resolverse junto con un ingeniero de UX o diseñador competente. Si quieres, puedes meter esa prioridad en cualquier metodología de desarrollo, así que Agile no tiene relevancia aquí
Lo reporté varias veces en los últimos 3 años. Porque editar texto mientras escribes es extremadamente difícil y molesto
Como desarrollador web, me pregunto cómo se rompió algo así para empezar. No sé qué nivel de incompetencia hace falta para romper algo que funciona por defecto. Es una corrección que no debería tomar más de 30 minutos y mejoraría 1000 veces la experiencia de usuario de todos, pero 3 años después de reportarlo sigue igual
En Teams también reporté, a través de Microsoft Premiere Support, un bug por el que no se pueden usar las teclas HOME/END en el campo de teléfono, y la respuesta fue “funciona según lo diseñado”
No me sorprende que los clientes ya no reporten este tipo de bugs. Porque ni los empleados/desarrolladores ni la empresa se preocupan de todos modos
Soy el desarrollador líder de un producto y hay muchos problemitas por todos lados. No se siente nada bien ser responsable de algo, pero no tener autoridad para arreglarlo
Desde el punto de vista del negocio, la lógica es: si no afecta los ingresos ni la marca, ¿por qué gastar tiempo y dinero en arreglarlo? A largo plazo sí afecta la marca, pero a la mayoría no le importa porque en menos de 5 años cambia de rol o de empresa
Si al menos recibes una respuesta, ya es un caso relativamente bueno
Claramente hay un proceso que no satisface las necesidades del cliente, así que arréglenlo con el equipo
Si tienen ceremonias de Scrum, se puede plantear en la retrospectiva, pero en realidad se puede hacer en cualquier momento. La retrospectiva solo es un espacio para mirar deliberadamente las últimas semanas; lo que se detecte durante el camino debería intentarse resolver durante el camino
Es muy importante contar con alguien que tenga el criterio para ver y corregir pequeños problemas de UX
En diseño UX, esto suele compararse con cortes de papel para el usuario. No son fatales, pero reducen la satisfacción del usuario
Para sumar a lo que dice el autor: ese radio button no sigue la convención de usar un punto, y no una marca de verificación, para indicar el estado seleccionado. A primera vista, el usuario puede malinterpretar que se pueden seleccionar varios, o que no hace falta seleccionar ninguno
Probablemente sea un efecto secundario de la función que lo cierra al hacer clic afuera
Si del lado negativo están los “Papercuts”, del lado positivo está Juice, que también se trató hace poco en HN
Este texto muestra muy bien por qué odio la programación de UI
Las cosas impredecibles y que pueden desalinearse por detalles mínimos superan mi paciencia. Hasta cierto punto disfruto pensar en formas en que algo puede fallar y escribir pruebas, pero hacer clic al azar para ver si se rompe me distrae y me irrita
Me pregunto si implementar UI es intrínsecamente así de complejo, o si todavía no encontramos el modelo de programación correcto. A veces me pregunto si esperar que algo se vea y funcione como se pretendía desde el inicio es poco razonable
Pulir la UI solo debería hacer falta cuando se crea el componente por primera vez. A veces puede ser necesario combinar componentes de otra manera o hacer una implementación puntual
Sinceramente, si sabes lo que haces, no toma tanto tiempo. Un buen design engineer es especialista en este tipo de rol
Hay demasiada libertad, y los elementos básicos como los formularios deberían funcionar bien solo con sus valores predeterminados
Ya existen buenas formas de expresar la UI mediante código. El problema es el juego de suma cero del lado del negocio. Si no haces UI multiplataforma con el stack de UI más feo, HTML/CSS/JS, el costo se vuelve demasiado alto
Pero la plataforma web, aunque funciona más o menos bien para documentos, no tiene el nivel de abstracción adecuado para apps. Por eso la UI web se reinventa cada año con abstracciones nuevas y con fugas
Solo mantenerse al día ya es demasiado trabajo
En otras áreas pasa algo parecido. Si no hay una forma fácil de enviar una solicitud o de poner parámetros en una consulta, la presión natural hace que la gente invente todo tipo de soluciones a medias, aunque intente tener cuidado
La plataforma web está a la vanguardia en gráficos, pero como UI es realmente pésima. Y aun así nadie quiere reconocerlo ni cambiarlo. La gente confía solo en la primera parte, y el legado y la complejidad de los navegadores bloquean los cambios. Si lo haces como librería, no es “estándar”, así que a nadie le importa
Por otro lado, algunas UI usan una caja cuadrada para los radio buttons
Hay botones resaltados que no se activan con la tecla Enter
También hay tres menús escondidos detrás de símbolos distintos (puntos suspensivos, hamburguesa, kebab)
La calidad varía muchísimo. La gente que pule la UI merece mucho agradecimiento
Hasta Apple lo está haciendo :(
No entiendo por qué no es popular meter los elementos de entrada dentro de la etiqueta
Con eso el problema desaparece por completo y tampoco hace falta crear un
idúnico para usar enforPero como se sabe que todavía hay algunas tecnologías de asistencia que no interpretan el nuevo patrón estándar válido, seguir el estándar de la Edad de Bronce termina siendo la mejor práctica [1]
Supongo que otros frameworks hacen algo parecido. Si envuelves esos dos campos de entrada con un elemento
label, ya no es HTML válidoCon los radio buttons no es un problema, pero parece que algunos pasan por esto y luego lo hacen así “para estar seguros”. Es parecido a poner punto y coma al final de cada línea en JavaScript. Casi nunca hace falta, pero como no saben exactamente cuándo sí, lo ponen en todos lados
En los casos de uso comunes de checkboxes/radio buttons, la sintaxis también queda mucho más limpia
Envuelves el elemento de entrada con el label y, si quieres aplicar estilos al texto, metes el texto en un
span. Puedes poner ellabelcomodisplay:flexy manejar así también la posición del textoEn los bug bash usamos este método, y salen muchísimos más tickets que con quienes arman las combinaciones de casos de prueba como una matriz de producto cartesiano multidimensional
Está bien conocer esos casos de prueba como punto de partida, pero para encontrar problemas pequeños, las pruebas aleatorias superan rápidamente a las pruebas planificadas
Las pruebas planificadas suelen quedarse en el camino feliz o en errores esperados. Este tipo de pulido encuentra bugs de borde mucho más rápido
Siempre termino encontrando problemas o pequeñas mejoras. Son cosas que, en la práctica, no habrían salido mucho con pruebas planificadas
Llevo casi 4 años puliendo mi sitio personal (https://dustinbrett.com), y siento que podría seguir indefinidamente
Por suerte disfruto trabajar en él
Espero que haya sido todo :-)
Cuando veo “un SO de escritorio sobre una página web”, la mayoría se siente a medio hacer y, francamente, ya se volvió demasiado común; pero esto, en cambio, se ve muy sólido y bien pulido
Está muy bien hecho e inspira. También es bastante entretenido pensar cómo habrás implementado todo
La necesidad de usar un SO basado en ventanas en el teléfono
Si tuviera que señalar algo que falta, es que no se puede usar mouse4/mouse5 en el explorer. El “pulido” realmente puede seguir para siempre