Smashing Conf – Performance matters or why you should add some poo to your unit tests

Smashing Conference Logo

Eine der diesjährigen Smashing Conferences fand im schönen Freiburg statt. Die Namics war mit insgesamt 6 Frontendlern  aus den verschiedenen Units stark vertreten. Am 15. + 16. September waren im historischen Kaufhaus inklusive Surprise Speaker 18 Talks aus den Bereichen Design und Frontend angesagt. Die über 300 Attendees waren aus den Bereichen Design, Typografie, Frontend und UX aus ganz Europa angereist. Nachdem uns Vitaly, der Editor in Chief des Smashing Magazine begrüsst hatte, ging es auch bereits mit dem ersten Speaker los. Nachfolgend sind die aus Frontend Sicht interessantesten Talks kurz zusammengefasst.

GOOD IS THE ENEMY OF GREAT

Marcin Wichary, ein Product Designer bei Medium, beglückte uns am Montag Morgen mit einigen interessanten Details zur Typografie. Unter anderem gab er einen Einblick, wie er 31 Tage benötigte, um den perfekten Text Underline zu entwickeln. In diesem Prozess probierte er diverse Techniken aus, unter anderem auch ein Gradient als Background des Wortes, welcher nur so schmal ist, dass es den Perfekten Underline bildet. Inklusive eines Text Shadows mit 1px Breite in der Farbe des Hintergrunds, damit Buchstaben wie g und y die Unterline unterbrechen. Das Fazit seines Talks war

Sometimes you’re trying to go to the moon, but you end up on Mars and that’s ok, because you still left Earth. – @mwichary

Oder anders gesagt, Good is not great, but its still better than it was before.

DESIGN DECISIONS THROUGH THE LENS OF A PERFORMANCE BUDGET

Der zweite Talk von Yesenia Perez-Cruz befasste sich mit einem sehr aktuelle Thema unserer Branche, nämlich der Performance. Diese sollte bereits im Design Prozess nicht nur beachtet werden, sondern als ein Key Feature eine Hauptrolle spielen. Sie erzählte uns dabei, wie sie früher  selbst überhaupt nicht auf die Performance achtete und dann von den Entwicklern Sätze wie „The designer added 5 carousels again –  And the client loved it!“ hörte.

Solche Designs entstehen aus Gründen wie schlechter Planung, schlechter Kommunikation und fehlendem Bewusstsein, welche Auswirkungen solche Designs haben können. Dabei stehen Faktoren wie Schnelligkeit, Funktionalität und Leichtheit im krassen Gegensatz zu Schönheit, Eye Catching und On-Brand. Sie hat sich deshalb selbst einige wichtige Punkte festgelegt, wie sie für Performance designen kann:

  • Think about Performance from the beginning
  • Establish a performance budget
  • Communicate
  • Performance is a design feature and not a technical concern

Das wichtigste Fazit daraus ist wohl, dass Performance Überlegungen beim Development Start schon viel zu spät sind, weil dann das Design bereits gemacht ist, dem Kunden gezeigt wurde und damit vielleicht auch Erwartungen geweckt wurden, welche nicht mit guter Performance vereinbar sind. Es sollte deshalb mit dem Kunden bereits am Anfang in der Spez Phase als Projekt Ziel festgelegt werden.

The goal of this Project is to create a beatiful, flexible, lightning-fast experience… – @yeseniaa

An dieses Projekt Ziel kann dann in der Projekt Phase auch immer wieder erinnert werden, wenn eventuell Kompromisse gemacht werden müssen. Zur Festlegung des Performance Budget hilft es, Seiten der Konkurrenz anzuschauen und gegebenenfalls einen visuellen Vergleich mit Tools wie webpagetest.org zu zeigen. Das Budget kann auf Seitengewicht in kb, Anzahl Requests oder auch Ladezeit ausgelegt sein. Anhand dieses Budgets sollten dann mit dem Kunden Kompromisse gefunden werden, ob er z.b. lieber ein Carousel auf der Startseite oder 4 verschiedene Webfonts haben möchte. Dabei helfen die 3 Schritte

  1. Remind
  2. Educate
  3. Find a Balance

Wenn dem Kunden dabei verschiedene Optionen geboten werden können, hat er auch eine Wahl was aus seiner Business Sicht besser ist.

Slides

UNICODE ♥ JAVASCRIPT

Gleich nach dem Mittag ging es mit einem eher technischen Thema weiter. Mathuas Bynens arbeitet bei Opera als Entwickler und ist Collaborator bei jsPerf und HTML5 Boilerplate. Die Aussage seines Vortrages ist dass Javascript ein Unicode Problem hat. Er führte uns dabei zuerst kurz in die Grundlagen von Unicode ein und erklärte uns dann anhand diverser Beispiele, dass einige Javascript Funktionen falsche Resultate liefern, wenn im String ein Unicode Sonderzeichen beinhaltet. Detailierte Beispiele dazu können hier angeschaut werden. Ein Real World Beispiel ist das Twitter Feld, welches 140 Zeichen erlaubt. Der JS Char Counter zählt dabei das Unicode Zeichen „Pile of Poo“ als zwei Zeichen, da die JS String Funktion Length ein falsches Resultat zurück liefert.

Als Fazit sollte man mitnehmen, dass bei JS Code mit String Operationen immer mal wieder falsche oder unerwartete Resultate herauskommen. Es lohnt sich deshalb ein Unit Test mit z.b. dem Zeichen „Pile of Poo“ darin gemacht werden sollte. (The Pile of Poo Test™)

DESIGN CONSISTENCY FOR THE RESPONSIVE WEB: HOW WE DEFINE AND DELIVER

Patty Toland arbeitet bei der Filament Group, welche sich auf Progressive Enhancement (PE) und Responsive Web Design (RWD) spezialisiert haben. Ihre Firma hat dabei bekannte Seiten wie der Boston Globe, Lego oder Rent.com designt und realisiert.

Beim RWD gehen oft folgende Annahmen einher:

  • Es gibt einheitliche Regeln für alle Seiten
  • Device Grössen / Möglichkeiten sind gleich und voraussagbar

Die Realität vor allem in der Android Welt, aber seit den neuen Iphones auch immer mehr in der IOS Welt sieht leider anders aus. Eine gute Übersicht bietet dabei die Seite Open Signals. Wir müssen uns darum von den Pixel Perfect Layouts verabschieden, da diese auch mit den Wearables, Smart TV’s und allen anderen Internetfähigen Geräten dies einfach nicht realistisch ist.

Die Maslofsche Bedürfnis Pyramide kann gut auf RWD umgemünzt werden, jedoch vielleicht mit einem überraschenden Resultat. Das stabile Fundament bildet nämlich Speed, gefolgt von Access, Scale und Style, welches zuoberst kommt.

„Analytics can’t tell you, how many visitors leave before your site shows up“- @pattytoland

Auch hier kam wieder die grundlegende Aussage, Geschwindigkeit als einen essentiellen Teil des Design Prozesses zu etablieren.

Dabei sollte sich immer gefragt werden, ist dieses Element nötig? Für alle User? Sofort? Mit einem Kritischen Blick sollten somit nur die essentiellsten Dinge initial geladen werden. Progressive Enhancement sollte dabei so angewendet werden, dass nicht das All or Nothing Prinzip gilt, wenn der User z.b. kein Javascript hat.

Bezüglich Breakpoints und Layouting gilt es den Hinweis zu beachten, möglichst wenig Breakpoints Global zu definieren und die Komplexität in den Komponenten selbst abzuhandeln. Dies gibt einem viel mehr Möglichkeiten, Micro-Optimizations auch hinsichtlich Content zu machen.

Slides

FAZIT DES ERSTEN TAGES

Historisches Kaufhaus Freiburg

Historisches Kaufhaus Freiburg

Nach 9 Vorträgen waren wir froh, als der Letzte vorüber war. Vor allem auch, da Dieser noch schwere Kost war, da er das Thema Fokussierung, Soziale Medien, Burnout hatte und der Speaker seine sehr persönliche Geschichte erzählte..  Neben einigen sehr themenspezifischen Vorträgen war eines der Haupthemen des Tages sicher die Performance, welche in mehreren Vorträgen besonders auch hinsichtlich des Designprozesses behandelt wurde.

Nach einem Kurzen Abstecher ins Hotel und einem Abendessen war um 21.00 Uhr der Social Event angesagt.

THE MYSTERY SPEAKER

Am nächsten Morgen war um 9.00 Uhr Beginn mit dem Mystery Speaker. Dies war Dave Shea, welcher die Seite  CSS Zen Garden gegründet hat und nun bei der Firma Mobify arbeitet. In seinem Vortrag ging es um CSS Architekturen. Trotz einigen Existierenden wie BEM, OOCSS haben sie ihr eigenes Architektur Framework entwickelt. Es heisst Argon und basiert auf BEM, ist aber ein bisschen anders. Sie haben dabei folgende Dinge beachtet:

  • Predictability
  • Re-usability
  • no specifity battles
  • no id styling
  • no styling of html tags
  • don’t rely on any html ordering structure, except pseudo elements
  • no usage of !important
  • Javascript Classes do not contain any styling
  • Visibility Styling are named with .is-visible
  • Do not nest too many selectory since it leads to Selector Names, which are really hard to override
  • Source Maps are extremely helpful to develop
  • The syntax is not the important thing, it’s the discipline to stick with it

Ich denke, wir beachten bei der Namics bereits viele dieser best Practices und entwickeln auch so. Darum war es auch eine Bestätigung zu sehen, dass Andere dies auch so machen und es der richtige Weg zu sein scheint.

Slides

TYPEFACES FOR SCREENS

Der nächste Vortrag wurde von Gerry Leonidas, einem Professor für Typographie, gehalten und hatte einen für uns doch vielversprechenden Titel. Wir erhofften uns einige Inputs zur Auswahl von geeigneten Webfonts und auf was man dabei achten sollte. Der Vortrag war dann jedoch mehr über die Geschichte der Entwicklung von Typefaces. 3 wichtige Inputs bei der Auswahl geeigneter Screen Typefaces konnten wir aber trotzdem mitnehmen. Die Schrift sollte nämlich die folgenden Dinge haben

  • Even Spacing
  • Open Counters
  • Clear Stroke Joints

Während der Speaker dann eine Folie mit zwei Overlays von verschiedenen Schriften zeigte, welche sich sehr geringfügig unterschieden sagte er

If you think you’re nerds, think again. – @gerryleonidas

Slides

 ADAPTIVE INPUT

Der letzte Vortrag wurde von Jason Grigsby gehalten und hatte das Thema Adaptive Input. Bereits schon seit einige Jahren ist es auch mit den Smart TVs möglich, im Internet zu surfen. Gemäss einer Studie haben dies jedoch erst 10% aller Smart Tv Besitzer nur mal auspropiert. Mit immer mehr Devices in ganz verschiedenen Screensizes verschwimmen die ehemals klaren Linien zwischen Device Klassen immer mehr. So wurde es bezüglich Auflösung auch immer schwieriger klar abzugrenzen, was ein Smartphone und was ein Tablet ist. Der richtige Ansatz dazu ist, dass man die Devices gar nicht abgrenzen soll, sondern mit Inhaltsbasierenden Media Queries Responsive Webseiten entwickelt, wo der Inhalt auf jedem Device gut lesbar ist.

Die Möglichkeiten und Lösungsansätz für die verschiedenen Screensizes sind also da und werden von unserer Industrie auch bereits aktiv genützt. Mit der Erkennung der verfügbaren Input Methode steht jedoch bereits die nächste grosse Herausforderung an.

Adaptive Input

Adaptive Input

Bereits jetzt ist es nicht mehr möglich, zuverlässig zu erkennen, ob ein Gerät Touchfähig ist. Es ist deshalb eine Illusion anhand der Screen Grösse  oder dem Form Faktor zu schliessen, welche Input Methoden auf dem Gerät verfügbar sind. Schliesslich gibt es ja auch Geräte wie das Chromebook, welche Touch und Maus haben. Ebenso ist es auch nicht möglich, zu erkennen ob ein Gerät eine Maus, eine Tastatur oder auch ein D-Pad angeschlossen hat. Mit dem Aufkommen von Wearables wie Apple Watch, Google Glass aber auch Voice Control Systemen wie Siri ändern sich die Input Methoden schneller als je zuvor.

Die wichtigste Schlussfolgerung, die es mitzunehmen gilt, ist deshalb dass jede Desktop UI für Touch designed sein muss. Das heisst, möglichst auf Hover Effekte verzichten, oder diese nur als Nice to have zusätzlich anzubieten. Wir entwickeln nicht für Formfaktoren sondern für das Bedürfnis der User. Ebenso ist Progressive Enhancement bezüglich Input Methoden heikel, da wir den User nicht zwingen dürfen, eine gewissen Input Methode zu benützen. Die UI sollte deshalb auch nicht basierend auf verfügbaren Input Methoden angepasst werden.

Slides

FAZIT DER CONFERENCE

Während den zwei Tagen in Freiburg haben wir sehr viele Spannende Vorträge erlebt und auch gesehen, was andere Personen und Firmen aktuell für Themen beschäftigen. Wir haben in einigen Dingen eine Bestätigung unserer Arbeitsmethoden gesehen und aber auch einige Dinge erfahren, die wir verbessern können, um dem User noch ein besseres Erlebnis beim Surfen auf einer Webseite zu bieten.

Die wichtigsten Punkte, die ich mitgenommen habe sind:

  • Performance ist ein Key Feature, welches schon ganz am Anfang als Requirement beachtet werden muss
  • Designs müssen für Touch Design werden, da wir Input Methoden nicht detektieren können
  • Progressive Enhancement verwenden, nicht all or nothing

LINKS

Ein Gedanke zu “Smashing Conf – Performance matters or why you should add some poo to your unit tests

  1. Spannender Bericht von der Smashing Conference. Schade, dass der Vortrag über Typefaces for Screens so geschichtslastig ausgefallen ist. Ein Vortrag mit Praxisnahen Tipps, wie klare Vorschläge und Vergleiche von Webfonts hinsichtlich Ästhetik und Lesbarkeit wären hier besser gewesen. Oder Vergleiche hinsichtlich Anzahl vorhandener Schnitte im Web. Danke für die Zusammenfassung!

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>