Reaktives Webdesign: Das Geheimnis, um Web-Apps zu erstellen, die sich großartig anfühlen

Im letzten Jahr habe ich zwei subtile Techniken beobachtet, die von einigen Entwicklern verwendet werden, um eine Web-App von einem langsamen und ruckeligen Gefühl zu einem hochreaktiven und ausgefeilten Gefühl zu machen.

Ich glaube, diese Techniken sind so wichtig, dass sie einen Namen brauchen: Reactive Web Design.

Zusammenfassend lässt sich sagen, dass reaktives Webdesign eine Reihe von Techniken ist, mit denen Websites erstellt werden können, die sich unabhängig von der Netzwerkgeschwindigkeit oder der Latenzzeit immer schnell anfühlen und auf Benutzereingaben reagieren.

Als Webentwickler und Framework-Autoren glaube ich, dass es für die Verbesserung von UX und der wahrgenommenen Leistung im Web von höchster Priorität ist, Wege zu finden, wie diese Muster in allen von uns erstellten Standardmustern verwendet werden können.

Technik 1: Sofortladungen mit Skelettschirmen

Bei guter Anwendung wird diese Technik fast nie bemerkt, hat jedoch einen großen Einfluss auf die wahrgenommene Leistung einer Site.

Interessanterweise wird die Technik von fast allen nativen Apps verwendet, sodass sie sich auch in schrecklichen Netzwerken sehr reaktiv anfühlen. Sie wird jedoch fast nie im Web verwendet!

Gelegenheit liegt auf diesem Weg!

Kurz gesagt, Skeleton-Bildschirme stellen sicher, dass die Seite sofort reagiert, wenn der Benutzer auf eine Schaltfläche oder einen Link tippt, indem er den Benutzer auf diese neue Seite umstellt und dann den Inhalt auf diese Seite lädt, sobald der Inhalt verfügbar ist.

Facebook mit einem Skelettbildschirm, um die wahrgenommene Leistung beim ersten Öffnen zu verbessern

Skeleton-Bildschirme sind eine der wichtigsten wahrgenommenen Leistungstechniken, da sich Anwendungen dadurch viel schneller anfühlen und die Anzahl der Momente, in denen sich der Benutzer wundert, drastisch verringert wird:

Was ist los? Wird es überhaupt geladen? Habe ich richtig getippt?

Flipkart.com ist ein seltenes Beispiel für eine Website, die diesen Ansatz verwendet. Das Durchsuchen von Kategorien oder das Antippen von Produkten fühlt sich daher blitzschnell an, auch wenn das Laden der tatsächlichen Ergebnisse einige Sekunden dauert:

Eine Bildschirmaufnahme von flipkart.com, die im Standalone-Modus auf Android vom Startbildschirm aus gestartet wurde

Wenn diese Technik am besten angewendet wird, können bereits verfügbare Inhalte wie Miniaturansichten oder Artikeltitel wiederverwendet werden, um die wahrgenommene Leistung noch weiter zu verbessern, sodass sich die Ladevorgänge sofort anfühlen.

app.jalantikus.com verwendet das Skeleton Screens-Muster und verwendet Titel und Miniaturansichten über die Übergänge hinweg erneut

Teststellen mit Skelettschirmen

Das Testen, wie gut Websites diese Technik verwenden, ist einfach: Verwenden Sie die Chrome-Netzwerkemulation, um das Netzwerk so langsam wie möglich zu gestalten, und klicken Sie dann auf eine Website. Wenn dies gut gelingt, fühlt sich die Site immer noch bissig und reagiert auf Ihre Eingaben.

Die langsamste Geschwindigkeit, die in der Chrome-Netzwerkemulation unterstützt wird

Technik 2: „Stabile Lasten“ über vordefinierte Größen an Elementen

Sie kennen das Gefühl, dass eine Website herumspringt, während Sie versuchen, sie zu verwenden? Sie versuchen nur, einen Artikel zu lesen und der Text bewegt sich weiter? Das nennen wir eine "instabile Ladung" und wir müssen sie mit Feuer verbrennen.

Der Inhalt von slate.com springt beim Laden der Seite sehr aggressiv umher. Je langsamer das Netzwerk ist, desto länger dauert der Sprung.

Instabile Lasten erschweren die Interaktion mit Websites und sorgen dafür, dass sie sich… gut… instabil anfühlen!

Das Durchsuchen einer instabilen Site erinnert mich immer daran, wie ich mir vorstelle, dass es sich anfühlt, während eines Erdbebens herumzulaufen

Instabile Lasten werden durch Bilder und Anzeigen verursacht, die in eine Seite eingebettet sind, jedoch keine Größeninformationen enthalten. Standardmäßig kennt der Browser die Größe dieser Dateien erst, nachdem sie geladen wurden. Sobald ein Bild geladen wurde, wird THUNK !, die gesamte Seite nach unten verschoben .

Um dies zu verhindern, müssen alle -Tags auf einer Seite proaktiv die Abmessungen des Bildes enthalten, das sie enthalten.

In vielen Fällen haben Bilder, die auf bestimmten Seiten verwendet werden, immer dieselbe Größe und können daher einfach in die HTML-Vorlage aufgenommen werden. In einigen Fällen ist die Größe der Bilder jedoch dynamisch. Daher sollte ihre Größe berechnet werden, wenn das Bild hochgeladen und dann als Vorlage verwendet wird in das HTML, wenn es erstellt wird.


Gleiches gilt für Anzeigen, die häufig für instabile Lasten verantwortlich sind. Erstellen Sie nach Möglichkeit ein Div, das eine Anzeige enthält, und legen Sie in Ihren Vorlagen die Größe so fest, dass Sie genau wissen, wie groß diese Anzeige sein wird.

Beachten Sie, dass instabile Lasten in langsamen Netzwerken am schlimmsten sind, da Sie gerade damit begonnen haben, Inhalte zu lesen, wenn sie plötzlich springen, und Sie nie ganz sicher sein können, dass Sie in Sicherheit sind.

Alles zusammen

Ich habe eine kleine Demoseite unter reaction.surge.sh erstellt, um den Unterschied zwischen konventionellem und reaktivem Webdesign zu demonstrieren.

Konventionelles Laden von Artikeln

Beachten Sie, wie träge es sich anfühlt und wie frustrierend das Springen von Inhalten ist. Interessanterweise finde ich diese Größenordnungen auf Mobilgeräten ärgerlicher, wenn ich auf den Bildschirm tippe und nicht sehe, dass er reagiert.

Laden eines Artikels mit reaktivem Webdesign

Bei reaktivem Design fühlt sich die Ladung sofort an und die Site bleibt reaktiv, wenn Sie mehrmals auf das Zurück-Symbol und den Artikeltitel tippen

Einpacken

Je langsamer das Netzwerk ist, desto schlechter wird die Benutzererfahrung, wenn Seitenübergänge im Netzwerk blockiert werden und Seiten für längere Zeiträume herumspringen.

Mit Reactive Web Design können wir unsere Erfahrung selbst in langsamen und schmerzhaften Netzwerken bissig und reaktionsschnell machen („Responsive Design“, wie der Name schon sagte, d’oh!).

Ich würde gerne etwas über Daten aus der Community zu den Auswirkungen der wahrgenommenen Leistung auf KPIs wie Engagement und Umsatz erfahren!

Darüber hinaus möchte ich Autoren von Frameworks und Bibliotheken dazu ermutigen, sich zu überlegen, wie Skeleton-Screens und Stable-Loads zum Standard werden sollen, der auch als Erfolgsgrube bezeichnet wird.

Wenn Sie Gedanken dazu haben, twittern Sie mich bitte @owencm, und wenn Sie dies genossen haben, geben Sie es bitte ein ♥!

P.S. Schauen Sie sich unbedingt die Demoseite "reaction.surge.sh" auf einem mobilen Gerät an, um den vollen Glanz zu erhalten!