Fronteers 2014 highlights

Door Iain van der Wiel, front-end developer
24 oktober 2014 - 2395 x bekeken - Categorieën: Kennis

Dit jaar is er weer een delegatie van E-sites naar de Fronteers conferentie geweest, bestaande uit Ingmar Krijtenberg en mijzelf, Iain van der Wiel.

Fronteers is een congres dat georganiseerd wordt door de gelijknamige front-end vakvereniging en is hét Nederlandse (maar Engels-talige) front-end congres. Elk jaar wordt dit georganiseerd in zaal 1 van het Pathé Tuschinski theater in Amsterdam en staan erom bekend dat ze goed georganiseerd zijn en goede sprekers hebben (en een lekkere lunch). Dit jaar was daarop geen uitzondering!

Animatie - een populair onderwerp

Dit jaar waren animaties een populair onderwerp op Fronteers. Rachel Nabors gaf ons een uitgebreide kijk op het toepassen van animaties in interfaces en het belang van animaties voor gebruikers. Google heeft hier met hun Material Design filosofie ook over nagedacht met zelfs video’s als voorbeelden. Ook liet ze ons kennismaken met een paar libraries waarmee we deze het snelst op het scherm kunnen weergeven, namelijk GSAP en Velocity.js.

Sara Soueidan dook dieper in het animeren van SVG’s via CSS en SMIL. SMIL is een relatief nieuwe specificatie die toegepast kan worden op SVG afbeeldingen, waarmee we veel uitgebreidere animaties kunnen behalen dan via CSS. Denk hierbij aan het animeren van lijnen en vormen, elementen die paden volgen en nog veel meer. Zie hiervoor ook haar eigen website, waar artikelen staan die verder ingaan op SVG’s en het animeren daarvan.

Denk aan je bezoekers

Verschillende presentaties gingen in op het belang van de usability en performance van je website. Heydon Pickering had het voornamelijk over accessibility en hoe we deze in onze 'best practices' toe kunnen passen. Hoewel er op Fronteers veel over animaties gepraat werd, is het een interessant weetje dat sommige animaties gebruikers zelfs ziek kunnen maken. Zo kan overdreven of veelvuldig gebruik van heftige animaties bezoekers misselijk maken of het gevoel van hoogtevrees geven!

Ook moeten we rekening houden met de mogelijkheden van de bezoekers. Niet elke bezoeker kan horen of zien namelijk en websites die hier te weinig rekening mee houden zijn een kriem om door te navigeren voor zo’n bezoeker. Gebruik hier bv. ARIA-rollen voor om aan te geven wat welke elementen op de website doen voor de gebruiker. Voor onze klant Bartimeus hebben we zelf ook al ervaren hoe bijvoorbeeld slechtziende of blinde mensen over een site navigeren. Zo organiseerde collega Hester een tijdje terug voor de collega's een test waarbij we door middel van een speciale bril minder zagen en we op andere manieren moesten navigeren, bijvoorbeeld met een screen reader.

Een ander onderwerp dat hiermee te maken heeft is de performance van je website. Dave Olsen liet zien dat een gemiddelde homepage tegenwoordig al 1.8MB groot is en dat heeft veelal te maken met de afbeeldingen, scripts en webfonts die worden ingeladen. Maar liefst 71% van de bezoekers verwacht dat een mobiele website even snel laadt als een desktop website, maar in de praktijk blijkt dat lang niet altijd gehaald te worden. Hier zijn verschillende oplossingen voor, zoals responsive images en het optimaliseren van de 'critical rendering path'. Reponsive images kunnen we gebruiken om kleinere versies van afbeeldingen te tonen op mobiele devices, zodat er in plaats van 1.8MB maar 100KB ingeladen hoeft te worden. Het optimaliseren van het critical rendering path kan door bijvoorbeeld de CSS die verantwoordelijk is voor de content die boven 'the fold' getoond wordt, inline op de pagina in te laden en de overige CSS asynchroon in te laden wanneer de pagina geladen is. Dit geeft de bezoeker het idee dat de website supersnel getoond wordt, terwijl er op de achtergrond nog van alles ingeladen kan worden.

Een gegeven waar maar weinig rekening mee gehouden wordt is dat de bezoekers van onze sites en apps niet altijd online zijn. Veel apps worden bij het ontbreken van een (stabiele) verbinding alleen maar goed in het tonen van een foutmelding dat er geen verbinding beschikbaar is. Maar is offline zijn wel een fout? Volgens Alex Feyerke van het Hood.ie ontwikkelteam niet. Offline zijn is een gegeven, een omgevingsvariabele, net als het apparaat of de browser waarin iemand in werkt, of de schermgrootte van het display. Wanneer we hier rekening mee houden, offline-first genaamd, kunnen we onze apps veel nuttiger maken voor onze gebruikers. Zo kunnen we kritieke data natuurlijk ook op het apparaat zelf opslaan in plaats van alleen in de cloud. Gebruikers kunnen dan te allen tijde nog bij de gegevens die op hun eigen apparaat staan. Met behulp van Hood.ie kunnen gebruikers zelfs nog op een site of app gegevens aanpassen, waarna deze gegevens weer gesynchroniseerd worden met de cloud wanneer er verbinding is. Ideaal toch? In ieder geval genoeg stof tot nadenken.

Realtime communicatie

In sommige situaties is het nodig om realtime te communiceren met de bezoeker, bijvoorbeeld bij een chat-dienst. Hierbij is het van belang dat de berichten van anderen zo snel mogelijk terecht komen bij iedereen. Arnout Kazemier liet ons een aantal technieken zien:

  • Short-polling, hierbij wordt er met een kort interval aan de server gevraagd om nieuwe informatie. Nadeel hiervan is dat er niet altijd informatie is om terug te geven en het dus verspilde requests zijn. Ook is dit niet helemaal realtime, omdat er vlak na een request informatie beschikbaar komt die pas met de volgende request wordt verstuurd. Wanneer hier dus een aantal seconden of minuten tussen zit, kan je niet meer echt spreken van realtime.
  • Long-polling. Met long-polling wordt er een verbinding opengehouden met de server, waarbij de server pas reageert als er nieuwe informatie beschikbaar is. Voordeel hiervan is dat de request pas wordt beantwoord wanneer er nieuwe informatie is. Probleem hierbij is dat wanneer de request langer dan ± 25 seconden openstaat, dit in veel browsers resulteert in een timeout waarna er alsnog een nieuw request verstuurd moet worden om up to date te blijven.
  • WebSockets. WebSockets zijn een relatief nieuwe techniek. Met deze techniek kan er via het WebSockets protocol een verbinding opengezet worden waarmee server en client realtime naar elkaar berichten kunnen versturen zonder dat de ander daarom hoeft te vragen. Probleem met WebSockets is dat deze niet altijd even stabiel zijn. In sommige browsers of besturingsystemen kan dit zelfs tot complete crashes van de browser leiden. Gelukkig zijn deze bugs te verhelpen en wordt die langzamerhand steeds beter.
  • Server Sent Events, oftewel EventSource. Met Server Side event kan er vanuit de server ook een bericht verstuurd worden naar de client. Maar zoals de naam doet vermoeden is dit vooral éénrichtingsverkeer. Niet ideaal dus wanneer er ook data verstuurd moet worden vanaf de client.
  • WebRTC. Deze techniek is cutting-edge en wordt bijvoorbeeld als in een project van ons gebruikt om realtime video-chats mee op te zetten. Met WebRTC kunnen twee browsers, zonder tussenkomst van een server, met elkaar verbinding maken om data naar elkaar te versturen. Dit kunnen eenvoudige tekstberichten zijn, maar ook bestanden of videostreams. Omdat deze techniek zo nieuw is, wordt deze nog niet overal ondersteund. Firefox, Chrome en de laatste Android versie ondersteunen deze techniek. iOS, Safari en IE blijven voorlopig achter qua ondersteuning.

Potje gamen?

Tijdens drie korte mini-sessies werd ons getoond hoe verschillende developers het ontwikkelen van games voor de browser hebben aangepakt. Thomas Palef van LessMilk had zichzelf als doel gesteld om gedurende 12 weken elke week 1 game te maken. Hiervoor heeft hij gebruik gemaakt van de Javascript game engine Phaser. Hij raadde aan om wanneer je developer bent en van gamen houdt, je eens te verdiepen in het maken van games. Zijn advies was dan ook: begin, maar begin simpel, gebruik een framework en verleg langzaam maar zeker je grenzen.

Luc Bloom van Blue Giraffe liet ons zien hoe zij het ontwikkelen van games voor de browser hebben benaderd. Dit jaar zijn ze voor het eerst gaan overwegen om games te ontwikkelen voor de browser, wat gelijk een aantal vragen bij ze opriep over bijvoorbeeld performance, security, verdienmodel en copyright. Ook zij hebben Phaser als game engine gebruikt omdat het anders teveel tijd kost om de onderliggende techniek zelf te gaan schrijven.

Als laatste game presentatie kwam Dominic Szablewski met een imposante demo van zijn eigen game engine, Impact. Dit is voornamelijk een 2d game engine, maar voor een competitie (waarvan hij de deadline maar met ongeveer een jaar overschreed ;)) wilde hij een 3d game maken. Hij ontwikkelde Xibalba, een 3d shooter die me nog het meest aan Wolfenstein en Doom deed denken met imposante sprite art. Ook liet hij de zelf-ontwikkelde map editor zien die hij daarvoor had ontwikkeld om snel en heel eenvoudig levels te maken.

Voor herhaling vatbaar?

Jazeker. Fronteers was ook dit jaar weer een zeer interessante conferentie, waarbij er voor iedereen wel zeer interessante onderwerpen tussen zaten. Ook volgend jaar hopen we weer van de partij te kunnen zijn, dus misschien, tot volgend jaar?

 

E-sites zoekt developers!

Technologie ontwikkelt zich razendsnel. En wij dus ook. We omarmen nieuwe technologie, experimenteren en investeren. In goede tools en apparatuur. En in jou. Join us! Bekijk onze vacatures.

Tik um aan vrouwen!

Door E-sites

Een ode. Aan alle vrouwen die werkzaam zijn binnen de technologie. - Lees meer

Lees verder