Avec le défilement infini, les barres de défilement ont-elles toujours un sens?
Je l'ai remarqué aujourd'hui sur Google Plus:
Barre de défilement virtuelle dans une galerie Google+
Il s'agit d'une barre de défilement virtuelle, par opposition à native barres de défilement que tout le monde sous Windows ou pré-Lion OS X connaît.
Maintenant, cela se trouve être une barre de défilement dans un contexte de défilement infini: c'est-à-dire que le document réel (la galerie) est beaucoup plus long, contenant environ 3000 images.
Pourtant, la barre de défilement agit comme une barre de défilement native: toute sa longueur représente le montant téléchargé pour le client, plutôt que la longueur du document réel, et le le défilement devient plus petit à mesure que plus de parties du document sont téléchargées, jusqu'à ce qu'il atteigne une taille minimale encore confortable à faire glisser avec un pointeur de souris.
Je suppose que je suis l'un des derniers gars ici à avoir dit "non merci" à Lion et peut-être que tout le monde est habitué à ces barres de défilement délicates qui apparaissent partout, des smartphones aux interfaces de bureau, alors je suis peut-être l'un des derniers utilisateurs de barres de défilement sur le monde entier.
Pourtant, cela m'amène à une question: les barres de défilement sont-elles encore utiles, en particulier avec un défilement infini/de grandes données?
Le concept original de la barre de défilement était simple: vous avez un document et vous n'en visualisez qu'une partie:
Avec les barres de défilement traditionnelles, le défilement indique la taille de la partie vue par rapport à l'ensemble ainsi que la distance que nous avons recherchée depuis le début
Mais avec l'avènement du défilement infini, nous avons ceci:
Dans les situations de défilement infini, la barre de défilement n'a pas de relation directe avec la taille du document
Donc, nous voyons la partie téléchargée du document. Bien que cela puisse être une limitation technique de barres de défilement natives, nous parlons d'une barre de défilement virtuelle ici: cela devait en fait être programmé à la main, et la plupart éventuellement conçu UX.
Historiquement, un traitement de texte (comme, excusez-moi, Word) n'a pas chargé tout le document: il a plutôt stocké la taille géométrique de tous les objets à charger, les a ajoutés, a créé une barre de défilement et n'a chargé que la partie qui était vu ou déjà vu. (*)
Donc ma principale question est: est-il nécessaire d'avoir une barre de défilement en 2012, si elle existe, à quoi devrait-elle ressembler (y compris les solutions de repli) et s'il n'y en a pas, que devrait-il arriver à la place? Pourquoi, pourquoi pas?
Notre contexte serait les sites de la communauté des consommateurs, donc, les galeries de photos et les fils d'actualité (tout ce que nous appelons le "Votre ami [~ # ~] xy [~ # ~] did quelque chose sur les pages de notre site), public cible 30 + -5, en possession d'un smartphone mais utilisant un ordinateur de bureau pour certaines tâches.
(*) (Pour l'historique technique à ce sujet, lisez Design Patterns dans le Gang of Four: c'est ce qu'on appelle le modèle "Proxy"
Mise à jour: pour être clair: je voudrais voir des explications, des modèles, des wireframes. "Ça dépend" n'est pas une réponse: bien sûr que ça dépend! Cela dépend de quoi, et "par exemple si X", que recommandez-vous, "mais si Y", que recommandez-vous, exemples, idées, maquettes.
Le défilement infini est abondant aujourd'hui, et les barres de défilement sont là avec nous depuis environ les années 80 (c'est peut-être un motif Xerox Star). Pourtant, je pense que leur combinaison actuelle n'a aucun sens, un non-sens. Étant donné que nous avons la puissance de calcul pour implémenter nos propres barres de défilement, à quoi devrait ressembler cette barre de défilement virtuelle pour un défilement infini? Pourquoi?
(Même avec 50 primes et 15 votes positifs, personne n'a d'alternative?)
Donc, quelques alternatives.
Émuler une "vraie" barre de défilement tout en conservant un défilement infini
L'approche orientée émulation restaure les barres de défilement habituelles tout en offrant un défilement infini. Ils sont utiles si le contenu a une fin raisonnable.
Une galerie d'images comme dans l'exemple ci-dessus est une telle chose, tandis qu'un contre-exemple serait la section "Vote" de 9gag - je suis sûr qu'elle n'a pas de fin définitive ...
Approche orientée lignes
Tout d'abord, la solution ci-dessus de G + est mauvaise. Vous pouvez facilement calculer la taille totale de la page à partir de métadonnées limitées. Vous avez besoin:
- la largeur et la hauteur de la fenêtre
- la hauteur d'une image (elle est constante)
- la largeur de toutes les images telles qu'elles apparaissent (une série de nombres, comme 480, 480, 640, 480 ...) dans le cas général, le nombre de lignes dans ce cas particulier (avez-vous remarqué que c'est justifié?)
- index de la ligne supérieure que vous voyez
Si vous connaissez la hauteur d'une rangée, rien de plus simple:
Fondamentalement, la "longueur physique" de votre barre de défilement est:
height of one image * number of rows
Mais son affichage est égal à la hauteur de la fenêtre. Par conséquent, une seule rangée d'images est représentée par:
single row = height of window / number of rows
Combien représente un parchemin? Cela dépend du nombre de lignes affichées.
nr of rows on the screen = height of window / height of one image
par conséquent, la taille de votre parchemin est:
scroll size = single row * nr of rows on the screen =
(height of window)^2 / (height of one image * number of rows)
et la taille de votre décalage pour le défilement est toujours:
scroll offset = (index of topmost row / nr of rows) * window height
C'est un peu de maths mais vous pouvez vivre avec
Chaque fois que l'utilisateur fait défiler vers le bas (en saisissant le défilement), vous pouvez calculer la ligne à commencer à charger, en appliquant ceci à l'inverse, donc:
index of topmost row to load = (scroll offset/ window height) * nr of rows
En utilisant ce calcul simple, vous pourriez agir comme un traitement de texte, ayant une barre de défilement complète à portée de main, le tour est joué.
Approche orientée page
Si vous ne connaissez pas vos lignes, il y a peut-être encore une astuce: vous pouvez toujours charger (à peu près) la même hauteur d'informations en une seule page. La page sur le Web est plus ou moins arbitraire, elle contient généralement 20 éléments, mais cela peut être compensé par un ou deux éléments sans que l'utilisateur ne le remarque.
Le calcul de base est le même (remplacez row par page), cependant, vous devez avoir une conception de page orientée grille, et certaines parties de l'application doit connaître cette grille. En outre, vous devez calculer vos propres caractères/ligne moyens, afin que le backend puisse les compter.
Le backend pourrait donc faire un tel calcul:
article size = headline (const.) + sum of margins (const.) +
height of text + sum height of images
height of text ~ length of text (in characters) / average characters in a line
Et vous sert, disons, 20 + -5 résultats basé sur ce qui serait plus proche de la taille idéale.
Bien sûr, chaque fois qu'un changement de disposition se produit, cette méthode se casse.
Barre de défilement de téléavertisseur
Si nous ne voulons pas calculer tout cela, nous pourrions tout de même avoir une barre de défilement "numérique": une telle barre de défilement est en fait un indicateur de page vertical. Il aide toujours les utilisateurs à s'orienter dans un contexte plus large (l'ensemble du document), mais il oublie la surface réelle de l'écran. Il se déplace "numériquement", c'est-à-dire que si vous le faites glisser, il "s'accroche" à la page suivante.
Il pourrait être implémenté latéralement avec un défilement "dans la page" à l'intérieur, de cette façon, l'utilisateur est capable de naviguer à la fois dans le contexte plus large de l'application complète et dans le contexte local de la page actuellement consultée.
Avec une solution scroll-within-scroll sur une barre de défilement pager, l'utilisateur est capable de naviguer rapidement à la fois dans le contexte plus large du site Web et dans le contexte local des pages chargées.
C'est en fait assez facile à implémenter: vous implémentez un pager normal, le visualisez un peu différemment, puis lorsque vous téléchargez une nouvelle page depuis le serveur, vous la chargez dans une seule div. jQuery est rapide pour vous dire la taille de votre div, donc:
size of outer scroll = height of window / nr of pages
offset of outer scroll = page number
size of inner scroll = height of window / height of current page
offset from top of webpage - (sum of height of loaded pages -1)
offset of inner scroll = _______________________________________________________________
height of current page
Indiquant visuellement à l'utilisateur qu'un défilement infini est en place
Parfois, les données sont tout simplement trop longues pour faire une barre de défilement significative, ou nous ne voulons tout simplement pas traiter de calculs réels. Pourtant, je suppose que nous devons donner une indice visuel que ce site a des pages ouvertes.
Un bon exemple est tumblr: alors qu'un seul utilisateur tumblr n'est pas assez rapide pour collecter une quantité infinie de données, les données sont suffisamment longues.
Veuillez comprendre que dans ce cas, il doit également y avoir un autre type de navigation: des solutions basées sur la chronologie (pages basées sur des jours ou plus) pourraient le faire.
Le modèle "ressort"
Le défilement infini a toujours une "zone sensible au défilement": lorsque la zone sensible au défilement devient visible (généralement s'il y a moins que la valeur d'un écran de données à afficher), l'application commence à charger la page suivante:
Maintenant, en fait, nous pourrions rendre cette zone visuelle. Les barres de défilement qui n'ont pas cette zone en bas sont des barres de défilement "normales", tandis que celles qui en ont sont des barres de défilement à défilement infini.
Une bonne métaphore serait le ressort: Imaginez qu'il y ait un ressort au fond, et votre molette est une sorte de force, comme la gravitation. Si vous poussez le ressort, il se comprime d'abord, mais ensuite il essaie de s'étendre: c'est ainsi que fonctionnent les lanceurs de flipper.
n ressort de lanceur de flipper pourrait être une bonne métaphore pour la zone sensible au défilement
Dans notre cas, la force est si grande qu'en réalité le parchemin devient plus petit après le saut: ce n'est pas tout à fait un phénomène inconnu: si vous éjectez depuis le cockpit d'un avion de chasse, vous raccourcissez de quelques centimètres. Notre printemps est vraiment fort :-)
Cette logique pourrait en fait fonctionner assez bien, mais elle doit être testée.
Défilement flou
Dans le cas où nous ne voulons pas d'animations élaborées dénotant une métaphore simple et simple, nous pourrions suivre la voie la plus simple: l'information que nous devons dire à l'utilisateur est que nous ne savons pas encore où elle se termine. Il y a un "brouillard", on ne voit pas la fin de la route.
ne sorte de "brouillard" cache la fin du document. On pourrait dénoter l'infini en utilisant un flou ou un dégradé
Des données vraiment infinies
Les données peuvent être "vraiment" infinies. J'utilise Facebook depuis environ 2007. Si je descendais mon fil d'actualité jusqu'en 2007 (je sais que c'est impossible, il s'arrête après environ 10 pages), ce serait énorme.
Ou allez à 9gag (ne le faites pas, si vous êtes au travail), et cliquez sur "tendance" ou "vote". Ces données sont "vraiment" infinies, dans le sens où elles traitent chaque jour des milliers d'images depuis 2005 environ.
De plus, pendant que je défile vers le bas, de nouvelles informations peuvent apparaître sur le "haut"! Les images 9gag sont publiées en continu, mais cela va également sur Facebook: pendant que je navigue vers le bas, de nouvelles nouvelles pourraient apparaître.
Dans ces cas les barres de défilement n'ont pas de sens: il n'y a tout simplement pas bien défini début des données, ni bien défini fin de celles-ci. Vous regardez un flux d'informations sans fin. bien qu'il puisse être important de revenir en arrière quelques éléments, puisque le flux lui-même est sans fin dans les deux sens, vous ne pouvez pas avoir une compréhension des progrès dans les informations.
En outre, le défilement infini nuirait à votre navigateur: les navigateurs ne sont pas conçus pour "oublier" les données que vous avez déjà téléchargées. Par conséquent, le navigateur commence à manger votre mémoire.
Il s'épuisera assez rapidement, donc le soi-disant échange doit être fait (écrire des parties de mémoire non utilisées sur le disque dur et prétendre qu'il fait partie de la mémoire), ce qui, dans le cas où vous n'avez pas de disque dur SSD, ralentit votre système - si vous avez un disque dur SSD, sa durée de vie est littéralement raccourcie de plusieurs années.
Qu'est-ce qui compte cette fois?
- le poste que je regarde
- la page où je me tiens
- Je me souviens peut-être des 40 à 50 derniers messages que j'ai vus aujourd'hui
- Combien de nouveaux éléments ont été publiés depuis que j'ai commencé à déplacer/la page où j'ai commencé.
- où je suis chronologiquement
- où je suis par rapport à l'endroit où j'ai commencé
- combien de pages/éléments ai-je parcouru.
En outre, ce qui compte, c'est linkability. C'est assez ennuyeux de ne pas pouvoir vraiment lier une page entière au milieu d'un défilement infini, non?
Par conséquent, la barre de défilement peut être remplacée par des indices.
Navigateur d'articles simple
Le cas le plus simple est que nous différencions les "pages" (pour une navigation rapide) et les "articles", et nous masquons la barre de défilement:
Chaque fois que l'utilisateur utilise le défilement, nous changeons la couleur du navigateur d'élément en une autre (ou la clignotons), indiquant que cela fonctionne.
On peut noter que ce n'est pas la fin du document en utilisant un "brouillard" (flou ou dégradé simple) en bas de page.
Défilement d'une page
En plus de cela, nous pourrions toujours avoir une barre de défilement pour la page actuellement consultée uniquement. Que se passe-t-il avec les pages précédentes? Nous les cacher. Ce n'est pas que nous les supprimions de la mémoire (c'est peut-être une solution également), mais nous pourrions toujours les afficher en fonction du décalage actuel: si le décalage atteint zéro, nous sommes à la fin de la page suivante.
Cette méthode est en fait modélisée d'après la façon dont OS X Preview gère les pages.
Nous aurons également besoin d'une zone tampon: pendant que nous affichons la fin de la page en cours, nous affichons déjà le début de la page en cours.
Quelle doit être la taille de ce tampon? Exactement une seule hauteur d'écran!
Nous chargeons du nouveau contenu dans cet espace limité, afin de pouvoir l'afficher. Chaque fois qu'il atteint le haut de l'écran, nous échangeons des pages.
(Voir en gros ici )
Dernières pensées
Ce sont quelques-unes des solutions que je pensais qu'elles pourraient être éligibles pour une réponse.
J'aurais accepté n'importe lequel de ceux-ci, et J'accepte toujours (dans les 23 prochaines heures) pour la prime toute réponse similaire à ceux-ci .
Alors que dollbaby avait raison que nous avons besoin de navigations supplémentaires chaque fois que nous parlons de défilement infini, je ne pense toujours pas qu'il soit éligible pour une prime, car en ce qui concerne la barre de défilement, elle a toujours recommandé de maintenir le statu quo.
Je pense que la créativité ne doit pas s'arrêter au maintien d'un statu quo. Comme Ford l'a dit un jour, "si je demandais ce que les gens veulent, ils auraient dit: des chevaux plus rapides"
Certaines de ces solutions sont assez mathématiques: je ne m'attends pas à ce que tout le monde les comprenne, et c'est sûr qu'elles sont difficiles à mettre en œuvre, mais j'espère qu'elles en valent la peine.
Quant à l'implémentation facile, fin floue est le plus simple.
Pourtant, aucun de ceux-ci n'est implémenté, ni testé par l'utilisateur . Je pense que la plupart d'entre eux dépendent également de vos besoins réels. J'ai essayé de fournir des contextes où ils pourraient être utiles. J'espère qu'un jour quelqu'un les mettra en œuvre, les testera et rendra compte des résultats.
Si ces exemples stimulent votre imagination, vous pourriez toujours être éligible à une prime. Donnez simplement un exemple qui ne se trouve pas ici.
Lorsqu'il existe une liste de contenu, les barres de défilement sont impératives. Les utilisateurs apprennent à comprendre le défilement jusqu'à la fin du contenu chargé, puis à pouvoir faire défiler davantage après le chargement de plus de contenu grâce à des plateformes telles que Twitter et Facebook. La barre de défilement n'est plus nécessairement un indicateur de la longueur des listes sur une application Web.
Les barres de défilement sont un élément reconnu qui permet aux utilisateurs d'afficher des listes étendues d'éléments. Pour les listes extrêmement volumineuses, il peut être difficile d'utiliser une barre de défilement seule, car essayer d'atteindre les éléments qui sont loin dans la liste nécessite beaucoup de défilement.
Pour les listes extrêmement volumineuses, un méta-défilement supplémentaire doit être fourni à l'utilisateur afin qu'il puisse accéder à une partie spécifique de la liste, puis utiliser le défilement pour afficher les éléments locaux jusqu'à ce point.
Un exemple où cela fonctionne est la chronologie de Facebook - Facebook a un défilement "infini", mais permet aux utilisateurs de passer à des périodes spécifiques.
Clarification en réponse à la question:
"est-il nécessaire d'avoir une barre de défilement en 2012, si elle existe, à quoi devrait-elle ressembler (y compris les solutions de repli) et si ce n'est pas le cas, que devrait-il arriver à la place? Pourquoi, pourquoi pas?"
Ma réponse est que oui, ils sont nécessaires. Ils ne doivent pas être modifiés car ils sont des fonctions reconnues. La modification des fonctions reconnues nuit à la convivialité. ci-dessous.
Les barres de défilement sont une méthode établie pour parcourir de grandes quantités de contenu. Les supprimer est irresponsable et téméraire. Le changer pour qu'il se comporte différemment ou soit trop différent pour que son méconnaissable soit également irresponsable et téméraire. La barre de défilement jscript de Google est OK car elle ressemble et se comporte de la même manière qu'une barre de défilement standard.
Un modèle a déjà été établi pour le défilement infini dans le contexte dont vous parlez (c'est-à-dire social) - les utilisateurs parcourent le bas du contenu chargé et attendent pour en charger plus. Les utilisateurs ont appris ce modèle et cela n'entrave pas la convivialité.
Cela fonctionne bien pour les besoins des utilisateurs car les utilisateurs ne veulent généralement voir que du contenu local et récent - ils ne recherchent pas quelque chose de spécifique. Ils ne se soucient pas non plus de voir les 3000 photos.
La seule exception est lorsqu'ils souhaitent afficher du contenu local spécifique à une certaine période du passé - ce qui rend le défilement infini difficile. C'est pourquoi un méta défilement est utile, comme la fonctionnalité de Facebook qui vous permet de passer à des périodes spécifiques dans la chronologie d'un utilisateur. ** Il s'agit simplement d'un ensemble de liens dans la zone de contenu qui permettent aux utilisateurs de "sauter" vers divers emplacements dans le grand ensemble de contenu.
Pour les scénarios où les utilisateurs pourraient vouloir trouver un contenu spécifique basé sur des métadonnées telles que la catégorie, la date, les balises, etc., vous pouvez fournir une option de filtre, une option de tri ou une option de recherche. L'utilisation de ces fonctionnalités dépend du contenu et des utilisateurs. Par exemple, vous pouvez l'instaurer pour flickr, mais pas pour g +. Les deux s'inscrivent dans le contexte de votre question.
Créer une nouvelle façon de parcourir ce contenu signifierait une nouvelle interface que les utilisateurs devraient apprendre à utiliser. Évitez cela à tout prix. Tirez parti des modèles mentaux existants pour créer des fonctionnalités intuitives, c'est-à-dire. utiliser une fonctionnalité établie.
Je pense que la barre de défilement standard satisfait la tâche utilisateur la plus courante, qui consiste à faire défiler le contenu qui a déjà été téléchargé.
Pour les cas où l'utilisateur peut souhaiter faire défiler la liste beaucoup plus bas ( dans le cas de Facebook, plus loin dans le temps), je pourrais envisager une barre de défilement qui fonctionne exactement comme la barre de défilement standard, sauf avec l'ajout de "bogues de plage" de début et de fin que vous pouvez déplacer de haut en bas pour indiquer le contenu que vous souhaitez parcourir.
La maquette ci-dessous montre un exemple pour une page qui affiche un contenu organisé sur une longue période de temps (encore une fois, comme avec Facebook). Cela pourrait également fonctionner avec du contenu organisé par nom, numéro ou autre catégorie utile.
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Un aspect important de cette conception devrait être de conserver l'aspect "téléchargement à la demande" de la page. Évidemment, si vous essayez de télécharger trois ans de contenu à la fois, l'utilisateur attendra longtemps. Par conséquent, la page doit être principalement vierge et le contenu ne doit être rempli que lorsque la partie de la page où ce contenu irait est révélée. Plus ce processus peut se produire rapidement, plus l'UX est transparent, mais cela dépend de la bande passante, des performances du serveur et des requêtes, de l'indexation de la base de données, etc.
Sausage.js fournit un modèle intéressant qui peut résoudre les problèmes d'utilisation du défilement infini par rapport à la barre de défilement. Similaire à votre exemple de "pager-scrollbar" - il crée une "saucisse" pour chaque section d'une page qui renvoie à cette section. La barre de défilement standard est toujours présente.
Pour une page à défilement infini, au lieu des saucisses représentant des sections de page, une saucisse pourrait être créée chaque fois qu'un nouveau lot de contenu est ajouté. permettre un accès rapide à toutes les sections de la "page" en constante évolution.
Vous devrez faire l'expérience de la démo pour voir les saucisses en tandem avec la barre de défilement.
Bien que cela ne réponde pas à la question "la barre de défilement at-elle encore un sens", elle fournit une alternative significative dans le contexte du défilement infini. La barre de défilement standard pourrait toujours fonctionner comme votre exemple de levier de flipper - nous sommes toujours dans le navigateur Web, donc je ne suis pas trop sûr qu'il serait sage de s'en débarrasser.
Je pense qu'il est logique que la barre de défilement soit affichée, car l'utilisateur peut voir où ils se trouvent entre le contenu qu'ils ont vu et le contenu téléchargé à la demande.
Même le contenu étant infini, la barre de défilement peut être utilisée pour que l'utilisateur navigue vers le haut ou le milieu, ou recherche également du contenu qu'il a vu.
Oui pour moi, la barre de défilement est toujours utile. Mais maintenant, la barre de défilement a besoin de plus de fonctionnalités: elle devrait avoir des indicateurs de marqueur. J'ai expliqué ma compréhension des barres de défilement avancées ici: https://ux.stackexchange.com/a/25127/17466