Dieser Artikel ist meine Übersetzung von „Lame excuses for not being a Web professional“, den Roger Johanson in seinem Blog 456Bereastreet veröffentlicht hat. Ich kann dem nur zustimmen, denn das gleiche erlebe ich genauso fast jeden Tag.

Hier der Text von Roger Johanson:

Schlechte Ausreden, kein Web-Profi zu sein

Zeit sich aufzuregen. Ich muss mal Frust abbauen. Frust, der von Leuten und Haltungen kommt, die mir in meiner täglichen Arbeit begegnen, von Kommentaren auf dieser Seite und von Artikeln, die ich anderswo lese. Mich frustriert, dass die Webindustrie überschwemmt wird von faulen, ignoranten, unfähigen Leuten, die anscheinend nicht im geringsten interessiert sind zu lernen, wie man Dinge ordentlich erledigt.

Wer solche Ausbrüche nicht mag: nicht weiterlesen. Wer allerdings etwas an Tiraden findet – und daran Webseiten zu bauen, die für so viele Leute wie möglich funktionieren – der könnte das hier mögen. Besonders, wenn man genauso von den Ausreden genervt ist, die Leute vorbringen, wenn sie sich nicht bemühen, immer so gut zu arbeiten wie sie können.

Visuelle Konsistenz

Ah, die Ausrede Nummer 1 dafür, es den Usern schwerzumachen. Farbige Scrollbalken? Nicht erkennbare Formularelemente? Nicht auszumachende Links? Unlesbarer Text? Die Liste lässt sich fortführen. Diese Ausrede wird gewöhnlich von visuell ausgerichteten Flash-Designern vorgebracht oder von Art-Direktoren aus Werbeagenturen, die Designs vorgeben, die schlicht im Web nicht funktionieren. Anstatt ihr Design anzupassen, wenn sie auf Probleme stoßen, machen sie dickköpfig weiter. Wodurch wir User mehr als nötig nachdenken müssen und uns schwerer tun, wenn wir deren Sites benutzen. Wenn euer Design – oder ihr als Designer – nicht damit umgehen könnt, dass das Web das Web ist, bitte: Tut allen einen Gefallen und bleibt bei der Sicherheit eurer gedruckten Broschüren.

Tolles Nutzererlebnis

Immer wenn ihr jemanden sagen hört: „Tolles Nutzererlebnis“: lauft weg. Nur zu oft bedeutet „Tolles Nutzererlebnis“, dass die Site vollgepackt ist mit sinnlosem Flash-Gedudel und/oder fertigen Javascript-Effekten, die jede Chance zunichte machen, dass der User auf der Seite irgendwas geregelt kriegt. Wer viel von gutem Nutzererlebnis redet, hat meistens überhaupt keine Ahnung von Usability oder Interaktionsdesign. Komisch, nicht?

Zielgruppe

Es ist offensichtlich gut, über die Zusammensetzung der Leute Bescheid zu wissen, die man erreichen möchte. Aber jedesmal, wenn ich jemanden „Zielgruppe“ sagen höre, gehen bei mir die Alarmglocken an. „Zielgruppe“ ist in der Hand der falschen Leute eine gefährliche Waffe. Viel zu bequem kann man damit rechtfertigen, so ziemlich jede Nutzergruppe auszuschließen. Dann hört man so etwas wie „Unsere Zielgruppe benutzt keine Macs.“, „Wir haben keine behinderten Kunden.“, „Niemand in unserer Zielgruppe hat Javascript abgeschaltet.“, und „Alle in unserer Zielgruppe haben schnelle Computer, DSL und Flash.”. Diese Behauptungen sind natürlich fast nie durch Tatsachen belegt.

Es ist eine Sache, sein Design so zu optimieren, dass sie die Hauptzielgruppe anspricht und für sie gut funktioniert. Man muss aber sehr gut, nein, überaus exakt wissen, wer genau die Seite besuchen wird, womit er das tut und unter welchen Umständen das passiert, wenn die Designentscheidungen dazu führen, dass andere die Site nur schwer oder gar nicht benutzen können. Das ist das Web. Das einzige, was man weiß, ist dass man nicht weiß, wer kommt.

Statistik

Diese Ausrede ist ein naher Verwandter der „Zielgruppe“-Ausrede. Leute, die sich so herausreden, möchten die Zahl derjenigen möglichst unerheblich erscheinen lassen, die genau wegen schlechter Design- oder Technikentscheidungen abgewiesen werden. Das geht so: Man teilt die Gesamtmenge aller derer, die die Site nicht vernünftig benutzen können, in kleine Gruppen, von denen jede als vertretbarer Kollateralschaden angesehen werden kann. Wer die Zielgruppen-Ausrede anbringt, lässt seine (schlechte) Wahl von Design und/oder Technik entscheiden, wer die Zielgruppe ist.

HTML-unfähige Entwicklungsumgebungen und Frameworks

Aus Gründen, die ich nicht verstehe, hängen anscheinend viele Back-End-Entwickler vollständig davon ab, dass eine Entwicklungsumgebung oder ein Framework ihren Frontendcode erzeugt. Es sieht so aus, als ob HTML, CSS und JavaScript viel zu kompliziert für die meisten Back-End-Entwickler sind. Und das ist wirklich schade, weil die meisten Umgebungen einfach nur lächerlichen Frontend-Code erzeugen.

Es ist doch so einfach: Ihr seid Programmierer. Ihr solltet intelligent genug sein, HTML, CSS und Javascript zu lernen. Wenn eure Entwicklungswerkzeuge nur Müll ausgeben, lasst das nicht zu. Zwingt sie, vernünftigen Code abzuliefern.

Das ist die Wirklichkeit in meiner täglichen Arbeit. Eins unserer Content-Managment-Systeme basiert auf ASP.NET, mit dem ganzen schlampigen Front-End-Code, den das mit sich bringt. Wir umgehen das einfach. Wenn wir das nicht könnten, würden wir etwas anderes benutzen. Das solltet ihr auch tun. Akzeptiert nicht, dass eure Entwicklungswerkzeuge von sich aus Müll erzeugen.

In der Wirklichkeit

Manche entkräften gern diese Argumente von Leuten, die das Web verbessern wollen (wie uns) damit, dass wir keine richtige Arbeit haben, und dass wir keine echten Sites für echte Leute bauen. Also, ich kann versichern, dass ich – und jeder den ich kenne, der die gleichen Ideale vertritt – echte Jobs haben mit echten Kunden und echten Deadlines. Der Unterschied ist, dass wir (ok, ich – ich möchte niemandem etwas in den Mund legen) das, was wir tun als Handwerk betrachten und ehrlich danach streben, immer erstklassige Arbeit abzuliefern.

Funktioniert doch

„Funktioniert doch“ heißt in Wirklichkeit „Es funktioniert mit den Standardeinstellungen in meinem Browser, in dem meines Vorgesetzten und im Browser des Kunden. Das reicht mir. Ich will jetzt nach Hause und fernsehen.“

Warum arbeitet ihr im Internetgeschäft, wenn es euch nicht interessiert? Dann grillt doch lieber Burger bei McDonalds.

Einige Ausreden kann man gelegentlich gelten lassen

Einige dieser Ausreden kann man gelegentlich gelten lassen, aber nur in sehr besonderen Ausnahmefällen. Das Störende dabei ist, dass mit diesen Ausreden in den allermeisten Fällen nur Faulheit und mangelnde Fachkenntnisse verdeckt werden sollen.

Eins noch: Ich weiß, dass es sehr fähige Webentwickler gibt, die manchmal eine der genannten Ausreden benutzen. Aber auf euch hacke ich nicht herum.

Was für schlechte Ausreden gibt es noch?