“Onze huidige cmd-amsterdam.nl website zou het visitekaartje van onze opleiding moeten zijn. De website moet als voorbeeld dienen hoe wij op CMD digital interactive design zien, een uiting van onze ontwerpvisie. Een vertaling van onze inhoud, lesstof en vakken. Practice what you teach. En dat is nu niet het geval.”

Huidige situatie

• Standaard: opleidingspagina binnen de HvA-website

• Aanvullend: ‘corporate’ WordPress-site met een aangeschaft thema

• Studenten vinden het leuk om door deze laatste site heen te navigeren (hierna te noemen: ‘deze/huidige site’) en meer over CMD te weten te komen.

• Voor aanpassen van de site moet je ervaring hebben met WordPress

• Qua vormgeving en ontwerp gelimiteerd tot de componenten van een aangekocht thema

• De back-end is te verweven met de front-end wat het lastig maakt om onderdelen op lange termijn te vervangen.

• Vervuilde WP-content

Probleemstelling

• Deze site representeert de identiteit van CMD niet voldoende; een redesign is gevraagd

• Ook: deze site is eigenlijk ‘niet meer de bedoeling’ vanuit de HvA; ivm afwijkende huisstijl en daarbij behorende online middelen

Eisen nieuwe website

• Makkelijk te onderhouden door Mattijs

• Oogt visueel sterker dan de opleidingspagina en geeft meer mogelijkheden om CMD te presenteren

• Geen clash met de huisstijl/merkenstrategie van de HvA; geen officiële ‘corporate’ site.

• Aansluiting op de HvA-huisstijl waar mogelijk

• Bevat aanvullende digitale componenten op onze huidige huisstijl

• Technisch: voldoet aan performancestandaarden

• Technisch: voldoet aan a11y

• Technisch: open-source op GitHub

Visie

• Dient als visitekaartje van onze opleiding

• Representeert onze visie op digital interactive design

• Onderscheidt ons van de andere CMD’s

• Site van en door de CMD-community

• Laat talent zien van onze studenten, docenten en bedrijven binnen onze disciplines

Onderzoeksvraag

Hoe kunnen wij een online omgeving creëren die onze identiteit uitstraalt en laat zien wat wij doen, zonder dat dit een botsing met de HvA oplevert?

Data

Wat hebben we?

• De content van de huidige Wordpress-site (tekst-export, WordPress API)

• De pitch voor redesign van de site

• De CMD-huisstijlelementen

Concept 1: Digital Playground

Een organische plek waarbij we bijvoorbeeld een toolbox aanbieden met elementen uit onze CMD-beeldtaal. Hierin laten wij zien wat wij onder gebruiksvriendelijk ontwerpen ontstaan, waarbij rekening gehouden wordt met de laatste ontwikkeling van goede online producten. Kortgezegd: het is een CMS waarbij bezoekers van de site, zelf componenten samen kunnen stellen die bij CMD passen? Build-a-bear maar dan voor een website, zodat CMD kan zeggen ‘tja, technisch gezien dragen zo veel personen continu hieraan bij dat het geen official corporate website van onszelf is..’?

Onderdelen online toolbox

• Digitale bouwblokken uit onze CMD-huisstijl

• Blokken met content

• Fotografie

Interactie

• Hiermee nieuwe elementen maken voor deze omgeving

• Bijv; de pagina-templates

Eisen

• De site moet een aantal templates bevatten (zie pitch)

• De site moet een aantal features bevatten (zie pitch)

Doelgroep

• Docenten

• Studenten

• Aankomende studenten

• Iedereen die denkt het beter te kunnen

Concept 2: Design System (redesign)

Een gestructureerde redesign van de huidige CMD-site; digital focused (web)vertaling- en aanvulling van de huidige huisstijl en beeldtaal. Als we een gevarieerde set componenten maken, is elke gewenste pagina te bouwen.

Eisen

• Huidige huisstijl aanvullen.

  • Het ontwerpen van een meer digital focused (web) vertaling van de huisstijl.

• Heeft betere performance

• Voldoet aan a11y standaarden.

• Open-source codebase

• Co-creatie mogelijk

  • Biedt mogelijkheden om het bijdragen aan de site te verwerken in andere CMD-vakken

• Voegt content samen op een centrale URL

  • cmdmethods.nl cmd.amsterdam/methods

  • cmda.eu cmd.amsterdam/stages

  • eventbrite.nl cmd.amsterdam/events

  • flickr.com cmd.amsterdam/photos

• Bevat een custom pattern library ter aanvulling van de beeldtaal

  • Digitale componenten waaruit de website samengesteld wordt

(Headless CMS)

• De content van de CMD Amsterdam-website beschikbaar stellen door middel van een API. Studenten kunnen zelf projecten bouwen met onze content.

Templates

• Landingspagina’s voor bijv. Golden Dot Awards of DID Conference

• Homepage

• Tekstpagina

• Alumnipagina

• Eventspagina

• Studiegids

• Studentenwerk

• Curriculum

• ‘Nieuw’/blog

• Stagebank

• Tekst & resources

• Battery

Conclusie/aanpak?

We zoeken uit wat er gaat gebeuren met de content; vanuit WP nog steeds aangeleverd, of gaan we headless en designen we zelf een manier waarop de content gemanaged wordt?

We fixen dan eerst de set componenten vanuit de huisstijl, leggen daar een documentatie/database van aan en bouwen daar dan de pagina’s van op volgorde van prioriteit van de features/templates. Aanvulling van de huidige beeldtaal dmv web-based design is wenselijk; animaties and such, in ieder geval niet meer alleen print-based design.

Opmerkingen/vragen

• SSL ontbreekt bij de huidige WP-site..?

• Moet de nieuwe site nu vooral een passende oplossing zijn met inachtneming van de regel van de HvA, of mogen we wel gewoon ‘t uitgangspunt van ‘de huidige site redesignen’ puur als doel behouden?

• Oftewel; is het de bedoeling dat we wel echt wat doen met dat het geen official site meer mag zijn, maar eveneens wat doen met de ideas uit de pitch van vóór deze maatregel?

• Moeten we het overzicht van functionaliteiten binnen de huidige website (MOSCOW) behouden voor ‘t redesign?

Logic-first approach

Eerst de logica, dan de vormgeving: dat was ons uitgangspunt. (dit was een misstap in retrospectief, daar meer over in de conclusie). Dit maakte wel dat we sneller konden doorontwikkelen op die logica. We zijn zo snel mogelijk in het opzetten van een goede basis betreft workflow gedoken zodat we daar de rest van het project profijt van zouden hebben (bevordert de samenwerking, vermindert merge conflicts, etc).

Wij hebben hetzelfde gedaan met het opzetten van de server; wat er benodigd was voor het serveren van een nieuwe, snelle site, kon al opgezet worden voordat er verdere case-specifieke keuzes moesten worden gemaakt. Zoals; static site generator, deployment, etc.

Een Headless CMS

In de briefing werd al de suggestie opgeworpen om te migreren van het nu gebruikte WordPress naar een zogenoemde headless CMS. Hierbij kun je gebruik maken van losse externe modules die makkelijk inwisselbaar zijn. Dit is makkelijker voor studenten en docenten om code te schrijven voor alleen de front-end zonder iets van een CMS af te weten.

Wat is headless?

Headless (of serverless / JAMStack) houdt in dat je front-end van een website theoretisch loskoppelt van bijvoorbeeld het CMS en communiceert met zo'n CMS middels een API in plaats van dat de website direct gekoppeld is aan het CMS en het CMS (de server) zelf de pagina's serveert.

Als je meer informatie wilt over wat Headless precies inhoudt kan je kijken naar de Headless CMS-pagina.

Waarom headless?

We hebben voor een headless opzet gekozen om de volgende redenen: (ook te vinden op JAMStack.org).

Betere performance

Niets is sneller dan het serveren van statische bestanden vanaf een CDN (Content Delivery Network) zoals ook de website JAMStack.org zelf zegt. Daarnaast is dit ook iets wat Declan tijdens de minor aankaartte. Aangezien CMD ons inziens staat voor performant, accessible en progressively enhanced websites is dit iets wat heel zwaar woog in onze beslissing.

Goedkoop en eenvoudiger op te schalen

Het hosten van een headless website kan vaak gratis, het enige wat je hoeft aan te schaffen is een domeinnaam, vervolgens kan je de website (aangezien het uiteindelijk allemaal statische bestanden zijn) via een CDN als Netlify of Vercel hosten in plaats van dit te moeten doen op een dedicated server.

Betere developer-ervaring

Iedereen die aan het project werkt kan zich grotendeels focussen op puur de front-end code. Er is namelijk geen server die we zelf hoeven te onderhouden, ook hoeven we vrijwel geen server-side code te schrijven. Het enige dat we hoeven te schrijven zijn HTML, JavaScript en CSS bestanden. Dit maakt de drempel om aan de CMD-website te werken ook lager.

Nadeel van headless

Er zal een migratie van de content nodig zijn. Hierbij zou theoretisch gezien een koppeling gemaakt kunnen worden met WordPress, of de content geheel geëxporteerd kunnen worden en vervolgens geïmporteerd in het nieuwe CMS.

Bij de bespreking van onze debriefing werd daarentegen duidelijk dat de benodigde content op de (nieuwe) site, vrijwel parralel staat aan wat er nu op de live website te zien is. What you see is what you get. Het leek ons hierna eigenlijk niet een groot probleem om de content simpelweg handmatig over te nemen van de huidige site.

CMS-onderzoek

Uiteindelijk hebben we voor het Storyblok-CMS gekozen omdat deze volgens ons de beste user experience bood en alle functionaliteiten bevatte die wij nodig achtten. Een relatief veel kleinere cognitieve lading, veel te customizen, en de fijnste interface. Daarnaast beschikt het over een live preview, iets wat een enorme must was vanuit de opdrachtgever.

Gaandeweg merken wij ook op dat zij erg actief zijn betreft bugfixes en het uitrollen van nieuwe features, wat vertrouwen bood betreft toekomstbestendigheid. Er is nu al veel mogelijk, en dat wordt steeds meer.

Pattern Library

Verder zijn we tijdens dit onderzoek naar een geschikte CMS ook gestuit op het eventuele gebruik van specifieke Design Pattern Libraries. Hierbij ontwerp je componenten in isolatie (onafhankelijk van de gehele webapplicatie dus!) om ze vanaf daar als single source of truth te kunnen gebruiken voor het bouwen van je website.

Aangezien dit tijdens onze zoektocht naar een CMS naar boven kwam en het ons bij deze case vooral ook een handige tool leek voor het displayen van onze componenten, nemen we dit ook mee onder 'CMS-onderzoek'. Hierbij hebben wij de keuze gemaakt voor Storybook. Dit onderzoek is hier te vinden.

Een basis leggen voor de toekomst

Dit project is duidelijk niet 100% af maar dient eerder als een solide basis voor de toekomstige opzet van een CMD Digital Playground / website. Zoals een prototype in een Proof of Concept bedoeld is. We hebben het project zo opgezet dat er later door andere developers / studenten eenvoudig aan verder gewerkt kan worden.

Componenten bouwen

De Digital Playground is voornamelijk gericht op het makkelijk code-loos kunnen invoeren van content in het Storyblok-CMS. Hierin kunnen CMD studenten / -docenten nieuwe componenten aanmaken en/of de inhoud van bestaande componenten aanpassen.

De componenten kunnen stuk voor stuk ontworpen en gebouwd worden door mensen binnen CMD, mits de persoon in kwestie beschikt over enige kennis van HTML, CSS en JavaScript. Deze talen worden in de Propedeuse behandeld, wat dan ook een CMD-brede toegankelijkheid biedt voor het bijdragen. Dit maakt dat we niet alleen de volledige vrijheid hebben qua ontwerp maar ook qua accessibility, performance en progressive enhancement van de componenten.

Pagina's bouwen vanuit componenten

Vanuit de componenten, die studenten dus hebben gemaakt, kunnen pagina's opgebouwd worden. Dit is simpelweg een kwestie van het kiezen van componenten om op de pagina te tonen. De volgorde en inhoud van die componenten kunnen dan binnen de pagina aangepast worden. Ook bij het ontwerp van specifieke pagina's hebben we weer de volledige vrijheid qua ontwerp.

Live preview

Zoals eerder aangegeven in de exploratiefase beschikt Storyblok over een live preview-omgeving zodat een gebruiker direct kan zien welk effect de aanpassingen hebben die zij maken. Echter, gezien de opzet van de techniek was het lastig om dit goed werkend te krijgen.

Om wijzigingen te zien moet de website in zijn volledigheid opnieuw "gebuild" worden om toegang te hebben tot de nieuwe data, dit duurt zo'n dertig seconden. Dit betekent in onze huidige oplossing dat een gebruiker dus zo'n dertig seconden moet wachten totdat een wijziging zichtbaar is binnen de preview omgeving.

Omdat we tijdens het opzetten van deze website ervoor hebben gekozen om zo dicht mogelijk bij 'vanilla' JavaScript, HTML en CSS te blijven (omdat dit volgens ons de core van tech-CMD is) is het lastig om dit soort zaken binnen een tijdsbestek van vijf weken optimaal te laten werken. Wel hebben we hiervoor een oplossing beschikbaar, daarop komen we terug in de conclusie.

Fool-proof

We hebben geprobeerd om het CMS zo fool-proof mogelijk te maken. Het is dus niet zo dat als iemand gaat klooien in het CMS dat de hele website dan kapot gaat. Dit is ten eerste te danken aan de headless opzet en ten tweede aan dat we ook in de code voor hebben gezorgd dat een component expliciet toegevoegd moet worden aan de code voordat de website er gebruik van maakt.

Alles open source

De broncode van de website is publiek beschikbaar via GitHub. Dit maakt het enerzijds mogelijk dat studenten eenvoudig kunnen bijdragen aan de vormgeving en techniek van de website, anderzijds toont het de kwaliteit van CMD-studentenwerk.

Studenten werken eraan, er is precies te achterhalen wie wat gebouwd heeft en hoe zij dit hebben aangepakt. Externe partijen kunnen zo dus eenvoudig zien hoe vaardig de studenten van CMD Amsterdam zijn in hun vak, en wat de standaarden zijn die wij aangeleerd krijgen.

Ook kan het ervoor zorgen dat eventueel toekomstige CMD studenten warm gemaakt worden om bij ons te komen studeren omdat het ook een stukje transparantie toont over hoe wij te werk gaan.

Wat is headless?

De website is dus gebouwd op een moderne, headless stack die ook wel de JAMStack wordt genoemd. JAM staat voor Javascript, Api’s en Markup.

Javascript voor het ophalen van data en front-end interactiviteit, Api’s om de data vandaan te halen en te gebruiken voor het toevoegen van bepaalde functionaliteit en (statisch gegenereerde) Markup waaruit je pagina’s worden opgebouwd.

In plaats van dat je dus een pure server hebt waaraan de browser telkens vraagt “hoe ziet deze pagina eruit?” krijgt de CMD website in deze nieuwe opzet de benodigde data voor de pagina’s vooraf en laten we een static site generator de benodigde HTML files wegschrijven.

Javascript

Hoewel de website erg licht is voor wat betreft de hoeveelheid JavaScript die gebruikt wordt in de browser, gebruiken we het wel veel wanneer we data ergens voor nodig hebben (bijvoorbeeld om de data voor de pagina’s op te halen). JavaScript gebruik je in deze opzet dus voornamelijk om data ergens vandaan te halen of om een externe service te gebruiken.

API's

Api's gebruiken we in deze onder andere om data op te halen uit het CMS. Echter, we gebruiken ze ook (middels een serverless function) om bijvoorbeeld de data uit formulieren te verwerken. API's gebruik je in een headless opzet dus om data op te halen of om te praten met externe services (zie ook de codesnippets bij 'Content ophalen vanuit een headless CMS').

Markup

De data die je binnenhaalt moet natuurlijk ook getoond worden op de pagina. Dit is waar het markup gedeelte van pas komt. We hebben HTML templates gebouwd voor elk component. Elk component krijgt dan simpelweg een stukje data mee die je dan kan gebruiken binnen die template. In Nunjucks werkt dat als volgt:

<section>
    <h2>{{ data.title }}</h2>
    <p>{{ data.text }}</p>
    
    {% for article in data.articles %}
        <article>
            <h3>{{ article.title }}</h3>
            <p>{{ article.text }}</p>
        </article>
    {% endfor %}
</section>

Content verkrijgen vanuit een headless CMS

Omdat we dus een statische website hebben verkrijgen we allereerst alle content pre-build (hierover later meer). Voor het verkrijgen van de data maken we gebruik van de Storyblok API. We doen simpelweg een request naar de Storyblok API als volgt:

// Onze eigen storyblok-instance
require('dotenv-safe').config()
const StoryblokClient = require('storyblok-js-client')

const {
  ELEVENTY_ENV,
  STORYBLOK_PREVIEW_KEY,
  STORYBLOK_PUBLIC_KEY
} = process.env
const production = ELEVENTY_ENV === 'production'
const STORYBLOK_KEY = production ? STORYBLOK_PUBLIC_KEY : STORYBLOK_PREVIEW_KEY

module.exports = new StoryblokClient({
  accessToken: STORYBLOK_KEY,
  cache: {
    clear: 'auto',
    type: 'memory'
  }
})

// Het verkrijgen van data middels onze Storyblok instance
const getPagesData = require('../../../lib/get-pages-data')
const getNavigationData = require('../../../lib/get-navigation-data')
const Storyblok = require('../../lib/storyblok-instance')
const getEventsData = require('../../../lib/get-events-data')
const getFooterData = require('../../lib/get-footer-data')

module.exports = async () => {
  const env = process.env.ELEVENTY_ENV
  const version = env === 'production' ? 'published' : 'draft'

  const [pages, events] = await Promise.all([
    Storyblok.get('cdn/stories', { version }),
    Storyblok.get('cdn/stories', { starts_with: 'events', version })
  ])

  const { stories = [] } = pages.data

  return {
    navigation: getNavigationData(stories),
    footer: getFooterData(stories),
    stories: getPagesData(
      stories, 
      getEventsData(events.data.stories)
    ),
  }
}

“Een co-created visueel en technisch herontwerp van de publieke website van Communication and Multimedia Design (CMD) die voldoet aan de standaarden betreft vormgeving, interactie & techniek.”

De afgelopen weken hebben we gewerkt aan de CMD Digital Playground. We hebben hiervoor drie deliverables gemaakt:

1. Een nieuwe, statisch gegenereerde website wat als startpunt dient voor een nieuwe CMD website

2. Een ingericht headless CMS waarin studenten / docenten van CMD componenten en pagina's kunnen aanmaken

3. Een documentatie die dient als onboarding voor nieuwe collaborators (studenten / docenten) waarin uitgelegd staat hoe het CMS en de nieuwe website werkt

Omdat het visuele ontwerp nog volop in ontwikkeling is door design bureau GRRR hebben we ons in eerste instantie met name gefocust op de technische opzet van het project.

Er zijn, ondanks vijf weken hard werk dan ook nog wat losse eindjes. Zo werkt bijvoorbeeld de live preview ondanks een aantal pogingen nog niet naar behoren en blijkt het CMS voor een niet-technische docent nog een aardige wirwar te zijn.

In deze Design Rationale lees je over de verschillende stappen die wij hebben ondernomen om tot ons uiteindelijke concept te komen. We beginnen daarmee met de onderzoeksfase. We leggen je onder andere uit wat headless precies inhoudt en hoe we tot de keuze voor het CMS zijn gekomen.

Daarnaast gaan we dieper in op het concept en hoe dat in elkaar steekt en geven we een korte uitleg van de technische opzet van het project en onderbouwen we de keuzes die we hebben gemaakt. We sluiten af met een kleine conclusie / reflectie op het proces en de deliverables.

In overeenstemming met de opdrachtgever hebben wij besloten ons voor onze Proof of Concept te richten op het uitwerken van het template voor een evenementenpagina.

CMD organiseert jaarlijks standaard een aantal interessante evenementen die voor zowel intern- als externen interessant zijn om bij te wonen. Met de komst van de CMDA Community worden dat er steeds meer. Tot op heden was er nog geen pagina met een overzicht van zulke evenementen.

Wij hebben onderzoek gedaan naar de huidige opbouw van evenementpagina's en diens benodigde informatievoorziening en we zijn hierbij tot de conclusie gekomen dat de pagina('s) minimaal de volgende componenten en functionaliteiten zal moeten (kunnen) bevatten:

Op de website

• Actueel evenementenoverzicht (titel, datum, locatie, preview)

• Detailpagina

  • Aanmeldformulier/(link naar)ticketverkoop

  • Datum/tijd

  • Titel + tekstveld

  • Afbeelding (banner)

In het CMS

• Archief van afgelopen evenementen

• Standaardtemplate voor het aanmaken van een nieuw evenement

Het hieraan voorafgaande onderzoek is hier te vinden.

Collaborators faciliteren

Om collaborators zo goed mogelijk te faciliteren hebben we een gebruikershandleiding bij de website geschreven. Deze gebruikershandleiding dient met name als een soort guide om nieuwe collaborators op weg te helpen binnen het CMS en onze codebase.

Opzet van de documentatie

De documentatie is grotendeels onderverdeeld in het volgende:

• Over het project Hierin staat wat algemene informatie over de website, hoe het is opgebouwd en hoe het tot stand is gekomen.

• How to's Hier kunnen de studenten / docenten / collaborators vinden hoe ze verschillende dingen moeten doen zoals het aanmaken van een pagina of component in het CMS of het werken met Nunjucks, de te gebruiken templating language.

• Guidelines Hierin staan wat coding guidelines en principes die iedereen op z'n gemak door kan lezen. Veel dingen worden advised en zijn niet in steen gegraveerd.

• API's Allerlei informatie over hoe te werken met (de Storyblok) API's.

• FAQ Veelgestelde vragen kunnen hier toegevoegd worden.

Werking van het CMS

Voor de werking van het CMS hebben we de documentatie geschreven per feature. Zo hebben we bijvoorbeeld behandeld hoe je een component moet aanmaken, hoe je een pagina moet aanmaken en hoe je content moet toevoegen aan Storyblok. Met name de 'how to'-pagina's staan ook vol met screenshots etc. om de boel nog duidelijker te maken.

In de toekomst willen we de documentatie hiervoor nog verder uitbreiden en verdelen in kleinere stukken omdat we tijdens de gesprekken met Danny en Mattijs merkten dat de documentatie soms als een heel groot boekwerk oogt en dat verhoogt de drempel voor nieuwe collaborators om te willen werken aan dit project.

Werken met de codebase

Ondanks dat we zo dicht mogelijk bij vanilla HTML, JavaScript en CSS zijn gebleven snappen we dat het voor nieuwe collaborators best lastig kan zijn om te werken aan een onbekende codebase. Daarom hebben we gekozen om ook daarvoor documentatie te schrijven.

Zo hebben we bijvoorbeeld een stuk geschreven over hoe je met de Storyblok API werkt en hoe je data kan ophalen. Ook hebben we in 'About the project' al uitgelegd wat headless is en hoe de website aan z'n content komt etc. zodat het voor nieuwe mensen minder magisch is hoe dit allemaal in elkaar zit.

De mappenstructuur binnen het project is als volgt:

De probleemdefinitie -en onze oplossing zijn van toepassing op een bepaalde gebruikersgroep, bestaande uit meerdere stakeholders. Wij zijn middels de debriefing en opvolgende gesprekken met de opdrachtgever tot de volgende stakeholders en bijkomende user stories gekomen.

Stakeholders

• Content creator (Mattijs, in dit geval)

• Developers (wij, of iemand als Danny)

• Collaborators (anderen die graag mee willen helpen aan de site/omgeving)

  • Andere content creator

  • Tech-savy studenten

• Informatie-inwinners

  • Huidige studenten

  • Aankomende studenten

  • Bedrijven

• CMD

• HvA

Content creator

Mattijs wil content online kunnen invoeren zonder al te veel poespas of complexiteit.

Mattijs organiseert de Golden Dot Awards 2020 en wil hiervoor een nieuwe pagina aanmaken. Hij opent de online editor, zoekt ‘t template voor GDA (of generic eventpagina) en vult vervolgens de informatie in de velden in. Publish!

Collaborators

De collaborators (CMD-studenten) ontwerpen iets voor de CMD-website en zetten dit ontwerp vervolgens om naar HTML/CSS (/JS). Een tech-focused eerstejaarsstudent wil bijdragen aan de CMD-website en zou graag een component hierbinnen willen verbeteren.

Mark is een eerstejaarsstudent die al best goed overweg kan met HTML, CSS en Javascript. Hij is erg betrokken bij de studie en wil dan ook graag bijdragen aan vanallesennogwat. Hij moest laatst iets opzoeken op de cmd-website en vond een bepaald blokje/component best wel lelijk. “Dit kan ik beter!” denkt hij, en geeft aan dit te willen redesignen.

Hij maakt een nieuw component aan in plain HTML/CSS/JavaScript en kan middels een pull request verzoeken tot implementatie van zijn ontwerp.

+ een design-focused CMD-student (/docent, etc.) wil ook bij kunnen dragen aan de CMD-website; dit kan in samenwerking met een ieder die dit ontwerp voor diegene in bovengenoemde talen kan realiseren. Deze skills behoren tot het curriculum in de Propedeuse en omvat dus een groot deel van onze studenten.

+ een niet design/tech-focused persoon wil een pagina aanmaken voor hun dingetje (evenement, initiatief, etc) --> content creator

Informatie-inwinners

Huidige student

Een CMD-student wil aan haar ouders laten zien en weten wat zij zoal doet op deze studie en wil hiervoor de website gebruiken als uitgangspunt.

Marlies is al de hele week hard bezig met werken aan haar deadlines en plots vraagt haar vader tijdens het eten wat zij nu eigenlijk ‘wordt’ met deze opleiding en waarom dit zo veel tijd kost. Ze vindt het wat lastig uit te leggen in twee zinnen en wil daarom wat van de eindprojecten van haar studiegenoten laten zien. Natuurlijk wil ze dat het cool overkomt en dat het duidelijk maakt waarvoor zij zo hard werkt, dus wil ze snel een overzicht hebben van het beste studentenwerk.

Aankomende student

Een aankomende student wil graag weten wat zij op CMD zal gaan leren, maken en als wat zij dan afstudeert.

Johan doet komende zomer examen en twijfelt nog tussen MIC en CMD.

Wat zijn de punten waarop hij zijn keuze zal baseren?

Bedrijven

Een bedrijf heeft interesse om een samenwerking te starten met CMD en wil middels de website snel een indruk krijgen van hoe en wie wij zijn.

Op een conferentie raakt de eigenaar van een Digital Agency aan de praat met één van onze docenten. Het ziet ernaar uit dat er een mogelijkheid is voor een toffe samenwerking. Deze docent geeft zijn visitekaartje aan diegene mee, waarop onder andere de CMD-site aangegeven staat. De eigenaar neemt een kijkje om een indruk te krijgen van hoe wij onszelf als opleiding zien, wat onze visie is en of dat een beetje overeenkomt met zíjn visie.

CMD

Harry (opleidingsmanager)

Harry wil dat de nieuwe website er niet voor zorgt dat CMD op onnodig hoge kosten wordt gejaagd.

Harry investeert graag in kwalitatief onderwijs. Hieronder valt ook de informatievoorziening vanuit de opleiding richting studenten, aankomende studenten, werknemers en externen (zoals bedrijven uit het vakgebied). Een nieuwe website klinkt zeer goed, maar aangezien we momenteel een gratis CMS gebruiken zou een verbeterde versie geen berg geld hoeven kosten, toch? Anders kunnen we dat geld ook prima gebruiken voor andere onderwijsdoeleinden.

HvA

Hogeschool van Amsterdam

De HvA wil dat CMD niet een geheel ander pad bewandelt in hoe zij zich etaleert, en eist dat de ‘voordeur’ van de CMD-website aantoonbaar binnen de HvA-huisstijl past.

De HvA vindt onze eigen identiteit niet zo tof samengaan onder ‘t kopje ‘HvA’. Te veel opleidingen geven hun eigen draai aan hoe zij zichzelf profileren en het loopt dusdanig uiteen dat het de gemeenschappelijke HvA wat achterstelt. Bij een redesign door ons zou dan ook (achteraf) een nieuwe styleguide geïmplementeerd moeten kunnen worden waarin deze unison gerealiseerd is.

Hoofddoelen

De hoofddoelen lijken dus als volgt te zijn:

• Editors willen content kunnen toevoegen

  • en de pagina wat kunnen tweaken op ‘top-level’ (blokken bouwen)

• Developers willen een customizable omgeving

• Gebruikers willen informatie inwinnen over CMD

Doel 1: Eventpagina-template bouwen

Subgoal 1: Iemand zonder tech-achtergrond (Mattijs!) kan met dat template, de pagina van de Golden Dot Awards maken

Subgoal 2: Iemand met tech-achtergrond (Joost/Koop) kan ook nog los gaan op die pagina/losse componenten

Persona’s

(created by CMD Amsterdam)

Huidige situatie

We begrijpen dat het project zoals het nu is niet direct live zou kunnen omdat het simpelweg niet een website is die 100% af is. Het project fungeert dan ook vooral als een Proof of Concept om de mogelijkheden van dit CMS te exploreren.

Ook zijn er nog een aantal losse eindjes binnen de keuze voor het CMS en binnen het gekozen CMS. Zo bleek tijdens de user test dat zodra iemand zonder enige voorkennis en technische know-how in het CMS begint te wroeten dat het nog aardig lastig is om te snappen wat er allemaal gebeurt.

Hoewel de documentatie dit deels dient op te lossen hadden we achteraf gezien wellicht de drie onderzochte CMS'en parallel aan elkaar moeten inrichten en meer moeten testen. Wellicht dat we dan wel tot een nog betere keuze waren gekomen voor wat betreft het CMS.

Echter, we denken niet dat dit haalbaar was geweest zonder op de rest van het concept in te leveren.

Een ander dingetje is de werking van de live preview omgeving binnen Storyblok. Door de keuze om een statische website te bouwen die zo dicht mogelijk bij vanilla HTML, CSS en JavaScript ligt bleek het lastig om de preview omgeving ideaal te laten werken.

Ons testpersoon gaf zelfs aan in de test dat het zou helpen als je live feedback zou krijgen van de live preview die zichtbaar is terwijl je de pagina aan het editen bent, omdat je dan precies weet wat je aan het aanpassen bent.

Echter, om dat te bewerkstelligen binnen dezelfde tijd zouden we ofwel een server-side gerenderde website moeten bouwen of snel naar een JavaScript framework moeten grijpen.

We zijn vooralsnog niet van mening dat de negatieve kanten van de bovenstaande 'oplossingen' opwegen tegen de positieve kanten (het goed laten werken van de preview omgeving). De eerste ondermijnt het hele principe van een snelle website bestaande uit enkel statische bestanden waar de tweede oplossing de drempel voor nieuwe developers zou verhogen om aan de website te werken en afwijkt van 'de CMD-school'.

Huidige performance/accessibility

Ons advies

Storyblok biedt momenteel veel functionaliteiten en mogelijkheden qua customization, maar niet alles verloopt nog geheel vlekkeloos. Gelukkig zien wij dat zij zeer actief bezig zijn met dit te verbeteren, waardoor dit best een toekomstbestendige keuze zou kunnen zijn. Er zijn ook nog veel functionaliteiten die wij niet in zijn geheel uit hebben kunnen testen aangezien wij op een 'free plan' hebben moeten werken.

Wij raden aan om allereerst een beslissing te maken betreft de live preview (WYSIWYG);

• Een framework als Vue gebruiken, waar Storyblok ook veel andere mogelijkheden bij biedt

  • Voordeel: meer mogelijkheden, betere reload

  • Nadeel: geen vanilla

• Of: een aparte staging-omgeving ontwikkelen waarbij je said framework alleen daarvoor gebruikt

  • Voordeel: behoud van snelheid van de website

  • Nadeel: bijhouden van twee verschillende codebases

• Een server-site gerenderde website bouwen in plaats van het serveren van een statische site

  • Voordeel: live preview werkt

  • Nadeel: minder snelle site

Vanuit deze keuze is ons advies om allereerst met de gebruiker te testen of het CMS dan wat gebruiksvriendelijker is en van daaruit verdere uit die test gebleken 'minpuntjes' aan te pakken. Voor nu is namelijk de grootste blokkade de custom live preview geweest.

Storyblok (CMS)

We gebruiken Storyblok als headless CMS. Na ons onderzoek hebben we besloten dat van de drie geteste CMS'en Storyblok beschikt over de meest gebruiksvriendelijke interface.

Daarnaast was het hebben van een live preview een grote must vanuit de opdrachtgever dus dat woog zwaar mee in onze beslissing om uiteindelijk te kiezen voor Storyblok. Voor de developers scheelt het dat integratie met Storyblok eenvoudig is op te zetten zoals eerder te lezen is in het Headless CMS hoofdstuk.

Eleventy (static site generator)

We gebruiken Eleventy als static site generator. Eleventy zorgt er dus voor dat we vanuit HTML (Nunjucks) templates pagina's kunnen opbouwen. De reden dat we Eleventy gebruiken is omdat we enerzijds niet de tijd hadden om zelf een static site generator te bouwen en anderzijds dat we zo dicht als mogelijk wilde blijven bij vanilla JavaScript, HTML en CSS en dit biedt Eleventy dan ook.

De reden dat we 't dichtst bij vanilla wilde blijven is dat dit het eenvoudiger maakt voor andere CMD studenten / docenten om verder te werken aan dit project door bijvoorbeeld componenten te kunnen bouwen.

Als we gebruik zouden maken van bijvoorbeeld Nuxt (Vue) of Next (React) dan zouden nieuwe collaborators eerst specifiek dat framework moeten leren voordat ze aan de slag kunnen met het verder bouwen aan de playground.

Ook forceert dit de developers een beetje om meer progressively enhanced te werken waar je anders eerder naar een JavaScript oplossing zou grijpen omdat dat een simpelere oplossing is binnen een JavaScript framework als Nuxt of Next.

Nunjucks (templating)

We gebruiken Nunjucks vooralsnog als templating language. Met name omdat dit zit ingebakken met Eleventy en het daar heel lekker mee werkt. Natuurlijk kan dit later nog omgezet worden naar iets als EJS bijvoorbeeld wat veel studenten tijdens de tech-track gebruiken.

Vercel (deployment)

De keuze voor Vercel in plaats van iets als Netlify is met name vanwege de integratie van serverless functions. De serverless functions van Vercel liggen wat dat betreft dichter bij een Express JS route (again, iets wat de studenten in de tech-track leren) in tegenstelling tot die van Netlify (zie onderstaande code snippets).

// Vercel serverless function
module.exports = (request, response) => {
  response.status(200)
  response.json({
    message: "Dit is een Vercel serverless function"
  })
}

// Netlify serverless function
exports.handler = async (event, context) => {
  return {
    statusCode: 200,
    body: {
      message: "Dit is een Netlify serverless function"
    }
  }
}

Ook is het gebruik van Vercel serverless functions ons inziens eenvoudiger qua mappenstructuur. Door simpelweg een `api` folder te plaatsen in de root van het project pakt Vercel dat direct op alszijnde serverless functions waar je met Netlify in de config file een pad moet aangeven naar die serverless functions en altijd moet fetchen naar /.netlify/functions/my-serverless-function waar je bij Vercel simpelweg een request kan sturen naar /api/my-serverless-function.

Verder delen Vercel en Netlify veel functionaliteiten zoals Continiuous Integration / Development en deploy previews (waardoor het eenvoudiger is te zien welke wijzigingen zijn aangebracht in een pull request).

Storybook (pattern library)

Als we uiteindelijk helemaal voluit willen gaan kunnen we er ook voor kiezen om alle gebruikte componenten beschikbaar te maken in Storybook. Storybook is een pattern library tool waar alle componenten geïsoleerd van elkaar ontwikkeld en getest kunnen worden.

Idealiter schrijven we voor nu een script waarmee onze nu geschreven component-templates post-build omgezet worden naar plain HTML, weggeschreven naar de Storybook-folder en er vervolgens met die data een Storybook-Pattern Library wordt gegenereerd. Dan fungeert Storybook als style guide en component library.

Wat nog beter zou zijn, is dit proces omdraaien; componenten worden aangemaakt in Storybook en fungeren als single source of truth. Zoals de library bedoeld is; 'pattern library first' designen en developen.

Dit hebben we tijdens dit project helaas niet actief kunnen doen vanwege een gebrek aan tijd. Dit zou er daarentegen wel voor kunnen zorgen dat we vanaf de basis altijd een soort bibliotheek hebben van de CMD-componenten ondanks dat misschien de hele website op de schop gaat. Die bibliotheek kunnen we dan ook afgezonderd delen met derde partijen, via iets als zeroheight nóg toffer displayen, serveren als een statische site en toevoegen aan de cmd-site zelf, etc.

Een beschrijving van de belangrijkste iteraties die we hebben doorgevoerd en uitkomsten. Wat leidde ertoe en wat was de uitkomst?

CMS (Storyblok)

• We hebben de folder structure gewijzigd (wat werkt het beste?) --> algemene layout van gehele pagina's in 'pages', navigatie in 'navigation' en de verdere content in aparte mappen (zoals: 'Events').

• We hebben de previewmodus gewijzigd

• We hebben 'preview templates' toegevoegd aan de componenten (waardoor je de content van een component in de visual editor kan zien)

• We hebben de user roles aangepast

• We hebben de filenames en componenten in het CMS vertaald naar het Nederlands

Styling

Layout homepage

Veelal from scratch wat placeholdertext gebruikt om de functionaliteiten mee te testen.

Dit hebben wij uiteraard wel rechtgetrokken na het applyen van de algehele styling.

Layout evenementenoverzichtspagina

Layout header

Layout evenementenpagina

Code iteraties

Het bouwen van een preview omgeving

Om aan content-editors te kunnen tonen welke aanpassingen ze aan het doen zijn is het handig om direct feedback te tonen (iets wat uiteindelijk ook terug kwam uit de user test, waarover je later meer kan lezen). In eerste instantie hadden we ervoor te kozen om hier veel te leunen op JavaScript zodat je dus live die aanpassingen kan tonen. Echter, dit maakte dat we elk component twee keer moesten bouwen als het ware, eenmaal in HTML/Nunjucks en eenmaal als Javascript component waardoor je de volgende situatie kreeg:

// src/assets/js/preview-environment/components/button.js
export default ({ _editable, text, type, link }) => {
  if (type === 'button') {
    return `
    <button class="button">
      ${text}
    </button>
  `
  } else {
    return `
    <a class="button" href="${link.url}">
      ${text}
    </a>
    `
  }

}

{% macro component(item) %}
  {% if item.type === "button" %}
    <button class="button">
      {{ item.text }}
    </button>

    {% else %}
    <a class="button" href="{{ item.link.url }}">
      {{ item.text }}
    </a>

  {% endif %}
{% endmacro %}

Hoewel dit maakte dat de preview omgeving inderdaad live kon updaten maakte het dat we de website als het ware moesten hijacken met JavaScript zodra het in de preview omgeving zit.

Dat is natuurlijk iets wat mogelijk is maar dit zorgt voor veel extra werk voor developers en dat is iets wat we willen vermijden om de drempel voor nieuwe developers laag te houden. Daarom hebben we besloten dat we met een andere oplossing moesten komen. Het eerste waar we op kwamen is het aanmaken van een aparte preview branch die dan vanuit het CMS te updaten is.

Echter, dit zorgde ervoor dat een content-editor bij elke aanpassing die hij of zij wilt zien vanuit de pagina waar die aan bezig is naar de tasks moet binnen het CMS, op 'deploy preview' moet klikken, 30 seconden moet wachten om vervolgens de pagina te refreshen. Dit zorgt voor de content-editor weer voor heel veel extra overhead. Onze laatste oplossing was dat we op de preview branch ervoor zorgden dat de preview branch wordt geüpdatet wanneer een content-editor op 'save' klikt. Ook komt er dan een melding in beeld en refresht de pagina na 30 seconden:

De opzet van modular content

Het modular-content component is misschien wel het belangrijkste component van de hele website. Hierin kunnen namelijk alle componenten ingeladen worden vanuit het CMS en weergegeven worden op een pagina. In eerste instantie hadden we een component gebouwd met veel ifjes in de layout om zo te kunnen bepalen welke elementen getoond worden (zie onderstaande snippet).

<!-- If-statements in de layout -->
{% from "components/test-component.html" import testComponent %}

{% macro modularContent(content) %}
  <div class="modular-content" id="modular-content">
    {% for item in content %}

    {% if item.component === "Test component" %}
      {{ testComponent(item) }}
    {% endif %}

    {% endfor %}
  </div>
{% endmacro %}

Als je weinig componenten hebt is dit nog overzichtelijk. Echter toen we meer componenten kregen liepen we er tegenaan dat het voor de developer onoverzichtelijk wordt met al die if-statements in de markup. Daarom heeft Gijs toentertijd een slimmere oplossing gebouwd waar elk component een soort slug mee kreeg van welke map het component in te vinden is. Hierdoor hoefden we in de markup alleen maar te loopen over de content en konden we de componenten dynamisch importeren en implementeren:

{% macro modularContent(content) %}
  <div class="modular-content" id="modular-content">
    {% for item in content %}

    {% if item._editable %}
    <!-- {{ item._editable }} -->
    {% endif %}

    {# site.js creates a slug from the component name. #}
    {% from "components/" + item.componentSlug + "/" + item.componentSlug + ".html" import component %}
    {{ component(item) }}
    {% endfor %}
  </div>
{% endmacro %}

Hoewel de bovenstaande oplossing voorkwam dat we allemaal if-statements in de markup hadden staan maakte het wel dat we elk component moesten behandelen als een macro die we dan altijd component moesten noemen, dit maakt dat je het nog duidelijker zou moeten documenteren.

Ook zorgde dit ervoor dat als iemand in Storyblok een component zou maken en implementeren in een pagina maar het HTML bestand niet bestaat binnen de codebase dat dan de build faalt, ook wanneer je slechts aan het developen bent. Dit zorgt ervoor dat de workflow stroperig wordt wanneer je met meerdere mensen tegelijk aan het ontwikkelen bent.

Uiteindelijk hebben we daarom gekozen om terug te gaan naar de if-statements oplossing omdat we toch vonden dat dit de meest duidelijke manier is om de componenten te implementeren zonder dat er veel 'magie' under the hood gebeurt, het ziet er nu als volgt uit:

{% macro modularContent(content) %}
  <div class="modular-content" id="modular-content">
    {% for item in content %}

    {% if item._editable %}
    <!-- {{ item._editable }} -->
    {% endif %}

    {% if item.componentSlug === 'events' %}
      {% from 'components/events/events.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'hero-header' %}
      {% from 'components/hero-header/hero-header.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'image-text' %}
      {% from 'components/image-text/image-text.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'form' %}
      {% from 'components/form/form.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'button' %}
      {% from 'components/button/button.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'latest-events' %}
      {% include('components/latest-events/latest-events.html') %}
    {% endif %}

    {% if item.componentSlug === 'assessment_elements' %}
      {% from 'components/assessment_elements/assessment_elements.html' import component %}
      {{ component(item) }}
    {% endif %}

    {% if item.componentSlug === 'description_list' %}
      {% from 'components/description_list/description_list.html' import component %}
      {{ component(item) }}
    {% endif %}


    {% endfor %}
  </div>
{% endmacro %}

Dit maakt dat we niet alleen macro's hoeven te gebruiken maar dat we ook componenten kunnen 'includen', dit is eveneens iets waar we tegenaan liepen met de vorige oplossing.