Daniel Hundt - Erfahrung Technologien im Frontend

zurück zur Technologie-Übersicht

Warum es manchmal besser ist, länger zu warten

Inhalt

Zur Reaktionszeit von Benutzeroberflächen haben sich im Laufe der Zeit folgende Grundsätze heraus gebildet:

  • Bei einer Interaktion (z.B. click) wird innerhalb sehr kurzer Zeit (bis ca. 300ms) eine Reaktion erwartet, andernfalls wird der Nutzer verwirrt ("Kann ich nicht mit dem Element interagieren? War meine Interaktion erfolgreich? Hängt das Programm?")
  • Beim Wechsel der Darstellung bzw. von Inhalt benötigt der Nutzer eine gewisse Zeit (ab ca. 1s) um diese zu erfassen, andernfalls wird der Nutzer verwirrt ("Was hat sich da gerade geändert? Warum hat das geflackert? Habe ich etwas falsch gemacht? Ist das Programm kaputt?")
  • Je öfter ein Nutzer mit einem Programm arbeitet umso mehr wird erwartet, dass (ähnliche) Prozesse immer etwa die selbe Zeit benötigen. ("Das Speichern ging schneller als sonst, war das wirklich erfolgreich? Warum dauert das plötzlich so lange?")
  • Nach einer längeren Zeit ohne Reaktion (ca. 15s) wird der Nutzer ungeduldig. ("Läuft der Prozess noch? Ist das Programm abgestürzt?")

Im Web-Umfeld muss man insbesondere auf Grund des (drahtlosen) Netzwerks und der Entfernung zwischen Nutzer und Server mit deutlicher Verzögerung zwischen Anfrage und Antwort rechnen. Caching und CDN können helfen die Antwortzeit zu reduzieren. Trotzdem wird es insbesondere bei "schlechtem Empfang" schwierig, weniger als 300ms zu benötigen um Anfrage und Antwort vollständig zu übertragen und zu verarbeiten.

Beispiel 1: Verzögerte Reaktion

ms
async function onClick() {
	await doSomething(); // >300ms
	showReaction();
}

Hier sieht man schön, dass keine direkt Reaktion auf das onClick erfolgt. Gerade bei längerer Reaktionszeit fühlt sich das für den Nutzer nicht "rund" an.

Beispiel 2: Direkte Reaktion

ms
async function onClick() {
	showReaction1();
	await doSomething(); // >300ms
	showReaction2();
}

Allein ein kurzer Hinweis auf die erfolgreiche Interaktion verbessert das Nutzungserlebnis.

Beispiel 3: Schneller Wechsel

ms
async function onClick() {
	showReaction1();
	await doSomething(); // <1s
	hideReaction2();
}

Kommt das Ergebnis sehr schnell zurück, hat der Nutzer keine Möglichkeit, die Änderung an der UI vollständig zu erfassen.

Beispiel 4: Verzögerter Wechsel

ms
async function onClick() {
	var minTime = 3000;
	
	var t1 = (new Date()).getTime();
	showReaction1();
	await doSomething(); // 300ms...1s
	var t2 = (new Date()).getTime();
	await sleep(Math.max(0, minTime - (t2 - t1)));
	hideReaction2();
}

Damit der Nutzer die Möglichkeit hat, die Änderung zu verarbeiten, kann die Ladezeit künstlich verlängert werden. Dies hat bei geeigneter Wahl der Mindestzeit auch den Vorteil, dass die (kommunizierten) Ladezeiten in den meisten Fällen gleich groß sind. Arbeitet man an dieser Stelle mit Animationen, so lässt sich die "gefühlte" Ladezeit weiter reduzieren (z.B. 1s einblenden + 2s anzeigen = 3s Überbrückung).

Beispiel 5: Limiter

Intern:
async function onClick() {
	var minTime = 2000;
	
	var t1 = (new Date()).getTime();
	showReaction1();
	await doSomething(); // 40ms...2100ms
	var t2 = (new Date()).getTime();
	await sleep(Math.max(0, minTime - (t2 - t1)));
	hideReaction2();
}

Insbesondere bei schwankenden Antwortzeiten der API wird durch den "Limiter" eine gleichmäßige Nutzungserfahrung erreicht.