Webapplikationen mit Unterstützung von XML

Navigation:

Inhalt -> 3 Webapplikationen -> 3.3 Usability

Neues und Änderungen << Vorheriges Kapitel | Nächstes Kapitel >>

Die Usability (engl. für Brauchbarkeit) von Webseiten ist ein vieldiskutiertes Thema. Vor allem deswegen, da sich Usability und ästhetisches Design oft nur schwierig vereinbaren lassen. Zumindest hat man diesen Eindruck, wenn man die Diskussionen zwischen Usability-Experten und Webdesignern mitverfolgt.

Um so wenig Besucher wie möglich auszuschließen und die Bedienung so einfach als möglich zu gestalten, ist es anzuraten, die allgemein gültigen Usability-Regeln beim Design einer Webseite einzuhalten.

Bei Webapplikationen kann man dies allerdings je nach Anwendungsfall differenzierter betrachten: Beispielsweise kann es bei Intranetanwendungen durchaus sinnvoll sein, zu Gunsten der Usability der Anwendung auf die Einhaltung mancher allgemeinen Usability-Regeln zu verzichten.

• Kurze Textsegmente mit aussagekräftigen Überschriften verwenden. Keine großen Textblöcke ohne Strukturierung. [Krems 2002] [Nielsen 2002]
• Links nur zu Webseiten mit engen inhaltlichen Bezügen. [Krems 2002]
• Im Fließtext so wenige Links wie möglich verwenden. [Krems 2002]
• Lange Ladezeiten vermeiden. [Krems 2002] [Nielsen 1999a]
• Vermeiden von langen Seiten mit Scrollbalken. [Krems 2002]
• Das Navigationssystem sollte dem Benutzer immer Auskunft geben, wo er sich innerhalb der Seitenstruktur gerade befindet. [Krems 2002]
• Die Webseiten sollen hierarchisch und nicht netzwerkartig verlinkt sein. [Krems 2002]
• Es soll eine leicht zugängliche Möglichkeit bestehen, den oder die Seitenbetreiber zu kontaktieren. [Krems 2002]
• Ab einer gewissen Größe der Webseite (etwa 100 Einzelseiten), soll eine - nach Möglichkeit - fehlertolerante Suche innerhalb der Seiten zur Verfügung stehen. So genannte "Sitemaps", die möglichst alle Seiten eines Webauftritts aufzählen, sind auch schon bei kleineren Webauftritten sinnvoll. [Nielsen 2002] [Nielsen 2002a] [Nielsen 1999]
• Die Webseiten sollen nicht zu breit sein. Horizontale Scrollbalken sollen vermieden werden. Eine minimale Bildschirmauflösung von 800x600 Pixel kann aber mittlerweile angenommen werden. [Nielsen 2002]
• Der Benutzer soll die Schriftgröße frei wählen können. [Nielsen 2002]
• Links sollten so funktionieren, wie das üblich ist. Insbesondere sollten keine zusätzlichen Fenster ("Pop-Ups") mit Hilfe von Javascript geöffnet werden. [Nielsen 2002]
• Die URLs sollten nicht zu lange und nicht zu kompliziert sein. Dann können Benutzer auch anhand der URL die Struktur der Seite erkennen. Außerdem können sie leichter niedergeschrieben werden. [Nielsen 2002]
• Eine Webseite sollte einen aussagekräftigen Titel erhalten (für Suchmaschinen, Bookmarks). [Nielsen 2002a]
• Auf Webseiten sollte zuerst eine Zusammenfassung der Seite kommen. Dadurch erfährt der Besucher sofort um was es geht, und kann bei Interesse den ausführlichen Text lesen. [Nielsen 2002a]
• Links sollten aussagekräftige Namen erhalten. Nicht nur: "Klicken Sie hier." Er soll sich also selbst beschreiben und nicht der Text davor oder danach. Außerdem sollten Links auch eine Linkbeschreibung erhalten. (Linkbeschreibung: Gelber Zusatztext, der erscheint wenn man mit der Maus über den Link fährt.) [Nielsen 2002a] [Nielsen 1999]
• Es hat sich eingebürgert, dass sich links oben der Name und das Logo der Firma oder Organisation befinden. Dies sollte gleichzeitig ein Link zurück zur Startseite sein. [Nielsen 1999]
• Sicherstellen, dass die Seiten auch für schwachsichtige oder blinde Besucher benutzbar sind. Zum Testen kann man sich eine Seite etwa mit einem Textbrowser wie Lynx ansehen. [Nielsen 1999]
• An anderen großen Webseiten orientieren. Die Benutzer werden die meiste Zeit auf anderen (großen) Webseiten verbringen. Wenn die eigene Seite in einer ähnlichen Weise bedienbar ist wie die großen Webseiten, werden sie sich schneller zurechtfinden. [Nielsen 1999]
• Eingangsseiten mit Animationen sind bestenfalls für Personen mit Breitbandinternetanschluss beim ersten Besuch interessant. Sonst stören sie nur und erschweren das schnelle Auffinden von relevanten Informationen. [Nielsen 1999b]
• Der Code einer Webseite muss HTML- bzw. XHTML-konform sein. Die Seiten sollen auf allen wichtigen Browsern getestet sein, damit sichergestellt werden kann, dass sie auf möglichst allen Browsern funktionieren [Schulz U. 2002]
• Eine Webseite muss auch ohne Plugins oder ähnliche Browsererweiterungen benutzbar sein. [Schulz U. 2002]
• Die Verwendung von Frames ist nicht mehr so schlimm, wie das früher (1996) war, aber trotzdem gibt es Probleme mit Suchmaschinen und bei Bookmarks. Problematisch ist auch das Linken auf eine Seite innerhalb eines Frames: Oft fehlt dann die Navigationsmöglichkeit (Menü). [Nielsen 1999c]

Kommentare des Autors

Auf Webseiten geht es meist darum, schnell Informationen zu suchen und zu finden. Es ist daher wichtig aussagekräftige Überschriften (auch Zwischenüberschriften) und kurze Absätze, die schnell überflogen werden können, zu verwenden. Es hat sich auch als nützlich herausgestellt, gleich zu Begin der Seite eine kurze Zusammenfassung anzubieten. So sieht der Besucher sofort, welchen Inhalt die Seite enthält. Zu viele Links innerhalb des Fließtext haben sich als unübersichtlich herausgestellt. Sollte der Besucher weiterlesen, oder sich zuerst den Link ansehen?

Seitenlänge - Scrollen

Anfängliche Untersuchungen von Jakob Nielsen haben gezeigt, dass Benutzer von Webseiten den Scrollbalken kaum benützen [Nielsen 1996]. Das lag einerseits vermutlich am Unwissen der Benutzer, andererseits auch an der Tatsache, dass die Scrollbalken nicht sehr einfach zu bedienen sind. Man muss relativ kontrolliert mit der Maus navigieren. Außerdem sind die Scrollbalken bei den meisten Betriebssystemen rechts. Der Text und viele Navigationselemente, wie Menüs, sind aber fast immer links angeordnet. D.h. die Maus muss immer zwischen linken und rechten Fensterrand hin und her wandern. Die Verbreitung des so genannten Scrollrades auf der Maus hat das Scrollen aber mittlerweile stark vereinfacht.

Spätere Studien haben gezeigt, dass Benutzer sehr wohl scrollen. Trotzdem sollten laut [Krems 2002] lange Seiten vermieden werden. Die Frage ist allerdings, ob nicht in vielen Fällen (z.B. längerer Text zu einem Thema) eine etwas längere Seite gegenüber mehreren Einzelseiten zu bevorzugen ist. Einzelseiten müssen immer neu geladen werden und enthalten Overhead durch Navigationselemente, Logos, etc.

Seitenbreite und Bildschirmauflösungen

Wichtiger als die Länge einer Webseite ist deren Breite. Idealerweise wird eine Webseite so entworfen, dass ein unkompliziertes Betrachten in jeder beliebigen Bildschirmauflösung möglich ist. Allerdings ist das in der Praxis oft so gut wie unmöglich. Einerseits passen viele Inhalte nicht auf Seiten mit kleinen Breiten, andererseits ist ein einfacher Text, der bei einer Breite von 600 Pixel noch gut lesbar ist, bei einer Breite von 1200 Pixel kaum lesbar, weil es äußerst schwierig ist, beim Zeilenumbruch die richtige Zeile zu finden. Mittlerweile haben zumindest in den Industrienationen fast alle Benutzer Auflösungen von mindestens 800 x 600 Pixel. Eine Webseite kann also durchaus eine Breite von bis zu 760, 770 Pixel aufweisen.32 Früher wurde zwar empfohlen, dass Webseiten auch auf einer Auflösung von 640 x 480 Pixel ohne horizontales Scrollen sichtbar sein soll. Die Frage ist allerdings, ob man für einige sehr wenige Besucher eine Seite entwerfen soll, die dann für den Großteil der Besucher, die Auflösungen von 1024 x 768 Pixel und mehr verwenden, sehr klein oder unübersichtlich ist.

Leider sieht man immer wieder Seiten, die auf 1024 x 768 Pixel ausgelegt sind. Wie aber in Tabelle 1 zu sehen ist, verwenden noch genügend Besucher eine Auflösung von 800 x 600 Pixel. Und viele, die größere Bildschirme besitzen und damit größere Auflösungen verwenden können, wollen Webseiten nicht im Vollbildmodus betrachten, sondern benutzen kleinere Browser-Fenster, damit sie mit mehreren Fenstern gleichzeitig arbeiten können.

Die vom Besucher verwendete Bildschirmauflösung kann nur mit Hilfe eines Javascript-Programmes ermittelt werden. Nach den Statistiken haben etwa 10% der Besucher Javascript deaktiviert.36

Nach Quelle 1, die über 330 Mio. internationale Besucher - hauptsächlich aus den USA - repräsentiert, verwenden die meisten Besucher nach wie vor eine Auflösung von 800x600 Pixel. Mit 2,3% ist der Anteil der Besucher, die noch 640x480 Pixel verwendet, relativ hoch. Das ist immerhin jeder 43. Besucher.

Quellen 2 und 3 sind Seiten des Autors zu einem Sportthema mit Zugriffen von 18.500 bzw. 29.000 verschiedenen Rechnern (eigentlich IP-Adressen) pro Monat. Die Besucher stammen hauptsächlich aus dem deutschsprachigen Raum (etwa 90%) und sind typischerweise zwischen 15 und 35 Jahre alt. Vor allem bei Quelle 3 - einem Online-Diskussionsforum - zeigt sich ein deutlicher Trend zu größeren Auflösungen. Vermutlich sind diese bei jüngeren Benutzern und im deutschsprachigen Raum schon weiter verbreitet als im internationalen Vergleich. Zu beachten ist, dass die Besucher der Seiten von Quelle 2 und 3 üblicherweise keine Computerexperten sind, eher im Gegenteil.

Seitengröße und Download-Geschwindigkeit

Trotz zunehmender Verbreitung von Breitband-Internet-Anschlüssen sollte auf schnellen Seitenaufbau auch bei langsamen Verbindungen (Modem) geachtet werden. Hilfreich dabei ist die Verwendung von CSS vor allem für Schriftarten und -größen, Abstände, und Hintergrundfarben. Zusätzlich bieten fast alle Webserver und Webbrowser die Möglichkeit an, Webseiten komprimiert zu übertragen. (Siehe Kapitel 2.6.5 Geschwindigkeit.) Am wichtigsten sind allerdings die sparsame Verwendung von Bildern und deren korrekte Komprimierung. Zu stark komprimierte Bilder sehen jedoch unprofessionell aus. Bei Grafiken mit weniger Farben und Farbübergängen erhält man üblicherweise mit dem GIF-Format die besseren Ergebnisse. Bei Fotos hingegen mit dem JPG-Format. Für die Algorithmen, die bei der Komprimierung der Bilder beim GIF-Format verwendet werden, sind allerdings von den Softwareherstellern Patentgebühren zu zahlen. Es wird daher angestrebt, das GIF-Format durch das PNG-Format abzulösen. Dieses ist frei von Patenten, erreicht meist eine bessere Komprimierung als GIF und erlaubt mehrere Transparenzstufen und eine Gammakorrektur.

Korrekte Codierung von Webseiten

Webseiten sollten bei so vielen Browsern als möglich korrekt dargestellt werden. Das setzt voraus, dass der HTML-Code fehlerfrei ist. Bei neuen Projekten empfiehlt es sich, die Seiten XHTML-konform zu erstellen. Eine Überprüfung auf Korrektheit (Wohlgeformtheit und Gültigkeit, siehe Kapitel 2.2.1 XML - Extensible Markup Language) ist dadurch leichter möglich. Vor allem muss eine Seite mit den zur Zeit am meisten verwendeten Browsern (Internet Explorer, Mozilla und Derivate, Opera) getestet werden.

Beim Codieren ist es auch wichtig übliche Vorgehensweisen einzuhalten. Hier kann der Vergleich mit großen, bekannten Seiten nicht schaden. Z.B. sollten alle Bilder mit dem "alt"-Attribut des "img"-Tags versehen werden. Hier kann man eine Beschreibung des Bildes angeben. Diese wird üblicherweise beim Drüberfahren mit der Maus in einem kleinen gelben Fenster angezeigt. Hat ein Besucher die Anzeige von Bildern ausgeschaltet, so sieht er so eine Beschreibung. Blinde Benutzer können dann ebenfalls diese Beschreibung sehen. Mit dem "title"-Attribut des Link-Tags (<a href="URL" title="Beschreibung" >) kann Ähnliches erreicht werden. Das Logo links oben sollte auf die Startseite zurücklinken. Normaler Text sollte nicht unterstrichen werden, um eine Verwechslung mit Links, die üblicherweise unterstrichen sein sollten, zu vermeiden.

Frames

Zu Beginn des Design-Prozesses der Webseite stellt sich die Frage, ob eine Seite mit oder ohne Frames erstellt werden soll. Beim Einsatz von Frames werden üblicherweise die Navigationselement in eigene Frames untergebracht. Dieser Teil bleibt dann unverändert. In einem anderen Frame befindet sich der eigentlich Seiteninhalt. Vorteil: Navigationselemente sind nur in einer Datei enthalten. Sie können daher leichter gewartet und müssen nicht bei jedem Seitenaufruf neu geladen werden. Beim Einsatz von dynamischen (also durch Programme erstellten) Webseiten, können die Navigationselemente allerdings in eigene Quelltext-Dateien ausgelagert werden, sodass ebenfalls nur eine Datei gewartet werden muss, die Navigation aber trotzdem auf allen Einzelseiten vorhanden ist. Auch der Vorteil in der Ladezeit ist wegen der immer schnelleren Internetverbindungen meist zu vernachlässigen.

Probleme kann der Einsatz von Frames bei Suchmaschinen und Bookmarks, bzw. allgemein bei externen Links machen. Suchmaschinen können zwar mittlerweile auch Frameseiten indizieren. Allerdings können externe Links (wie eben auch bei der Suchmaschinen nötig) im Allgemeinen nicht auf die komplette Webseite mit einer bestimmten Inhalt im Frame linken. Entweder sie linken nur auf die Inhalts-Seite, dann fehlt oft der Navigationsbereich, oder sie linken auf die Hauptseite, dann kann aber die Inhaltsseite nicht angegeben werden. Es wird nur die Standard-Inhaltsseite (Startseite) angezeigt. Im ersten Fall könnte man mit Javascript den Navigationsbereich nachladen. Im zweiten Fall könnte man sich mit dynamisch generierten Framesets helfen, denen per Query-String (Siehe Kapitel 3.4.2 Datenübertragung zwischen Client und Server.) die URL des Inhalts-Bereichs übergeben wird. Allerdings müssten Webmaster, die solche externen Links setzen wollen, wissen, wie das im jeweiligen Fall genau implementiert ist. Allgemein gültig ist das nicht.

Mittlerweile unterstützen alle Browser Frames. Sogar mit dem textbasierten Browser Lynx ist es möglich, Frameseiten anzusehen. Trotzdem könnte es sein, dass spezielle Browser (z.B. für Blinde) mit Frames schlechter umgehen könnten. Es empfiehlt sich daher im so genannten "noframe"-Tag eine kurze Beschreibung des Seiteninhaltes wiederzugeben. Dies könnte auch bei der einen oder anderen Suchmaschine vorteilhaft sein.

Beim Einsatz von Frames ist außerdem zu beachten, dass man niemals fremde Inhalte in eigene Frames lädt und damit suggeriert, es wäre der eigene Inhalt. Mittlerweile gab es deswegen schon einige Gerichtsverfahren.

Ein Online-Shop wie etwa Amazon.de kann es sich natürlich nicht leisten, seine Webseite beispielsweise für eine Auflösung von 1024x768 Pixel zu optimieren und einen Einkauf nur mit aktiviertem Javascript zu erlauben. Anders sieht es allerdings bei einem webbasiertem CMS (Content Management System) oder einem Werkzeug zum Verwalten von Webservern aus. Hier kann man davon ausgehen, dass die Anwendung von versierten Benutzern verwendet wird. Wenn durch den Einsatz einer größeren Bildschirmauflösung die Übersichtlichkeit steigt oder durch den Einsatz von Javascript eine bestimmte Aufgabe schneller durchgeführt werden kann, ist das durchaus zu empfehlen. Benutzer solcher Anwendungen wollen (oder müssen) diese verwenden und sind daher auch eher bereit, Hilfeseiten oder Dokumentationen zu lesen.

Bei Webapplikationen im Intranet (im LAN) kann man durchaus noch einen Schritt weiter gehen. Die Soft- und Hardware-Ausstattung der Client-Rechner ist bekannt und die Benutzer können für eine bestimmte Anwendung eingeschult werden. Das ist natürlich kein Freibrief, sämtliche Usability-Kriterien, wie sie für Webseiten gelten, zu ignorieren.

Wird so eine Intranet-Anwendung von bestimmten Mitarbeitern etwa nur einmal im Monat oder noch seltener benutzt, ist deren Benützung sehr mühsam, wenn sie nicht selbsterklärend ist. Zu Bedenken ist auch, dass eine Intranet-Anwendung eventuell verkauft werden könnte, oder nach Firmenübernahmen auf anderer Hard- oder Software laufen muss.

Wird auf einer Webseite oft auf verschiedene Bereiche zugegriffen (lesen, auf Links klicken, etc.), ist es äußerst mühsam für den Benutzer, wenn die Seite so lange ist, dass ständig gescrollt werden muss. Ein typisches Beispiel wäre ein umfangreiches Menü. Eine Lösung dieses Problems wäre ein Übersichtsmenü zu Beginn der Seite, von wo aus die einzelnen Bereiche der Seite angesprungen werden können. Wird eine Seite dagegen hauptsächlich sequentiell abgearbeitet (z.B. ein längerer zusammenhängender Text oder ein längeres Formular) ist eine längere Seite meist sinnvoller. Es muss allerdings bedacht werden, dass bei großen Formularen auf einer Seite die Gefahr des Datenverlustes größer ist, als bei einem auf mehrere Seiten aufgeteiltes Formular. Bei aufgeteilten Formularen werden die Daten beim Weiterklicken auf den nächsten Teil jeweils am Server gespeichert. Füllt man dagegen ein langes Formular aus und es tritt ein Problem beim Absenden auf, so können die eingegebenen Daten verloren sein.37

Eine weitere Rolle spielt die Ladezeit einer Seite. Ein umfangreiches Menü ist meist schneller zu bedienen, wenn es auf zwei (oder mehr) Ebenen verteilt ist, als eine extrem lange Seite, auf der man beim Scrollen schnell den Überblick verlieren kann. Kennt man die Navigation und laden die Einzelseiten schnell (im LAN), kann man die gewünschte Seite mit zwei bis drei Klicks erreichen. Das kann schneller sein als ein langes Scrollen.

Anders sieht es dagegen aus, wenn die Zeit zum Generieren und Übertragen der Seite sehr lange dauert. Beispielsweise eine aufwändige Suche in der Datenbank, die mehrere Sekunden in Anspruch nimmt. Wenn das Suchergebnis nicht zwischengespeichert wird, also bei jeder Abfrage wieder dieselbe Zeit in Anspruch nimmt, ist es sinnvoller, die Suchergebnisse oder die Liste der Suchergebnisse auf möglichst wenige Seiten aufzuteilen.

Dasselbe gilt, falls bestimmte Seiten häufig ausgedruckt oder gespeichert werden sollen. Das geht einfacher mit einer langen Seite als vielen kurzen Einzelseiten.

Frames

Frames eignen sich besonders zur schnellen Navigation und zur Darstellung mehrerer Inhalte in einem Fenster, wobei in jedem Frame extra gescrollt werden kann. Da die Navigationselemente in einem extra Frame enthalten sein können und deshalb auf den Inhaltsseiten nicht mehr vorhanden sein müssen, können die Inhaltsseiten schneller geladen werden. Die üblichen Probleme mit Frames, insbesondere bei Suchmaschinen und Bookmarks, fallen bei Webapplikationen wenig ins Gewicht. Zuviele Frames können aber äußerst problematisch werden. Sollten etwa der Inhalt von zwei Frames gleichzeitig ausgetauscht werden, kann das nur mit Hilfe von Javascript erfolgen. (Siehe: [Münz 2001b].) Geht der Benutzer mit dem "Zurück-Button" des Browser zurück, wird dann je nach Browser-Produkt und Javascript-Code nur in einem Fenster der ursprüngliche Inhalt wieder geladen.38

Javascript

Wie aus Tabelle 1 ersichtlich, haben bis zu 10% der Besucher Javascript deaktiviert.39 Ist eine Webseite ohne Javascript nicht zu bedienen, sperrt man im schlimmsten Fall jeden zehnten Besucher aus. Es gibt jedoch einige Dinge, die sich nur durch Javascript realisieren lassen, oder die mit Hilfe von Javascript viel einfacher durchzuführen sind als ohne. Da grundsätzlich alle modernen Browser Javascript unterstützen, kann es für Webapplikationen verwendet werden. Typische Beispiele für den Einsatz von Javascript sind:

• Überprüfen von Formulareingaben. Trotzdem müssen sie am Server vor der Verarbeitung nochmals überprüft werden. Sonst könnte ein Besucher mit deaktiviertem Javascript ungültige Daten eingeben und somit unter Umständen Fehler in der Anwendung provozieren.
• Ändern des Inhaltes in Textfeldern oder Auswahlfeldern in HTML-Formularen. Beispiel: Im Formular-Textfeld zum Hinzufügen neuer Einträge in einem Forum können mit Markup spezielle Formatierungen oder Funktionen (Links, Fettschrift, Smilies, Zitate, ...) erreicht werden. Mit Hilfe von Buttons oder Links und Javascript kann dieser Markup auch automatisch dem Textfeld hinzugefügt werden.
• Kleine, clientseitige40 Berechnungen innerhalb eines Formulars: Euro-Umrechner, Taschenrechner, etc.
• Dynamische Navigation: Menüs, die sich beim Drüberfahren oder Anklicken erweitern. Oder Formular-Auswahlboxen, die bei der Auswahl wie Links funktionieren. Achtung: Auf normalen Webseiten muss immer eine alternative Möglichkeit bestehen, auch ohne Javascript alle Seiten zu erreichen!

Browser, Plugins und Browsererweiterungen

Wird eine Webapplikation nur in einer bekannten Umgebung verwendet, wie das etwa in einem Intranet der Fall ist, kann es im Einzelfall durchaus sinnvoll sein, auf einen spezielle Browser zu optimieren. Dieser Punkt ist in letzter Zeit nicht mehr so entscheidend, da alle großen Browser (Internet Explorer, Mozilla und Derivate und Opera) die wichtigsten Standards unterstützen. Trotzdem kann es vorkommen, dass sich eine bestimmte Aufgabe am idealsten mit einer Funktion durchführen lässt, die (noch) nicht von allen Browsern unterstützt wird. Vorzugsweise gilt das natürlich für Standards, die aber nur teilweise umgesetzt sind (XHTML, CSS, Javascript, ...). Auch der Einsatz von weit verbreiteten Plugins kann sinnvoll sein, wenn dadurch die Durchführung von Aufgaben ermöglicht wird, die auf herkömmliche Weise nicht oder nur schlecht durchgeführt werden kann.

Absolut nicht zu empfehlen ist der Einsatz von Browsererweiterungen, die die Browserhersteller zusätzlich einbauen, aber auf keinen Standard basieren. Vor einigen Jahren gab es hier sehr viele Funktionen, die Microsoft oder Netscape in ihre Browser integrierten. Teilweise beruhte das darauf, dass die Entwicklung der Standards zu lange dauerte, die Benutzer, Webmaster und -designer aber neue Funktionen forderten. So entwickelten die Hersteller viele proprietäre Erweiterungen. Manche haben sich durchgesetzt und sind zu Standards geworden, wie beispielsweise die Cookies oder SSL, andere wieder nicht, wie die Layer-Tags (Ebenen) von Netscape.

32800 Pixel - Breite des Fensterrandes und des Scrollbalkens

33Daten vom Dezember 2002 von www.thecounter.com/stats/. Es sind die Gesamtstatistiken von Zählern auf vielen einzelnen internationalen (hauptsächlich amerikanischen) Webseiten. Insgesamt 331 Mio. Besucher.

34Daten vom Jänner 2003 einer Webseite des Autors mit einem Sportthema (www.dh-rangers.com). 18.500 verschiedene IP-Adressen, hauptsächlich aus dem deutschsprachigen Raum. Da aber alle Seiten auch in Englisch vorhanden sind, gibt es auch internationale Besucher.

35Daten vom Jänner 2003 eines Online-Diskussionsforum des Autors zu einem Sportthema (www.downhill-board.com). 29.000 verschiedene IP-Adressen. Fast ausschließlich Zugriffe aus dem deutschsprachigen Raum. Altersgruppe: 15 - 35 Jahre.

36 Wieso bei den beiden ähnlichen Seiten 2 und 3 die Javascript-Zahlen so unterschiedlich sind, lässt sich dadurch erklären, dass auf 3 (ein Forum) sehr viele Seiten von Suchmaschinenrobotern (auch: Bot, Spider) abgerufen werden. Diese Roboter sind Programme, die die Seiten abrufen und in den Suchmaschinenindex aufnehmen. Diese Programme laufen auf vielen verschiedenen Rechnern, die natürlich alle unterschiedliche IP-Adressen haben. Dadurch sind sie für die Zähler (Page-Counter) viele unterschiedliche Besucher, die üblicherweise kein Javascript verwenden. Abgesehen davon verwenden diese Programme sowieso keinen Monitor (mit einer bestimmten Auflösung), um den Inhalt der Seiten anzusehen.

37Oft hilft ein Klick auf den "Aktualisierungs-Button" (Reload) oder auf "Zurück" (Back) im Browser, sobald der Server oder die Verbindung dorthin wieder funktioniert, um die Daten doch noch sicher speichern zu können.

38Sollte es zu diesem Problem kommen, kann es sich als hilfreich erweisen, statt "location.href=", wie in [Münz 2001b] beschrieben, "location.replace()" zu versuchen. Siehe: selfhtml.teamone.de/javascript/objekte/location.htm#replace.

39Vermutlich etwas weniger, weil bei den 10% auch Suchmaschinenroboter dabei sind, die ebenfalls kein Javascript aktiviert haben.

40"Clientseitig" heißt, dass die Abwicklung am Client (Browser) erfolgt. Der Server ist nicht involviert. In diesem Fall heißt es, dass keine neue Seite vom Server geladen werden muss, um das Ergebnis der Berechnung zu erhalten.