Die unsichtbaren Disziplinen

„Ich bin visuell gesteuert, ich muss das sehen“. Ja, das ist ja schön und gut - und nebenbei nichts Neues. Der visuelle Sinn ist beim Menschen wohl stets der am stärksten ausgeprägte, von Ausnahmen einmal abgesehen. Aber wenn Kunden was „sehen wollen“, um etwas qualitativ zu bewerten, kratzen sie - ohne es zu wollen oder zu wissen - bei Webseiten höchstens an der Oberfläche.

Die unsichtbaren Disziplinen

Irgendwie sind wir doch alle sehr augengesteuert. Wir machen Design-Entwürfe und -Revisionen, bringen Browsern bei, pixelgenau das Design aus Photoshop (in meinem Fall Fireworks) darzustellen und streiten uns um Farben, Bilder und Größen. Wird hier mit heißer Nadel gestrickt, setzen wir alles daran, dass zumindest die Oberfläche der Website schön anzusehen ist. Darunter leidet fast immer das Herz der Website, das, worin die eigentliche Arbeit steckt. Weil das aber kaum ein nicht-Webentwickler sehen kann, nenne ich dieses Herz

Die unsichtbaren Disziplinen eines Webworkers

Barrierefreiheit - oder: schon mal 'nen Skiplink vermisst?

Barrierefreiheit - „...eine Gestaltung der Webapplikation in der Weise, dass sie von Menschen mit Behinderung in derselben Weise genutzt werden kann wie von Menschen ohne Behinderung.“ (frei nach Wikipedia). Das heißt auch - aber nicht nur - dass beispielsweise Menschen, die gar nicht erst sehen können, was auf dem Bildschirm vor sich geht, die Webseite verstehen und bedienen können. In jedem Fall bedeutet es für den Frontend-Entwickler der konsequente Einsatz von Techniken, welche es assistiven Technologien (wie Screenreader oder Braillezeilen) einfach machen, die Inhalte wiederzugeben. Der Quelltext muss also mehr sein als nur die Grundlage für eine schöne Oberfläche.

Unsichtbare Anreicherungen wie WAI-ARIA-Attribute, Skiplinks und anderes sind gar nicht so zeitaufwändig, werden aber allzu gerne vergessen.
Es soll sogar Fälle gegeben haben, in denen Kunden ein „brauchen wir für unsere Zielgruppe nicht“ geäußert haben. Nunja, darüber kann man streiten und jeder gewissenhafte Webworker wird für Barrierefreiheit einstehen wollen, aber da es hier selten ein Korrektiv oder eine Qualitätssicherung gibt, entscheidet es sich an der Disziplin eines jeden einzelnen Entwicklers.

Und herrje, bereits dieser Abschnitt packt mich an der eigenen Nase und schleudert im hohen Bogen Punkte auf meine Todo-Liste.

Semantik - oder: Nur, weil es so aussieht...

Es versteht sich von selbst, dass ein guter Webworker das HTML-Markup in einer Weise einsetzt und aufbereitet, dass eine Überschrift eine Überschrift, eine Liste eine Liste und ein Absatz ein Absatz ist. Semantik heißt das Zauberwort. Guter Stil, Webstandards und der ganze Kram, der den, der „was mit Medien“ macht vom Profi unterscheidet.

Doch es gibt noch mehr. Von HTML5 Microdata über Microformats bis hinzu Open Graphs und RDFa können Inhalte auf Webseiten noch besser ausgezeichnet werden, es kann ihnen eine noch konkrete Bedeutung und Funktion zugeordnet werden. Das Buzzword „semantic Web“ bekommt hier seine Relevanz.

Kann, nicht muss. Kunden sehen von diesen Implementationen wenig bis gar nichts - zumindest zunächst. Die verschiedenen Standards und teilweise fragwürdige Praxisrelevanz machen die Arbeit, den Code über „normales“ HTML hinaus anzureichen natürlich nicht zur attraktivsten. Aber dennoch können diese Techniken die Usability und Zugänglichkeit deutlich verbessern. Facebook beispielsweise liest Snippets und Vorschaubilder aus den Open Graphs. Suchmaschinen können bei Einsatz von RDFa zu besseren Auszügen kommen und belohnen das möglicherweise mit einem besseren Ranking. Die Anwendung von Microformats auf Adressen oder Veranstaltungen machen es beispielsweise möglich, diese Daten strukturiert direkt in die Kontakte oder den Kalender zu importieren.

Die Anwendungsfälle sind beispielhaft, viele dieser Techniken überschneiden sich und der Weisheit letzter Schluss ist keine von Ihnen. Aber das schlimmste ist: die Notwendigkeit, die Chance und die Arbeit an und mit ihnen wird von den wenigsten AuftraggeberInnen wirklich gesehen.

Coding und Programmierung - oder: viele Wege führen nach Rom

Codequalität, ob HTML, CSS, JavaScript, PHP, MySQL und wie sie alle heißen, hat Einfluss auf Performance, die Usability und nicht zuletzt die Wartbarkeit und Skalierbarkeit „fertiger“ Projekte.

Es ist nicht nur, dass vernünftige Dokumentation und Code-Kommentare die Arbeit am Code für andere Entwickler (und für das zukünftige ich) erleichtern. Es geht auch um die Verständlichkeit der Abläufe, die Namenskonventionen bei Variablen, die grundsätzliche Anwendung von Objekt-orientiertem Programmcode und vielem mehr, was einen hochwertigen Code auszeichnet.

Dabei kann das Ergebnis eines chaotischen Codes und das eines sauberen Codes vornerum auf den ersten Blick identisch wirken. Aber wenn dann die Arbeit daran weitergeführt werden soll, wenn irgendwann größere Anforderungen an das System gestellt werden, wenn sich zeigt, wo tatsächlich Flaschenhälse und Speicherlecks sind, ist die Katastrophe groß.

Dies ist ein Punkt, der insbesondere bei eiligen Projekten sehr stark leiden kann - denn die Website muss einfach erst einmal funktionieren - wie sie dieses Ziel erreicht, steht nicht zur Debatte, die Deadline diktiert die maximalen Arbeitsstunden. Und auch wenn man sich vornimmt, anschließend noch ein wenig Aufzuräumen und ein wenig zu optimieren, so ist bei dieser Arbeit doch viel zu schnell die Luft raus. Und da der Kunde das so haben wollte, auch die Motivation weg.

Optimierung von Medien - oder: was sind schon 300dpi?

Nicht selten fragen mich Fotografen, in welchem Format sie denn das Bild liefern sollen. Ich frage mich dann immer, ob man mir als Webdesigner nicht zutraut, ein JPG zu skalieren oder zu beschneiden.
Naja, es ist ja schön, wenn ich nicht die RAW-Dateien von der Kamera bekomme - schon alleine wegen des Speicherplatz meines E-Mail-Postfachs. Aber dass ich mir ein Bild zurechtschneiden lassen und direkt auf der Website einsetzen kann, ist ebenfalls Utopie.

Es sind nur wenig Handgriffe, die mithilfe von Bildkompressoren und sonstigen Optimierungstools ein Bild so aufbereiten, dass das beste Größen/Qualitäts-Verhältnis erreicht wird. Trotzdem kennen die wenigsten Mediennutzer dieses kleine ein-mal-eins und so bleibt auch diese Leistung des Webdesigners vorerst unsichtbar.

Icons, Icons - oder: nehmen Sie doch das Logo

Der Auszug einer Website beschränkt sich nicht nur auf den Text und ein paar Fotos. Feststehende Identitätsmerkmale wie ein Logo soll gut und gerne auch in Bookmarks, beim Teilen auf sozialen Plattformen oder beim Hinzufügen von Shortcuts auf mobilen Geräten erscheinen. Diese Grafiken müssen erstellt werden - doch an Favicons, Touch-Icons und sonstige grafischen Stellvertreter denken meist weder Designer noch Konzepter.

Interessanterweise zeigt sich hier auch in der neuen modernen Welt voller millionen von Farben und hochauflösender Displays, was ein teuer erstelltes Logo zu leisten vermag. Favicons werden beispielsweise nach wie vor in 16x16 Pixel oben am Browser-Tab angezeigt. Einfach das Logo für diese Größe und dieses Format zu verwenden ist nicht selten ein mehr als unglückliches Unterfangen. Also muss eine Adaption her, eine für eine bestimmte Darstellung optimierte Variante der Markenvisualisierung. Aber auch eins, das in doppelter und vierfacher Größe und/oder Auflösung noch gut aussieht. Und für das Open-Graph-Image gleich mit, bitte.

So selbstverständlich wie das Vorhandensein dieser Elemente sein sollte, so unsichtbar ist oft die Arbeit dahinter.

Responsives Design - oder: mein Bildschirm, dein Bildschirm

Ich kann viel über fluides oder responsives Design erzählen, aber ich glaube, so wirklich begriffen hat das die AuftraggeberInnen-Welt noch nicht. Da kann ich noch so stolz drauf sein, dass die Website sich an alle möglichen und unmöglichen Browsergrößen und Geräte anpasst, bei der Abnahme gilt die Peripherie des/der Geldgeberin.

Natürlich profitieren die unterschiedlichen Besucher von einer Seite, die sowohl auf Smartphones als auch auf Fernsehbildschirmen gut aussieht und bedienbar ist. Und dennoch bleibt die Arbeit dahinter unsichtbar, denn kein Nutzer dieser Welt skaliert - einfach so zum Spaß - die Browsergröße hin und her, vor und zurück, wie es Webworker täglich tun. Für sie ist diese Version der Website die „normale“ Version, die einzige, die es gibt, was soll daran besonders sein?

Touch-Optimierung - oder: streicheln und berühren

„Klicken sie hier“ ist eine Floskel, die jahrelange Tradition hat. Doch mit der Verschiebung zum mobile Web und seinen Touch-Screens ist diese Formulierung so langsam aber sicher nicht mehr das Maß der Dinge.

Eine Bildergalerie, die mit Lightboxen und Navigationspfeilen auf einem Gerät mit Maus sehr gut zu bedienen ist, kommt auf einem Tablet ins Hintertreffen. Hübsch designte, leicht klein geratene Menüpunkte mit tollem Hover-Effekt sind mit Tastatur und Maus noch gut zu bedienen, ein Smartphone hat überhaupt nichts davon.

Es ist bei der Optimierung für Tables und Smartphones also nicht allein mit der Größe getan - auch grundsätzliche Interaktionensschemata müssen überdacht werden. Und das geht teilweise bis in den Text hinein (siehe erstes Beispiel).

Und wie auch beim responsiven Design ist das Bewusstsein für diese zusätzlichen Anpassungen eher gering - sie Optimierungen sind vorhanden, aber unsichtbar.

Druckausgabe - oder: @media print { *{display:none} }

Wenn dann mal eine Design-Abteilung ein finales Layout rüberwachsen lässt, ist damit die Bildschirmansicht oft mehr als ausreichend beschrieben. Doch wie sieht es aus, wenn die BesucherIn der Website zufällig auf Datei => Drucken gelangt? Kann die Druckausgabe mit dem Screendesign mithalten?

Verstehen Sie mich nicht falsch: es geht nicht darum, eine Kopie der Website auf Papier zu bringen, dafür gibt es Screenshots. Es geht darum, die Inhalte für die Druckausgabe so aufzubereiten, dass sie sinnvoll, leserlich und effizient auf ein anderes Medium übertragen werden können. Nämlich (meist) auf ein DIN A 4-Blatt.

Es sind - wie bei einem Mindestmaß an Barrierefreiheit oder Optimierung von Bildern - nicht viele Handgriffe, die eine akzeptable Druckausgabe ermöglichen. Aber auch hier findet sich selten ein/e AuftraggeberIn, die diese Arbeit prüft oder überhaupt bewusst beansprucht. Dabei kann sie für die NutzerInnen der Website von großer Bedeutung werden. Es soll sie ja geben, die Internetausdrucker.

Redaktionssystem erweitern - oder: ein Hebel für den WAU

Der WAU - also der wahrscheinlichst anzunehmende User - ist selten mit der internen Struktur eines Redaktionssystem vertraut. Aber es oder sie soll es bedienen können. Das erfordert eine kleine bis sehr große Anpassung des Systems, so dass Funktionen ermöglicht und andere versteckt werden.

Kürzlich baute ich in ein Wordpress-System eine Funktion ein, die es ermöglichte, einem Beitrag beliebig viele Datumsangaben inklusive Start- und Enduhrzeit hinzuzufügen. Das war nicht ganz ohne. Allerdings war es derart in den nativen Kontext von Wordpress eingebaut, dass man meinen könnte, es habe schon immer dazu gehört.

Darüber hinaus gibt es immer wieder Momente, in denen die Umsetzung einer neuen Funktion auf zwei Ebenen Arbeit verlangt: auf der Ebene für die Besucher und auf der für diejenigen, welche die Funktion über das Redaktionssystem „idiotensicher“ anwenden können müssen. Denn die zweite Seite der Medaille (die interne Funktionalität) entsteht nicht von Geisterhand, auch wenn es oft danach aussieht.

Ninja bleiben - oder doch lieber mit offenen Karten spielen?

Zugegeben, auch wenn sich die obigen Punkte viel nach „mimimi“ anhören, ich persönlich mache diese Arbeiten sehr gerne, auch wenn sie nicht jeweils mit einem Schulterklopfen honoriert werden. Aber ich wünsche mir ein bisschen mehr Bewusstsein in Bezug auf diese Arbeiten von allen TeilnehmerInnen dieser Branche - Kunden, Lieferanten, Abnehmer, Grafiker, Programmierer, Berater und so weiter und so fort.

Denn es fällt mir oft schwer, einen Qualitätsstandard zu halten, wenn ich Zeit- und/oder Budget-technisch beschnitten werde. Es ärgert mich kolossal, wenn ich wegen widriger Umstände nicht die Leistung bringen kann, die ich mit mehr Zeit und besseren Briefings bringen könnte. Und nicht selten ist es schwer zu vermitteln, warum ich einen viermal höheren Stundensatz verlange als der Sohn des Schwagers, der „das doch auch eben umsetzen könnte“.

Es sind die unsichtbaren Disziplinen, die die Spreu vom Weizen trennen. Wie ein Webentwickler-Kollege kürzlich zu mir meinte „wer Webseiten verkauft, aber diese Leistung nicht mit erbringt, ist nichts weiter als ein Heuchler“.

In diesem Sinne: auf ein gutes Handwerk!