In een wereld waar alle webdevelopers komen met hun eigen — haast eindeloze — door jargon doordrenkte lijst met specialiteiten en prestaties die moeilijk in perspectief te plaatsen zijn, is het vaak moeilijk om het kaf van het koren te scheiden.
Of je nu een eenmansbedrijf bent op zoek naar een enkele developer, een marketingmanager op zoek naar een bureau of een bureau op zoek naar een nieuwe developer werknemer, als je een langdurige relatie aan wilt gaan (wat je zou moeten), kun je waarschijnlijk enkele tips gebruiken om de juiste developer te vinden.
Simpel gezegd, er zijn waarschijnlijk eigenschappen waarvan je weet dat je ze wilt, zoals X jaar ervaring of vaardigheid in taal Y. In dit artikel ga ik het daarentegen hebben over een eigenschap waarvan je niet weet dat je deze wilt: de mogelijkheid om kwaliteitscode te produceren.

Na het lezen van dit artikel heb je een idee waarom goed geschreven code belangrijk is, waar je dealbreakers moet zoeken en wat je van een developer kunt verwachten om ervoor te zorgen dat jij en je gebruikers een naadloze ervaring hebben. Kort gezegd: de praktische waarde van kwaliteit, of praktaliteit™.

Dit artikel gaat uit van enige voorkennis over webtechnologieën, maar niet van programmeren 😁.


Laten we de meest voorkomende situatie nemen: je vertegenwoordigt een bedrijf en moet een bureau vinden dat je website gaat ontwikkelen en onderhouden, bij voorkeur natuurlijk voor zo lang dat nodig blijkt te zijn. Normaal gesproken legt men in een dergelijke situatie ruwweg alle nadruk op de volgende criteria: betrouwbaarheid, ervaring, prijs en design.

Vertrouwen is de basis voor elke relatie. Een website online krijgen zonder een partner die je kunt vertrouwen, is zelden eenvoudig. Je weet dit en vindt uiteindelijk een ervaren bureau dat goed communiceert en kan aantonen dat het deadlines haalt. Nadat jullie alle ins en outs hebben besproken, concluderen ze dat ze je website voor 70% van je budget live kunnen laten gaan binnen de gestelde tijd. Mieters! Na enkele iteraties kom je samen uit bij een ontwerp en enkele weken later is jullie website online, zoals beloofd.

3 jaar later…

Je hebt wat kleine veranderingen nodig. Ze zijn doodsimpel, maar niet iets dat je vanuit het CMS kunt doen. Het bureau moet ernaar kijken. Je neemt contact met ze op en vraagt ​​hoe lang ze erover gaan doen. Vervolgens komen ze terug met een verhaal over hoe het gros van de code is geschreven door iemand die er niet meer werkt, of erger nog: ze werken er nog steeds, maar kunnen gewoon niet begrijpen wat ze eerder hebben geschreven.

Over het algemeen verwacht je vandaag de dag min of meer dezelfde behandeling als toen je de relatie aanging. Met die reden heb je niet onderhandeld over een soort “nazorgplan”. Het is moeilijk voor te stellen hoe zo’n plan eruit zou zien, zelfs met het oog op de huidige situatie. Ik bedoel, natuurlijk heb je met elkaar afgesproken dat ze altijd bugs voor jullie zullen oplossen, maar “op maat” wijzigingen zijn niet makkelijk kwantificeerbaar en als zodanig was de enige belofte die werd gedaan “vaste prijs, gebaseerd op hetzelfde uurloon.” Het aantal uren is echter hoog of onbekend. Dus, wat zijn je opties? Als je niet iemand in huis hebt die aan je website kan knutselen, kun je een veelvoud betalen van wat nodig zou zijn voor de veranderingen, een ander bureau zoeken dat het voor minder kan doen (onwaarschijnlijk) of je kunt een geheel nieuwe website regelen. Ai… Plots is de 70% die je 3 jaar geleden betaalde niet zo “mieters” meer.

Functioneel gesproken draait elke website op niets anders dan een groot aantal verschillende programmeertalen. De bovengenoemde criteria waarop iedereen lijkt te focussen, hebben daarentegen niets te maken met de code en de onderhoudbaarheid ervan.

Dit komt omdat voor de meeste mensen die zelf geen code schrijven, code behoorlijk binair is (woordgrap zeer intentioneel): het is werkend of niet werkend. Op zichzelf is die aanname niet goed of fout; het is het sentiment dat ertoe doet:
Voor de meeste niet-programmeurs is code, zolang er geen zichtbare bugs zijn, zo goed als perfect. Laat me je vertellen waarom dat verkeerd is, van back-end tot content.

“[H]et is het sentiment dat ertoe doet:

Voor de meeste niet-programmeurs is code, zolang er geen zichtbare bugs zijn, zo goed als perfect.”

Back-end

75% van alle websites heeft een back-end geschreven in PHP. Dit is de taal die de meeste CMS’en aanstuurt, inclusief WordPress, het meest gebruikte CMS ter wereld. Vanwege deze veelvoorkomendheid zit er een enorme gemeenschap van actieve developers achter. Eenvoudige copy-paste codevoorbeelden zijn overal op het internet te vinden en er zijn honderden PHP-handleidingen geschreven voor elk niveau developer, beginneling tot pro.

Dit alles bij elkaar zorgt ervoor dat de instapdrempel voor het gebruik van PHP vrij laag is. Het betekent ook dat er genoeg amateurs in de business zitten. Ze kunnen de klus misschien wel klaren, maar in ruil daarvoor zijn beveiligingsmaatregelen onvolledig (zonder dat jij of zij het weten), lijken laadtijden op die van het inbel tijdperk (als millennial, weet ik daar natuurlijk alles van) en met randgevallen wordt amper rekening gehouden.

Randgeval

Over randgevallen gesproken, ik heb ooit een forum bezocht waar ik het adres van m’n persoonlijke website kon invoeren bij het plaatsen van een comment. Het adres is mijn volledige naam met een punt tegen het einde: gustvandew.al. Voor de rest van het internet is deze “domeinhack” niets meer dan een Albanese website. En toch, na het proberen te versturen van m’n comment, liet een kleine rode waarschuwing me weten dat het “geen geldige URL” was. Ik probeerde het nog eens door een combinatie van onze goede oude https:// en www. erin te mixen, maar het mocht niet baten.

Mogelijkheden om te controleren of een adres een geldig adres is, zijn in de vorm van libraries beschikbaar in alle back-end-talen. Ze kunnen allemaal controleren op het bestaan ​​van een adres door het adres daadwerkelijk te pingen om te zien of het een antwoord krijgt, dus er blijft geen enkel excuus over voor de website om willekeurige landen hun TLD’s niet te ondersteunen. Helaas had het forum dat ik bezocht een aftakelende library gekozen of geprobeerd het wiel opnieuw uit te vinden, wat mislukte.

Voor een developer om hun eigen implementatie te maken van iets dat in talloze uitvoeringen voor ze is geprogrammeerd, moet er een tastbaar voordeel zijn. Als dat er is, zal de developer lang en goed moeten nadenken over alle situaties waarin hun gebruikers zich kunnen bevinden en hoe ze dingen toekomstbestendig kunnen maken.

Dat gezegd hebbende: je zou eindeloos veel randgevallen kunnen bedenken en testen, maar als manier om er de kwaliteit van de back-end code mee uit te vinden, zou ik het niet bepaald efficiënt noemen. Toch zijn er altijd wel wat dingen die de back-end regelt die aan het oppervlak te zien zijn. Op websites die door hetzelfde bureau gemaakt zijn kun je als bezoeker dus testjes uitvoeren.

Controleer op websites gemaakt door hetzelfde bureau:

Zijn de responstijden en laadtijden draaglijk?

Talloze onderzoeken (sommigen door giga’s zoals Google, Amazon en Walmart) hebben aangetoond dat de ervaren snelheid van je website van cruciaal belang is voor conversie en gebruikerservaring. Statistieken over de kwestie veranderen voortdurend naarmate het web en de verwachtingen van gebruikers evolueren, dus ik heb een afbeelding gemaakt waarvan ik vond dat het goed samenvatte waar elke studie over de kwestie het afzonderlijk van elkaar over eens is:

Total loading time 0s 2s 5s 10s Happy Leaving Screaming out of frustration Visitor status

Ondanks het belang ervan, zou het je misschien verbazen dat een analyse van 5M+ webpagina’s door Backlinko heeft vastgesteld dat de responstijden gemiddeld 1,3 seconden zijn op desktop en 2,6 seconden op mobiel en dat de laadtijden gemiddeld 10,3 seconden zijn op desktop en 27,3 seconden op mobiel.

Je zou kunnen concluderen dat de responstijden onbetekenend zijn in vergelijking met zulke laadtijden, maar niets is minder waar. Hoe langer de responstijd, des te meer je gebruikers zich in de wacht gezet zullen voelen bij de minste interactie — op een website, met de internetsnelheid die we tegenwoordig hebben.

Als het je echter lukt om je pagina bruikbaar te houden terwijl bestanden in de achtergrond worden ingeladen, is er vanaf dat moment vrijwel geen probleem. Door ervoor te zorgen dat bestanden correct in de cache worden opgeslagen, worden de laadtijden verkort na de eerste keer dat de pagina wordt bezocht.

Zijn er op maat gemaakte foutmeldingpagina’s?

Vraag een pagina aan die niet bestaat door het padnaam (het stuk na de slash) te wijzigen naar onzin.

Krijg je op maat gemaakte 404-pagina’s? Perfect! (dit is echter normaal)
Krijg je blanke pagina’s, standaard foutmeldingen of programmeergebrabbel te zien? Rode vlag!

Kun je formulieren breken?

Het hangt allemaal af van wat je als een “gebroken formulier” beschouwt, maar hier zijn enkele suggesties:

  • Kunnen tekstvelden die louter letters zouden moeten toelaten (zoals een naamveld), ook cijfers of andere dingen bevatten die duidelijk niet geldig zouden moeten zijn, zoals emoji?
  • Kun je wegkomen met het invullen van slechts 1 letter in verplichte velden?
  • Als je een formulier verstuurt en het mislukt, zijn de velden die je had ingevuld dan nog steeds ingevuld?
    Ook foutief ingevulde velden moeten hetzelfde blijven. Als gebruiker wil je over het algemeen zien welke waarden je hebt ingevoerd die de check niet hebben doorstaan, zodat je mogelijk fouten kunt spotten en corrigeren.

Hoe nuttig zijn de padnamen?

Het aantal tekens dat in een URL kan worden gebruikt, is zeer beperkt. De meeste onbruikbare tekens kunnen echter nog steeds worden gerepresenteerd, maar enkel door ze te coderen (een spatie wordt bijvoorbeeld %20). Zoals je je kunt voorstellen, maakt het gebruik van dergelijke tekens in je padnaam (het deel achter de domeinnaam) ze snel onleesbaar. Daarom is er maar één situatie waarbij het gebruik van zulke gecodeerde tekens zou moeten plaastvinden: wanneer de padnaam tekst bevat die 1 op 1 moet worden gekopieerd om de website te laten functioneren. Een voorbeeld is de padnamen die je krijgt als je een Google-zoekopdracht uitvoert. Zoeken naar “katten en honden” resulteert in een padnaam met de “query” ?q=katten%20en%20honden. Google kan dit stuk van de URL niet “mooier maken” naar ?q=katten-en-honden, want dan zou je zoeken naar “katten-en-honden”.
Statische pagina’s zoals die met algemene voorwaarden kunnen daarentegen vriendelijke adressen zijn, zoals /algemene-voorwaarden.

Wanneer een gebruiker producten filtert, moet de padnaam dit ook weerspiegelen. En nee, /schoenen?maat=2,3&kleur=8 is niet leesbaar genoeg, noch ziet het er toekomstbestendig uit. De maat-waarden komen niet overeen met werkelijke schoenmaten, de kleur-waarde is geen echte kleur en het vergroten of verkleinen van het aantal opties voor een van de twee filters wordt snel problematisch.

Wees voorzichtig wanneer:

Het bureau voorstelt van hun zelfgemaakte CMS gebruik te maken

Een CMS van de grond af aan opbouwen is een enorme taak. Het onderhouden ervan is een constante taak. Als er niet ten minste één zeer ervaren developer aan het CMS werkt, zou ik het voor geen goud vertrouwen. Alleen ervaren developers kunnen anticiperen welke obstakels te verwachten zijn, hoe ze er omheen kunnen werken en hoe ze alles stabiel en veilig kunnen maken. Een CMS geeft je alle controle die je nodig hebt, wat betekent dat het een hacker ook alle controle kan geven die ze nodig hebben; het is niet iets wat je kunt riskeren fout te laten gaan. En dan hebben we het nog niet eens gehad over het feit dat je waarschijnlijk snel wilt dat bugs opgelost worden.

Het hebben van een kwetsbare infrastructuur rond je CMS is niet bepaald verstandig. Developers die cruciaal zijn om de kwaliteit van het CMS te behouden, zullen er toch op een gegeven moment mee stoppen. Dat is een gegeven. De vraag is “wanneer?”

  • Het bureau kan developers ontslaan die het onderhouden.
  • Deze developers kunnen zelf naar een ander bureau vertrekken, ook al was het het bureau’s intentie ze te behouden.
  • Het bureau kan het CMS helemaal laten vallen.
  • Het bureau kan liquideren.

Vanaf dat moment is het een kwestie van tijd totdat de bugs beginnen binnen te stromen.

Open-source CMS’en zoals WordPress worden verzorgd door een leger van nerds die niets anders willen dan constante verbetering. Ze repareren bugs voor je, net zoals een bureau dat zou doen. Als je een functie voorstelt die meer implementeerders van het CMS ten goede zou komen, voegen ze die toe, net als een bureau, maar zonder de kosten. Open-source CMS’en passen ook snel nieuwe standaarden toe, terwijl het gemiddelde huisgemaakte CMS langzaamaan steeds meer in de versukkeling raakt.

Maak altijd afspraken over:

Veilig verkeer

Op websites moet altijd een SSL-certificaat zijn geïnstalleerd, zodat je verkeer veilig (HTTPS) is. Gelukkig wordt dit langzaamaan algemene kennis. Wat echter nauwelijks algemene kennis is, is dat het genereren van een SSL-certificaat gratis is en dat het verversen ervan makkelijk kan worden geautomatiseerd. Het moet altijd bij een website worden geleverd, dus laat niemand je er een hoofdprijs voor in rekening brengen, laat staan ​​een periodieke!

De padnamen

Het veranderen van padnamen nadat ze in productie zijn gegaan, is verre van moeilijk. Toch is er nog een reden voor mij om te benadrukken hoe belangrijk het is om dit vanaf het begin goed te doen: URL’s worden van tijd tot tijd gedeeld en gedeelde URL’s hebben de vervelende eigenschappen dat 1. Ze zijn verschrikkelijk in interesse wekken bij mensen wanneer ze lelijk of onleesbaar zijn en 2. Ze veranderen niet mee wanneer je padnamen op je website verandert. Zelfs al doe je een 301 (permanente) redirect naar de nieuwe URL, blijven de gedeelde URL’s hetzelfde.

Performance

“Een resource (bestanden en serverreacties verwacht door onderliggende scripts) duurt nooit meer dan X milliseconden om volledig te downloaden vanaf het moment dat het verzoek is verzonden” is een goed startpunt. Door gewoon een maximum te stellen aan de hoeveelheid tijd die een actie kan nemen, worden de developers ertoe aangezet om efficiënte code te schrijven. Of je nu van plan bent een kleine website te maken waarbij de enige interactie een contactformulier is of een volwaardige web-app die constant interactie heeft met een database, ik zou het maximum specificeren voor elke actie waar gebruikers het voltooien van af moeten wachten. Dit omvat het opvragen, opslaan, genereren en filteren van data, evenals het samenstellen van (sub-)pagina’s. Voor downloads van grote bestanden richt je je natuurlijk meer op hun gemiddelde downloadsnelheid dan bijvoorbeeld de responstijd.

Een technisch onderlegd persoon zal op de juiste cijfers voor jouw project moeten komen.

Het is echter niet alleen de taak van de back-end om je website snel te laten werken. De front-end speelt hierin ook een belangrijke rol, dus laten we daar op ingaan!

Front-end

De front-end technologieën HTML en CSS (en de DOM) evolueren samen met een almaar groeiend aantal mensen en apparaten, terwijl aan de scripttaal JavaScript langzaam wordt gewerkt om de ervaring van het schrijven van JavaScript te verbeteren. Het is een taal die bekend staat om zijn eigenaardigheden en uitzonderingen, en toch is het de meest gebruikte programmeertaal ter wereld dankzij de ietwat zachte leercurve (al helemaal als je het begint te leren met behulp van libraries / frameworks) en de hedendaagse alomtegenwoordigheid van het web (wat de vraag naar developers vergroot en de gemeenschap levendiger maken). Deze twee elementen hebben er in het laatste decennium voor gezorgd dat er een enorm levendige community achter de taal zit.

Het is gemakkelijk om uit te breiden op reeds bestaande implementaties, wat betekent dat er elke dag nieuwe JavaScript-frameworks worden geboren. Dit betekent ook dat de gemiddelde front-end skillset steeds meer gefragmenteerd raakt. De manier waarop we JavaScript transformeren en compileren verandert voortdurend, eens bruikbare libraries worden vervangen door in de browser gebakken API’s en het de facto framework van morgen is gisteren al vervangen.

Al met al blijkt het schrijven van JavaScript dat de tand des tijds overleeft moeilijk te zijn. Dit is jammer, omdat er goede redenen zijn om aan te nemen dat, binnen de context van codekwaliteit, de rol van de front-end developer het meest cruciaal is:

  • De front-end-code is wat er naar gebruikers wordt verzonden. Hun perceptie van je bedrijf is het belangrijkste.
  • De front-end-code is wat zoekmachines zoals Google kunnen inspecteren. Ze kunnen niet zien wat er in de back-end gebeurt, en het maakt ze ook niet uit hoe “goed” je website eruit ziet. Ze geven om de prestaties, functionele structuur en, natuurlijk, inhoud van je website.
  • Vanwege het brede scala aan omgevingen waarin front-end code moet worden uitgevoerd, komen sommige soorten fouten alleen in specifieke situaties voor, waardoor ze voor de developer onopgemerkt kunnen blijven. Dit kan ertoe leiden dat een aanzienlijk deel van de gebruikers de website niet correct kan gebruiken.
  • Een slecht presterende back-end kan soms worden verholpen door een goede front-end. Als de respons- en/of laadtijden lang zijn en daar niets aan te doen is, is het de taak van de front-end developer om gebruikers de feedback te geven die ze nodig hebben. Het verschil tussen een pagina die niets lijkt te doen en een pagina met een eenvoudige laadafbeelding is als dag en nacht.

Randgeval

Dit gebeurde tijdens het schrijven van dit artikel. Mijn vriendin heeft toegang tot een web-app waarin ze haar werkschema kan inzien (voor een multinational, ja). Terwijl ze probeerde in te loggen, bleef de app zeggen dat het wachtwoord dat ze had ingevoerd verkeerd was. Nu is het niet zo ongebruikelijk voor een persoon om plotseling een wachtwoord te vergeten — vooral als het een tijd geleden is dat hij/zij het zich voor het laatst heeft moeten herinneren — maar ze logt daar minstens één keer per week in.

Na een paar pogingen te hebben gedaan, merkten we dat ze geen internetverbinding had. “Vreemd. Hoe kan een website mogelijk zien of het wachtwoord correct is zonder verbinding?”
En inderdaad, zodra we de internetverbinding herstelde en probeerden in te loggen, werden we onmiddellijk toegelaten.

Zonder internetverbinding kan de back-end natuurlijk onmogelijk verantwoordelijk zijn voor deze fout, dus het is de front-end waar de fout ligt. Zoals duidelijk is gemaakt, viel deze specifieke interface standaard terug op een “verkeerd wachtwoord”-foutmelding, ook al kunnen en zullen netwerkfouten altijd optreden. We hadden het geluk dat we binnen enkele minuten ontdekten wat er mis was, want deze manier van foutafhandeling kan anderszins enorme frustratie veroorzaken. Als er een obstakel is, ben je als gebruiker afhankelijk van de feedback die een website je geeft. Geen feedback krijgen is al erg genoeg, maar feitelijk onjuiste feedback kan een obstakel onoverkoombaar doen lijken. Op zo’n moment vertrekken de meeste gebruikers liever meteen.

Hoe eenvoudig het ontwerp van je website er ook uitziet, een slechte front-end developer kan je SEO-inspanningen verpesten en de gebruikerservaring te gronde richten. Dat, het feit dat de front-end goed te inspecteren is en het feit dat ik zelf een front-end developer ben, is waarom deze checklist het uitgebreidst is.

Controleer op websites gemaakt door hetzelfde bureau:

Worden phablets ondersteund?

Controleer niet alleen of de website er goed uitziet op je desktop en je mobiele telefoon afzonderlijk. Neem de desktopversie en verklein het browservenster zodat je van elk schermformaat kunt zien hoe de website erop uitziet, vooral tussen telefoon- en tabletformaten. Die formaten zijn de meest onhandige om te ondersteunen en het kost vaak wat extra tijd om te perfectioneren. Meestal is de vensterbreedte waar de lay-out moet wisselen van twee kolommen naar één kolom de lelijkste. De kans is groot dat er tablets zijn die deze versie van het ontwerp altijd zien.

Is het logo een vectorafbeelding?

rasterized image of Q

De lay-out en tekst op een website worden in wezen weergegeven door sets coördinaten te volgen en pixels te vullen aan de hand van de vormen die deze coördinaten construeren.

Dit betekent dat ze, in tegenstelling tot rasterafbeeldingen, oneindig kunnen worden opgeschaald zonder kwaliteitsverlies.

Elke op maat gemaakte visual op een website dat geen momentopname is (foto’s, screenshots, enz.), kan waarschijnlijk een vectorafbeelding zijn. Logo’s zijn een veel voorkomend voorbeeld hiervan. Logo’s zijn tegenwoordig overweldigend plat, bestaande uit simpele geometrische vormen. Als het logo aan die eisen voldoet, maar geen vectorafbeelding is, zou ik een heel goede uitleg waarom verwachten.

Hoeveel lettertypen worden er gedownload?

Elke discipline in elke hoek van het internet is het daarmee eens: een website moet proberen het aantal lettertypefamilies zo dicht mogelijk bij 1 te houden, bij voorkeur niet hoger dan 2! Per lettertypefamilie zijn er variaties zoals vet, cursief en vet cursief, allemaal volledige lettertypen die afzonderlijk moeten worden gedownload. Hier is hun grootte verwaarloosbaar; een enkele afbeelding van lage kwaliteit kan gemakkelijk meer bytes zijn dan alle lettertypen samen. Het zijn de afzonderlijke verzoeken en downloadtijd die tellen, evenals de harmonie van de pagina (het komt zelden voor dat een goed ontwerp meer dan twee lettertypefamilies gebruikt, maar dat is de verantwoordelijkheid van de ontwerper, niet de front-end developer).

Alle andere lettertypen moeten worden gebruikt voor speciale gevallen, zoals monospace voor code of “icon fonts” voor, nou ja, iconen (vanwege hun monochromatische aard en de oneindige vector-gedreven schaalbaarheid van tekst zijn iconen tegenwoordig vaak letters uit een lettertypefamilie).

Zijn alle favicons er?

Met deze Favicon-checker kun je zien welke versies van het logo de developers voor verschillende applicaties hebben geleverd. Als alles goed is geconfigureerd, zien de favicons er consistent uitzien.

Zijn er placeholders voor dingen die nog gedownload moeten worden?

Dit is echt een van mijn pet peeves. Er is niets zo vervelend als proberen ergens op te klikken wanneer- WHOOPS! De hele pagina verspringt omdat een afbeelding klaar is met downloaden en je klikt op het verkeerde.

Kun je de website met je toetsenbord navigeren?

De statistieken zijn ook hier wazig. Conservatieve statistieken tonen aan dat minstens 8,5 procent van de bevolking een handicap heeft die het internetgebruik beïnvloedt, van wie de helft een visuele beperking heeft. Onder hen is natuurlijk een significante hoeveelheid mensen dat hun gezichtsvermogen herstellen met fysieke hulpmiddelen of die vanwege hun beperking zelden toegang tot het internet zoeken. Wat je overhoudt, is een goede 1 procent gebruikers voor wie het toetsenbord voor navigatie absoluut noodzakelijk is. Voor de rest is het de voorkeur, al is het maar af en toe.

Zijn lettertypegroottes relatief?

Wellicht weet je niet dat het mogelijk is, maar je kunt de lettertypegrootte van je browser wijzigen in de instellingen. Mensen met verminderde gezichtsscherpte kunnen besluiten de lettergrootte te vergroten, zodat ze de tekst op je website beter kunnen lezen.

Als je zelf de standaard lettergrootte vergroot, groeit alle tekst dan op een logische manier respectievelijk? Zo ja, verbreekt het de lay-out van de pagina? Sommige dingen kunnen zeker kapot gaan, maar je zou de lettergrootte met 50% moeten kunnen vergroten zonder delen van de website onherkenbaar te maken.

Wees voorzichtig wanneer:

Een front-end developer zegt dat iets onmogelijk is.

Ik kan me geen enkel geval herinneren waarin een front-end developer correct beweerde dat een taak onmogelijk was. Begrijp me niet verkeerd, genoeg dingen zijn praktisch onmogelijk, maar ze zijn veel zeldzamer dan je zou denken. Met dat in gedachten, overweeg ze een uitleg te vragen waarom de taak onmogelijk is. Als ze moeite hebben om een ​​manier te vinden om het probleem te beschrijven of als ze de taak snel wegschuiven als “simpelweg te ingewikkeld”, bestaat de kans dat de developer niet eens weet wat ze niet weten / meer over zouden moeten weten.

Maak altijd afspraken over:

Universele ondersteuning.

Elk deel van je website moet voor iedereen toegankelijk zijn, op elke locatie en op elk apparaat.

Zoals ik al zei, moet toetsenbordnavigatie mogelijk zijn, dus invoerelementen moeten focusringen (of een andere voor de hand liggende indicator) hebben wanneer je ze focust met de Tab. Überhaupt dat de focusringen er zijn, is niet het enige dat van belang is, maar ook het contrast tussen de focusring en de achtergrond! Kleurenblinde mensen gebruiken ook vaak het toetsenbord omdat het moeilijk te zien is welke elementen klikbaar zijn wanneer contrast, niet kleur, de enige betrouwbare factor is. Er zijn ook tal van tijdelijke redenen voor mensen om het toetsenbord te gebruiken: kapotte touchpad, lege muisbatterij, gebroken arm, oogletsel, verloren bril.

Bovendien hebben mobiele apparaten meestal ook geen muis, dus geen enkele essentiële functionaliteit kan afhankelijk zijn van alleen-muisgebeurtenissen, zoals een actie die afvuurt bij rechter muisknop.

Zoals uitgelegd in mijn laatste blogpost, nemen de meeste wijzigingen die je moet aanbrengen om basis-, maar essentiële, ondersteuning voor slechtzienden toe te voegen, slechts een paar minuten van je tijd in beslag. Maar naast het feit dat het een inherent goede zaak is om mensen met een handicap te ondersteunen, is er een extra reden om dit te doen die je misschien niet had overwogen:

Als geen van de websites van je rivalen ze ondersteunt, maar jij wel, kun je vrijwel alle conversies voor jezelf houden, wat betekent dat de eerder genoemde 1 procent aanzienlijk kan oplopen. Als je concurrent 10 keer zoveel verkeer heeft als jij, maar geen van hun gebruikers met een visuele beperking daar uiteindelijk koopt vanwege hun problematische navigatie, dan zou dat betekenen dat je — in een ideale wereld waar elke dergelijke gebruiker op hun beurt naar jouw website gaat — geen verhoging van 1 procent krijgt, maar een verhoging van 10 procent.

“Als geen van de websites van je rivalen [mensen met een handicap] ondersteunt, maar jij wel, kun je vrijwel alle conversies voor jezelf houden”

Performance

Net als bij de back-end, kun je kei harde getallen betrekken bij de front-end performance. Er zijn er twee waar ik in het bijzonder aandacht aan zou geven:

  1. “De FMP (First Meaningful Paint) vindt plaats binnen X milliseconds.”
    Het is de beste basis die ik kan bedenken, aangezien deze vereiste heel handig uitkomt als je je bedenkt dat gebruikers binnen seconden weer weg zijn.
  2. “Op geen enkel moment gaat de FPS (frames per second) onder X.”
    Niemand houdt van een stotterende webpagina. Een developer kan misschien prachtige, complexe parallax-effecten creëren die naadloos worden afgespeeld op hun hoogstaande computer-setup, maar als hetzelfde script de ​​gemiddelde mobiele telefoon terugbrengt naar een slakkenpas, is er iets mis. Daarom moet je vragen om een ​​overzicht van “dynamische momenten”, waarbij er wijzigingen worden aangebracht aan de pagina of animaties worden afgespeeld, en ze doornemen op tragere apparaten.

Van MDN:

“Users expect all interface interactions to be smooth and all user interfaces to be responsive. Animation can help make a site feel faster and responsive, but animations can also make a site feel slower and janky if not done correctly. Responsive user interfaces have a frame rate of 60 frames per second (fps). While it is not always possible to maintain 60fps, it is important to maintain a high and steady frame rate for all animations.”

Content

Of de cont-end, zoals ik het graag noem.

Content is niet geprogrammeerd, maar wordt door de eigenaar aangeleverd via een CMS. Om deze reden lijkt content niet bepaald iets dat een hoge of lage kwaliteit heeft, qua code. Het zijn tenslotte alleen je teksten / afbeeldingen / video’s, niets van “lage kwaliteit”, toch? Een misleidende veronderstelling.

Je content ondergaat veel transformaties voordat het door je gebruikers wordt gezien. Ten eerste moet een visuele interface (het CMS) je content nemen en interpreteren. Voor mediabestanden zoals afbeeldingen is dit proces vrij eenvoudig. Voor tekst zijn er echter tal van implementaties.

Ten tweede moeten de gegevens naar de back-end worden gestuurd en in de database worden opgeslagen, zodat ze later weer kunnen worden opgehaald.

Ten slotte, wanneer een gebruiker een resource aanvraagt, moeten de relevante gegevens uit de database worden gelezen en teruggestuurd naar de front-end om te worden weergegeven in wéér een andere visuele interface (de website).

Al deze stappen zorgen ervoor dat je content wijzigingen ondergaat, zij het door opnieuw te formatteren of door te coderen / decoderen. Het is zo gemakkelijk om het te verknallen dat de meest voorkomende fout (de ampersand, &, weergegeven als &amp) door de jaren heen een aantal vragen op Reddit heeft gegenereerd van mensen die zich afvragen waarom ze het op verschillende plekken op het internet blijven zien. Sommige grote namen doen het nog steeds op sommige plekken fout, zoals SoundCloud:

Zoek je op een artiest met een ampersand in de naam, dan krijg je normale resultaten:

Een SoundCloud pagina als zoekresultaat met een ampersand in de titel

Zoek je daarentegen naar een specifiek item uit een discografie, dan krijg je dit:

Een SoundCloud pagina als zoekresultaat met een verkeerd weergegeven ampersand in de titel

Semantiek

Het grootste probleem met de verschillende stappen die je content neemt voordat deze je gebruikers bereikt, ligt echter niet in dit soort bugs, maar in iets heel anders: semantiek, het ding waar onze grote vrienden in de cloud en hun webcrawlers waarde aan hechten. De back-end developers, front-end developers en jij moeten het eens zijn over hoe je de content van je website maakt en bewerkt. Dit kan in wezen slechts op één manier worden gedaan: door jou intuïtieve tools te bieden waarmee het moeilijk is (of onmogelijk, als dat je voorkeur is) om fouten te maken. Meestal betekent dit dat er minimale verantwoordelijkheid aan jou wordt overgedragen en dat je via een eenvoudige maar volledige interface gestuurd wordt.

De trieste realiteit is dat het vinden van een balans tussen deze kwaliteiten erg moeilijk is. Er zijn veel technische details waarover we je liever niet expliciet hoeven te vertellen, maar we moeten er ook voor zorgen dat deze technische details worden nageleefd. Daarom worden alles-in-een-oplossingen zoals rich text-editors (RTE’s) over het algemeen gezien als de beste methode om content te verwerken.

Ze zijn gemakkelijk te gebruiken en zitten boordevol functies, en dat is precies waar het misgaat. Je kunt elke teksteigenschap met een paar klikken wijzigen. Als je wilt, kun je mediabestanden in het midden van een zin plaatsen. Je kunt tabellen creëren en in sommige editors kun je tabellen zelfs vanuit je klembord plakken. De meeste hebben ingebouwde image-editors en ik denk niet dat het lang zal duren voordat het voorzien van een video-editor ook de norm wordt. Al deze mogelijkheden maken het beheren van content zo eenvoudig dat ze je kunnen doen vergeten om de rol van een stuk content expliciet te vermelden, terwijl dit essentieel is voor je SEO-ranking en toegankelijkheid. Het op deze manier gebruiken van RTE’s is analoog aan het toegereikt krijgen van een grote set penselen en verven, waardoor je elke gewenste look kunt creëren die je maar wilt, alleen om erachter te komen dat je binnen de lijnen moet kleuren.

Een hint van wat ik bedoel, is te vinden in dagelijkse documenteditors wiens look en feel door RTE’s worden nagebootst, zoals Microsoft Word. Hoewel het verstrekken van meta-informatie voor Word-documenten zinloos is als je ze enkel gaat afdrukken, is dit nog steeds een prominent onderdeel van het programma. De redenen zijn voornamelijk dezelfde als voor het web. Hieronder is een video van 2 minuten uit de kennisbank van Microsoft waarin ze worden uiteengezet (geloof me, je wilt deze tot het einde zien).

Zoals je kunt zien, voegt de juiste semantiek structuur toe en draagt het ​​informatie met zich mee waar andere programma’s gebruik van kunnen maken. Schermlezers kunnen het documentoverzicht lezen, zonder dat je er expliciet een hoeft te genereren. Toetsenbordgebruikers kunnen naar een volgende sectie gaan door telkens naar de eerstvolgende koptekst te gaan. Webcrawlers kunnen informatie beter extraheren en prioriteren tijdens het indexeren van je website.

Het huidige RTE-landschap bestaat voornamelijk uit editors die het product zijn van verschillende ideeën en technologieën die langzaam tot één product culmineren; sommigen blinken echt uit in bepaalde taken, maar geen enkele is helemaal perfect. Het kwaliteitsverschil tussen betaalde RTE’s en gratis RTE’s wordt langzaam kleiner, maar is mogelijk cruciaal. Al deze kenmerken en variaties maken het moeilijk om het bos door de bomen te zien, maar ze komen neer op één advies:

Wanneer je een bureau of developer beoordeelt die aan een CMS of een RTE gaat werken, vraag hen dan hoe de gebruikers de juiste semantische elementen voor hun content kunnen creëren.

Zoals gezegd zijn er tal van implementaties voor het beheren van content, vooral voor tekst. Sterker nog, er zijn niet eens officiële standaarden als het hierom gaat — niet in HTML, noch in JavaScript — dus wees niet te streng voor de developer. Door naar deze dingen te vragen, kun je een indruk scheppen of de developer zich überhaupt zorgen maakt over dit soort dingen en of ze zich inzetten om het beste product te produceren dat ze kunnen.

Hieronder staat een lijst met contentelementen, waarvan de meeste een semantisch doel hebben. Misschien doe je er goed aan het ergens op te slaan (door dit artikel natuurlijk als bladwijzer toe te voegen), zodat je er altijd naar terug kunt keren om de punten opnieuw door te nemen voor het volgende project. Als alles goed gaat, hoef je je nooit te beseffen dat je iets mist zodra de ontwikkeling al achter de rug is.

Koppen

In plaats van de lettergrootte en -dikte te vergroten, moet er een optie zijn om koptekst van broodtekst te onderscheiden. Dit kan worden gedaan door jou afzonderlijke gebieden voor de koppen en broodtekst te geven, waardoor onderscheid wordt gecreëerd door de interface. De RTE kan ook worden voorzien van een speciale kopknop. Hoe dan ook, je zou 6 koptekstgroottes moeten kunnen maken. HTML biedt 6 koptekst niveau’s.

Bijna alle RTE’s worden met deze functie geleverd.

Lijsten

In plaats van een minteken of een getal aan het begin van elk lijstpunt te schrijven en het erbij te laten, zijn er ook toegewezen lijstelementen. Er zijn 3 verschillende mogelijkheden tot het creëren van lijsten:

  1. De algemene, ongeorderde lijst (“unordered list” (<ul>))
  2. De genummerde lijst (“ordered list” (<ol>))
    Bij dit type lijst moet je ook aan kunnen geven of hij op- of af- moet tellen en vanaf welk getal. Die dingen zijn allemaal deel van de standaard.
  3. De omschrijvingslijst (“description list” (<dl>))
    Deze (veel obscuurdere) omschrijvingslijst bestaat uit term-beschrijving-sets.

Tabellen

Ik herinner je er maar even aan dat ze bestaan. Als je ooit tabelgegevens wilt presenteren zoals je zou doen in Microsoft Excel, dan heb je tabellen nodig.

Citaten

Naast de quote zelf en de persoon die je citeert, moet je bij elke quote ook de naam van het geciteerde materiaal en een URL naar dat materiaal kunnen specificeren. Op die manier kan een zoekmachine je quote valideren.

Afkortingen

Ik heb in dit artikel veel gebruik gemaakt van de <abbr> tag. Iedereen zou deze moeten gebruiken!

Meer obscure tekststijlen

Misschien is het markeren van tekst jouw ding.

Verwijderde tekst is ook iets dat je misschien wilt kunnen aanmaken.

Dan zijn er nog subscript en superscript. Hoewel ze meestal worden gebruikt voor formules, zijn er genoeg redenen om ondersteuning voor hen te vragen, vooral superscript. Met superscript kun je zaken typen als 2e, 22 and praktaliteit™.

Inline tekst met meerdere kolommen

Ik heb mensen kolommen in hun tekst zien maken door enorm veel witruimte toe te voegen tussen stukjes tekst. Ook heb ik de opeenvolgende nachten geen oog dichtgedaan.

Grappen terzijde, ik heb dit meerdere keren zien gebeuren. Er is zoveel mis met het op die manier maken van kolommen dat ik het niet eens ga uitleggen; als je de laatste paar duizend woorden op hebt gelet, weet je wel waarom. Als je wilt dat een stuk tekst wordt opgesplitst in 2 of 3 kolommen, vraag de developers daar dan een optie voor toe te voegen.

Ik heb het niet over de mogelijkheid om handmatig kolommen te maken, maar over de mogelijkheid om te beslissen over hoeveel kolommen de browser je tekst moet verdelen (standaard is dit 1). Wanneer je tekst toevoegt / verwijdert, blijven alle kolommen automatisch op dezelfde hoogte.

Oh, en als je denkt dat je nooit ondersteuning voor meerdere inline kolommen nodig hebt, bedenk dan hoe een boodschappenlijstje er zonder uit zou zien op je website.

Netheid

Tekst

Inline tekststijlen

Dit zou geen ding moeten zijn.

Natuurlijk moet je je tekst gekleurd, vet, cursief of monospace kunnen maken. Maar — zoals eerder besproken — hoe deze varianten van je lettertype eruit zien, zijn ontwerpbeslissingen. Je website hoort er waarschijnlijk niet uit te zien als een lagere school knutselwerkje, dus eigenschappen zoals lettertypefamilie, lettergrootte, woordafstand en regelafstand mogen helemaal niet inline worden gewijzigd.

Link stijlen

Om aan het bovenstaande punt toe te voegen, is er een plaats waar het geen zin heeft om iemand welke stijl dan ook te laten veranderen, en dat zijn hyperlinks. Onze eerste blogpost dook toevallig in op dit onderwerp en het toegankelijkheidsaspect ervan.

Dubbele spaties

Er zijn genoeg redenen om geen spellingcontroles te implementeren, maar er moet in ieder geval worden gecontroleerd op meer “universelere” fouten, zoals dubbele spaties, dubbele komma’s, enz.

Ik heb dubbele spaties gezien op websites van alle kalibers en het lijkt nooit met opzet te zijn geweest. En dat terwijl een simpele zoekopdracht naar dubbele spaties in een tel is gebeurd.

Afbeeldingen

Tekst in afbeeldingen

Een van de dingen die jij zelf moet vermijden, is het toevoegen van afbeeldingen met tekst erin. Ja, er zijn situaties waarin stukjes tekst in afbeeldingsformaat mogen komen, zolang ze geschikte beschrijvingen krijgen in de functionele opmaak van de pagina. Flashy graphics die alleen gemaakt kunnen worden met externe tools zoals Photoshop zijn hier een voorbeeld van. Tekst die alleen voor esthetische doeleinden in afbeeldingen is opgenomen, in plaats van bedoeld te zijn voor schermlezers en webcrawlers, kan worden genegeerd.

Slecht uitgesneden afbeeldingen

Donkere tekst op lichte achtergronden is beter leesbaar dan andersom. Dit geldt zowel voor papier als voor schermen. Als zodanig is een “blank canvas” bijna altijd wit, ook voor beeldbewerkingssoftware. Maar het maken en testen van je afbeeldingen met alleen een witte achtergrond kan ervoor zorgen dat je website in plaats van een verfijnde indruk, een slordige indruk afgeeft. Google verpest dit zelfs, soms:

screenshot van moment dat Google hun doodle niet goed hadden afgestemd op de achtergrond

Denk hier altijd aan wanneer je afbeeldingen maakt of gaat laten maken. Als je denkt dat je zeker weet dat de achtergrond niets anders is dan wit, denk dan nog eens goed na. Geforceerde “dark mode” keert veel kleuren op de pagina om, inclusief de achtergrondkleur, maar niet die in afbeeldingen (natuurlijk).

Maak altijd afspraken over:

Open Graph-gegevens

Bekijk onze blogpost over Open Graph.

Complete faviconset

Zoals ik eerder zei, zou een Favicon-checker een harmonieuze set pictogrammen moeten laten zien. Dit zorgt ervoor dat wanneer mensen jouw website als snelkoppeling op hun apparaat bewaren, deze snelkoppeling visueel identiek is aan een normale app, met jouw branding. Zo past het icoon beter tussen de rest.

Dubbel Check:

Spelling en grammatica

Google bestraft websites niet voor spellings- en grammaticafouten omdat taal veel te divers is om met vertrouwen te zeggen of iets “fout” is. Elke dag worden nieuwe woorden bedacht en mensen spellen woorden soms zelfs expres verkeerd.

“Dus wat is het probleem?” denk je misschien. Het blijkt dat het bouncepercentage voor pagina’s met taalfouten twee keer zo hoog is als voor pagina’s zonder. Je zou bij voorkeur een professional in moeten huren om je content te schrijven. Ga je dat niet doen? Zorg er dan in ieder geval voor dat alles door meerdere mensen wordt gecontroleerd op fouten.

Je wensen & vereisten

Dit is een van die dingen die de kwaliteit van de codebase kunnen verlagen, zelfs als er competente developer aan het werk zijn: klanten die tijdens de ontwikkeling de eisen veranderen. Dit is niet zó erg, als het met mate gebeurt. Ik ben echter in sommige situaties geweest waarin klanten hebben gevraagd om praktisch alles te veranderen terwijl ze al hadden ingestemd met wat er werd ontwikkeld. Dingen kunnen akelig worden, niet alleen omdat je moet betalen voor de extra tijd die wordt besteed aan het doorvoeren van de wijzigingen, maar ook omdat het bureau de tijd beschikbaar moet hebben om voor je te werken. Zorg er dus voor dat je wensen en vereisten duidelijk zijn vastgelegd. Een manier om hiervoor te zorgen is een goede communicatie.

Je hebt waarschijnlijk zelf een vrij goed idee van hoe je website eruit zou moeten zien en hoe deze zou moeten functioneren. Maar omdat je geen developer bent, kun je onmogelijk voorzien welke beslissingen vanuit jouw kant moeten worden gemaakt. Dat is waar de developers inspringen. Nadat je hen hebben verteld wat de intenties van je website zijn en welke vereisten je zelf hebt uitgewerkt, zouden ze die met een developersmentaliteit moeten kunnen specificeren en je kunnen vertellen wat er ontbreekt. Dit is een proces dat hand in hand kan gaan met het testen van prototypes, iets dat het ontdekken van alternatieve vereisten een stuk eenvoudiger maakt.

Aan de andere kant is een andere veelgemaakte fout dat klanten vergeten na te denken van welke onderdelen ze eigenlijk verwachten dat herbruikbaar / bewerkbaar zijn. Laten we dit voorbeeld nemen: je gaat tweedehands T-shirts verkopen op je website. Gebruikers gaan hun T-shirts plaatsen, vergezeld van één foto van de voorkant en één van de achterkant. Met dit eenvoudige concept in gedachten, zou een van je vereisten kunnen worden: “Gebruikers moeten 2 afbeeldingen per bericht uploaden”. Het lijkt goed, maar later kom je misschien tot het besef dat je gebruikers ook een afbeelding van het waslabel moeten kunnen toevoegen, dus je moet het maximum verhogen van 2 naar 3.

Maar kun je dat ook? Moet het kunnen worden gewijzigd? Hebben de developers het überhaupt gemakkelijk veranderbaar gemaakt in de codebase? Zo niet, dan staat je een aantal vers berekende kosten te wachten. Niet alleen dat, maar hoe langer je wacht voordat je om de wijziging vraagt, hoe groter de kans dat er complicaties optreden. Dus een betere vereiste zou zijn geweest: “Gebruikers moeten minimaal twee afbeeldingen per bericht uploaden. Het maximum is configureerbaar vanuit het CMS.”

Vuistregel:
Probeer bij het bedenken van eisen geen redenen te bedenken om aspecten te fixeren, maar andersom: probeer redenen te verzinnen om ze open te laten.

Laten we het T-shirt-voorbeeld hierboven nemen. Wanneer je de vereisten opsomt, kun je gemakkelijk naar de limiet van twee afbeeldingen kijken en deze meteen accepteren. “Een T-shirt heeft maar twee kanten. Dat zal niet veranderen”, zou de redenering kunnen zijn. Wanneer je jezelf er daarentegen toe zet om jezelf af te vragen ​​waarom je een aspect op een later moment wél zou willen wijzigen, wordt het veel moeilijker om het aspect te fixeren. Hoewel het vrij simpele tegengestelde denkwijzen zijn, maakt deze manier van denken het makkelijker voor een “wat als?”-gevoel om over te nemen. Je moet bewust zeggen dat er geen enkele reden is of zal zijn dat je het aspect in de toekomst wilt veranderen, wat veel enger is dan het gewoon open te laten.

“Gebruikers willen misschien dat een T-shirt wordt gedragen, close-ups van slijtage, een aparte afbeelding van de branding of een afbeelding van het waslabel,” zijn dingen die toch al vrij snel in je opkomen wanneer je jezelf dwingt redenen te verzinnen om de limiet te veranderen.

Vooral als je een vereiste beoordeelt dat een hoeveelheid bevat (zoals “2 afbeeldingen per bericht”), zou ik je aanraden om er opnieuw over na te denken. Het is zelden schadelijk om dergelijke opties open te laten.

Tot slot

Ik besloot dit artikel te schrijven omdat ik de laatste tijd wat kleinere wijzigingen heb aangebracht aan een website die door een ander bureau is gemaakt. De mensen die bij het betreffende bureau werken, zeggen op hun eigen manier dat ze aan de top staan ​​als het gaat om webdevelopment, wat ze stellig geloven. Echter:

  • Ze hadden een WordPress-thema geïnstalleerd en daarna lieten ze mij het geheel responsive maken (behalve dat ze niet in staat zijn om een ​​responsive website te ontwikkelen, kozen ze niet eens een thema dat dat is. Verbazingwekkend). De CSS die ze hadden geschreven, maakte de website zo wankel dat vrijwel geen van de elementen op de pagina correct was uitgelijnd. Ik moest het allemaal oplossen.
  • Alle koppen waren (en zijn nog steeds) wazige rasterafbeeldingen, nieteens geplaatst in kopelementen (semantiek, weet je nog?).
  • De actie “Alle resultaten bekijken” van hun filter kostte 80 seconden om te reageren, zonder natuurlijk een laadindicator.
  • Ze moesten me vragen om dingen van kleur te veranderen (binnen de eerste 2 minuten van een CSS-cursus weet je hoe je dat moet doen).
  • Om een ​​afbeelding in de rechteronderhoek van een element te plaatsen, creëerden ze een hele nieuwe rij eronder, vulden deze met vier kolommen, lieten de eerste drie leeg en plaatsten de afbeelding in de laatste. Vervolgens hebben ze het visueel naar boven, naar de hoek van het element verplaatst.
    Dit is vergelijkbaar met het inhuren van een helikopterpiloot om constant voor de zon te vliegen, in plaats van gewoon je zonnebril op te zetten.

Laat me hun standpunt over hun expertise herhalen:
Ze beweren niet dat ze “oké” zijn.
Ze beweren niet “goed” te zijn.
Ze beweren niet eens dat ze “erg goed” zijn.
Nee, ze beweren tot de allerbeste te behoren.

Conclusie? Vraag altijd om een ​​second opinion!

In mijn ervaring vertellen goede developers waarom ze de dingen doen die ze doen, niet hoe of hoe goed. Ik heb veel developers ontmoet waarvan ik denk dat ze zich regelmatig een weg banen naar een positie door haastig een aantal cutting-edge technologieën te noemen in de hoop dat de persoon aan de andere kant bijt, in plaats van uit te leggen waarom hun methodologieën de betrokken mensen ten goede komen — jij, je collega’s, je klanten.

Er zijn genoeg pet peeves die ik niet heb besproken, zoals developers die een andere taal dan Engels gebruiken bij het benoemen van dingen in hun code of het inladen van gigantische frameworks voor slechts een van diens functionaliteiten. De eerste is stilistisch en objectief onbelangrijk voor de gebruikerservaring, de laatste is te moeilijk om te bevestigen om hier te bespreken.

Aan de andere kant lijken sommige van de dingen die ik heb besproken misschien een beetje overdreven. Immers, “is het logo een vectorafbeelding?” is waarschijnlijk niet iets waar je eerder wat om gaf, laat staan nu. Nee, de kern van de controles is dat hun gecombineerde resultaten je een redelijk goede indicatie geven van de kwaliteit van het werk dat wordt gedaan. Zoals ik al zei, wilde ik controles opnoemen die aan het oppervlak te vinden zijn, wat de mogelijkheden ernstig beperkt. In ieder geval, als een developer geen van alle checks haalt, zou ik sowieso niet ónder de kap durven kijken.

Voor de developer onder jullie, ik heb een laatste anekdote die ik gewoon niet niet kan vertellen. klik hier om hem te lezen.

In Slack bespraken we het feit dat de leeftijden op onze teampagina niet automatisch updaten, wat betekende dat deze leeftijden iedere keer geüpdatet moesten worden zodra iemand jarig was. Onze server heeft PHP geïnstalleerd, dus het automatiseren ervan is in een minuutje gedaan. Als je ooit PHP hebt gebruikt, weet je dit. Zie:

function getAge ($date) {
  return substr(date('Ymd') - date('Ymd', strtotime($date)), 0, -4);
}

echo getAge('1990-01-01');

Zoals je kunt zien, is het een super simpel probleem om op te lossen. Een full-stack freelancer in hetzelfde kanaal op Slack, daarentegen, had een heel ander idee, waarna ik meteen wist dat hij me de kers op m’n blogpost-taart had gegeven. Zijn voorstel: “Gewoon een headless CMS pakken en React of Vue leren en klaar ben je. PHP is volledig overbodig.”

“Ik denk dat ik een ander idee van ‘overbodig’ heb, dan,” is wat ik antwoordde.

Elke maand nieuwe tips in je mailbox?

Schrijf je in voor onze nieuwsbrief en ontvang 1x per maand nieuwe tips in je mailbox waarmee je jouw website kunt verbeteren.