18073 sujets
QuentinC a écrit :
Pas très utile sinon dupliquer une fonction native du navigateur que tout le monde connaît
Ben, AMHA, ça se discute...
Personnellement, je suis très friand de l'icône "Précédent" dans les navigateurs, que j'utilise d'ailleurs "à donf", mais lorsque je tombe sur une page assez longue qui me propose un bouton "Retour", je suis plutôt content, un clic sur le bouton m'évite de devoir déplacer ma souris en haut à droite de mon navigateur...
C'est un "plus" appréciable dans ce cas, je ne vois pas pourquoi on ne devrait pas le proposer aux utilisateurs....
... surtout si le seul argument est "tout le monde connait" ! (parce que je suis à peu près sûr que "certains" n'ont pas l'habitude, comme nous, d'utiliser "Précédent" à tout bout de champ).
Bonjour,
Nous avons eu sur ce forum il y a quelques temps un échange assez "nourri" sur cette duplication des fonctionnalités natives
Disons pour résumer que le problème se pose toujours à deux niveaux :
- celui de la démarche globale, qui aboutit souvent à complexifier l'interface de la page. Exemple-type: les pages d'articles du Monde, déjà surchargées et assez imbittables, et dans laquelle la série de boutons dupliquants n'améliore pas les choses.
- celui de la fonctionnalité précise qui est dupliquée, avec des risques de non-fonctionnement (le lien haut de page du Monde, justement, dans Opera, le lien retour dans l'historique si javascript n'est pas activé...), de confusion ou d'accessibilité cognitive...
Un exemple pour l'accessibilité cognitive : Retour, c'est "retour à la page précédente" ou "retour en haut de page" ? Tous les utilisateurs n'auront pas la même réponse. Je viens justement de faire sauter ce retour généré par défaut par le CMS (joomla) choisi pour un projet de grand compte à cause de cela. J'ai, du coup, économisé du temps de développement pour valider cette fonctionnalité du CMS au regards des standards, la tester dans des cas de figures d'accessibilité, et l'intégrer dans la formation des rédacteurs et administrateur du projet à l'utilisation de leur outil... ce qui est un autre point à prendre en compte dans un contexte "professionnel" - pour faire court-
Face à cela, l'utilisateur a, dans son propre interface, de multiples moyens de gérer ces fonctionnalités et de les adapter à ses préférences ou à ses besoins. Par exemple, il est très facile dans Opera d'ajouter un bouton retour à la page précédente (ou retour en haut de page dans une barre d'outil placée en bas à droite de la fenêtre du navigateur...). Tous les navigateurs ne le permettent pas, mais il faut dire qu'il y a encore un très gros travail à mener de leur part sur les personnalisations d'interface.
Dupliquer localement une fonctionnalité peut être jouable ergonomiquement, à condition que ce soit bien géré côté accessibilité et ergonomie. Les fonctionnalités n'ont pas à cet égard le même statut :
- à un bout de l'échelle, le lien "haut de page" et celui du style switcher ne sont pas les plus problématiques.
- à l'autre bout, les liens d'agrandissement ne passent pas la barre, sauf si une contrainte propre au contenu bloque la fonctionnalité native et qu'il s'agit de faire de l'accessible en proposant un mécanisme alternatif : ils sont catastrophiques dans toutes les situations d'accès non javascript+css+visuel.
Où se situe ce lien retour de l'historique dans cette échelle ? Disons qu'il rentre déjà dans une catégorie "confort ultraluxe", sauf cas où le fonctionnement du site entrave l'historique du navigateur. Offrir ce type de béquille ergonomique peut être justifiable à court terme (faciliter la vie de l'utilisateur sur une gêne totalement mineure), mais s'avère franchement contre-productif à long terme (suppléer aux carences du développement des interfaces de navigateurs ne les encourage pas à prendre en compte la question).
En d'autres termes: il me paraît sage de réserver le lien "retour" aux cas où le site rend inutilisable l'historique native du navigateur. Et de laisser les utilisateurs avares de leurs mouvements de souris s'assumer ou changer de navigateurs
Modifié par Laurent Denis (19 Mar 2006 - 08:28)
Nous avons eu sur ce forum il y a quelques temps un échange assez "nourri" sur cette duplication des fonctionnalités natives
Disons pour résumer que le problème se pose toujours à deux niveaux :
- celui de la démarche globale, qui aboutit souvent à complexifier l'interface de la page. Exemple-type: les pages d'articles du Monde, déjà surchargées et assez imbittables, et dans laquelle la série de boutons dupliquants n'améliore pas les choses.
- celui de la fonctionnalité précise qui est dupliquée, avec des risques de non-fonctionnement (le lien haut de page du Monde, justement, dans Opera, le lien retour dans l'historique si javascript n'est pas activé...), de confusion ou d'accessibilité cognitive...
Un exemple pour l'accessibilité cognitive : Retour, c'est "retour à la page précédente" ou "retour en haut de page" ? Tous les utilisateurs n'auront pas la même réponse. Je viens justement de faire sauter ce retour généré par défaut par le CMS (joomla) choisi pour un projet de grand compte à cause de cela. J'ai, du coup, économisé du temps de développement pour valider cette fonctionnalité du CMS au regards des standards, la tester dans des cas de figures d'accessibilité, et l'intégrer dans la formation des rédacteurs et administrateur du projet à l'utilisation de leur outil... ce qui est un autre point à prendre en compte dans un contexte "professionnel" - pour faire court-
Face à cela, l'utilisateur a, dans son propre interface, de multiples moyens de gérer ces fonctionnalités et de les adapter à ses préférences ou à ses besoins. Par exemple, il est très facile dans Opera d'ajouter un bouton retour à la page précédente (ou retour en haut de page dans une barre d'outil placée en bas à droite de la fenêtre du navigateur...). Tous les navigateurs ne le permettent pas, mais il faut dire qu'il y a encore un très gros travail à mener de leur part sur les personnalisations d'interface.
Dupliquer localement une fonctionnalité peut être jouable ergonomiquement, à condition que ce soit bien géré côté accessibilité et ergonomie. Les fonctionnalités n'ont pas à cet égard le même statut :
- à un bout de l'échelle, le lien "haut de page" et celui du style switcher ne sont pas les plus problématiques.
- à l'autre bout, les liens d'agrandissement ne passent pas la barre, sauf si une contrainte propre au contenu bloque la fonctionnalité native et qu'il s'agit de faire de l'accessible en proposant un mécanisme alternatif : ils sont catastrophiques dans toutes les situations d'accès non javascript+css+visuel.
Où se situe ce lien retour de l'historique dans cette échelle ? Disons qu'il rentre déjà dans une catégorie "confort ultraluxe", sauf cas où le fonctionnement du site entrave l'historique du navigateur. Offrir ce type de béquille ergonomique peut être justifiable à court terme (faciliter la vie de l'utilisateur sur une gêne totalement mineure), mais s'avère franchement contre-productif à long terme (suppléer aux carences du développement des interfaces de navigateurs ne les encourage pas à prendre en compte la question).
En d'autres termes: il me paraît sage de réserver le lien "retour" aux cas où le site rend inutilisable l'historique native du navigateur. Et de laisser les utilisateurs avares de leurs mouvements de souris s'assumer ou changer de navigateurs
Modifié par Laurent Denis (19 Mar 2006 - 08:28)
Bonsoir Laurent,
Je m'apprêtais à te répondre que je n'étais pas d'accord/convaincu....
...et puis je relis ta réponse... (que tu as d'ailleurs enrichie par rapport à ce qu'il me semblait avoir lu ce matin )
...et maintenant, je suis converti !
Ce qui ne m'avait pas vraiment plu dans la discussion à laquelle tu fais référence, c'est que tu semblais de fonder uniquement sur un principe ("ne pas dupliquer les fonctionalités natives") pour "refuser" toute une série de choses (haut de page, rajouter aux favoris, retour, boutons d'aggrandissement, etc...) en bloc.
Là, sur le cas particulier du bouton "Retour", tu fournis d'une part un vrai argument
et surtout tu distingues les cas (le coup de l'échelle et "Les fonctionnalités n'ont pas à cet égard le même statut").
De plus, tu admets que dans certains cas, ça peut être utile
Mon site n'appartenant pas à cette catégorie , je vais donc suivre ton conseil et supprimer les quelques "Retours" que j'y avais mis (sauf dans ma page "Contact" où je désire faire un retour de 2 pages à la fois...)
(et je renverrai mes utilisateurs qui me demanderont où est le bouton retour à cette discussion...
)
Je m'apprêtais à te répondre que je n'étais pas d'accord/convaincu....
...et puis je relis ta réponse... (que tu as d'ailleurs enrichie par rapport à ce qu'il me semblait avoir lu ce matin
)...et maintenant, je suis converti !
Ce qui ne m'avait pas vraiment plu dans la discussion à laquelle tu fais référence, c'est que tu semblais de fonder uniquement sur un principe ("ne pas dupliquer les fonctionalités natives") pour "refuser" toute une série de choses (haut de page, rajouter aux favoris, retour, boutons d'aggrandissement, etc...) en bloc.
Là, sur le cas particulier du bouton "Retour", tu fournis d'une part un vrai argument
a écrit :
Retour, c'est "retour à la page précédente" ou "retour en haut de page" ?
et surtout tu distingues les cas (le coup de l'échelle et "Les fonctionnalités n'ont pas à cet égard le même statut").
De plus, tu admets que dans certains cas, ça peut être utile
a écrit :
réserver le lien "retour" aux cas où le site rend inutilisable l'historique native du navigateur.
Mon site n'appartenant pas à cette catégorie
, je vais donc suivre ton conseil et supprimer les quelques "Retours" que j'y avais mis (sauf dans ma page "Contact" où je désire faire un retour de 2 pages à la fois...)(et je renverrai mes utilisateurs qui me demanderont où est le bouton retour à cette discussion...
)