-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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.