Logs - DaanKetelaars/ilojo-bar GitHub Wiki
https://github.com/JuulVrasdonk/ilojo-bar/wiki
Deze week zijn Juul en ik begonnen aan ons gezamenlijke project voor de meesterproef. Samen zijn we ingedeeld voor het project Ilojo Bar. Hier is het idee om een digitaal monument te gaan maken. Maandag hebben we contact gehad met Femke van Zeijl, zij is journaliste en al sinds 2012 actief in Lagos, Nigeria. Femke is samen met de stichting Legacy aan de gang gegaan om meer aandacht te schenken aan de Ilojo Bar. Deze bar heeft ontzettend veel verhalen en word ook gezien als een stukje geschiedenis van Lagos, maar ook van Nigeria.
Aan ons de taak dus, om dit digitaal op te pakken. We hebben dinsdag via zoom samen met de andere teams gesproken met Femke. Hier werden we gebriefd door haar en hebben we ook een beter beeld gekregen over het project. De dag erna hebben we een debriefing geschreven op basis van deze briefing. Via deze manier kunnen we voor onszelf even op een rijtje zetten hoe we het project zien. Femke had hier en daar nog wel wat kleine aan en opmerkingen op onze debriefing, maar in grote lijnen klopte onze debriefing.
De taak is nu aan ons om een concept te gaan bedenken en zoveel mogelijk klaar te krijgen voor volgende week vrijdag. Dan spreken we Femke weer. Woensdag hebben is er ook een handige workshop geweest van Joost over het gebruik van een Headless CMS. Voor ons project is dat handig, de opdrachtgever wil graag dat er verhalen toegevoegd kunnen worden. Hier zou een CMS erg mee helpen om dit gemakkelijk te kunnen verwerken.
Naast de meesterproef was er ook tijd om langs te gaan bij DEPT voor de weekly mingle. Het was tof om een keer binnen te stappen bij DEPT en te zien hoe zo'n enorme agency te werk gaat. Naast de rondleiding in het toch wel enorme gebouw (waar je gemakkelijk verdwaald kan raken), werd er ook een presentatie gehouden over DEPT en als je daar eventueel gaat werk/stage lopen. Jammer dat we niet gebruikt mochten maken van de bar voor een klein biertje, desondanks wel een leuke weekly mingle!
Na de eerste week hebben Juul en ik een start gemaakt aan ons concept. Vanuit het gesprek met onze opdrachtgever hebben wij nu een beter beeld gekregen over het project. Hierop kunnen wij beginnen met een goed concept neer te zetten en later ook een digitaal product. Beide hadden we wel het idee om storytelling te gaan gebruiken. Zo hadden we al wel een vaag idee in ons hoofd, maar wilden we toch nog wat extra onderzoek doen. Via de website Awwwards kwamen we wat storytelling voorbeelden tegen die ons aanspraken. Voornamelijk omdat ze ook wat te maken hadden met geschiedenis. Hieronder 3 voorbeelden die Juul en ik gevonden hadden. Of, onze top 3 eigenlijk. Vanuit deze voorbeelden zijn we verdergegaan in ons proces.
⁃ https://elukash.com/ ⁃ https://www.bbc.com/storyworks/specials/kazakhstan-transport/inspired-by-the-past-designed-for-the-future/ ⁃ https://calem.pt/douro/
Voor ons concept wilden we de verhalen die Femke geschreven heeft hun eigen karakter meegeven. Ook was het idee om iets grafisch te doen en een visuele website te bouwen. Naast dit hadden we ook nog in ons hoofd om iets met 3D te gaan doen. Bijna de hele groep wel. Uiteindelijk zijn Juul en ik gegaan voor eenzelfde soort idee als de “Elukash” website. Een soort fotoboek waar je doorheen kan bladeren, nu dan scrollen. Langzaam komen er foto’s in beeld schuiven. Misschien wel een soort tafel waar de informatie op gelegd wordt. Alsof je een duik neemt in het Journalistieke werk van Femke. Nou het concept was wel redelijk duidelijk. Het was niet het idee om hier te lang aan te zitten. Toch konden we niet heel veel verder. Femke moest nog wat beeld aanleveren. Met dat beeld konden we echt pas beginnen aan ons concept. Helemaal de 3D tekeningen die zij had. Het lag eraan hoe makkelijk we die tekeningen konden gebruiken in ons concept. Het zou namelijk heel tof zijn om het gebouw wat verwoest is tot leven te laten brengen.
Ons concept:
Een rustige week wel, veel ideeën, nog weinig actie qua code. Vanaf volgende week kunnen we echt goed aan de slag. Aan het einde van de week zijn we natuurlijk naar onze weekly mingle geweest, dit was bij de Voorhoede. Hier hebben wij een kleine workshop gehad in design systems en hoe deze ook tegenwoordig gebruikt worden in de Front-end wereld. Via deze manier kun je namelijk veel gemakkelijker en effectiever werken. Helemaal als team.
Week 3 is onderweg. Deze week kunnen we echt gaan vlammen. We hebben alles binnen van Femke en kunnen nu ons idee/concept gaan uitwerken in een ontwerp. Juul en ik (ondanks het advies van sommige docenten) vinden het prettiger om ons concept uit te werken in een designprogramma. Om daarna pas de overstap te maken naar code. Dit geeft ons overzicht over het project. Ook omdat wij met nieuwe technische tools gaan werken. Dan is het handiger om zo geordend mogelijk aan de slag te gaan.
Kleine ingreep in ons iteratie proces voor ons ontwerp. We zijn begonnen met het zoeken naar het juiste lettertype en vanuit daar geprobeerd het concept om te zetten in Figma.
Lettertypes:
Gekozen lettertypes, Helvetica Neue en Roxborough:
Iteraties op het design:
Onze tech stack voor dit project zal namelijk iets anders zijn. We hebben gekozen voor Next.JS als framework, geen Vanilla JS of Express. Juul en ik gaan veel met Next werken tijdens onze afstudeerstages. Daarom leek het ons goed en leuk om Next nu al uit te proberen. Daarnaast biedt Next ook veel features waar je normaal toch nog een aantal uren aan kwijt bent. Eén van die features is het optimaliseren van je code. Heel veel dingen zijn al voor je gedaan. Daar is het een framework voor natuurlijk. Dus het opzetten van routing is niet meer nodig. En als laatste, Next is ook server-side. Het lijkt eigenlijk wel aardig wat op Express. Dit zijn wel zaken waar we naar gekeken hebben. Ons optiek was niet om een framework te kiezen omdat het tof is en iedereen het gebruikt.
Meer hier over Next.JS: https://nextjs.org/
Uiteindelijk was niet iedereen het met ons eens, dit kan en mag. Vorige week hadden we ons eerste design en code review. Hier waren de meningen wat verdeeld over het gebruik van Next.JS. Ons project wordt uiteindelijk gebruikt door gebruikers in Lagos, Nigeria. Hier is schijnbaar het internet minder en lopen ze wat achter qua devices en daardoor ook browsers. Dit is niet ideaal. Daarom gaven sommige docenten ons het advies om eerder alles in basis HTML/CSS/JS te doen. Via deze manier een website te bouwen die qua progressive enhancement en performance heel sterk staat. Heel tof om te doen, maar Juul en ik wilden toch heel graag verder met Next.JS. Uiteindelijk hebben wij nog een paar andere docenten gesproken, die raden ons weer aan om met Next verder te gaan. Uiteindelijk zijn het adviezen, Juul en ik zijn bij ons plan gebleven. Wel hebben we het er nog over gehad. Maar Next is toch voor ons op dit moment de beste keuze.
Deze week hebben we ook het design eindelijk afgerond. Dit hebben we ook gepresenteerd aan Femke. Zij was hier erg tevreden over en de stijl sprak haar heel erg aan. Toch had zij als feedback om te kijken naar de volgorde van de verhalen. De volgorde die wij hebben zou voor problemen kunnen zorgen bij een bepaalde familie. De desbetreffende familie is gelinkt aan de sloop, of een familielid. Hierdoor zou het vervelend over kunnen komen. Haar advies was om dat verhaal als laatst te tonen.
Het design:
Goed, wij konden verder. We hadden voor onze meeting de designs uitgeprint. Hierop hebben we breakdownschetsen gemaakt. Omdat we met een nieuwe tech stack werken leek dit voor ons een handige stap. Dit zou het overzetten van design naar code wat gemakkelijker maken. Naast dit moeten we ook nog gaan nadenken over het koppelen van Next.JS en Prismic (headless CMS). Nou weet ik dat je met Next heel eenvoudig een headless CMS kan koppelen. Weer een voordeel van Next ;). Maar omdat het nieuw voor ons is, is het wel handig om hier even goed voor te zitten.
Onze breakdownschetsen:
Nu even wat vervolg stappen. Ik had vorige week al de basis van Next opgezet, gezamenlijk met onze Git Repo. Nu is het plan dat Juul zich bezig gaat houden met het visuele omzetten van ons design naar Next. Ik pak de taak op om ons CMS te koppelen met Next.
Zoals gewoonlijk zijn we weer naar de weekly mingle geweest. Deze keer Build in Amsterdam. De stageplek van Juul. Een heel tof bedrijf, ik volg ze al een tijdje. Altijd wel onder de indruk geweest van hun werk. Met de weekly nerd van Fenna kreeg je al een kleine indruk van Build in en hun aanpak.
Folkert-Jan van Build in gaf een presentatie over zichzelf en zijn pad naar Build in. Daarnaast ook over het bedrijf zelf. En als laatst heeft hij ons getrakteerd op een kleine workshop, scroll animaties. Geheel Vanilla. Wel grappig om te zien dat je toch wat wiskunde en reken werk gebruikt bij het bouwen van wat complexere animaties. Wat ik wel meeneem van die workshop, is hoe hij zijn animaties eerst uitschets. Hij had de animatie en de complexiteit wel redelijk op papier gezet. Heel handig en dit bied overzicht als je gaat werken aan een toch wat complexe functionaliteit.
Nou, een goede week. Al zeg ik het zelf.
De één na laatste week is aangebroken. In deze week zijn Juul en ik voornamelijk bezig geweest met de code. Juul meer met het visuele gedeelte en ik met de data vanuit het CMS. Ik ben in het begin van deze week verdergegaan met het implementeren van Prismic in onze Next setup.
Ik heb wel wat problemen gehad met Prismic. Naast de karige documentatie wat betreft Next & Prismic. Ja, er is wel documentatie. Alleen vaak klopt er dan een klein stukje code niet (omdat het te oud is) of is het net niet waar wij naar zoeken. De slices in Prismic vond ik ook wat verwarrend. Kijken naar de krappe 2 weken die we nog hebben, leek het mij slimmer om op zoek te gaan naar een alternatief. Via wat klasgenoten, die ook niet al tevreden waren over Prismic kwam ik uit op GraphCMS. Dit was via Nathan.
GraphCMS had al meer documentatie en het was gemakkelijk om veel tutorials te vinden van het koppelen met Next. GraphCMS is ontworpen door GraphQL, het inladen van data zal hierdoor ook prettiger zijn. En het laatste voordeel is de interface. In mijn ogen wat eenvoudiger. Helemaal voor onze opdrachtgever. Zij is natuurlijk niet zo technisch zoals wij.
Hier meer over GraphCMS: https://graphcms.com/
Het duurde even, maar het is mij gelukt om Next te koppelen met GraphCMS. Onze data wordt gewoon getoond. Misschien wat nerdy, maar altijd wel een goed gevoel als iets werkt haha. Helemaal als het iets nieuws is. Toch kwamen Juul en ik erachter, dat onze aanpak in het CMS en code uiteindelijk niet soepel zou gaan werken. Helemaal omdat de vraag van de opdrachtgever is om de sections/stories te kunnen verschuiven. De volgorde mag niet vaststaan. Dit moet anders neergezet kunnen worden. Juul en ik hebben na het gesprek met onze opdrachtgever contact gezocht met Joost. Hij had hier kennis van en heeft ons uiteindelijk goed op weg geholpen. Dit hebben we in een teams call gedaan. Hierna hebben Juul en ik alles omgegooid. We hadden eerst meerdere story components en pagina’s. Het was handiger om hier één van te maken en dan binnen het CMS het zo neer te zetten dat je wel die aparte verhalen hebt. Een beetje zoals je bij posts of berichten hebt. Er is een standaard post layout, alleen de inhoud is verschillend.
Hier kort hoe het eruit ziet achter in ons CMS:
Je hebt models in GraphCMS. Dit kun je zien als een soort pages. Wij hebben hierin een Main model, met daarin een relation naar ons story component/model. In de story model zitten onze elementen die we nodig hebben voor het verhaal. Als je dan naar het kopje content gaat in GraphCMS, kom je in de achterkant van deze models. Hierin kun je de content wijzigen. Zo kun je dus een apart verhaal bewerken, maar ook de volgorde van de verhalen.
Deze video legt uit hoe dit werkt, hieruit heb ik de aanpak ook gehaald. https://www.youtube.com/watch?v=6DRtat2jBps&t=455s
Hier nog wat over relations en reference types in de GraphCMS documentatie. Voor dit onderdeel maak ik nu gebruik van de two-way reference. Dit geeft je de optie om zo informatie te queryen van beide kanten. https://graphcms.com/features/content-modeling/reference-type
Nu heb je een story block, hierin worden de elementen geladen die nodig zijn. Titel, subtitel, broodtekst en plaatjes. Femke kan via dit block, vanwege de relation type, nu meerdere verhalen aanmaken. In de CSS zorg je er dan voor dat de verhalen visueel verschillend zijn en hun eigen karakter hebben. Deze manier is veel geschikter en schaalbaar.
Alles staat nu perfect in het CMS, maar nog niet in Next. We laden nu namelijk data in via server-side (Next is server-side). Alleen wij hebben onze data ook nodig in client-side components. Next heeft hier niet een gemakkelijke oplossing voor, je kan dat niet even zomaar omzetten. Robert gaf al aan om een context provider te maken, hier ben ik verder op gaan borduren. Maar toch hebben we Joost weer even om advies gevraagd. Dit was ook de eerste keer voor ons en voor mij met een context provider. Joost heeft ons weer wat op weg geholpen en duidelijkheid gegeven. 20 min na dit gesprek had ik de context provider opgelost en konden wij data versturen naar onze clients-side components. He he… het echte werk kon nu eindelijk beginnen. Het tonen van de data op de juiste plek, alles koppelen en beginnen met het stijlen van de verhalen.
Inladen van data in Next.JS. Dit gebeurt via getStaticProps. Deze functie is het beste als je een headless CMS gebruikt. Ook komt de data binnen na de build en voor het request van de gebruiker
Meer over getStaticProps hier: https://nextjs.org/docs/basic-features/data-fetching/get-static-props
Eerst maak je een functie aan (het liefst in een ander bestand. Bij ons in de folder "lib" en genaamd api.js) en hier maak je gebruik van GraphQL om je data in te laden. Daarna gebruik je getStaticProps in je pagina om deze data door te sturen. Er zitten in deze code ook wat stukjes om nu de data door te sturen naar client-side components. Normaal is het alleen server-side.
export async function getAllStories(section) {
const query = gql `
{
mains {
blocks {
... on Story {
id
bodytext01 {
text
}
bodytext02 {
text
}
images {
id
url
}
title
subtitle
}
}
}
headersConnection {
edges {
node {
heading
id
image {
url
id
}
}
}
}
footersConnection {
edges {
node {
title
image {
url
id
}
}
}
}
}
`;
const results = await graphcms.request(query);
mains = results.mains;
mains.forEach((item) => {
blocks = item.blocks;
});
results.headersConnection.edges.forEach((result) => {
header = result.node;
});
results.footersConnection.edges.forEach((result) => {
footer = result.node;
});
const sections = {
blocks,
header,
footer,
};
return sections;
}export async function getStaticProps() {
const stories = (await getAllStories()) || [];
return {
props: { stories },
};
}Ik heb in onze readme ook een uitgebreide uitleg geschreven over de context provider. Wat doet het, hoe werkt het en hoe gebruiken wij hem.
https://github.com/DaanKetelaars/ilojo-bar
De laatste week, nog even knallen om alles af te krijgen. De ingewikkelde technische zaken zijn geregeld, nu is het vooral styling en animatie werk. Juul en ik hebben tijdens ons project al vaker een opdeling gehad van onze website. Deze hebben wij weer erbij gepakt, dan weten we wie welk verhaal maakt en ontwerpt.
Omdat bij onze opdracht mobiel erg belangrijk was hebben we voor nu ons project mobile first en only gemaakt. Voor de volgende groep die verder gaat aan dit project kunnen wij wat vervolgstappen meegegeven. Fully responsive zou dan één van die stappen zijn. Nou was het soms nog wel even een gedoe om het zelfs op mobiel lekker te laten werken. Ons design is erg grafisch en er gebeurt veel. Voor het werken met de beelden in CSS is even een gedoe. Juul kwam met het idee om display: flex; te gebruiken. Dan met flex order de volgorde te bepalen van de content in de sections. Dit gaf ons de kans om onze verhalen gemakkelijker te stijlen zoals ons design
Hierna hebben we ons lijstje afgewerkt. Nadat we klaar waren zijn we verdergegaan met de animaties. Ik heb mij gefocust op de animaties van de afbeeldingen en wat tekst animaties. Juul heeft wat speciale effecten toegevoegd, zoals het “grain” effect. We hebben ook nog een smooth scroll scriptje toegevoegd, deze had ik nog vanuit een ander project. Ook is er een scriptje gemaakt voor als onze headings. Het laatste scriptje zorgt ervoor dat elk 2de en 3de woord van onze headings een ander lettertype heeft. Dit hadden wij ook in ons design staan.
Hier nog een stukje code voor de animaties waar ik aan gewerkt heb. Deze code voegt een class toe als de afbeeldingen in de viewport komen van de gebruiker.
Ik maak gebruik van de intersectionObserver. Deze functie of Web API is super handig voor on scroll animaties. Veel grote agencies maken hier nog steeds gebruik van, zo hoef je niet moeilijk te doen met libraries zoals FramerMotion of GSAP.
Ik pak alle items die ik nodig heb. Daarna maak ik wat opties aan voor mijn intersection observer. Dit zijn standaard opties. Daarna heb ik een inViewCallBack, hierin loop ik over de entries (de elementen) en voeg ik een class toe als ze in beeld zijn. Daarna voeg ik de code die ik in het begin geschreven heb toe aan mijn observer. Anders pakt hij niks en werkt het niet.
let observedElements = document.querySelectorAll('.article-img, h2, h4'); // Define the elements you want to intiate an action on
const options = { //define your options
root: null, // Null = based on viewport
rootMargin: "0px", // Margin for root if desired
treshold: 0.5
}
const inViewCallback = entries => {
entries.forEach(entry => {
if (entry.isIntersecting) { // define the event/property you want to use
entry.target.classList.add('inview');
//do something with the element
}
});
}
let observer = new IntersectionObserver(inViewCallback, options); // create a new instance using our callback which contains our elements and actions, using the options we defined
observedElements.forEach(element => {
observer.observe(element) // run the observer
});Hier de code voor de headings. Wat hier gebeurt is redelijk simpel. De typeof window die om de code staat is nodig zodat je client-side JS kan gebruiken in Next.JS. Dat werkt even iets anders. Maar wat ik hierin doe is, het selecteren van alle headings. Daarna loop ik over die headings heen met forEach. Binnen in die forEach gebruik ik trim en split. Trim haalt witruimtes weg en split koppelt woorden los van een zin. Ik heb die losse woorden nodig, dan kan ik namelijk aangeven dat het 2de en 3de woord een andere style moet krijgen. Wat ik daarna doe is een map over deze woorden die ik net gesplit heb. In de map functie ga ik deze woorden wijzigen, daarom is het handig dat je map gebruikt en niet forEach. Ik filter op woord 2 en 3, als die gevonden zijn dan moet hij een span om die woorden gooien. Daarna voeg ik alles weer samen. In de CSS kan ik dan de span stylen met een ander lettertypen.
if (typeof window !== "undefined") {
let node = document.querySelectorAll('h2, h1');
node.forEach(node => {
if (node) {
let content = node.textContent.trim().split(" ").map((word, i) => i === 1 || i === 2 ? `<span>${word}</span>` : word);
node.innerHTML = content.join(" ")
}
})
}Juul kwam op het laatst nog met één klein css probleem, dit ging om hoe we onze images hadden neergezet. Dit deden wij met position: absolute; en dan via top, bottom, left en right positioneerden wij de afbeeldingen op de juiste plek. Dit werkte soms niet heel lekker, uiteindelijk zijn we voor een aanpak gegaan waar alleen afbeeldingen die position: absolute; nodig hebben dit krijgen. De rest krijgt dit niet. En als er absolute afbeeldingen zijn dan dient er één relative te zijn. Dit zorgt voor een soort “schild” zoals Juul heel mooi zei. Hierdoor kunnen we namelijk de absolute afbeeldingen goed neerzetten en krijgen we ook geen problemen met de flex orders.
De CSS was klaar, nu tijd voor wat performance issues. Zoals ik had aangeven doet Next hier al veel in voor ons. Dit gebeurt in de build fase van Next. Dit waren we even vergeten, dus in het begin was onze performance erg laag. 63 zelfs, zie hieronder. Na het runnen van de build ging dit naar 100. In de build fase haalt Next onnodige troep weg. Hiernaast hebben wij nog wat kleine issues handmatig gefixt. Font-display: swap; bij alle font-families, afbeeldingen eventueel verkleinen en nog wat andere taken vanuit lighthouse.
Hier nog onze lighthouse scores:
Uiteindelijk is dit dan het eindresultaat van Juul en mij. Beide zijn we erg trots op ons eindproduct. Natuurlijk is het nog niet perfect, maar voor die 5 weken zijn wij erg tevreden.