Voor het Dura Vermeer project heb ik in eerste instantie veel moeten uitzoeken. Vooral omdat dit mijn eerste project was waar ik aan mee ging werken en ik nog geen idee had wat voor standaarden ze hier gebruikten en hoe het nieuwe CMS werkte. De eerste dagen ben ik vooral bezig geweest met rondklikken, vragen stellen en notities maken, zodat ik een basis had om op door te bouwen. Het CMS wat we gingen gebruiken heet Umbraco. Het is een redelijk uitgebreid, maar vooral gebruiksvriendelijk CMS. Aangezien de mensen van Dura Vermeer met het CMS moet gaan werken wilden we alles zo netjes en compleet mogelijk opleveren. Het is mogelijk om omschrijvingen toe te voegen bij alle invoervelden in het CMS. Dit had ik allemaal netjes gedaan in het Nederlands, maar toen kwam het punt van meertaligheid in het CMS ter sprake. Het is dus mogelijk om de taal van het CMS per gebruiker in te stellen, wat bijvoorbeeld handig is voor mensen die de Nederlandse taal niet beheersen. Het CMS vertaald dan alle invoerveld kopjes/titels, maar de beschrijvingen blijven Nederlands. Ik bracht toen naar voren of het niet mogelijk was die beschrijvingen ook te vertalen. Niemand wist of dat überhaupt mogelijk was, dus ben ik wat onderzoek gaan doen naar de mogelijkheden. Ook op internet waren er geen duidelijke antwoorden te vinden of het mogelijk was dit te doen. Uiteindelijk kreeg ik vanuit DotControl groen licht om contact op te nemen met Umbraco Support. Daar heb ik dezelfde vraag gesteld of het mogelijk was om vertalingen toe te voegen bij omschrijvingen van velden in het CMS. Tot mijn verbazing kreeg ik daar het antwoord op dat het nog niet mogelijk was en de vraag of ik dat eventueel zelf wilde ontwikkelen voor het CMS. Helaas was daar geen tijd en budget voor binnen dit project, maar ik heb in ieder geval alles geprobeerd om deze extra functie toe te voegen.

Tijdens het bouwen van verschillende blokken moesten we een image-picker toevoegen. Hiermee kan je in het CMS een foto kiezen uit je media-bibliotheek. Iets wat belangrijk is voor foto’s op je website is een zogeheten alt-tekst. Een alt-tekst zorgt ervoor dat er woorden komen te staan als de foto niet getoond kan worden. Als je geen alt-teksten toevoegt aan je foto’s kan dat impact hebben op je SEO-score. Het is dus beter als je ze toevoegt, dan heb je er alleen maar profijt van. Ditzelfde zei ik ook tegen mijn team op het moment dat we bezig waren met het opzetten van de Blocks. Er is toen besloten om het toe te voegen wanneer een gebruiker een foto toevoegt aan de mediabibliotheek. De gebruiker kan nu de foto uploaden en direct een alt-tekst invoeren. Zo kost het ook niet veel tijd om de alt-teksten toe te voegen, aangezien je dit direct doet per foto als je ze toevoegt in plaats van dat je alles achteraf moet aanpassen.

Een andere kleine functie die ik heb mogen toevoegen was de scroll button in de header van de homepagina en in het aanmeldformulier. De knop bestaat uit een pijl, een cirkel en een tekst. Het idee van onze designer was dat wanneer je er overheen hoverd met de muis, de gehele knop zou verkleinen of vergroten. Ik vond dit niet passen bij de functie achter de knop dus heb ik een ander voorstel gedaan, namelijk een kleine animatie waar de pijl naar beneden beweegt wanneer er overheen gehoverd wordt. Dit is ter indicatie dat er een scrollbeweging zal plaatsvinden op het moment dat er geklikt wordt. Na overleg met onze designer mocht deze mini animatie erin blijven. Dit was een simpele toevoeging, maar het draagt bij aan de gebruiksvriendelijkheid van de website.

Nog een voorbeeld voor een extra stukje visuele ondersteuning is een overlay wat ik gemaakt heb voor de nieuwsberichten in het nieuwsoverzicht. Zodra de gebruiker over een foto of een bericht zonder foto hoverd met de muis, komt er een overlay overheen. Voor foto’s zal dat in de primair gekozen kleur zijn en voor een bericht zonder foto is dat wit. Hierdoor krijg je als gebruiker ook een stukje feedback vanuit de website wat je gaat aanklikken.

Als laatste had ik de opdracht gekregen om een Google Maps Block te bouwen. Dit was niet geheel nieuw voor mij, want dit had ik al eens gedaan. Voor ik zelf iets ging bouwen heb ik eerst gekeken naar alternatieve optie die wellicht beter zouden kunnen functioneren met dit project en waar de klant makkelijker mee zou kunnen werken. Zo had ik een tweetal plugins gevonden die zouden kunnen werken met ons Umbraco project. Helaas werd de beslissing genomen deze niet te gaan gebruiken en alles zelf te maken. Ik mocht dus alsnog aan de slag om het Block zelf te maken, dat vond ik overigens wel een goede opdracht om mijn JavaScript skills te oefenen. Ik heb toen eerst het Block binnen een script tag gebouwd tussen de HTML van het Block zelf. Dat was lokaal een goede oplossing, maar toen dat werkte kreeg ik te horen dat ik hem nu als apart component mocht bouwen en dit keer niet in JavaScript, maar in TypeScript met de bijbehorende dynamische velden uit het CMS. Dit heeft in eerste instantie een hoop tijd en moeite gekost, omdat mijn TypeScript skills niet zo goed waren en er was heel erg weinig documentatie te vinden over Google Maps in Typescript. Na enige tijd heb ik samen met een andere developer toch het Block afgemaakt, maar toen kwam het tweede probleem, namelijk het doorgeven van data uit Umbraco naar RazorScript documenten (C#) en die data vervolgens doorgeven naar TypeScript. Hiervoor heb ik een hoop documentatie doorgenomen van zowel Typescript als C#, maar het was mij niet duidelijk wat ik moest doen. Deze taak is toen overgedragen aan iemand die meer kennis van zaken had en die heeft het dan ook voor ons geregeld. Later in het project kwam er nog eenzelfde situatie voor waar we op dezelfde manier de data moesten doorgeven, dit heb ik toen wel zelf opgelost.

Ik heb ook nog een stukje service verricht dit blok. De klant had feedback gegeven dat het niet helemaal duidelijk was hoe ze het Google Maps Block moesten aanmaken. Om dat te verduidelijken heb ik toen een handleiding gemaakt waarin ik stap voor stap uitleg hoe ze dat moeten doen.

Tijdens dit project was samenwerking zeker nodig. Ik heb gewerkt in een team van 8 mensen bestaande uit de product owner, een scrummaster, de Development Lead van dit team, de designer, een backender, twee andere developers en ik. Ondertussen zijn er mensen weggegaan en bijgekomen. Met dit team hadden we elke dag Stand Up meetings. Tijdens deze Stand Up’s werd alle voortgang van het project besproken en alle eventuele problemen aangekaart. Elke twee weken, wanneer de sprint was afgerond, hadden we ook met dit team een retrospective en een planning meeting. We hebben het hele project door alle deadlines gehaald op een aantal kleine dingetjes na. Uiteindelijk hebben we het project op tijd kunnen opleveren, ondanks de onverwachte toevoegingen en eisen. Ook de samenwerking met een derde partij zorgde voor enige vertraging, maar ook dit hebben we netjes op kunnen lossen.

De communicatie tijdens dit project liep voornamelijk via het communicatie- en samenwerkingsplatform Microsoft Teams. Dit vind ik zelf een erg fijn programma om te gebruiken en het is vanuit DotControl gestructureerd ingericht wat het voor nieuwe mensen makkelijk maakt om mee te starten. Verder stond ons hele project qua code en scrumbord + backlog online via Azure DevOps. Hierdoor was alle data voor het project altijd bereikbaar. Ook de code reviews gingen via Azure DevOps. Alle developers kunnen dan bij de Pull Requests (PR), mits ze zijn toegevoegd aan het project, en op die manier kan iedereen je code reviewen. Wat hiervan de bedoeling is, is dat je niet zomaar je PR kan doorvoeren zonder dat het nogmaals is gecheckt door iemand. De standaard is dan ook dat je PR minimaal door twee mensen moet worden goedgekeurd voor je hem mag mergen met de master branch. Dit was voor mij heel fijn om te weten in de eerste weken, want ik wist nu dat ik niet met één verkeerd PR het hele project kapot kon maken.