+1
Navigation entre les sorties
+1
2 Likes
il faut créer le ticket sur Github en « new feature »
j’ai mis l’issue sur github
2 Likes
Hello !
Ça fait un moment que j’avais envie de faire ça : pouvoir regarder une sortie « dans le cadre d’une recherche » et pouvoir donc avoir des boutons suivants/précédents.
Ça s’applique pour voir les sorties associées à un itinéraire, mais dans pas mal d’autres cas, par exemple : parcourir tous les itinéraires associé à un point de passage, toutes les sorties dans une zone donnée de la carte, …
panglesd a travaillé sur cette fonctionnalité. Merci à lui !
Il a des questions : https://github.com/c2corg/c2c_ui/pull/3676
Il faudrait lui répondre pour qu’il puisse avancer.
[Edit Mod: sujet rendu indépendant de la discussion ajout d’un classement par appréciation sur les sorties]
1 Like
Personne n’a d’avis sur les questions posées ?
Faudra pas venir râler ensuite si les choix faits ne vous plaisent pas 
1 Like
Salut ! Ici « panglesd ».
Ca va faire une requete en plus au service
/outingsà chaque affichage de sortie concerné? Si oui, vous avez vérifié que le backend va tenir la charge ?
Bonne question, à laquelle je ne saurai répondre tout seul !
Une alternative serait de modifier l’API pour n’avoir qu’une requête à faire, mais cela fait une modification bien plus grosse…
Et sinon, fbunoz propose un autre design des flêches:
Quelqu’un a-t-il un avis/d’autre suggestions ?
Je pose une question naïve : cette query_list, il ne faudrait pas plutôt
stocker la liste des numéros de document issue de la recherche dans un cookie ou autre, plutôt que de faire une requête à /outing ? Ça permettrait pas de faire un tri ?
Je dis peut-être des bêtises, mais j’ai l’impression que c’est une question de mise en page du site (UI), et que cela ne devrait pas impacter l’API ni les performances.
Pour l’ergonomie, j’aime bien les flèches proposées par Bubu et leur emplacement. C’est assez intuitif et ne rentre pas en concurrence avec d’autres choses (donc ergonomique). Faut définir dans quel cadre c’est utile. Selon moi :
- pour naviguer dans les sorties d’un itinéraire. Quand on clique sur les sorties à partir d’un itinéraire, on peut parcourir celles-ci. Quand on clique sur suivante à partir de la dernière de la liste, appel API pour charger les suivantes et Maj la liste ? Le tri de base est par date, donc pertinent.
- pour naviguer dans les itinéraires d’un point de passage. Même fonctionnement, sans filtre par activité. Par contre le tri par défaut est aléatoire, alphabétique serait mieux (mais reste sur une liste partielle, donc pas si pertinent).
- pour naviguer dans les résultats d’une recherche, avec donc des filtres (éventuellement issu de voir toutes les sorties/ tout les itinéraires). Dans ce cas, il faudrait ajouter entre les flèches un bouton « retour à la recherche ». Tri ?
Le 3e point me semble moins important.
Voilà ma réflexion rapide de non dev.
1 Like
Comment tu as fais pour l’instant ? (A priori il n’y a pas de site de demo online ?)
Est-ce que la page peut conserver des données entre 2 chargements de documents de même nature ? (sans utiliser les data storage, c’est juste temporaire).
Si oui, depuis une liste de documents, quand on clique sur un document les données de la liste seraient sauvegardées (elles peuvent même être sauvegardées dès le chargement de la liste en prévision). En utilisant les flèches, ça ne ferait que charger le contenu du doc suivant ou précédent, en recherchant dans les données sauvegardées quel est l’id du doc suivant/précédent, donc pas de requète pour récupérer la liste des docs à chaque affichage de doc. Quand on arrive au début ou à la fin de liste sauvegardée, ça fait une requête pour obtenir les 30 docs suivants/précédents (ou alors juste faire par paquets de 10 ?).
Un bouton de retour à la liste, situé entre les flèches, serait utile.
C’est surtout pour avoir un design commun entre desktop et mobile (surtout en portrait). Car sur mobile il n’y a pas la place pour mettre les 2 gros boutons de part et d’autre du titre.
De plus, pour naviguer facilement d’avant en arrière, il vaut mieux avoir les 2 flèches pas loin l’une de l’autre.
Le design exact des flèches est bien sûr à améliorer.
2 Likes
Perso, j’aime bien la solution de @Bubu. Après je comprend pas bien a quoi correspond l’encart « associated search » sur le design actuel ?
Ce sont les boutons « Filtrer » et « Voir tous les résultats » en bas des listes d’itinéraires et de sorties dans un WP ou un itinéraire.
Le but est que lorsqu’on clique sur une sortie dans la page d’un itinéraire ou d’un WP (ou n’importe quelle résultat de recherche), dans la page de la sortie il y a des flèches qui permettent de naviguer entre les sorties de cette liste.
Ca signifie que pour une même sortie, les flèches n’amènent pas aux mêmes sorties selon qu’on a cliqué sur la page de l’itinéraire, d’un WP, etc pour accéder à la première sortie affichée. Et c’est ce qu’on veut : éviter de revenir à la liste pour accéder à la sortie suivante.
C’était une fonctionnalité présente sur la V4 
Ok, c’est clair. (j’étais en train de me rendre compte du casse tête que pouvais représenter une sortie associée à plusieurs itinéraires !)
Du coup, je ne sais pas si la question porte également sur cet encart mais pour moi, ça surcharge. Peut être juste ajouter un retour à la recherche. Par exemple :
Il n’y a pas de modif de design des boutons pour accéder aux listes dans les itinéraires et WP. C’est juste pour naviguer entre les résultats une fois qu’on a cliqué sur un élément d’une liste.
Je comprend pas. A quelle page actuelle correspondrait le screenshot proposé en design actuel ? Pas à la page sortie à laquelle on aurait accédée via une recherche ?
Si, c’est le design de n’importe quelle sortie.
Sauf que le lien sur chacune des flèches ne serait pas le même selon qu’on vient de la home, d’une liste de sortie d’un WP, d’un itinéraire, de son profile, etc.
Mais il y aurait aussi ces flèches sur la page d’un itinéraire ou d’un WP, pour naviguer entre les résultats de recherche d’itinéraires ou de WP.
J’ai pas ça moi 
Voir la page de la sortie correspondante que j’ai posté plus haut.
Ce n’est pas en prod, on est justement en train de discuter du design à partir de maquettes.