The application should be quickly usable on mobile on startup

[CeyFun]

Description

The mobile version takes a long time to load every item when the user first connect without feedback indicating that the application is loading.

What is the valuable outcome that cannot be achieved because of this bug?

The application could be mistaken as not working, thus the users could give up using it pretty quickly.

For which stakeholder (people, role, project, domain) is it important?

This impacts the end users.

Reproduction scenario

Steps to reproduce the behavior:

1. Go to main page of the application.

Expected behavior

The first loading should be quick or at least indicated to the end user.

Environment

• OS: iOS or Android
• Browser: Every browser

Workaround

Wait.

Deliverables status

Phase 1

• [ ] Scenarios (Gherkin)
• [ ] Implementation strategy

Phase 2

• [ ] Acceptance tests (Capybara)
• [ ] Implementation

[benel]

Wait.

😉

[qhainos]

(en avance pour la suite)

fait avec @lusardia @CeyFun @dylan-correia

Après vérification, les images semblent assez optimisées et nous ne pensons pas que ce soit le problème principal. Selon nous, le problème vient plutôt du fait que les 1700+ images de vitraux s’affichent dès le lancement du site. L’utilisateur n’a aucune utilité de voir ces 1700 vitraux de manière non filtrée, en plus de cela, ces images se chargent à l’insu de l’utilisateur et lui demandent une certaine utilisation de ses données mobiles avant de prendre de la place dans le cache de son navigateur. (Après vérification, ce problème semble lié à Steatite qui envoit toutes les données d’un coup et ne peut pas les envoyer par paquets).

Solution 1 : Nous pensons qu’il serait plus intéressant de les charger progressivement au fur et à mesure que l’utilisateur fait défiler la page.

Solution 2 : La seconde solution serait de diviser les vitraux en pages contenant un nombre de vitraux que l’utilisateur peut choisir via un mini menu déroulant du même type que celui positionné sous le plan.

Solution 3 : Enfin, une dernière solution serait de ne charger aucun vitrail au chargement de la page et de ne les charger que lors de l’ajout d’attributs de la part de l’utilisateur (exemple : spatial, artiste…).

Nous privilégions la première solution car c’est celle qui nous semble la plus simple, à la fois pour les utilisateurs et à implémenter.

Maquettes imageant les solutions envisagées : https://www.figma.com/file/NAptXTPj8xrmkYZoEBPaFS/Issue-383?node-id=0%3A1

Partie du code impactée (classes, méthodes)

Nous avons trouvé la partie du code qui impacte le chargement des items (photos des vitraux) sur la page d’accueil. Nous pensons qu’il s’agit de la classe Corpora. Cette classe est située sur le fichier Porphyry/src/components/portfolioPage/Corpora.jsx nous nous intéresserons donc à la méthode Item(props) appelée dans la méthode render().

Le code de Steatite sera également à analyser et à modifier pour pouvoir optimiser l’envoi de données (par paquets si possible, au lieu d’envoyer tout d’un coup).

Difficultés algorithmiques et pistes de résolution

Chargement progressif (testé mais ne résout pas le problème) :

• Ajout de l’attribut “loading=”lazy”” dans la balise “img” (testé et charge les images uniquement quand elles sont affichées, mais ne règle pas le problème). Division en pages :
• / Aucun chargement sur la page d’accueil :
• /

Nos solutions ne changent pas, nous avons simplement vu que le problème se situait sur Steatite plutôt que dans Argos ou dans le code de Porphyry.

Données nécessaires : structure et stratégies de récupération

Pour pouvoir tester nos différentes solutions, nous aurions besoin d’avoir accès à un grand nombre de vitraux pour pouvoir comparer l’évolution des temps de chargement. En effet, sur notre base de données Argos, nous avons trop peu de données, le chargement est assez rapide.

Bibliothèques

Il ne semble pas nécessaire d'avoir recours à des bibliothèques pour simplifier l'implémentation.

Test de snippets de code

https://github.com/CeyFun/Porphyry/tree/test-lazy-loading

Services extérieurs

Pas besoin d'appeler des services extérieurs supplémentaires, le service steatite est utilisé pour optimiser le poids des images, mais ces dernières sont déjà très légères, nous pensons donc qu’il n’est pas nécessaire de les optimiser plus. Il faudra l’analyser et le modifier afin qu’on puisse procéder aux solutions envisagées.

Étapes préalables de développement

Pour avoir un jeu de données suffisant, nous avons redirigé les requêtes de Porphyry vers les serveurs Argos et Steatite hébergés à l’UTT.

[benel]

@qhainos @lusardia @CeyFun @dylan-correia Merci pour ce début de stratégie d'implémentation (en avance).

Solution 3 : Enfin, une dernière solution serait de ne charger aucun vitrail au chargement de la page et de ne les charger que lors de l’ajout d’attributs de la part de l’utilisateur (exemple : spatial, artiste…).

Comme mentionné lors de la réunion de ce matin, c'est cette dernière solution qui est à privilégier mais UNIQUEMENT quand on est en mobilité (en effet les besoins et les contraintes ne sont pas du tout les mêmes quand on est sur un bureau).

Nous avons trouvé la partie du code qui impacte le chargement des items (photos des vitraux) sur la page d’accueil. Nous pensons qu’il s’agit de la classe Corpora. Cette classe est située sur le fichier Porphyry/src/components/portfolioPage/Corpora.jsx nous nous intéresserons donc à la méthode Item(props) appelée dans la méthode render().

La zone est bonne... Après on voit dans votre texte qu'il y a un petit flottement pour savoir si sera plus précisément dans le render de Corpora ou d'Item (ou dans les fonctions qui permettent d'utiliser l'un dans l'autre).

C'est un peu normal car vous avez deux critères qui doivent être conbinés pour les cacher :

• l'affichage sur un petit terminal,
• le fait que la sélection soit vide (et donc que tous les items soient sélectionnés).

Le premier est faisable avec Bootstrap, mais le second est plus un traitement à partir des données de haut niveau. Donc effectivement ce ne serait pas étonnant qu'il y ait des modifications à deux endroits différents.

D'autres points étant hors-sujet, du coup, je n'en parlerai pas ici.

[Couapy]

A défaut de pouvoir charger l'application plus rapidement, ou reduire le nombre de requêtes, il serait aussi possible d'afficher un spinner (exemple ici), ou des skeletons (exemple ici), le temps que les différentes requêtes soient traitées. Cela permettrait de pouvoir tester cette fonctionnalité. Il faudrait également pouvoir tester les temps de rendu de l'application selon les réseaux.