Relaunch der Süddeutschen Zeitung – unter die Haube geschaut

Seit heute präsentiert sich die Süddeutsche Zeitung im neuen Gewand. Das weckt mein Interesse, denn schliesslich lese ich sie nicht nur hin und wieder gerne. Ich nehme sie in meinen Schulungen und Vorträgen auch immer wieder als leuchtendes Negativbeispiel. Zusammen mit dem Stern, denn beide Seiten zeichnen Überschriften auf der Startseite nicht als solche aus.

Ich war also gespannt, ob der Relaunch nicht nur ein attraktives Äußeres, sondern auch einen besseren Code gebracht hat. Neben den fehlenden Überschriften waren auch immer sinnfreie oder englischsprachige Alternativtexte für Bilder zu sehen. Möglicherweise hat die Redaktion auf die Pflege der Bilderdatenbank keinen Einfluss, ich weiss es nicht. Alternativtexte gehörten jedenfalls nicht zur Stärke der Datenbank.

Banale Fehler sollten nicht vorkommen

Im neuen Auftritt fallen eine Reihe Bilder auf, die mehr oder minder dekorativ sind und deshalb nicht zwangsweise einen Alternativtext benötigen. Deshalb sollte man ihn einfach leer lassen. Bei der Süddeutschen fehlt das Attribut. Damit wird Screenreadernutzern der Bildername vorgelesen.

Tabellen kann man mit Attributen gestalten, sollte man aber nicht. Jeder Frontendentwickler, der sich mit CSS gut genug auskennt, käme nicht auf die Idee, so etwas zu tun. Und da jede Zelle eine Klasse hat, spricht auch nichts dagegen, CSS die Kontrolle zu überlassen. Es sei denn, man will auch extrem abseitige Browser wie Netscape 4 noch unterstützen. Doch darüber sollten wir nicht ernsthaft diskutieren, oder?

Ergänzt wird das Bild schludrigen Codes durch die sechsfache Nutzung der selben ID innerhalb der Navigation. Hin und wieder die eigene Arbeit zu validieren hilft ungemein. Ich habe für sowas einen Grunt-Prozess. Dabei wäre auch aufgefallen, dass die Süddeutsche zwar das time-Element nutzt, aber nicht mit dem dazugehörigen Attribut. Dann kann man es auch gleich lassen. Denn ohne das Attribut ist es in der genutzten Form nicht maschinenlesbar und damit nutzlos. In einem anderen Fall wurde das falsche Zeitformat in das eigene Attribut data-time gesetzt, anstatt das korrkete datetime zu nutzen. Es wäre auch aufgefallen, dass einem Bild als Attribut width="100%" mitgegeben wurde. Das Prozentzeichen gehört hier nicht hin. Für solche Fälle haben wir CSS.

Übrigens: würden die Bilder zumindest ein leeres Alt-Attribut bekommen, die doppelten IDs entfernt werden und die time-Elemente die korrekten Attribute mit dem korrekten Format bekommen, wäre die Seite fast fehlerfrei.

Und die Überschriften?

Kommen wir also zu meiner Ausgangsfrage: wie sieht es mit Überschriften aus? Auf der Startseite finden sich ein paar. Es sind aber nicht die, die wir erwarten. Im Megamenü sind ein paar Überschriften vierter Ordnung verstreut. Dann kommt das Logo als Überschrift erster Ordnung. Dem Logo folgt sinnloserweise eine h4, die das Kürzel „sz.de“ umfasst. Der Sinn dieser Aktion erschliesst sich mir nicht. Es muss also etwas mit SEO zu tun haben.

Nun folgen Überschriften zweiter Ordnung, die Bereichsüberschriften darstellen, wie bspw. „Artikel aus dem Ressort München“. Die eigentlichen Artikel haben allerdings keine Überschriften. Stattdessen sehen wir Links mit eingeschachtelten Inline-Elementen:

<a href="ein-toller-link.html" class="entry-title" rel="bookmark" data-pagetype="STANDARD_ARTICLE" data-id="1.2406293">
  <strong>
    Starke Konjunktur
  </strong>
  <em>Steuereinnahmen steigen rasant</em>
</a>  

Optisch sieht dieses Arrangement auf der Starseite folgendermassen aus:

Screenshot einer optischen Headline bei der Süddeutschen, die semantisch leider keine ist.

Screenshot einer optischen Headline bei der Süddeutschen, die semantisch leider keine ist.

Der Stern hat ebenso solche Konstrukte. Da schienen die Entwickler nach aussen ihre Hilflosigkeit dokumentieren zu wollen, indem sie den Überschriften eine Klasse h2 mitgaben. Jedesmal, wenn ich solche Konstrukte sehe, stelle ich mir die Frage nach dem Sinn. In einem Kommentar zu einem Artikel von Marco Zehe wird der Eindruck erweckt, zumindest in der letzten Iteration der Süddeutschen wurde aus SEO-Gründen auf Überschriften verzichtet. Das hört sich widersinnig an, denn schliesslich kann Google (andere Suchmaschinen interessieren in Deutschland nicht) mit semantischem HTML etwas anfangen und goutiert es sogar. Meine Frage an zwei SEO-Experten und eigene Recherchen brachten auch keinen Beweis für die These, viele verlinkte Überschriften wären nachteilig.

Und selbst wenn dem so wäre: erstens ändert Google sowieso alle paar Monate den Algorithmus. Was einmal als Gesetz galt, kann dann abgestraft werden. Zweitens schreiben wir Webseiten idealerweise für Menschen, nicht für Maschinen. Und drittens ist HTML in erster Linie Handwerk. Der Verzicht auf Überschriften ist schlechtes Handwerk.

Auf den Unterseiten sieht es nur wenig besser aus. Aus dem seltsamen Konstrukt von oben wird tatsächlich eine h2. Allerdings werden dabei zwei unterschiedliche inhaltliche Ebenen miteinander verwoben und nur durch ein strong voneinander getrennt.

<h2>
    <strong>
        Starke Konjunktur
    </strong>
    Steuereinnahmen steigen rasant
</h2>

Besser wäre gewesen, beide Texte als unterschiedliche Überschriften zu interpretieren, die sie auch sind. Eine Überschrift ist eine inhaltliche Klammer.

<h2>Starke Konjunktur</h2>
<h3>Steuereinnahmen steigen rasant</h3>

Unter „Starke Konjunktur“ kann man sich noch weitere Artikel vorstellen, deshalb funktioniert diese Überschrift als eigene inhaltliche Klammer.

Die Bildunterschriften bekommen nun auf einmal auch Überschriften und reihen sich somit in die Logik der eigentlichen Zwischenüberschriften ein. Das dürfte für Screenreadernutzer verwirrend sein. Es ist auch nicht gerechtfertigt.

Validität und Überschriften sind doch unwichtig

Man mag einwenden, dass ich kleinlich bin, wenn ich richtige Attribute, richtig eingesetzte Elemente anmahne und mich an fehlenden Überschriften aufhänge. All das sind Zeichen für richtig oder falsch geschriebenes HTML. HTML hat zwei Ebenen: die syntaktisch richtige Anwendung und die inhaltlich korrekte Anwendung. Das Attribut datetime muss richtig geschrieben werden und Überschriften als solche ausgezeichnet werden. So einfach ist das.

Genauso einfach ist es mit der Anwendung der deutschen Sprache. Sie muss syntaktisch korrekt genutzt werden, das nennt man Rechtschreibung. Und sie soll inhaltlich Sinn ergeben. „Wechselstaben verbuchteln“ ist witzig, weil es mit dem zweiten Aspekt spielt. Als seriöse Tageszeitung sollte ein solcher Unsinn allerdings nicht der Normalfall sein.

Aber warum wird eine falsche Schreibweise bei den Inhalten nicht akzeptiert, bei HTML scheint dieser Aspekt hingegen egal zu sein?

Was noch so auffällt

Die Seite wartet mit Conditional Comments für den IE 10 und den IE 11 auf. Dummerweise wurden die Conditional Comments mit dem IE 10 abgeschafft.

Auf der Artikelseite wird anstatt eines header-Elements ein section-Element genutzt. Das macht keinen Sinn. Die neuen semantischen Elemente, die mit HTML5 eingeführt wurden, scheinen bei der Süddeutschen bekannt zu sein. Doch leider wurde ihr Sinn und ihr Einsatzzweck nicht verstanden. Auch das ist schlechtes Handwerk.

Responsive? Bleib mir fort!

Zum Schluss, nach all der Codeorgie, interessiert mich, ob die Süddeutsche nicht nur optisch, sondern auch konzeptionell modern ist. Insbesondere bei solche Massenseiten wie der Süddeutschen sollte es selbstverständlich sein, dass ein Relaunch auch ein responsiver Relaunch ist. Aber wir befinden uns in Deutschland. Hier ist die Internet-Infrastruktur mittelmäßig bis schlecht, unsere sogenannten Eliten haben keine Ahnung vom Medium und unsere Nachrichtenhäuser scheinen mehrheitlich ängstlich dem Internet gegenüber zu sein.

Die Süddeutsche bringt keinen responsiven, eher einen adaptiven Webauftritt. Wenn ich das richtig sehe, wird mittels Browsersniffing die Notwendigkeit für ein mobiles CSS erkannt. Beschönigend wird sowas auch RESS genannt. Kann man machen, ist zumindest besser, als die mobile Extra-Seite, die bspw. die Frankfurter Rundschau präsentiert und die zudem extra hässlich ist.

Ich wünsche mir, dass es auch in Deutschland ein offenes, modernes Verlagshaus oder Rundfunkanstalt gibt, das wie der Guardian und die BBC in England ihren Entwicklungsprozess öffentlich dokumentieren und dabei sogar neue Techniken entwickeln und propagieren. Es wird, so fürchte ich, ein Wunschtraum bleiben.

Fazit

Alle meine Ausführungen lesen sich sicherlich für manche wie Krümelkotzen, kleinlich und oberlehrerhaft. Aber mein Punkt ist, dass Frontendentwicklung ein Handwerk ist. Es folgt relativ einfachen Regeln, die all diejenigen beherrschen sollten, die es ausüben. Perfektion gibt es in der Frontenentwicklung nicht, dafür gibt es zuviele Zweifelsfälle im Bereich Semantik. Und manchmal muss man wegen des Designs Kompromisse eingehen und einen zusätzlichen Container um den Inhalt legen. Aber abseits dieser Kompromisse sollte man sich um guten Code bemühen. Wer das nicht will oder kann, sollte keinen Frontendcode schreiben. Dazu gehört zuallererst Selbsterkenntnis und daneben die passende Erkenntnis der Vorgesetzten.

Im Falle der Süddeutschen spricht nichts gegen guten Quellcode. Ansätze sind ja da, denn HTML5 scheint prinzipiell bekannt zu sein. Das Team dürfte nicht klein gewesen sein. Der Auftraggeber ist finanziell potent genug, sich auch externen Rat über Codequalität holen zu können. (Ich habe das selber schon bei einem ähnlich großen Projekt für einen Fernsehsender gemacht.) Und die Projektdauer von zwei Jahren spricht auch dafür, dass man nicht unter enormem Zeitdruck im Frontend stand. Trotzdem ist kein wirklich gutes Ergebnis dabei herausgekommen. Die Optik gefällt mir, aber die ist nur die halbe Wahrheit. Handwerklich ist die neue Sueddeutsche.de nicht gut.

Nachtrag

Während der Abfassung dieser Analyse, die doch länger als geplant wurde, kam mir ein Link zu dem Magazin „Wired“ unter. Ich las das Interview mit Sascha Lobo und da ich gerade bei der semantischen Analyse der Süddeutschen war, interessierte mich die Überschriftenstruktur von Wired. Überschriften scheinen eindeutig überbewertet zu sein, denn Wired besitzt keine einzige. Das ist miserables Handwerk. Das Augenmerk lag offenbar nur auf der Optik. Dagegen ist der Code der Süddeutschen ja richtig gut.

26 Kommentare

  1. Wenn ich mich richtig irre, ist width="100%" valide. In HTML sind sind Pixel- (einheitslos) und Prozentangaben (mit „%“) erlaubt, alle anderen Einheiten müssen über CSS benutzt werden.

    Über die Sinnhaftigkeit dessen kann natürlich diskutiert werden.

  2. Mal abgesehen vom Code-Müll und gerade aufgrund der traurigen GermanWings-Geschichte bemerkt. Die haben einen Liveticker eingerichtet. Dieser aktualisiert sich von selbst, aber nur dahingehend, dass da ein Link steht mit „Aktualisieren (2 neue Meldungen)“. Und ratet mal was passiert, wenn man ihn aktualisiert? Klar, kompletter Page-Refresh (um Werbung neu zu laden natürlich) und nicht einmal ein Sprung auf den Ticker selbst, sondern an den Seitenanfang.

  3. Und: 216 Requests, 2,8MB an Daten. OK, so eine Seite ist natürlich mittlerweile sehr bildlastig, aber was alles an Tracking- und Ad-Banner-JavaScript auf so einer Zeitungs-Webseite zu finden ist, ist echt gruselig.

    • Unter den Requests sind 10 (!) Schriften. Das sind zusammen schon bestimmt an die 800 KB.

      • Ein Gedanke hierzu noch: gerade als Verlagshaus ist uns eine hauseigene Typographie sehr wichtig. Das kann man gut oder schlecht finden. Wir finden das eher gut. Und Ihnen ist sicherlich auch aufgefallen, daß die Schriften nur beim ersten Laden der Seite gezogen werden, oder?

        • Ihre hauseigene Typo sei Ihnen gegönnt. Aber 10 Schriftschnitte? Ich habe nicht nachgeschaut, aber packen Sie diese dem Nutzer wenigstens in localstorage? Wenn nicht, dann kann es sein, dass sie beim nächsten Mal wieder gezogen werden.

          Es ist immer wieder ein interessanter Dialog mit Designern, die ernsthaft glauben, dass irgendjemand ausser ihnen und deren Kollegen 10 unterschiedliche Schriftschnitte sieht, erkennt und goutiert.

          Sie haben doch agil gearbeitet. Lautete da eine Story ernsthaft: „Als Leser möchte ich mit einer Vielzahl an Schriftschnitten die Details der Webseite fein gezeichnet bekommen.“ Das wäre cool, aber voll an der Realitöt vorbei.

      • Ich habe die Webtypografie der SZ.de seit Jahren als vorbildlich in meinen Vorträgen hervorgehoben, weil sie über die individuellen Webfonts absolut überzeugend das Design der Printausgabe aufnehmen und fortführen. Dass diese Detailliebe nicht jeder aktiv würdigen kann, ist klar, aber man spürt es als Leser subtil im Hintergrund.

        Von daher Daumen rauf für 10 Webfonts, wenn es – wie hier – der Sache dienlich ist.

        • Jens Grochtdreis

          24. März 2015 um 19:13 Uhr

          Du findest ernsthaft 10 Webfonts gut? Das ist doch kein Kunstprojekt. Die Menschen wollen informiert werden und das schnell. Ich mag auch schöne Typo. Zehn Schriftschnitte finde ich aber overdone.

          Hoffentlich haben sie wenigstens die Bilder gut komprimiert. Wobei, wenn ich raten sollte …

  4. Lieber Herr Grochtdreis,

    zuallererst vielen Dank für das ausführliche und detaillierte Feedback!

    Und wir müssen zugeben: sie haben uns auf einige Verbesserungen hingewiesen, welche wir auch beherzigen werden. Das gilt vor allem für die Liste der banalen Fehler: ja, das können wir besser!

    Den Punkt Überschriften haben wir persönlich schon im vorletzten Jahr diskutiert. Die aktuelle Verwendung der Überschriften entspricht in etwa den Anforderungen, welche unser damaliger Kollege 2011 in einem Kommentar grob skizziert hat. Wir nehmen auch hier ihre Anregung auf und prüfen da unseren Standpunkt. Bitte haben sie aber Verständnis dafür, daß eine neue Verwendung der Überschriften-Tags nicht Inhalt unseres heutigen Relaunches war. Letztlich müssen wir unsere Aktivitäten auch priorisieren – und müssen dabei leider mehr als „technische Raffinesse“ im Blick behalten.

    Was den Punkt „Responsive“ angeht: seien sie sich versichert, daß wir das beherrschen. Unsere mobile Seite haben sie ja selbst schon entdeckt. Das wir hier einen adaptiven Ansatz verfolgen, entspricht den Möglichkeiten der heutigen Anzeigenvermarktung. Wir wünschen uns da auch mehr.

    Vielleicht haben sie aber Lust, ein 14-tägiges kostenloses Probeabo abzuschließen (ja – das endet auch automatisch) und einen Blick auf https://zeitung.sueddeutsche.de/ zu werfen. Dort werden sie eine Seite erleben, die komplett responsive funktioniert. Dabei haben wir übrigens auch auf Angularjs als Frontend-Framework gesetzt. Für mich fühlt sich das eher modern und fortschrittlich an. Gerne erhalten wir auch zu dieser Seite ihr kritisches Feedback!

    Zum Abschluss möchte ich unsere Entwickler auch ein wenig verteidigen. Auf Basis der berechtigten Hinweise einem ganzen Team gleich Schludrigkeit vorzuwerfen, schießt meines Erachtens etwas über das Ziel hinaus. Ich kann Ihnen versichern, daß wir heute ein umfangreiches Releasepaket ohne große Probleme auf Produktion gebracht haben. An einem Tag, der aufgrund eines tragischen Flugzeugunglücks auch technische Herausforderungen parat hielt. Das schaffen wir nur, weil wir auch technisch viel Wert auf Qualität legen.

    Für mich ist das Glas deshalb eher halbvoll. Deshalb meine ich, daß wir auch durch den Relaunch heute Ihrem Bild eines offenen und modernen Verlagshauses einen großen Schritt näher gekommen sind.

    Für den regen Austausch möchte ich mich nochmal bedanken!

    Bleiben Sie uns gewogen!
    Ingolf Sander

    • Hallo Herr Sander,

      es freut mich, dass meine Besprechung den Adressaten erreicht hat. Ihre Verteidigungsrede ist in etwa so, wie ich sie erwartet habe.

      Fragen Sie mal bei Ihren Journalistenkollegen, ob Überschriften und korrekte Rechtschreibung „technische Raffinesse“ sind. Ich denke, wir beide kennen die Antwort.

      Weshalb ist es also der Aufbau des Frontend-Codes nebensächlich? Wenn Sie als Redaktion besonderen Wert auf die technische Implementierung Ihrer neuen Bezahlschranke legen, dann muss das das Frontend nicht interessieren? Oder waren hier mal wieder Backendentwickler zur Frontendentwicklung genötigt worden und mussten diesen Code dann quasi nebenher schreiben?

      Nein, ich habe kein Verständnis dafür, dass man einen Relaunch macht und die Fehler der Vergangenheit mitschleppt und einfach schlechtes Handwerk abliefert. Entweder sind die Kollegen nicht dazu in der Lage oder sie wurden von – meist fachfremden – Vorgesetzten dazu genötigt. So ist jedenfalls meine These.

      Eine separate responsive Seite ist relativ albern. Das ist wie eine separate barrierefreie Seite. Ich hoffe, die Angular-App (was sonst?) ist besser erstellt, als Ihr Impressum. Darein haben sich auch Angular-Versatzstücke verirrt. Und wie ich bei Angular immer vermute, waren es wenig durchdachte. Schauen Sie sich mal die Twitter-Links bei den Redaktionsmitgliedern an. Sie haben kein href-Attribut. Das soll – sinnloserweise – bestimmt durch eine Angular-Direktive nachgerüstet werden. Das funktioniert aber nicht. Die Links sind nicht aktiv, man klickt sich tot.

      Ich kenne den Umgang mit solch komplexen Projekten. Sie sind alles andere als banal und einfach. Ich weiss aber auch, dass man deshalb eine Arbeitsteilung hat. Der Livegang hat mich als Frontendentwickler nie tangiert. Ich hatte damit nichts zu tun. Das machen die Backend-Jungs. Aber wenn die natürlich in Personalunion existieren sollten, wäre die Überlastung des Frontends erklärt.

    • Hallo Herr Sander,

      https://zeitung.sueddeutsche.de/ läuft ja wie angesprochen mit dem JS „mvc“ framework AngularJS. Neben den dazu angesprochenen Problemen (Links etc.) von Herrn Grochtdreis, würde ich gern erfahren, warum hier die Wahl auf AngularJS fiel?

      Welche Features machen AngularJS an dieser Stelle notwendig? Sämtliche Links leiten auf neue URLs/Seiten weiter und der Seitenaufruf OHNE JS bringt lediglich einen „weißen“ Viewport auf den Bildschirm. Auch „interaktive“ Elemente oder Inhalte die man nachladen kann finde ich nicht. Die ganze Seite wird bei JS (nach)geladen.

      Eine „webapp“ ist das aus meiner Sicht nicht!

      Grüße,

      Kobe

      • Hallo Herr Kobe,

        wir haben uns für AngularJS entschieden, weil es aus unserer Sicht ein ausgereiftes Framework ist. Folgende Vorteile hat unser Entwicklerteam identifiziert:

        – sehr ausgereiftes, gut geschriebenes Framework
        – sehr gut für Single Page Applikationen geeignet
        – ausgezeichnete Testbarkeit durch bereits integrierte Mechanismen und Dependency Injection
        – Two-way Data Binding out of the Box
        – Leicht verständliches arbeiten mit POJSOs möglich
        – Größe 36kB
        – Sehr gute Dokumentation

        Uns ist dabei nur ein Nachteil aufgefallen:

        – Dirty checking performance

        Die Zusammenfassung unserer Entwickler war:

        Die angestrebte Lösung ist aktuell eine Implementierung mit Angularjs. Backbone und Knockout fallen als Lösung aus, da hier zu viel händisch gebaut werden müsste, was von Angular bereits mitgebracht wird. Testing ist mit diesen beiden Systemen ebenfalls nicht optimal gelöst. Folgende Gründe sprechen für eine Implementierung in Angular anstelle von Ember:
        1. In Ember muss mehr Boilerplatecode geschrieben werden, damit Two-Way-Data Binding richtig funktioniert.
        2. Die durch Dirty checking verursachten Performance Probleme von Angularjs wiegen im Fall unserer Webapp nicht zu schwer, da sie erst ab ca 2000 Objekten im Scope problematisch werden und wir wahrscheinlich deutlich unter dieser Schwelle bleiben. Eine UI mit mehr als 2000 Datensätzen ohne Paging wäre ohnehin nicht besonders Nutzerfreundlich.
        3.In Angular kann mit POJSOs gearbeitet und es können auch sonst Javascript übliche Patterns verwendet werden. Im Gegensatz dazu folgt man bei Ember sehr stark Ember eigenen Konzepten, damit alles korrekt funktioniert. Damit wäre ein Ausstieg aus Angular in Zukunft einfacher als aus Ember.
        4. Möglicherweise wird Dirtychecking in Zukunft ein schwindendes Problem darstellen, da es mit der nächsten ECMAScript Version die Möglichkeit geben könnte auf Changes in POJSOs zu lauschen. Damit könnte die zugrundeliegende Implementierung für das Two-Way-Databinding in Angular angepasst werden und die Performance optimiert werden, ohne dass ein Umbau von unserer Seite nötig ist. In Ember wird es diese Verbesserung nicht geben, bzw nicht ohne dass Konzepte verändert werden, wodurch bei uns Refactoring anfallen würde.
        5. Angular Dokumentation ist unserer Meinung nach übersichtlicher als Ember Dokumentation.

        Die Inhalte liegen als fertig gerendertes HTML vor und werden aus einem bestehenden Backend nachgeladen. Das Refactoring dieses Systems haben wir nach einer Kosten-/Nutzen-Analyse nicht vorgenommen. Es wird auch von anderen Frontends noch verwendet – was das Thema noch komplizierter gemacht hätte. Ohne diese Rahmenbedingung hätten wir sicher anders gehandelt.

        Das wir bei dieser SinglePage-App auch jedesmal die URL verändern, ist eine konkrete Anforderung unserer Redaktion. Sie wünschen sich, daß man nicht nur die App, sondern jede einzelne Seite über soziale Medien teilen kann. Wir hätten dafür natürlich in jede Seite entsprechende Plugins einbauen können. Wir gehen aber davon aus, daß eine beträchtliche Anzahl von Nutzern einfach die URL aus dem Browserfenster kopiert und mit anderen teilt. Auch das sollte funktionieren.

        Ich hoffe, ich konnte Ihnen so unseren Entscheidungsweg verdeutlichen.

        Viele Grüße sendet Ihnen
        Ingolf Sander

  5. Die Erstellung und moderner Websites ist ein komplexes Handwerk, bei der viele Personen beteiligt sind: Frontendentwickler, Designer, Backendentwickler, CMS-Programmierer, API-Entwickler für Anbindung von und zu Drittsystemen, wie auch Social Media, Systemadministratoren. Bei der Bedienung kommen dann normale Autoren hinzu, es gibt ein Rollenkonzepte, Redakteure, Kommentarbearbeitung, Foto-Redakteure, etc pp.

    Eine gute Site ist daher durchaus vergleichbar mit einem Auto.
    Auch ein Auto kann ein tolles Design haben.
    Aber ohne ein funktionierendes System, welches auf den Benutzer in allen Situationen angepasst reagieren kann, nutzt auch das beste Design nichts.
    So ist eine Website, die heute (!) noch keine oder mangelhafte Barrierefreiheit liefert, zu vergleichen mit einem Auto ohne Bremsen.

    Genausowenig wie man beim voll integrierten und ausgearbeiteten Auto die Bremen einfach so später zubauen kann, kann man dies bei einer modernen Website.
    Und genauso wie beim Auto ist diese starke Vernetzung aller Komponenten und Bestandteile auch bei der Website vorhanden.
    Und daher ergibt sich der Widerspruch zum Kommentar von Herrn Sander: Doch! Es ist ein Versagen des gesamten Teams, wenn solche wesentlichen Dinge nicht berücksichtigt wurden.

    Die Kosten, die nun auf die SZ zukommen werden, um diese Handwerksfehler nachträglich zu reparieren, werden sicherlich bei 25-50% der bisherigen Projektkosten liegen. So jedenfalls die Erfahrung aus vielen, vielen vergleichbaren Projekten.

    Das wäre vermeidbar gewesen. Ich beneide diejenigen nicht, die jetzt diese undankbare Aufgabe vor sich haben um das zu reparieren, was andere verbockt haben. Denn üblicherweise sind die Verursacher dann meist schon mit anderen Projekten beschäftigt und dank voreiliger Abnahme auch nicht mehr greifbar.

  6. In „Journalist“ 11/14 war ein Beitrag (war sogar Titelthema) über die Schwierigkeiten für die Entwickler von der in Verlagshäusern genutzten CMS. Hat den schönen Namen „Die Leiden des jungen Programmierers“. Zusammenfassend: Mit dem CMS soll ein Redakteur neben den herkömmlichen auch neue Erzählformen realisieren können. Dabei soll das CMS in gewissen Maßen die Abläufen von Offline-Journalismus abbilden könne. Und man ist nicht gewillt, alte Inhalt zu igrnorieren; sprich, sie sollen trotzdem fast genauso aussehen / funktionieren.

    Wenn man den Artikel gelesen hat, kann man ein gewisses Verständnis für die Entwickler aufbringen (oder Mitleid).

    Erstaunlich finde ich das Vorgehen und die Begründung bei Überschriften. Wenn ich das richtig verstehe, begründet man es mit SEO. Das sich die Auszeichnung von Überschriften (!) mit h2 negativ auf die Startseite (!) auswirken sollte, überrascht mich. Oder wird dann die interne Verlinkung nicht so gut gewertet? Bemerkenswert auch, dass ein (vermeintlicher) Standard im Internet im Allgemeinen und bei SEO im Speziellen heute noch genauso aktuell sein soll wie 2011 und davor (der hier verlinkte Kommentar bezieht sich auf diesen Zeitraum). Ironie: Wenn mich jemand fragen würde, was heute noch wie damals gilt dann würde ich spontan „semantisches HTML“ sagen.
    Sonderlich auch die Formulierung „eine neue Verwendung der Überschriften-Tags nicht Inhalt unseres heutigen Relaunches war.“ Weil zu aufwändig, aus SEO-Gründen oder weil man es nicht auf dem Schirm hat?

    Bei allen Verständnis für die Probleme, der Blick unter die Haube spiegelt genau das Bild wieder, welches ich vom Online-Journalismus in diesem Lande habe: Er ist nicht zeitgemäß. Und er ist nicht innovativ.

  7. Wenn ich in Ihrem Text erfahre, dass Sie Code mit Hilfe eines Grunt-Prozesses validieren, im gleichen Absatz jedoch „korrkete“ lesen muss, dann frage ich mich, weshalb Sie nicht auch Ihre Rechtschreibung mit einer Rechtschreibprüfung prüfen? Wer im Glashaus sitzt … Wobei: eine Rechtschreibprüfung würde auch der Süddeutschen Zeitung gut tun 🙂

    • Meine Artikel schreibe ich für gewöhnlich im Texteditor in Markdown. Der kennt keine Rechtschreibprüfung. In diesem Fall habe ich ihn sogar zweimal gelesen, aber einzelne Fehler rutschen immer wieder durch. Entwertet das jetzt den Artikel?

      • ähh..soviel zu deiner code qualität…

        F-LOG-GE

        • Ich verstehe den Witz nicht. Ausserdem möchtest Du jetzt nicht die Qualität eines Standardtemplates mit Handarbeit vergleichen, oder? Du könntest mir jetzt natürlich vorwerfen, dass ich mein Template nicht selber schreibe. Aber das trägt zur eigentlichen Diskussion auch nicht viel bei und kann auch schlecht meine Argumente entkräften. Oder?

  8. Hallo Herr Sander,

    da auf zeitung.sueddeutsche.de verwiesen wurde ein paar Hinweise: Leider hat der Registrierungsprozess hat ebenfalls Mängel.

    Der Seitentitel ist unvollständig, die Tabreihenfolge ist nicht korrekt (Ursache ist möglicherweise tabindex mit Werten größer 0. Sofern man hier tabindex > 0 überhaupt verwenden möchte, dann muss man das für _alle_ Links und Steuerelemente einer Seite tun). Zumindest in FF, mit IE habe ich nicht geschaut, scheint die „Adressänderung“ mit der Tastatur gar nicht erreichbar. Den Label-Elementen – sofern vorhanden – fehlen for=““ und id=““; Screenreader werden daher die Bedeutung der Eingabefelder nicht ansagen. Und ich denke, dass die Strukturierung über Legend statt H4 ebenfalls besser wäre.

    Soweit nur ein wirklich ganz kurzer Blick. Da man im Quellcode einiges an ARIA sieht, kann man davon ausgehen, dass das Formular nicht so ganz alt ist und mindestens einmal in der jüngsten Vergangenheit überarbeitet wurde. Auch hier wäre eine korrekte Überarbeitung angeraten (gewesen) und müsste im Rahmen der Kundengewinnung zudem im Interesse der Süddeutschen sein.

  9. Ich habe gerade gesehen, dass für strong-Tags eine extra Schrift geladen wird. Ein SZBold Font. Leider ist das Rendering des Fonts derart schlecht (Firefox, Mac OS X), dass ich mir wünschte, dass stattdessen ein guter Boldschnitt oder aber wenigstens nur ein faux-bold Schnitt des Browsers genutzt wird.

    Das Argument, die vielen Font-Schnitte wegen der hochwertigeren Schriftrenderings zu nutzen, halte ich daher für falsch.

  10. Audits sind so beliebt wie früher Berater: Draufsicht auf Prozesse, die nur versteht wer drin steckt, sind leider oft wohlfeile Wortmeldungen zu einem fertig iterierten Produktzyklus. Früher war es mit den Beratern so: eh‘ man sich’s versah sind die bezahlt und wie Heuschrecken weiter gezogen. Hinterlassen haben sie meist nur was wiederum von Investoren filetiert und veräußert werden konnte. Das die Süddeutsche den Kommentar überhaupt wahrnimmt finde ich schon mal erstaunlich und bemerkenswert. Und das die Kritik nicht nur abgetan wird sondern berechtige angetan aufgenommen werden zeugt doch von einer anderen Kultur. Deutsche, insbesondere Zeitungsleser, sind keine dankbare Zielgruppe. Gerade überregionale Publikationen kämpfen mit Jahrzehnte lang an sich gebundene Leser, die zum Teil viele, viele Jahre alte Hardware einsetzen oder ihre Infrastruktur nur widerwillig auf dem Laufenden halten. Sie sind wiederum wie die gefühlte Ewigkeiten und also unkündbar im Unternehmen verankerte Resignatoren, die schon alles gesehen haben und auch das überleben wollen. Man kann oder will nicht ohne sie, wie etwa Abonnenten der Wochenendausgaben, die man zwar regelmäßig von den Vorzügen eines herkömmlichen Abos unterrichtet, aber irgendwie schon ahnt, das die seit Jahrzehnten passiven Leser noch ein paar Jahre mit dem Status Quo hadert und schließlich dran gibt oder drunter liegt. Lange Schreibe, kurzer Sinn: Die auf mobile Besucher zugeschnittene Seite wird die veranschlagten 3 MB sicherlich nicht aufweisen, altgediente Leser haben eine Alternativer der Form der klassischen Website und die anderen Besucher haben offenbar inzwischen alle nach oben offenen Datendurchsatz und Festplatten, die vom Browser bis Ende Abschreibung nicht vollgeschrieben bekommen, selbst wenn sie jetzt anfangen jedes html5-Video in x Formaten zu speichern.