Namics @ #SmashingConf – Day 1

Drei Frontend Entwickler (Natalie Bausch, Denis Skeledzic-Gemperli, Lars-Olof Krause) und ein Designer (Stephan Nuber) von Namics hat es zwei Tage auf die Smashing Konferenz nach Freiburg gezogen.

Event-Location

An dieser Stelle ein Bericht des ersten Tages. Für Interessierte sind die breits vorhandenen Präsentationen der einzelnen Vortäge jeweils verlinkt.

Die Konferenz findet im historischen Kaufhaus in Freiburg direkt am Münster statt – ein oft fotografiertes Gebäude, in das man normalerweise nicht so einfach hinein kommt. Als Teilnehmer haben wir die Ehre dieses Gebäude betreten zu dürfen. Bei der Anmeldung erhalten wir unser „Attendee-Batch“, welches uns in der nächsten Zeit ausweisen soll, sowie eine Tasche mit weiteren „Goodies“.

smashingconf2016_startIm großen Kaisersaal geht es um 9 Uhr los mit eine Einstimmung der anderen Art – „When I’m Sixty-Four“ mit Smashing Text als Kazoo Konzert aller Teilnehmer.

Danach gibt es (nacheinander und mit Pausen) 7 Vorträge verschiedener Redner zu unterschiedlichsten Themen, aus dem Bereich des Webs.

Dave Rupert – „Vague, But Exciting“

Dave Rupert gibt in seinem Vortrage „Vague, But Exciting“ einen Einblick in die Beste Herangehensweise an neue (Web-)Projekte. So sollte man möglichst früh Prototypen erstellen, um herauszufinden ob eine Idee umsetzbar ist: „Find out if it’s a dumb idea – as fast as possible“. Eine Herangehensweise die ich in meiner Arbeit bei Namics auch schon verwendet habe – lieber einmal testen, ob etwas geht, als vorher zu tief zu definieren/konzipieren und mit Pech zu scheitern.
Interessant ist die Aussage „80% is better than 90%“ zum Thema Prototyping, es geht dabei darum, dass ein Prototyp einer Technologie/Umsetzung lieber an einigen Stellen grober ist, denn so fokusiert sich der Tester auf die eigentliche Funktion und nicht auf kleine Details und gibt so besseres Feedback.
Ein weiterer viel versprechender Ansatz ist der „4 hour chunk approach“, hier nutzt man nach Entwickeln einer Idee 4 Stunden um diese prototypisch umzusetzen, wenn es nicht klappt, wird nochmals probiert, anschließend berichtet man anderen von den Versuchen – selbst wenn die Umsetzung nicht erfolgreich war.

Una Kravets – „Practical Blend Modes“

Im nächsten Vortrag stellt Una Kravets die Möglichkeiten von SVG und CSS „filters“ und „blend modes“ vor. Mittlerweise können in Browsern sehr viele Funktionen genutzt werden, die früher nur über ein Bildbearbeitungsprogramm möglich waren. So ist es zum Beispiel kein Problem mehr die Farbe von Bildern auf verschiedenste Weise zu verändern oder Bilder ineinander zu kopieren oder zu überlagern.
Das Thema „Browser-Support“ spielt hier jedoch eine große Rolle – so werden diese Funktionen leider bis jetzt nur vereinzelt von Browsern unterstützt, somit ist ein vernünftiger Einsatz auf einer produktiven Seite derzeit unwahrscheinlich.

Slides – „Paractical Blend Modes“

Adrian Holovaty – „Building an Interactive Sheet Music Engine“

Soundslice ist ein Projekt von Andrian Holovaty, dass die dynamische Darstellung von Partituren mittels Javascript und HTML5 ermöglicht. Das Projekt bietet Musikern die Möglichkeit neue Stücke interaktiv zu lernen, so können unterschiedliche Audio-Quellen wie Videos oder aber eine Midi-Implementierung abgespielt werden, deren Geschwindigkeit geändert und die jeweilige Abspielposition in den Noten angezeigt werden. Als Webentwickler ist hier besonders das Thema „Responsive Content“ sehr interessant – das System zeigt je nach Bildschirmgröße optimierten Inhalt an, dabei brechen zum Beispiel Noten in der Partitur in eine neue Zeile um, wenn nicht genügend Platz vorhanden ist.

Adrian Holovaty weist darauf hin, dass „requestAnimationFrames“ Performance-Wunder bewirken können und gibt einige weitere Tipps zu verschiedenen Micro-Optimierungsmöglichkeiten von Javascript. Auch Webfonts können und sollten in Ihrer Größe optimiert werden, so ist es möglich nur bestimmte Character-Sets im Font zu belassen und ungenutzte Bereiche zu entfernen.
Die Herangehensweise bei allgemeiner Performance-Optimierungen ist dabei klar: „When it’s slow and you don’t know why – delete stuff“ eine sehr sympatische Aussage, denn wahrscheinlich jeder Entwickler kommt zu einem solchen Punkt in der Analyse.

„Hardware is Cheap Programmers are Expensive“ auf diesen Fakt sollte man nach Adrian Holowaty nicht eingehen, immer öfter ist es leider so, dass bei der Entwicklung und Optimierung von Systemen gespart wird und dem Nutzer so auferlegt wird immer neuere, schnellere Hardware zu erwerben.

Lyza Danger – „A Pragmatist’s Guide To Service Workers“

Service Worker sind eine interessante Technologie, die bspw. dazu eingesetzt werden können Webauftritte/Webapplikation offline nutzbar zu machen. Dabei ist ein Service Worker eine JS-Datei die sich sozusagen in das Browserverhalten „einklinkt“. So kann das Aufrufen einer Ressource abgefangen werden und direkt auf eine Variante aus dem Cache umgeleitet werden, falls diese existiert, selbst wenn das System online ist. Oder aber zunächst versucht werden die Ressourcen vom Server zu laden und nur wenn dies fehlschlägt auf den Cache zurückzugreifen.
Wichtig bei Service Worker ist, dass diese nur auf sicheren Verbinungen (HTTPS) verwendbar sind und das Javascript der Seite sowie der Service Worker asynchron arbeiten müssen, so verhindert bspw. die verwendung von LocalStorage die Funktion, das dies eine „Blocking“-Aufruf ist.

Slides „A Pragmatist’s Guide To Service Workers

Nathan Curtis – „BeSpreading Design System Across People & Products“

Nathan Curtis stellt verschiedene Herangehensweise an das Thema „Design System“ vor. Es geht hierbei darum wie ein (Corporate-)Design verbreitet bzw. zur Verfügung gestellt werden kann. Die Problematik dabei besteht darin, dass verschiedene Geschäftsbereiche teils sehr differierende Bedürfnisse an Styles, Code u.ä. haben. Der wichtigste Faktor bei der Nutzung und Entwicklung eines Design Systems ist die verschiedenen Nutzer zusammenzubringen und den verschiedenen Vertretern für die Abstimmung ausreichend Zeit dafür einzuräumen. Dabei kann es helfen eine Liste von priorisierten UI-Elemente zu definieren, auf die der Fokus der Entwicklung liegt. Nach der Erstellung eines Desing Systems, muss weiterhin ein ein dediziertes Team bzw. Personen existieren die zuständig sind das System zu pflegen und zu erweitern. Sehr wichtig ist abschließend zu nennen, dass auch eine gewisse zugelassene Unschärfe nötig ist. Es muss also bewusst sein, dass nicht immer alle Regeln des Design Systems eingehalten werden können.

Aaron Gustafson – „The Feature of Highly Effective Forms“

Aaron Gustafson behandelt in seinem Vortrag das große Thema „Accessibility“. Dabei geht es beispielsweise um die korrekte Semantik und Auszeichnung für Screenreader, aber auch um die Spache mit denen das Webinterface mit dem Nutzer interagiert.

Allgemein sollten wir als Entwickler härter arbeiten, um dafür zu sorgen, dass unsere User dies nicht tun müssen. So sollten bspw. Formulare dem Nutzer dabei helfen keine Fehleingaben zu machen. Dazu gehören sowohl treffende Labels von Feldern, als auch verständliche, ausführliche Fehlerhinweise mit Begründung („Talk to your users as your users talk to each other“).
Bei Formularen sollte auch stets auf korrekte Feldtypen geachtet werden, denn so besteht die Möglichkeit dass der Browser oder auch Screenreader die Eingabe auf das entsprechende Feld optimiert. Ganz nebenbei bekommen man so – je nach Browser – bereits eine Formular-Validierung mitgeliefert.

Für Screenreade ist breits der semantische Aufbau und die korrekte Verwendung von HTML-Tags sehr wichtig. So sollte die Navigation (<nav>), der Hauptinhalt (<main>) und der Fuß (<footer>) des Dokuments gekennzeichnet sein.
Bei der Textauszeichnung sollte die bedeutung der einzelnen Tags hinterfragt und diese korrekt eingesetzt werden. So gibt es zwischen <em> und <i> aus Styling-Sicht zunächst keinen unterschied, jedoch zeichnet <em> eine Betonung aus. <b> und <strong> sind beide fett, jedoch bedeutet letzeres eine erhöhte Wichtigkeit. Werden Abschnitte/Unterteilungen benötigt, die keine spezielle Aussage haben, sollte immer ein <span> oder <div> verwendet werden, alle anderen Elemente haben meist zusätzliche Bedeutungen.
Links können natürlich auch optimiert werden. Sie können bspw. durch Annotationen zu Inhalt oder Sprache erweitert werden.

Slides – Aaron Gustafson

Monica Dinculescu – „🎉🐱✨ Or: How I Didn’t Fix Emoji In Chrome“

Als Abschluss der Vorträge bietet uns Monica Dinculescu einen sehr lustigen Einblick in Ihre Arbeit und Erfahungen mit Emoji. Bei Emoji handelt es sich um Unicode-Zeichen, die durch Browser mit eine speziellen Unicode-Font angezeigt werden. Damit ist es klar, dass je nach Gerät ein Emoji unterschiedlich aussehen kann.

Die technische Länge eines solchen Icons ist anders als ein Buchstabe größer als „1“. Ein Emoji ist sozusagen nicht ein Zeichen sondern eine Kombination aus mehreren Zeichen – die losgelößt meist keinen Sinn ergeben.
Interessant ist der spezielle Aufbau von Emoji mit unterschiedlicher Hautfarbe. Diese setzen sich technisch aus dem Grund-Icon und einer zusätzlichen Farbdefinition zusammen. Auch Familien Icons setzen sich aus mehreren Icons zusammen – die einzelnen Familienmitglieder verbunden mit einem nicht sichtbaren Zeichen. Somit kann man hier „creepy“ Sachen mit Javascript anstellen, so ist ein Kind schnell durch ein anderes Kinde ersetzt.

Fun-Fact: Emoji können auch als Klassenname im HTML und zur Auszeichnung im CSS verwendet werden.

smashingconf2016_minions

Der interessante, sehr warme Tag wird durch ein gemeinsamen Planetarium Besuch abgerundet.

Viele Grüße aus Freiburg

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>