Bei red@ktiv sind wir zwischenzeitlich dazu übergegangen, an uns herangetragene Projekte gegen folgende OpenSource-Lösungen zu prüfen:

• Typo3: ein sehr mächtiges Content-Management-System, das mit TypoScript fast eine eigene Programmiersprache mitbringt. Ist die Einrichtung einer Präsenz mit der Festlegung von Templates, Funktionen und Gestaltung erst einmal erfolgt, wird man jedoch mit einem leistungsfähigen Tool belohnt, mit dem man dennoch Kunden nach kurzer Einarbeitung guten Gewissens bei der Pflege ihrer Seiten weitgehend alleine lassen kann. Insbesondere die Möglichkeit mehrere Sprachvarianten einer Seite zu haben ist ein schlagendes Argument pro Typo3. Vorgehende Versuche ähnliches mit Mambo zu realisieren endeten in einem ziemlichen Desaster, so daß wir davon komplett abgekommen sind. Auch wenn die Einrichtung und Verwaltung unter Mambo sehr viel einfacher und oft genug auch ausreichend wäre, greifen wir auch für kleinere Projekte bevorzugt auf Typo3 zurück.
• WordPress: Blog-Systeme sind nach wie vor en vogue und für kleine, private Webseiten ein gutes Mittel der Wahl um aktuelle Begebenheiten zu erfassen und zu publizieren. Darüberhinaus können Blogs eine wichtige Begleitmusik in Sachen Suchmaschinenoptimierung spielen. Aktualität ein wichtiges Kriterium für das Ranking bei Suchmaschinen. Und einfacher als mit einem Blog lassen sich aktuelle Dinge kaum erfassen. Über ein gut ausgebautes System von PlugIns lassen sich leicht zusätzliche Funktionen in WordPress implementieren.
• xt:Commerce: auch wenn das Vertriebskonzept mit kostenpflichtiger Zwangsmitgliedschaft im Supportforum der Hauptentwickler mit dem Opensoure-Gedanken in krassem Widerspruch steht und etliches am HTML- und CSS-Code von xtCommerce ziemlich krank ist – es ist das Mittel der Wahl, wenn es um einen guten Webshop geht! Sowohl funktional als auch gestalterisch (wenn man denn die elementarsten Fehler mal gerade gerückt hat) bietet xt-Commerce eine exzellente Basis für eCommerce Anwendungen. Wie auch bei Typo3 ist die Möglichkeit mehrere Sprachvarianten zu verwalten sehr ausgeprägt und für ein Online-Business geradezu elementar. Über das smarty-System das für die Generierung der Templates verantwortlich ist, kann man zu dem die Gestaltung der Seiten sehr gut anpassen und in valides XHTML überführen, so daß ein gute Grundlage für die Gestaltung mit CSS besteht. Die in der Szene gehandelten oder bereitgestellten total veralteten Tabellenlayout-Konstrukte, die mit i
• phpiCalender/phpMyCal: wenn es um die Erfassung und Verwaltung von Terminen geht kann es nur eine Wahl gegen – ein System das den iCal-Standard unterstützt. phpiCalendar tut dies vorbildlich. In Zusammenarbeit mit phpMyCal entsteht noch ein Webfrontend über das Termine zu erfassen und zu pflegen sind. Leider ist phpMyCal derzeit vom Netz verschwunden, so daß wir hier eine von Relate Me >bereitgestellte Version, die wir auf Standalone-Betrieb rückentwickelt haben, nach den Regeln der GPL zum Download einstellen.

Modifizierte Version von phpiCalendar mit phpMyCal-Extension

Wie man an den aufgeführten Beispielen unschwer erkennen kann: es bleibt in allen Fällen genügend Arbeit übrig um die “fertigen” System passend für die Kundenanforderunge zu modifizieren. Durch die Offenheit des Quelltextes ist es uns jedoch leicht möglich zusätzliche Funktionaliäten oder kundenspezifische Änderungen zu erstellen. Der Fall, das eine OpenSource-Software out-of-the-box die Anforderungen des Kunden erfüllt ist höchst selten. Mindestens die Identifikation und Installation von PlugIns gehört zum Standardrepertoire. Im nächsten Schritt steht dann die Entwicklung eigner Erweiterungen. Erst wenn die Anforderungen soweit vom Grundsystem abweichen, das schon die Umprogrammierung und -konfigurierung des Grundsystems einer kompletten Neuentwicklung gleich kommt, greift noch “Plan B” und wir entwickeln Dinge von Grund auf neu und kundenspezifisch.

Beim Gestalten tabellenfreier Websites sind viele Dinge zu beachten: Das Box-Modell, mysteriöse 3-Pixel große Abstände, relative Schriftgrößen, kaskadierende Stilregeln, Textumfluß … aber nichts davon ist wirklich wichtig. Beim Entwurf einer Website sollte man an all das nicht denken.

Wenn es an die Gestaltung von Websites geht, sind reine Grafikdesigner mit Unwissenheit gesegnet. Sie müssen nicht vorausdenken, wie ihr Design umzusetzen ist. Sie müssen sich keine Gedanken machen, wie ein Fußbereich auf einer Seite konstant unten fixiert wird. Und genau so
sollten es WebDesigner machen.

Standard-basiertes WebDesign steckt noch in den Kinderschuhen. Überall findet man Tutorials über die Erstellung von Webseiten in XHMTL/CSS und jeden Tag entsteht eine neue Technik in diesem Bereich. Ohne fortschrittliches Design, ohne die Freiheit mal nicht über die Umsetzung nachzudenken, würde niemand die Grenzen der Webstandards verschieben. Möglicherweise wären sie in dem Moment
verschwunden, wenn jemand die Frage stellte »Wie schaffe ich es, daß zwei Spalten immer gleich lang sind?«.

Beim Design geht es nicht um die Werkzeuge, es soll dem Anwender das bestmögliche Erlebnis vermitteln. Ein Design sollte auf Benutzbarkeit (usability), Zugänglichkeit (accesibility) und Ästhetik beruhen, aber niemals auf Umflüssen, Listen oder Hintergrundbildern.

Wenn ich)* beginne, eine Website zu entwerfen, ist es ein rein graphischer Ansatz. Photoshop und Illustrator allein bestimmen die Grenzen. Innerhalb dieser Grenzen kann ich ein fünfspaltiges Layout mit fixiertem Fußbereich, Drop-Down-Menüs und freischwebender Farbauswahl für die Schrift erschaffen. Egal ob ich das umsetzen kann – das ist, was ich gerne sehen würde.

Dann, … danach geht es an die Lösung der Probleme. Es ist die analytische Seite des WebDesign, bei der uns WebDesignern das Wasser im Mund zusammenläuft, die uns teilweise zu Turing, teilweise zu Picasso (zumindest ein bischen) macht. Natürlich dürfte es ruhig machmal etwas einfacher sein, die Lösung für das Layout zu finden, Aber ich genieße die Herausforderung und stelle mich allem, was da kommt.

Das Ziel der Web-Standards ist es, unsichtbar zu sein. Sie dürfen nichts anderes hervorbringen als Tabellenlayouts oder jeder andere Tag-Sumpf. Es ist also unsere Pflicht, gut zu designen und uns erst
später um die Standards zu kümmern.

* ich = “The Man in Blue”, AKA Cameron Adams. Aber wir arbeiten da genauso…

(Übersetzt von The Man in Blue
Dort an ein Gespräch mit der Web Standards Group angelehnt.)

Was kann an Webdesign elastisch sein?

Gemeint ist, das eine Seite unabhängig von der Fenstergröße oder der Bildschirmauflösung für den Betrachter benutzbar bleibt. Inspiriert durch die Artikel Sliding Doors of CSS und Elastic Design entstand für die red@ktiv-Seite ein entsprechendes Layout.

Zunächst gilt es das Font-Size Problem zu lösen. Während Mac und Linux Browser i.d.R. eine Auflösung von 72 dpi (dot per inch = Pixel pro Zoll) nutzen, sind Windows Browser i.d.R. auf 96 dpi eingestellt. Wie immer, so auch hier: keine Regel ohne Ausnahme. Aber egal wie ihr Browser eingestellt ist: Bei Schriftgrößen, die über die Einheit »Punkt« definiert werden, kommt es zum Problem, das eine mittlere Schriftgröße auf 72 dpi für den 96 dpi-Browser zu groß erscheint und umgekehrt eine mittlere Schriftgröße für 96 dpi bei 72 dpi-Browsern zu Augenpulver wird. Ein erster Ansatz »Pixel« (px) als Einheit zu wählen (10 px sind und bleiben 10 px, egal wieviele davon auf einem Zoll untergebracht werden, die Schriften erscheinen also überall gleich groß) stellt sich schnell als unbrauchbar heraus, weil damit die Skalierung der Schrift durch den Benutzer unterbunden wird. Genau diese Bevormundung steht dem Anspruch einer »universellen Zugänglichkeit« aber im Weg. Man denke nur an Menschen mit eingeschränkter Sehfähigkeit, die auf die Vergrößerung der Schrift angewiesen sind. Abhilfe schafft die Verwendung der Einheit »em«. »em« steht dabei für »Elementeinheit«. 1 em entspricht dabei 100 % der im Browser voreingestellten Standardschriftgröße. Diese kann der Benutzer global in den Voreinstellungen seines Browsers anpassen; oder auch je Fenster individuell über entsprechende Vergrößerungs-/Verkleinerungs-Tasten oder -Menüeinträge in seinem Browser. Damit ist ein erster Schritt zum »elastischem Design« getan.

Der zweite wesentliche und konsequente Schritt besteht nun darin, die Einheit »em« auf weitere Seitenelemente zu übertragen. Arbeitet man CSS nach dem Box-Modell ab, besteht eine Seite letztlich immer aus neben-, über- und ineinander gestapelten Rechtecken (Boxes). Diese Boxes wiederum sind durch einige Attribute beschrieben – z.B. die Beschaffenheit des Hintergrunds (Farbe, eingebundenes Bild, das ggf. wiederholt wird), Beschaffenheit des Rahmens (Dicke, Farbe, Strichelung), der Abstand des enthaltenen Textes zum äußeren Rahmen (padding) und der Randabstand der Box zu benachbarten Elementen (margin). Wendet man nun auf alle Größenangaben die eine solche Box beschreiben wiederum die Einheit »em« an, so werden auch diese Elemente anhand der Browservorgaben skaliert.

Als dritter – schon etwas anspruchsvollerer – Schritt kommt noch die Anwendung der Einheit »em« auf Bilder dazu. Anstatt der üblichen Höhen- und Breitenangaben in Pixeln (px) erfolgt auch hier die Angabe in »em«. Dabei ist darauf zu achten, das durch die Verwendung das Seitenverhältnis des Bildes gewahrt bleibt. Letztlich eine einfache Dreisatzrechnung um die vorhandene Pixelgröße in em zu übertragen. Idealerweise sollten daher Bilder verarbeitet werden, die über ein fixes Seitenverhältnis verfügen (4:3 oder 16:9 oder quadratisch). Damit können CSS-Klassen auf das jeweilige Verhältnis in Hoch- und Querformat beschränkt werden. Desweiteren müssen die Bilder in einer etwas höheren Qualitätsstufe als ansonsten üblich vorliegen, da diese ja vergrößert werden können und dann immer noch scharf sein sollten. Wahlweise kann dies über eine niedrigere Kompressionsrate bei .jpgs oder über ein größeres Format (mehr Pixel) erfolgen. Die Möglichkeiten muß man abhängig vom Motiv durchprobieren, ein Patentrezept für einen Kompromiß aus bestmöglicher Darstellungsqualität und kleiner Dateigröße (für schnelle Ladezeiten) gibt es leider nicht.

Im Ergebnis ergibt sich dann eine Webseite, die komplett »mitwächst« wenn die Darstellung vergrößert oder verkleinert wird. Die Proportionen innerhalb der Seite von Textgrößen zueinander, Bild zu Text und Gestaltungsmerkmale des Layouts bleiben – unabhängig von der eingestellten Darstellungsgröße – weitestgehend erhalten. Weitestgehend deshalb, weil »ems« mit »nur« einer Stelle hinter dem Komma zuverlässig anzugeben sind. Durch Rundungsfehler beim Skalieren können dann einzelne geringere Abweichungen entstehen.

Wird das CSS komplett abgeschaltet (z.B. durch alternative Darstellungsgeräte, wie Screenreader, Brailledisplays oder auch durch reine Textbrowser) bleibt der Inhalt komplett zugänglich. Durch eine durchdachte Struktur z.B. bei der Anordnung von Links zur Navigation innerhalb der Seite wird zudem auch bei nicht vorhandenem CSS eine gute Nutzbarkeit (Usability) sichergestellt.

Wir diskutieren mit einigen Kollegen. Und immer wieder mit welchen, die glauben an dieser Stelle die Statistiken auf ihrer Seite zu haben. Über den Verbreitungsgrad dieses oder jenes Betriebssystems, des Browsers XYZ, die Bildschirmauflösung 08/15 und des Sowieso-PlugIns.

Ok, reden wir über Statistik:

Blenden wir die auch in diesem Fall völlig richtige Weisheit Winston Churchills Man kann nur einer Statistik trauen, die man selbst gefälscht hat einmal komplett aus. Versuchen wir einfach den höchstmöglichen Verbreitungsgrad für die häufigst unterstellte Umgebung zu errechnen:

• aktueller Internet Explorer (ab Version 5 und neuer)
• unter Windows (wir nehmen alles mit: 3.x, 95, 98, ME, 2000, NT, XP)
• bei einer Bildschirmauflösung von mindestens 1024 x 768 Pixeln
• mit installiertem Macromedia Flash-PlugIn, wahlweise aktiviertem JavaScript

Unterstellen wir Windows einen Marktanteil von 90% (genaue Zahlen für Desktop Betriebssysteme sind leider nirgends zu bekommen – wahrscheinlich aus gutem Grund nicht mal von Microsoft selbst). Auch für die Browserverteilung gehen wir von 90% aus . Ebenso nehmen wir für Bildschirmauflösungen von 1024 x 768 und höher einen Verbreitungsgrad von 90% an. Bei der Auswahl zwischen Pest und Cholera Flash und JavaScript entscheiden wir uns für Flash und übernehmen die 97% Verbreitungsgrad die Macromedia von sich selbst behauptet.

Jetzt wird’s spannend

Nach einfachen Rechenregeln und der Annahme einer statistischen Normalverteilung macht das: 0,9 * 0,9 * 0,9 * 0,97 = 0,70713 oder großzügig gerundet: 71%! Nochmal: sämtliche Basiszahlen sind mit hoher Unsicherheit behaftet. Aber selbst wenn man einen »Sicherheitsaufschlag« dazu nähme und mit 0,95 * 0,95 * 0,95 * 0,99 rechnete, würden »nur« knappe 85% herauskommen. Das Szenario das eintritt, wenn die Zahlen schlechter sein sollten, mag sich jeder selbst ausmalen.

Sind 85% viel?

Nein, es sind glatte 15%, die an vollständiger Zugänglichkeit fehlen. Mal ehrlich: welcher klug rechnende Geschäftsmann kann es sich heutzutage leisten auf 15 oder gar 30% seiner potentiellen Kundschaft, seiner Umsätze, seiner Gewinne zu verzichten? Die Antwort ist ebenso einfach wie die Lösung für das oben beschriebene Dilemma: Verlangen Sie als Kunde von ihrem WebDesigner Seiten die auf allen Browsern, auf allen Betriebssystemen, bei allen Bildschirmauflösungen – richtiger sogar auf allen Ausgabegeräten, es gibt mehr als nur optische Ausgabegeräte! – mit allen Systemumgebungen funktionieren. Nicht auf einigen. Nicht auf den meisten. Auf allen! Der Aufwand für solche Seiten ist nicht größer als für das was die »optimiert für«-Fraktion abliefert.