roy_home
Deze pagina is voor de productbiografie van het project JungleGym. In deze pagina wordt het proces, iteraties en werkwijze beschreven. Ook schetsen, testen en code voorbeelden worden deel van deze pagina.
- Week 1
- Week 5
Toen de eerste week was begonnen van dit project ben ik de opdracht zo goed mogelijk gaan doorlezen om het daarna te bespreken met mijn team. Wij hadden vanaf het begin van dit project besloten om met ze alle in een groep te gaan werken om op deze manier het beste resultaat te krijgen. In de eerste groeps-meeting hebben wij met elkaar de opdracht doorgenomen en onduidelijkheden opgeschreven die we in het aankomende gesprek met de opdrachtgevers kunnen vragen.
Tijdens onze eerste groeps-meeting hebben wij ook afgesproken dat we het nieuwe framework Svelte Kit willen gaan gebruiken. Zelf heb ik hier echter nog geen ervaring mee en zal ik dus een aantal tutorials moeten volgen om hierin mee te komen. Svelte een eigen tutorial waar ze alle features zo goed mogelijk uitleggen. Naast dit is er een actieve Discord voor Svelte waar je met al je vragen naartoe kan gaan.
Het eerste gesprek met onze opdrachtgever was een kennismakingsgesprek. Dit gesprek vond plaats op maandag 17 mei 2021. Hierin hebben ze ons meer verteld over hun stage in Suriname en hoe ze uiteindelijk op het idee zijn gekomen voor de JungleGym applicatie. Het kwam er op neer dat ze hun stage eerder moesten afronden dan ze eigenlijk hadden gewild door Corona. Het was hun opgemerkt dat de vakdocenten in Suriname soms moeite hadden met het creëren en geven van lessen. De ALO studenten hielpen tijdens deze stage periode met het maken/geven van de gym lessen.
Toen we van beide kanten een intro hadden gegeven zijn we wat dieper in gegaan op de functionaliteiten die hun hadden opgeschreven in de opdracht. Wij hadden voor ons zelf een aantal vragen opgesteld, maar eerst wilde we graag vanuit hun horen hoe hun ideale applicatie eruit zag om op deze manier te kijken wat wij als groep kunnen gaan produceren.
De vragen die wij hadden opgeschreven waren erg algemeen. In de opdracht werd er goed beschreven wat ze wilde hebben en hadden wij dus al een duidelijk beeld van hoe de applicatie eruit moest zien. Des te langer we bezig zijn in dit project komen er vast wel meer vragen naar boven, maar voor nu waren deze vragen het belangrijkst vanuit dit gesprek
- Waar en wanneer wordt de applicatie gebruikt?
Notieties: Internet in de jungle (geen wifi). Het internet is niet goed. Te gebruiken wanneer er geen internet is. Veel buiten gebruiken. Zonder internet moeten zij wel iets hebben. Onvoorspelbaar en onbetrouwbaar internet. Side note: Slow 3G instellingen
- Waar wordt jullie data vandaan gehaald?
Notities: Momenteel een PDF bestand met alle spellen. Alles staat daar in. 12 spellen. Ook willen zij de mogelijkheid om dit zelf aan te passen en toe te voegen.
- Op welke devices wordt de applicatie gebruikt?
Notities: Mobiel Android Google Chrome. Niet hele nieuwe telefoons. Ook moeten we gaan kijken naar het contrast in de zon. In de Jungle worden deze lessen altijd buiten in de zon gegeven.
Nadat wij het gesprek hadden afgerond zijn we met ze vieren in een gesprek gaan zitten om voor ons zelf op te schrijven wat er allemaal is gezegd. Toen we dit gedaan hadden heeft iedereen voor zichzelf een debrief geschreven die we later in de middag samen hebben gevoegd tot een geheel. Deze moest daarna worden opgestuurd naar de opdrachtgevers met hierbij een uitnodiging voor een nieuwe meeting.
Tijdens het samenvoegen van onze debriefen hebben we nog goed gekeken naar onze Job Stories. Deze wilde we zo goed als klaar hebben, voordat we gingen beginnen met het maken van de applicatie. Hier hebben we een groot deel van de middag aangezeten en uiteindelijk de stories ook ingedeeld met de MOSCOW methode. Ook hebben wij aangegeven welke taken er voor ons out of scope waren. Deze taken zullen open blijven staan voor mensen die later verder gaan met deze applicatie. Hieronder valt het productie waardig maken van het inlog systeem en het maken van een NativeApp.
Aan het einde van de middag hebben we als groep de GitHub opgezet. We hadden afgesproken dat we met een development en main branch gingen werken en dan wanneer er aan een nieuwe feature was gewerkt zal dit in een feature/[feature-naam] branch gedaan worden. Ook gingen we een externe API maken waaruit we de Gym spellen data konden halen. Dit wilde Thijs voornamelijk doen dus hij had hiervoor een branch aangemaakt.
Toen we met alles klaar waren voor vandaag heb ik nog even de tutorial van Svelte erbij gepakt en hierin een aantal hoofdstukken gedaan. Dit vond ik zelf erg handig doordat ik eigenlijk nog niet zo heel veel met Frameworks heb gewerkt. Door deze tutorial weet ik nu de basics van Svelte en kan ik morgen gaan beginnen met coderen in ons project.
Jochem had de algemene installatie gedaan van Svelte en ben dus in de ochtend begonnen om deze door te nemen. Ook hebben we met ze alle bepaalde code conventies afgesproken en deze verwerkt in de eslint en prettier. Op deze manier kunnen we een fijne werk omgeving creëren en blijft onze code netjes en leesbaar.
Prettier code conventions
{
"useTabs": true,
"singleQuote": true,
"trailingComma": "none",
"printWidth": 100
}
Eslint code conventions
module.exports = {
root: true,
parser: '@typescript-eslint/parser',
extends: ['eslint:recommended', 'plugin:@typescript-eslint/recommended', 'prettier'],
plugins: ['svelte3', '@typescript-eslint'],
ignorePatterns: ['*.cjs'],
overrides: [{ files: ['*.svelte'], processor: 'svelte3/svelte3' }],
settings: {
'svelte3/typescript': () => require('typescript')
},
parserOptions: {
sourceType: 'module',
ecmaVersion: 2019
},
env: {
browser: true,
es2017: true,
node: true
}
};
Thijs en Jochem wilde graag de GitHub omgeving zo praktisch mogelijk opzetten. Hier hebben ze verschillende features toegevoegd die vanuit github kwamen. We maken gebruik van het project bord waar alle stories, taken en bugs op komen en daarnaast zijn er templates aangemaakt waardoor we issues / pull requesten op een consistente manier kunnen aanmaken. Ook zijn Thijs en Jochem bezig geweest met de CI van Github om hier bepaalde functionaliteiten aan toe te voegen om onze workflow nog beter te maken. Ze vertelde ook dat gaande het project verder komt er meer functionaliteiten bij gaan komen.
Ik heb mijzelf bezig gehouden met het designen van het filter menu. We hadden als team een algemeen design uitgekozen om hierop verder te itereren. Ik ben variaties gaan maken voor het filter menu om op deze manier wat meer mogelijkheden te krijgen hoe we het menu kunnen gaan maken. Toen ik klaar was hebben we dit als groep besproken en hebben we nog even na zitten praten wat we allemaal fijn vonden en heb ik een uiteindelijk design kunnen maken.
Aan het einde van de middag heb ik dit design gemaakt voor ons project. De basis van de overzichtspagina stond al dus kon ik mooi hierop verder werken. Dit heb ik vandaag voor een groot deel afgekregen, maar wilde alleen nog wat extra animaties toevoegen om de user experience wat fijner te maken.
Toen ik klaar was met het design wilde ik dit gaan maken in Svelte. Natuurlijk had ik hier nog niet mee gewerkt dus dit ging in eerste instantie niet helemaal geweldig en moest even me weg vinden. Nadat ik nog wat documentatie had doorgelezen was ik begonnen met het filter menu. Hierin moest een dropdown komen met verschillende filter buttons. Wanneer er op deze filter knoppen geklikt werd zou er een menu moeten openklappen. Het begin van het filter menu staat er en morgen ga ik hiermee verder mee.
Ik ben in de ochtend druk bezig geweest met het afmaken van het filter menu. Uiteindelijk was het filter menu af. Ik wilde de user experience nog verbeteren om een extra animatie toe te voegen. Het doel van dit onderdeel was het maken van een dropdown menu, dus ik wilde graag een dropdown animatie toevoegen.
Bij Svelte is er een speciale manier waarop je door middel van een true|false variabele kan bepalen wat voor class je op een element wilt hebben. In eerste instantie wilde ik het op de normale JavaScript manier doen, maar dit was achteraf helemaal niet nodig en kan het eigenlijk op een hele makkelijke manier. Je zet een on:click op de menu-dropdown en wanneer deze afgaat moet hij een functie runnen waar dit instaat variabele = !variabele op deze manier krijg je telkens een true of false terug als je klikt.
Deze twee lijnen voeg je dan toe aan het element waar je de verschillende classes op wilt hebben:
class:dropdown-close={variabele}
class:dropdown-open={!variabele}
Nadat ik de dropdown af had gemaakt ben ik samen met Sjoerd de filters gaan samen voegen met de dropdown. Als je namelijk op de filter knoppen klikt in mijn dropdown menu komt er dus een pop-up omhoog met hierin de filters die geselecteerd kunnen worden. Dit was een uiteindelijk een moeilijke klus en hebben we dus de rest van de middag aangezeten. Uiteindelijk was het ons niet gelukt en gaan we hier morgen verder mee.
Vandaag zijn Sjoerd en ik weer verder gegaan met het verbinden van onze twee onderdelen. Nadat we onze dagelijkse stand-up hadden gehad vertelde Jochem ons een manier waarop ons probleem verholpen kon worden. We waren bezig met het te kunnen openen en sluiten van de filters pop-up. Het openen was heel makkelijk, maar het daarna weer sluiten ging wat moeilijker. De oplossing was een bepaalde Svelte functionaliteit die we moesten gebruiken. Je noemt dit ook wel een dispatch. Hiermee konden we hem aanroepen in een andere Svelte file om op deze manier de close te activeren.
Uiteindelijk hebben we alles geprobeerd zo goed mogelijk te verdelen in aparte componenten. Hierbij kan je denken aan de buttons die hierin gebruikt werden, maar ook beide onderdelen waren een apart component dat aangeroepen werd in de index file. Wanneer we dit gedaan hadden gingen we de data van de filters dynamisch in proberen te laden met dummie data, zodat als Thijs de API af had hij deze alleen hiermee hoeft te connecten en dan hoeft die dat alleen een beetje om te schrijven.
Aan het einde van de middag zijn we aan de slag gegaan met het onderzoeken van hoe we de correcte query params kunnen mee geven wanneer we de filters selecteren. Hier zijn Sjoerd en ik aardig ver mee gekomen en wilde morgen ochtend het nog even gaan nakijken samen met Thijs om de link te leggen tussen de back-end en front-end.
let filterButtons = activeQueries;
function submitForm() {
let queries = filterButtons.map((activeFilter) => [filterTitle, activeFilter]);
const searchParams = new URLSearchParams(queries);
goto(`/?${searchParams.toString()}`).then(() => closeFilter());
}
Dit is de link die we hebben gebruikt om het stuk code te schrijven:
In de ochtend zijn we verder gegaan met de query params. Hier moesten we kijken of we hem konden linken met het fetch request dat werd gedaan op de homepagina. Thijs ging de afhandeling doen van de request, maar wij moesten hem er zien in te krijgen. Uiteindelijk hadden we alles werkend en konden we de filters gebruiken. Dit was een van de grootste features die we daadwerkelijk toegevoegd wilde hebben en om deze in de eerste week al af te hebben is een grote prestatie. We hadden wat ups en downs tijdens het maken van deze feature, maar dat is dan ook wel logisch als je voor het eerst met Svelte/Query params werkt.
Als je met een grote groep werkt is consistentie een groot deel van de werk-flow. Wanneer je code niet consistent is wordt het erg rommelig en kan je snel het overzicht verliezen. Iedereen werkt natuurlijk op een andere manier en heeft zijn eigen eigenschappen die hij wil mee nemen in het project. Regels voor consistentie hebben we met ze alle afgesproken, voordat we waren begonnen met het project. De standaard procedures worden mee genomen in de ESlint en Prettier. Hierbij moet je denken aan spaties/tabs, puntkomma of niet. Maar je hebt ook regels waar je je als programmeur aan moet houden in een project zonder dat een externe extensie je helpt. Zoals het gebruiken van normale CSS selectoren waar dit kan in plaats van classes of ID's. Hier ben ik een groot deel van de middag mee bezig geweest om dit recht te trekken in ons project.
Zelf ben ik erg geïnteresseerd in het maken van animaties met CSS. Hiervoor wilde ik dus een aantal animaties toevoegen in onze applicatie. Ik wil nog verder onderzoek doen over animaties wanneer je deze wel en niet kan gebruiken en hoe lang een perfecte animatie mag zijn in een design. Toch heb ik alvast een aantal animaties toegevoegd om de user experience wat soepeler te laten verlopen.
Hier zie je de animaties die ik heb toegevoegd. Het gaat hier om de animaties van de filters. Je ziet dat hij een fade/slide-in & out heeft. Dit zit in Svelte zelf en heb even moeten uitzoeken hoe het precies werkt, maar daarna was het resultaat erg fijn en vet om te zien.
Slide in/ out animaties && Dropdown animatie
Als laatst heb ik de dropdown animatie nog wat verbeterd. Hij was een beetje stijf en verliep niet heel soepel. Dit heb ik aangepast, zodat de ervaring met het dropdown filter menu wat makkelijker/mooier verloopt.
In het algemeen is deze week erg goed gegaan. Ons doel was het maken van de filters en deze zo ver mogelijk afkrijgen om deze dan in de eerst volgende test sessie te laten zien. In eerste instantie vond ik het lastig om in een groot team te werken, maar achteraf was deze zorgen helemaal niet nodig. Het is fijn om met een team te werken die weten waarmee ze bezig zijn en op deze manier kan je alleen maar meer leren van elkaar.
Toch vind ik dat ik mezelf nog wat meer moet laten horen tijdens het oppakken van stories/taken en algemene zaken. Hierin ga ik in de aankomende weken verbetering in boeken. Op het moment is er niet echt een leider aanwezig, maar zijn we vier developers met allemaal een eigen mening hoe bepaalde dingen horen te gaan. Toch kunnen we goed met elkaar overweg en wanneer we het niet eens zijn met elkaar praten we dit onderling uit en kiezen we dan de beste optie.
Dus over het algemeen ben ik erg blij met wat ik tot nu toe heb kunnen bereiken. Doordat ik nog nooit met het Svelte framework had gewerkt heb ik in eerste instantie veel documentatie moeten doorlezen. Toch vind ik zelf dat het daadwerkelijk uitproberen en programmeren mij beter afgaat dan alles proberen te snappen door documentatie. Op deze manier loop ik sneller tegen fouten aan en kan ik specifiek opzoeken wat ik nodig heb. Ik vind dat ik goed gebruik maak van de kennis die ik heb opgedaan en dat we als team nu al een super tof project aan het opzetten zijn.
De eerste test sessie komt er aan volgende week dinsdag en ben erg benieuwd wat voor reacties we gaan krijgen op ons gemaakte deel. Voor mijn gevoel gaan we erg snel en ben ik benieuwd wat voor iteraties we moeten gaan doen op ons huidige design. Ook ben ik erg benieuwd naar hoeveel stories we uiteindelijk kunnen afkrijgen voor het einde van de meesterproef.
Vandaag hebben wij onze eerste test met de opdrachtgever. Hierin willen wij het filteren laten zien en het tot nu toe gemaakte design wat hierbij hoort. Voordat we deze meeting hadden hebben we nog een aantal kleine styling aanpassingen gedaan aan de overview pagina. Deze was niet helemaal meer in de goede staat zoals die op ons huidige design was. Toen ik dit terug had gezet kon hij naar onze main branch gemerged worden om op deze manier een live link te krijgen die we kunnen gebruiken in de meeting. Ook is er op het moment maar een filter beschikbaar, doordat er bij ons nog onduidelijkheden waren in de gym data die we hadden gekregen.
Op sommige websites heb je een mooie overgang tussen pagina's, vooral detail pagina's van bijvoorbeeld een product of een artikel. Ik had het er samen met Jochem over of dit mogelijk was in Svelte en dit ben ik dus gaan uitproberen en heb dit uiteindelijk voor elkaar gekregen. Je kan een fly in/out zetten op de volledige content om op deze manier de content naar de rechterkant te laten vliegen en dan wanneer de detail pagina inlaad het van links laten invliegen. Op deze manier heb je een makkelijke/mooie flow van de overzichtspagina naar de detailpagina. Achteraf vond de rest van het team dit nog niet zo relevant en houden we dit in ons achterhoofd om het misschien in de laatste week nog toe te voegen.
Voordat we de meeting hadden met onze opdrachtgevers hebben we met ze alle nog even gekeken naar wat we precies wilde vragen. Om op deze manier zoveel mogelijk uit de test te krijgen. De vragen die we wilde stellen gingen voor groot en deels over de data die wij hebben gekregen van de opdrachtgever. Deze data was op sommige vlakken een beetje inconsistent waardoor het lastig was om sommige opties te gebruiken als filter. Deze opties zullen met de test dan ook nog uit staan en zullen we later verwerken als we hier de antwoorden voor hebben.
De vragen die gesteld waren zijn:
De app moet voornamelijk op mobiel te gebruiken zijn. Als jullie straks spellen gaan toevoegen. Gaat dit dan ook via mobiel of doen jullie het liever via de laptop?
Notities: Dit gaan wij voornamelijk doen op de laptop.
Op welke manier moeten de groepen beschreven worden?
Notities: De groepen mogen los geschreven worden. (op deze manier kunnen wij makkelijker filteren dan 1/2, 3/4)
Jullie vertelde dat jullie geen login wilde. Moet er een inlogscherm zijn waar je kunt klikken op doorgaan zonder account of moet je altijd door kunnen gaan en moet er een login knop zijn?
Notities: Een kleine inlog knop moet al voldoende zijn. Ze vertellen ook over zo'n person icoon die altijd wordt gebruikt (Affordance)
Bij materialen zijn er ook aantallen van een bepaald material, kunnen wij deze achterwegen laten in het filteren en terug laten komen in de detail pagina?
Notities: Dit vinden wij geen probleem en op deze manier kunnen ze gewoon de materialen selecteren die ze hebben en dan kunnen ze daarna bij het spel kijken hoeveel ze hiervan nodig hebben.
Over het algemeen waren ze erg positief en waren ze verbaast in hoever we al waren gekomen binnen één week. Door deze testsessie hebben we erg veel iteratie materiaal gekregen en kunnen we hier mooi mee verder gaan werken. Ook hebben we afgesproken met de opdrachtgever dat voor volgende sprint we de offline pagina willen gaan maken. Op deze manier kunnen de spellen offline beschikbaar worden en wanneer er geen internet is in Suriname en een vak docent heeft wel een spel opgeslagen kan de content hiervan gewoon bekeken worden. Dit is ook een van de hoofdfunctionaliteiten die gemaakt moeten worden en gaan we dus hard mee aan de slag.
Overige details vanuit de test sessie:
- Betere feedback voor de checkboxes van het filter
- Spelsoort knop is niet zichtbaar (alleen de tekst)
- Eerste pagina (‘hoofdpagina’).
- Uitgelichte, favorieten, nieuwe (suggesties) etc.
- Gek algoritme maken die op basis van de interesses van de gebruiker de juiste spellen laat zien (jk)
- Kleurcontrast is wel iets om op te letten. Met name door het licht dat erop komt. Jungle/groen is ook wel leuk. Wellicht dat je daar iets mee kunt doen.
- Lijst met alle filters (met kruisje erachter)
- geen plaatjes in overzicht!
- Alle groepen los (1, 2, 3 etc.)
- Geen exacte match voor materialen
- Meeste materialen zitten er wel in. De kans dat ze nog toevoegen is vrij klein, maar gaat wel gebeuren. Geen prio.
- Menu maken
In het begin van de ochtend ben ik begonnen met alle notities van ons test gesprek, te verwerken naar stories / taken in de issues lijst op github. Op deze manier kunnen ze worden opgepakt door een teamlid wanneer hij tijd heeft. Alle iteraties heb ik als taken opgeschreven en uit het test gesprek was ook naar voren gekomen dat ze een homepagina wilde hebben in vergelijking tot netflix. Waar je verschillende onderwerpen hebt en de gym spellen in een slide staan wat ook bij netflix wordt gebruikt.
Toen Sjoerd online was gekomen zijn we samen begonnen aan de service-worker. Sjoerd had een kleine opzet gemaakt van de service worker. Uiteindelijk was het ons doel om een spel apart te kunnen opslaan in de cache en hier zijn we vandaag mee verder gegaan.
Install event && activate event:
self.addEventListener('install', (event) => {
event.waitUntil(
caches
.open(staticCacheName)
.then((cache) => cache.addAll(assets))
.then(self.skipWaiting())
);
});
self.addEventListener('activate', (event) => {
event.waitUntil(
caches.keys().then((keys) => {
return Promise.all(
keys.filter((key) => key !== staticCacheName).map((key) => caches.delete(key))
);
})
);
});
Wat wij nu nog moesten doen was het fetch event werkend krijgen. Op deze manier konden we dynamische cache opslaan dus wanneer een gebruiker naar een pagina navigeerde die nog niet gecachet was werd deze dan opgeslagen. Uiteindelijk hebben ik en Sjoerd de fetch nog aardig werkend gekregen en zag hij er zo uit:
self.addEventListener('fetch', (evt) => {
console.log('event', evt.request);
evt.respondWith(
caches.match(evt.request).then((cacheRes) => {
return (
cacheRes ||
fetch(evt.request).then((fetchRes) => {
return caches.open(dynamicCacheName).then((cache) => {
cache.put(evt.request.url, fetchRes.clone());
return fetchRes;
});
})
);
})
);
});
Toen moesten we gaan kijken of we een fall-back pagina konden maken wanneer gebruikers bepaalde URL's niet hadden gecachet. Als dit dan gebeurde zouden ze een offline pagina moeten zien. Dit is ons uiteindelijk niet meer gelukt doordat het niet echt mogelijk was op deze manier en voor ons gevoel zat Svelte hier in de weg en werkte de redirect niet als een pagina niet in de cache stond. Hij kwam bij ons niet eens in de .catch terecht waardoor hij dit niet kon uitvoeren: }).catch(() => caches.match('/offline'))
Morgen gaat Thijs ons hiermee verder helpen, omdat het toch wat moeilijker was dan we dachten. Gelukkig hebben wij de basis voor elkaar gekregen, maar wie weet kan Thijs ons daar in verder helpen.
Vandaag ben ik begonnen met het oppakken van het dynamisch maken van de filter titel. De titel krijgen we mee uit de API die we hebben gemaakt alleen is nog niet dynamisch aangegeven in de filteropties. Nadat ik deze had aangepast en ik gaan kijken om herbruikbaar knop-componenten te maken. Hierbij waren dan voornamelijk een submit en cancel button nodig. Nadat ik deze componenten had gemaakt heb ik ze meteen gebruikt in de filter opties pop-up, zodat we zoveel mogelijk gebruik maken van aparte componenten. Ook leer je hierdoor echt goed werken in componenten, ook al moet ik wel zeggen dat ik het soms nog lastig vind wanneer je nu iets in een component moet zetten of niet. Iedereen in ons groepje heeft daar een andere mening over, maar doordat we natuurlijk in een framework werken en dit een van de grote voordelen is moet je hier wel zo goed mogelijk gebruik van maken.
Aan het begin van de middag zijn Thijs en ik samen verder gegaan met het offline gedeelte van de applicatie. We hadden uiteindelijk besloten om geen fall-back pagina te maken maar een component die de gebruiker te zien krijgt wanneer hij offline is. Als de gebruiker offline is wordt er een bericht op de homepagina weergeven met hierop een dynamisch bericht. Het offline component heb ik voor deze situatie gemaakt en ziet er als volgt uit:
Het wordt dus een standaard kaart die boven aan de lijst wordt neergezet en hierbij opvolgend komen alle offline beschikbare spellen. Het is ons namelijk ook gelukt om de games te kunnen cachen via een klik op de spel opslaan knop. Hier zitten hier en daar nog wel wat bugs in, maar we hebben aardige progressie geboekt hierin.
Morgen gaan we verder kijken of we hem daadwerkelijk zichtbaar kunnen krijgen op de homepagina. Dus wanneer de gebruiker offline is zal hij het offline component zien en de opgeslagen games om op deze manier de spellen offline te kunnen bekijken.
Vanuit onze eerste testsessie snapte de opdrachtgevers niet precies hoe het filteren werkte. Ze wisten niet dat ze meerdere opties konden selecteren en dachten dat ze de opties ook weer uit moesten zetten als ze andere wilde selecteren. Dit is een checkboxen systeem dus er kunnen meerdere filters tegelijk geselecteerd worden. Ik ben dus in de ochtend bezig geweest om een verbeterde versie te maken en de checkboxen terug te laten komen in dit design. Dit heb ik uiteindelijk toegevoegd en uiteindelijk nog visueler gemaakt door een animatie toe te voegen. Ook heb ik ze in dezelfde style gemaakt als de filters, zodat ze netjes overeen komen en weten de gebruikers dat het bij elkaar hoort.
In de middag heb ik met Thijs gezeten aan het laatste stukje wat we af moesten krijgen voor het offline gedeelte. Dus hier hebben we samen de rest van de middag aan zitten werken om het zo ver mogelijk af te krijgen. Uiteindelijk was het ons gelukt om de games zichtbaar te krijgen onder het offline component in de overzichtspagina. Thijs vertelde dat er nog enkele functionaliteiten gedaan moesten worden en wilde dit in het weekend nog eventjes doen.
In week twee zijn we druk bezig geweest met de iteraties die we hebben moeten toepassen op het design. De grootste taak deze week was de offline beschikbaarheid. Dit duurde in eerste instantie langer dan we eigenlijk hadden verwacht, want we wilde eigenlijk ook nog het inlog systeem afkrijgen deze week. Dit is uiteindelijk niet gelukt en we hebben ons volledig moeten focussen op het itereren en maken van de offline functionaliteit. Nu we de offline functionaliteit er zo goed als in hebben zitten moeten we gaan kijken wat de volgende stappen gaan zijn voor ons proces.
Het was een tijd geleden dat ik met een service-worker en manifest had gewerkt. Dit was zeker de eerste dag eventjes wennen, maar doordat ik samen met Sjoerd hier aan kon werken ging het wel een stuk makkelijker. We konden elkaar hier goed op aanvullen en op deze manier kwamen we achter de verschillende functionaliteiten die we moesten toevoegen. Ook heb ik een stuk samengewerkt met Thijs en is Sjoerd toen aan de slag gegaan met de nieuwe homepagina die gemaakt moest worden. Thijs was aan de slag gegaan met de service-worker en nam me mee in dit proces. Ik heb daarnaast het herbruikbare offline component gemaakt wat in samenwerking ging met de service-worker.
Er kwam best veel complexe code bij kijken en vond het nogal lastig om Thijs te volgen en de kennis mee te krijgen. Toch heb ik er veel van geleerd en ben ik er nu achter gekomen dat je bepaalde functionaliteiten vanuit een service-worker niet per se in de service-worker file hoeft te zetten, maar dit ook gewoon in een Svelte file kan stoppen. Op deze manier hebben we dus kunnen regelen dat we een URL konden cachen van een spel pagina en Thijs heeft nog in het weekend gekeken na hoe hij een offline tag kon mee geven aan de API dat we ze dan op deze manier dynamisch konden inladen.
Ook al vind ik het designen en maken van de front-end een stuk leuker dit soort functionaliteiten waar ik nog niet zoveel kennis over heb spreken mijzelf ook veel aan. Ik vind het nog wel steeds lastig dat we in een team werken en dat je bepaalde delen van het project uit handen moet geven. Dit is volkomen logisch, want je kunt niet elk deel van het project in je eentje doen als je in een groep werkt. Dit zijn bepaalde punten waar ik nog aan moet werken en me minder aan moet gaan ergeren.
Vanochtend vroeg ben ik begonnen met het maken van de offline knop. Het toevoegen van een spelpagina aan de cache hadden we vorige week al gemaakt dus nu moesten we alleen nog het gedeelte maken dat je het spel weer uit de cache kan verwijderen. Als eerst open je de gamecache en daarna verwijder je de cache die gelinkt is met de pagina waarop je bent. Wanneer de gebruiker dus een keer op de opslaan knop heeft gedrukt veranderd de state, zodat de gebruiker hem daarna kan verwijderen. De on:click krijgt de deleteCache functie mee en de tekst is ook veranderd. Wanneer de gebruiker er dus voor de tweede keer op klikt zal de pagina waarop hij zich bevind weer uit de cache worden verwijderd. Ook wordt de offline state naar false gezet. Op deze manier is hij niet meer zichtbaar in de overzichtspagina als de gebruiker offline is en zal de tag ook verwijderd worden van de gameCard
function deleteCache() {
return Promise.all([
caches.open('gamesCache').then((cache) => cache.delete(`/spellen/${gameSlug}.json`)),
caches.open('gamesCacheSSR').then((cache) => cache.delete(`/spellen/${gameSlug}`))
]).then(() => (game.offline = false));
}
Ik had Thijs om wat hulp gevraagd om mee te kijken naar een probleem wat ik had. Ik kon de cache wel verwijderen, maar dit onthoude die niet als ik naar een andere pagina ging. Hiervoor moest ik dus een klein stukje code toevoegen aan de delete & add van de cache. De game.offline moest ik naar false of true zetten wanneer de gebruiker op de knop drukte.
Daarna zijn we met de hele groep de test ingegaan. We hadden niet een visueel prototype wat de opdrachtgevers konden testen zoals we dit vorige week hadden. Dus we hadden ons scherm gedeeld tijdens deze test. Ook hadden we de offline functionaliteit uitgelegd en laten zien en daarna de gemaakte designs besproken. De helft van de opdrachtgevers waren ook niet aanwezig waardoor we deze test minder feedback hebben kunnen krijgen. Zelf vind ik dat de twee test personen die niet aanwezig waren de fijnste feedback geven en het meeste praten van de vier. Hierdoor hebben we dus voornamelijk gehoord dat de applicatie goed was en echt minimale iteraties gehoord. Ik vond het zelf natuurlijk wel jammer dat we niet een daadwerkelijke demo hadden om te laten zien, maar daarnaast hebben we wel een hele grote functionaliteit kunnen fixen die ze graag in de applicatie wilden hebben.
Overige notities vanuit het test gesprek
-
Voeg toe knopals laatste card in de rij op e homepagina ( weten niet of dit daadwerkelijk nodig is -
Als gebruiker wil ik laten weten aan de maker hoe ik het spel vond (Ranking/reactie komt later)
-
terug kunnen vinden van spellen (favorieten pagina)
-
Vakdocenten zullen er niet veel verstand van hebben hoe ze een reactie kunnen plaatsen(Weinig kennis)
-
Twijfelt over de verwijder knop dus liefst op een andere pagina. (Bang dat die aangeklikt gaat worden)
-
edit velden vinden ze logisch en overzicht.
-
wordt ingevuld door mensen die er wat van snappen.
In de middag ben ik aan de slag gegaan met het uitzoeken van de spam bug. Wanneer je meerdere keren op een spelkaart klikt wordt de URL gedupliceerd en wordt dit in URL gezet. Op deze manier kom je altijd uit op een 404 pagina, omdat er geen pagina bestaat die er zo uitziet: localhost:3000/spellen/spellen/spellen/kat-en-muis. Na een tijdje zoeken heb ik het kunnen fixen door de href URL absoluut te maken door een / aan de voorkant van de URL toe te voegen. Nu kun je niet meer spam klikken op het gameCard component.
Aan het einde van de dag ben ik aan de slag gegaan met het maken van een like knop voor op de details pagina's. In eerste instantie heb ik wat onderzoek gedaan naar wat voor like knoppen er allemaal worden gebruikt en ben uiteindelijk met het team samen uitgekomen op een like knop met het aantal likes ernaast. Morgen ga ik beginnen met het maken van deze knop in Svelte.
Vandaag ga ik verder met het maken van de like knop. Het doel van deze like knop is dat dit feedback geeft naar de vakdocenten en ALO studenten, zodat ze te weten komen welke spellen het beste zijn. Deze informatie kunnen ze dan later weer mee nemen als er nieuwe spellen worden gemaakt. Deze like knop komt te staan op de detailpagina van een spel te staan en wordt gelinkt aan een account waarmee de gebruiker inlogt. Op deze manier kan er maar een keer geliket worden als gebruiker. Wanneer dit volledig werkend is willen we gaan kijken of we ook een sorteerfunctionaliteit kunnen toevoegen waardoor je dus kan sorteren op spellen met de meeste likes.
Dit is wat er uiteindelijk uit is gekomen. De plaats waar de like knop nu staat gaat nog veranderd worden en we zijn nog aan het discuteren of we de like / favoriet knop gaan samen voegen naar een button om op deze manier de UX makkelijker te maken. Zoals je ziet in de gif kan er per gebruiker maar een keer op worden geklikt en kun je hem dus liken, maar ook un-liken. Uiteindelijk gaan we hem verbinden aan een account. Op dit moment zit ik nog te wachten op het back-end gedeelte om te kunnen inloggen als vakdocent. Op dit moment is Thijs daar nog mee bezig en ga ik met dit gedeelte dus verder dan dit af is.
We hebben als groep besloten om een grote refactor te doen van de hele code base om op deze manier de consistentie terug te brengen die er naar een tijdje uit is gegaan. Dit komt natuurlijk doordat je met vier verschillende developers werkt en af en toe wel eens een code standaard vergeet. Ook waren sommige HTML delen niet helemaal semantisch en werden er classes gebruikt in de CSS in plaats van de standaard selectoren. Al deze elementen werden mee gepakt in deze grote refactor. In het begin deel hebben Thijs en ik dit gedaan en uiteindelijk heeft Thijs dit afgemaakt. Ook wilde we dit graag doen om voor volgende week een mooi gelikt prototype te laten zien aan de opdrachtgever.
Vandaag ben ik begonnen met wat kleinere issues oppakken die nog open stonden. Ik had de grote taken voor de aankomende test sessie al voltooid en moest eigenlijk wachten een ander team lid om weer door te kunnen. Hierin ben ik als eerst begonnen met het implementeren van een Iconen library. Tot op heden hadden wij alle iconen gedownload en in een static map gezet om ze hieruit op te halen. Dit kan op een veel makkelijkere manier door middel van de material-icon library van google. Ik heb deze in de script tags van onze static HTML file aangeroepen en dan kan je de iconen als volgt aanroepen:
<i class="material-icon" > [Naam Icoon]</i>
Dit heb ik voor elk huidig icoon wat we hadden gedaan en de gedownloade iconen heb ik kunnen verwijderen. Uiteindelijk hebben we in de refactor nog een apart component hiervoor gemaakt. Hier hoef je dus alleen maar de naam van het icoon mee te geven aan het component en hij wordt ingeladen.
Naast deze taak ben ik het design van Jochem gaan reviewen en heb ik deze nogmaals samen met Thijs doorgenomen en gekeken wat we nog zouden kunnen verbeteren. Uiteindelijk heb ik dit gedaan en daarna heb ik direct extra design voorbeelden gemaakt die ik kan laten zien tijdens de design review van morgen.
Na de lunch ben ik aan de slag gegaan met een Studie Regie Punt, dus pak ik morgen weer nieuwe issues op.
In de ochtend hebben Thijs en ik alleen de refactor van het menu kunnen doen. Hierin hebben we enkele CSS en HTML veranderd om het wat netter eruit te laten zien. Thijs gaat uiteindelijk verder met de volledige refactor en wij zullen dit uiteindelijk met ze alle doornemen.
Oude navigatie menu
Nieuwe navigatie menu
Jochem en Sjoerd hadden in de ochtend een Design review. Door deze design review zijn ze gaan kijken hoe ze bepaalde designs konden verbeteren om de user experience beter te maken. Hierin heb ik zie geholpen en hebben we enkele uur aan gezeten. Uiteindelijk zijn we op verschillende design versies uitgekomen die we kunnen gaan toevoegen in de daadwerkelijke applicatie. Hoogstwaarschijnlijk worden deze mee genomen in het refactor issue die nu open staat.
Nu we steeds meer functionaliteiten krijgen met requests naar de gebouwde API willen we een error handling component hiervoor maken. Tijdens mijn stage werd hier altijd een snackbar component voor gebruikt. Ik ben dus aan de slag gegaan met een component maken hiervoor. Deze kan Thijs dan gebruiken in de error handling met de API requests.
{#if showSnackbar}
<aside in:fly={{ x: -400, duration: 500 }} out:fly={{ x: -400, duration: 500 }}>
<h1>{message}</h1>
<button on:click={() => (showSnackbar = !showSnackbar)} on:click={() => clearTimeout(timeOut)}
>Close</button
>
</aside>
{/if}
Later in de middag zijn Thijs en ik samen naar de design review geweest van Vasilis. Hierin hadden we verschillende functionaliteiten die we wilde testen op UX en dan voornamelijk het kunnen filteren in onze applicatie. Vasilis vertelde ons dat we het beste hiermee naar Koop of Sanne konden gaan, omdat hij hier veel meer verstand van heeft. Deze design review was nog voor de grote refactor van onze code base dus konden we alle overige feedback mooi mee nemen hierbij. Vasilis heeft ons enkele tips mee gegeven die we konden verbeteren:
- Contrast van de applicatie is op het moment nog best laag, hier moet zeker nog wat aan gedaan worden.
- Het is verstandig om het filter altijd open te laten staan in plaats van een dropdown.
- Witruimte moet consistent zijn.
- Goed testen op kleinere telefoons, omdat we niet letterlijk met de gebruikers van deze applicatie kunnen testen.
Aan het einde van de middag zijn ik en Thijs nog eventjes door gegaan met de refactor en hebben we het menu volledig af gemaakt en doorgezet naar de development branch. Thijs gaat morgen verder met de refactor en ik ga morgen aan mijn product biografie werken.
Iedere ochtend beginnen we met ze vieren om even te overleggen wat er deze dag allemaal moet gebeuren en wat er gedaan kan worden. Vandaag was een dag waar we veel gingen proberen te refactoren. We hebben besproken welke punten we allemaal nog moesten verbeteren en daarnaast moesten er nog kleine taken worden opgepakt.
Ik wilde een inhaalslag maken met mijn product biografie, zodat ik daar geen stress van krijg wanneer we aan het einde van de meesterproef zijn. Deze dat bestond dus voornamelijk uit het maken van de product biografie en daarnaast heb ik nog af en toe geholpen met het mee kijken naar de refactor wanneer Thijs mijn hulp nodig had. Door de grote refactor kunnen we een samenhangend product opleveren die voldoet aan de opdrachtgever zijn eisen.
In het begin van de week hadden we onze derde test en ik vond deze aardig goed gaan. We hadden hierin weer veel complimentjes gekregen en wat extra feedback wat we mee konden nemen deze week. Het was geen uitgebreide meeting, doordat de helft van het ALO studenten team niet aanwezig was. In deze meeting hebben we de punten doorgenomen die we deze week wilden gaan behalen. Vooraf hadden we afgesproken dat we deze week veel wilden gaan doen aan de UI van de applicatie en het algemene design. Het werd tijd dat we branding gingen doen voor onze applicatie. De sfeer van de jungle in onze applicatie verwerken en een logo maken met de daarbij behorende Surinaamse kleuren. Ook hebben we deze week een headless (CMS) kunnen toevoegen waarbij we dus nieuwe spellen kunnen toevoegen. We hadden zelfs nog tijd over aan het einde van deze sprint om de volledige code base te refactoren.
Ik merkte aan mijzelf dat ik het deze week wel wat lastiger had met taken oppakken dan de voor afgaande weken. Ik wist niet zo goed wat ik kon doen en moest dit veel vragen bij de teamleden. Het issue bord stond ook niet te springen met nieuwe features, waardoor er dus ook niet veel te doen was. Ik neem aan dat dit volgende week weer anders gaat zijn, doordat alle opdrachtgevers er weer bij zijn en we het volledig nieuwe design kunnen laten zien. Week vier zal ook de laatste week zijn dat we grotere functionaliteiten gaan toevoegen dus we moeten in de aankomende sprint alle laatste puntjes gaan wegwerken.
Over het algemeen mogen we blij zijn met hoever we zijn gekomen in deze drie weken. We hebben de Must haves van onze stories zo goed als af en zijn nu al bezig met veel verschillende Should haves. Ik vind overigens ook dat de applicatie nu in een mooie staat is met het nieuwe design dat is toegevoegd en de globale refactor die nu wordt gedaan. Ook al hoeven we geen productie waardig project neer te zetten vind ik toch dat we daar naartoe aan het werken zijn.
In de ochtend zijn we als eerste ons gaan voorbereiden op de derde testsessie met de opdrachtgever. We maken altijd voordat we beginnen een Google docs file aan waarin we de verschillende vragen zetten. Ook zetten we de notities tijdens het gesprek hierin om op deze manier de notities van de testsessie terug te vinden in een file. Deze week hebben we best veel functionaliteiten om te laten zien en ben benieuwd wat de ALO studenten ervan gaan vinden. Zo wilde we het nieuwe design laten zien wat we hadden gemaakt en het hierbij horende logo. Over het logo + design waren ze razend enthousiast en vonden ze het er geweldig uitzien. Thijs heeft de refactor in het weekend nog doorgezet, hierin heeft hij direct het design mee genomen en kunnen we deze dus live in een prototype laten zien. Ook hebben we de headless (CMS) uitgelegd en op deze manier kunnen er dus spellen worden toegevoegd aan de interface. We hebben ze ook gevraagd om dit daadwerkelijk van de week te gaan doen om uit te testen of ze het snappen en/of er nog vragen of onduidelijkheden zijn.
De vragen die we hebben gesteld tijdens het test gesprek:
Is het een optie om de homepagina samen te voegen met de spellen overzicht pagina?
Homepagina willen we eigenlijk apart houden. Misschien meer links naar het speloverzicht om ze meer te linken met elkaar.
Is het nodig om naast een filter functie ook een order knop te hebben?
Ze hadden hier nog nooit overna gedacht en is eigenlijk wel handig. Dus alle nieuwe spellen komen boven aan te staan, maar als er een spel wordt bijgewerkt komt deze ook boven aan te staan.
Het zijn een hoop opties die jij de gebruiker geeft. Wij snappen het verschil tussen deze opties, maar zijn het er niet te veel?
Itereren op verschillende versies, posities van de knoppen, bij elkaar/los van elkaar. Meer review voor docenten ( dus ipv like meer review met sterren en tekst). Downloaden en favorieten samen voegen?
Zouden jullie een zoekfunctie willen?
Ja, het is altijd handig om te kunnen zoeken in een applicatie met een grote lijst. Wel alleen op de titel en niet op overige filter opties.
Nadat we klaar waren met de testsessie zijn we alle notities gaan omzetten in issues op GitHub en daarna hebben we ze onderling verdeelt. Voordat we aan de issues gaan beginnen, hebben we eerst met ze alle de refactor doorgenomen om te kijken of het duidelijk was wat Thijs had aangepast. Na enkele kleine typescript vraagjes van mijn kant hebben we hem door gemerged naar development om hier op verder te gaan werken met de nieuwe issues.
Ik ben begonnen aan het front-end gedeelte van de favorieten pagina ook wel Mijn gymlessen genoemd. We willen dus dat vak docenten de spellen in hun favorieten lijst kunnen opslaan om ze op deze manier makkelijk terug te vinden. Dit gedeelte zit gelinkt aan de inlogfunctionaliteit. Dus wanneer dit volledig werkend is zal een gebruiker moeten inloggen om de favorieten functionaliteit te kunnen uitvoeren. Ook zal de inloggen knop in het navigatiemenu veranderen naar account onder deze tab komt ook de mijn gymlessen pagina waar de vakdocenten dus de spellen kunnen terug vinden.
Ik kon de favorieten pagina nog niet volledig af maken, doordat de back-end nog verder ontwikkeld moest worden. Ik ben samen met Thijs bezig gegaan om het snackbar component globaal beschikbaar te maken. In eerste instantie wilde we dit doen door hem op de __layout pagina te zetten van svelte, maar dit lukte uiteindelijk niet. Daarna zijn we gaan werken met een writable store om op deze manier globaal de message te kunnen doorgeven aan de snackbar. Op deze manier kan je in elke file een subscribe functie aanroepen op deze store en daar de message aan mee geven en dan kan je het snackbar component laten zien. Een writable store is een object met een subscribe functionaliteit waarmee je bepaalde files die deze subscribe functie gebruiken kan laten weten wanneer de store value veranderd.
Op deze manier ziet de subscribe functionaliteit er nu uit:
messageStore.subscribe((newMessage) => {
if (newMessage) {
showSnackbar = true;
message = newMessage;
timeOut = setTimeout(() => {
showSnackbar = false;
}, 5000);
}
});
En dit is hoe de store eruit ziet:
import { writable } from 'svelte/store';
export const messageStore = writable(undefined)
Ik was verbaasd dat dit zo makkelijk werkte en vond het eigenlijk zonde dat we niet eerder in dit project gebruik hadden gemaakt van de writable store. Ik ga kijken of ik in de loop van deze week nogmaals een writable store object kan maken, zodat ik nog een beetje kan oefenen hiermee.
In de ochtend hadden we een gesprek met Joost. Hierin hadden we besproken wat we tot nu toe hadden staan en Joost was blij met het dream team. Hij had een paar kleine opmerkingen over een design probleempje die we hadden, maar daarin tegen was ons werk goed en is die benieuwd wat we gaan opleveren aan het eind van volgende week.
Ik heb in eerste instantie nog wat verder gewerkt aan de favorieten pagina. Hierin wilde ik een terug knop hebben, omdat het een sub pagina is van account. Deze terug knop wordt vaker gebruikt in onze applicatie dus heb ik er een apart component van gemaakt die je kan aanroepen.
Als volgende issue heb ik het aanzetten van de overige filters opgepakt. Tot op heden hadden we alleen spelsoorten aanstaan als filter, doordat deze als enige werkten met de API. Thijs had al een tijdje geleden gefixt dat de andere filters ook werkten ze moesten alleen nog aan worden gezet. Aankomende donderdag hebben we een design review en hier willen we graag de filters laten zien om extra feedback op te krijgen. Als eerst ben ik de titels gaan doorgeven op een correcte manier. Dus met hoofdletters en de goede benamingen hiervan. Op deze manier konden we ze linken met de API en kregen we dus de gefilterde data terug.
Eerder was de titel van de spellen boven aan het filter in het Engels. Dit hebben we veranderd door een nieuwe prop toe te voegen: filterQuery="category" deze naam moet precies hetzelfde zijn als die vanuit de API, zodat we ze dus kunnen linken. Nu kan de filter titel prop de Nederlandse vertaling van de filter titel mee krijgen om op deze manier ze te kunnen scheiden.
Wanneer er een filter aan staat komt er een tag boven de spellen te staan met de naam van het filter dat is aangezet. Deze kun je weghalen door erop te klikken. In eerste instantie was alleen categorie beschikbaar. Nu is deze filter tag voor elk filter beschikbaar en zal deze boven de spellen komen te staan als het filter daadwerkelijk aan staat. Ook wanneer je dus op deze tag klikt verwijderd die het element, maar ook het gedeelte van de eigen filter query achter de URL.
Wanneer het filter form verstuurd werd moest hij een query parameter doorsturen achter de URL. Deze werd continue verdubbeld als je het filter form twee keer verstuurde. Ik ben samen met Thijs aan deze issue gaan zitten en we hebben samen het volgende stuk code gemaakt hiervoor. We maken een nieuwe array met een .map en hier voegen we de filterquery en de activeFilter in toe. Deze slaan we op in de queries variabele en daarna geven we deze variabele door aan de URLSearchParams. Daarna kijken we voor elke query entree of die al voorkomt in de filterQuery en wanneer dit niet zo is voegen we hem bij de URL query param toe.
function submitForm() {
let queries = filterButtons.map((activeFilter) => [filterQuery, activeFilter]);
const searchParams = new URLSearchParams(queries);
for (const [key, value] of query.entries()) {
if (key !== filterQuery) {
searchParams.append(key, value);
}
}
goto(`/spellen/?${searchParams.toString()}`).then(() => closeFilter());
}
Nadat we dit werkend hebben gekregen ben ik gestopt voor vandaag en morgen maak ik de issue verder af. Op het moment is er nog een bug in het doorgeven van de minimumPlayers. Deze ga ik morgen proberen te fixen.
In de ochtend ben ik door gegaan met het maken van de filters. Er was een filter die ik nog niet werkend had gekregen en dat was de minimumPlayers filter. Het filter form waar deze in wordt gemaakt moest op een andere manier verstuurd worden, doordat het een Number input was in plaats van een checkbox de code hiervoor zag er uiteindelijk zo uit:
function submitMinimalPlayerForm(minimalPlayerCount) {
let queries = [filterQuery, minimalPlayerCount];
const searchParams = new URLSearchParams([queries]);
for (const [key, value] of query.entries()) {
if (key !== filterQuery) {
searchParams.append(key, value);
}
}
goto(`/spellen/?${searchParams.toString()}`).then(() => closeFilter());
}
Dit stukje code is ongeveer hetzelfde als wat ik gister had gemaakt, dus het was makkelijk te implementeren. Ook heb ik een writable store aangemaakt voor het onthouden van de spelers_count. Op deze manier bleef het getal in het filter form altijd staan op de laatst gekozen getal. Heb hiervoor ook de decrease en increase functies wat moeten aanpassen door een update te gebruiken op de store variabele.
Nadat ik dit had gedaan heb ik de styling van het login form opgepakt. Deze moest in de huisstyle van onze applicatie komen. Thijs is de back-end hiervoor aan het maken en ik ben met de front-end bezig gegaan.
De rest van de middag heb ik gewerkt aan de documentatie.
In de ochtend hadden Thijs en ik onze tweede design review. Deze keer was dit samen met Koop. Hierin wilde we de offline pagina en de filters gaan laten reviewen. We hebben aangegeven dat we zaten na te denken om de download / favorieten knop samen te voegen om op deze manier de technische kant uit het verhaal te halen. Op deze manier kan de vakdocent in Suriname een spel toevoegen aan zijn gym lessen en op deze manier zijn ook de spellen direct offline beschikbaar. Ook gaf koop aan dat we gebruik kunnen maken van wat extra feedback zoals iconen of een tooltip die uitlegt aan de gebruiker wat er precies gebeurd en wat hij kan doen.
Het tweede deel van de review ging voornamelijk over het filteren op de speloverzichtspagina. We hadden zelf nog veel twijfels over de flow van de filters. Als de gebruiker een van de filter wilt toevoegen moet er meerdere keren geklikt worden voordat er een filter aanstaat. Er moeten dus veranderingen in komen. Vanuit het gesprek kwam het erop neer dat we meer feedback aan de gebruiker moeten geven. Dit konden we doen door de kleinere filters daadwerkelijk in het uitklapmenu te laten zien. Ook moeten we gaan kijken of we de gebruikers feedback kunnen geven bij de filteropties zelf. Hier moesten we denken aan bijv. 16 gefilterde items beschikbaar en deze zin zal telkens veranderen wanneer er een filter uit of aan wordt gezet. Op deze manier laat je de gebruiker zien hoeveel items er zichtbaar worden. Dit konden we daarnaast ook als titel gebruiken boven de kaartjes. We hadden nog niet bedacht wat voor titel we boven de beschikbare spellen wilden hebben.
Wanneer er een filter aanstaat komt er onder de dropdown een tag te staan met de filter titel hierin. Er werd ons verteld dat het juist handig is om alle geselecteerde filters hier neer te zetten. Ook al is dit een grote lijst het is een stuk feedback die de gebruiker nodig heeft. Hier kunnen we ook een andere manier voor gaan verzinnen dat het niet zoveel ruimte inneemt.
Vandaag was een dag voor veel meetings en ons eind plan bedenken. We hebben als groep veel code geschreven en wat minder de documentatie gedaan, waardoor we nu de laatste week voornamelijk willen gebruiken om ons werk te gaan documenteren. De applicatie die we hebben gemaakt is meer dan af voor hoeveel tijd we erin hebben besteedt. We hebben dus als groep afgesproken wie welk gedeelte van de documentatie gaat doen. Natuurlijk moet iedereen zijn eigen product biografie schrijven, maar daarnaast moeten ook alle features onderbouwt worden. We hebben een onderlinge verdeling gemaakt hiervoor en gaan hier volgende week mee bezig.
In het begin van de middag ben ik enkele feedback punten gaan verwerken uit de design review. Hierin wilde ik voornamelijk gaan kijken naar hoe je een button meer affordance kan geven. Hier heb ik onderzoek voor gedaan en enkele artikelen gelezen.
Uiteindelijk zijn we eruit gekomen om wat vaker een achtergrond kleur te gebruiken en daarnaast ook een box-shadow. Op deze manier geef je de gebruiker een affordance dat ze er daadwerkelijk op kunnen klikken. In het design hebben we dat op deze manier mee genomen:
In de ochtend ben ik voornamelijk bezig geweest met wat kleine aanpassingen in mijn product biografie en hebben we een overleg gehad met wat voor features we nu nog willen afkrijgen voor de oplevering. Ook hebben we gekeken naar het issue bord op GitHub en enkele stories op toekomst gezet of out-of-scope. Op deze manier hebben we een overzicht met wat we nog allemaal gaan doen voor het einde. Ik vind dat we een grote applicatie opleveren en uiteindelijk meer hebben gedaan dan dat we in eerste instantie wilden doen. Dus een soort van slot op de openstaande issues is dan wel fijn, zodat je daar rust in kan krijgen en op deze manier kunnen we ons gaan focussen op de documentatie.
In de middag zijn Thijs en ik aan de slag gegaan met een van de laatste features die we wilde toevoegen. We zijn van plan om het offline beschikbaarheid en het opslaan in favorieten samen toevoegen tot een lijst waar alle spellen instaan voor de gebruiker. In eerste instantie waren we gaan kijken naar de interface en hoe we deze kunnen gaan veranderen. Ik had van tevoren al een branch aangemaakt en hierin de like knop verwijderd en de offline opslaan knop naar boven gezet en deze een stuk meer affordance gegeven dan onze buttons in eerste instantie hadden. Nadat we samen hadden doorgenomen wat we allemaal moesten gaan maken zijn we als eerst naar het Mijn Gymles scherm gaan kijken. Hier moeten we de gebruiker een bepaalde feedback geven wanneer hij nog niet is ingelogd. Het moet de gebruiker dus een uitleg geven over wat de pagina doet, maar ook aangeven dat de gebruiker moet inloggen om deze pagina überhaupt te kunnen gebruiken.
Wanneer de gebruiker is ingelogd kunnen er spellen worden toegevoegd aan deze pagina. Het tweede bericht dat de gebruiker te zien krijgt over het inloggen is dan niet meer zichtbaar en als de gebruiker een van de spellen heeft toegevoegd komt die hierin te staan en is het eerste bericht ook niet meer zichtbaar. Op deze manier geef je de gebruiker genoeg feedback en uitleg over de feature.
Doordat we een homepagina hebben met hierin enkele onderwerpen zoals; Populair, Uitgelicht en nu ook favorieten willen we de gebruiker hier ook feedback geven om ze te begeleiden door de applicatie. We hebben een zero state die de gebruiker ziet als hij op de homepagina komt, maar daarnaast gaat hij ook naar het tweede element in de carrousel wanneer deze aanwezig is.
Zero state favorieten lijst
Active state favorieten lijst
Uiteindelijk zijn we tot hier gekomen en heeft Thijs besloten om in het weekend nog verder te gaan aan deze feature om te kijken of hij ze daadwerkelijk in de favorieten lijst kan krijgen. Dit is meer het back-end gedeelte en we hadden hiervoor dus geen tijd meer om dit samen te doen.
Dit is onze laatste week waar we daadwerkelijk nog grotere functionaliteiten kunnen toevoegen aan het project, maar ook de week waar we eigenlijk moeten gaan afmaken. Ik ben nogmaals trots op wat we hebben kunnen neerzetten als team. Ook de werk-flow waarin het programmeren is gegaan en de dagelijkse stand-ups zijn fijn. Dus over het algemeen is de organisatie in ons team fijn en ook deze week weer helemaal goed gegaan.
Natuurlijk hebben we elke week een gesprek met de opdrachtgevers van dit project. Tot nu toe is elk gesprek super positief gegaan en hebben we er veel uit kunnen halen. Hetzelfde geld ook voor deze week. We hadden een prototype laten zien en hoorde alleen maar positieve feedback en we hadden natuurlijk veel aan het uiterlijk van de applicatie gewerkt en kregen hier alleen maar complimenten op. Daarnaast hebben we dus gekeken wat we nog voor elkaar kunnen krijgen deze week en hebben we met ze afgesproken voor de volgende meeting. Volgende week is natuurlijk ook de oplever week en zullen we dus veel moeten gaan werken aan de documentatie. We hebben dus met ze alle afgesproken dat we tot het eind van deze week nog issues gaan oppakken en in de laatste week alleen nog gaan werken aan de documentatie.
In het begin van de week heb ik aardig wat issues kunnen oppakken om stukken van de applicatie net iets beter te maken dit kun je natuurlijk ook terug lezen in de dag overzichten die ik schrijf. Toch denk ik wel dat het begin van de week een stuk productiever was dan het laatste gedeelte van de week. Ik merk altijd erg aan mezelf wanneer ik documentatie moet gaan schrijven dat er stukken zijn waarop ik vast loop en dit een stuk langer duurt dan ik eigenlijk wil.
In deze periode gaan we voornamelijk werken aan de documentatie van het project. Dit gaan we doen in onze GitBook. Hier gaan we onze design rationale schrijven. Ook zal hier extra informatie over het project te vinden zijn. Op deze manier kunnen we het opleveren aan de opdrachtgever en zullen ze hiermee naar een ander bedrijf kunnen toestappen om dit project productie waardig te maken.