Fronteers — vakvereniging voor front-end developers

Hoe een blinde klant zich heel even miljonair waande

Tijdens een screenreader demo zorgt het wel eens voor verwarring (of hilariteit) als een Engelse afkorting met een sappig Vlaams accent wordt opgelezen, of wanneer een screenreader iets onverstaanbaars uitkraamt. In uitzonderlijke gevallen leest een screenreader ook iets voor wat er helemaal niet lijkt te staan. Weird!

Front-endontwikkelaars die hun werk testen met een screenreader — dat is een prima gewoonte — komen hierdoor wel eens in de verleiding om 'ter verduidelijking' verborgen stukjes tekst toe te voegen, of te vervangen door iets anders (bijvoorbeeld met behulp van een aria-label).

Is dat nou echt nodig? Of maakt het je webinhoud juist minder toegankelijk? Dat onderzoek ik voor je in dit artikel.

Collage: stapel eurobiljetten en icoon van een luidspreker

What the FAQ?

Wat volgt, is een eerder extreem voorbeeld, maar het zet de toon. Een tijd geleden stootte ik op deze vraag in een discussiegroep:

"Help! Jaws (een populaire screenreader) leest de link 'FAQ' in onze navigatie voor als f*ck. Dat wil ik niet. Hoe los ik dat op?"

Behulpzame mensen suggereerden vervolgens vanalles, gaande van het toevoegen van een <abbr title="Veelgestelde vragen"> tot het vervangen van het woord FAQ door F.A.Q. (waardoor de letters afzonderlijk worden uitgesproken). Het slechtste advies was wellicht om het woord FAQ met behulp van een aria-label te vervangen door het fonetische F E Cue (omdat dat met een Nederlandse stem dan net zo klinkt als FAQ in het Engels).

De tipgevers leken ervan uit te gaan dat iedere screenreader dezelfde text-to-speech (TTS) engine gebruikt (met dezelfde uitspraakregels) en dat TTS de enige manier is waarop blinde gebruikers tekst en webinhoud consumeren.

Wat ze ook over het hoofd zagen, is dat F E Cue in (refreshable) braille vast nog meer wenkbrauwen doet fronsen dan wanneer FAQ als F*ck wordt uitgesproken. De meeste blinden gebruiken TTS en braille immers naast (en door) elkaar, bijvoorbeeld voor het invullen van formulieren en het verbeteren van teksten (een dt-fout kan je immers niet horen).

Wat is dan de juiste aanpak?

Een goede raad is om je niet al te druk te maken om zo'n slip of the (synthetic) tongue. Ik zou hoogstens adviseren het woordje FAQ te voorzien van een lang="en" attribuut. Hierdoor zal een screenreader in de meeste gevallen tijdelijk omschakelen naar een Engelstalige TTS engine voor het oplezen van dat ene woordje. Dat zou je overigens ook kunnen doen wanneer je een Engelse uitdrukking gebruikt, zoals a slip of the tongue dus.

In theorie zou je er ook met CSS voor kunnen zorgen dat een string uitgespeld wordt, bijvoorbeeld door een eenvoudige helper class te gebruiken:

.speak-literal {
speak: literal-punctuation;
}

Helaas werkt dat dan weer enkel op iOS, dus ook daar kan je niet op vertrouwen.

Maar, omdat je aandringt: hier zijn drie verschillende manieren waarop FAQ kan weerklinken door de speakers van je gebruiker:

  • FAQ wordt netjes (als een letterwoord) gespeld door Alex (een Amerikaanse mannenstem die standaard bij macOS zit).
  • FAQ wordt (voluit) opgelezen als 'Frequently Asked Questions' door Nora of Samantha (populaire stemmen in VoiceOver op iOS).
  • FAQ klinkt inderdaad als F*ck uit de (synthetische) mond van de meeste Nederlandse stemmen van fabrikant Nuance, die bijvoorbeeld populair zijn bij Windows-gebruikers.

Let it go

Je kunt nooit met zekerheid weten welke synthetische stem je gebruiker verkiest of geïnstalleerd heeft, laat staan hoe geavanceerd de voice heuristics zijn die de TTS engine hanteert bij het omzetten van tekst naar kunstmatige spraak. Straks meer over de werking van die heuristics.

Je kan bijgevolg helemaal niet voorspellen hoe FAQ (of een ander woord) zal klinken op het device van jouw gebruiker.

Hoe werkt dat dan?

Windows, macOS, iOS en Android hebben een ingebakken Speech API. Die zorgt ervoor dat software-ontwikkelaars gemakkelijk een stem kunnen geven aan hun applicaties. Ook screenreaders als Jaws en VoiceOver maken gebruik van die functionaliteit.

Zo'n Speech API werkt maar in één richting: de screenreader stuurt strings (woorden of lappen tekst) naar de Speech API en geeft hierbij hoogstens aan met welke stem (en dus ook in welke taal) en met welke spreeksnelheid of toonhoogte die fragmenten voorgelezen moeten worden. Dat doet zo'n kunstmatige stem vervolgens plichtsgetrouw, zonder zich bewust te zijn van de context.

(Die stukjes tekst haalt de screenreader overigens eerst — via een Platform API — op uit de accessibility tree van je browser, maar dat is een verhaal voor een andere keer.)

Stephen Hawking on steroids?

Kunstmatige stemmen (in alle mogelijke talen) worden tegenwoordig gewoon meegeleverd met het OS. Voor Windows, macOS en Android zijn bovendien diverse third party stemmen te koop die ontwikkelaars via dezelfde API’s kunnen aanspreken. Sommige van die stemmen klinken tegenwoordig verbazend natuurgetrouw (Google Wavenet, anyone?), maar dat is niet per se wat een screenreadergebruiker wil.

Screenreadergebruikers bepalen helemaal zelf welke stemmen hen het meeste comfort bieden. De meeste gebruikers verkiezen hierbij efficiëntie boven 'menselijkheid'.

Een vriend van me is blind. Hij zweert bij een (stokoude) robotische stem met een erg hoge spreeksnelheid (Stephen Hawking on steroids, zeg maar). Voor een ongetraind oor klinkt dat als een onverstaanbaar geratel, maar voor hem is het een uiterst effectieve manier om snel informatie te 'op te nemen'. Het gaat immers veel sneller dan braille lezen, en misschien zelfs sneller dan 'gewoon' lezen (met je ogen dus).

Voice Heuristics

TTS engines zitten vol met regeltjes of 'heuristics'. Die zijn bedoeld om de stem zo natuurlijk mogelijk te doen klinken, en zijn verschillend naargelang de stem, de taal, de fabrikant en de versie van de stem (yes, ook stemmen krijgen wel eens een update).

Als een TTS engine té slim wordt, loopt het wel eens mis. Straks meer, maar eerst: speeltijd.

Tem die stem!

Om een idee te krijgen hoe die 'regeltjes' werken, is het leuk om zelf wat te experimenteren met hoe verschillende strings voorgelezen worden met verschillende stemmen.

Op macOS kan je in een Terminal-venster het say commando uitvoeren. Met -v kies je de stem. Ga naar Systeemvoorkeuren → Spraak om te zien welke stemmen beschikbaar zijn op jouw computer (of tik say -v ? in de Terminal).

Enkele leuke voorbeelden:

say "Lodewijk IV" -v Xander	# klinkt als "Lodewijk Vier"
say "Louis IV" -v Alex # klinkt als "Louis The Fourth"

Hé, wat is ie slim! Of toch niet?

say ":-)" -v Alex	# klinkt als "" (stilte)
say ":-)" -v Ellen # klinkt als "Blije smiley"
say "(*)" -v Alex # klinkt als "Asterisk"
say "(*)" -v Ellen # klinkt als "" (stilte)

Je leest (hoort) het goed: de Vlaamse stem Ellen negeert deze drie opeenvolgende karakters (haakje open, asterisk, sluitend haakje) gek genoeg helemaal. Best lastig wanneer je wilt aangeven wanneer iets verplicht in te vullen is. Hier zou een aria-label="Verplicht" bijvoorbeeld uitkomst kunnen bieden.

Maar, wat denk je van deze?

say "1/12/2018" -v Xander	# klinkt als "1 december 2018"
say "1/12/2018" -v Alex # klinkt als "January 12, 2018"

Wacht, wat? Dit zijn toch precies dezelfde strings? Probeert de TTS Engine ons te slim af te zijn?

Xander is een Nederlandse stem, Alex een Amerikaanse. Als je een Amerikaan van vlees en bloed zou vragen om "1/12/2018" voor te lezen, zou hij het net zo interpreteren (en voorlezen) als Alex. Als 12 januari dus. Slim toch, van die computerstem?

En toch zie je dat developers in meertalige applicaties helemaal overboord gaan met dynamisch gegenereerde aria-label's om ervoor te zorgen dat datums, prijzen, tijdstippen etc. 'juist' opgelezen worden. Helemaal niet nodig, en een vorm van over-engineering waarmee ze het zich enkel lastig maken.

Als je hierop let, gaat het vanzelf goed:

  • Zorg ervoor dat je de (natuurlijke) taal goed aangeeft (bv. met een lang attribuut op het <html> element) zodat de screenreader een TTS engine aanspreekt die de juiste taal spreekt.
  • Respecteer simpelweg lokale regels over de notatie van datums: als je applicatie in het Nederlands wordt weergegeven, gebruik je dd/mm/jjjj. In het Engels wordt dat mm/dd/yyyy. Dan gaat het vanzelf goed.

Hoe een blinde klant zich heel even miljonair waande

Ik sluit af met een true story. Deze (sterk vereenvoudigde) markup oogt onschuldig, zeg nu zelf. (Ik heb het stukje HTML geplukt uit de webapplicatie van een bank.)

<h1>Transacties</h1>
<ul>
<li>
<span class="date">1/12/2018</span>
<span class="amount">€ 50</span>
<span class="from">R. Van Gils</span>
</li>
<li>
<span class="date">31/11/2018</span>
<span class="amount">€ 25</span>
<span class="from">M. Rutte</span>
</li>
</ul>

Je weet natuurlijk dat <span>'s inline level HTML-elementen zonder semantische eigenschappen zijn. Daarom worden het bedrag en de naam in de accessibility tree 'versmolten' tot de strings € 50 R. Van Gils en € 25 M. Rutte. Dat gebeurt overigens ook wanneer de <span>'s met display: flex of display: block worden uitgelijnd (of anderszins opgesmukt), want daar heeft een screenreader lak aan.

De TTS engine zal opnieuw zijn (of haar) beste beentje voorzetten om de aangeleverde strings zo menselijk mogelijk voor te lezen. Dat is immers haar (of zijn) enige taak.

Voor bovenstaand voorbeeld klinkt dat (alweer afhankelijk van de gebruikte TTS engine) ongeveer zo:

  • Kopniveau 1: Transacties
  • Lijst met 2 items
  • Vijftig euro R. Van Gils
  • Vijfentwintig miljoen euro Rutte
  • Einde van lijst

Wat? 🙆‍♀️ Vijfentwintig miljoen? Dat klopt natuurlijk niet. De helpdesk van deze bank reageerde met ongeloof toen een blinde klant dit probleem meldde, en ook de testers wisten er in eerste instantie geen raad mee.

Maar, je begrijpt intussen waar het aan ligt: een gebrek aan semantiek in combinatie met 'slimme' voice heuristics. De voorletter 'M.' zorgt er namelijk voor dat de string € 25 M. Rutte geïnterpreteerd (en opgelezen) wordt als Vijfentwintig miljoen euro Rutte.

Is het een edge case? Tja, wel eentje die zich voordoet bij alle mensen die M. als voorletter hebben in hun naam. Is het makkelijk te voorkomen? Zeker! Je hoeft dit niet te patchen met aria-label's. Je lost het simpelweg op door headings, paragrafen en lijsten te gebruiken in plaats van <span>'s. Of wat had je gedacht?

Conclusie

Je zal het altijd zien: als je paginasemantiek fout zit (of ontbreekt), gaat de accessibility van je website ook de mist in. Niet enkel omdat het dan lastig navigeren wordt voor screenreadergebruikers, maar dus ook omdat TTS Engines de plank dan vaker misslaan.

Dat neemt niet weg dat het altijd de moeite loont om je website te testen met een echte screenreader. Zo kan je gênante situaties voorkomen.

En, oh ja: maak je niet al te druk over iedere synthetische slip of the tongue, want dat doen jouw gebruikers ook niet.

CSS statistieken om je codebase te verbeteren

Front-end is makkelijk, CSS helemaal. Toch valt het veel developers niet mee om complexiteit de baas te blijven bij groeiende CSS codebases. Zeker wanneer met meerdere personen en teams aan een project gewerkt wordt, is het lastig om bij te houden en te controleren of iedereen zich nog wel aan de afspraken houdt. Het klassieke voorbeeld is de monoliet van duizenden regels code die meer dan 50 tinten grijs bevat of ruim 100 unieke font-sizes. Gelukkig zijn er tools voorhanden die je inzicht kunnen geven in de CSS die jouw applicatie uitspuugt. Deze tools analyseren je CSS en genereren een rapport met bijvoorbeeld de filesize, het aantal selectors, de unieke kleuren en ga zo maar door. Tijdens een presentatie die ik hierover een aantal jaar geleden gaf, bleek de interesse voor CSS statistiek-tools groot, dus hieronder wat tips om CSS statistieken in te zetten om de kwaliteit van je codebase inzichtelijk te maken en te verbeteren.

De tools

Allereerst, de tools. Zelf gebruik ik de volgende tools om statistieken over mijn CSS te laten genereren:

  • CSS Stats - Webapp en CLI tool om verschillende statistieken over je CSS te visualiseren
  • Parker - CLI tool/node module voor CSS statistieken
  • Project Wallace CSS Analyzer - CLI tool voor CSS statistieken. Op de website kan ik bijhouden hoe de statistieken veranderen naarmate de tijd verstrijkt.

De ene tool is niet per definitie beter dan de andere. Het is maar wat je er mee wilt bereiken. Voor dit artikel kijken we voornamelijk naar het meten van complexiteit en kwaliteit.

Complexiteit meten

‘Echte’ developers hebben het al heel lang, maar wij CSS-nerds zijn nog een beetje verstoken van tooling zoals het meten van bijvoorbeeld cyclomatic complexity. Gelukkig kunnen we met wat statistieken wel vergelijkbare metrics opstellen. Enkele belangrijke metrics die ik zelf toepas om de complexiteit van een codebase te bepalen zijn:

  • Gemiddeld aantal identifiers per selector: Lange selectors betekenen dat je CSS nauw verbonden is aan de HTML. Dat betekent dat je styling stuk kan gaan als een kleine wijziging wordt gedaan in je template. Eigenlijk is elke identifier in je selector een if-statement en daarom is deze metric voor mij min of meer gelijk aan het meten van cyclomatic complexity.
.my-selector {} /* 1 identifier */
.my #super [complex^="selector"] > with ~ many :identifiers {} /* 6 identifiers */
  • Average cohesion: Het gemiddeld aantal declarations per ruleset. Een laag gemiddelde is een indicatie van complexe ‘objecten’.
/* 1 rule, 1 declaration => cohesion = 1 */
.text-center {
text-align: center;
}

/* 1 rule, 8 declarations => cohesion = (1 / 8) = 0.125 */
.button {
background-color: blue;
color: white;
padding: 1em;
border: 1px solid;
display: inline-block;
font-size: normal;
font-weight: bold;
text-decoration: none;
}
  • Filesize: Hoe groter je CSS, hoe complexer…
  • Importants: Hoewel een !important op zijn tijd zeker niet verkeerd is, kan een hoog aantal !importants duiden op een moeilijk onderhoudbaar stuk CSS.
  • Aantal unieke kleuren/font-families/font-sizes: Projecten die honderden unieke kleuren en font-sizes gebruiken zijn lastig. Wanneer weet je of je de juiste font-size of color hebt? En is de grijs van de header nou de goede, of die van de footer? Ach, ik gebruik de color picker van Photoshop wel weer om een kleurtje uit het design te pikken…
  • Aantal unieke @media queries: Zoals met elke metric is het lastig te bepalen wat goed is en wat slecht, maar als ik 150 unieke @media queries zie, dan weet ik dat het lastig gokken wordt om de juiste te gebruiken.
  • Specificity graph: Het gebruik van de specificity graph is handig als je wilt kunnen zien waar complexe selectors zich in je codebase bevinden. Daar zijn gelukkig ook tools voor!

Kwaliteit meten

Wat de term kwaliteit inhoudt verschilt per project (evenals complexiteit overigens), maar voor veel projecten gelden de volgende punten zeker:

  • Branding - aantal unieke kleuren/font-families/font-sizes: CSS gaat voornamelijk om branding en het mooi maken van webpagina’s. Vormgevers doen hun best op het maken van mockups die wij weer omzetten in code. Daarbij gaat wel eens een detail verloren en kan het gebeuren dat het eindproduct andere kleuren bevat dan de vormgever voor ogen had. Ik heb voor bedrijven gewerkt waar geëist werd dat alle kleuren en fonts voldeden aan de voorgeschreven brand guide. Gelukkig had ik tools om aan te tonen dat alles netjes binnen de kaders was.
  • Methodologie - cohesion, gemiddeld aantal identifiers: Een opkomende trend in het CSS-landschap is utility-based CSS. Kort gezegd is dat een stylesheet vol classes die een heel klein dingetje doen. Een kenmerk van zo’n library is dan dus ook dat de cohesion heel dicht bij 1 ligt, evenals het gemiddeld aantal identifiers per selector. Goede metrics om aan te tonen dat je niet afwijkt van je gekozen strategie!
/* 
Voorbeeld uit Tailwind CSS waar 1 rule
1 selector en 1 declaration heeft:
https://tailwindcss.com/docs/text-color
*/
.text-transparent { color: transparent; }
.text-black { color: #22292f; }
.text-grey-darkest { color: #3d4852; }

Bugs opsporen

Soms kom je onverwachte dingen tegen in je CSS statistieken. Rare selectors of onverwacht complexe declarations. Een greep uit een aantal vondsten die ik de afgelopen tijd in eigen of andermans codebases deed:

  • Fronteers.nl bevat 20 lege rulesets 😱
  • Bol.com heeft een wel heel rare selector: Bulk beeldmerk 22 mei 2017 .flexbanner--billboard .flexbanner__button.c-btn-tertiary--small.mini_details:before
  • Een project op mijn werk waar een selector als volgt werd getoond als meest complex: input[type=checkbox]:checked+.label input[type=radio]+label:focus:after. Een gevalletje waar we een foutje hadden gemaakt met nesting in de preprocessor (inputs nesten werkt doorgaans niet zo best). Gelukkig zagen we de fout op tijd dankzij Project Wallace.
  • Facebook heeft vier verschillende manieren om de kleur wit te beschrijven. Dat is niet noodzakelijk verkeerd, maar het kan een teken zijn van een aantal issues in de codebase, zoals bijvoorbeeld een kapotte CSS minifier.
  • Catawiki had op enig moment meer dan 4095 selectors (IE selector limit, iemand?) en wetende dat zij IE8+ supporten in verband met een breed internationaal publiek, betekende het dat bezoekers met IE9 niet alle CSS voorgeschoteld kregen wat mogelijk tot bugs geleid heeft. Na een melding hebben zij hun stylesheet in tweeën gesplitst en was het euvel voorlopig verholpen.

Tot slot

Voor alle metrics die deze tools genereren geldt dat er niet noodzakelijk een goed of fout is. Er zijn developers die zweren bij het nesten van selectors met behulp van preprocessors en er zijn developers die dat haten. Zo zijn er ook mensen die fel gekant zijn tegen het gebruik van !important en mensen die het inzetten om hun utility classes meer kracht bij te zetten. Wat je voorkeur ook is, deze en andere tools kunnen je helpen om de gevolgen van jouw keuzes inzichtelijk te maken voor jezelf, maar hopelijk ook voor anderen. Doe er je voordeel mee.

Wil je meer lezen? Hier enkele leestips:

Word een front-end developer

Begin september 2018 heeft Shaun Michael Stone zijn ervaringen, mening en advies gedeeld over hoe het is om front-end web engineer te zijn.

In dit artikel wil ik mijn ervaringen delen over het begin van een front-end carrière.

Beginnen met leren

Veel front-end developers beginnen door te experimenteren. Het is niet zo moeiijk om daarmee te beginnen. Je hebt alleen een browser en een texteditor nodig. Twee hele goede voorbeelden zijn Visual Studio Code en Atom en ze zijn gratis! Daarna wil je HTML en CSS leren. Door in een zoekmachine te zoeken naar “HTML tutorial” en “CSS tutorial” zou je al een heel eind moeten komen. Voor je het door hebt, bouw je een website!

Tijdens de experimentele fase zal je vooral het volgende leren:

  • HTML: HyperText Markup Language, de taal om inhoud te organiseren
  • CSS: Cascading StyleSheets, de taal om de inhoud te stijlen
  • JavaScript: een programmeertaal waarmee je complexe features kunt bouwen
  • Basiskennis over browsers en hoe internet werkt

Beginnen met HTML en CSS is makkelijk, maar het goed doen is een ander verhaal en vergt best veel kennis. Ik verwacht niet dat junior developers bekend zijn met alle onderwerpen in het lijstje hieronder, maar er van bewust zijn dat het bestaat en wat je kunt leren, kan je wel een voorsprong geven:

  • HTML
    • Basis: in staat zijn om functionerende HTML te schrijven
    • Validiteit: in staat zijn om HTML te schrijven met weinig fouten
    • Browser compatibiliteit: hoe om te gaan met browser incompatibiliteit
    • Memorisatie: bekend zijn welke HTML tags bestaan
    • Semantiek: weten welke HTML tag goed is in welke situatie
    • Toegankelijkheid: markup optimaliseren voor iedereen, ook mensen met beperkingen
  • CSS
    • Basis: in staat zijn om functionerende CSS te schrijven
    • Validiteit: in staat zijn om CSS te schrijven met weinig fouten
    • Browser compatibiliteit: hoe om te gaan met browser incompatibiliteit
    • Responsive ontwerp: weten hoe je een ontwerp optimaliseert voor verschillende apparaten en schermen
    • Architectuur: weten hoe je dingen moet noemen, verantwoordelijkheden scheidt, bestanden organiseert, en de code onderhoudbaar houdt
    • Toegankelijkheid: weten wat voor rol stijling bijdraagt aan toegankelijkheid en afweten van beste en slechte praktijken
  • JavaScript
    • Basis: in staat zijn om functionerende JS te schrijven
    • Probleemoplossend vermogen: weten hoe je een probleem aanpakt om een doel te behalen
    • Debuggen: hoe je bugs vindt, isoleert en oplost
    • Web platform: wat kennis van de DOM API (HTML hiërarchie tijdens runtime) en wat Web APIs
    • Principes: scheiden van verantwoordelijkheden, KISS, etc
    • Onderhoudbaarheid: hoe je de code onderhoudbaar houdt
    • Wanneer je het moet gebruiken, en wanneer niet
    • Verschil tussen ECMAScript en JavaScript
  • Browsers en het internet
    • HTTP Protocol: hoe browsers inhoud laden
    • Media encoderingen: weten wanneer je gif, jpg, png, svg, webp, mp3, mp4, etc. moet gebruiken

Bovenstaande lijst lijkt misschien veel, maar maak je geen zorgen. Focus vooral op HTML, CSS en basis JavaScript. De rest volgt vanzelf.

Beginnende front-end developers ontdekken snel wat JavaScript is en hoe populair het is. De markt heeft veel vraag naar developers die kunnen programmeren met JavaScript. Sterker nog, er is vaak voorkeur naar mensen die vloeiend JavaScript programmeren dan mensen die vloeiend HTML en CSS schrijven, terwijl slechte HTML en CSS vaak problemen veroorzaken wat betreft toegankelijkheid.

Wanneer je de basis leert, leer ook wat JavaScript, maar vergeet niet dat (goede) HTML en CSS essentieel zijn voor websites en webapplicaties.

Jouw eerste baan

Je eerste baan is een gigantische mijlpaal! Het is je allereerste stap in je carrière. Maar hoe bereik je die mijlpaal?

Net als met producten is er vraag en aanbod in de banenmarkt die de “prijs” bepaalt. In de banenmarkt is de “prijs” terug te zien in je salaris en extra’s. Momenteel is de markt in ons voordeel: er is veel vraag naar front-end developers, vooral ervaren front-end developers.

Ik verwacht dat het aanbod zal stijgen, maar daarmee moet je meer opvallen ten opzichte van andere mensen die een baan zoeken als front-end developer. Er zijn een paar manieren om dat te doen.

Haal een diploma

Ik was heel lui en verveeld op school. Ik denk dat ik met een beetje moeite een bachelor en/of master graad had kunnen behalen, maar dat heb ik niet gedaan. Ondanks dat ik dat niet heb, werk ik met toffe en hele slimme mensen.

Momenteel lijkt het er op dat een diploma niet zo veel helpt. Veel mensen die dit wel hebben, hebben vaak wel een goede theoretische achtergrond en lijken problemen op een meer wetenschappelijke methode te benaderen.

Wanneer de vraag in de banenmarkt groeit, denk ik dat een opleiding in media of informatica belangrijker gaat worden, vooral voor developers die geen of weinig ervaring hebben.

Een studie doen is niet goedkoop en kost veel tijd. Gelukkig zijn er veel bedrijven die de kosten (deels) op hun nemen en soms mag je zelfs tijdens werkuren studeren. Dan kan je studeren en ook je rekeningen betalen! Denk goed na over wat voor opties er zijn en wat het beste bij jou past.

Zelfstandig leren

Front-end development is heel goed gedocumenteerd. Online is er heel veel informatie te vinden, wat het mogelijk maakt om een developer te worden door te lezen of online cursussen te volgen. Veel developers die ik ken hebben het vak volledig zelfstandig gestudeerd.

Hier een paar linkjes naar documentatie en cursussen om zelfstandig te studeren:

Je kunt ook lid worden van een gemeenschap zodat je met anderen kan praten over front-end development. Neem bijvoorbeeld de Fronteers Slack of FEDs on Slack.

Documentatie is belangrijk

Laten zien wat je gemaakt heb is een goede manier om jezelf te verkopen, dus zorg ervoor dat je een portfolio hebt met wat je gemaakt hebt. Documenteer je projecten (ook van school) en side-projects goed.

Zorg er ook voor dat je niet alleen het resultaat demonstreert, maar ook het proces daar naartoe. Gedurende een project los je uitdagingen op door opties te overwegen. Het verdedigen van die keuzes geeft veel inzicht in hoe goed jij bent en hoe jij keuzes maakt.

Als je schrijven leuk vind, kun je ook artikelen schrijven! Het schrijven van technische artikelen geeft een enorme voorsprong. Sommige bedrijven betalen zelfs om een artikel op hun blog te publiceren, wat mooi meegenomen is.

Wees zichtbaar

Laat jezelf zien! Je bent een front-end developer. Het web is jouw domein. Gebruik dat dus!

  • Je kunt LinkedIn gebruiken als een soort online CV en om je interesses te delen
  • Publiceer je eigen code (bijvoorbeeld experimenten) op GitHub
  • CodePen is een leuke site om kleine demo’s en experimenten te maken en te laten zien
  • Andere sociale media, zoals Twitter en Facebook, kunnen ook handig zijn om interesses te delen en om te netwerken
  • Een eigen website met een blog en links naar jouw profielen
  • Als je een freelancer wilt worden, denk na over een ‘personal brand’ en hoe je jezelf in de markt wilt zetten

Misschien valt het op dat veel opties in bovenstaande lijst een offer vergt: tijd. Al is geen van bovenstaande punten vereist om een baan te vinden, je springt er wel door uit, dus durf wat tijd te investeren.

Overweeg opties

Wil je generaliseren of specialiseren? In wat voor soort situatie kan je het meest leren? Wat voor soort bedrijf zou jou een kans geven?

Denk goed na over hoe je jouw carrière wilt starten. Wil je een ‘manusje-van-alles’ zijn bij een klein bureau, of wil je specialiseren als een in-house developer met collega’s waar je van kunt leren? Misschien wil je jouw eigen ding doen als een freelancer. Wat je ook kiest, elk heeft voor en nadelen, dus denk daar over na.

Als je andere interesses hebt buiten development, is het leuk om een baan te vinden in die industrie.

Aan de slag! Wat nu?

Software verandert constant, dus we moeten up-to-date blijven om relevant te blijven. Denk aan principes, tools, browsers, specificaties, browser compatibiliteit, apparaten en features van apparaten. Dat zijn heel veel onderwerpen om in de gaten te houden en dit verklaart ook waarom het vak front-end development langzaam opsplitst in specifiekere specialisaties.

Als je naar specificaties en documentatie kijkt, kan alleen al de hoeveelheid browser-functies en Web API's schrikbarend veel zijn. Gelukkig heb ik een strategie om niet gek te worden van de hoeveelheid nieuwe informatie.

Een klein deel van al die API’s wordt vaak gebruikt. In plaats van proberen alle API’s te onthouden, lees ik een klein beetje over elke API zodat ik ongeveer weet wat ik kan doen en vergeet ik de details. API’s die ik vaak gebruik, onthou ik vanzelf. Door deze strategie kan ik mij richten op probleemoplossend denken, best practices, patronen, principes en andere dingen die lastig te vertalen zijn in concrete zoektermen.

Om up-to-date te blijven kan ik sociale media aanraden. Ondanks de ruis is het vaak de eerste plek waar nieuws wordt gedeeld. Zoek mensen en bedrijven op die jij interessant vind en volg ze. Hier wat voorbeelden:

Lezen en experimenteren met dingen die je leert, zou je tijdens werkuren moeten kunnen doen. Een fatsoenlijk bedrijf zal je die gelegenheid geven en heeft een opleidingsbudget zodat je congressen en workshops kan bezoeken. Maak daar gebruik van! Een paar goede events zijn:

Werken in je vrije tijd

Eerder in dit artikel heb ik het werken in je vrije tijd al kort benoemd om een portfolio op te bouwen. Ik moedig dit aan als je een voorsprong wilt hebben op anderen, maar ik wil je ook waarschuwen.

Veel bedrijven erkennen het werk in je vrije tijd niet als extra ervaring. Al zou je, naast een 8-urige werkdag, nog 4 uur investeren in side-projects, heb je na een jaar niet anderhalf jaar ervaring opgebouwd. Maar wat je in die extra tijd hebt geleerd, is natuurlijk wel waardevol.

Ons vakgebied reageert erg positief op werken in je vrije tijd, wat veel mensen motiveert om dat te doen, maar niet zonder consequenties. Het kan bijdragen aan problemen met je geestelijke gezondheid. Veel open-source projecten zijn ten einde gekomen of het beheer is naar iemand anders gegaan omdat de originele auteur last heeft van een burn-out.

Werken (inclusief studeren en experimenteren) in je vrije tijd is niet zonder risico’s. Rust en ontspanning zijn belangrijk, en de balans tussen werk en privé is delicaat. Sommige mensen kunnen heel veel stress hebben. Sommige niet. Een ‘workaholic’ zijn is niet cool.

Ik wil heel duidelijk zijn dat werken in je vrije tijd niet verplicht is en waarschijnlijk ongezond. Jouw werkplek moet de tijd faciliteren om nieuwe dingen te leren. Wat je met je eigen tijd doet, is aan jou.

Conclusie

Er zijn veel manieren om front-end web developer te worden. Je kan het jezelf aanleren of met begeleiding door bijvoorbeeld een opleiding te doen. Je kan een generalist of een specialist worden. Je kan zelfstandig beginnen of een bij een bedrijf gaan werken en nieuwe dingen van collega’s leren.

Wat je ook kiest, basiskennis van HTML, CSS en JavaScript is voldoende om aan de slag te gaan. De rest volgt vanzelf.