Reflectie - GiovanniKaaijk/meesterproef-1920 GitHub Wiki

Werkwijze en samenwerking

Omdat wij in een team van 3 aan het project werkten, hebben wij samen bepaalde regels opgesteld om goed samen te kunnen werken. Voor de communicatie gebruiken wij Slack en Discord. Slack voor de chat, Discord voor het bellen. Wij prefereerden Discord boven Slack met bellen omdat je op Discord goed je beeld kon streamen naar de anderen, dit zorgde ervoor dat de samenwerking makkelijker verliep. Ook spraken wij elke dag af om ongeveer 9:30 op Discord, dit zorgde voor een soort vast schema, waardoor je een fijne 'werkflow' had. Het is een aantal keer gebeurd dat iemand niet aanwezig kon zijn bij een meeting, ook bij mij. Dat was geen groot probleem, alles werd goed opgeschreven en na afloop praatte wij elkaar weer bij.

Tijdens het maken van de designs hebben wij gekozen om Figma te gebruiken, Figma is een design tool waar je met meerdere mensen tegelijk in 1 bestand kan werken. Doordat wij op afstand samen werkte, kwam dit goed van pas.

Voor het schrijven van code hebben wij 1 Git repo gebruikt. Ieder werkte aan zijn eigen functionaliteiten, dus wanneer je een nieuwe functie ging bouwen, moest je een nieuwe branche aanmaken. Om ervoor te zorgen dat de master branche altijd representatief was voor onze progressie en dus altijd moest blijven werken, mergede je je branche pas naar de master wanneer je functie volledig werkte. Wanneer er een merge conflict optrad, moest je deze zelf oplossen, zodat de kans zo klein mogelijk was dat andere code kapot ging. Dit is dan ook altijd goed gegaan.

Al met al verliep de samenwerking erg goed.

Het product

Bij het kiezen van het project, kwam Foxfit bij ons 3 goed over, het stond daarom ook op onze eerste keus. Echter bleek na de debriefing dat er weinig technische uitdaging in het project zat, wat wij op dat moment jammer vonden. Op de momenten dat wij nieuwe ideeën met meer uitdaging voorlegde aan de opdrachtgever, kwamen we keer op keer terug bij het eerste plan, dat zou het beste werken. Hierover hebben wij het met de verschillende coaches gehad, wat toch tot interessante inzichten kwam. Uiteindelijk hebben wij ervoor gekozen om het plan van de opdrachtgever aan te houden, dat was immers de eindgebruiker. Wij wilde een zo goed mogelijk product voor hen neerzetten. Uiteindelijk weten wij niet zeker of wat wij hebben neergezet een goed concept is, omdat wij dit niet hebben kunnen testen. Toch verwachten wij dat het erg bruikbaar zal zijn voor de zorgverleners.

Qua code hebben wij ervoor gezorgd om een zo goed bruikbare code neer te zetten voor andere developers, omdat wij alleen het concept neer gingen zetten. Tijdens het maken van de functies, hebben wij naar elkaars code gekeken, zodat alles zoveel mogelijk met elkaar overeen komt. Dit is uiteindelijk erg schaalbaar geworden en makkelijk te gebruiken voor andere developers. Niks is hard coded er in gezet en alles is variabel gemaakt.

Criteria

Hieronder staan alle criteria die wij in dit project gingen gebruiken van de vakken die wij in deze minor hebben volbracht.

WAFS

Criteria

  • De code bevat geen syntaxfouten en is netjes opgemaakt
    • HOE: Linter en uitleg in de readme, zodat we allen dezelfde syntax gebruiken.
    • WAAROM: Zodat de code onderhoudbaar is door meerdere personen en bugs makkelijker te vinden zijn.
  • Code is correct gescoped en opgedeeld in modules die overeen komen met het actor diagram
    • HOE: Van elke herbruikbare functie maken wij een module, hiermee voorkomen wij dubbele code.
    • WAAROM: Hierdoor worden de requests kleiner en zal de pagina sneller opgehaald kunnen worden, daarnaast schrijven wij ook geen dubbele code.
  • JSON data kan met een asynchrone request worden opgehaald uit een API
    • HOE: Via onze eigen gemaakte API, maken wij asynchrone requests om de data op te halen. Daarna kunnen wij die data gebruiken om de grafieken te renderen.
    • WAAROM: Normaal kon dit alleen met een SQL query gedaan worden, maar als je dit op de frontend doet gaat het een stuk slomer. Dit doen wij daarom op de server. Zodat het op de frontend alleen afgehandeld hoeft te worden met een fetch.
  • JSON data kan, al dan niet met een micro library, client side in de HTML worden gerenderd.
    • HOE: Met D3 laden we de data in. Daarna word het ook gerendered met D3.
    • WAAROM: Dit gaat een stuk sneller op de client side dan op server-side.
  • Routing & states kunnen, al dan niet met een micro library, worden gemanaged
    • HOE: Binnen het dashboard gebruiken wij een hashrouter om zo verschillende grafieken te laten zien.
    • WAAROM: Hierdoor hoeft de statische pagina niet steeds geserveerd te worden aan de client. Dit verbruikt minder data.
  • De user flow en object / class flow zijn visueel gemaakt
    • HOE: De user flow is visueel gemaakt in het interaction diagram.
    • WAAROM: Dit geeft een beter overzicht van wat de user doet, of waar de user zich bevindt.
  • De interface bevat feedback naar de gebruiker op het moment dat er gewacht moet worden op het laden van data

CSS to the rescue

Criteria

  • You can show that CSS can be used for more than just styling web pages.
    • HOE: CSS wordt voor meer toegepast in de grafiek voor de kinderen.
    • WAAROM: Dit geeft een betere ervaring voor de kinderen, waardoor zij het ook beter begrijpen.
  • You can show that you can use the cascade, inheritance and specificity in your project
    • HOE: Wij gaan een standaard stylesheet gebruiken voor alle paginas, maar ook aparte stylesheets voor specifiekere projecten.
    • WAAROM: De code is hierdoor beter onderhoudbaar en bespaart veel tijd door minder code te schrijven
  • Is interactivity enhanced within the given CSS scope?
    • HOE: Bij de grafieken voor de kinderen is het interactief.
    • WAAROM: Kinderen zullen doordat het interactief is de applicatie meer gaan exploreren, waardoor ze meer te weten komen over de data.

Browser-technologies

Criteria

  • Student kan de core functionaliteit van een use case doorgronden
    • HOE: De core functionaliteit kunnen wij doorgronden, deze staat verder toegelicht in de debriefing.
    • WAAROM: Hierdoor zullen wij de core functionaliteit echt gaan uitwerken voor de opdrachtgever.
  • Toegankelijkheid: De user experience is goed
  • Readme: In de beschrijving van het project staat een probleemdefinitie, hoe het probleem is opgelost en een uitleg van de code.
    • HOE: Het probleem is verder uitgelicht in de debriefing, en daar staat ook in hoe wij dit gaan oplossen.
    • WAAROM: Doordat we het probleem toelichten, is het makkelijker om het probleem ook op te lossen, hier zijn we meer gefocust op.

Web-design

Criteria

  • Student laat zien hoe de Exclusive Design Principles zijn toegepast in het ontwerp.
    • HOE: Het dashboard dat is gebouwd specifiek voor de zorgverleners maken, zodat hun het snappen en de grafiek voor kinderen zo speels mogelijk maken, zodat we inspelen op de kinderen.
    • WAAROM: Dit is zodat de zorgverleners het dashboard makkelijk kunnen gebruiken en het aan de kinderen kan laten zien.
  • Readme: In de beschrijving van het project staat de opdracht uitgelegd, is het probleem duidelijk beschreven en hoe het probleem is opgelost.
  • Er is een user scenario geschreven dat aansluit bij de identiteit van de test persoon.
    • HOE: Wij zullen een user scenario schrijven van zowel het kind als de zorgverlener.
    • WAAROM: Dit is om een beter beeld van het doel te krijgen.
  • De student kan testresultaten toepassen om een ontwerp te verbeteren.
    • HOE: We hebben het zo ver het ging met Annette getest en besproken. Nu het lastig is om met de gespecialiseerde zorgverleners te testen is dit the next best thing. Zij heeft wel veel contact gehad met de zorgverleners en is goed op de hoogte van wat zij graag willen en hoe zij het product gaan gebruiken.