Jakob Nielsen ist im Herzen ein Blogger, er kann es nur (noch?) nicht eingestehen. Zusätzlich dazu, dass er seinen Rhythmus von zweiwöchentlich kommentarlos auf wöchentlich hochgefahren hat (wir berichteten, vierter Absatz), beantwortet er jetzt auch noch Leserfragen in seinem „Alertbox E-Mail Newsletter“, in dem er sonst nur auf eine neue Kolumne aufmerksam machte (und penetrant ein bisschen Werbung für die nächsten teuren Veranstaltungen). Das allein ist eigentlich auch ein Usability-Problem: Er selbst würde sicherlich monieren, dass in einem Newsletter, der fünf Jahre lang nur als Link auf eine Website fungierte, plötzliche exklusive Inhalte wie seine neuen Q&As fehl am Platze sind.
Sei’s drum. Hier seine längliche Antwort auf die Frage nach der maximal erlaubten Antwortzeit einer Webapplikation:
I keep getting questions like this, so I decided to answer it in the newsletter.
Q: „You mention many times that response time is important, and there are tons of tools to measure response time, but what is an acceptable web based application’s response time? What is a user’s tolerance, not for a shopping experience, but for an interactive application?“
A: I wish we could eradicate the term „web-based application“ because it distracts from the real issue, which is one of application UI design. We don’t have special guidelines for applications implemented in C++ relative to apps implemented in Visual Basic. The fundamental usability recommendations are the same, no matter the implementation, since we are discussing user experience, not coding.
Therefore, the response time guidelines for web-based applications are the same as for all other applications. These guidelines have been the same for 37 years now, so they are also not likely to change with whatever implementation technology comes next.
0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the user selects a column in a table until that column should highlight or otherwise give feedback that it’s selected. Ideally, this would also be the response time for sorting the column – if so, users would feel that *they* are sorting the table.
1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2-1.0 seconds does mean that users notice the delay and thus feel the computer is „working“ on the command, as opposed to having the command be a direct effect of the users‘ actions. Example: If sorting a table according to the selected column can’t be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of „flow“ in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.
10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user’s work, for example when switching tasks.
http://www.useit.com/papers/responsetime.html
Nielsens wichtigste Aussage: Die erlaubte Antwortzeit hängt nicht von der Art der Applikation ab, sondern ist immer gleich.
Man unterscheidet, so ein Argument, ja auch nicht, ob eine Desktop-Applikation in Visual Basic oder C++ programmiert ist. Deswegen gelten für das Web dieselben Regel wie für alle anderen Anwendungen.
Ich bin nicht einverstanden. Das ist pure Theorie, die mit der Praxis nichts zu tun hat. Und der Vergleich VB/C++ ist pure Polemik. Komisch, dass Nielsen sich zu solchen Aussagen versteigt, wo er doch sonst immer recht nah am User ist und zumindest den Eindruck erweckt, er beobachte noch regelmässig selbst Tests (was ich nicht ganz glaube). Ich vermute, es ist ein Teil seines „Das Web muss noch ganz anders werden bevor es halbwegs benutzbar ist, und nur ich weiss, wie“-Mini-Kreuzzugs, den er praktisch seit dem ersten Tag fährt.
Warum wäre seine Aussage theoretisch richtig? Weil die User sich vor jedem Computersystem natürlich zunächst gleich verhalten.
Warum ist sie de facto falsch?
Weil die User schnell lernen, dass das Web anders ist. Sprich: langsamer. Sowohl bei den Antwortzeiten- als auch bei der Auslieferung der Daten. Wer das erste Mal vor einem Browser sitzt, wird sich vielleicht ein paar Minuten lang wundern, aber er/sie wird es schnell lernen: Online arbeiten funktioniert in kleinen Zeitscheiben: Klicken, ein paar Sekunden warten, lesen, wieder klicken. (1996, als alles noch viel langsamer war, war ich beim beim Surfen grundsätzlich auf zwei Sites gleichzeitig, so dass ich immer in den Pausen auf der einen Site ein bisschen auf der anderen lesen konnte. Leider eine nur vermeintlich effiziente Angelegenheit, denn man vergisst dabei oft, was man eigentlich im anderen Fenster machen wollte.) Bei Usability-Tests kann man dieses unterschiedliche Verhalten sehr gut beobachten: Wenn in lokal laufenden Anwendungen wie Windows oder Office die Software nicht sofort reagiert (hier können Nielsens 0.1 Sekunden stimmen), wiederholen die User die Aktion. Im Web haben sie gelernt, dass es dauert, sie beachten auch genau die Statusleiste des Internet Explorers — solange die kleinen grünen Kästchen einen Fortschritt anzeigen, üben sie sich in Geduld. Wenn sie ein zweites Mal klicken, weil scheinbar irgendwas hakt, dann erst nach mehreren Sekunden. (Dass wenig versierte User mangels mentalem Modell oft nicht unterscheiden können, ob die Inhalte lokal oder remote sind, lassen wir hier mal der Einfachheit halber weg.)
Das alles gilt natürlich für klassische Web-1.0-Applikationen, bei denen der Server jede neue Seite einzeln ausliefert. Ich habe noch keine Ajax-Applikationen getestet (es gibt ja noch kaum deutschsprachige), aber bei denen sollte genau das natürlich grundlegend anders werden. Ich glaube aber nicht, dass das dann zu Usability-Problemen führen wird, denn den Übergang von langsam zu schnell sollte jeder meistern — wie man auch jetzt schon an normalen JavaScript-Funktionen sieht. Umgekehrt kann es aber sein, wenn „schnelle“ Ajax-Applikationen mal der Standard werden sollten (was wohl noch einige Zeit dauern dürfte), dass dann Nielsens Regeln wieder stimmen und die heute noch „normalen“ Sites dann als besonders langsam wahrgenommen werden. Ich bin gespannt, wie sich die Wahrnehmung entwickeln wird.
Tatsache ist: Heute hat Nielsen eindeutig unrecht.
Kommentare