web-dev-qa-db-fra.com

Les utilisateurs doivent-ils être dirigés vers une page 404 ou une page de destination?

Nous avons deux pages. L'une est une page de destination, donnée par l'itinéraire /region. L'autre est une page de détail pour une région particulière, donnée par l'itinéraire /region/summary/{id}. La page de destination est le moyen normal par lequel un utilisateur accède à une page de détails.

Supposons qu'un utilisateur visite l'itinéraire intermédiaire region/summary. Doit-il être redirigé vers une page 404, car techniquement ce n'est pas un itinéraire valide, ou redirigé vers la page region, car le problème principal est qu'il n'a pas fourni d'identifiant dans l'itinéraire, et il trouver des liens valides partout sur la page de destination?

website-designusabilityuser-behaviorlanding-pageerrors
20
Peter Majeed

C'était à l'origine un commentaire, car j'avais supposé qu'il avait été pris en compte et non utilisé avant la publication de cette question.

Pour le moment, ce sont vos URL (avec "résumé" étant un type d'action, probablement):

/region
/region/{action}/{id}

Votre question est, que devez-vous faire si quelqu'un essaie d'y accéder sans ID, comme ceci:

/region/{action}

Je dis: ne le permettez pas en premier lieu, et façonnez vos URL conceptuellement comme ceci:

/region
/region/{action}
/{region}
/{region}/{action}

Donc, avec ce mappage: {region} -> region/{id}, vous obtenez les URL:

/region
/region/{action}
/region/{id}
/region/{id}/{action}
  • /region irait toujours au même endroit que vous avez l'intention; une page de destination.
  • /region/{id}/summary fait la même chose que votre /region/summary/{id}
  • /region/{id} signifierait essentiellement "Obtenez-moi des informations sur la région {ID}", qui pourrait être de 302 à /region/{id}/summary, ou renvoyez simplement cette page.
  • De même pour /region/summary - l'utilisateur demande des informations sur la page de destination. Il devrait renvoyer la même chose que /region (ou 302, ou /region devrait 302 ici).

RL RESTful comme ceci sont utilisés dans les API Web, et ils sont assez intuitifs, ce qui en fait un bon modèle pour les sites qui peuvent les utiliser.

Deux autres ensembles d'exemples de StackExchange API (qui, accordé, n'inclut pas /tags/{tags}):

/badges                   Get all badges on the site, in alphabetical order.
/badges/{ids}             Get the badges identified by ids.
/badges/recipients        Get badges recently awarded on the site.
/badges/{ids}/recipients  Get the recent recipients of the given badges. 

/tags                   Get the tags on the site.
/tags/{tags}/info       Get tags on the site by their names.
/tags/synonyms          Get all the tag synonyms on the site.
/tags/{tags}/synonyms   Get the synonyms for a specific set of tags.

Et une de cette page Modifier la réponse (qui, malheureusement, ne fonctionne pas sans /edit...):

http://ux.stackexchange.com/posts/39273/edit
12
Izkata

Je pense qu'il est correct de deviner où vos utilisateurs essayaient d'aller, mais fournissez toujours le bon code de réponse HTTP pour indiquer que l'élément n'a pas été trouvé ou a été "déplacé de manière permanente" et envisagez de montrer un simple message sur la page au cas où l'utilisateur tenterait vraiment d'aller quelque part qu'il pensait être légitime et ne comprend pas pourquoi vous l'avez redirigé.

8
sirtimbly

Je dirais que si vous avez la possibilité de revenir à une page qui peut être utile, vous devriez le faire plutôt que de donner une erreur 404.

Dans votre exemple, revenir à /region quand quelqu'un entre /region/summary donne à l'utilisateur la possibilité de sélectionner ce qu'il recherche. Cela interrompt leur flux beaucoup moins qu'il ne l'aurait fait si vous leur avez donné une page d'erreur 404 et leur présente un meilleur UX.

Lorsque vous travaillez avec des personnes, vous devez tenir compte de l'intention de l'utilisateur et être aussi flexible que possible. Avec les machines, il s'agit plus d'être précis, et c'est là que vous devez donner une erreur au lieu de revenir aux informations les plus proches dont vous disposez.

En revanche, s'ils ont donné un {id} erroné, vous devriez revenir à une page d'erreur 404 avec les informations les plus utiles que vous puissiez offrir.

3
JohnGB

404 Les erreurs peuvent être très utiles.

Tout le monde veut que leurs sites soient intuitifs et chaque utilisateur s'efforce de faire moins de travail. Cela étant dit, les erreurs 404 dans vos statistiques et journaux peuvent vous aider à déterminer où résident les lacunes de votre interface utilisateur. Si l'interface utilisateur est si mauvaise du point de vue de l'expérience utilisateur que les utilisateurs essaient de "sauter" en utilisant l'interface, alors il y a un besoin de révision. Google et les moteurs de recherche ne devraient généralement pas atteindre une erreur 404 sur votre site, car ils ne suivent que des liens durs. Dans le backend des outils pour les webmasters de Google, ils fournissent des informations sur la découverte ou non d'un lien incorrect ou mort sur votre site Web et vous pouvez rechercher dans Google pour déterminer d'où il provient.

Si vous donnez aveuglément à quelqu'un une redirection 301 [permanente] qui lui présente des informations erronées, vous risquez de chasser les visiteurs du site. Si vous redirigez tout le trafic vers la page de destination dans le cas où ils auraient tenté d'accéder à une page qui n'existait pas, ils n'ont aucun moyen de savoir si c'était leur propre erreur, si la page n'existe plus, ou pire si le site est cassé.

J'ai trouvé utile d'analyser la demande pour montrer les liens probables que le visiteur souhaitait. Ceux-ci sont présentés dans une liste sous la forme d'une redirection 300 indiquant qu'une autre action est nécessaire car plusieurs actions peuvent potentiellement être prises. S'il n'y a aucun enregistrement même à distance sur le sujet de la demande, je fournis une erreur 404 car je ne veux pas que les moteurs de recherche ou les visiteurs relient mon site à la requête, aux mots clés ou au contexte qui ont échoué. Cela peut aider à maintenir le trafic sur le site et à informer les moteurs de recherche qu'il existe des éléments connexes dans votre site.

2
AbsoluteƵERØ