Würde "endloses Scrollen" mit bearbeitbaren Dingen funktionieren?

Question

Ich arbeite an dieser Anwendung, die wie ein Blog ist. Ich denke darüber nach etwas zu tun, wo der Benutzer durch alle seine Beiträge mit einer "endlosen Scroll" -Funktion wie Google Reader scrollen kann.

Hier ist das Problem, das ich bin Antizipation ... wenn der Benutzer klickt auf eine Post zu bearbeiten, das wird nehmen ihn/sie auf eine neue Seite. Schon bald werden sie zur Scroll-Ansicht zurückkehren wollen und wahrscheinlich an den gleichen Ort zurückkehren, an dem sie sich befanden, als sie auf "Bearbeiten" geklickt haben.

ich vorstellen, dass sie erschrocken würde, wenn sie nicht die gleiche Sammlung von Beiträgen sehen, der dort war, wenn sie angeklickt „bearbeiten“. Sie werden nicht zum Anfang des Scroll-while-progressive-load-posts Prozesses zurückkehren wollen und müssen es noch einmal machen.

Ich hatte die Gedanken an die IDs der akkumulierten Beiträge und die Bildlaufposition in der Sitzung zu speichern und alles zu rekonstruieren, wenn der Benutzer zurückgegeben. Aber was wäre, wenn sie durch Dutzende oder Hunderte von Posts gescrollt hätten, bevor sie auf "Bearbeiten" geklickt hätten? Das könnte zu viele Daten in einer angemessenen Zeit zu laden.

Dann gibt es die Idee, einen Dialog statt zu einer neuen Seite für die Bearbeitung verwendet wird, aber das bringt eine ganz andere Reihe von Problemen. Z. B., was passiert, wenn der Benutzer versucht, den Dialog in einem neuen Tab zu öffnen?

Vielleicht ist dies nicht eine großartige Kulisse für „Endlos-Scroll.“ Vielleicht ist das herkömmliche Paging ein weiter Weg.

Hat jemand so etwas implementiert? Irgendwelche Gedanken?

Answer 1

Vorsicht: I 'Endlos-Scroll' lästig finden. Es vermasselt den Scroll-Daumen als Positionsanzeige, mit überraschenden Änderungen und Pausen. Irgendwann wird es unhandlich - das "Hunderte von Postszenarien" -Szenario, das du erwähnst - es sei denn, es gibt noch mehr Komplexität (das Abwerfen von Gegenständen von der Spitze, wenn du tief liegst und zufälligen Zugriff bietet).

Aber überlegen, wie Google Reader, das Beispiel, das Sie zitieren, mit dem Problem beschäftigt: Sie selten von den Endlosscroll-Fenstern navigieren weg. Einige Operationen pro Element (Tagging) werden inline ausgeführt, die meisten Links werden jedoch in einem anderen Fenster geöffnet, um das Problem vollständig zu umgehen. Wenn Sie die Einstellungen ändern, kehren Sie zu "google reader" zurück. Ihre Scroll-Position kehrt an die Spitze zurück - vielleicht ist es also nicht so groß. (Obwohl vor allem: wenn Sie zurückkommen, das Ausmaß der Liste all zuvor geladene Gegenstände - nicht das Original just-Top-geladen Mehr dazu weiter unten.).

Ich würde nicht modal in - Place Editing - Das Bearbeitungsfeld wird im Scroll-Bereich über oder neben dem bearbeiteten Element eingefügt.

Oder, wenn das eine Schlüsselbit der Kontinuität ist, dass Sie Leute zurück senden möchten, um genau das gerade bearbeitete Element anzuzeigen, stellen Sie sicher, dass der Link "Zurück zur Liste" einen Zeiger auf die Stelle enthält, an der die Ansicht automatisch angezeigt werden soll. Roll-to (zum Beispiel im #Fragment-Anker).

Weiter, wenn entweder Ihr Code oder der Browser die Hunderte von vorherigen Elementen im Cache gespeichert haben (wie oben erwähnt, scheint Google Reader zu tun), sollte der Roll-Forward sofort erfolgen, ohne dass ein erneutes Laden erforderlich ist.

Answer 2

Ich habe etwas mit dynamischen Daten wie folgt getan. Ich gab ein Anchor-Tag aus, das die ID des Posts war und über POST oder GET weitergegeben wurde, oder innerhalb des Posts basierend auf dem, worauf der Benutzer klickte, so dass mein Code den Anker einfügte, wenn er erneut zur Seite navigierte.

so etwas wie:

header("location:http://www.myDomain.com/posts.php" . "#" . $post_id); 

Answer 3

Endlos-Scroll-UIs haben bekanntermaßen eine Lernkurve - abhängig von Ihrer Benutzerbasis können sie eher unbekanntes Gebiet sein und mehr verwirren als Hilfe. Dies wird sich wahrscheinlich in den kommenden Jahren oder Monaten ändern, also hängt alles davon ab ...

Wie immer im Zweifelsfall von Ihren Benutzern selbst herausfinden. Idealerweise sollten Sie eine Beobachtungsstudie durchführen, bei der Sie ähnliche Endlos-Scroll-UIs verwenden. Sind sie völlig verwirrt? Oder verstehen sie es schneller als herkömmliche Paginierung?

Denken Sie daran, dass Leute wie wir (die Twitter und Google Reader verwenden) der Zeit voraus sind und unsere Bedürfnisse, Ziele und Erwartungen sich wahrscheinlich von Ihren Zielnutzern unterscheiden.

Also, in aller Kürze sollten Sie wirklich beginnen, indem Sie herausfinden, ob eine endlose Scroll-UI geeignet ist. Es ist durchaus möglich, dass dies nicht der Fall ist.

Answer 4

Endlose/lange Scrolls sind schlechte Usability-Praxis. Selbst wenn es Ihnen gelingt, den Benutzer nach einer Bearbeitung auf den richtigen Post umzuleiten, haben sie möglicherweise während der Bearbeitung vergessen, wo sie sich befanden. Sie werden dann nach oben blättern, um zu bestätigen, auf welcher Seite sie sich befinden.

Vielleicht einfach halten Sie es einfach und begrenzen Sie die Beiträge pro Seite & bieten Paging-Funktionalität. Dies ist vertraute UI-Funktionalität für Benutzer & sie sollten nicht verloren gehen.

Oder geben Sie einfach die einzelnen Posts an, die auf einen Klick erweitert/verkleinert werden können, um den vollständigen Beitrag anzuzeigen bzw. zu verbergen. Dies ermöglicht viel mehr Beiträge pro Seite ohne übermäßiges Scrollen.