Bessere Qualität durch Tabus

Artikel vom 29. April 2006. ISSN 1614-3124, #22. Schwerpunkt: Methodik (RSS-Feed für alle Themen).

Wo wir gerade dabei sind, hier ist ein kleines Büchlein nur über die Qualitätssicherung von Websites: The Little Book of Website Quality Control.

»Tabus« können ein Hilfsmittel sein, um übermäßigem Pragmatismus vorzubeugen und die Qualität von Produkten auf einfache Art zu halten und zu steigern. Sie beziehen sich in diesem Artikel vor allem auf Online-Informationsangebote, also Websites. Die Idee von expliziten Tabus ergab sich in der Praxis anhand von leider häufig fehlenden Grenzen, grundlegenden Maßnahmen, um hochwertige Ergebnisse zu erzielen. Das Konzept konnte ich jüngst in Gesprächen mit Timo Wirth und Heike Edinger in knapper Form diskutieren und überdenken.

Was sind Tabus?

Wikipedia sagt (getreu Meyers Konversationslexikon von 1897):

Tabu (tapu), nach einem aus der Sprache der Südseeinsulaner (Tonga) herrührenden Wort, heißt so viel wie unverletzlich. Das Wort hat im 20. Jahrhundert Eingang in die deutsche Sprache gefunden und bezeichnet eine Handlung oder Verhaltensweise, die durch Sitte oder Gesetz verboten ist.

Wie können Tabus der Qualität dienen?

Beim Entwerfen und Entwickeln von Informationsangeboten stellen Tabus gewissermaßen das Gegenstück zu üblichen Regeln für »gute« Websites dar. Sie sind in ihrer Zielsetzung als Teilmenge vom bestmöglichen Ergebnis zu verstehen, können und sollen also kein Ersatz für bestehende, bewährte Prinzipien, Regeln und Maßnahmen sein. Das Tabu-Konzept darf dabei nicht dazu führen, dass sich auf ihnen »ausgeruht« wird, sondern soll einfach Rahmen und Basis für die Arbeit festlegen.

Beispiel:

Der Code aller Dokumente und Stylesheets muss validieren.

Ein entsprechendes Tabu:

Es wird kein Dokument oder Stylesheet veröffentlicht, dessen Code nicht validiert.

Dies ist recht einfach, aber der Nutzen des Tabus deshalb vielleicht noch nicht so deutlich. In einer Organisation gilt möglicherweise eher (wenn überhaupt):

Der Code aller Dokumente und Stylesheets sollte validieren.

Diese Regel ist schwach, und durch ein Tabu kann sie erheblich gestärkt werden, denn: Tabus wirken oft verbindlicher als Regeln. Das ist als Grundgedanke zu verstehen.

Analog zu bestimmten Grundregeln und Prinzipien muss in der Praxis aber auch in der gesamten Organisation (zumindest den betroffenen Abteilungen) Konsens über selbige bestehen. Tabus müssen von der Organisation getragen werden. Andernfalls besteht die Gefahr von Ab- und Aufweichungen: »Dieses Projekt ist eh nicht lange online, da macht es nichts, wenn ein paar Benutzer nicht darauf zugreifen können.« Wurde ein Tabu definiert, kommuniziert und wird es vor allem »von oben« getragen, kann eine solche »Argumentation« ausgehebelt werden; das Projekt geht bei Tabubruch nicht online.

Anwendung und Beispiele

Tabus sollen nicht dazu dienen, Innovation und Verbesserungen zu hemmen. Ganz im Gegenteil, sie sollen das Fundament für diese legen. Sie können auch so verstanden werden, dass sie einen wie beim Bergsteigen absichern – wird ein neuer Vorsprung erreicht, wird gesichert. Sind Papierprototypen erstmal etabliert, werden sie Pflicht, und ihr Auslassen damit ein Tabu.

Tabus dürfen aber auch nur innerhalb der bestehenden Möglichkeiten definiert werden. Wenn kein Know-How für Barrierefreiheit vorliegt, bringt ein Tabu à la »ohne WCAG-AAA-Konformität geht nichts online« schlichtweg nichts und kann sogar kontraproduktiv sein, da es schon bei der ersten Gelegenheit gebrochen wird. Zwangsläufig.

Beispiele unterschiedlich anwendbarer und unterschiedlich streng definierter Tabus:

• »Kein Meeting ohne Zielsetzung.«
• »Kein Projektbeginn, wenn kein Nutzen für den Benutzer erkennbar ist.«
• »Kein Projektbeginn ohne Konzept.«
• »Kein Konzept ohne definierte Erfolgskriterien (Metriken).«
• »Keine Designfreigabe bei Problemen mit Kontrast oder Farbenblindheit.«
• »Keine Projektfreigabe ohne n Tage oder Wochen Testphase.«
• »Kein Online-Gang ohne mindestens n Nutzertest(s).«
• »Kein Online-Gang, wenn der zugrundeliegende Code nicht validiert.«
• »Keine Multimedia- ohne Alternativ-Inhalte.«
• »Keine präsentationsbezogenen Attribute (HTML).«
• »Kein Online-Gang ohne Code-Review.«
• »Keine ›schwarze‹ Suchmaschinenoptimierung (Cloaking, eingekaufter Traffic, …).«
• »Keine als regulärer Inhalt getarnte Werbung.«
• (Ihre eigenen Tabus hier.)

»Kein« heißt dabei auch wirklich »kein«, oder auch »niemals«, »gar nicht«, »überhaupt nicht«, »wirklich nicht«, »nein«.

Vor- und Nachteile

Während die Grundidee hinter Tabus bei der Arbeit an Informationsangeboten also einfach aussagt, »definiere Grenzen, und breche sie niemals«, sollte man nochmal auf ihr Profil achten:

Vorteile von Tabus

• Schneller zu definieren und verbindlicher als Regeln;
• aufgrund des einfachen Charakters eher geeignet, Konsens zu erzielen;
• strikter und unmissverständlicher in der Interpretation (sofern nicht »überdefiniert«);
• leicht und nachdrücklich kommunizierbar.

Nachteile von Tabus

• Erfordern unbedingten Konsens bei Betroffenen, um nicht unterminiert zu werden;
• alleine nicht ausreichend, da zum Beispiel »kein invalider Code« nicht »semantischer, valider, barrierefreier Code mit Zucker obendrauf« bedeutet.

Sofern sie verstanden werden und sich ihrer angenommen wird, wiegen die Nachteile von Tabus niemals schwerer als ihre Vorteile. Zudem verwenden viele professionelle Webdesigner und -entwickler sie bereits, vielleicht in Form »ungeschriebener Gesetze«, möglicher- und beispielsweise mit dem Anspruch, keinen invaliden Code zu veröffentlichen. Ebenso, wie Ein-Mann-Organisationen von wohldefinierten Tabus profitieren können, können dies auch multinationale Konzerne. Zumindest diejenigen, die dort unsere Profession vertreten.

Über mich

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)