Pagination ou défilement infini des listes catégorisées
Nous avons un défi intéressant - nous avons une liste classée et nous devons limiter la quantité initiale d'entrées à charger.
Cela nous amène à la guerre Pagination vs Infinite Scroll, mais honnêtement, le problème est un peu plus élaboré. Normalement, j'ai une assez bonne idée du moment où utiliser l'un sur l'autre.
En mettant en œuvre soit au niveau de la page, vous pourriez charger plus facilement, mais la hauteur de la page augmente et vous perdez le contexte de l'endroit où vous êtes/étiez. Pas si idéal.
Bien sûr, la pagination pourrait fonctionner si nous implémentions par bloc de catégorie, mais elle a juste un flux horrible. Je préfère l'éviter si je le peux.
L'implémentation d'Infinite Scroll au niveau d'une catégorie vous empêchera de faire défiler facilement les entrées de votre liste en raison du temps de chargement, puis votre liste s'allongera soudainement, vous laissant ignorant où vous vous trouvez dans la liste.
Des pensées? J'ai du mal à trouver des exemples de cela dans la nature. Je pense que j'ai une idée, qui devrait ensuite être testée, mais s'il existe une solution commune, ce serait utile
Nous ne pouvons pas simplement filtrer par catégorie, car l'utilisateur peut avoir besoin du contexte de l'entrée de la catégorie 233e, mais il faut tout de même savoir que les entrées de la catégorie B
Voici une approche qui a bien fonctionné pour nous. Dans l'application, les utilisateurs finaux recherchent simultanément de nombreux types de données et les mots clés sont interrogés et affichés dans plusieurs catégories. L'écran de résultats principal limite les résultats dans chaque catégorie pour dépasser les 5 résultats ou n'importe quel nombre défini. Si le résultat n'est pas présent dans les premiers résultats, les utilisateurs ont la possibilité d'afficher les résultats complets dans les catégories principales ou d'affiner leurs mots clés de recherche. Les résultats complets sont ensuite sur un défilement infini avec un nombre X de résultats préchargés à mesure qu'ils défilent. Tout cela peut être fait sur des grilles afin que les modifications apportées aux données puissent être mises à jour en ligne ou via une sorte d'interface de sélection.
J'espère que ça aide.
Écran des résultats primaires
Écran des résultats détaillés des catégories
Le défilement infini a un défaut majeur: s'il est utilisé sur une page (de destination) qui devrait inspirer (par exemple, "y a-t-il un produit que vous aimez?") - donc pas au niveau d'une catégorie profonde, mais à un niveau faible - c'est une bonne chose . À ce stade, les utilisateurs veulent voir une variété, car ils n'ont peut-être pas encore décidé d'un itinéraire de plongée de catégorie. C'est pourquoi nous n'utilisons généralement PAS de défilement infini sur les pages qui sont en dessous du niveau 1.
Dans votre cas, cependant, le but des éléments répertoriés semble être de pouvoir saisir les informations contenues dans les éléments de la liste.
Je voudrais vous poser une ou deux questions à ce sujet: les utilisateurs veulent-ils COMPARER des articles? Si oui, le défilement infini pourrait être une bonne idée. (Je viens de lire que vous avez déjà répondu à cela)
Deuxième question: la liste d'articles est-elle filtrable? Cela rendra toute l'histoire plus facile.
Comme l'ont dit d'autres répondants, "savoir où cela se termine" permet aux utilisateurs de se sentir plus en contrôle, la vue d'ensemble est meilleure. Donc, au lieu de faire des efforts dans le défilement infini, j'opterais plutôt pour le filtrage (réduisant ainsi la liste), car il n'y a pas encore de partie "inspiration" dans votre concept.
Sans filtrage, vous pouvez utiliser "Accordéon" pour les catégories afin d'utiliser les données en défilement infini.
Vous avez toujours une référence à la catégorie avec globalement moins de surface pour faire défiler/déplacer.
sur notre site Web de commerce électronique, nous avons essayé les deux et nous avons réalisé que la pagination fonctionnait mieux pour notre groupe démographique particulier d'utilisateurs (c'est-à-dire le commerce électronique de mode en Asie). nous avons fait quelques observations sur la façon dont les utilisateurs naviguent sur les deux et sommes tombés sur les éléments suivants.
Les utilisateurs passeraient aux 3,5 pages plutôt que de passer à ..2,3,4 .. après ne pas avoir trouvé ce qu'ils cherchaient dans la 1ère page
Les utilisateurs n'étaient pas habitués au défilement infini, donc lorsqu'ils faisaient défiler très profondément et voulaient trouver quelque chose qu'ils avaient passé auparavant, ils ne pouvaient pas le trouver. par rapport à la pagination, ils se souvenaient à peu près de la page sur laquelle il se trouvait.
les utilisateurs ont parcouru les produits plus rapidement avec un défilement infini, car ils s'attendaient toujours à plus.
l'effet de défilement infini ne fonctionnait pas bien pour les catégories qui avaient quelques produits, ils n'étaient pas "infinis".
Sur quel type de site Internet travaillez-vous? une solution de commerce électronique ne fonctionnerait pas avec un défilement infini car il est difficile de mettre en signet/partager l'URL des "résultats" car techniquement, il n'y a qu'une seule page avec des CHARGES de morceaux de contenu.
Imaginez la conversation; "Ouais, regarde ces super chaussures, continue de défiler jusqu'à ce que tu vois le t-shirt jaune, puis descends deux autres parchemins." - Euh? Ceux-ci? Est-ce qu'elle veut dire ceux-là? - Pas une super expérience, car c'est ambitieux.
La pagination fonctionne beaucoup mieux pour les sites lorsque le contenu a une sorte de `` limite '' - dans le cas de Pinterest, le contenu est généré par l'utilisateur et à l'échelle infinie. Conçu pour montrer beaucoup et enregistrer beaucoup par les utilisateurs. Il s'agit plus d'une "vitrine" que d'un lieu pour obtenir des informations plus détaillées sur des produits spécifiques.
-
De quoi s'agit-il encore de la nature du site?
Nous ne pouvons pas simplement filtrer par catégorie, car l'utilisateur peut avoir besoin du contexte de l'entrée de la catégorie 233e, mais il faut tout de même savoir que les entrées de la catégorie B
Je pense que c'est l'élément clé de votre décision. Je pense que le défilement infini est utile lorsque le seul facteur de la façon dont l'utilisateur s'oriente est le temps - comme Twitter, ou un fil de blog, ou autre .
À partir de ce que vous décrivez, vos utilisateurs ont plutôt besoin de mieux comprendre où ils en sont dans leur tâche. David Keiras, de l'Université du Michigan, fait valoir que atteindre un point final améliore le sentiment de contrôle .
La question de votre réponse est déterminée par ce qui est le plus important pour le succès de votre site/application: le contrôle ou l'esthétique.
Je pense que l'expérience utilisateur globale de la pagination commence à être nulle quand il y a un nombre écrasant de pages ou d'options, mais cela a plus en commun avec trop d'éléments de menu que la pagination en particulier.
Quoi qu'il en soit, je suis totalement intéressé par ce que vous vous retrouvez. Certainement un problème unique.
Si vous avez un grand nombre d'éléments (20+), un accordéon n'est pas idéal pour la numérisation car, comme vous l'avez mentionné, il est très facile de perdre la trace des regroupements de catégories lorsque le groupe étendu dépasse la hauteur de l'écran.
Je recommanderais de supprimer votre catégorie d'accordéon et de placer les catégories à gauche comme navigation, puis de fournir un défilement infini par catégorie si l'utilisateur n'a pas besoin de référencer l'emplacement spécifique de l'élément sur la liste lors de ses prochaines visites. Si l'utilisateur doit faire référence à un élément plus bas dans la liste, la pagination doit être utilisée au lieu du défilement infini. Par exemple. J'ai besoin du 2e/3e élément de la page 2, est beaucoup plus facile à trouver, puis à faire défiler vers le bas pour trouver le 53e élément. Voir cette question pour plus d'informations sur la décision entre la pagination et le défilement infini.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
