Reflectie Tristan - TristanVarewijck/oba-junior-chatbot Wiki

Op deze pagina ga ik vertellen welke vakken ik heb toegepast bij het maken van De meesterproef. Ik ga uitleggen wat het is wat ik in deze vakken heb geleerd en waarom ik bepaalde stof wel en niet heb toegepast.

Het project

Het project De meesterproef is het maken van een app met als doelgroep kinderen van 6/7 jaar. Op de app moeten de gebruikers op een gebruiksvriendelijke manier boeken kunnen zoeken. Het project is aangeboden door de OBA en functioneert als update of andere versie van de huidige OBA-junior website.

CSS to the resque

Los van dat ik CSS to the resque zelf nog niet gehaald heb, heb ik wel nieuwe css technieken toegepast ik heb namelijk Sass (scss) gebruikt voor de css. Ik ben er achter gekomen dat dit super handig is, omdat je met scss gebruik kan maken nesting waardoor je niet veel code meer hoeft te kopiëren. Ook heb ik custom-properties gebruikt wat ik geleerd heb bij 'css to the resque' en daarnaast heb ik nog gekeken naar mix-ins en include wat handige functies zijn binnen Sass (scss). Je kan hierdoor namelijk partials maken binnen je css bijvoorbeeld van het maken van een vaste list values die je vaker gebruikt over je pagina zoals hieronder;

@mixin reset-list {
  margin: 0; 
list-style-type: none; 
padding: 0;
}

@mixin vertical-list{
@include reset-list; 
display: flex; 
justify-content: space-between; 

li{
 display: inline-block;
    margin: 2em;
}
}

nav ul {
@include vertical-list; 
}

Real-time web

Het vak real-time-web is bijna niet toegepast, maar dat komt puur, omdat dit vak niet goed terug kwam in onze case we hebben namelijk geen multi-user experience en handelen ook geen data real-time dit doen we niet omdat dit niet nodig was om dit project succesvol te laten slagen. Daarnaast hebben we wel een goede data management, doordat we de data apart schoonmaken in modules en weer terug sturen als de data opgeschoont is. Hiermee bedoel ik dat lege tabellen zijn opgevuld en dat de data die we niet nodig hebben eruit wordt gefiltered.

Hieronder zie je dat we eerst de keys pakken die we gaan gebruiken en dat de functie ervoor zorgt dat als een key niet bestaat in een data tabel dat hij vervangen wordt door een ander teken dit doen we zodat er geen errors onstaan bij het ophalen, eigenlijk is de API een beetje slordig in elkaar gezet waardoor we dit moesten doen.

Als laatst returnen we een nieuw data object die nu opgeschoonde waardes vasthoudt.

const dataParser = (data) => {
  const cleanedData = data.map((result) => {
    const myKeys = [
      "summaries",
      "year",
      "titles",
      "authors",
      "id",
      "coverimages",
      "genres",
      "detailLink",
    ];

    // check if a key is absent or not
    myKeys.forEach((key) => {
      key in result ? result[key] : (result[key] = ["-"]);
    });

    return {
      title: result.titles[0],
      summary: result.summaries[0],
      year: result.year,
      img: result.coverimages[1],
      id: result.id,
      authors: addSpaces(result.authors.toString()),
      genres: addSpaces(result.genres.toString()),
      link: result.detailLink,
    };
  });
};

function addSpaces(authors) {
  const fixedSpacing = authors.replaceAll(",", ", ");
  return fixedSpacing;
}

Human Centered Design

Het vak Human Centered Design hebben we veel toegepast niet in de zin dat het specifiek voor 1 persoon was, maar wel voor een hele specifieke doelgroep, namelijk kinderen van 6/7 jaar. We hebben daarom ook voordat we zijn begonnen met het concept bedenken flink onderzoek gedaan naar het gedrag van kinderen en hoe zij deze tijd met digitale technieken omgaan, ook hebben we op de markt gekeken naar wat er op dit moment voor kinderen is en hoe deze producten eruit zien en het belangrijkste waarom ze er zo uit zien. Na dit onderzoek zijn we pas echt begonnen met het onderwerpen van een concept.

Daarbij hebben we ook meerdere keren gestest met in totaal 6 kinderen dit was handig, omdat we bij de eerste test erachter kwamen dat het nog niet helemaal lekker werkte met de mascotte de kinderen kregen niet echt een band ermee maar bij de tweede test ging het eigenlijk al heel goed. Als we niet getest hadden dan zaten we nog steeds met een product dat misschien niet helemaal aansloot.

Als verbeterpunt zou ik zeggen dat we misschien meerdere user-scenarios hadden moeten uitschrijven maar door de drukte hebben we dit helaas over ons hoofd gezien.

Browser technologies

Het vak browser technologies is niet echt veel terugkomen bij de meesterproef we zijn er namelijk achtergekomen dat OBA gewoon Safari of Chrome gebruikt wat goed gesupporte browsers zijn ook weten we dat als oba een kinder platform maken zoals die van ons dat ze er waarschijnlijk een vaste desktop app van maken (net zoals de tablet bij de Macdonald). Naast dat browser technologies niet echt terug kwam in de meesterproef hebben we wel ervoor gezorgd dat er meerdere @supports zijn voor verschillende CSS properties die niet cross-browser zijn. Ook hebben we een library gebruikt voor het maken van Carroussels wanneer deze library uitvalt dan schakelt het over naar een flex-box slider waardoor je dus geen JS nodig hebt om nog steeds een caroussel gevoel te geven.

Ook hebben we (bijna) alle animaties met CSS @keyframes gemaakt dit met de gedachte dat we alles zoveel mogelijk met CSS wilde doen zodat wanneer Javascript mocht uitvallen het er nog steeds aantrekkelijk uitziet voor de kids.

Hieronder zie je een klein voorbeeld van hoe we browser technologies hebben gebruikt.

@supports not (display: grid) {
  .grid-layout {
    float: right;
  }
}

@supports not (box-shadow: 0px 4px 18px rgba(169, 169, 169, 0.15)) {
  .grid-layout section {
    box-shadow: none;
    border: solid 1px lightGray; 
  }
}

// _noScript_ wanneer er geen javascript is verander de section dan in een flex-box slider. 

<noscript>
.caroussel{
display: flex; 
flex-wrap: no-wrap; 
justify-content: space-evenly; 
}
</noscript>

Web-app from Scratch

Het vak web-app from scratch is eigenlijk de basis van de applicatie alles wat we geleerd hebben uit dit vak is toegepast er is vanilla js html en css geschreven, Daarnaast is er gebruikt gemaakt van een externe API en een user-interface gebouwd op wens van de doelgroep en klant. Behalve dat het vak web-app- from scratch client-side gebaseerd is hebben wij onze routes / data management op de server draaien dit werkt beter en heeft een lagere workload voor de browser. Omdat als je alles client-side zou renderen dan kan de app zwaarder worden voor de browser daarnaast is het ook geen goeie use-case om dat op die manier te doen.

Dat we bepaalde onderdelen op de server hebben staan komt uit het van progressive web-apps wat ik in het volgende punt verder toe zal lichten.

Hieronder zie je bijvoorbeeld een stukje vanilla client-side JavaScript het staat op de client, omdat dit echt een front-end functie is en niet echt afhankelijk van de route waarin het zich bevindt.

window.addEventListener("load", (event) => {
  setTimeout(function () {
    var mascotte = document.querySelector(".mascotte");

    if (mascotte.src === "http://localhost:3500/assets/images/Lion.png") {
      var snurk = new Audio("/assets/audio/snurken.mp3");
      snurk.play();
      mascotte.src = "/assets/images/slaapleeuw.gif";
      setTimeout(function () {
        mascotte.src = "/assets/images/Lion.png";
      }, 8000);
    } else {
    }
  }, 10000);
});

document.querySelector("#chatbotbtn").addEventListener("click", () => {
  document
    .querySelector(".chatbot-container")
    .classList.add("animation-containter");

  document.querySelector("#chatbotbtn").classList.add("animate-mascotte");

  setTimeout(function () {
    window.location.href = "/search";
  }, 2000);
});

Progressive web-apps

Het vak progressive-web-apps komt naar voren op de manier dat we server-side en client-side renderen we houden bepaalde functies voor de ene kant en de andere kant. Functies zoals die iets animeren draaien op de client omdat dit puur front-end is, maar functies die worden aangeroepen op een bepaalde "route" die draaien we op de server. Daarnaast hebben we ook een bescheiden server-worker die de styling cached en een offline pagina, zodat wanneer er geen internet is de gebruiker toch nog iets kan zien van de app.

Vooruit kijkend zouden we iets meer kunnen doen met de service-worker en daarmee een uitgebreide offline experience meegeven.

Hieronder zie je de service-worker die we hebben toegepast en zie je de mappen structuur zodat je een beeld krijgt hoe we bepaalde files apart houden van server en client.

File structure:

Service-worker:

const staticCacheName = "site-static-v5";
const assets = [
  "/css/index.css",
  "/html/offline.html"
];

self.addEventListener("install", (evt) => {
  evt.waitUntil(
    caches.open(staticCacheName).then((cache) => {
      cache.addAll(assets);
    })
  );
});
self.addEventListener("activate", (evt) => {
  evt.waitUntil(
    caches.keys().then((keys) => {
      return Promise.all(
        keys
          .filter((key) => key !== staticCacheName)
          .map((key) => caches.delete(key))
      );
    })
  );
});

self.addEventListener("fetch", (evt) => {
  evt.respondWith(
    caches.match(evt.request).then((cacheRes) => {
      return (
        cacheRes ||
        fetch(evt.request)
          .catch(() => caches.match("/html/offline.html"))
      );
    })
  );
});

Conclusie

Mijn conclusie op de meesterproef is dat het een goede ervaring was en dat ik zeker heb geleerd dat de klant veel aandachts van je vereist dat was soms wel lastig. Wat ik jammer vond aan De meesterproef dat er veel dingen aan de zijkant bij kwamen kijken zoals de code en design reviews en dan ook nog elke week een uitje naar een stagebedrijf ik vind dit best vermoeiend aangezien ik gewoon wil coderen en iets vets wil maken. Daarnaast was de meesterproef erg leerzaam doordat je moet werken met een klant en je eigenlijk je keuzes baseert op hun feedback. Ook was de case leuker dan verwacht dus in het algemeen een goede ervaring!

⚠️ **GitHub.com Fallback** ⚠️