Scrollen oder Blättern?

Das Thema kam bei der Arbeit auf, und nachdem ich in einem Rabbithole deswegen versunken bin, möchte ich meine Erkenntnisse einmal zusammenfassen. Wir können wohl kaum die einzigen sein, die sich die Frage gestellt haben, ob Inhalte besser gescrollt oder geblättert werden sollen.

Das Problem

Es gibt einfach Inhalte im Web oder für Anwendungen, die sehr lang sind, bzw. mehr Platz benötigen. Hier stellt sich nun die Frage; macht man eine sehr lange Seite, oder lieber viele einzelne? Was ist für die Nutzenden angenehmer? Scrollen oder blättern?

Durch die verstärkte Nutzung von Mobilgeräten kann man davon ausgehen, dass etwa die Hälfte der Nutzenden per Mobilgerät auf die Anwendung zugreifen. Für Mobilgeräte ist es grundsätzlich angenehmer zu scrollen, als zu blättern. Aber wir wollen eine Lösung für Desktop und Mobil.

Im vorhandenen Fall ist es außerdem so, dass der Seitenwechsel eine Validierung des vorhandenen Formulars auslöst. Es schwingt also auch die Frage mit, wie häufig Validiert werden soll und welche Auswirkungen das hat.

Anwender

Als erstes stellt sich die Frage, wer Anwender der Anwendung ist. Beziehungsweise, wird Inhalt konsumiert, oder muss wie in einem Formular Interaktion getätigt werden und die Anwender müssen liefern?

Weiterhin ist die Frage, ob die Anwender die Anwendung als Werkzeug nutzen, dieses also kennen und möglichst schnell und ohne zusätzliche Klicks bedienen wollen. Für In-House Software ist dies häufig der Fall.
Soll die Zielgruppe viel und häufig mit der Anwendung interagieren, dann bietet sich aus Effizienzgründen die Darstellung auf einer, bzw. möglichst langen Seiten an.

Content fatigue

Zu viel Inhalt kann überwältigend sein. Der Anblick eines riesigen Formulars wirkt abschreckend und zum Beispiel nachladende Produkte in einem Webshop wie beim infinite scrolling sorgen dafür, dass Nutzende den Überblick verlieren.

Infinite Scrolling hat seine Berechtigung, wenn konsumierbarende Inhalte unbemerkt nachgeladen werden, um das Nutzererlebnis zu verbessern und Besuchende möglichst lange auf der Seite zu halten.
Für ein Formular kommt dies allerdings überhaupt nicht infrage, da die Übersicht verloren geht, wie groß dieses Formular überhaupt ist.

Bei Artikeln oder Geschichten sind längere Seiten von Vorteil, da die Inhalte „am Stück“ konsumiert werden können. Das Blättern auf die nächste Seite springt so logisch unterteilt zum nächsten Abschnitt.

Abschnitte

Gänzlich unabhängig von der Seitenaufteilung findet sich überall die klare Empfehlung – wenn nicht sogar Regel – Inhalte logisch zu gruppieren. Entweder wie eben erwähnt in Kapitel oder zusammenhängende Links und Bilder.

Formulare lassen sich in der Regel ebenso gruppieren. So sollten Personendaten, Adressen, Bankverbindung, Informationen zum Buch oder worum auch immer es geht gruppiert sein.

Bonuspunkte wenn hier programmatisch fieldsets genutzt werden oder sogar Zwischenüberschriften verwendet werden, um zusätzlichen Kontext zu bieten.
Im Umkehrschluss sollten verwandte Eingabefelder nicht auf verschiedene Seiten verteilt sein.

Validierung

Feld-Validierung sollte stets direkt nach der Eingabe der Nutzenden ausgelöst werden. Es gibt aber auch solche, die einen anderen Trigger brauchen, wie der Versuch auf die nächste Seite zu Navigieren oder das Absenden des Formulars. Zum Beispiel fehlende Felder werden bei dieser Aktion erst angemerkt.

Besonders bei fehlenden Felder ist es gute Praxis, die Seite zum fehlerhaften Feld zu scrollen, um die Korrektur möglichst einfach zu machen. Hier ist nun klar ersichtlich, dass eine lange Seite dazu führt, dass über die gesamte Seite zurück gescrollt werden muss, um weiter zu kommen.
Oder falls kein automatisches Scrollen stattfindet, muss die gesamte Seite nach dem fehlerhaften Feld durchsucht werden.

Fortschritt

Sowohl auf langen, als auch bei vielen Seiten müssen Nutzende ein Gefühl dafür haben, was sie erwartet. Also wie lang die Seite ist und wieviele Seiten oder Abschnitte zu erwarten sind.

Eine Möglichkeit zur Forschrittsanzeige bei mehreren Seiten ist eine Progressbar und/oder die Ausgabe eines Textes wie „Seite 2/5“.

Für lange Seiten empfehlen sich Sprungmarken und ggf. ein verlinktes Inhaltsverzeichnis.

In beiden Fällen sollte vorher ersichtlich sein, welchen Umfang der Inhalt hat, am besten noch, wie viel Zeit das Lesen oder die Bearbeitung in Anspruch nehmen wird.

Fazit

Die uneindeutige Antwort, ob lange Seiten oder viele Seiten besser sind ist „es kommt darauf an“. Nicht immer hat man die Möglichkeiten, beide Varianten mit einem AB-Test auszuprobieren (ich wäre aber an entsprechenden Ergebnissen interessiert, wenn die jemand hat).

• Zu konsumierende Inhalte besser auf wenigen, langen Seiten darstellen.
• Formulare zu sinnvollen Blöcken zusammenfassen und diese sinnhaft auf einzelne Seiten verteilen.
• Nutzenden ein Anhaltspunkt für den Fortschritt vermitteln.

Für mein „Arbeits-Problem“ werden wir eine Lösung in der Mitte finden, mit halblangen Seiten, die aber jeweils Dateneingaben zu einem Thema enthalten.

Quellen

Ich habe vor allem die folgenden zwei Artikel in meine Erkenntnisse einfließen lassen:

• Infinite Scroll vs. Pagination (englisch, designerly)
• Pagination in Web Forms (englisch, uxmatters)