Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Darf man nicht? Darf man wohl!

Meinung: Ausnahmen von Best Practices

Darf man nicht? Darf man wohl!

Geht nicht! Gibt’s nicht! Darf man nicht! Bei bestimmten Themen weiß jeder Webworker reflexartig, was sich gehört und wie man es richtig macht. Alles andere ist böse! Darf das HTML oder CSS vielleicht auch mal nicht validieren? Darf ein Webworker target="_blank" nicht doch benutzen? Darf er nicht? Doch, darf er. Wenn er einen guten Grund dafür vorweisen kann.

HTML und CSS müssen validieren

Nö, aktuell müssen HTML und CSS nicht unbedingt in jedem Fall validieren. Oder genauer: Es kommt darauf an. HTML und CSS entwickeln sich laufend weiter. Unter Umständen ist der Validator bei bestimmten Elementen nicht auf der Höhe der Zeit. Bzw. ändern sich einige Schemata so schnell, dass der Validator nicht nachkommt. Etwa beim Thema RDFa. Auf Wikipedia ist aktuell ein Beispiel für HTML 5 + RDFa 1.1 zu finden. Ergänzt um den HTML5-Doctype lautet es:

  1. <!DOCTYPE html>
  2. <html prefix="dc: http://purl.org/dc/elements/1.1/" lang="en">
  3.   <head>
  4.     <title>John's Home Page</title>
  5.     <base href="http://example.org/john-d/" />
  6.     <meta property="dc:creator" content="Jonathan Doe" />
  7.     <link rel="foaf:primaryTopic" href="http://example.org/john-d/#me" />
  8.   </head>
  9.   <body about="http://example.org/john-d/#me">
  10.     <h1>John's Home Page</h1>
  11.     <p>My name is <span property="foaf:nick">John D</span> and I like
  12.       <a href="http://www.neubauten.org/" rel="foaf:interest"
  13.         lang="de">Einstürzende Neubauten</a>.
  14.     </p>
  15.     <p>
  16.       My <span rel="foaf:interest" resource="urn:ISBN:0752820907">favorite
  17.       book is the inspiring <span about="urn:ISBN:0752820907"><cite
  18.       property="dc:title">Weaving the Web</cite> by
  19.       <span property="dc:creator">Tim Berners-Lee</span></span>
  20.      </span>
  21.     </p>
  22.   </body>
  23. </html>

Der HTML-Validator aber meldet drei Fehler und sechs Warnungen. Auch Beispiele des W3C zum RDFa Core 1.1 validieren nicht. Wer Zeit und Muse hat, kann sich näher einarbeiten und findet vielleicht eine Variante, die der Validator kennt und akzeptiert. Aber auf größeren Webseiten werden die Autoren ja nicht alle Elemente selbst per Hand eintragen. Das wird ein entsprechendes RDFa-Modul übernehmen. Statt daran rumzuschrauben, kann es viel einfacher sein, auf ein Update des Moduls und/oder des Validators zu warten. In der Zwischenzeit validiert die Seite eben nicht.

Ergebnis im Validator des W3C
Das Ergebnis des RDFa-Beispiels im Validator des W3C

Hinweis: Es existiert auch ein eigener RDFa Validator. Der meldet bei dem Wikipedia-Beispiel zwar keinen Fehler, prüft aber auch nur das RDFa und nicht den Rest einer HTML- oder XML-Datei.

Ähnliches gilt für CSS. Wir nutzen für viele Eigenschaften noch Browser-Prefixes. Beispielsweise für Transitions, damit diese in möglichst vielen Browsern korrekt funktionieren. Da die Prefixes Erweiterungen der Browserhersteller sind, die nicht zum Standard gehören, können diese zwangsläufig nicht validieren. Immerhin werden sie nur als Warnung angezeigt. Der CSS-Validator produziert also trotzdem ein ersehntes: Dieses Dokument wurde als CSS level 3 validiert!

Anders verhält es sich bei experimentellen Features: neuen CSS-Eigenschaften in einem frühen Draft oder auch Ideen einzelner Browser-Hersteller. Wer sich zum Beispiel näher mit Typografie beschäftigt, wird eventuell auf die Eigenschaft text-rendering aufmerksam. Vielleicht sorgt diese Eigenschaft bereits jetzt schon in modernen Browsern für eine bessere Lesbarkeit. Grund genug sie auch einzusetzen. Allerdings wird der CSS-Validator melden: Die Eigenschaft text-rendering existiert nicht. Und damit validiert das CSS nicht mehr.

Rendering der Wörter »Web Validator Tastatur ff fi«
Anzeige via text-rendering mit den Werten optimizeLegibility, optimizeSpeed und geometricPrecision in Chrome

Das heißt: In weiten Teilen und auf »normalen«, »einfachen«, »üblichen« Webseiten sollten HTML und CSS tatsächlich validieren, ja. Aber bei einigen Projekten mag es interessant sein, mit neuen Möglichkeiten zu spielen, die vielleicht nur in manchen Browsern funktionieren – und auch nicht validieren.

Der Validator ist nur ein Werkzeug. Es ist unser Job, richtig damit umzugehen; und die angezeigten Fehler und Warnungen zu verstehen und entsprechend einzuordnen.

target="_blank" gehört verboten

Unter Webworkern hat es sich durchgesetzt, dass allein der Besucher entscheiden soll, ob sich ein Link in demselben oder einem neuen Fenster (Tab) öffnen soll. Insofern gilt erst einmal: das Relikt target="_blank" nervt und gehört verboten.

Eine Ausnahme geben Kunden vor. Wenn die eine Liste mit Partnern auf ihrer Webseite pflegen, kommen sie irgendwann auf die Idee, dass sich solche Links doch bitte in einem neuen Tab öffnen sollen. Da können wir dann argumentieren. Manchmal gewinnen wir, manchmal gewinnt der Kunde. Als Dienstleister fügen wir wenn nötig eben das target="_blank" ein; auch wenn wir es selbst anders handhaben würden.

In einem Fall aber finde ich target="_blank" sogar sinnvoll. Und zwar immer dann, wenn Links in der Nähe eines Formulars vorkommen. Wir haben unten in den Kommentaren unsere Hausregeln und die Gravatare verlinkt. Auf anderen Webseiten können das Hinweise zum Datenschutz oder Hilfen für HTML-Formate sein. Für erfahrene Webworker ist das kein Problem. Die nutzen automatisch STRG + Mausklick (oder ⌘ + Mausklick). Aber ich habe schon mehrere Projekte betreut, bei denen sich die Kunden beschwert haben, dass der Text »plötzlich« verschwindet, nur weil sie auf einen der Links geklickt haben. Es kann nämlich passieren, dass die das Formular schon ausfüllen, und später erst auf die Idee kommen, auf den Link zu klicken. Hier sorgt target="_blank" zumindest dafür, dass der Text in den Formularen erhalten bleibt. In diesem Fall ziehe ich die Usability für unerfahrene Nutzer vor.

Alternativ könnten wir solche Links natürlich auch per JavaScript in einer Lightbox öffnen. Dann bleibt der Text im Formular ebenso erhalten. Aber dann bräuchten wir trotzdem eine Lösung, falls JavaScript ausgeschaltet wäre.

Insofern: target="_blank" ist zwar eigentlich böse, wird aber in bestimmten Fällen explizit gewünscht und kann sogar nützlich sein.

JavaScript richtig einbinden

An welcher Stelle packen wir unser JavaScript auf die Seite? Am besten in den Fuß, kombiniert mit all den anderen JS-Dateien und ordentlich minifiziert. Natürlich, das ist besser für die Performance.

Auch hier bestätigen Ausnahmen die Regel. Die Bibliothek Modernizr zum Beispiel empfiehlt, das JavaScript im <head> einzubinden (weil 1. das HTML5 Shiv vor dem <body> ausgeführt werden muss und 2. ein Flash Of Unstyled Content vermieden werden soll).

In Content-Management-Systeme kann es – abhängig von den installierten Modulen – vorkommen, dass die JavaScripte nicht mehr funktionieren, wenn sie erst im Fuß eingebunden werden. Das spricht manchmal für ein schlecht programmiertes Modul. Aber in der Regel will ich ja keine Module überarbeiten, sondern Webseiten bauen. Dann stehen die JavaScripte eben im <head> – auch wenn es der Best Practice widerspricht.

Es gibt auch (seltene) Fälle, in denen JavaScripte nicht mehr richtig arbeiten, wenn sie minifiziert und kombiniert werden. Das deutet erst recht auf ein schlecht geschriebenes Modul hin. Hier gilt es also abzuwägen: Brauche ich das Modul? Bin ich in der Lage, es selbst zu verbessern? Wird mir die Zeit dafür bezahlt? Oder verzichte ich aufs Minifizieren/Kombinieren und hoffe, dass sich niemand den Quellcode anschaut?

Pixel-Größen für Schriften sind böse

Eigentlich seltsam, dass das (in dieser Form) immer noch kursiert. Früher sind wir brav auf em-Werte für Fonts umgestiegen, weil die Internet Explorer keinen reinen Text-Zoom bei Pixel-Werten hinbekommen. Das hat uns beim schon IE6 genervt, aber auch die IE 7 bis 9 scheitern daran kläglich.

Allerdings hat sich die Zoom-Situation in den letzten Jahren grundlegend geändert. Während wir zunächst überall einen reinen Text-Zoom hatten, haben alle Browser mittlerweile standardmäßig auf einen Seiten-Zoom umgestellt. Und wenn wir die komplette Seite vergrößern, wächst eben auch die Schrift mit. Im Sinne der Barrierefreiheit und WCAG 2.0 sind Pixel-Angaben im Zusammenspiel mit dem Seiten-Zoom durchaus ok.

Genauer: Der Seiten-Zoom reicht für die Stufe AA der WCAG 2.0. Bei AAA hingegen ist kein waagerechter Scrollbalken mehr erlaubt. Wenn also AAA angepeilt wird, dann sind Zoom-Layouts meist nicht mehr ausreichend. AA ist jedoch weitgehend Standard, beispielsweise auch in den kommenden EU-Vorgaben für Ausschreibungen im ICT-Bereich, die im Rahmen von Mandat 376 entstehen.
Es kommt also auf das konkrete Projekt an und nach welchem Maßstab die Barrierefreiheit geprüft wird. Beim BITV-Test etwa muss auch die reine Textvergrößerung bei 150% – bzw. »Schriftgrad am größten« im IE – erfüllt sein (entgegen WCAG 2.0, die von 200% spricht).

Insofern sind Pixel-Größen nicht mehr grundsätzlich böse. Durch den Seitenzoom ist die Barrierefreiheit sogar erst einmal erfüllt. Allerdings können wir es besser machen, wenn wir auch den reinen Text-Zoom berücksichtigen wollen (oder müssen).

Die Website muss perfekt werden

Bei vielen Projekten können wir uns schnell davon verabschieden, auch nur im Ansatz an einem »Perfekt« zu kratzen. Aus Zeit- oder Budgetgründen holen wir ohnehin »nur« das Beste heraus, was zu machen ist. Und haben im Kopf eine lange Liste von möglichen Verbesserungen im Detail. Bei unseren eigenen Projekten sieht es schon ganz anders aus. Wir wissen ja, worauf es ankommt. Was wir alles bedenken wollen und sollten. Und vor allem: Was, wenn die Kollegen da mal genauer hinschauen? Da können wir ja nicht etwas nur Fast-Fertiges ins Web stellen. Das muss schon Hand und Fuß haben!

Ja, bis zu einem gewissen Grad muss es das. In erster Linie aber gilt: Hauptsache online. Alles andere können wir auch im laufenden Betrieb verbessern. Sonst würde dieser Adventskalender zum Beispiel auch noch im alten Design erscheinen. Die perfekte Webseite gibt es ohnehin nicht.

Kommentare

Susanna Künzl
am 17.12.2012 - 08:34

Ein erfrischendes Plädoyer für das sinnvollerweise Machbare. Wer möchte schon Features wie RDFa abschalten, nur damit die Seite validiert.

Permanenter Link

David
am 17.12.2012 - 10:12

»In einem Fall aber finde ich target="_blank" sogar sinnvoll. […]«
Das läuft aber genau so auf Bevormundung hinaus, wie bei jedem anderen »guten Grund«. Wenn sich jemand darüber beschwert, dann kläre ihn über die bestehenden Möglichkeiten seitens des Browsers auf (Strg + Klick, Mittlere Maustaste). Im Übrigen: welcher Browser behält Formulareingaben denn nicht, wenn man wieder auf die Formularseite zurück kehrt?

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Autor)
am 17.12.2012 - 10:31

Das läuft aber genau so auf Bevormundung hinaus, wie bei jedem anderen »guten Grund«.

Ja, das nimmst du so wahr. Die Kunden, bei denen ich das so mache, halten das aber für guten Service.

Wenn sich jemand darüber beschwert, dann kläre ihn über die bestehenden Möglichkeiten seitens des Browsers auf (Strg + Klick, Mittlere Maustaste). Im Übrigen: welcher Browser behält Formulareingaben denn nicht, wenn man wieder auf die Formularseite zurück kehrt?

User aufklären? Das funktioniert natürlich bei einigen. Aber es ist schlicht realitätsfern anzunehmen, dass das bei allen klappt. In manchen Fällen gibt es ja schon Verwirrung beim Unterschied zwischen Website-URLs und E-Mail-Adressen. Nicht alle Leute nutzen einen Zurück-Button, die klicken sich erneut über die Navigation zum betreffenden Formular. Das ist eine Frage der Zielgruppe, ob du mit Aufklärung weiterkommst.

Permanenter Link

Roland
am 17.12.2012 - 20:04

Ich finde target="_blank" sogar meistens sinnvoll. Es ärgert mich jedesmal, wenn, nur weil ich auf einen Link klicke, die aktuelle Seite verschwindet. Und nur, weil einige Schlaumeier das für richtig halten, muss ich jetzt beidhändig surfen, um neben der Maus- auch die Strg-Taste zu drücken. Bezüglich der Bevormundung fühle ich mich bevormundet, wenn der Webdesigner auf target="_blank" verzichtet - sei es aus Faulheit oder weil er sich von einem "das ist aber besser so" bevormunden lässt. Ich wünsche mir einen Browser, bei dem ich target="_blank" als per Voreinstellung dauerhaft aktivieren kann. Das wäre dann wirkliche Befreiung von jeglicher Bevormundung.

Permanenter Link

Mathias
am 17.12.2012 - 23:01

In FF oder Chrome: Rechtsklick, dann "Link in neuem Tab öffnen", und Du hast Deine 1-Hand-Lösung. Alternativ: Firefox mit dem Add-On Tab Mix Plus, dann kannst Du das voreinstellen.

Permanenter Link

Christian
am 18.12.2012 - 13:25

Einhandlösung => Mittlere Maustaste

Man kann sogar damit die Tabs wieder schließen :-)

Permanenter Link

Humppa
am 18.12.2012 - 13:07

Ich bin mir nicht sicher, ob das Standard ist; kann mich zumindest nicht erinnern, dass jemals aktiviert zu haben. Ich klick immer mit dem Mausrad auf ein Link, um ihn in einem neuen Tab zu öffnen.

Permanenter Link

nikosch
am 19.12.2012 - 16:47

„Ich wünsche mir einen Browser, bei dem ich target="_blank" als per Voreinstellung dauerhaft aktivieren kann.“

Ähm, und wie soll das aussehen? Das jeder Link auf der Website, jeder Navigationspunkt etc. einen neuen Tab öffnet?! Na das klingt ja irre praktisch.

Permanenter Link

nikosch
am 19.12.2012 - 16:44

Also mir passiert das regelmäßig in irgendwelchen Wordpress-Kommentarfeldern, dass die im Jahr 2012 nichts von Affenformular gehört haben und Eingaben nach dem Back-Button („benutzen sie bitte zurück und passen sie das Captcha an“) alles vergessen haben.

Zum Thema target in diesen Fällen: Dann bitte aber auch den Link mit einem entsprechenden Hinweis versehen („AGB bestätigen. Link öffnet ein separates Fenster)“). Denn sonst hat man trotzdem eine Unsicherheit. Gerade einige JS-basierte „Popups“ haben auch die Eigenschaft, wiederum mit einem „in neuem Tab öffnen“ zu kollidieren.

Permanenter Link

Sven
am 17.12.2012 - 11:01

Fragt euch mal, für wen die Seiten gebaut werden? Für Validatoren & der Möglichkeit, sich einen hässliche Grafik auf der Seite zu setzen, Validiert nach W3C? Oder baut Ihr Seiten für die User, denen W3C schon gar nichts sagt? Sicher sollte man sich stark wie möglich an den Standart halten, aber die Browserhersteller machen es ja auch nicht 100%.
Also im Zweifelsfalle immer für den User.. ;)

Permanenter Link

Tekl
am 17.12.2012 - 11:17

Die Target-blank-Diskussion ist ja eigentlich schon ziemlich angestaubt. Ich bin mittlerweile wieder zurückgerudert. Die meisten Kunden wollen eh, dass externe Links in neuen Fenstern/Tabs geöffnet werden und auch heute noch nehme ich wahr, dass ein Großteil der Nutzer entweder nicht weiß, dass man Links in einem neuen Tab öffnen kann oder zu bequem sind, diesen Extraschritt auszuführen. Bei einer Diskussion herrscht die Ansicht vor, dass es doch auf vielen Webseiten auch ohne Überlegen geht und das Verhalten der Seite ohne target="_blank" (oder Alternativen) wird oft als Fehler angesehen. Ich kenn allerdings auch den anderen Fall, dass erwartet wird, dass die Zurück-Schaltfläche im Browser immer zu funktionieren hat und Tabs gar nicht wahrgenommen werden. Wie überall im Leben; man kann's nicht allen recht machen.

Zur Perfektion von Websites könnte man – auch selbstkritisch – differenzieren, warum diese Perfektion überhaupt angestrebt wird. Sicher nicht selten rührt sie aus einem gewissen Mangel an Selbstbewusstsein des Webentwicklers her, der sich mit einer perfekten Seite unangreifbar machen möchte. Findet jemand einen Fehler, wird das als persönlicher Angriff aufgefasst und es ist ein mehr oder weniger großer emotionaler, unangenehmer Kraftakt, sich da rauszuwinden. Da wird dann eifrig argumentiert und hitzig gerechtfertigt oder es werden still und heimlich mit schlechtem Gefühl Nachtschichten eingelegt. Websites sind ja besonders verheerend, da sie jederzeit überprüfbar sind und eben auch den „Quellcode“ immer offen mitliefern und somit viele „innere Werte“ preisgeben. Dass gelegentlich auch mal negativ über Resultate von „Kollegen“ getwittert wird kann da sicher noch mehr Ängste schüren, da es da dann plötzlich auch ein Stück weit in die öffentliche Reputation reicht, welche nachvollziehbar bleibt. Wer da nicht auf sich selbst aufpasst und sich einzig mit seiner Arbeit identifiziert unterliegt einem erhöhten Risiko daran irgendwann zu erkranken.

Insgesamt ein schöner Artikel, der wichtige Aspekte anspricht und auch etwas Menschlichkeit und Realismus in die Fülle von Fachartikeln bringt, die ja eben doch oft von Perfektion und Regelerfüllung geprägt sind. Das liegt natürlich in der Natur der Sache.

Permanenter Link

Peter
am 17.12.2012 - 14:43

Den Argumenten von Tekl möchte ich mit einige Aussnahmen zustimmen.

Die Diskussion um das berüchtigte "target" halte ich genauso wenig für zielführend, wie die Diskussionen um das "beste" Betriebssystem", den "besten Browser " oder um Geschmacksfragen beim Design. Da sollte jeder mit seiner Herangehensweise oder Ansicht glücklich werden können.

..nicht selten rührt sie aus einem gewissen Mangel an Selbstbewusstsein des Webentwicklers...

Das halte ich für ziemlich starken Tobak und auch recht unfair anderen Kollegen gegenüber. Könnte es vielleicht sein, dass der Eine oder Andere Spaß an seiner Arbeit hat und stolz darauf ist, wenige Fehler zu machen? Darf man im Gegenzug stolz darauf sein - weil ja tolles Selbstbewußtsein - dass man eben nicht fehlerfrei arbeitet?

Damit meine ich natürlich nicht die "Fehler", die der Validator wegen Unfähigkeit ausspukt oder die wir ganz bewußt in Kauf nehmen, weil es neue Fetaure in den Standards sind. Ich meine hier Unzulänglichkeiten, die eigentlich zu den Basics gehören, die man aber aus welchem Grund auch immer so langsam aber stetig "vergißt". Ein tolles Argument: "Hauptsache online, den Rest machen wir nachher".

Haben wir das nicht schon immer den Machern von Kleinweich vorgehalten, weil sie die User als kostenlose Tester ansahen?
Passiert hier nun nicht das gleiche? Erstmal mit mit dem Slogan "Für mehr Qualität im Web" online gehen und dann auf Zuruf die Mängel beseitigen?

Fehlende Hauptsprache (inzwischen nachgereicht), einen skiplink, den der Nutzuer nicht sehen kann, weil er verdeckt wird und einen scheußlichen Kontrast hat, ungünstige interne Navigation mit Verweis auf den Zurück-Button? Leute, das gehört doch zu den Basics.

Das soll kein Rundumschlag und alles vernichtende Kritik an den Machern sein - auch wenn es wahrscheinlich so empfunden wird. Ich habe große Hochachtung vor den Kolleginnen und Kollegen. Lese ich ihre Blogbeiträge, komme ich mir, fachlich gesehen, sehr klein vor. Und ich verstehe schon, dass wenig Zeit bleibt, sich an überholten Werten eines Berufsstandes zu orientieren, wenn alle nasenlang ein neues rosarotes Tier durch Dorf getrieben wird.

Yeoman, Fireworks, Sass, ProcessWire, Grunt, Brackets, SublineText, Grids und wie die Tools auch heißen - alles sicher tolle Dinge, die dem gestressten und unter Zeitdruck stehenden Web Worker helfen, das Berufsleben leichter zu machen. Und vielleicht verständlich, dass bei soviel Effizenzstreben dabei schon mal die Basics unter die Räder kommen - kein Problem.

Sich aber selbst so großes Selbstvertrauen - man könnte das auch ganz anders nennen - zuzugestehen, dass man einfach mal über eigene Fehler erhaben ist, ist die eine Seite. Anderen aber das Selbstvertrauenm abzusprechen, eher müde lächelnd auf sie herab zublicken, nur weil sie Perfektion - was immer das dann auch bedeutet - anstreben, finde ich ziemlich daneben.

Nix für ungut...

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Autor)
am 17.12.2012 - 15:29

Passiert hier nun nicht das gleiche? Erstmal mit mit dem Slogan "Für mehr Qualität im Web" online gehen und dann auf Zuruf die Mängel beseitigen?

Fehlende Hauptsprache (inzwischen nachgereicht), einen skiplink, den der Nutzer nicht sehen kann, weil er verdeckt wird und einen scheußlichen Kontrast hat, ungünstige interne Navigation mit Verweis auf den Zurück-Button? Leute, das gehört doch zu den Basics.

Ich habe den Artikel absichtlich allgemein gehalten. Aber weil du dich auf die Seite beziehst: Jeder Webworker dürfte seine eigenen Vorstellungen haben, was zu den Basics gehört und was nicht. Da hatte ich also die Sprachangabe vergessen, der Skiplink ist doof, und ein Dutzend anderer Dinge. Sollte deshalb die Seite nicht online gehen? Mit einem Slogan wie »Für mehr Qualität im Web« lehnen wir uns natürlich aus dem Fenster. Aber immerhin gibt es aktuell sehr viel weniger zu kritisieren als noch vor einem Monat. Bei großen Websites, an denen mehrere Leute wochenlang arbeiten, lege ich auch andere Maßstäbe an. webkrauts.de lebt von freiwilligem (unentgeltlichen) Engagement. Zumindest ich habe deshalb kein Problem mit »work-in-progress«.

Permanenter Link

Nina Gerling
am 20.12.2012 - 11:57

An der Stelle mal einfach ein: +1

Es kommt immer auf die Umstände an. Pauschales Verurteilungen/Schlechtmachen der Arbeit von Kollegen halte ich mittlerweile für einen der größten Fehler unserer Branche. Ich habe über die Jahre gelernt, dass man sehr vorsichtig sein sollte, solange man nicht die genauen Umstände (unumstößliche Vorgaben, verfügbare Zeit, verfügbares Budget, problematische Kundeneigenheiten, uvm.) kennt. Wenn die Umstände schlecht sind, kann selbst der beste Webdesigner nur eine mittelmäßige Website produzieren.

Oder mal anders: Oft verdanken wir guten Webdesignern eine mittelmäßige Website an den Stellen, wo - aufgrund der Umstände - unter "normalen" Umständen eigentlich nur eine miserable Website zu erwarten gewesen wäre. Ich habe schon oft erlebt, dass Kollegen freiwillig und unbezahlt ein paar Stunden Mehrarbeit gemacht haben, damit sie bei schrecklichen Projekten zumindest ein Mindestmaß an Benutzerfreundlichkeit unterbringen. Das ist löblich, kann aber nicht zwingend erwartet werden. Vor allem träfe es in diesen Fällen dann wirklich die falschen Leute, wenn pauschal mit Kritik um sich geworfen wird.

Und ja, auch ich baue manchmal Websites die teilweise nicht 100% benutzerfreundlich oder barrierefrei sind. Shit happens. Aber sicher nicht, weil ich mir keine Gedanken gemacht habe, sondern weil es Gründe gab, die verhindern, dass ich so arbeiten kann, wie ich das eigentlich möchte. Diese Gründe sind normalerweise nicht fehlendes Wissen oder Wollen meinerseits, sondern von außen aufgezwungen. Wenn das bei mir so ist, gesteh ich Kollegen zu, dass es bei ihnen vermutlich auch so ein Grund war, falls ich Arbeiten von ihnen sehe, die nicht einwandfrei sind.

Permanenter Link

Tekl
am 17.12.2012 - 18:04

Vielleicht habe ich mich etwas missverständlich ausgedrückt und zu diffus differenziert. Ich wollte nicht pauschal Webworker mit hohem perfektionistischen Ansatz anprangern oder ihnen mangelndes Selbstbewusstsein zuschreiben, sondern zum Nachdenken anregen, weshalb ich ja auch das Wort „selbstkritisch“ mit eingeschoben habe.

Es ging mir ja auch um Kritikfähigkeit, somit sehe ich deinen Umkehrschluss nicht für angebracht. Aber du differenzierst ja selber, wo man nun Perfektion genau ansetzt. Bewusst Fehler des Validators in Kauf zu nehmen steht für mich schon für das gewisse Selbstvertrauen, über das ich sprach und das eben nicht jeder besitzt. Bei deinem Beispiel bleibend, würde eine betroffene Person in eine gewisse Not geraten, wenn jemand ihn auf die Nichtvalidität hinweist.

Ich möchte das ja eben nicht ankreiden und jemanden vorführen, sondern anregen, auch mal darauf zu schauen. Kein Mensch ist ohne Fehler und geringes Selbstvertrauen ist ja nichts verwerfliches oder ein nicht trag- oder nicht behebbarer Mangel, sondern etwas, woran man persönlich arbeiten kann (und nicht mal muss), vor allem durch Übung und Erfahrung. Und selbst dem Menschen mit dem größten Selbstvertrauen wird es nicht gelingen Kritik überhaupt nicht persönlich zu nehmen.

Vielleicht konkretisiere ich mal mit einem spekulierten Beispiel. Angenommen, jemand stellt gerade für sich fest, dass er schlecht mit Kritik umgehen kann oder dass sein Perfektionismus für ihn ungesunde Züge angenommen hat, weil er bis zu Schlaflosigkeit vom Perfektionismus getrieben ist. Er könnte sich nun fragen, was genau dahinter steckt, was ihn dazu treibt und ob es möglich und nötig ist, daran etwas zu ändern und vor allem was er selbst ändern kann statt äußere Umstände verantwortlich zu machen. Es ist sicher nicht leicht, in so einer Situation das überhaupt für sich selbst zu erkennen. Es könnte z. B. die Idee eines Versuchs entstehen, mal testweise bewusst weniger perfektionistisch mit sich und anderen umzugehen, und Risiken in Kauf zu nehmen. Und genau das wollte ich mit meinem Kommentar anstoßen.

Ich bekomme halt immer wieder mal mit, wie unbarmherzig einige mit sich selbst (und auch anderen) umgehen und das unabhängig vom Beruf. Ich habe keine Zahlen oder so, nur ist in meiner Wahrnehmung die Zahl in einer Höhe, dass es mir auffällt. Liegt natürlich auch am Umfeld.

Ich hoffe, ich konnte das nun verständlicher ausdrücken.

Permanenter Link

Peter
am 17.12.2012 - 17:51

Hallo Nikolai,

in erster Linie und zu allererst habe ich auf den Kommentar von Tekl geantwortet. Alles andere ergab sich daraus.

Jeder Webworker dürfte seine eigenen Vorstellungen haben, was zu den Basics gehört und was nicht.

Nun, neben den Basisc hat und darf natürlich jeder Webworker seine eigenen speziellen Interessen haben. Das stelle ich nicht in Abrede. In jeder Branche gibt es aber eben auch die Grundfertigkeiten (die Basics), über die man bei der Arbeit nicht weiter nachdenken muß.
Da mutet es schon etwas merkwürdig an, wenn gerade bei diesen Basics Nachlässigkeiten festzustellen sind. Im Gegensatz dazu bewundere ich Euer Engagement, wenn es um neue Trends geht. Ob die nun alle so wichtig sind, sei dahingestellt bzw. siehe oben.

Die fehlende Hauptsprache kann man nicht mal ebenso vergessen, wenn das in Fleisch und Blut übergegangen ist, oder? Ich denke, sie erschien in Moment nur nicht so wichtig...

Der skiplink ist nicht "doof". Er ist schlicht und ergreifend so nicht benutzbar. Ist Euch das bei der Entwicklung nicht aufgefallen? Wahrscheinlich ward ihr mit Eurem CSS- und JS-Gedöhns so beschäftigt, dass für dieses "Basic" keine Zeit blieb.

Und das "Dutzend anderer Dinge" ist auch übertrieben. Natürlich frage ich mich, worin der Nutzen besteht, dass die Seite über den Kurzlink auf sich selbst verlinkt, warum es keine benutzerfreundliche Navigation innerhalb des Kalenders gibt. Das meine ich u.a. mit Basisc. Wenn so etwas alles in Sack und Tüten ist, kann man sich gern mit seinen "Hobbies" beschäftigen.

Mag ja sein, dass meine Ansichten etwas antiquiert sind, eine Generationsfrage vielleicht. Ob aber dem Web die zunehmende Öberflächlichkeit in vielen Bereichen gut zu Gesicht steht? Zeitgeist?

Aber hier ist nicht der richtige Ort, um das auszudiskutieren. Schließen wir das Thema ab.

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Autor)
am 17.12.2012 - 18:42

Wir können das gerne abschließen, aber ich glaube beim Skiplink gibt es ein Missverständnis.

Der skiplink ist nicht "doof". Er ist schlicht und ergreifend so nicht benutzbar. Ist Euch das bei der Entwicklung nicht aufgefallen?

Der Link ist nur für Screenreader gedacht, und da funktioniert er auch. Ein Nutzer soll den Skiplink gar nicht sehen. Der Start des Hauptinhalts ist ohnehin immer sichtbar.

Permanenter Link

Rainer
am 17.12.2012 - 20:19

Der Link ist nur für Screenreader gedacht, und da funktioniert er auch. Ein Nutzer soll den Skiplink gar nicht sehen.

Warum nicht? Reine Tastaturnutzer (motorisch eingeschränkte Personen, die keine Maus bedienen können) sollen den Skiplink, der für sie nützlich wäre, nur erraten dürfen? Bitte etwas weiter über den Tellerrand hinausschauen, es gibt nicht nur Blinde unter den körperlich Eingeschränkten.

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Autor)
am 17.12.2012 - 21:07

Ah, richtig, die Tastatur-Nutzer. Ja, dann ist das ein Fehler – und wird demnächst korrigiert.

Permanenter Link

Sebastian
am 17.12.2012 - 21:13

Zuerst einmal: ein toller Artikel.
Dann zum Thema Validität: Ich finde alle "Fehler", die man als Entwickler erklären und begründen kann, sind i.O.
Also insbesondere solche bei denen man sagt: "das ist ein neues Feature für den Browser XY" oder "sonst funktioniert das nicht mit Browser XZ".
Ich gehe bei neuen Projekten immer die Meldungen des Validators durch (CSS und HTML) und entscheide dann, was ein echter Fehler und was ein Feature für einen best. Browser ist. Und was evtl. der Kunde extra so gewollt hat.

Permanenter Link

Humppa
am 18.12.2012 - 13:03

"Unter Webworkern hat es sich durchgesetzt, dass allein der Besucher entscheiden soll," - Sollten Webworker es nicht eigentlich so umsetzen, wie der Besucher es will? Will der Besucher denn selbst entscheiden, ob ein Link in einem neuen Fenster/Tab aufgeht? Es ist natürlich abhängig vom Projekt, aber häufig ist es meinem Eindruck nach eine Mehrheit an Nutzer, die erwartet, dass externe Links in einem neuen Fenster/Tab geöffnet werden. Hinzu kommt noch wie bereits erwähnt, dass manche gar nicht wissen, wie das geht. Und generell halte ich die Nutzer, die sich durch "target='_blank'" bevormundet fühlt, für eine Minderheit.

Permanenter Link

Die Kommentare sind geschlossen.