Aus Fehlern lernen

Designer sind kreativ. Diesen Satz wird wohl niemand anzweifeln. Ein bisschen weniger bekannt ist (außerhalb der IT-Szene), dass auch Programmierung ein kreativer Prozess ist.

Für einen Außenstehenden mag Logik oder mathematisches Verständnis, auswendig-gelerntes Theorie-Zeugs die Hauptzutat eines Programms oder einer Web-Anwendung sein.

Wer selber programmiert weiß, dass logisches Verständnis eines Sachverhaltes und die nötigen theoretischen Grundlagen nur die Voraussetzung zu einer Problemlösung sind, die eines kreativen Ansatzes bedarf. Oft beschreitet man einen Lösungsweg zum ersten Mal.

Das gilt auch für andere Teilbereiche der IT, wie die Entwicklung von Frontends, die keine klassische Programmierung sind.

Was hat das mit Fehlern zu tun? Immer wenn wir etwas zum ersten Mal umsetzen, gibt es keine Garantie, dass unsere Entwicklung funktionieren wird. Noch weniger lässt sich sicherstellen, dass es von den Nutzern angenommen wird, selbst wenn es keine technischen Fehler gibt.

Wird ein Button gefunden und verstehen Nutzer, welche Aktion ausgelöst wird, wenn dieser Button gedrückt wird?

In unseren Statistiken finden wir Hinweise auf falsches UX-Design, wir bekommen (wenn wir Glück haben) empörtes Feedback oder Kritik unserer Kunden.

Das sollte uns aber nicht davon abhalten, immer wieder neues zu probieren. Denn sonst geht uns unsere Kreativität verloren.

Wer nichts (neues) tut, macht auch keine Fehler. Er entwickelt sich aber auch nicht weiter und inspiriert auch niemanden.

Man sollte sich aber mit Fehlern beschäftigen und aus ihnen lernen!

Erfreulicherweise müssen es nicht die eigenen sein. Als Dozent berichte ich freimütig von allen möglichen Dingen, an denen ich selber nahezu verzweifelt bin. Um hier nur ein Beispiel zu nennen: Für meinen bis dahin größten Auftrag (Neugestaltung der Site http://www.runetwork.org/) hatte ich von meinem Designer diverse Bildchen für das Menü bekommen (vor 16 Jahren noch eine übliche Vorgehensweise), die ich brav mit alt-Texten versehen und verlinkt habe.

Um meinen Quellcode besser lesen zu können, habe ich vor einem der Bilder einen Zeilenumbruch eingefügt – der Browser fügt dann an dieser Stelle ein Leerzeichen ein, wodurch optisch natürlich eine kleine Lücke im Menü entsteht. Ein absoluter Anfängerfehler, aber ich war noch nicht erfahren genug, um den auf Anhieb zu sehen. Ich hatte auch zwischenzeitlich den automatischen Zeilenumbruch aktiviert, um bei der Suche nach dem Fehler allen Code im sichtbaren Bereich des Editor-Fensters zu haben (Monitore waren damals noch klein). Jetzt hatte ich haufenweise umgebrochene Zeilen und den händisch eingefügten Zeilenumbruch konnte man nur noch an der zusätzlichen Zeilennummer erkennen, die der Editor dort anzeigt. – Zu unauffällig für mich…

Als ich alleine nicht mehr weiterkam, machte ich mich zum ersten Mal im Netz auf die Suche.

Noch unerfahren in der Online-Recherche, mit weniger leistungsfähigen Suchmaschinen als es Google heute ist und natürlich weniger (deutschsprachigen) Inhalten im Netz, dauerte es eine gefühlte Ewigkeit, bis ich im Netz Artikel gefunden hatte, die über mein Problem berichteten – und die Lösung nannten.

Aber endlich wusste ich, wonach ich suchen musste, schaltete den automatischen Zeilenumbruch aus (den ich bis heute nicht mehr mag 😉 und behob den Fehler nicht nur, ich hatte auch ein wesentliches Prinzip verstanden: Browser fassen ein oder mehr Whitespaces im Quelltext zu einem einzigen Leerzeichen zusammen.

Verstanden habe ich das nur, weil andere mutig und freundlich genug waren, ihren Fehler zuzugeben und dieselben oder andere Menschen, Lösungen und Erklärungen kostenlos für alle bereit zu stellen.

Im folgenden habe ich immer weniger aus Büchern, dafür immer mehr online gelernt. Von Beginn an habe ich öffentlich Fragen gestellt und damit dokumentiert, nicht perfekt zu sein. Mitunter kam Kritik, dass ich als Dienstleister öffentliche Foren auf diese Weise nutze.

Aber ich habe immer Hilfe erhalten. Und heute, wo ich dazu in der Lage bin, gebe ich das zurück. Gerne an dem Ort, der mir selber viel gegeben hat: das Forum von SelfHTML, einem der wenigen Plätze im deutschsprachigen Web, wo man gezwungen wird, Lösungen zu verstehen, statt Code zu kopieren.

Aber zurück zu den Fehlern: einen sehr schönen Beitrag habe ich auf Youtube gefunden, den ich gerne mit euch teilen möchte (englisch):

„CSS lessons learned the hard way (CSS-Lektionen, auf die harte Tour gelernt)“ von Zoe Mickley Gillenwater

 

CSS: Flex-Box

Flex-Boxen sind der aktuelle Stand der Technik bei der Umsetzung responsiver Layouts. Responsive Designs wiederum sind die einzige zeitgemäßen Designs.

Grund genug also, sich mit der Technik auseinanderzusetzen, zumal der Einstieg nicht kompliziert ist.

Zoe Mickley Gillenwater zeigt im folgenden Video was Flex-Boxen tun und wie sie das Leben der Entwickler vereinfachen. Zumal sich die Notwendigkeit von Fallbacks in naher Zukunft erledigt hat.

Der InternetExplorer unterstützt Flex-Boxen seit Version 10 in der alten Schreibweise von 2012 und hat auch in der 11er-Version noch mit allerhand Bugs zu kämpfen. In Deutschland wie Global hat die 11er-Version bereits heute nur noch einen Anteil von 6,5% am Browser-Markt, Tendenz fallend.

Randbemerkung: nicht an Edge (Markt-Anteil etwa 3%) gibt der InternetExplorer seine Nutzer weiter. Die wandern offenbar zur Konkurrenz von Mozilla und vor allem Chrome. Dabei macht Edge vieles richtig und es wäre natürlich wünschenswert, wenn die im Internet übermächtige Firma Google/Alphabet noch etwas Konkurrenz hätte…

Flexbox Froggy

Flexboxen sind ein CSS-Layout-Konzept, das inzwischen von allen aktuellen Browsern unterstützt wird.

Nur wenn noch (sehr) alte Browser wie der InternetExplorer oder älter in einem Projekt berücksichtigt werden müssen, können Flexboxen nicht ohne Fallback-Lösung verwendet werden. Höchste Zeit also, sich mit dem Thema mal auseinander zu setzen. Am besten mit Spaß am Lernen. Den bietet Flexbox Froggy: Eine schöne Seite um spielerisch den Umgang mit den CSS-Flexboxen zu erlernen.

Jetzt zu Flexbox Froggy

Homepage erstellen mit HTML5

Die eigene Homepage ist immer noch der beste Platz für eine verlässliche Selbstdarstellung. Was für Netzwerke und Medien auch kommen und gehen, haunschild.de gibt es bereits seit knapp 20 Jahren!

Nur über die eigene Homepage können Sie komplett selbst bestimmen. Wenn Sie wissen möchten, wie Sie sich Ihr eigenes zu Hause im Internet aufbauen, hilft Ihnen mein HTML5-Buch aus dem Herd-Verlag:

HTML5 – Grundlagen der Erstellung von Webseiten

Gedruckt (gut zum Durchlesen): http://www.herdt.de/artikel/HTML5/HTML5/#description

Digital (gut zum nachschlagen): http://herdt-digital.de/product/HTML5

Überarbeitete 2. Auflage: CSS – Cascading Style Sheets Level 3

Ihr erfolgreicher Einstieg in die Formatierungssprache CSS!

Frisch überarbeitet: die zweite Auflage meines CSS3-Buches.

Alle Texte sind auf den aktuellen Stand der Technik gebracht worden, den Möglichkeiten neuerer Browser-Versionen wird Rechnung getragen.

Wenn Sie sich CSS3 selber beibringen möchten oder ein Nachschlage-Werk für Schule, Studium oder Beruf suchen: mit diesem von Dozenten in Universitäten und Volkshochschulen verwendeten Lehrbuch, lernen Sie die Sprache, mit der Sie moderne Webseiten gestalten können.

CSS – Cascading Style Sheets Level 3 Gedruckt (besonders bequem zum Lesen):
http://www.herdt.de/artikel/CSS3/CSS—Cascading-Style-Sheets-Level-3/#description

CSS – Cascading Style Sheets Level 3 Digital (PDF – besonders bequem zum Nachschlagen):

http://herdt-digital.de/product/CSS3

Slick – interessanter Slider

Im Moment kann man sich kaum noch in einem Social Media Network bewegen, ohne über den Slider Slick zu stolpern. Scheint im Moment ziemlich angesagt zu sein und die Anleitung ist mit Code als „Copy & Paste“-Vorlagen gespickt.

Dem Einsatz in einer eigenen Website steht also nichts im Weg!

Slick beeindruckt mit einer langen Feature-Liste, umfangreichen Optionen und angeblicher Barrierefreiheit. Klar, dass ich hellhörig geworden bin. Bisher habe ich ihn noch nicht produktiv eingesetzt – ich steh generell nicht besonders auf Slider – aber Slick gefällt mir vom ersten Eindruck her.

Setzt Ihr Slick bereits ein? Welche Erfahrungen habt Ihr gemacht?

Umsetzung zugänglicher Webseiten

20131120-162814.jpgMan sollte nicht den Eindruck erwecken, es sei wahnsinnig
zeitaufwändig, zugängliche Webseiten zu erstellen. Nötig ist
eigentlich vor allem ein einmaliger Lernaufwand, damit man weiß,
wie es geht. Beispielsweise semantisch korrekte Auszeichnung: die
Tags zur Auszeichnung einer Überschrift schreiben sich nicht
langsamer als die für das Element strong. Man muss nur wissen, dass
strong eben nicht für die Auszeichnung von Überschriften geeignet
ist und wie es besser geht. Dasselbe gilt für die Verwendung von
header, main, blockquote, usw statt div. Auch zusätzliche Angaben
sind in aller Regel schnell gemacht. So soll die Hervorhebung von
angetabbten Links mindestens so deutlich sein, wie die
Hervorhebungen für Mausnutzer (:hover). In der Praxis bedeutet es,
dass ich einen langen Selektor wie main #content article a:hover
markiere, kopiere und ein zweites mal einfüge, hover durch focus
ersetze und ein Komma einfüge. Ergebnis: main #content article
a:focus, main #content article a:hover Dauer etwa 5-10 Sekunden.
Das ist selbst bei aufwändig durchgestylten Webseiten, an denen man
mehrere Tage entwickelt, selten mehr als zehn Mal nötig.
Gesamtaufwand maximal also eineinhalb Minuten. Nutzt man Vorlagen
wie HTML5-Boilerplate, hat man gleich jene ganze Reihe von Klassen
inklusive, die auch die Entwicklung zugänglicherSeiten erleichtern,
wie zum Beispiel visuallyhidden, um Texte nur für
Screenreadernutzer bereit zu stellen (oder falls mal CSS nicht
funktioniert). Mit einem durchdachten Workflow, klug gewählten
Vorlagen und Werkzeugen und dem nötigen Wissen entsteht dafür kaum
ein nennenswerter Mehraufwand. So ist es mit vielen Dingen.
Berücksichtigt man gleich beim Design ausreichende Kontraste und
gibt man für das Layout nicht pixelgenaue Breiten statt fluider
Spalten vor (was in Zeiten des responsiven Designs ohnedies
schwachsinnig ist), wie viel länger dauert das dann, wenn
überhaupt? Zugegeben, der Testaufwand steigt. Aber in Zeiten
responsiver Layouts ist auch das anteilmäßig nicht mehr so der
große Brocken. Es ist deutlich aufwändiger in allen Browser- und
(mobilen) OS-Kombinationen zu testen, als einen Test auf
Zugänglichkeit zu machen (der sich größtenteils in die anderen
Tests integrieren lässt). Viele Dinge, die für zugängliche
Webseiten vorgeschrieben sind, sind ohnehin nach W3-Standard nötig,
wie valides HTML, Verzicht auch veraltete Elemente und Attribute,
alt-Texte, semantische Elemente statt div und so weiter. Aufwändig
und teuer (und relativ nutzlos) sind dagegen Zusammenfassungen in
Leichter Sprache und Deutscher Gebärdensprache. Entweder man
„übersetzt“ alle Inhalte (de facto wohl nicht zu leisten) oder man
steht auch dazu und lässt es gleich ganz. Für mich sind diese
Forderungen der BITV (die ohnehin nur für die wenigsten Sites,
nämlich Portale verlangt werden) reine Alibi-Forderungen, um sagen
zu können, dass man Gehörlose und Menschen mit kognitiven
Einschränkungen auch ernst nimmt. Von daher kann ich auch ein Stück
weit verstehen, dass die Vertreter der diversen Behindertenverbände
behaupten, die BITV berücksichtige vor allem die Interessen von
Fehlsichtigen und Blinden. Nichtsdestotrotz: viele wesentliche
Verbesserungen sind schnell gemacht. Der zusätzliche Aufwand sollte
(für die einmaligen technischen und gestalterischen Aspekte) 10%
kaum überschreiten, selbst wenn es schon richtig gut gemacht wird.
Wenn man dazu noch bedenkt, dass bei zwei bis fünf Jahren der
Laufzeit einer Website der Dauerbetrieb deutlich mehr Ressourcen
verbraucht, sieht man, wie gering der Zusatzaufwand während der
gesamten Lebensdauer solch eines Projektes ist. Was ich aber nicht
verschweigen möchte, Sind inhaltliche (nicht technische)
Gesichtspunkte. Redakteure müssen einige Angaben machen, die für
zugängliche Webseiten vorgeschrieben sind, die aber die Nutzbarkeit
für jeden Leser erhöhen verbessern. Das sind beispielsweise
saubere, tippfehlerfreie Texte, die nach den Regeln der
entsprechenden Textgattung verfasst und sprachlich an die
Zielgruppe angepasst sind: Zitate sollen als Zitate ausgezeichnet,
Abkürzungen aufgelöst, fremdsprachige Texte übersetzt sein – alles
für jeden Webseitenbesucher und -Betreiber ein Gewinn. Denn auf
solche Webseiten kommt man gerne wieder. Das gilt auch für Tante
Google, die man mit den Auflösungen von Abkürzungen oder
Übersetzungen natürlich ebenfalls füttert und die Texte so
bewertet, als wären sie gut geschrieben (wichtiges zuerst, später
die Details und am Ende ein Fazit). Google ist sicher der häufigste
wiederkehrende „blinde“ Besucher der meisten Websites. Darum hat
auch der Betreiber einer Seite etwas davon, wenn diese Kriterien
der Zugänglichkeit berücksichtigt. Ganz zu schweigen davon, dass
man potentiell mehr Besucher erreicht, wenn man Menschen mit
Behinderungen nicht durch unüberwindbare Hürden vom Besuch der
eigenen Site abhält. Und letztendlich macht es einen Auftraggeber
oder Webseitenbetreiber sympathisch, wenn er Seiten für alle
erstellt. So kann man soziale Kompetenz demonstrieren.

Texte aufklappen und verbergen mittels <details> und <summary>

Gerade auf Smartphones ist Platz kostbar. Aber auch auf dem Desktop ist es mitunter sinnvoll, Inhalte nur bei Bedarf ainzublenden. HTML5 bringt mit den Elementen details und summary alles nötige mit.

Beispiele mit etwas Text

Mittels details und summary kann man es dem Besucher einer Webseite die Entscheidung überlassen, Texte anzuzeigen oder zu verbergen.

Leider unterstützen derzeit weder Firefox noch InternetExplorer diese Elemente (details auf caniuse). Glücklicherweise hat ein freundlicher Belgier namens Matthias Bynens hingesetzt und ein Polyfill geschrieben, dass bei fehlender Unterstützung die korrekte Verhaltensweise emuliert. Dies stellt er als jQuery-Plugin zur Verfügung:
http://mathiasbynens.be/demo/html5-details-jquery