-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nombre d'affichages de centres #37
Comments
Il faut réfléchir à comment cela va s'articuler avec la double-liste (centres dispos vs centres indispos) On pagine les 2 listes ? Ça nécessite un peu de maquetting / intégration également |
ok, je vais y réfléchir. sur ce template de résultat on a donc à réfléchir à... :
|
Avançons petit à petit, tu vois trop loin @francoisBouchet :-) Je sais bien que faire un design qui adresse toutes les problématiques est moins coûteux pour toi, mais ça risque de se transformer en une de ces grosses issues énormes à implémenter car elles révolutionnent complètement l'écran. Je préfèrerais qu'on y aille petit à petit : ici, le sujet est de paginer des résultats. |
bin le truc, c'est que je pense que la pagination ne solutionne pas voire complique le fait de trouver un lieu de vaccination proche de chez soi... notamment dans des zones géographiques vastes type Paris IDF, Lyon, Marseille. Créer des écrans intermédiaires, tu perds X% de tes utilisateurs à chaque changement d'écran (et tu en perds moins à les laisser scroller... c'est d'ailleurs une partie du succès de twitter ou facebook --> le rouleau de PQ sans fin... :). Dans ma carrière d'UX & CRO, j'ai pu drastiquement améliorer les performances des sites en réduisant les écrans (et même de résultats de recherche), plutôt qu'en segmentant sous prétexte de rendre les choses plus digestes. Donc pour le coup, paginer pour paginer, c'est non pour moi. |
En fait je pensais pas à rajouter des pages qui changent, mais que tout se fasse dans la meme page, sans redirection, juste du js. C'est possible ? |
et rendre les pages plus digestes, c'est plus efficace de le faire par la géographie. une petite ville. aura peu de centres et sa page sera lisible. un arondissement parisien sera également plus "droit au but" que le département parisien. |
j'ai bien compris, mais pour l'utilisateur, l'interaction est la même : un clic. et le coût d'un clic en CRO... $$$ |
@francoisBouchet le truc c'est que nos données sont segmentées par département aujourd'hui Je te laisse te rapprocher de l'équipe back si tu souhaites militer pour leur faire produire des JSON à un autre niveau géographique, mais je ne vois pas ce point arriver rapidement hônnetement |
Avant d'etre regrouper par dpt, elles sont aussi stockées de maniere generale : https://raw.github.com/CovidTrackerFr/vitemadose/data-auto/data/output/info_centres.json |
donc si je comprends bien, on a uniquement le code postal dans la string adresse ^^? ou sinon une string ville |
Je me vois mal faire télécharger 2Mo à tous les utilisateurs qui font une recherche sur VMD :/ |
Pas faux, après est ce que la donnee heures d'ouverture est utilisée ? |
non mais on peut faire le "group-by" CP ou ville côté server non ? et venir "hydrater" les pages non ? enfin c'est ce que j'avais cru comprendre par le concept d'hydratation... |
Pour le moment, on n'a aucun serveur Tout ce qu'on a, c'est des scripts qui viennent préparer la donnée pour qu'elle vienne être consommée ensuite par le front. |
on peut clôturer ce ticket. |
Pour info, la pagination permettrait également d'alléger le partie rendering du DOM sur les gros départements (on est actuellement à 62ms de rendering sur le 75 avec 79 centres dispos+indispos, contre 15ms sur un departements avec 0 centres. => en gros, 1ms par rdv possible Bon, je sais pas si on est amenés à arriver au millier de rdv affichés (plus on aura de plateformes, et plus on risque d'avoir des doublons) mais si c'est cas ça peut devenir handicapant. Clairement, aujourd'hui on est pas sur des nombres qui handicapent la navigation, donc sûrement pas une priorité. |
On peut mettre en place une pagination côté front sinon ? Pas de changement nécessaire côté back, on ne réduit pas la quantité de données récupérée mais ça aura le mérite d'améliorer l'ergonomie ? 🤔 Si j'ai bien compris, un trop grand nombre d'éléments entraînait les plantages dans Safari ? Si oui il semble important de passer un peu de temps sur ce sujet. |
Oui, je serais d'avis de faire un infinite scroll à la twitter et afficher par groupe de 20 centres à chaque fois. Honnêtement ça ne devrait pas être très compliqué à faire. |
…ely call re-render
…super slow when infinite scrolling
…ely call re-render
…super slow when infinite scrolling
Lorsque beaucoup de centres sont répertoriés, ils sont tous affichés sur la meme page.
Pourquoi pas mettre en place un systeme de "pages" avec un nombre de centres affichés maximum à l'écran (10 par ex)
The text was updated successfully, but these errors were encountered: