Web-Weaver

10 Regeln für ein optimales und überall les- und nutzbares Web-Design

Keep it as simple as possible but not simpler.
(A. Einstein)

Einleitung

Wer viel mit dem Mac im Web unterwegs ist, wird täglich mit vielen Scheußlichkeiten gequält, die ihm angeblich professionelle Webdesigner unterjubeln wollen. Da wird behauptet, daß die Seite optimal nur mit dem Browser eines bestimmten Herstellers zu sehen sei, da wird man aufgefordert, Plug-Ins, Active-X-Elemente oder sonstige gefährliche und zeitraubende Sachen runterzuladen (selbst dann, wenn man diese Plug-Ins schon installiert hat, die Abfrage danach aber nur mit einem bestimmten Betriebssystem möglich ist). Da sind Seiten für eine volle Monitor-Auflösung optimiert, als ob sich nicht rumgesprochen hätte, daß meistens der Benutzer mit seinem Rechner noch irgendetwas anderes zu erledigen hat, außer im Web zu surfen und daher Zugang zu einigen anderen Elementen seines Desktops neben seinem Browser benötigt. JavaScript Fehler ohne Ende (Endlosschleifen!), Navigationselemente, die unter anderen Elementen versteckt sind, weil die Positionierung nicht anständig geklappt hat, bis hin zu Seiten, die den Browser in den Abgrund reißen... Die Liste ließe sich beliebig fortsetzen.

Und an allem ist natürlich - wie immer - der Benutzer schuld. Wie die blödsinnige Initiative Webmasters Against Netscape zeigt, haben viele noch nicht begriffen, daß man dem Benutzer weder einen Browser verbieten noch einen anderen Browser vorschreiben darf. Das Netz ist ein Informationsmedium, dessen Inhalt allen uneingeschränkt zur Verfügung stehen sollte, ohne Rücksicht auf Browser, Betriebssystem oder Rechner. So gibt es Blinde, die sich ihre Webseiten vom Rechner vorlesen lassen, Nutzer, denen eine restriktive Firewall oder Firmenpolicy JavaScript verbietet oder gar Netscape 4 als Browser vorschreibt. Nutzer, die aufgrund ihrer finanziellen Möglichkeiten mit alten 286ern unter Windows 3.1 oder mit Browsern auf betagten Ataris surfen. (Beispiel Dritte Welt!) Und dann die Menge der wissenschaftlichen Spezialbrowser (die meist nur HTML 3.2 können - da in Java geschrieben), die z.B. mathematische Formeln darstellen können oder die Molekülstrukturen in VRML anzeigen. Das Netz ist so vielfältig wie seine Benutzer und wer für das Web entwirft, tut gut daran, dies als Chance zu akzeptieren und nicht als Einschränkung zu empfinden. Webseiten, die nur auf dem Rechner des Designers gut aussehen, sind Onanie. Sie sollten dort auch bleiben und nicht ins Netz gestellt werden.

Dabei ist es eigentlich sehr einfach, valides und überall lesbares Design zu produzieren. Professionelles Webdesign steht - wie das Brandenburger Tor in Berlin - auf sechs Säulen. Die ersten drei Säulen heißen Standards, Standards, Standards und die zweiten drei Säulen Testen, Testen und noch einmal Testen.

Regel 1: Valides HTML ist eine notwendige, aber keine hinreichende Voraussetzung für optimales Webdesign.

Eine Grundvoraussetzung für überall lesbare Webseiten ist das Einhalten von Standards. Professionell erstellte Webseiten müssen den Anforderungen des W3C genügen und zwar ebenso im HTML- wie auch im CSS-Bereich. Das gehört in jedes Pflichtenheft! Es gibt keine Garantie, wie ein Browser mit fehlerhaften Seiten umgeht. Einige Browser sind großzügig und stellen die Seiten trotz der Fehler lesbar dar, andere zeigen gar nichts oder schmieren gar ab. Berüchtigt war die Fehlerbehandlung des Netscape 4.x auf dem Mac. Seiten, die Tabellen ohne schließende /tr-Tags hatten, wurden erst gar nicht angezeigt.

Ausnahme: Leider muß man bei der Darstellung von Multimedia-Inhalten (QuickTime Movies) von der hehren Leitlinie abweichen. Der HTML-4-konforme object-Tag wird von älteren Browsern nicht verstanden, man kann die Movies an dieser Stelle nur mit dem embed-Tag einbinden. Man kann hier entweder auf die Validierung verzichten oder die DTD einer älteren HTML-Version benutzen, die den embed-Tag akzeptiert.

Regel 2: Defensives Codieren.

Daraus folgt, daß alleine das Insistieren auf Standards noch keinen Erfolg bringt. HTML-Konstrukte, von denen man weiß, daß sie auch nur auf einem der Browser eines potientiellen Nutzers der Site nicht funktionieren, dürfen - selbst wenn sie gültiges HTML sind - nicht eingesetzt werden. Das betrifft z.B. tief verschachtelte Tabellen (mit denen hat Netscape 4.x auf dem Mac massive Probleme), auch wenn es komplizierter ist, sollte man nur eine Tabelle mit vielen Row- and Colspans entwerfen.

Überhaupt Tabellen: Lesegeräte für Blinde und auch textbasierte Browser wie der Lynx können Tabellen nicht darstellen. Sie werden stattdessen reihenweise von rechts nach links gelesen und elementweise untereinander angezeigt. Ein Testlauf im Lynx zeigt an, ob eine Site auch von Behinderten gelesen werden kann.

Zusätzlich muß also die Regel des defensiven Codierens angewendet werden. Sicherheitshalber nur das nehmen, von dem man weiß, das es überall funktioniert. Auch wenn das vielfach angenommen wird, ist das keine neue - nur auf HTML beschränkte - Regel. Alteingesessene Programmierer kennen das Prinzip der »Sicherheitsklammern«: Auch wenn die Sprachdefintiion keine Klammern an dieser Stelle vorsieht - besser klammern. Wer weiß, ab der Compiler die Sprachdefiniton richtig gelesen hat.

Noch stärker als für HTML gilt die Regel des defensiven Codierens für JavaScript. Wenn man es nur irgendwie vermeiden kann, sollte man auf den Einsatz von JavaScript verzichten. Insbesondere die unterschiedlichen Document Object Modelle (DOM) der Browser sind eine Quelle ständigen Ärgers. Außerdem existiert JavaScript in mindestens drei unterschiedlichen Versionen: Einmal das JavaScript von Netscape, dann das JScript von Microsoft und schließlich das ECMA-Script des W3C. Und wie könnte es anderes sein: Alle drei verhalten sich abweichend und machen dem Web-Designer das Leben schwer. Mit dem immer stärker werdenden Vordringen von ActionScript als vierter JavaScript-Variante wird sein Leben auch nicht gerade leichter.

Regel 3: Vorsicht mit CSS.

Bei der Einschätzung von CSS wohnen zwei Seelen in meiner Brust. CSS würde tatsächlich die Trennung von Inhalt und Layout ermöglichen - ja wenn es denn überall funktionierte. Insbesondere die Positionierung und Farbgebung von Elementen sorgt bei nahezu allen Browsern auf den Mac für seltsame Ergebnisse: iCab kann es gar nicht, der Internet Explorer 5 hat bei der Darstellung einen fetten Bug (der leider auch in 5.1 nicht ausgeräumt wurde), Omniweb kann es auch nicht und Netscape 4.x hat sehr eigenwillige Vorstellungen, was der Designer da gemeint haben könnte. Einzig Netscape 6/Mozilla läßt die Seiten so aussehen, wie sie der Designer vielleicht gedacht haben könnte.

Außerdem sollte die Trennung von Inhalt und Layout in der Datenbasis (sprich im Content Management System (CMS) oder in den der Website zugrundleigenden XML-Files) vorgenommen werden und nicht in der HTML-Seite.

CSS ist ein großer Fortschritt für die Darstellung von Webseiten. Leider wird dieser Fortschritt von nahezu allen Browserherstellern nur mangelhaft unterstützt. Daher Vorsicht mit CSS. Alle Seiten mit CSS müssen intensiv auf möglichst vielen Betriebssystemen und mit möglichst vielen Browsern getestet werden. Als Faustregel gilt: Die Seite mit abgeschalteten CSS anschauen. Wenn sie dann schrecklich aussieht, stimmt irgendetwas mit dem Design nicht, denn CSS-basierte Seiten sollten auch mit abgeschaltetem CSS noch lesbar sein. Das ist insbesondere auch für alternative Clients wie Braille-Lesegeräte etc. wichtig.

Regel 4: Keine Bilder, wo auch Text die Aufgabe löst.

Sehr beliebt bei Webdesignern sind Bildchen anstelle von Text in den Menüleisten. Die Bilder haben den Vorteil, daß sie auf den beliebten Rollover-Effekt reagieren: Wenn der Benutzer mit der Maus über dem Bild schwebt, ändert dieses die Farbe oder das Aussehen und signalisiert dem User »Bitte klick mich«. Sie haben aus der Sicht des Designers auch noch einen weiteren Vorteil: Wenn nur ein einziger Menüpunkt dazukommt, muß der Designer wieder gerufen (und bezahlt!) werden, um ein neues Bildchen zu entwerfen.

Unbestrittene Tatsache ist, daß der Rollover-Effekt für Text nur mit dem Internet-Explorer funktioniert. Wer ihn also - aus welchen Gründen auch immer - benötigt, muß an dieser Stelle ein Bild einsetzen. Aber ist das für Menüleisten wirklich notwendig? Weiß nicht sowieso jeder Benutzer, daß ein Menü etwas zum Klicken ist? Bilder in der Menüleiste verlangsamen das Laden und Aufbauen einer Seite extrem. Ein abschreckendes Beispiel sind die Seiten des Spiegel. Deren völlig auf Bilder setzende Navigation läßt den Aufbau der Seiten nicht nur bei einer langsamen Modemverbindung so lahmen, daß ich die Seiten des Spiegel schon lange nur noch sporadisch besuche.

Auf »anspruchsvolles« Design für die Menüleiste braucht man auch ohne Bilder nicht zu verzichten. CSS-Textauszeichnungen gehören zu den CSS-Elemtenten, die nahezu überall funktionieren und die man problemlos einsetzen kann.

Regel 5: Keine Annahmen über Browser, Rechner und Monitor des Benutzers

Viele Designer nehmen an, daß ihre Nutzer sowieso mit Internet Explorer 5 unterwegs sind und es höchstens ein paar Exoten gibt, die einen alternativen Zugang zu ihren Seiten wollen. Diese Annahme ist ebenso kurzsichtig wie falsch. Zwar kann es unter Umständen jetzt stimmen, doch kaum ein Metier ist so schnelllebig und so vielen Vweränderungen unterworfen, wie das WWW. Und wenn eine Site längere Zeit - unter Umständen sogar Jahre im Web stehen soll, tut der Entwickler gut daran, keine Annahmen über Browser, Rechner und Monitor des Benutzers zu machen. Sicher, die Auflösungen der Monitore des Desktops werden immer größer, doch gibt es nicht bald den Benutzer, der mit PDA, Palmtop oder Handy das Netz durchstreift?

Oder ist die nächste Killer-Applikation der Browser, der die Webseiten zu einem Quicktime-Movie rendert und sie als Würfel im Kontext ihrer Beziehungen untereinander anzeigt?

Regel 6: Vorsicht mit Flash und Shockwave und anderen Plug-Ins.

Da Flash- und Shockwave-Plug-Ins auf zwei Plattformen von den zwei großen Browsern mitgeliefert werden, veranlaßt dies viele Designer zu dem Glauben, daß der Gebrauch von Flash und/oder Shockwave heute ungestraft möglich sei. Dies ist falsch! Erstens gibt es immer noch relevante Plattformen, auf denen Flash und Shockwave nicht unterstützt wird, zweitens lassen etliche Firmen-Firewalls weder Flash noch Shockwave durch und drittens sind Flash und insbesondere Shockwave-Dateiein so fett, daß sie eine beträchtliche Bandbreitenverschwendung darstellen und lange Ladezeiten verursachen. Viele User brechen den Besuch der Seite deswegen ab.

Flash-Animationen gehören daher - auch wenn es beliebt ist - auf gar keinen Fall auf die Startseite einer Site. Auch nicht, wenn alternativ ein Skip-Intro-Button angeboten wird, der Benutzer ist verärgert. Flash-Animationen gehören (wie übrigens auch PDF-Dokumente) auf tiefer liegende Seiten und der Link dazu sollte einmal sagen, welches Plug-In benötigt wird und dann auch Angaben über die Größe machen. Das gilt analog auch für ähnliche Plug-Ins und Dateien wie Shockwave, QuickTime oder PDF.

Ein Plug-In, auf das man völlig verzichten sollte, ist der Real-Player. Ich habe es bisher nur selten geschafft, diesen Player runterzuladen, ohne vorher entnervt aufzugeben. Plug-Ins, die zum Download persönliche Daten abfragen, einen mit aller Gewalt auf die kostenpflichtige Version lenken oder sonstwie verärgern wollen, gehören von jeder Website verbannt.

Regel 7: Keine Browser- oder Betriebssystem-Weichen

Immer wieder stoße ich auf Seiten, die entweder lieblos gemacht den Inhalt pur ins Netz stellen oder mir gar nur die mehr oder weniger höflich formulierte Behauptung unterstellen: Sie surfen mit einem veralteten Browser. Um diese Seiten optimal lesen zu können, benötigen sie einen Browser der jüngeren Generation. Bitte laden sie Netscape 6 oder Internet Explorer 5 runter und kommen sie dann wieder. Ohne noch einmal darauf zurückzukommen, daß es zwingende Gründe geben kann, einen »veralteten Browser« zu benutzen - ich bin fast nie mit einem veralteten Browser unterwegs. Ich surfe fast immer mit der neuesten Version des iCab, der - obwohl er sich stolz als iCab identifiziert - von der Browserweiche nicht erkannt und daher einfach zu einem veralteten Browser erklärt wird.

Es ist nahezu unmöglich, fehlerfreie Browserweichen zu implementieren, da immer wieder neue Browser auf dem Markt auftauchen, alte verschwinden etc. Man müßte also ständig den Markt beobachten und seine Browserweiche aktualisieren - eine Zeit, die man nicht hat.

Außerdem ist es aufwendig, mehrere Versionen einer Site zu pflegen und zu aktualisieren. Dies hat zur Folge, daß die »alternativen Versionen« in der Regel lieblos mitgeschleppt werden. Das merkt der Benutzer natürlich und ist verstimmt.

Also folgt hieraus meistens die Notwendigkeit, eine Site zu entwerfen, die von allen Clients gelesen werden kann.

Regel 8 - 10: Testen, testen, testen!

Zur Test-Suite eines professionellen Webdesigners gehören folgende Plattformen: Windows (95/98, 2000, NT/XP), Mac (Classic/OS X), Linux und je nach Zielgruppe auch noch Solaris, IRIX und OS/2 (wichtig bei Applikationen für Banker!) Zu testende Browser sind unter Windows der Internet Explorer (immer die aktuelle Version und die mit dem Release-Stand von Windows mitgelieferte, viele Benutzer machen nie eine Update!), Netscape 4.x, Netscape/Mozilla 6 und Opera 5, beim Mac Internet-Explorer 4.x und 5.x, Netscape 3.x, 4.7 und Netscape/Mozilla 6, Opera, iCab und Omniweb, unter Linux Netscape 3.x, 4.x und Mozilla/Netscape 6, Amaya und Lynx. Die anderen Plattformen laufen außerhalb meiner Kompetenz. Leute, die für Banker entwickeln, sollten die verfügbaren Browser für OS/2 kennen.

Fazit: Der wichtigste Browser des Webdesigners ist der Lynx.

Was bleibt ist eine weitere Faustregel: Schauen Sie sich ihre Seiten im Lynx an. Wenn dieser textbasierte Browser (den es übrigens nicht nur für Linux, sondern auch für Windows, Mac und nahezu alle anderen Plattformen gibt) ihre Seiten lesbar anzeigt, dann können Sie ziemlich sicher sein, daß ihre Seiten von allen heutigen Browsern und vermutlich auch von allen zukünftigen Browsern lesbar dargestellt werden.

Ich weiß, daß diese Regeln bei einigen Designern heftigen Widerspruch auslösen werden (ich führe die Diskussion schließlich schon länger). Sie fühlen sich durch solche Regeln in ihrer künstlerischen Freiheit beschränkt. Kein Designer hat je behauptet, daß er in seiner künstlerischen Freiheit beschränkt sei, weil er keine Animation in einem Buch unterbringen kann, Animationen sind dem Medium Buch fremd. Genau so fremd ist dem Medium Web pixelgenaues Design und feste Seitengrößen. Wer dies nicht akzeptieren kann, sollte zum Printmedium oder zur Macromedia Director CD-ROM-Produktion zurückkehren. Aber sich nicht Webdesigner nennen.

Ziel jedes Webdesigns sollte es sein, eine Site für alle und für jeden gut lesbar rüberzubringen: This site is best viewed with any fucking Browser! Schließlich transportiert beinahe jede Website Inhalte, die es zu vermitteln gilt und nicht Design.