En estos días he estado trabajando con un proyecto donde estoy intentando hacer una interfaz lo más agradable, amigable y útil para el usuario, ya que la interfaz actual no está siendo muy amigable; un punto de este proyecto es que ya estaba previamente programado y los servidores están respondiendo lento, por lo que el cliente queda a la espera de su información y cree que el sistema no está haciendo nada y terminan cerrando el sitio o recargando una y otra vez.

Una herramienta que me permitió corroborar este dato fue SmartLook que gracias a sus grabaciones pude ver que un problema está sobre la recarga constante del sitio por lo que el servidor se está saturando cada vez más.

Gracias a que este proyecto está sobre Angular (ojo, no AngularJS), puedo aprovechar el render del HTML previo a la carga desde el API. Pero ¿Cómo podía entonces hacerle saber a un usuario que algo está sucediendo como para que evite recargar la página y por qué tarda tanto en cargar el API o por qué tarda tanto en mostrarse la respuesta, qué está pasando?

Antes de empezar a mejorar las cosas, hay qué pensar qué sucede además de que la gente recarga y es aquí donde solicité, ¿por qué tarda tanto en cargar esto o qué sucede?, y me explican que el API para el sitio principal está cargando al rededor de 100 sitios distintos desde donde lee información, la procesa y posterior le da una respuesta al cliente, pero a veces los servidores de las páginas se saturan, o tardan en procesar esa información, ¿qué información?. Generalmente información de lugares y de noticias.

La aplicación lo que está haciendo es que un cliente cuando se registra, selecciona su ciudad y el sistema se conecta de forma automática a varios sitios para obtener información de lugares como bares, antros, restaurantes, lugares de entretenimiento, entre otros, los pinta en un mapa y luego, llama información de noticias locales, así como de otros datos de interés de la persona.

El proceso actual está tardando en una respuesta desde 25 hasta 62 segundos en promedio con una carga que va desde 25 megas hasta 121 megas en algunos casos de las pruebas que se le hicieron. Es decir, un cliente debe estar 25 a 62 segundos viendo una pantalla con solo un par de textos y mal acomodada mientras cargaba, y esto en pruebas básicas a 5mbps de conexión, en móviles se disparaba hasta 150 segundos en promedio.

Ya que tenemos un contexto para entender, es donde podemos intentar mejorar la respuesta del servidor, podemos mejorar el backend en general, subirle al servidor la capacidad y demás, pero, ¿tiene algún sentido esto?, realmente no, porque así se mejore por mucho el API y el servidor si los sitios que ofrecen la información son lentos se seguirá tardando en mostrar la información. Es por ello que debemos atacar directamente el problema en las interfaces de forma inicial.

En este caso apreciamos los placeholders (o marcadores) y un preloader (o precargador) de Slack que está funcionando en su mayoría del lado del cliente, es decir, lo único que carga en este apartado son las frases que podemos personalizar, de esta forma, slack te hace pensar que está cargando algo o al menos, que algo sucede mientras esperas.

Es por ello que esto sería el mejor método para que el usuario sepa que algo sucede. Pero, ¿qué más se puede hacer aparte de los placeholders y precargadores?, de hecho aquí quisiera abordar un punto extra al de esta publicación, pero lo haremos al final de la misma.

Ya teniendo un contexto y una forma de atacar el problema se desarrolló la idea, la interfaz cargaba un mapa, este mapa es un GMap con los múltiples puntos, que era la parte central superior, en la barra lateral cargaba la información del cliente, en la parte derecha publicidad, en la parte central debajo del mapa una serie de publicaciones para noticias y por último una barra que se movía con nosotros con otros datos como clima, etc.

Para ello podemos ver que hay 5 objetivos principales, las imágenes, los textos de apis externas (clima y otros), las publicaciones, la publicidad y la información del cliente.

Aquí tenemos la forma para las imágenes que usa Medium, primero las muestra borrosas por así decirlo y luego las carga totalmente.

Esto se conoce como “lazy load” es decir una forma de cargar imágenes de por ejemplo 50px por 50px las cuales se difuminan totalmente para que no se vea el pixelaje extremo por expandir la imagen y hacen creer al usuario que ahí habrá una imagen, este fue mi primer objetivo, lo que hice fue que en realidad no usaba del todo imágenes reales, en realidad tomaba desde los assets del sitio unas 50 imágenes difuminadas y las cargaba de forma aleatoria, que aparentasen imágenes reales.

Hasta aquí cumplimos con las imágenes para aparentarle al usuario que está cargando algo, ahora hay que hacer el apartado de textos extras, para el apartado de clima por ejemplo, se muestra un ícono default con “tres puntos suspensivos cargando”, estos lucen más o menos de la siguiente forma:

De esta forma el cliente sabe que hay algo ahí pero está “cargando”, al menos ya sabrá que está obteniendo datos, por ello hay 2 puntos completos, para la publicidad, y las publicaciones se combinan haciendo uso de los placeholders.

Para ello se desarrolló la base de la tarjeta donde se mostraría la información, en el caso de publicidad por ejemplo es un recuadro blanco con un recuadro gris interno marcando que algo aparecerá ahí así como las publicaciones con el siguiente estilo por ejemplo:

De esta forma el cliente ya tiene una interfaz formada en su mayoría. Lo único que falta es aplicar esto a la información del cliente, para esto, se almacenó la información del cliente directamente en su navegador y así comprimiendo la imagen de perfil con base64 para leerla desde los storages del navegador, se ahorra la carga de sus datos ya que estos no cambiarán a menos que lo hagan los usuarios directamente y cuando decidan editar sus datos entonces se hace la actualización en el storage.

De esta forma, la página ya muestra una interfaz prácticamente cargada en su totalidad, pero sin información final, sin embargo a pesar de esto el cliente entonces entenderá que algo está cargando y aparecerá de esta forma. Gracias a unos cambios dentro del API, así como mejoras y estos cambios en la interfaz, se notó que 72% de los usuarios ya no están actualizando o cerrando la pestaña, es decir, de cada 100 usuarios solamente 28 siguen con un problema, pero de estos 28, 8 usuarios únicamente cierran la página, comparando los datos en los que se tenían 31 cierres, 40 actualizaciones y 29 usuarios que esperaban, a 72 usuarios que esperan, 8 cierres y 20 actualizaciones nos permite un cambio drástico.

Extra: Cargas por etapas

Algo que también ha estado ayudando y que se espera, se irá mejorando en esta plataforma, es que se aplicaron cambios en el API para que se permita la carga por etapas, es decir, en vez de cargar 100 sitios por así decirlo, carga únicamente 10, luego que lo logra y las imprime, empieza la precarga de otras 10 y así sucesivamente, por lo que de los mencionados hasta 62 segundos, para mostrar los primeros 10 sitios de datos+ los sitios en el mapa, por etapas también terminamos con una carga promedio de 2 a 27 segundos en promedio y en móviles o redes lentas de 150 segundos promediados se bajó a 41.

De esta forma combinado a los marcadores o placeholders + los precargadores o preloaders, con una buena interfaz ha mejorado el uso de la plataforma y se vió un incremento de usuarios incluso de 21 usuarios cada minuto a 27 haciendo que la plataforma se empiece a posicionar poco a poco mejor ante los usuarios.