Twee dagen lang leerden en bevestigden sprekers van hoog niveau ons wat er zoal leeft en wat we in de toekomst mogen verwachten op vlak van front-end development.
Vlakbij de mooie torens van Gent waren we begin juni aanwezig op frontend-united dat plaats vond in de Sphinx cinema. Twee dagen lang leerden en bevestigden sprekers van hoog niveau ons wat er zoal leeft en wat we in de toekomst mogen verwachten op vlak van front-end development. Een korte samenvatting van wat ons bij bleef.
Een front-end developer, Drupal themer, slicer ... of hoe je hem/haar ook noemt stond vooral bekend als de persoon die een ontwerp omzet naar html en css. Je kan het al raden, vandaag de dag is deze omschrijving totaal niet meer van toepassing en veel te beknopt. Er komt bij front-end veel meer kijken dan enkel de development.
In elke front-end developer zit deels …
.. een designer. Vaak wordt de designfase om budgettaire en/of timing redenen beperkt tot het maken van de slechts enkele templates, een overzicht van visuele elementen en een briefing van de designer. Hierdoor moet de front-end developer terugvallen op zijn eigen designer capaciteiten en zo aan de hand van de visuele elementen en een brand book de overige templates onmiddellijk in de code vormgeven. Wanneer er geen prototypes werden uitgewerkt is het ook de front-end developer zijn taak om het project te voorzien van passende animaties en transities die bijdragen aan de user experience, het gebruiksgemak en het visuele wow-effect. Daarnaast is ook software kennis erg van belang (Photoshop, Sketch, Illustrator, ..) Dit uiteraard allemaal onder het goedkeurende oog van de echte designer ;)
.. een marketeer. Het is te zeggen, een deel van de SEO capaciteiten van een marketeer dan toch. Samen met de developer zorgt de front-end developer ervoor dat elke template en elk onderdeel semantisch correct in elkaar zit zodat het voor zowel de eindgebruiker als voor een zoekrobot duidelijk is wat de inhoud betekent, wat het onderwerp is, waar de belangrijkste inhoud staat en hoe deze opgedeeld is.
.. een developer. Er wordt meer en meer verwacht dat de front-end developer zelf aanpassingen kan aanbrengen in de code om zo de juiste output te krijgen die hij nodig heeft om het ontwerp te evenaren. Zeker nu Twig zijn plaats kreeg in Drupal 8. Ook version control zoals Git en SVN worden als vanzelfsprekend beschouwd. Connecties maken met de server via de terminal, af en toe de rechten eens wijzigen of een vergelijking doen met vorige versies.. elke front-end developer weet er mee om te gaan.
Deze steeds uitbreidende verwachtingen van een front-end developer vielen op door het ruime aanbod aan verschillende onderwerpen op dit event.
Zij die Karl al eens aan het werk zagen weten dat zijn presentaties motiverend en inspirerend werken. Hij zet iedereen in de zaal terug met de voeten op de grond. Wat ons bij bleef aan deze presentatie is dat je als designer nog zo overtuigd kan zijn van je ontwerp; de cijfers en analyses hebben steeds gelijk. Je kan je creatieve ideeën verdedigen met de grootste overtuiging en beste theorieën. Wanneer later dan bijvoorbeeld blijkt dat een product meer wordt aangekocht wanneer de call-to-action knal groen wordt weergegeven in plaats van in de zelfde kleurtinten als in de huisstijl van het merk, kan je ofwel koppig zijn en je eigen ontwerp blijven verdedigen ten nadele van het doel. Of je kan de cijfers accepteren en met de verkregen informatie een oplossing zoeken die visueel voldoet en de gewenste gebruiker acties in stand houdt.
Bekijk hier de presentatie van Karl (een aanrader!)
Een project wordt naar gewoonte uitgewerkt in Photoshop of Sketch en resulteert meestal in statische jpg’s. Weliswaar met de nodige uitleg van de designer. Wanneer de klant akkoord is met de vormgeving worden de bronbestanden doorgestuurd naar de front-end developer die aan de slag gaat met het omzetten van het ontwerp naar een uitgewerkt werkend product. Doordat de aangeleverde jpg’s statisch zijn zal de front-end developer voor het grootste deel zelf instaan voor de animaties, transities en hovers op bepaalde elementen. Het zal dus na de uitwerking en dus ook na de development zijn dat de klant zijn project voor het eerst kan gebruiken en kan voelen of de UX werkt. Wanneer er in die fase nog aanpassingen gewenst zijn brengt dit vaak ook heel wat development aanpassingen met zich mee. Een oplossing? prototypes! Johan gaf ons in zijn presentatie een kijkje in zijn workflow in het maken van werkende prototypes. Ontwerpen worden onmiddellijk in code uitgewerkt. Geen must, deze ontwerpen kunnen ook eerst statisch worden uitgewerkt alvorens de prototypes uit te werken. Prototypes in de ontwerpfase geven de klant een duidelijk beeld van hoe zijn project zal functioneren en aanvoelen. Ze geven de front-end developer een duidelijk beeld van hoe een object zich moet gedragen en vermijden grote development wijzigingen doordat de UX goedkeuring vroeger kan verkregen worden. De CSS en javascript kunnen trouwens perfect overgenomen worden van het prototype naar de productie website. Johan gaf enkele leuke tips die de prototype workflow een pak kan versnellen.
Christian Heilmann
The image problem of the web and how to solve it…
Bekijk de presentatie van Christian.
PostCSS
Sass, maar dan sneller ;)
Bekijk hier de presentatie over postCSS.
Vladimir Grinenko
BEM: complete guide for your component front-end development
Drupal 8 maakt deels gebruik van BEM. Deze presentatie toonde dat BEM nog veel verder gaat…
Bekijk hier de presentatie over BEM.
