Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Operas MAMA-Studie: Die durchschnittliche Webseite validiert nicht

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Operas MAMA-Studie: Die durchschnittliche Webseite validiert nicht

Das Ergebnis von Operas MAMA-Studie - gerade mal 4% der Seiten validieren - hat für große Aufregung in der Webstandards-Gemeinde gesorgt. Sylvia Egger hat genauer hingesehen.

Das Ergebnis von Operas MAMA-Studie, dass nur 4,13% der untersuchten URLs – immerhin ein großer Batzen von 3,5 Millionen – validieren, hat in der Webstandards-Gemeinde wieder für große Aufregung gesorgt. Schließlich ist die W3C-Validierung wichtiges Aushängeschild und nach wie vor verlässlicher Indikator, dass das Markup der Webseite den gängigen Regeln entspricht. Oberflächlich betrachtet sieht das dann tatsächlich wie der Niedergang der Standardisierung aus, aber – wie immer bei Statistiken – lohnt es sich doch, genauer hinzusehen.

Was ist MAMA?

Das MAMA-Projekt ist eine Suchmaschine, die Struktur und Validität einer Webseite erfasst und in einer Datenbank speichert. Bereits 2004 fragte man sich bei Opera, wie sieht es denn wirklich aus mit der realen Umsetzung von Webseiten und welche Fragen würden Entwickler an Realitäten im WWW stellen. Diesen Fragen stellt sich die MAMA-Suchmaschine und hat im ersten Schritt die Antworten ausgewertet. Nach und nach sollen weitere Detailergebnisse zu Markup, CSS und dem Einsatz von Skripten online gehen. Ende des Jahres werden ausgewählte Personen die Möglichkeit haben, die Suchmaschine zu testen. Für Entwickler soll sie dann spätestens im zweiten Quartal 2009 an den Start gehen. Sicherlich nimmt das MAMA-Projekt derzeit eine Vorreiterrolle ein, aber es gibt dennoch Vorläufer-Projekte wie die Google Code Studie aus dem Jahre 2005, die jedoch nicht in gleicher Breite online ausgewertet wurde.

Opera versucht nun die ersten Ergebnisse auf unterschiedlichen Ebenen abzuklopfen: So arbeiten sie die vermeintlich positiven Beispiele heraus – Seiten der W3C-Mitglieder etwa -, von denen man annehmen würde, die müssten valider sein. Dann werden Häufigkeiten der wichtigsten Techniken wie HTML, CSS, Flash und Skripte ausgewertet. Letztlich gipfelt dann alles in einem Prototyp: der durchschnittlichen Webseite.

Die vermeintlich Guten: das W3C und seine Buttons

Es scheint mittlerweile ein beliebtes Gesellschaftsspiel zu sein, die Seiten von W3C-Mitgliedern auf Validität zu untersuchen. Das liegt zum einen daran, dass es sich dabei um einen abgegrenzten Korpus handelt – die Zahl liegt derzeit um die 400 Mitglieder -, und zum anderen, dass man hier durchaus annehmen muss und geltend machen kann, dass gerade deren Webseiten vor Validität strotzen müssten. Immerhin kann man eine ansteigende Tendenz feststellen: In Marko Karpinnens Studie 2002 waren es gerade mal 4%, in der Saarsoo Studie 2006 schon 17%, in der Fadtastic Studie 2007, die Opera nicht zitiert, immerhin schon 22%. In Operas MAMA Studie fällt der Wert dann wieder ein wenig ab auf nur 20% und präsentiert eine Ehrenliste der Mitglieder, die positiv validiert haben mit einem Vergleich zu den Vorjahren. Die Liste schrumpft bei diesem Vergleich dann gänzlich zusammen: Opera hat in all den Jahren validiert, zweimal unter anderem Hitachi und Mozilla, der Rest ist mehr oder weniger Neuzugang und valide Eintagsfliege. Interessant – und das trifft auf alle Ergebnisse der Studie zu – ist, dass nach einem kurzen Quertest der Ehrenliste meinerseits leider viele Mitglieder nicht mehr valide sind. Was auch nicht weiter verwunderlich ist, schließlich sind das durchaus große, dynamische Portale und der Grad der Validität variiert sicherlich mit dem Tageseinsatz.

Ein ähnlich positiv akzentuierter Zugang ist, Webseiten, die W3C-Validierungs-Button einsetzen, auf ihre tatsächliche Validierung zu prüfen. Wie zu erwarten war, sehen die Ergebnisse hier ebenso mager aus, nur die Hälfte dieser Seiten validieren. Ein Ergebnis der Opera Studie ist, dass das W3C eine Information zur Verwendung ihrer Buttons ergänzt hat: Es wird angeraten, die Validierungs-Buttons zur erneuten Validierung zu verwenden. Man sollte ohnehin hier einwenden, dass der Trend zu derartigen Offenbarungs-Buttons stark nachgelassen hat, weil jeder weiß, dass sie nur einen punktuellen Zustand wiedergeben.

Die vermeintlich Guten: CMSe und Editoren

Der interpretative Ansatz von Opera geht aber noch weiter, denn zu den vermeintlich Guten, weil standardkonform in Anwendung und Technik, sind nun mal vor allem Content Management Systeme und Editoren. Grundsätzlich ein richtiger Ansatz, leider scheitert er zum einen an der Auswahl der Stichprobe und zum anderen an der letztlich zu oberflächlichen Interpretation der Ergebnisse. Wenn wir uns die Ergebnisse für das CMS ansehen, fällt sofort ins Auge, dass die Stichprobe nicht hinreichend ist. Typo 3 ist gewiss ein CMS und mit 13% der Sieger, mit Joomla erstellte Seiten sind hingegen nur zu 6,5% valide. Dann werden nur noch WordPress, das etwas valider als Joomla ist, und weit abgeschlagen Blogger angeführt. Der Schluss, den man daraus ziehen müßte, ist, dass in dieser großen Stichprobe keine anderen CMSe genutzt werden, andere CMSe invalide Seiten produzieren oder im Kopf der Seite sich schlicht nicht zu erkennen geben. Die Auswahl ist zu mager, um eine tatsächliche Aussage über CMSe zu machen.

Bei den Editoren sieht die Auswahl etwas üppiger aus, der Spitzenreiter Apple iWeb muss aber in den richtigen Kontext gesetzt werden. So führt dieser mit 82% einsam die Validierungsspitze an, aber mit keinem Wort wird erwähnt, dass es sich bei diesem Editor um einen reinen WYSIWYG-Editor handelt, der es nicht zulässt, den Quellcode zu editieren. Daher ist es nachvollziehbar, dass Seiten weitaus valider ausgespielt werden, als etwa bei Dreamweaver, weit abgeschlagen mit 3,4%, wo man als Nutzer mehr Spielraum hat und auch noch den Quellcode nacheditieren kann. Ohnehin – und das betrifft wieder die gesamte Stichprobe – muss es sich um eher alte Webseiten handeln, die seit Jahren kein Update erfahren haben. Am häufigsten ist Frontpage zu finden und die Liste ist mit Editorleichen wie Adobe PageMill und Claris Homepage gepflastert. Man muss also wirklich warten, bis aktuellere Ergebnisse mit neueren Editoren vorliegen. Die Google Code Studie 2005 ging im übrigen einen gänzlich anderen Weg, um die Validität von Editoren zu erfassen. Sie haben sich die Häufigkeit des problematischen Quellcodes, den Editoren erzeugen, angesehen – etwa von Adobe GoLive. Man müsste diese Methode schlicht mit jener von Opera, das entsprechende META-Element auszulesen, kombinieren, um mehr und bessere Ergebnisse zu erhalten.

Die Häufigkeiten: HTML, CSS, Flash und AJAX

Sieht man von der schlichten Zahl 4,13% valider Seiten mal ab, wird es dann richtig interessant, wenn man sich die tatsächlichen Häufigkeiten der verwendeten Techniken und Elemente genauer absieht. Hinsichtlich HTML hat sich seit der Google Code Studie 2005 immerhin verändert, dass man heute mehr CLASS-Attribute vorfindet, was indirekt auf einen verstärkten Einsatz von CSS hindeutet. Leider werden immer noch zu einem sehr großen Teil Layouttabellen eingesetzt – das TABLE-Element rangiert an der acht häufigsten Stelle -, der Rückschluss ist zulässig, wenn man sich die geringe Verwendung von TBODY, TFOOT, THEAD oder auch TH ansieht – TH rangiert an der 52. Stelle. Es handelt sich also mitnichten um Datentabellen. Auch werden immer noch alte Elemente wie FONT und CENTER eingesetzt und in der semantischen Auszeichnung dominiert die physische Auszeichnung mit B- und I-Elementen. Gänzlich weit abgeschlagen, weil ihr Einsatz doch auch spezifisch ist, Elemente wie INS, VAR oder KBD. Für CSS lässt sich ein ähnliches Ergebnis ausmachen. Zwar nutzen 80% der Seiten CSS, aber am populärsten ist der schlichte Einsatz zur Textformatierung mit COLOR, FONT-SIZE und FONT-WEIGHT. FONT-WEIGHT scheint, weil es an fünfthäufigster Stelle rangiert, gänzlich kontraproduktiv dafür genutzt zu werden, semantische Ergebnisse zu erzielen. Auch lässt sich ein Trend zur absoluten Positionierung ausmachen, POSITION rangiert vor FLOAT. Aber hier könnte man auch wieder eine historische Option aufmachen, schließlich war lange Zeit das absolute Positionieren durchaus gängiger. Skurril in den Einzelauswertungen sind die Vertipper in den CSS-Eigenschaften: FONT-FANILY, VERTICAL-ALGIN, DISLAY oder OVERLOW.

Zu Flash- und AJAX-Einsatz muss von Operas Seite noch weiter ins Detail gegangen werden. Hier liegen erst länderspezifische Ergebnisse vor. So ist bei AJAX ein Aufwärtstrend erkennbar, wird sehr häufig in Norwegen oder etwa China eingesetzt, wenig in Italien und Japan. Bei Flash ist das ähnlich, dominant in China, rückläufig in Deutschland. Die Studienergebnisse von Adobe liefern für den Browsereinsatz weitaus höhere Ergebnisse, sind aber hiermit nicht vergleichbar, weil sie ein gänzlich anderes Verfahren einsetzen. Adobe liefert dem Nutzer Beispielseiten mit unterschiedlichen Multimediaelementen und dieser muss rückmelden, was er sehen kann. Hierbei geht es um die Verbreitung des Plugins, nicht ob Webseiten tatsächlich Flash einsetzen. Operas Studie orientiert sich da ganz klar an den gängigen Einbindungsmethoden in HTML vom OBJECT-Element bis zur Skript-Einbindung. Die Ergebnisse für Flash und AJAX sind aber dünn, geben generelle Häufigkeiten wieder, aber keine Informationen über die Standardkonformität der eingesetzten Elemente und Skripte. Hier wäre der Mut zur Lücke mehr gewesen, mit diesen Ergebnissen kann man nichts anfangen.

Viel interessanter und für die Standardkonformität von großer Bedeutung ist der Einsatz des DOCTYPES und wie sich die Validität hinsichtlich HTML, XHTML und den Varianten verteilt. Hierbei ist nämlich das wirklich Innovative zu berichten: 50% aller Seiten verwenden einen DOCTYPE! Nicht dass diese Seiten dann automatisch auch valide sind, aber – wir erinnern uns noch gut an die alten Zeiten, wo kein HTML-Hahn nach DOCTYPE gekräht hat – es hat sich sowohl in den Tools als auch bei den Entwicklern ein Verständnis für konforme Webseiten durchgesetzt. HTML 4 dominiert zwar noch, aber XHTML validiert häufiger, strikte öfter als transitional Varianten. Der häufigste DOCTYPE, wie nicht anders zu erwarten, ist transitional.

Die durchschnittliche Webseite

Aus den ganzen Häufigkeitswerten extrahiert Opera dann auch die typische Webseite, die man sich natürlich heute weitaus valider und standardkonfomer wünschen würde, aber das Ergebnis ist nicht unerwartet. Der DOCTYPE ist HTML 4 transitional, enthält das gängige Basismarkup mit den üblichen alten Verdächtigen etwa im BODY ein BGCOLOR-Attribut, hat kein Formular, Plugin oder Event-Handler, aber mindestens ein Skript, validiert nicht und enthält im BODY eine 3-fach geschachtelte Layouttabelle. Immerhin hat die Seite noch eine externe CSS-Datei mit dem typischen Namen styles.css, wenngleich sie die CSS-Eigenschaften nur dazu nutzt, Text zu formatieren mit COLOR oder FONT-FAMILY.

Fazit

Die Opera MAMA Studie kann erst ein Anfang sein, um wirklich umfassende Ergebnisse in Sachen Häufigkeit, Validität und Webstandards zu liefern. Noch stehen zu sehr, teilweise obskure Häufigkeiten im Vordergrund und werden nicht hinreichend in einen Kontext gesetzt oder hinterfragt. So ist es fast nachlässig bei CMS und Editoren nicht darauf hinzuweisen, dass wie etwa bei WordPress das Standardtheme sehr wohl standardkonform in seiner Auslieferung ist, aber – und hier ist der Knackpunkt – was der Nutzer daraus macht, ist letztlich das Problem. Für CMS sieht die Kehrseite genauso aus, sowohl für die integrierten und überarbeiteten Templates als auch für die im CMS integrierten Editoren. Es ist schlicht zu simpel, hier Häufigkeiten geltend zu machen, wo andere, externe Faktoren oft eine viel größere, invalide Rolle spielen.

So sehr die Ergebnisse nun zur Interpretation bereit liegen, sollte man sie immer auch noch mal abklopfen. Schlussfolgerungen, wie man sie andernorts lesen kann, dass man dem Kunden gegenüber nun wieder weniger Argumente gegen Tabellenlayouts hätte oder das im Grunde keiner Wert auf Standards legen würde, sollte man tunlichst sein lassen. Auch wird der W3C aufgrund der MAMA Studie nicht anfangen, seine Standards nachzujustieren, weil eine Technologie oder diese oder jene HTML-Elemente kaum Verwendung finden. Gut, diese Argumente hat man in der Standardisierungs-Diskussionen vor allem im Hinblick auf barrierefreie Optimierung immer wieder gehört – was nicht häufig verwendet wird, könne auch raus. Aber das ist nun mal das Manko von Häufigkeiten. Die Mehrheit mag noch immer Layouttabellen einsetzen, aber wir alle wissen, dass das Stillstand bedeutet. Was wir brauchen – wie Eric Eggert auch aktuell fordert -, ist Bewegung.

Kommentare

Joerg
am 09.11.2008 - 10:02

Nun frag ich mich in welcher Version hat Dreamweaver je ein META Element ausgegeben an Hand dessen man eine Seite als mit Dreamweaver erstellt erkennen kann?

Permanenter Link
Sylvia Egger

Sylvia Egger (Autor)
am 09.11.2008 - 12:36

Für die Version 8 läßt sich das durchaus in den Code-Suchmaschinen finden. Aber nicht üppig. Da ich Dreamweaver nicht nutze, kann ich dazu wenig Infos geben. Die aktuelle CS4 macht das nicht automatisch, man kann wohl ein Zusatzplugin nutzen für Metatags, wo man auch den GENERATOR einbinden kann. Aber soweit ich mich erinnere, haben das früher die meisten Editoren automatisch gemacht.

Daher auch mein Verdacht, dass die Stichprobe schlicht zu "alt" ist. Und ganz klar, die Methode den META auszulesen, ist mehr als angreifbar. Da ging Google Code schon einen Schritt weiter.

Permanenter Link

Anne-Kathrin
am 10.11.2008 - 12:59

Übrigens:
Das, was mit einem durchschnittlichen WYSIWYG Editor eines CMS an abenteuerlichem Quellcode produziert werden kann, auch wenn dieser Editor durch den Webdesigner abgespeckt und angepasst wurde, ist immens.
Es passiert u.a. übrigens nicht nur durch Unwissenheit, sondern auch durch Löschen oder Umstellen von Textelementen. Angefangen von leeren Überschriftenelementen, über leere Listen, leere Paragraphs, nicht endenwollenden Breaklineanweisungen bis hin zu haarsträubenden Tabellenaufbauten - und dem unbearften User fällt's womöglich gar nicht auf.
Spätestens wenn man als Dienstleister eine Seite freigibt, muss man sich auf böse Überraschungen gefasst machen und sollte den Perfektionsanspruch im eigenen Interesse deutlich zurückfahren, um nicht unglücklich zu werden.
Trotz allen Abspecken und aller Restriktion: es gibt auch Nutzer (=Kunden), die jene Restriktion absolut nicht wünschen ("geben Sie mir ruhig einen Admin Account, ich mach schon nichts kaputt").
Inzwischen können wir weiter idealistisch und verzweifelt Überzeugungsarbeit leisten...

Permanenter Link
Peter Rozek

Peter Rozek
am 10.11.2008 - 16:10

@Anne-Kathrin: Spätestens wenn man als Dienstleister eine Seite freigibt, muss man sich auf böse Überraschungen gefasst machen und sollte den Perfektionsanspruch im eigenen Interesse deutlich zurückfahren, um nicht unglücklich zu werden.

Es besteht ja immer noch die Möglichkeit den Kunden am Editor und am CMS zu schulen. Wenn der Kunde in regelmäßigen Abständen Inhalte einpflegt, wird mit der Zeit deutlich mehr Sicherheit einkehren.
Oder einen Styleguide aufstellen, wo der Kunde immer wieder nachschlagen kann. Auf jeden Fall muss man die richtigen Argumente finden und den Kunden den Sinn und Zweck erklären.
Nicht immer nur auf den Kunden schimpfen… sind auch nur Menschen.

Wenn der Kunde natürlich gerne Admin sein möchte, gut, soll er machen. Wenn er die Seite total abschießt oder völligen Mumpitz treibt, wird das Geraderücken teuer. Auch das muss man dem Kunden mit den richtigen Worten mitteilen. Wahrscheinlich denkt er ja noch mal darüber nach, ob er wirklich Admin sein möchte.

Permanenter Link

Björn
am 10.11.2008 - 18:05

Es besteht ja immer noch die Möglichkeit den Kunden am Editor und am CMS zu schulen. Wenn der Kunde in regelmäßigen Abständen Inhalte einpflegt, wird mit der Zeit deutlich mehr Sicherheit einkehren.
Oder einen Styleguide aufstellen, wo der Kunde immer wieder nachschlagen kann.

Das funktioniert auch ganz gut. Und man muss nicht immer die technischen Hintergründe erklären. Natürlich geht das auf die Dauern nicht immer ganz fehlerfrei. Aber eine Schulung, ein Handbuch oder Styleguide sollten zum Angebot gehören.

Man sollte allerdings auch die Editoren der CMS auf die wichtigsten Funktionen beschneiden. Raus müssen z.B. auf alle Fälle: Fettdruck, kursiv und Farben ;-)

Permanenter Link

Dieter Petereit
am 10.11.2008 - 18:22

Gut zu lesen, dass wenigstens hier auf das Einhalten von Standards gepocht wird...

Wenn schon sonst nirgends...

Permanenter Link

Anne-Kathrin
am 10.11.2008 - 20:05

Nein, ich schimpfe nicht auf die Kunden. Sorry, wenn das so angekommen ist. Ganz im Gegenteil.

Was ich damit sagen wollte ist vielmehr: es ist nicht alles so einfach wie es aussieht.Und ich glaube, wir müssen "den Kunden" da abholen, wo er steht - vielleicht muten wir dem ganz normalen User da auch gelegentlich zu viel zu. Es ist alles so idealistisch (und der Idealismus ist auch wichtig), nur realistisch ist das nicht immer - leider.

Habt Ihr das nicht selbst schon mal erlebt, dass das Arbeiten mit einem Editor beim schnell mal Löschen und Einfügen (durch Verschieben, nicht durch Copy & Paste aus Word oder einem ähnlichen Unding!) plötzlich Formatierungen oder leere Tags hängen bleiben? Es gibt einiges, was mir einfällt, bei dem kein Styleguide hilft sondern nur viel Geduld auf allen Seiten.

Permanenter Link
Peter Rozek

Peter Rozek
am 10.11.2008 - 20:08

@Björn: Man sollte allerdings auch die Editoren der CMS auf die wichtigsten Funktionen beschneiden. Raus müssen z.B. auf alle Fälle: Fettdruck, kursiv und Farben

Korrekt – alles was nicht gebraucht wird, raus aus dem Editor! Je weniger Funktionen der Editor mitbringt umso besser.
Für den Kunden es einfach und angenehm gestalten, wie es nur geht. Schließlich soll die Inhaltspflege ja auch ein wenig Spaß machen ;-)

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Webkraut)
am 10.11.2008 - 20:36

@Björn: Man sollte allerdings auch die Editoren der CMS auf die wichtigsten Funktionen beschneiden. Raus müssen z.B. auf alle Fälle: Fettdruck, kursiv und Farben

Warum sollten fett und kursiv in jedem Fall raus? Die sind mitunter ganz nützlich, wenn der Kunde es damit nicht übertreibt. Moderne Editoren machen da automatisch <em> und <strong> raus, also alles semantisch korrekt.

Permanenter Link
Sylvia Egger

Sylvia Egger (Autor)
am 10.11.2008 - 21:42

@Björn
Für die Semantik es ist es schon wichtig, dass fett und kursiv erhalten bleiben. :) Moderne Editoren machen das auch ganz korrekt. Das Problem sehe ich eher darin, dass Kunden immer noch gerne aus Word kopieren, auch wenn man es ihnen immer wieder sagt, dass sie das nicht tun sollen. Es gibt zwar auch immer bei Editoren eine Funktion, dass auch das bereinigt werden kann, aber naja - meisthin ist dann eher schon alles verloren.

Abspecken sollte man vor allem Layoutmöglichkeiten, wie links- oder rechtsbündig.

Permanenter Link

Anne-Kathrin
am 11.11.2008 - 07:35

Fett und kursiv. Das hatte ich auch nicht verstanden. Eigentlich das, was für jeden User intuitiv ist, im Vergleich zu manch anderem geringe Fehlerquellen birgt und sich wirklich unproblematisch in das Ganze einfügt.

Permanenter Link

GE
am 11.11.2008 - 08:50

fett & Co. (incl. Farben) sehe ich auch nicht als Problem. Wenn das nicht da ist, ist der Kunde unglücklich :-( , und das wollen wir ja nicht.

Ich bringe dem Kunden immer als erstes bei, dass er solche Formatierungen zwar gerne verschachteln kann, aber nicht überlappen sollte. Dann gehts auch.

Wichtig ist es, die Funktion "Einfügen von Word-Text" zu entfernen, damit der Kunde gar nicht erst auf dumme Gedanken kommt. Dann zeigt man dem Kunden den ganz normalen Windows-Editor, bringt ihm die Tastaturfunktionen strg+c und strg+v bei, und dass er Word- oder andere Texte aus Textverarbeitungs-Programmen immer erst im Texteditor zwischenspeichern und dann in den WYSIWYG kopieren soll.

HTML-Fragmente, die beim Bearbeiten vorhandener Inhalte entstehen, sind tatsächlich das grösste Ärgernis. Die Seiten bleiben dummerweise dabei meistens valide, so dass man dem ganzen nur auf die Schliche kommt, wenn man den Quelltext analysiert. Und gerade damit wollen sich die Kunden ja nicht beschäftigen.

Permanenter Link

Björn
am 11.11.2008 - 09:57

Ok, war etwas zu extrem. Aber bei vielen wäre sogar das besser :-) Dann fragen manche nämlich, wie sie die Überschrift fett bekommen ;-) So wird dann gelernt, dass Überschriften aut. fett sind (soweit das so vorgesehen ist per CSS).

Permanenter Link
Peter Rozek

Peter Rozek
am 11.11.2008 - 10:46

Wenn der Editor fett und kursiv standardkonform in “strong” und “em” umwandelt, kann man beide Möglichkeiten im Editor belassen. Aber es gibt auch noch Kunden, die mit einem alten CMS, unterwegs sind. Hier tendiere ich dazu die Funktion rausnehmen.

@Björn: wie sie die Überschrift fett bekommen

Passiert tatsächlich, Kunden Fragen so etwas. Ach hier muss man sich am Kunden orientieren und seine Wehwehchen verstehen. Es gibt Kunden denen kann man die Problematik erklären und sie wird auch verstanden. Andere Kunden denken eher in der “MS-Word Kategorie". “Hier kann ich doch auch die Überschriften fetten".

Für den Kunden muss die Inhaltspflege einfach sein. Umso einfacher um so besser! Ob etwas standardkonform ist und der Semantik entspricht, sind für die meisten eher böhmische Dörfer.
Auf jeden Fall sollte man versuchen den Kunden vorwährend unterstützen und Hilfe anbieten. Ich habe es bisher noch nicht erlebt das ein Kunde bei Serviceleistungen und dazu zähle ich auch Beratung und Schulungen Nein sagt, wenn diese in Rechnung gestellt werden. Es kommt natürlich immer auf die Tonalität an.

@Sylvia: Das Problem sehe ich eher darin, dass Kunden immer noch gerne aus Word kopieren.

Wenn der Kunde es nicht besser weiß dann macht er sich das Leben einfach, zumindest glaubt er das. Hier muss die richtige Kundenansprache gewählt werden. Wenns gar nicht anders geht, die komplette Inhaltspflege als Serviceleistung anbieten. Wenn der Kunde sich natürlich als Beratungsresistent erweißt, wird die Sache schon schwierig. Entweder man hat dann eine Engelsgeduld oder man legt sich ein dickes Fehl zu.

Denn Kunden die Inhaltspflege mit der Technikerbrille zu erklären macht kein Sinn. Schon gar nicht dem Kunden etwas von der Web Developer Toolbar erzählen und das man, damit die Seite validieren kann. Tatsächlich habe ich erlebt, dass ein Kollege/in dem Kunden erklärt hat, er können über die Toolbar feststellen, ob er schon sauber gearbeitet hat. Schön: 1 von 100 versteht das vielleicht.

Wer Nachhaltigkeit fordert, muss auch bereit sein den Kunden zu schulen und wenn es sein muss auch an die Hand nehmen.

Permanenter Link

Ansgar
am 11.11.2008 - 16:49

Erstmal vielen Dank an Sylvia für die tolle Zusammenfassung. Ich hatte mich auch mit MAMA im Zusammenhang mit der CMS-Auswertung interessiert. Die Studie hat nur das META-Element für "generator" ausgewertet - das fliegt bei mir in 99% aller Fälle raus, weil es keinen praktischen Wert für die Website hat. Viele CMSse nutzen das nicht, viele Webdesigner auch nicht. Und woher kommt nun der hohe Anteil an TYPO3-Websites mit validem Code? Marktanteil. Gleiches gilt für Joomla. Loben muss man da auch die Standard-Template-Bastler, denn dank diverser Themes sind genau diese Systeme so gut geworden ... in der Studie.

Ergänzend mag ich noch sagen, dass die Validome-Studie vor einigen Jahren exakt jene 4% valider Seiten lieferte - interessant, oder?

Permanenter Link
Sylvia Egger

Sylvia Egger (Autor)
am 12.11.2008 - 10:58

@Ansgar

Das mit der ValiWatch 2005 ist wirklich interessant: 3,9%. :) Wahrscheinlich pendelt sich das da immer ein. ;)Interessant ist der Vergleich des DOCTYPES im Vergleich: 2005 war noch HTML 4 transitional eindeutig Marktführer. Was auch nicht verwundert. Insofern hat sich schon was getan, wenngleich mehr besser wäre.

Permanenter Link

Michael
am 20.11.2008 - 22:13

Die eigene Website ist mit Joomla umgesetzt worden. Beim ersten Wurf präsentierte Joomla vierfach ineinander geschachtelte Tabellen im Quellcode und ähnliche unschöne Überraschugen. Mit viel Zeit arbeitete ich mich in die Core-Dateiene ein und konnte wenigstens eine XHTML1.0-Konformität herstellen. Das CSS ist annähernd konform. Es wird immer noch jede Menge Quellcode generiert, so ds ich überlege, wieder auf ein händisch erzeugtes unt tabellenfreies Template zurück zu greifen.

Permanenter Link

Isa
am 24.11.2008 - 12:23

Eine allgemeine Durchsetzung der Standards fällt schwer - zum größten Teil hängt das mit dem Problembewusstsein zusammen: Selbst bei den üppigen Budgets für die Seite-Erstellung kommt die Seitenpflege und - aktualisierung zu kurz, im besten Fall geht es dann um die Contentpflege. Zum anderen ist es auch das Problem der Kompatibilität aller Elemente - CMS, Design ... wo man sich dann auf eine wenig optimale Lösung eingelassen hatte, den erschreckt der Optimierungsaufwand.

Permanenter Link

GE
am 25.11.2008 - 13:10

Das Problem besteht doch ganz einfach darin, dass die Browser alles anzeigen.

Wenn ich in einer Programmiersprache (wie z. B. PHP) auch nur einen einzigen Punkt vergesse, bekomme ich einen weissen Bildschirm, und wenn ich Glück habe eine Fehlermeldung. Bei den Markup-Sprachen HTML und XHTML kann ich mir dagegen einiges erlauben.

Das ist aber nun mal so eingerissen. Ein Browser, der nur standardgerechte Seiten anzeigt, hätte keine Chance, weil man sich mit dem eben nur 4% aller Internetseiten ansehen könnte. Kein Mensch würde so einen Browser benutzen.

Es wird also so bleiben, wie es ist. Der Mensch reagiert eben nur auf Druck und nicht auf gute Worte.

Permanenter Link

Die Kommentare sind geschlossen.