-
Notifications
You must be signed in to change notification settings - Fork 14
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
Customisation des informations affichées sur les cards en vue liste #987
Comments
En effet, lors du maquettage de GTR3, nous avions identifié et validé avec les utilisateurs les infos essentiels et génériques à afficher dès la liste de résultats, et toutes les autres uniquement dans la fiche détail. On pourrait imaginer en effet que l'on puisse remplacer ou ajouter des éléments avec de la configuration. Pour ma part, je ne suis pas convaincu par le fait d'ajouter d'office et pour tous le type de parcours, car nous avions retenu que cela était une info secondaire. |
Serait-ce risqué d'imaginer une logique métier selon la différence de dénivelé ? Par exemple en mettant une valeur de bascule à 20m :
Cette valeur de bascule pourrait être paramétrable |
Moi je préfère un affichage dans la liste simple et cohérent pour tous les objets, mais pourquoi pas permettre un affichage des infos de la fiche plus souple et configurable, voire adaptable en fonction de l'objet. |
On pourrait imaginer un fonctionnement de ce type :
|
Pour permettre de personnaliser les affichages des résultats dans la vue liste, il faudrait mettre en place un mécanisme qui permette à l'utilisateur de sélectionner certains champs à afficher et leur ordre (un peu comme la configuration des fiches détails mais pour les tuiles de résultats).
Certaines données restent obligatoires :
|
En plus, il faudrait pouvoir afficher certaines étiquettes (comment gérer côté GTA ? Côté GTR ?). Plus complexe, à prendre indépendamment. |
Plus techniquement il faudrait donc créer un fichier {
"themes": {
"display": true,
"order": 0,
},
"difficulty": {
"display": true,
"order": 10,
},
"duration": {
"display": true,
"order": 20,
},
"distance": {
"display": true,
"order": 30,
},
"elevation": {
"display": true,
"order": 40,
},
"negativeElevation": {
"display": false,
"order": 50,
},
"courseType": {
"display": true,
"order": 60,
},
"networks": {
"display": true,
"order": 70,
},
"place": {
"display": true
}
} Dont il serait possible de surcharger via |
Oui c'est ça.
Et pour les étiquettes, cela pourrait être un fonctionnement similaire, mais avec une option supplémentaire et optionnelle pour pouvoir définir uniquement l'affichage des pictos de certaines étiquettes uniquement :
|
Après reflexions et en reprenant les propositions :
Par conséquent avec la fonctionnalité des {
"trek": {
"location": {
"display": true,
},
"themes": {
"display": true
},
"labels": {
"display": true,
"includes": [1,3]
}
"informations": ["difficulty", "duration", "distance", "positiveElevation", "negativeElevation", "courseType", "networks"]
}
} Valeur par défaut de {
"trek": {
"location": {
"display": true,
},
"themes": {
"display": true
},
"labels": {
"display": true,
}
"informations": ["difficulty", "duration", "distance", "positiveElevation"]
}
} |
OK ça me semble très bien. |
Contexte
En vue liste dans GTR3, les informations affichées pour les itinéraires sont toujours les mêmes :
Pour les derniers éléments, affichés en une ligne, les informations ne sont pas toujours pertinentes.
Pour rappel, sur Geotrek-Widget, le choix a été effectué d'ajouter en plus le type de parcours sur la tuile, et d'identifier plus clairement la pratique plutôt que via un picto à survoler sur l'image.
Proposition
Il faudrait pouvoir paramétrer le contenu des ces cards, pour permettre d'afficher d'autres types de contenus car selon les territoires les besoins ne sont pas toujours les mêmes.
A minima, si on ne paramètre pas les contenus car trop compliqué, je pense qu'il faut discuter de la pertinence de mettre en avant le type de parcours et le dénivelé négatif.
Toutefois dans beaucoup de situations, le dénivelé négatif = dénivelé positif, donc pas forcément idéal non plus.
The text was updated successfully, but these errors were encountered: