Was macht eine gute Webseite aus?

Vorwort

Dies ist zweifellos ein Thema, über das man ausgiebig diskutieren kann. Hier habe ich einmal zusammengestellt, was meiner Ansicht nach dazugehört. Man beachte, daß ich vor allem Erfahrung mit Seiten habe, die nicht bloß spielerischer Selbstzweck sind, sondern vor allem Inhalte (zu gut neudeutsch "Content") rüberbringen sollen – was freilich auf nicht wenige zutreffen dürfte.

Wenn es so rüberkommen sollte, als sei Webauthoring (oft gleichgesetzt mit Webdesign), also das Schreiben von Seiten für das WWW (World Wide Web oder kurz Web), eine sehr diffizile Sache, so würde ich sagen, das kommt sehr drauf an. Gerade am Anfang sollte man seine Erwartungen nicht zu hoch schrauben (das sollte man sowieso nie) – eine einfache Seite genügt ja zunächst, und schließlich kann man auch schon mit wenigen, grundlegenden HTML-Elementen viel anstellen. Der wirklich knifflige Teil sind meines Erachtens nicht etwa die Standards (okay, float hat's doch etwas in sich), sondern ihre Umsetzung in Webbrowsern...

Also, was zeichnet denn nun eine gute Webseite aus? (Wen höre ich da rufen "Na, Tags natürlich! :P"?) (Für alle, die den Witz nicht verstanden haben: HTML = HyperText Markup Language ist eine Textauszeichnungssprache, die Hypertext erlaubt, Text mit Sprungfunktion à la Science-Fiction sozusagen.)

Inhalte

Besucher kommen für gewöhnlich nicht des schicken Seitendesigns wegen, sondern wollen handfeste Inhalte sehen. Eigentlich klar, oder?

Standardkonformität

Es hilft schon mal ungemein, wenn der Webbrowser nicht irgendwelches HTML-ähnliche Zeug mit abstrusen Konstrukten vorgesetzt bekommt (und dann raten muß, was wohl gemeint sein mag), sondern valides (also gültiges / technisch korrektes) (X)HTML und CSS. Sprich: Standardkonform sollte sie sein, die Seite.

Nützlich hierbei:

Bitte beachten Sie: Standardkonformität ist eine notwendige Vorbedingung für eine gute Seite, aber allein nicht ausreichend.

Sinnvolle Textauszeichnung

Dies bedeutet vor allem, (X)HTML-Elemente so zu verwenden, wie es ihre Bedeutung laut jeweiliger (X)HTML-Spezifikation impliziert, d.h. die Semantik sollte (halbwegs) stimmen. Zudem sollte man möglichst umfassend semantisch auszeichnen, halbwegs brauchbare Browserunterstützung für das jeweilige Element einmal vorausgesetzt. (In kritischen Fällen wie IE6/7 und Q kann man sich nötigenfalls noch mit einer CSS-Extrawurst behelfen.) Anregung dazu: HTML4-Elementliste (man beachte die Elemente, die nicht als "deprecated" markiert sind).

Beispiele?

Die Hauptüberschrift einer Seite wäre als H1, mithin Überschrift 1. Ordnung, ausgezeichnet, Unterüberschriften als H2 usw.
Absätze fänden sich in P,
Dinge mit Listencharakter wären selbstverständlich auch entsprechend ausgezeichnet (meist mit ungeordneten Listen UL oder geordneten Listen OL),
Dinge mit tabellarischem Charakter fänden sich in Tabellen, etc.pp.
Betonungen würde man als STRONG oder EM auszeichnen.
Auch das Vorhandensein eines aussagekräftigen Seitentitels im HEAD gehört hierzu.

Viele dieser Dinge erleichtern später auch den Einsatz von CSS.

Nicht ins Markup gehören Dinge, die allein die Darstellung beeinflussen – damit meine ich vor allem Antiquitäten wie FONT, B, U, I und ähnliche Relikte aus Vor-CSS-Zeiten, die mittlerweile durch CSS überflüssig geworden sind.
In Bezug auf HR kann man sich streiten; als Unterteilungsalternative für Non-CSS-Browser ist es zuweilen noch recht praktisch, zumal es mit CSS nicht 1:1 nachgebildet werden kann. (Soweit der O-Ton vor 5 Jahren. Heute wird man es wohl nicht mehr groß vermissen.)

Semantischen Unsinn gilt es zu vermeiden – ein <div class="ueber2"> läßt sich zwar per CSS ebenso handhaben wie ein H2, hat aber sonst keine eigene Bedeutung.
Wenn man einem Element nur eine Klasse bzw. ID zuweisen will, so muß man es dazu nicht in ein DIV wickeln, das geht auch direkt.

Unmengen verschachtelter Tabellen zur Seitengestaltung sind (oder waren anno 2004) eine verbreitete Unsitte aus alten Zeiten, die ebenso die Semantik ad absurdum führt – wenn es sich nicht vermeiden läßt, mit Layout-Tabellen zu arbeiten (viele dieser Exemplare lassen sich ohne weiteres durch Verwendung von CSS in Rente schicken), dann doch bitte in Maßen. Das gilt generell – auch eine undurchschaubare "DIV-Suppe" mit wenig Gehalt an Semantik ist wenig schmackhaft.

Möglichst geringes Datenvolumen

Es ist klar, daß Seiten, die nur so von riesigen Bildern, Flash-Spielereien etc.pp. strotzen, gerade Nutzern von ISDN und Modem wenig Freude bereiten werden. Von daher ist bei solchen Dingen ein Hang zum Minimalismus anzuraten.

Klassische "Bremsen" sind auch von externen Servern eingebundene Inhalte.

Das Optimieren von Bildgrößen ist auch Erfahrungssache und erfordert ggf. einfach etwas Experimentieren mit Formaten (JPEG, GIF oder doch PNG?), Bildgröße und Kompressionseinstellungen.

Erkundigen Sie sich doch mal, ob Ihr Webserver HTML-Seiten auch gzip-komprimiert ausliefert, wenn der Browser es unterstützt (von denen, die behaupten, es zu können, macht dabei eigentlich nur Netscape 4.x Probleme, und den kann man anno 2009 vermutlich vergessen). Schließlich läßt sich Text jeglicher Art ganz hervorragend eindampfen, und auch die z.B. bei Modemverbindungen verwendeten paketbasierten Kompressionsverfahren können gar nicht so effizient arbeiten wie solche, die die ganze Datei berücksichtigen.

Accessibility

Auf gut deutsch: Zugänglichkeit. Ein wahrlich weites Feld.

Fangen wir aber mal bei den Quasi-Binsenweisheiten an: Zu vermittelnde Inhalte und Navigationshilfen haben in unmittelbar zugänglicher Form im Dokument zu stehen. Klingt recht banal, aber so Undinge wie rein in Flash oder Java gehaltene Navigationshilfen oder gar ganz in Flash gehaltene Seiten sind so selten nicht. Die ganz dämliche Variante: Fließtext als Bild eingebunden. Auf Seiten, die sich explizit mit Flash oder Java beschäftigen oder nur damit zu realisieren sind, mag ein weitergehender Einsatz solcher Techniken sinnvoll sein, im Normalfall aber wird man damit allenfalls optionale Spielereien realisieren. Die "durchschnittliche Webseite" sollte auch ohne Browser-Plugins auskommen. Auch Javascript sollte keine zwingende Voraussetzung für die Benutzung der Seite (insbesondere: die Navigation) sein. Wenn die Seite in einem uralten grafischen oder einem Textbrowser vernünftig zu benutzen ist, so ist das schon mal ein gutes Zeichen.
Sinnvolle ALT-Texte für Bilder sind eigentlich so schwer nicht zu finden, wenn man erst einmal weiß, daß der Inhalt des ALT-Attributs dann angezeigt wird, wenn das betreffende Bild nicht dargestellt werden kann (ALTernativtext eben) und ein Bild mit rein schmückender Funktion am besten einen leeren ALT-Text erhält.
- Zusammenstellung zum Thema ALT-Texte von Christoph Päper
- Ausführungen von Björn Höhrmann zu ALT-Texten
Vorsicht bei Sonderzeichen in URLs. Nicht funktionierende Links und nicht dargestellte Bilder müssen nun wirklich nicht sein, darum sollte man "&" in jeglichen Pfaden immer als "&" maskieren. Auf Umlaute und desgleichen in Datei- und Verzeichnisnamen besser verzichten.
Browserweichen (Tut uns leid, aber mit ihrem Browser kommen Sie hier nicht rein! Und dann auch noch ohne gepunktete Krawatte!) sind von gestern und haben auf keiner modernen Webseite etwas verloren!
Etwas Mogelei beim CSS (und nur dort) läßt sich leider u.U. nicht ganz vermeiden, aber das ist grundsätzlich nicht so schwierig – siehe Kompatibilität.
Frames sind auch so was historisches. Die sollte man besser vermeiden, wo immer es geht.
Michael Nahrath hat einiges über die Problematik von Frames zusammengetragen.
Formulare haben auch so ihre Tücken in Sachen Accessibility. Weiteres hierzu erfährt man im Tutorial "Bessere Formulare" bei "Einfach für Alle". (Das war anno 2003, als ich den Link gesetzt habe, mal ein recht kompakter Artikel, der aber wohl später deutlich gewachsen ist und damit leider an Einsteiger-Tauglichkeit eingebüßt hat.)

Usability

Auf gut deutsch: Benutzbarkeit/Bedienbarkeit. Ein Thema, das für manch kontroverse Diskussion gut ist und mit dem sich Jakob Nielsen seit Jahren beschäftigt. In der Tat ist die Bedienbarkeit einer Website eine Sache für sich:

Übersichtlichkeit ist Trumpf – nichts ist schlimmer als eine mit tausenderlei verschiedenen Inhalten vollgestopfte, verwirrend unübersichtliche Seite, wie man sie "da draußen"[tm] leider recht oft findet. (Übrigens durchaus auch unter denen, die sonst Standardkonformität etc.pp. predigen – es ist eben nicht immer alles beisammen.) Auch im WWW gilt also oft "Weniger ist mehr".
Navigation ist teilweise Geschmackssache – mancher bindet überall ein Navigations"menü" ein, anderswo kann man sich über "Brotkrumen" (breadcrumbs) zu einer höheren Ebene hangeln, wo dann ein Inhaltsverzeichnis weiterhilft. Geht alles, Hauptsache keine Sackgassen, also Seiten, die einsam und allein unverlinkt in den Weiten des Netzes stehen. Wer solcherlei über eine Suchmaschine findet, wird wenig beglückt sein. Wer Nutzern von Text- und modernen grafischen Browsern helfen will, sollte sich das Element LINK einmal näher ansehen.
Wenn die Seite mal wieder länger wird, so ist es sinnvoll, eine Art Inhaltsverzeichnis anzulegen, über das die einzelnen Abschnitte zu erreichen sind. Ob man hierbei eher auf klassische Sprungziele (<a name="...">) oder neumodischere IDs verlinkt, ist Ansichtssache – erstere werden auch von ~~älteren~~richtig alten Browsern bis einschließlich Netscape 4.x unterstützt.
Auch die Farbwahl ist eine recht subjektive Sache (der eine verwendet Farben rein sachlich zur Unterstreichung des Markups, der andere meint, daß es auch noch schön aussehen solle), aber einige grundsätzliche Dinge lassen sich durchaus sagen: Schräge, grelle Farben, die die Farbwahrnehmung merklich stören, sind deutlich fehl am Platz – bewährt haben sich eher Pastelltöne. Zudem ist dunkle Schrift am hellem Hintergrund i.d.R. besser zu lesen als das umgekehrte. (Es sei denn, der Nutzer sitzt vor einem flimmrigen Röhrenmonitor, dann ist invers in der Tat augenschonender.) Man achte auf gute Kontraste!
Skalierung: Dies ist ein Punkt, der mir besonders am Herzen liegt. Schriftgrößen sind, wenn überhaupt, tunlichst so anzugeben, daß sie mit der Standardschriftgröße des Besuchers skalieren, z.B. in em, ausgehend von 1em für gewöhnlichen Fließtext. Wer unbedingt aus Rücksicht auf Netscape 4.x oder ähnliche Antiquitäten mit px arbeiten will, sollte doch bitte neueren Brausen per @import ein Stylesheet mit zeitgemäßerer Einheitenwahl vorsetzen – es gibt immer noch so Browser wie IE6, die px nicht skalieren. Wer große Schrift als häßlich empfindet, möge doch bitte die Schriftgröße in seinem Browser heruntersetzen und das ästhetische Empfinden den Besuchern überlassen, denen lesbare Schrift im Zweifelsfall wichtiger ist. Spätestens dann, wenn alles auf die Mindestgröße aufgezogen werden muß, ist es nämlich sowieso vorbei mit der Ästhetik. Auch die Voraussetzung einer minimalen Seitenbreite in Pixeln ist selten eine gute Idee. (Und wer so eine maximale Seitenbreite vorgibt, bei dem werden sich die Besucher mit etwas größerer Schrift über Absätze in Zeitungsspaltenbreite ärgern.) Ebenso sollte man darauf achten, daß eine Änderung der Schriftgröße nicht das langwierig erarbeitete Layout "zerschießt", Positionierungen etwa sollten also passend mitskalieren.
Das Web ist kein Medium für pickel-, äh, pixelgenaues Arbeiten. (Wer im Print-Bereich groß geworden ist, mag damit ganz und gar nicht glücklich sein, aber so ist das halt.) Dafür können (X)HTML-Seiten aber exzellent skalieren, wenn man sie nur läßt, was ganz neue Möglichkeiten eröffnen kann, wenn man's richtig anstellt und die lieben Browserlein ihren kooperativen Tag haben. (*seufz*) Die Darstellung muß ja nicht überall absolut identisch sein – der Benutzer hat i.d.R. eh keine Vergleichsmöglichkeit –, Hauptsache sie ist überall halbwegs gut. Moderne Browser eröffnen hier zusätzliche Möglichkeiten durch Unterstützung von CSS3-Media-Queries.
Typographie: Verglichen mit Printmedien ist die Zeilenhöhe und damit insbesondere der Abstand zwischen Zeilen bei der Darstellung am Rechner oft zu klein, den darf man daher etwas hochsetzen (die line-height auf meinen Seiten etwa ist im Laufe der Jahre von ursprünglich 1em auf 1.3em, dann 1.4em und schließlich 1.6em gestiegen, um nunmehr abhängig von der für Fließtext zur Verfügung stehenden Breite zwischen 1.3em und 2em zu rangieren.) Bei nominell gleicher Größe sind Schriftarten ohne Serifen oft besser lesbar – logisch, zum einen nehmen die Serifen ja auch etwas Platz ein und zum anderen scheint auch die Proportionierung von explizit für Bildschirmdarstellung entwickelten Schriften anders.
Wenn man seinen Besuchern noch mehr Gutes tun will, so mag man die Breite von Fließtext auf ca. 40..50em beschränken wollen (über die CSS-Eigenschaft max-width), der Ergonomie wegen – sehr lange Zeilen sind schwerer zu erfassen (ebenso wie sehr kurze übrigens). Dabei gibt es auch noch einen Zusammenhang mit der Zeilenhöhe – je länger die Zeilen, desto mehr Höhe sollte man für optimale Orientierung spendieren. Das geht allerdings nur in gewissen Grenzen, jenseits der 2em sieht es dann doch etwas merkwürdig aus, so daß hier derzeit maximal 70em effektive Breite bei 2em Zeilenhöhe zugelassen werden, wobei die Höhe bei weniger breiten Anzeigeflächen schrittweise schrumpft.
Eine wirklich gut gemachte Seite würde außerdem noch auf typographisch "richtige" Anführungszeichen, Gedankenstriche etc.pp. achten, ich bin da bloß zu faul. ;)
Typographie für Webautoren von Christoph Päper behandelt das Thema recht ausführlich.
Sinnvolle Links: "Klicken Sie doch mal hier." Sehr aussagekräftig, wie? Da ist "Zur Hauptseite" doch um einiges besser. Auch nicht sehr nutzerfreundlich: Navigation über verlinkte unbeschriftete Bilder ("mystery meat navigation"), bei denen ein Besucher oft nicht weiß, was sie wohl darstellen mögen.
Hinweise der dciwam-Checkliste zum Thema Hyperlinks
Nette Effekte, wie durch Einsatz der Pseudoklasse :hover erreichbar, sollte man in Maßen einsetzen. Ich würde etwa nicht empfehlen, damit ganze Absätze umzufärben, das ergibt beim Lesen und Scrollen ein ziemlich nerviges Geflacker, das die Konzentration auf die Inhalte stark stören kann. (Epileptiker wären damit sicher noch weniger glücklich.) Bei Bedarf aufklappende Navigationsmenüs (Indikatoren anzeigen mit :before/:after) oder kleine Gimmicks sind aber durchaus machbar.
...und ohne CSS? Ob man seine Seiten sinnvoll strukturiert hat, sieht man recht gut in einem Browser ohne CSS-Support.

Kompatibilität

Grau ist alle Theorie, wenn die an sich technisch korrekt umgesetzte Seite in irgendeinem Browser total zerschossen aussieht oder gar unbenutzbar wird. Hier hat sich zum Glück im Vergleich zu 2003/2004 vieles verbessert, weil die entsprechenden verbugten Browser-Antiquitäten wie Internet Explorer 3 für Win95/NT und Mac und Netscape 4.x schlicht ausgestorben sind. Inzwischen ist das noch verbreitetste Browserfossil mit deutlichen Macken (gemessen an den strikter gewordenen Standards) der Internet Explorer 6.0, welchen unter den Webdesignern mancher schon seit geraumer Zeit gern zu Grabe getragen sähe (das nötige Feintuning – wenn es denn dabei bleibt – ist nicht selten unbezahlte Mehrarbeit).

Eine Übersicht der CSS-Browserunterstützung sollte man schon zur Hand haben.

Um größere Unfälle in älteren, noch nicht so recht standardkonformen Browsern zu verhindern, gibt es ein paar Tricks:

Der mittlerweile wirklich uralte Netscape 4.x versteht keine @ rules, ist also leicht z.B. mit @media und damit effektiv verstecktem Styling (bei sinnvoll gewähltem Markup sollte eine Seite ja schließlich auch ganz ohne CSS halbwegs benutzbar sein) vor einem Schluckauf zu bewahren, und dem IE 6 und 7 kann man leicht per "conditional comment" ein zusätzliches Stylesheet vorsetzen, das problematische Formatierungsregeln (so führt z.B. die Anwendung von em beim IE6 zuweilen zu absurden Ergebnissen) mit leichter verdaulichen überschreibt und etwa den Inhalt des Elements Q (welches der IE bis einschließlich Version 7 nicht so unterstützt wie in HTML 4.01 vorgesehen) durch Kursivschrift hervorhebt.

Wie bereits erwähnt, eine Seite muß nicht überall gleich aussehen, aber (grundsätzlich) funktionieren.

Meine Standard-Testbrowser:

Die standardkonformen:: Gerade aktuelle Versionen von Firefox und Seamonkey (damit hat man derzeit Gecko 1.9, 1.9.1 und 1.8.1 erschlagen), Opera und (womit wir zur Webkit-Runde kämen) Safari oder Google Chrome
Die Extrawurst-Kandidaten: Internet Explorer 6.0 und 7.0
Der Textbrowser: Lynx 2.8.6 (irgendein Win32-Build); schlechte ALT-Texte lassen sich damit in nullkommanix entlarven

Hilfreiche Links

Generelles zur Gestaltung

Es ist zweifelsohne von Vorteil, wenn eine Webseite auf media="screen, projection" halbwegs ansehnlich daherkommt. Da ist Kreativität gefragt (ein Feld, auf dem ich immer schon eine ziemliche Niete war, von daher geht's hier i.allg. eher schlicht zu...), nicht nur im grafischen Bereich, auch angesichts der Restriktionen seitens des Datenvolumens.

Wenn eine Seite sich für das Ausdrucken anbieten mag, so kann ein kleines Print-Stylesheet nicht schaden – und da darf und sollte man mit medienspezifischen Einheiten wie pt arbeiten.

Wer sich schwerpunktmäßig an blinde Nutzer richtet, mag es für sinnvoll erachten, ein Voice-Stylesheet bereitzustellen. (Da muß ich zugeben, mich damit noch nicht wirklich beschäftigt zu haben.) Ähnliches gilt für Seiten, die vornehmlich für Benutzer von Organizern und ähnlichen mobilen Geräten mit eher kleinem Display gedacht sind, nur eben in diesem Fall für media="handheld".

Auch wenn man seine Seiten nicht speziell für bestimmte Benutzergruppen optimiert hat, etwa wie erwähnt mit entsprechenden Stylesheets, so hilft schon gut gewähltes Markup, denn ein Browserhersteller sollte sich bei der Interpretation völlig ungestylten Markups schon etwas gedacht haben. (Womit wir wieder beim Punkt "Sinnvolle Textauszeichnung" wären.)

Stilistisches

Übersichtlicher Quelltext zahlt sich aus – nichts ist schlimmer als ein übles HTML-Gewusel, in dem man nichts findet. Wie genau man diese Übersichtlichkeit nun herstellt, bleibt jedem selbst überlassen – recht oft findet man Einrückungen um ein paar Zeichen pro Verschachtelungsebene, auch ein Editor mit Syntax-Highlighting hilft.

Womit man anfängt, wenn man eine neue Seite gestaltet, ist Geschmackssache – ich zumindest bevorzuge den Ansatz "Erst Inhalt, dann optische Gestaltung". Wenn man bereits ein etabliertes Stylesheet hat, ist die Sache gar simpel hoch 3 – da braucht man nur das Stylesheet einzubinden und fröhlich am Inhalt zu basteln. (Ich nehme das freilich auch gern als Anlaß, mal wieder am Styling zu drehen.) Ein "Content first"-Ansatz hat auch den Vorteil, daß man erst mal die gestalterischen Möglichkeiten mit den semantisch relevanten Tags erkunden kann und erst nötigenfalls an sich bedeutungslose Dinge wie DIV einsetzen muß. Wer eher von der visuellen Schiene kommt, mag mit dem Layout anfangen wollen, das setzt aber zumindest eine Planung der Inhaltstypen voraus.