Una pantalla tarda tres segundos y aparece un spinner. Otra tarda lo mismo y dibuja media interfaz en gris. Las dos están esperando, pero no cuentan lo mismo. Elegir bien el indicador evita que el usuario confunda una carga normal con un bloqueo.
Empieza por dos preguntas
Antes de dibujar nada, averigua si el sistema conoce cuánto falta y si la estructura final ya está decidida. Esas dos respuestas separan casi todos los casos. Si solo se actualiza una tarjeta, mantén visible el resto de la pantalla; taparlo todo hace que una espera pequeña parezca una avería grande.
Carbon distingue los indicadores de carga, que solo confirman que el proceso sigue activo, de las barras que muestran avance. También recomienda un indicador en línea cuando se procesa un único componente. Un ejemplo sencillo: al invitar a una persona, anima el estado junto al botón y deja utilizable el resto de la vista.
Usa skeleton si conoces la forma
Un skeleton encaja cuando sabes que llegarán filas, tarjetas o una tabla, pero los datos aún no están listos. Sus bloques deben conservar el tamaño y el orden del contenido final; si cambian de altura al completarse, has escondido el salto en vez de evitarlo.
Carbon limita este patrón a contenedores y componentes de datos. No hace falta dibujar esqueletos de botones, casillas o menús. Yo usaría el mínimo: tres filas si habrá tres filas visibles, no una ciudad entera de rectángulos grises.
No inventes un porcentaje
Cuando el sistema conoce el total —por ejemplo, los bytes de un archivo—, una barra de progreso puede avanzar de 0 a 100 %. Si no puede calcularlo, usa un indicador indeterminado o un spinner y di qué está ocurriendo: «Procesando el archivo» ayuda más que una rueda muda.
El 73 % inventado resulta tentador porque parece preciso. También se vuelve sospechoso en cuanto se queda quieto. La guía de Carbon reserva la barra determinada para un objetivo medible y señala que el valor no debe retroceder ni reiniciarse.
Anuncia el cambio sin mover el foco
La espera también debe llegar al lector de pantalla. W3C explica que role="progressbar" comunica el valor, pero sus cambios no se anuncian automáticamente. Su técnica ARIA25 propone actualizar un texto en una región aria-live="polite", sin llevar allí el foco.
Conviene anunciar hitos útiles, no cada punto porcentual: inicio, progreso relevante, fin o error. Yo dejaría esta decisión escrita en el componente junto al patrón visual: texto anunciado y condición de salida. Es una nota corta y evita que el prototipo enseñe un skeleton mientras el producto termina con un spinner eterno.
0 comentarios
Todavía no hay comentarios.
Deja un comentario