En esta entrega de componentes UI vamos a ver los componentes de carga loaders y skeletons. Es decir, aquellos componentes de la interfaz gráfica que harán entender al usuario que la información está siendo cargada o renderizada.
Es importante no confundir estos componentes de carga con el cargador de archivos o file uploader. Como vimos, éste pertenece al grupo de componentes de entrada de datos.
Loaders
Los loaders muchas veces se conocen como spinners porque la mayoría de sistemas de diseño solo incluyen el spinner como único loader. Sin embargo, como veremos después, los spinners son solo un tipo de loader.
Continuando con los loaders, estos tienen un rol fundamental en ofrecer una buena UX (aunque mejor sería que el tiempo de carga fuera 0). Es crucial hacer ver al usuario que el sistema no ha dejado de funcionar y que solo necesita tiempo para procesar la operación. Ya te hablé de la importancia de comunicar eventos traseros
También Apple da unas muy buenas indicaciones sobre los loaders en las Human Interface Guidelines de Apple que te resumo a continuación.
Lo primero que dicen es que mientras se carga el contenido, hay que evitar mostrar una pantalla en blanco o estática que pueda hacer pensar que la app es lenta o se ha congelado. Además, nos dan 4 buenas prácticas que te explico de seguido:
- Mostrar el contenido lo antes posible.
- Comunicar claramente que el contenido se está cargando y el tiempo que puede tardar en completarse.
- Mostrar algo que ver mientras esperan si es inevitable que la carga tarde mucho tiempo.
- Considerar la posibilidad de personalizar las pantallas de carga.
Otras consideraciones importantes referidas a los loaders son:
- El uso de loaders determinados vs indeterminados que explico debajo.
- Mantener el movimiento en los loaders porque el usuario puede entrar en pánico si ve que hasta eso deja de funcionar.
- Mantener la consistencia en la forma y la ubicación. Es decir si nuestro loader es un spinner que no cambie a la mitad, que no aparezca a veces sí y a veces no pero sí que lo haga siempre en el mismo sitio.
- Permitir cancelar la carga cuando sea posible pero advertir de las consecuencias.
Loaders determinados vs indeterminados
Los loaders determinados son aquellos que indican qué porcentaje de carga llevamos en cada momento o mejor aún, estiman el tiempo que falta para la carga completa. Por el contrario, los loaders indeterminados no dan ninguna referencia de cuánto le queda al proceso.
La adecuación de utilizar uno u otro vendrá dada por diferentes factores.
Generalmente para tiempos de carga menores 1 segundo incluso a veces de 2 es recomendable no ensuciar con ningún loader. A partir de ahí si el tiempo es superior a los 2 segundos y no se puede saber cuánto le queda al proceso de carga, usaremos un loader indeterminado y en caso afirmativo usaremos el determinado.
Por otra parte, si hemos empezado con un loader indeterminado pero se da la ocasión de cambiarlo a uno determinado debemos hacerlo. De igual modo, cuanto más precisos seamos con el loader determinado, mejor será para el usuario. Con esto quiero decir que si podemos dar un contexto útil y preciso ayudaremos más a entender el evento trasero.
Una buena referencia de contexto y loader determinado lo tenemos en Photoshop que mientras carga te explica con texto qué sucede “Leyendo texturas”, “Inciando preferencias”, “Cargando pinceles”
Ahora ya sí podemos ver los tipos de loaders
Spinners
El típico circulo que da vueltas. En el sistema de diseño Carbon de IBM recomienda que se use cuando la carga tarde más de 3 segundos y en Flutter de Microsoft cuando tarde más de 2. Este último además nos pide que solo usemos uno por carga y que no incluyamos más que unas pocas palabras para acompañarlo. Por el contrario, en Analytics de Google sí se ven varios a la vez sin problema como vemos en el ejemplo siguiente.
Barras de progreso
La barra de progreso es la animación en una barra horizontal. Esta es la que se suele utilizar como loader determinado. Una práctica común con las barras de progreso es que si son determinadas, avancen al ritmo de la carga pero si son indeterminadas la animación sea constante y bastante rápida.
Texto informativo
Como en el ejemplo que ponía de Photoshop, podemos tener un loader que sea solo texto avisando de qué está pasando para que esté cargando la operación.
Skeleton
Otro componente de carga es el skeleton que en algunos sitios se llama Shimmer y es una preview que actúa como placeholder hasta que se renderiza el contenido. A nivel visual es como un wireframe de baja fidelidad de la vista a cargar. Normalmente es estático pero a veces también puede tener cierta animación.
En desarrollo son especialmente útiles para las ocasiones en que una llamada de servicio tarda en devolver datos pero no queremos bloquear el renderizado del resto de la interfaz gráfico.
Un aspecto positivo de los skeleton es que mejoran la percepción de la capacidad de respuesta de la página. Dan la sensación de que las cosas suceden con fluidez, como que primero se carga la estructura y ya luego los detalles.
El skeleton tiene sentido para reflejar que la app funciona pero está sin conexión y como los spinners, cuando el tiempo de carga sea superior a 2 segundos.
De cara al diseño de skeletons es importante considerar los breakpoints del producto digital y proporcionar diferentes diseños para esos tamaños.
Pantallas de carga
Las pantallas de carga no son más que una pantalla dedicada exclusivamente a hacer de transición mientras se carga el siguiente contenido. Suelen estar formadas por una imagen estática corporativa de fondo y por una barra de progreso. Como variante también es posible encontrarse con vídeos o elementos interactivos en vez de imagen estática o con un elemento flotante con consejos o instrucciones de uso del producto digital.
Estas pantallas de carga son muy raras en apps y webs, relativamente comunes en software y especialmente frecuentes en videojuegos. A mí me gusta porque son buenas para el branding ya que son un espacio publicitario que sí o sí se va a tragar el usuario aunque no abusaría de ellas para no provocar un efecto rechazo.
De igual modo, las pantallas de carga son útiles para instruir al usuario en el uso del producto y ayudarle a conectar con él. Por el principio de Pareto sabemos que el 80% de los usuarios solo conoce el 20% del potencial del sistema. Así que hay mucho margen para instruir al usuario recalcando funcionalidades, ideas o atajos.
La utilidad de las pantallas de carga es para procesos lentos, yo no sé en qué punto es que se deben utilizar pero seguro que no cuando la carga tarde menos de 5 segundos.
Pantallas de presentación o Splash Screens
Aunque las pantallas de carga son muy atípicas en apps, sí hay un tipo de pantalla de carga que todas las apps tienen, la pantalla de presentación más conocida como splash screen.
Las splash screens son una pantalla introductoria que los usuarios ven al iniciar la aplicación. Son una oportunidad para reforzar la identidad de marca y mantienen a los usuarios ocupados mientras la aplicación carga en segundo plano.
Estas pantallas generalmente consisten en un fondo de color corporativo y el logo en svg ya que es lo más ligero para cargar pero también las hay que contienen una imagen o una animación. A veces incluso acompañadas de una barra de progreso.
Si la app va a tardar mucho en cargar deberíamos sacar al usuario de la splash screen y llevarlo a un skeleton de la vista principal para que sienta que aunque despacio, todo va avanzando correctamente.
