Design rationale
- debriefing
- probleemdefinitie
- getoonde oplossing voor probleem
- uitleg code
- Wat is de huisstijl? Zijn er bestaande materialen? (Zoals logo’s of foto’s)
- Verwachten jullie een redesign of een compleet nieuwe website. En moet de content hetzelfde blijven als op de oude website?
- Moet de website live geüpdatet worden? (denken aan de live stream of live data ophalen).
- Hoe krijgen wij toegang tot de API? Hebben wij API-keys nodig of is het open-source? Is er meer data beschikbaar?
- Kunnen jullie wat context geven bij de data en de values hiervan?
- Wie is de doelgroep?
- Wat willen jullie dat de doelgroep doet of voelt?
- Wat willen jullie uiteindelijk bereiken?
- Wat vinden jullie het belangrijkst?
- Hoe ziet een succesvol eindresultaat eruit voor jullie?
- Zijn er voorbeelden die jullie aanspreken?
- Wanneer willen jullie de feedbackmomenten inplannen?
- Zijn er vaste contactmomenten?
- Wie is ons aanspreekpunt?
- Doen we de meetings online, in Amsterdam of in Utrecht? Of wisselen we dit af, afhankelijk van beschikbaarheid?
- Hoe nemen we het snelst contact met jullie op? (Teams, Whatsapp, mail?)
De opdrachtgever voor de Visdeurbel is een project van de gemeente Utrecht, Hoogheemraadschap De Stichtse Rijnlanden (HDSR) en Mark van Heukelum van Dutch Wall Fish. Gemeente Utrecht en en HDSR zorgen voor het beheer en de kwaliteit van het water in de Vecht, de Kromme Rijn en de Utrechtse grachten.
- Contactpersonen: Peter Stekelenburg en Paul van de Kant
- Bereikbaarheid: info@studiomoan.nl
- Contactmomenten: De meetings vinden fysiek plaats bij Studio Moan in Utrecht.
De opdrachtgever wil voor de visdeurbel verschillende data visualisaties van de verworven data zien, bij voorkeur als one-pager. De pagina wordt dan geïntegreerd in de bestaande website. De website moet volledig toegankelijk zijn volgens de WCAG richtlijnen (WCAG A compliance). Ook wordt de website vanuit de hele wereld bezocht, daarom moeten we ook nadenken over performance. De website moet natuurlijk ook volledig responsive zijn.
Ieder voorjaar zwemmen er duizenden vissen dwars door de grachten en singels van Utrecht Naar de Kromme Rijn, op zoek naar een plek om zich voort te planten. Visdeurbel.nl laat mensen live meekijken bij de sluis en vissen helpen door op een digitale bel te drukken. Wat begon als speels experiment, groeide razendsnel uit tot een publieksfavoriet met miljoenen bezoekers. De visdeurbel in Utrecht trekt elk jaar miljoenen kijkers, dit jaar hebben ze data verzameld bij elke druk op de deurbel. Aan het einde van het visdeurbel seizoen (dat loopt van maart tot en met 1 juli) willen ze met de verzamelde data meerdere data visualisaties maken.
Hoe kunnen we met de verzamelde data van de Visdeurbel een zo leuk en goed mogelijk beeld geven van de staat van de Utrechtse wateren en hoe de Visdeurbel dit jaar is gebruikt?
- Als trouwe kijker van de Visdeurbel wil ik zien hoe anderen, en ik, de Visdeurbel hebben gebruikt, zodat ik kan nagenieten van het Visdeurbel seizoen.
- Als gemeente Utrecht wil ik laten zien hoe populair de Visdeurbel is, zodat we kunnen laten zien hoe met behulp van de Visdeurbel Utrecht op de kaart wordt gezet.
- Als ecoloog wil ik interessante data over de vissen laten zien, zodat mensen meer leren over de vissen in de Utrechtse wateren.
Wij als team hebben interesse in design, front-end development en datavisualisatie. Zo hebben Mats en Rafi al eerder de minor ‘datavisualisation’ gevolgd aan de Hogeschool Van Amsterdam. Hierdoor kunnen wij zowel de technische als de visuele kant van het project ontwikkelen. Diego heeft een eerder project gevolgd waar hij data moest verwerken op de front-end. Daarnaast werken wij volgens een georganiseerde aanpak en met strakke afspraken.
Door onze interesse in gebruiksvriendelijkheid en storytelling willen wij data niet alleen correct weergeven, maar ook begrijpelijk en aantrekkelijk maken voor een breed publiek.
Wij als team ontwikkelen een interactieve webpagina waarop de verschillende data van de Visdeurbel op verschillende manieren visueel wordt weergegeven aan de hand van datavisualisaties in de huisstijl van de Visdeurbel.
Dit kan zijn:
- Interactieve datavisualisaties
- Mooie vormgegeven charts met een echte Visdeurbel stijl.
- Responsive en toegankelijke visualisaties.
Tijdens het project wordt verder onderzocht welke visualisaties relevant zijn voor de opdrachtgever.
De visualisaties worden ontwikkeld met HTML, CSS, JavaScript en D3.js. Hierbij werken wij modulair en houden wij rekening met performance, responsiveness en toegankelijkheid.
- De visualisaties worden ontwikkeld voor gebruik binnen een webomgeving.
- Toegankelijkheid en responsive design worden meegenomen binnen het ontwerp- en ontwikkelproces.
- De opdrachtgever levert alle benodigdheden aan, zoals data en content.
- De visualisaties moeten begrijpelijk zijn voor zowel technische als niet-technische gebruikers.
- Er moet echte data worden gebruikt binnen de website, geen statische vormen of foto’s om de data te weergeven.
- De webpagina moet de huisstijl aanhouden zonder uitzonderingen.
- We schrijven duidelijke, leesbare code.
- Namen zijn Engelstalig.
- Comments leggen uit waarom iets gebeurt, alleen bij lastige code ook WAT er gebeurt.
- Geen ongebruikte code of console.logs in de 'main.'
assets
js/
style/
- Bestanden: kebab-case.js
- Functies: camelCase
- Constants: UPPER_SNAKE_CASE
Voorbeelden:
const MAX_VISIBLE_FISH = 10;
function formatCountryName(countryCode) {}
class FishTimeline {}
- Gebruikt const, tenzij de waarde verandert.
- Gebruikt let alleen wanneer nodig
- Geen var
- Gebruik duidelijke functienamen
- Houd functies klein en specifiek
Iedereen werkt in zijn eigen branch en we mergen uiteindelijk alles naar de dev-branch.
De naam van je branch moet direct vertellen wat voor soort werk je doet en waar het over gaat.
Toegestane types voor branches
Je kan het typen als type/korte-beschrijving.
Types waar je uit kan kiezen:
-
feat/: Dit gebruik je voor branches waar je een nieuwe feature in maakt. -
bugfix/: Dit gebruik je als je een stuk bestaande code moet fixen. -
docs/: Dit gebruik je als je wijzigingen gaat maken in de README of andere documentatie
Regels voor branches
- Gebruik uitsluitend kleine lettertype
- gebruik ' - ' i.p.v. spaties
- Typ branch namen uitsluitend in het Engels
- Data eerst opschonen voordat je visualiseert.
- Elke chart moet passen bij de huisstijl.
- Mobile-first design
- Gebruik CSS custom properties
- Geen inline styling tenzij dit echt moet
- Elke visualisatie krijgt een titel en tekstuele samenvatting.
- Interactieve onderdelen zijn met toetsenbord te gebruiken.
- Kleur is niet de enige manier om informatie over te brengen.
- Afbeeldingen krijgen goede alt-tekst.
- Respecteer prefers-reduced-motion.
- Alleen noodzakelijke libraries gebruiken.
- Grote datasets eerst aggregeren.
- Geen onnodige re-renders.
- Afbeeldingen lazy-loaden.
Gebruik korte, maar duidelijke commit messages, zoals:
feat: add timeline chart
fix: correct date parsing
docs: add code conventions
style: update chart spacing
refactor: simplify CSV parser
Elke PR bevat:
- Korte beschrijving.
- Eventueel screenshot bij visuele wijzigingen.
- Eventuele issues
- Minimaal één teamlid reviewt.
- Feedback concreet en vriendelijk :)
- Grote aanpassingen altijd eerst bespreken.
We hebben de eerste week de test uitgevoerd met Cyd Stumpel, omdat collega's van Studio Moan nog op vakantie waren. Uit deze test hebben we alsnog veel nuttige feedback en aandachtspunten gekregen waarop wij ons de vervolgweek op kunnen richten.
- Bereidt je test goed voor met vragen, debriefing laten zien en vertellen wat iedereen gaat doen. En maak een presentatie met je planning
- Nog goed kijken naar wat er eigenlijk in de debriefing staat. Voorbereiding en vragen debriefing mag in een apart document. "Nieuwe functies" mag anders verwoord worden
- Header gewoon weg laten en logo laten staan header past op dit moment ook niet
- Als je een framework gebruikt kan je simpel een component maken en die hergebruiken Wijk vooral af van het design
- code aanleveren op Github - met uitleg van elke sectie, of toegankelijkheid hebt getest
- blauwe kleur mag gebruikt worden, maar hou het subtiel
- Header emoji van land-vlag werkt niet op windows
- Vis van seizoen ontwerp komt direct uit design, andere manier zou veel interessanter zijn
- Leuke scroll animatie
- De text alignment klopt niet
- Het lijkt nu op allebei de charts
- Gebruik anchor positioning voor de popup
- Maak van elke bar chart een button of iets dat accessibility-proof is
- Het is niet duidelijk wat de Y as van de chart betekent
- Foto's worden op de hand uitgekozen
- Let bij een label op toegankelijkheid
- gebruik ook een vervangende naam voor elke vis
- Een soort Spotify wrapped is wel een leuk alternatief idee
Uit de eerste test met Cyd bleek dat we nog te veel aan het ontwerpen zijn volgens de originele website. Het was van belang dat we nog bij elke sectie even terug keken naar het idee en ontwerp om nog met iets te komen dat nieuwer en origineler is. Ook mochten we beter ons best doen om het te presenteren, we hadden geen power point voorbereid en er zat geen duidelijke structuur in ons verhaal. Verder waren we wel erg goed op weg in de back-end en was het ontwerp erg volgens de huisstijl.
In week 2 waren we voor het eerst bij de opdrachtgever op bezoek. We hadden deze keer ons best gedaan om ons team en werk goed te presenteren en introduceren. We hebben presentatie slides gemaakt om te vertellen hoe dit traject verder verloopt en wat wij allemaal hadden gemaakt. Hieruit hebben erg veel nuttige feedback kunnen krijgen voor onze tweede versie
- Maak een lijst naast de wereld map
- Zo kunnen mensen er snel langs
- Geef de legenda een nieuwe plaatsing
- Skip button meer bij de section houden
- Ongemakkelijk gevoel over arme landen
- Achtergrond is wit, maar landen ook
- Indeling hoe je het laat zien en wat je laat zien nog even veranderen
- Mist interactie gevoel
- Misschien per continent
- Mist een beest "Visdeurbel saus feeling?"
- Text niet gecentreerd houden, is een no go
- Nog niet af, WIP
- Aquarium idee vinden ze vet. "Alsof je echt naar een gracht kijkt"
- Idee: voeg een fiets wrak toe
- Afbeeldingen in canvas plaatsen
- Eventueel verhoudingen van vissen gebruiken
- Meest top 3 gespotte vissen, of meest bijzondere vissen, etc. En maak hier dan user feedback bij.
- Maak het niet te druk qua vissen
- Drag en drop idee om met de vissen de slepen. Daarna bijvoorbeeld terug laten zwemmen
- Geweigerde uploads niet perse nodig om te zien, is niet nuttig voor de bezoeker.
- Moet net wat meer in de huisstijl, is net iets te 'spongebob'.
- Idee van de grafiek is leuk
- Dag en nacht dingen erbij, van licht naar donker in kleur
- Tekst pijltje moet een gewoon pijltje zijn
- Galerij selectie per vis (Bijvoorbeeld 6 foto's van een Baars als je op een Baars klikt)
- Het nodigt niet echt uit om te doen
- Ze spelen het wel :)
- Hij snapt niet gelijk wat hij moet doen
- Mag er nog steeds wel vet en leuk uit zien
- Informatie per vis (Zoals activiteit, etc) vinden ze een goed idee.
- Leg uit wat een vis is, of een feitje over de vis.
- Linken met Vis van het seizoen
Uit deze test hebben we erg goede ontwerp punten gekregen waar we ons de volgende week op kunnen richten. De wereldkaart willen we graag aanpassen zodat de top 3 drukste landen worden getoond. Verder willen we graag gericht werken zodat we de vis van het seizoen en visfoto van de maand samen kunnen voegen. Hierin kan je leuke feitjes zien over elke vis in bijvoorbeeld een pop-over of aparte pagina.
Test bij Studio Moan - Utrecht
Kaart
- Paars in de kaart ipv groen.
- Lijn altijd op het land op rang nummer 1.
- Visjes de richting naar Utrecht.
- Bolletje het visdeurbel logo.
- Kijk hoe wij met text styles werken.
- Knop naar recht uitlijnen.
- Icoontjes bij de land statistieken.
- De belletjes leiden meer af dan dat ze iets toevoegen.
- Visjes bewegen over de lijn.
- Meer onbrand, dus geen goud zilver brons ect.
- Kijk even naar Fiji die wordt afgesneden.
Vis van het seizoen
- Zet erbij wat de getallen achter de vissen echt betekend.
- De vissenrij bovenaan minder als knoppen weergeven.
- Alle vissen zijn klein/dezelfde grootte, gebruik de ‘echte’ groottes voor de vissen.
- Bodem is te cartoony, meer huisstijl.
- Schaduw van het water anders, kijk naar de assets.
- Doe misschien iets met de gracht zelf, hoe diep is de gracht, hoe breed?
- Voeg leuke details toe die de gracht meer als de Utrechtse gracht laat lijken.
- Kijk of je alles wat beter kan ordenen, net als bij de wereldkaart. Nu is het volledige breedte.
Hoelang voordat je de volgende vis ziet / visactiviteit afgelopen uur
- De visdeurbel is uit, dus het heeft geen nut om vissen in het laatste uur te tonen.
- Denk na over hoe je de tijdlijn kan aanpassen naar iets wat ‘niet actueel’ is.
Beste tijdstip van het seizoen
- Gebruik de pijlen die ook op de site staan / of iets wat hierop lijkt.
- Filter is klein. Neemt veel ruimte in en geeft een krap gevoel, geef alles wat meer ruimte.
- Alle tekst in filter is nu uppercase, misschien lowercase?
- Borderradius onderin wordt afgesneden.
- Tijdslijnen zijn moeilijk te zien.
- Doe misschien iets met dag en nacht.
- Geef context om te zeggen wat je laat zien.
- Probeer het dus een beetje aan te sluiten bij de visualisatie met het aquarium.
- Gebruik niet te nieuwe elementen (hergebruik buttons ect)
Kan jij de vis raden?
- Dat spelletje is niet echt iets nog, foto’s zijn lastig. Je kan dus beter niet gewoon 4 foto’s laten zien, maar mooie foto’s en data die je gewoon kan vinden online. Daarnaast dus natuurlijk leuke feitjes over de vissen.
- Het raad element is dus niet nodig.
- Besteed dus even wat tijd in wat je er echt mee wilt doen.
- Het samenvoegen met het aquarium kan misschien wel te druk worden, maar doe hier onderzoek naar of dat handig is, of dat het een los gedeelte blijft.
...
..
De wcag wet bestaat om het web inclusief te maken voor iedereen. Hier zijn verschillende niveau's voor, namelijk:
- Niveau A, het basis niveau. Omringt de basis principes dat ervoor zorgt dat de website bruikbaar is, alt teksten bevat en technisch bedient kan worden met een toetsenbord.
- Niveau AA, dit is het standaard en wettelijk verplicht niveau waar iedere website zich aan moet houden. Het bouwt verder op het basis niveau voor een betere gebruikerservaring.
- Niveau AAA, het hoogste niveau. Dit niveau is bedoeld om de website extreem toegankelijk te maken. Dit niveau is niet wettelijk verplicht
De wcag draait om de volgende onderwerpen:
- Waarneembaar, ervoor zorgen dat mensen alles kunnen zien of horen, ook als de mensen niet alles kunnen zien of horen.
- Bedienbaar, het mogelijk maken dat je website bedient kan worden met een toetsenbord of andere hulpmiddelen, niet alleen een muis.
- Begrijpelijk, ervoor zorgen dat informatie en bediening op je website begrijpelijk is voor de gebruiker.
- Robuust, je website zo bouwen dat hij goed werkt op verschillende apparaten en op verschillende hulptechnologieën
Om de website zo inclusief mogelijk te maken houden we ons graag minimaal aan de standaard eisen van de wcag, Verdere verbeteringen zullen benoemd worden in de design rationale.