it-swarm.com.de

iPhone & Mobile Web: Paginierung vs. Mehr laden vs. Scrollen

Wir arbeiten an einer iPhone-App und einer mobilen Website mit Suchergebnissen aus dem Internet. Es stehen mehrere Sortieroptionen zur Verfügung, jedes Ergebnis hat ein Foto. Es gibt möglicherweise Hunderte von Ergebnissen.

Ich sehe 4 Muster, um durch die Liste zu navigieren:

  1. Laden Sie alles, verwenden Sie keine Paginierung, scrollen Sie einfach nach unten. Gedanken : Es müssen zu viele Daten geladen werden (schlecht für die Geschwindigkeit und den Datenplan des Benutzers).

  2. Laden Sie eine bestimmte Anzahl von Ergebnissen, z. B. 20, und verwenden Sie die klassische Paginierung (Schaltflächen "Nächste Seite" und "Vorherige Seite"). Gedanken: Con: Der Benutzer muss zurückklicken, anstatt nur nach oben zu scrollen, wenn er zur ersten Seite zurückkehren möchte. Pro: Jede Seite hat eine echte URL (SEO relevant). Meine bevorzugte Version für die mobile Weblösung.

  3. Laden Sie 20 Elemente und fügen Sie am Ende der Liste die Schaltfläche "20 weitere laden" ein (wird im App Store von Apple verwendet). Gedanken : Sehr elegant für Apps - aber warum sollten Sie es verwenden, wenn Sie die Ergebnisse automatisch laden können? (siehe 4)

  4. Laden Sie zu Beginn 20 Elemente und die nächsten 20, wenn der Benutzer das Ende der Liste erreicht hat. Gedanken : Mein Lieblingsmuster für die App könnte sogar für mobile Websites verwendet werden, wenn SEO richtig gehandhabt wird.

Fragen : Gibt es noch andere Dinge zu beachten? Stimmen Sie meinen Gedanken zu? Warum verwendet nicht jeder Muster 4? (nicht einmal Apple)

Verwandte Fragen:

11
Phil

Ansatz 4 ist besonders nützlich auf dem iPhone, wo Sie mit nur wenigen Fingerbewegungen durch eine Liste scrollen können. Das manuelle Klicken durch Ergebnisseiten unterbricht diesen Fluss. Ich würde es so machen - Apple ist nicht immer perfekt .;)

Bei der SEO-Optimierung können Sie Ihre separaten URLs weiterhin im Back-End behalten. Sie würden sie einfach automatisch anfordern, wenn die Ansicht gescrollt wird (z. B./results/1,/results/2 usw.).

Edit :diese fantastische, ältere Antwort scheint das Problem ausführlicher zu behandeln.

4
Phil Cohen

Es ist ein Gleichgewichtsproblem. Einige Gedanken:

  • Im Fall Nr. 1 haben Sie eine verzögerte Ladung im Voraus in Kauf genommen, um später ein reibungsloses Erlebnis zu erzielen. Abhängig vom Anwendungsfall Ihrer App kann dies bevorzugt sein (stellen Sie sich vor, Sie lesen Twitter und müssen jedes Mal, wenn Sie den 20. Tweet erreichen, auf eine Ladung warten).

  • In Fall 2 muss nicht jede Seite eine echte SEO-URL haben, da sich die Daten ändern können. Die meisten Designkonventionen für die paginierte Suche weisen Google an, Paginierungslinks nicht zu folgen, da die Indizierung einzelner Suchergebnisseiten für Suchende nicht sehr wertvoll ist. Wie ich bereits sagte, können sich die Daten ändern.

  • In Fall 3 funktioniert dies gut in Situationen wie Google Bilder, in denen Sie eine Menge im Voraus laden, aber nicht zu viele laden möchten, da der Anwendungsfall möglicherweise vorschreibt, dass 80% Ihrer Nutzer mit der ersten Seite zufrieden sind. Sie möchten jedoch, dass der Benutzer mehr anfordern kann, wenn er möchte, sodass Sie die Schaltfläche "Mehr laden" haben.

  • Und was # 4 betrifft, ist der Grund, warum Sie dies nicht öfter sehen, der, dass die meisten Apps mit # 1 in Ordnung sind. Das Laden neuer Elemente in jedem X-Ergebnis führt zu einer Stop-Start-Erfahrung, die häufig nicht bevorzugt wird, wenn Sie ein schnelles Scan-Szenario durchführen (und wenn dies nicht der Fall ist, ist diese Art von Liste möglicherweise nicht die richtige Steuerung für Sie ).

Wenn ich mit solchen Entscheidungen konfrontiert werde, neige ich dazu, einen Schritt zurückzutreten und das Design zu überdenken. Manchmal ist das nicht möglich - zum Beispiel ist Twitter, wie oben erwähnt, von Natur aus eine Liste, und Sie können seit Beginn der Zeit nicht alle Tweets laden, sodass der Benutzer hier und da mit dem Laden fertig werden muss . Aber zum Glück sind Tweets sehr leicht, so dass Sie einige davon laden können, bevor Sie schnipsen müssen. Für andere Daten, z. B. Suchergebnisse auf einer Reise-Website, auf der Sie Fotos für jedes Ergebnis haben, könnte ich einen anderen Designansatz in Betracht ziehen.

5
Rahul

Ein Hauptproblem bei 4 ist, wenn die Illusion, dass sie alle geladen wurden, zusammenbricht. Ein schneller Film und plötzlich müssen Sie einen Platzhalter für das noch nicht geladene Bild anzeigen.

Warum verwenden nicht alle Muster 4? Ich denke, das liegt daran, dass für die Benutzer, die eine Galerie mit gleich großen Platzhalterbildern vorantreiben, dies nicht möglich ist. Sie haben keine Ahnung, wo Sie sind. Kein Problem beim expliziten Laden von jeweils 20. Es verlangsamt Ihren Benutzer genug. Entwickler verwenden Muster 4 nicht, da es viel zu tun gibt, um die Einträge mit Platzhaltern auch ohne ihre Bilder gut aussehen zu lassen und auch navigierbar zu sein - und das ist schwer gut zu machen.

Ein Vorschlag, das für 4 zu lösen

Finden Sie einen Weg, um eine Annäherung Fast augenblicklich in die dominanten Farben der Bilder zu laden. Weit weniger Daten. Anschließend können Sie in der App benutzerdefinierte Platzhalter erstellen, indem Sie diese Farben mit Text verwenden, der die Bilder angibt. Dies ist navigierbar und bleibt es auch, wenn die Bilder eintreffen. Es wird weniger Sprungdiskontinuität in der visuellen Erscheinung geben, wenn sie dies tun.

1
James Crook