{"id":741,"date":"2025-07-23T10:00:00","date_gmt":"2025-07-23T10:00:00","guid":{"rendered":"https:\/\/erdbeerbeet.com\/?p=741"},"modified":"2025-07-23T07:13:08","modified_gmt":"2025-07-23T07:13:08","slug":"scrollen-oder-blattern","status":"publish","type":"post","link":"https:\/\/erdbeerbeet.com\/de\/scrollen-oder-blattern","title":{"rendered":"Scrollen oder Bl\u00e4ttern?"},"content":{"rendered":"<\/p>\n\n\n

Das Thema kam bei der Arbeit auf, und nachdem ich in einem Rabbithole deswegen versunken bin, m\u00f6chte ich meine Erkenntnisse einmal zusammenfassen. Wir k\u00f6nnen wohl kaum die einzigen sein, die sich die Frage gestellt haben, ob Inhalte besser gescrollt oder gebl\u00e4ttert werden sollen.<\/p>\n\n\n\n

Das Problem<\/strong><\/h2>\n\n\n\n

Es gibt einfach Inhalte im Web oder f\u00fcr Anwendungen, die sehr lang sind, bzw. mehr Platz ben\u00f6tigen. Hier stellt sich nun die Frage; macht man eine sehr lange Seite, oder lieber viele einzelne? Was ist f\u00fcr die Nutzenden angenehmer<\/strong>? Scrollen oder bl\u00e4ttern?<\/p>\n\n\n\n

Durch die verst\u00e4rkte Nutzung von Mobilger\u00e4ten kann man davon ausgehen, dass etwa die H\u00e4lfte der Nutzenden per Mobilger\u00e4t<\/strong> auf die Anwendung zugreifen. F\u00fcr Mobilger\u00e4te ist es grunds\u00e4tzlich angenehmer zu scrollen, als zu bl\u00e4ttern. Aber wir wollen eine L\u00f6sung f\u00fcr Desktop und Mobil.<\/p>\n\n\n\n

Im vorhandenen Fall ist es au\u00dferdem so, dass der Seitenwechsel eine Validierung<\/strong> des vorhandenen Formulars ausl\u00f6st. Es schwingt also auch die Frage mit, wie h\u00e4ufig Validiert werden soll und welche Auswirkungen das hat.<\/p>\n\n\n\n

Anwender<\/strong><\/h2>\n\n\n\n

Als erstes stellt sich die Frage, wer Anwender der Anwendung ist. Beziehungsweise, wird Inhalt konsumiert, oder muss wie in einem Formular Interaktion get\u00e4tigt werden und die Anwender m\u00fcssen liefern?<\/p>\n\n\n\n

Weiterhin ist die Frage, ob die Anwender die Anwendung als Werkzeug nutzen, dieses also kennen und m\u00f6glichst schnell und ohne zus\u00e4tzliche Klicks bedienen wollen. F\u00fcr In-House Software ist dies h\u00e4ufig der Fall.
Soll die Zielgruppe viel und h\u00e4ufig mit der Anwendung interagieren, dann bietet sich aus Effizienzgr\u00fcnden<\/strong> die Darstellung auf einer, bzw. m\u00f6glichst langen Seiten an.<\/p>\n\n\n\n

Content fatigue<\/strong><\/h2>\n\n\n\n

Zu viel Inhalt kann \u00fcberw\u00e4ltigend sein. Der Anblick eines riesigen Formulars wirkt abschreckend und zum Beispiel nachladende Produkte in einem Webshop wie beim infinite scrolling<\/strong> sorgen daf\u00fcr, dass Nutzende den \u00dcberblick verlieren.<\/p>\n\n\n\n

Infinite Scrolling hat seine Berechtigung, wenn konsumierbarende Inhalte<\/strong> unbemerkt nachgeladen werden, um das Nutzererlebnis zu verbessern und Besuchende m\u00f6glichst lange auf der Seite zu halten.
F\u00fcr ein Formular kommt dies allerdings \u00fcberhaupt nicht infrage, da die \u00dcbersicht verloren geht, wie gro\u00df dieses Formular \u00fcberhaupt ist.<\/p>\n\n\n\n

Bei Artikeln<\/strong> oder Geschichten sind l\u00e4ngere Seiten von Vorteil, da die Inhalte “am St\u00fcck” konsumiert werden k\u00f6nnen. Das Bl\u00e4ttern auf die n\u00e4chste Seite springt so logisch unterteilt zum n\u00e4chsten Abschnitt.<\/p>\n\n\n\n

Abschnitte<\/strong><\/h2>\n\n\n\n

G\u00e4nzlich unabh\u00e4ngig von der Seitenaufteilung findet sich \u00fcberall die klare Empfehlung – wenn nicht sogar Regel – Inhalte logisch zu gruppieren<\/strong>. Entweder wie eben erw\u00e4hnt in Kapitel oder zusammenh\u00e4ngende Links und Bilder.<\/p>\n\n\n\n

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

Bonuspunkte wenn hier programmatisch fieldsets<\/strong> genutzt werden oder sogar Zwischen\u00fcberschriften<\/strong> verwendet werden, um zus\u00e4tzlichen Kontext zu bieten.
Im Umkehrschluss sollten verwandte Eingabefelder nicht auf verschiedene Seiten verteilt sein.<\/p>\n\n\n\n

Validierung<\/strong><\/h2>\n\n\n\n

Feld-Validierung sollte stets direkt nach der Eingabe<\/strong> der Nutzenden ausgel\u00f6st werden. Es gibt aber auch solche, die einen anderen Trigger brauchen, wie der Versuch auf die n\u00e4chste Seite zu Navigieren oder das Absenden des Formulars. Zum Beispiel fehlende Felder werden bei dieser Aktion erst angemerkt.<\/p>\n\n\n\n

Besonders bei fehlenden Felder ist es gute Praxis, die Seite zum fehlerhaften Feld zu scrollen, um die Korrektur m\u00f6glichst einfach<\/strong> zu machen. Hier ist nun klar ersichtlich, dass eine lange Seite dazu f\u00fchrt, dass \u00fcber die gesamte Seite zur\u00fcck gescrollt werden muss, um weiter zu kommen.
Oder falls kein automatisches Scrollen stattfindet, muss die gesamte Seite nach dem fehlerhaften Feld durchsucht<\/strong> werden.<\/p>\n\n\n\n

Fortschritt<\/strong><\/h2>\n\n\n\n

Sowohl auf langen, als auch bei vielen Seiten m\u00fcssen Nutzende ein Gef\u00fchl daf\u00fcr haben, was sie erwartet. Also wie lang die Seite ist und wieviele Seiten oder Abschnitte zu erwarten sind.<\/p>\n\n\n\n

Eine M\u00f6glichkeit zur Forschrittsanzeige bei mehreren Seiten ist eine Progressbar<\/strong> und\/oder die Ausgabe eines Textes wie “Seite 2\/5”.<\/p>\n\n\n\n

F\u00fcr lange Seiten empfehlen sich Sprungmarken<\/strong> und ggf. ein verlinktes Inhaltsverzeichnis<\/strong>.<\/p>\n\n\n\n

In beiden F\u00e4llen sollte vorher ersichtlich sein, welchen Umfang<\/strong> der Inhalt hat, am besten noch, wie viel Zeit<\/strong> das Lesen oder die Bearbeitung in Anspruch nehmen wird.<\/p>\n\n\n\n

Fazit<\/strong><\/h2>\n\n\n\n

Die uneindeutige Antwort, ob lange Seiten oder viele Seiten besser sind ist “es kommt darauf an”. Nicht immer hat man die M\u00f6glichkeiten, beide Varianten mit einem AB-Test auszuprobieren (ich w\u00e4re aber an entsprechenden Ergebnissen interessiert, wenn die jemand hat).<\/p>\n\n\n\n