zurück

weiter

Themen:

Einleitung

1. Performanz

2. Lesbarkeit

3. Frames

4. Seitenlänge

5. Orientierung

6. Navigation

7. Seitenfuß

8. Hyperlinks

9. Konsistenz

10. URLs

Literatur

zurück

weiter

1. Performanz - Gewährleisten kurzer Antwortzeiten

Bereits bei einem der ersten Hypertext-Systeme, dem ZOG-System der Carnegie Mellon University, wurde die Performanz als ein ganz entscheidender Faktor für die Benutzbarkeit des Systems erkannt. In einem Test untersuchte man drei verschiedene Systemversionen, die Antwortzeiten von 1/10, 2 und 5 Sekunden boten. Dabei wurden bei Benutzertests klare Unterschiede in der Benutzbarkeit festgestellt, weshalb eine Antwortzeit von maximal 2 Sekunden als Obergrenze angesehen wurde. Bei Systemen mit einer längeren Antwortzeit zweifelten die Tester, ob solche Hypertext-Systeme überhaupt noch ein sinnvolles Hilfsmittel darstellen können (Robertson, McCracken, Newell 79, S. 31).

Allgemeinere Untersuchungsergebnisse im Bereich der Software-Ergonomie untermauern dieses Ergebnis. Ab einer Antwortzeit von 2-4s sehen demnach die Benutzer den Arbeitsfluss als gestört an. Sie sind zudem bei der Arbeit weniger zufrieden und messbar weniger produktiv.

Diese Ergebnisse lassen sich auch auf das WWW übertragen. Antwortzeiten von unter 2s sind hier eher die Ausnahme. Bereits die grafische Aufbereitung der Seite benötigt oft länger als eine Sekunde, aber das eigentliche Problem sind die häufig viel längeren Übertragungszeiten.

Die Performanz des WWW wird laut Umfragen von den meisten Benutzern kritisiert. Beispielsweise gaben beim achten GVU User Survey 63% der Teilnehmer an, dass sie die Geschwindigkeit als großes Problem ansähen. Dieser Prozentsatz ist zwar gegenüber vorherigen Umfragen gesunken, stellt aber immer noch das Hauptproblem dar. Eine ähnliche Quote ergab sich bei einer vom Autor am Fachbereich Informatik der Universität Hamburg durchgeführten Umfrage. Hier nannte über 60% der Teilnehmer die Performanz als das Hauptproblem des WWW.

Die Bandbreite des Internet wird zwar stetig erhöht, aber zugleich steigt auch die Anzahl der Benutzer und die Menge der vom Einzelnen übertragenen Daten. Beispielsweise wäre der Download von mp3- und Video-Daten vor einigen Jahren noch unverhältnismäßig langwierig gewesen.

Bei der kritischen ,,Last Mile'', der Anbindung für Privathaushalte, haben sich zwar in letzter Zeit immer mehr Benutzer für eine der unterschiedlichen DSL-Varianten entschieden, dennoch kann die Mehrheit der Deutschen maximal auf ISDN mit seinen 64000 Bit/s zurückgreifen.

Empfehlungen

Als wichtigste Maßnahmen sind zu nennen:

• Format der Grafiken vorgeben
  Die Attribute HEIGHT und WIDTH bei allen Grafiken angeben. Dies führt dazu, dass der WWW-Browser die Seite im richtigen Format darstellen kann, bevor die Anfänge der Grafikdateien (mit den Formatparametern) übertragen wurden.
• Dokumente auch ohne Grafiken nutzbar machen
  Damit Benutzer eine grafische WWW-Seite verwenden können, bevor alle Grafiken übertragen wurden, müssen alternative Texte angeboten werden. Hierzu ist es zum einen notwendig, dass der Text des ALT-Tags für durchgängig angegeben wird.
  Tipp: Damit der ALT-Text von Browsern wie Netscape angezeigt werden kann, müssen die Grafiken, die sie repräsentieren, ein minimales Format von ca. 80x25 Pixeln aufweisen.
• Grafiken mehrfach verwenden
  Wenn die gleiche Grafik auf einer oder mehreren Seiten eines Servers wiederholt eingebunden wird, so braucht sie nur einmal übertragen zu werden. Aus diesem Grunde eignen sich beispielsweise wiederkehrende Icons (z.B. für die Homepage), Logos und Bullets besonders gut für das WWW-Design.
  
• Grafiken richtig komprimieren
  Eine gute, große Kompression von Grafiken zu erreichen ist teilweise nicht einfach. Der Weg zu einer kurzen Grafikdatei führt über ein kleines Format (Höhe und Breite) und die geeignete Kompressionsmethode. Als Faustregel kann man sagen, dass JPGs für Photos und realistische Bilder zu besseren Kompressionsergebnissen führen, GIFs hingegen bei abstrakten Grafiken. Bei JPGs reicht oft eine niedrige Qualität, und bei GIFs reduziert sich der Speicherbedarf entscheidend, wenn weniger Farben verwendet werden.
  Tipp: 16-farbige GIFs liefern für viele kleine Grafiken ein erstaunlich gutes Ergebnis und bieten oft die beste Kompression.
  
• Wenige Grafiken einbinden
  Für jede Grafik muss das WWW-Protokoll HTTP 1.0 eine neue TCP-Verbindung aufbauen, weshalb die Übertragung jeder einzelnen Datei eine zusätzliche Verzögerung bedeutet. Selbst bei HTTP 1.1, das persistente Verbindungen unterstützt, werden für jede eingebundene Grafik Protokoll-Informationen ausgetauscht. So kann durch viele eingebundene Elemente die real übertragene Datenmenge (inklusive der Protokolldaten) weit über der Netto-Nutzdatenmenge liegen.
  
• Interlaced GIFs und Progressive JPEGs einsetzen.
  Diese Formate führen bei großen Dateien zu einer subjektiv kürzeren Übertragungszeit. Die Grafiken werden bei diesen beiden Verfahren bereits mit einem Teil der Daten im ganzen Format dargestellt. Weitere Daten führen zu einer sukzessiv genaueren Darstellung der Grafik. Nachteile dieser Technik sind hingegen, dass die Dekompression auf langsamen Rechnern (z.B. 80486ern) länger dauert und dass alte Browser sie nicht darstellen können.
  
• Kurze Dokumente anbieten
  Obwohl ein Großteil der Übertragungszeit meist für die Grafiken benötigt wird, kann eine lange Seite zu starken Verzögerungen führen. Längere Wartezeiten entstehen insbesondere dann, wenn der Link auf einen Text im unteren Bereich einer umfangreichen Seite verweist.
• Komplexität der Seiten reduzieren
  Seiten mit komplexen Tabellen und großformatigen Grafiken können bei langsameren Computern dazu führen, dass der Aufbau der Seite durch den Browser unverhältnismäßig lange dauert. Kleinere Grafiken und das Aufteilen von Tabellen beschleunigen die Darstellung.
• Keine Java Applets auf der Homepage verwenden
  Da Java-Programme schnell einen Umfang von vielen -zig kByte haben und erst nach vollständiger Übertragung ausgeführt werden können, führen Java-Applets in der Regel zu erheblichen Verzögerungen. Empfehlenswert ist es daher, dem Benutzer die Wahl zu lassen, ob er das Applet tatsächlich benutzen möchte und ihm deshalb ggf. mehrere Versionen der Homepage anzubieten.
• Stets Tests durchführen
  Ein Test der WWW-Seiten per Modem sollte immer erfolgen, da so die möglichen Probleme anderer Benutzer schnell erkannt werden können. Es passiert beispielsweise recht häufig, dass WIDTH und HEIGHT nicht angegeben werden oder die Summe der Grafiken über 50kByte beträgt, was zumeist zu inakzeptablen Antwortzeiten führt.

Es ist nicht möglich, eine Maximalgröße für die verwendeten Grafiken anzugeben, da dies ein recht subjektiver Wert ist. Man kann allerdings davon ausgehen, dass bereits ab 30 kByte pro Seite für eine große Zahl der Benutzer (mit 56 kBps Modem) die Wartezeit bei über 4 Sekunden liegt.