-
Notifications
You must be signed in to change notification settings - Fork 0
Design rationale
In de Design Rationale schrijf je de debriefing, de probleemdefinitie, toon je de oplossing en schrijf je een uitleg van de code. De Design Rationale is een verantwoording van je ontwerp. Je maakt met je team één design rationale. Tip: Doe dit in de wiki van je project repo.
- 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.
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). Ook wordt de website vanuit de hele wereld bezocht, daarom moeten we ook nadenken over performance. De website moet natuurlijk ook volledig responsive zijn.
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.
- 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 hulptechnologiën
(dit word nog aangepast zodra de website final is.) 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.