Skip to content

WEEK 03

Michelle Hendriks edited this page Apr 12, 2024 · 9 revisions

Datum: 04-03-2024 tot 08-03-2024

🔎 1.0 Analyseren


1.1 Heronderzoek Tech-stack

📅 04-03-2024

  • De fase van front-end ontwikkeling:  Op basis van de projectvereisten wordt zorgvuldig zowel de Development Experience (DX) als de Content Management Experience (CX) onderzocht. Na dit onderzoek wordt er een geschikte technologie stack gekozen die optimaal aansluit bij de behoeften van de opdrachtgever, gebruiker en ontwikkelaar. Vervolgens wordt de ontwikkelomgeving ingericht met een logische mappenstructuur en koppelen we het CMS. Om snel van start te gaan, wordt er een basis responsive lay-out ontworpen.In latere fasen worden de complexere functionaliteiten toegevoegd, zoals een reserveringssysteem en een login systeem. Er worden regelmatig tests uit op verschillende browsers en apparaten uitgevoerd om een brede compatibiliteit te waarborgen. De code wordt voortdurend aangepast op basis van feedback, waardoor er een iteratieve en responsieve ontwikkelingsaanpak wordt gehanteerd.

  • Link naar eerste bevindingen.

1.0 User Experience

📅 05-03-2024

Voor een begrip van de gebruikerservaring van de WOGO website is er een klein onderzoek uitgevoerd, rekening houdend met de diverse aspecten die de UX beïnvloeden. Hierbij hebben we de kennis en ervaring die ik eerder heb opgedaan bij FDND met betrekking tot UX in acht genomen.

Het doel is inzicht inzicht te krijgen in de laaggeletterdheid, het bezit van apparaten en internetverbindingssnelheden onder zowel inwoners als toeristen in Amsterdam. De informatie uit dit onderzoek zal worden gebruikt om gedetailleerde persona's te creëren. Er Verschillende bronnen zijn geraadpleegd om een analyse uit te voeren.

Tech-geletterdheid: 



Apparaten: De doepgroep heeft een leefdtijd van 20 tot 45 jaar en volgens een table gebruiken de doelgroep verschillende apparaten zie excel bestand

2.1 Development Experience

Het doel van dit onderzoek is om de Development experience (DX) van vier populaire web development frameworks, namelijk Svelte Kit, Nuxt, Next.js, en Astro, te onderzoeken.

Link naar onderzoek DX

Screenshot 2024-03-21 at 23 03 34

Sveltekit

Screenshot 2024-03-21 at 23 04 57

Astro

Screenshot 2024-03-21 at 23 05 09

Nuxt

Screenshot 2024-03-21 at 23 05 17

Next.js

Screenshot 2024-03-21 at 23 05 25
Conclusie DX

In deze conclusie geef ik mijn persoonlijke voorkeur voor de pluspunten en nadelen van het bovengenoemde onderzoek naar de development experience (DX) van vier populaire frontend-frameworks, namelijk Svelte Kit, Nuxt, Next.js en Astro.

Framework Pluspunten nadelen
Sveltekit De code is leesbaas, minder code schrijven, Super georganiseerd en gewoon logisch. Ondanks de lage populariteit, waardoor overdracht van het project een uitdaging kan zijn, is het vanwege, dichtbij de webstandaarden en de lage leercurve toch een mogelijke optie. Kleinere community, maar het platform groeit wel snel. Minder geschikt voor complexe applicaties met veel features.
Astro Dicht bij webstandaarden, minder complexiteit in vergelijking met andere frameworks. SEO is erg sterk Astro is mogelijk minder geschikt voor toepassingen die zeer interactieve gebruikersinterfaces vereisen, Het ontbreken van ingebouwde ondersteuning voor dynamische routing kan de ontwikkelaarservaring beïnvloeden bij het werken aan grotere projecten. Kleine community
Nuxt Grote community met veel tutorials en ondersteuningsbronnen, Kan worden gebruikt om grote en complexe webapplicaties te bouwen. project sneller overdraagbaar door grote community De leercurve kan steiler zijn vanwege de vele features en opties, maar komt wel dichtbij Svelte in de buurt. Kost tijd door verdieping in nieuw techstack
Next.js Het geeft veel controle om dingen precies zo aan te passen als jij wilt. Dit is vooral handig voor grote, gecompliceerde websites. De grootste community Kan complexer zijn omdat het verder weg staat van webstandaarden.

SvelteKit heb ik al gebruikt in eerdere projecten, wat mijn ervaring en vertrouwdheid met de syntax vergroot. Dit leidt tot efficiëntie, aangezien ik geen nieuw concept hoef te leren. Hoewel SvelteKit niet zo'n grote community heeft als Next.js en Nuxt, heeft het aanzienlijke groei doorgemaakt en voldoende ondersteuning. Dit wordt bevestigd door het bovenstaande onderzoek, waaruit blijkt dat er maar liefst 10.000 video's beschikbaar zijn en SvelteKit in 2022 op de vierde plaats staat met 21% van de meest gedownloade frameworks.

Wat betreft Astro, hoewel het dicht bij webstandaarden ligt, heb ik ervoor gekozen het niet te gebruiken vanwege de beperktere community-ondersteuning in vergelijking met SvelteKit. Een sterke community is voor mij van groot belang om snel oplossingen te vinden en te blijven profiteren van de ontwikkelingen binnen het gekozen framework.

3.0 CMS

📅 06-03-2024

Headless CMS Vergelijking voor WOGO

Huidige Content management system WOGO

Momenteel maakt WOGO gebruik van het content management system(CMS) Wix.

  • Zoekmachine optimalisatie is onmogelijk of heel erg beperkt omdat de frontend is opgebouwd uit kant-en-klare componenten. - Dynamische gegevens vormenen ander probleem, aangezien gekoppelde CMS-websites statisch zijn, wat betekent dat de Hypertext.

De voor en nadelen worden nadelen hiervan zijn:

Voordelen:

  • Gebruikersgemak: Het huidige CMS biedt een intuïtieve gebruikersinterface die het voor niet-technische gebruikers gemakkelijk maakt om content te beheren en te publiceren, wat essentieel is voor het onderhouden van de dynamische inhoud van Wogo.

  • Kostenbesparing: Door de eenvoudige contentbeheerfuncties kan Wogo zonder uitgebreide training content wijzigen, waardoor de afhankelijkheid van externe ontwikkelaars wordt verminderd en kosten worden bespaard.

Nadelen:

  • Beperkte Aanpasbaarheid: Het CMS kan beperkingen hebben in termen van aanpasbaarheid en flexibiliteit, waardoor WOGO mogelijk niet in staat is om specifieke functionaliteiten of aangepaste ervaringen te implementeren die cruciaal kunnen zijn voor hun digitale strategie.

  • Schaalbaarheidsproblemen: Naarmate WOGO groeit, kan het huidige CMS moeite hebben om efficiënt te schalen, wat kan leiden tot prestatieproblemen of een verminderde gebruikerservaring.

Van zijn de beperkingen van WOGO momenteel?

  • Beperkte Creatieve Vrijheid in Thema's WIX biedt een breed scala aan thema's en een drag-and-drop interface, maar voor bedrijven met specifieke branding- of designvereisten kan dit beperkend zijn. De behoefte aan unieke, op maat gemaakte designs kan moeilijk te realiseren zijn binnen de structuur van een standaard WIX-thema.

  • Problemen met het Reserveringssysteem Probleem: Het handmatig moeten wijzigen van boekingen door het personeel, omdat klanten dit niet zelf kunnen, leidt tot inefficiëntie en verhoogt de werklast voor het team.

  • Problemen met de Chatbox Probleem: Het handmatig moeten beantwoorden van alle chatberichten kan leiden tot lange wachttijden voor gebruikers, wat de klanttevredenheid kan beïnvloeden.

  • Responsive Problemen Probleem: WOGO ondervindt problemen met de responsiviteit van hun WIX-website, wat betekent dat de website niet altijd goed wordt weergegeven of functioneert op verschillende apparaten en schermformaten. Dit kan leiden tot een suboptimale gebruikerservaring, vooral gezien het groeiende gebruik van mobiele apparaten voor het zoeken en boeken van uitgaansgelegenheden.

Conclusie Het huidige CMS biedt Wogo een gebruiksvriendelijke en kosteneffectieve oplossing voor contentbeheer en online zichtbaarheid. Echter, beperkingen in aanpasbaarheid, schaalbaarheid en veiligheid vereisen zorgvuldige overweging.

Wat betaald WOGO momenteel aan Wix?

●	jaarlijks iets van 300 euro voor t wix premium abbonoment
●	⁠jaarlijks 15 euro ofzo voor de website naam
●	⁠en dan voor t mailing systeem 35 per maand
●	⁠en dus commisie van 1-2% per transactie geloof ik

Waarom ik kies voor een headless CMS aanpak:

Creativiteit

Op technologisch heeft WOGO totale vrijheid nodig om onze visie op de digitale merkbeleving voor WOGO te realiseren. Traditionele WIX zijn beperkt in wat mogelijk is aan de voorkant. Dit komt door de manier waarop de voorkant direct verbonden is met de achterkant, waardoor een groot deel van het formaat en de ontwerpen wordt bepaald. Bij een headless CMS is dit niet het geval.

Dankzij de architectuur van een headless CMS beheer je al je content in één apart systeem, en laad je deze vervolgens via API’s in naar de verschillende frontends . Op deze manier verkrijgt u meer creatieve vrijheid en flexibiliteit , omdat de front-end nu niet langer beperkt wordt door de standaardoplossingen die gelden voor een traditioneel CMS, zoals WIX. Precies wat we nodig hadden voor dit project.

Een solide CMS voor flexibel contentbeheer Omdat de front-end voor dit project zo ambitieus is, moesten we kiezen voor een solide back-end-optie die eenvoudig in te stellen is . Er zijn veel traditionele CMS’en waarvoor het tijdrovend is om de servers in te richten en het CMS te installeren en configureren. Gelukkig zijn er inmiddels ook veel SaaS (Software as a Service) CMS’en waarvan het inrichten van de backend dankzij het gebruik van plug-and-play veel minder tijd kost. Daardoor konden we het grootste deel van onze tijd in de front-end investeren en zo de merkbeleving perfectioneren.

4.0 Planning

📅 07-03-2024

Nadat ik had gemerkt dat ik het overzicht over mijn project aan het verliezen was, leidde zelfreflectie me tot het besluit mijn aanpak te veranderen(zie vorige ingeleverde bewijslast voor 1e aanpak)

Op aanraden van Motker, wiens projectboard effectief bleek volgens Justus, heb ik zijn projectbord als voorbeeld gebruikt om mijn overzicht te herstellen. Door dit te doen, kon ik de taken die ik te abstract vond - zoals de punten geschat door Planning Poker - vervangen door een meer voor mij begrijpelijke methode. Ik koppelde uren aan elke taak, wat mij een helderheid gaf van wat haalbaar was binnen de tijd.

Ik heb alle taken herbekeken en ze ingericht volgens de development lifecycle. Ik heb specifieke taken gekoppeld aan elke webpagina om beter te begrijpen wat nodig was. Deze taken kwamen uit het prototype ontwerp.

Ik heb ook de MoSCoW-methode gebruikt om taken te prioriteren. Dit hielp mij om te focussen op de meest urgente taken eerst. Met een duidelijk overzicht van de uren die voor elke taak staan, heb ik een weekplanning gemaakt, met labels die aantonen wat er elke week moet gebeuren.

Voorstel opdrachtgever planning wijziging

Initieel was het plan om de volgende componenten te leveren:

  • Een Contentbeheersysteem (CMS)
  • Uitgebreide projectdocumentatie (Readme)
  • Een responsieve homepage
  • Een detailpagina voor tickets
  • Een boekingssysteem
  • Een chatbox
  • Een betalingsmethode
  • Een e-mailservice
  • Een kostenoverzicht voor CMS en hosting

Na het evalueren van de prioriteiten en de haalbaarheid binnen de gestelde tijd, heb ik de focus gelegd op het opleveren van de UI:

  • De Homepage**
  • Een ticketpagina**
  • Een detailpagina**
  • Een boekingssysteem**
  • Een 'Work with us'-pagina, misschien?**

Secundaire prioriteiten zijn:

  • Een giftcard-optie
  • Een chatbox
  • Een e-mailservice

Clone this wiki locally