Flash ist tot

Wie The Verge berichtet, blockiert in Zukunftder Firefox Browser von nun an standardmäßig Flash auf Webseiten und Facebook hat verkündet es nun endgültig killen zu wollen.

Seit durch den Hacking Team Hack eine noch unabsehbare Zahl von 0-Day-Lücken in Flash an das Licht der Öffentlichkeit geraten ist und klar ist, welchen Stellenwert Flash in der Blackhat- und Überwacher-Sphäre einnimmt, als Tool gegnerische (also unsere) Rechner zu übernehmen und auszuhorchen, werden allenorten Anleitungen verbreitet, wie man Flash auf dem eigenen Rechner deaktiviert (oder zumindest erst auf Klick ausführbar macht). Zur eigenen Sicherheit sollte man dies dann auch tatsächlich tun.

Die Sache hat natürlich auch einen Haken und zwar einen wirtschaftlichen: ich würde mal schätzen das mindestens 50% der Banner- und Onlinewerbeindustrie in der Hauptsache auf Flash setzt, wie immer ist man dort mit der Entwicklung weit dem eigentlichen Standard hinterher. Wenn aber von gestern auf heute Flash allenorten deaktiviert wird, wird dadurch allenmöglichen Webseiten nicht nur schneller, sondern auch deutlich ärmer.

Warum Flash noch flächendeckend in der Werbeindustrie eingesetzt wird, wider besseren Wissens? Zunächst mal, weil es so schön einfach zu verbreiten ist und pixelgleiches Aussehen, der heilige Gral der Werbung, auf allen Plattformen verspricht. Da sind HTML5-Ads in der derzeitigen Ausbaustufen noch das genaue Gegenteil, denn dort hat man natürlich mit den üblichen Browsertücken zu kämpfen, wie bei der täglichen Webentwicklung. Und der Einbau ist auch nicht gerade einfach. Das führt dazu, dass es einfach mehr kostet, ein HTML5-Werbmittel zu bauen. Und Kosten scheuen die Werbe- und Mediaagenturen natürlich, denn alle Betriebskosten gehen letztendlich von ihrem Gewinn ab. Und Gewinne werden dort mit jährlichen Bonizahlungen vergütet, also entscheidet sich jemand der Werbung platzieren will für den Anbieter, der die billigen Flashwerbemittel zulässt und nicht das teure HTML-Zeug.

Aber. Flash. Ist. Böse. Das ist nun zweifelsfrei bewiesen. Und da nun die Browserhersteller und sogar Facebook (oha, Facebook!) Fakten schaffen, wird sich schnell etwas bewegen müssen. Endlich.

Von der App zur Webversion direkt in die Grütze

Die Webversion von Flipboard hat es nicht nur geschafft, mit einer beworbenen Animationsgeschwindigkeit von durchgängig mindestens 60 fps Aufsehen zu erregen, sie sorgt auch sonst für Diskussionsstoff, wegen ihrer kompletten Unzugänglichkeit. Die Macher von Flipboard haben den DOM in <canvas> nachgebaut, weil er zu langsam ist. Klingt für mich nicht nach einer Idee, die man feiern sollte.

Ich kenne das selbst nur zu gut, Accessibility einzubauen, kann je nach Struktur des eigenen Codes sehr schwierig sein. Die gewählte Struktur ist, naja, sehr schwierig. Und vielleicht liefert Flipboard eines Tages ein Update, bei dem dann der Accessibility mehr Wert beigemessen wird, gänzlich unmöglich ist es ja nicht. Allerdings:

60 frames per second is not “would be nice”. It’s “must have”. And the DOM doesn’t have it. It’s not surprising that Flipboard’s workaround — the <canvas> element — was invented by Apple, as the basis for Dashboard widgets and potentially as the backdrop for the iPhone. But it’s damning that something Apple decided was too slow to serve as the basis for native iPhone apps is the best-performing backdrop for the mobile web.

John Gruber meint also, jetzt 60fps-Animationen an den Start zu bringen, sei wichtiger als Accessibility umzusetzen. Die kann man ja beizeiten nachliefern. Ja, ja, der DOM ist lang und weilig, kennen wir alle. Bisher gabss aber immer wichtigere Dinge, die entwickelt werden mussten. Aber nun kommt es darauf an, dass wir endlich endlich endlich flüssig scrollen können? Und bis das umgesetzt ist, lassen wir mal jene, die auf Zugänglichkeit angewiesen sind, im Regen stehen. Und Schuld ist auch noch das W3C!

Blinded by ideology, oblivious to the practical concerns of 60-FPS-or-bust-minded developers and designers, the W3C has allowed standard DOM development to fall into seemingly permanent second-class status.

Ich weiß gar nicht genau, welche dahinter steckende Denke mir mehr auf den Sack geht: ist das schon Technologiedarwinismus? Natürlich kann man wollen, dass der DOM ähnliche Leistungen vollbringt, wie auf Einzelplattform optimierte Grafikengines, aber der Kern des Web ist das nicht. Und wird es nie sein. Deswegen ist es aber keinesfalls zweitklassig. Vielmehr ist ja seine Stärke die Plattformunabhängigkeit und seine Breite. Und wer glaubt, nur weil jetzt ein paar Appentwickler im Apple Store nicht mehr genug Kohle machen, müsse man das web in eine andere Richtung entwickeln, also weniger offen, weniger zugänglich, aber mit 60fps, der beleidigt einen großen Teil seiner Nutzer und viele ernsthafte Webentwickler gleich mit. Es ist ein Fehler, Apps in HTML eins zu eins nachbauen zu wollen (weiss ich aus Erfahrung) diesen Fehler jetzt zur Ideologie zu erheben, halte ich bestenfalls für gefährlich.

Es muss einen (hust… finanziellen… hust) Grund geben, warum Apps wie Flipboard aus ihrer ach so primärtechnologischen Welt der Apps in das so lahme mobile Web wollen. Mit Menschenfreundlichkeit hat es offenbar nichts zu tun. Ich kann nur hoffen, dass, falls sich das als Trend erweisen sollte, wir stark genug sind, ein offenes und gleichberechtigtes Netz zu bewahren und nicht anfangen, langwierig Erkämpftes (was sich selbst noch deutlich ausbauen lässt) auf dem Altar der Animationsgeschwindigkeit zu opfern.

289 Passwörter

Hey, seit der letzten großen Passwortkatastrophe habe ich mich accountmäßig wirklich entschlackt. Doch, ehrlich. Ich melde mich bei jedem Dienst mit einer anderen Emailadresse an, catch-all macht’s möglich, und verwalte Logins und hochkomplexe, einmalige Passwörter in 1-Password. Trotzdem, ich lagere dort sage und schreibe 289 einzelne Logins. Und ja, ich habe eine Meise.

Ich fänd das wirklich sehr hilfreich, wenn sich mal jemand etwas neues an Stelle von Passwörtern ausdenken würde, also irgendetwas was besser skaliert? Das wäre fein. So kann das ja nicht wirklich sicher sein, ich kenne euch Pappenheimer doch, ihr geht nicht so ordentlich mit euren Logins um! Und zu der ganzen Unsicherheit mit dem widersprüchlichen soll kompliziert aber leicht zu merken sein, kommt ja auch immer noch das Gefuddel mit dem Passwortmanagern und alles dazu. Und wenn man dann mal ein Login sparen will, kommt man nach Monaten zur Anmeldung zurück und feststellen, dass man nicht mehr weiß, ob man nun Google, Facebook oder Twitter zu einloggen verwendet hatte. So klappt es also auch nicht. Und wirklich trauen will ich diesen Kraken auch nicht.

Was man also bräuchte, wäre etwas ganz anderes als Passwörter. Ich mag ja bspw. wenn ich mich irgendwo mit SSH anmelden muss, meinen Key auf den Server zu packen. So in der Art wär mir das lieb. Und dann immer schön zentral alles bei mir, aber immer so einzigartig, dass nicht das ganze Leben im Arsch ist, wenn mal etwas lecker. Und schön NSA ignorant bitte. Das kann doch jetzt mal jemand machen.

Boilerplate

Ich habe in den letzten Monaten viel mit grunt gearbeitet und viel gelernt (zusammen mit und von Kollegen), für eine kleine Website hatte ich das nochmal für mich zusammengeschrieben und nun begonnen daraus so etwas wie ein „Boilerplate” zu stricken. Das gibt es nun hier auf github.

Features bisher: bower-Support, jQuery, modernizr, normalize.css, Sass, compass, Linting, Konkatination, Uglyfiing, Bildoptimierung. Da fehlt noch einiges…

Ein (unzu)lässiger Vergleich

Passierschein A38

Ich fahre viel mit der Bahn. Das verändert die innere Einstellung erheblich. Man muss sich einen gesunden Phlegmatismus zulegen, weil man sonst nämlich auf lange Sicht wahnsinnig wird. Eine durchschnittliche Zugfahrt im Fernverkehr verläuft beispielsweise oft so:

  • Der ICE fährt von einem anderen Gleis, es gibt also keine Wagenstandsanzeige.
  • Die Wagenreihung ist geändert.
  • Es werden fünf Minuten Verspätung angekündigt.
  • Es werden zehn Minuten Verspätung angekündigt.
  • Grund für die Verspätung: Verzögerung im Betriebsablauf.
  • Der Zug trifft mit 15 Minuten Verspätung ein.
  • Aufgrund eines technischen Problems können die Reservierungen heute leider nicht angezeigt werden.
  • Es steht überall »Hotspot« dran, es gibt auch WLAN, dieses ist jedoch nicht mit dem Internet verbunden. @DB_Bahn meint, man solle mal beim Personal fragen, das Personal meint, dafür sei die Telekom zuständig.
  • Aufgrund eines technischen Problems kann der Zug heute leider nicht mit Höchstgeschwindigkeit fahren, ein Aufholen der verlorenen Zeit ist nicht möglich, im Gegenteil.
  • Information über Anschlusszüge: können nicht warten, bis auf einer.
  • Die Einfahrt in den Zielbahnhof ist blockiert, der letzte wartende Anschlußzug ist auch weg.

Wer sich kein dickes Fell zulegt, fährt früher oder später wieder Auto. Und was ändert sich? Nichts.

Genau so ist Webentwicklung.

Hamburger… considered harmful

Irgendwie seltsam, aber schon der Titel dieses Artikels ist doppeldeutig und damit nur schwierig zu verstehen. Die Hamburger haben ein Problem? Ganz bestimmt haben sie das, aber darum geht es hier nicht. Es geht vielmehr um das kleine Icon auf vielen mobilen immer mehr Webseiten, das man anklicken muss, um zu einen Menü zu gelangen.

Letztes Jahr noch der hice shice, wird es heute heiss diskutiert. Oft geht die Diskussion jedoch am Thema vorbei, zeigt Paddi McDonnel in seinem Artikel How to solve the hamburger icon problem ganz hervorragend. Die Frage, ob die Nutzer das Icon verstehen, oder ob da nun besser „Menü” dranstünde, ist gar nicht so entscheidend. Es geht um etwas ganz anderes.

Die Herkunft der drei Balken ☰, das chinesische Zeichen für Himmel, ist wohl in Apps für Smartphones zu suchen. Dort verdeckt es zumeist ein Menü mit zusätzlichen Optionen, bspw. Einstellungen, Wechsel des Anzeigemodus und so fort. Im Web, oft auf mobilen Webseiten, aber auch nicht nur dort, wird es verwendet um die Navigation zu verstecken. Die Navigation! Meine Damen und Herren, was macht die Navigation auf einer Website? Richtig, sie zeigt an „wo man gerade ist” und wohin man von dort aus gehen kann, oder soll. Wie erfüllt unser kleiner Hamburger diese Aufgabe? Gar nicht!

Eine App konzentriert sich zumeist auf eine spezielle Aufgabe, die sie idealerweise auf einem Bildschirm erledigt, da braucht es selten eine Navigation. Das ist auf den meisten Webseiten auf denen der Hamburger eingesetzt wird grundsätzlich anders und deswegen schlicht ein Fehler. Eigentlich ist es schon egal, ob ein User es nun gar nicht als Menü erkennt, oder einfach intuitiv nicht klickt—don’t make me think!—, weil es der Klick zu viel ist. Man lässt den Nutzer in beiden Fällen in einer Sackgasse stehen.

Dabei löst der Hamburger natürlich auch ein Problem. Nämlich, dass die langen Listen von Links, die viele Webseiten Navigation nennen, zu viel Platz wegnehmen. Allerdings müsste hier die Lösung sein, an der Information Architektur zu arbeiten, dem mobile first Gedanken folgend für die komplette Website.

Facebook’s app famously swapped their hamburger icon for a tab bar, and as a result saw improved conversions. But Facebook have done something far more significant than swap menu designs. Recently they’ve released their Messenger app, and the big deal about that is that they already had a perfectly functional and popular app that they could have integrated the messaging with. Facebook have compartmentalized their functions, by focusing each app’s role they’ve arrived at two simple apps, instead of one complex one. (Paddi McDonnel)

Was hier bei einer App funktioniert hat, gilt wohl auch für jede Website: unser Navigationsproblem im mobile Web lösen wir nicht mit dem Hamburger, sondern in dem wir bereit sind, unsere Inhalte zu fokussieren. Nun aber nicht gleich für jede Sektion eine eigene App planen, sondern einfach mal das Menü entschlacken.

Artikelbild: Bestimmte Rechte vorbehalten von pointnshoot.