Quelle est la meilleure approche pour l'en-tête / pied de page dans la conception de sites Web réactifs?
Je suis un IA faisant un site réactif, dans le cadre d'un site de commerce électronique à plus grande échelle. Nos pages sont les seules parties réactives de l'ensemble du site, donc 90% de notre site ne sera pas encore réactif. Une partie de ceci est un cas de test, l'autre partie est un travail préparatoire pour un effort beaucoup plus important.
Ma question concerne l'en-tête/pied de page.
Nous avons également un site optimisé pour les mobiles, réalisé par un fournisseur tiers. Étant donné que la grande majorité de nos liens en-tête/pied de page iront à des sites non réactifs et non optimisés pour les mobiles, est-il judicieux de filtrer ceux de notre site réactif pour une vue mobile?
Ce que j'ai fait jusqu'à présent est un IA/en-tête/pied de page qui ne comprend que des liens vers notre site mobile. De cette façon, l'utilisateur reste dans le contexte mobile et ne se retrouve pas renvoyé vers une page qui n'offre pas une bonne UX sur le mobile.
Est-ce la bonne façon de l'aborder?
Je ne sais pas si la bonne décision est d'inclure le même contenu exact d'en-tête/pied de page sur le mobile que nous avons pour le bureau/tablette.
J'ai lu des preuves des deux côtés:
NON, vous ne devez pas créer une navigation mobile distincte.
Les recherches de Sujan Shrestha (voir page 189) ont montré que le fait d'omettre une partie de la navigation sur le bureau sur mobile peut être désorientant pour les utilisateurs qui connaissent le site du bureau, ce qui réduit le temps d'exécution des tâches, vous avez donc raison y réfléchir à deux fois avant de changer la navigation pour mobile.
De plus, en masquant certaines pages du mobile, vous supposez implicitement un contexte mobile distinct. Environ 70% de l'accès aux appareils mobiles se produit dans un contexte stationnaire ( Heimonen trouvé 67% en 2009; Church & Oliver trouvé 71,4% en 2011, p. 71). Les personnes dans ces contextes stationnaires (et potentiellement même les utilisateurs mobiles dans des contextes mobiles) auront les mêmes besoins d'informations que les utilisateurs de bureau, donc masquer la partie pertinente de votre navigation, il leur sera difficile de trouver les informations qu'ils recherchent.
OUI, vous devez créer une navigation mobile distincte
Les auteurs de "Improving Web Search on Small Screen Devices" ont constaté que les utilisateurs d'appareils mobiles accédant à des sites de bureau échouaient souvent à effectuer des tâches sur des sites Web optimisés pour le bureau:
"La principale raison de l'échec, et les grandes échéances de tâches associées, étaient les grandes difficultés qu'ils avaient à naviguer sur le site sélectionné dans les résultats de la recherche. La plupart de leur temps et de leurs efforts gaspillés a été consacré à se perdre de plus en plus dans la petite fenêtre" (488 )
À moins que le contenu ne soit essentiel, en fournissant des liens vers celui-ci, vous ne ferez que frustrer vos utilisateurs car ils ont du mal à utiliser une interface surdimensionnée dans un écran sous-dimensionné. En supprimant cette partie de la navigation, vous améliorerez l'expérience pour tous les utilisateurs qui naviguent simplement et n'ont pas vraiment besoin d'effectuer des tâches sur ces pages.
Une mise en garde: certains autres chercheurs ont constaté que (au moins dans le contexte des applications mobiles) la navigation ne représentait que 10-12% de l'utilisation totale (p. 186), ce qui signifie que les utilisateurs seront souvent utiliser Internet dans un but précis. Même si ce but est simplement de trouver des informations ou de vérifier un statut, vous les empêcherez de le faire si vous masquez les pages sur mobile. Pour cette raison, si je devais choisir un côté personnellement, je choisirais de ne pas cacher les pages du bureau à la navigation mobile. Être frustré par un mauvais accès n'est pas aussi mauvais que d'être frustré de n'avoir aucun accès.
NI (l'idéal irréaliste)
Idéalement, la navigation pour les deux devrait finalement être la même parce que idéalement le contenu devrait être le même, les sites de bureau et mobiles tirant leur contenu de la même base de données, mais le formatant simplement différemment. Dans son livre Stratégie de contenu pour mobile, Karen McGrane montre comment la publication de contenu multiplateforme devrait fonctionner. Il semble que votre entreprise ait pour le moment bifurqué son contenu, donc ce n'est probablement pas une solution viable pour le moment, mais c'est quelque chose à garder à l'esprit pour l'avenir.
UN AVERTISSEMENT. Si vous choisissez de masquer les pages de la navigation ...
... alors considérons un écueil de navigation mobile sur lequel McGrane met en garde:
Les utilisateurs mobiles entrant sur votre site à partir de Google pourraient être redirigés vers la page d'accueil mobile si la page n'existe pas sur mobile, puis aller sur la version de bureau de la page d'accueil, puis effectuer une recherche laborieuse sur le bureau navigation interne de la version pour trouver la page qu'ils recherchent.
Si un utilisateur peut trouver une page sur Google, il devrait pouvoir y accéder sur mobile, même s'il ne s'agit que de la version bureau du site. Si vous décidez d'omettre le contenu de l'en-tête et du pied de page, assurez-vous de ne pas rediriger également les résultats de recherche de Google qui seraient allés vers ces pages.
Une dernière note ... McGrane recommande également de consulter les sites des concurrents pour vous aider à déterminer votre stratégie mobile:
comment gèrent-ils la navigation globale? Comprend-il les mêmes catégories principales que le site de bureau, ou juste un sous-ensemble? Les catégories de navigation sont-elles priorisées différemment pour les mobiles? Comment l'utilisateur accède-t-il à la navigation globale à partir de la page d'accueil et des autres pages du site?
... alors faire un audit concurrentiel pourrait vous aider à répondre à votre question.
Je pense qu'il y a au moins trois domaines à examiner:
UX - bien que les versions de bureau et mobiles soient différentes en raison des aspects UX et technologiques, celles-ci doivent rester similaires dans la mesure où elles n'entrent pas en conflit avec l'expérience utilisateur. Limiter l'accès à des fonctionnalités qui ne sont tout simplement pas accessibles sur mobile et donc dégrader gracieusement l'expérience est compréhensible et c'est en général une bonne direction. En ce qui concerne les liens de pied de page en particulier, je choisirais une solution intermédiaire: en appuyant sur le lien de pied de page hors site, vous pouvez afficher une alerte modale disant qu'il quitte maintenant le la version optimisée pour mobile et l'expérience supplémentaire peuvent être gravement affectées en raison de l'absence de convivialité mobile . De cette façon, vous pouvez conserver tous les liens et éviter la confusion, ce serait donc avoir le meilleur des deux mondes. Selon l'ampleur du manque d'ajustements mobiles, cela peut cependant être assez désagréable pour les utilisateurs, en particulier lorsqu'il est utilisé pour la navigation en-tête. Si tel est le cas, j'indiquerais en quelque sorte quels liens mènent à des sites adaptés aux mobiles et lesquels mènent uniquement à des versions de bureau (en regroupant et/ou une représentation graphique).
migration de liens - elle se situe entre la première et la seconde car elle touche à la fois à l'UX et au SEO. Ce sujet a été largement décrit par 3nafish dans sa réponse. En bref, il devrait y avoir une relation 1: 1 entre les liens mobiles et de bureau, donc si quelqu'un entre un lien de bureau depuis un mobile, il est redirigé vers le même contenu mais dans la version mobile du site (étant donné que vous avez un site mobile séparé, mise en page non réactive, où il est déjà traité) ET en même temps, suivre un lien mobile depuis le bureau devrait conduire au même contenu dans la version de bureau.
SEO - inclure/exclure des liens de la version mobile peut affecter le référencement, je pense que vous devriez également demander http://webmasters.stackexchange.com pour avis.
Le processus de navigation doit suivre les flux de tâches en fonction des besoins des utilisateurs dans un contexte spécifique. Développez vos flux de tâches en gardant à l'esprit le contexte et les besoins de l'utilisateur. S'il est testé pour être le même pour les utilisateurs de bureau et mobiles, respectez le modèle de navigation similaire, sinon, je vous suggère de changer, car les besoins et le contexte des utilisateurs de bureau et mobiles ont tendance à différer.