Datum en tijd kiezen — vier varianten, één advies

1Wat er nu in de app zit

Kort: Material's standaard-kiezers, 55 keer los aangeroepen, zonder één gedeelde plek. Geen extern pakket, geen Cupertino, geen eigen component.

Wat je nu ziet als je "Kies datum" tikt

Klacht 1 — "je moet telkens maand-voor-maand"

Klacht 2 — "een periode vraagt twee aparte pickers"

Twee dingen die niet in je klacht zaten, maar wél in de code

2Vier richtingen voor de datumkiezer

Alle vier zijn verdedigbaar; ze hebben elk een eigen profiel. Ik reken bij elke variant hetzelfde boodschappenlijstje af: "15 maart volgend jaar" (ver weg, precies) en "20 t/m 27 juli 2027" (een periode).

De vier naast elkaar

^* Gecorrigeerd in v2 — zie sectie 2b. In versie 1 stond hier "nee".

2bEen periode met wielen — kan dat?

Ja. Er is geen kant-en-klaar component voor, maar er zijn drie werkbare vormen, en ze verschillen sterk in hoe goed ze zijn. Ik heb ze alle drie afgerekend op vier dingen: past het op een telefoon (ook op een kleine, ook op 1,5× letters), hoeveel handelingen kost "3 t/m 10 augustus", kan "eind vóór start" nog gebeuren, en past het op alle acht bestaande periode-flows.

De drie naast elkaar, en wat ze doen met de acht bestaande flows

Per bestaande flow: welke stand past?

Score: drie flows willen duur, vijf willen twee datums. Dat is geen argument tegen W3 — de drie duur-flows zijn juist de flows waar je over viel (boeking en vakantie) en waar de meeste fouten in zaten. Maar het is wel het bewijs dat W2 en W3 samen één component moeten zijn, niet twee alternatieven waaruit je kiest. Eén sheet, twee standen, per aanroep ingesteld — en de gebruiker kan altijd wisselen door de einddatum aan te tikken.

2cWiel of kalender — per situatie of app-breed?

Je vroeg me expliciet of het antwoord per gebruikssituatie verschilt, en of dat de conventie niet te rommelig maakt. Dat is de scherpste vraag in dit hele stuk, dus ik heb het niet op gevoel gedaan: ik ben alle 42 datumplekken langsgelopen met één toets.

De telling

^† Grensgeval: de startdatum van een kuur is meestal "vandaag" of "morgen" (dus een chip), maar soms plan je hem rond een reis. Deze zit als startpunt in de kuur-periode, dus in de praktijk erft hij de body van die periode.
^‡ Dit zijn de twee flows waar de wissel-knop naar het maandgrid standaard in beeld staat — zie de kanttekening aan het eind van sectie 2b. Ze staan in de wielrij omdat het wiel er de standaard is, niet omdat de kalender er geen zin heeft.

Twee dingen die deze telling zegt, en één die ze niet zegt.

• Het wiel is voor de meerderheid het juiste antwoord — 31 van de 42. Jouw voorkeur is dus niet alleen smaak, hij past ook op de code.
• Het wiel lost jouw hoofdklacht schoner op dan D2. Van juli naar maart is nu vier tikken op ‹. In D2 is het twee tikken (maandknop + maand kiezen). Op een maandwiel is het één veeg. Op de 31 wiel-plekken is het wiel dus strikt beter dan zowel de huidige kiezer als D2.
• Maar aantal is niet gebruik. Die 11 maandgrid-plekken zijn de schermen die je gezin dagelijks aanraakt: agenda, taken, maaltijden. De 31 wiel-plekken zijn grotendeels formulieren die je één keer per polis of per apparaat invult. Als je op frequentie zou wegen in plaats van op aantal, kantelt het beeld. Daarom is "app-breed één vorm" in beide richtingen een slecht idee.

Wordt het dan niet rommelig?

Dat was je zorg, en die is terecht — twee soorten datumkiezers in één app is precies het soort inconsistentie waar je aan het begin over viel. Drie dingen houden het bij elkaar:

1. Het is één sheet, niet twee dialogen. Dezelfde bottom-sheet, dezelfde kop, dezelfde snelkoppelingschips bovenaan (Vandaag / Morgen / Volgende week), hetzelfde typveld onderaan, dezelfde Klaar-balk. Alleen het middenstuk wisselt tussen een wielenbank en een maandgrid. Dat leest niet als twee producten; het leest als één kiezer die twee gezichten heeft — zoals een toetsenbord dat wisselt tussen letters en cijfers.
2. De regel is uit te leggen in één zin (de toets hierboven). Een conventie die je in één zin kunt zeggen, is geen rommel. Een conventie die per scherm anders is "omdat het daar beter voelde", dát is rommel.
3. Er staat een wissel-knop in de sheet. Een klein wiel/kalender-icoontje in de hoek. Per plek zetten wij de standaard; de gebruiker mag altijd omschakelen en we onthouden zijn keuze. Zo is een verkeerde gok van ons één tik werk voor hem in plaats van een klacht. Dit is ook het antwoord op de vakantie-kanttekening uit 2b.

Mijn keuze, expliciet: per situatie, langs die ene regel, met een wissel-knop als vangnet — en niet app-breed één vorm. De reden dat ik dit durf: het kost bijna niets extra zodra beide bodies achter dezelfde wrapper zitten, en het maakt de vraag "wiel of kalender hier?" omkeerbaar in plaats van definitief.

Eén component of twee? — de vraag die je openliet

Je zei: "dat mogen eventueel twee aparte componenten zijn of een variatie op hetzelfde component." Dit is geen detail, want het bepaalt hoe die 42 plekken eruit gaan zien. Ik werk beide kanten uit.

Drie richtingen voor de tijdkiezer

Uitgangspunt uit de code: in Tendlo vallen tijden bijna altijd op een kwartier of een half uur (afspraken 09:00, sport 18:30, medicijnen 08:00, digest 07:00, stille uren 22:00–07:00). En op vier plekken is een tijd eigenlijk een tijdvak, geen tijdstip. De schijf van Material rondt al af op 5 minuten, dus het probleem is niet de precisie — het is dat je twee schijven moet slepen waar één tik genoeg was.

Waarom datum en tijd hier dezelfde taal spreken

Je vroeg expliciet om één ontwerptaal. In add_appointment_sheet, add_sport_event_sheet, add_task_sheet, add_medication_sheet, add_movement_session_sheet en add_vacation_item_sheet staan datum en tijd in hetzelfde formulier onder elkaar. Na deze wijziging delen ze twee lagen — en de tweede is belangrijker dan de eerste.

Laag 1 — dezelfde vorm

1. Bottom-sheet, geen dialoog in het midden van het scherm.
2. Snelkoppelingen bovenaan als chips (Vandaag / Morgen — nu / +15 min).
3. Wielen in het midden: dag/maand/jaar voor datum, uur/kwartier voor tijd. Eén veeg = één keuze. (Op de 11 maandgrid-plekken is het middenstuk een maandgrid; de rest van de sheet blijft identiek.)
4. Typen als ontsnapping onderaan, altijd zichtbaar maar nooit in de weg.

Laag 2 — dezelfde logica, en dít is de echte winst

Een periode is overal een startpunt plus een lengte. "Vanaf 3 augustus, 7 nachten" (W3) en "vanaf 09:00, 1 uur" (T3) zijn hetzelfde idee op twee schalen. Dat betekent dat een gebruiker die één keer begrijpt hoe een vakantieperiode werkt, óók weet hoe een afspraak van anderhalf uur werkt. En het betekent dat "eind vóór start" in de hele app geen bestaande toestand meer is — niet bij dagen, niet bij uren.

Dat is een sterkere vorm van consistentie dan gelijke opmaak. Opmaak kun je zien; logica voel je pas als je een fout niet meer kunt maken.

Kunnen wielen en D2 naast elkaar bestaan?

Je vroeg dit expliciet, en het antwoord bepaalt of de keuze uit sectie 2c omkeerbaar is of dat je er nu voorgoed aan vastzit. Het antwoord is ja, en het sluit precies aan op het wrapper-advies dat al in versie 1 stond — dat advies wordt hier van "netjes" naar "de spil van het hele plan".

Hoe het werkt

Alle 55 aanroepen gaan door pickTendloDate / pickTendloDateRange / pickTendloTime. Die functies openen één sheet die drie dingen los van elkaar vaststelt:

1. Het chroom — sheet, kop, snelkoppelingschips, typveld, Klaar-balk. Altijd hetzelfde, ongeacht de rest.
2. De body — een wielenbank óf een maandgrid. Dit is de enige plek waar wiel-versus-kalender bestaat.
3. De periodestand — één datum, of start+duur (W3), of Van/Tot (W2). Onafhankelijk van de body: een periode kan zowel met wielen als met een maandgrid.

Omdat die drie los staan, is de verdeling uit sectie 2c niets meer dan één tabel van standaarden in één bestand. Die tabel aanpassen — na jouw feedback, na tester-feedback, of omdat we het gewoon verkeerd gokten — raakt nul van de 55 aanroepen.

Wat het kost om béide bodies te bouwen

Dit is de vraag die je waarschijnlijk echt stelt: is dat niet dubbel werk? Nee — het is ongeveer 2 à 3 dagen extra, omdat het meeste werk niet in de body zit.

Alleen wielen: ~8 dagen. Wielen + D2: ~11 dagen. Voor 3 dagen koop je: de 11 afweeg-plekken goed bediend, een vangnet als we een plek verkeerd inschatten, en een keuze die je later kunt verschuiven zonder migratie. Dat is de goedkoopste verzekering in dit hele voorstel.

En het omgekeerde is óók waar en daarom vermeld ik het: als je die 3 dagen niet wil, dan is "alleen wielen, overal" een verdedigbare keuze — met de eerlijke prijs dat agenda, taken en maaltijden hun maandbeeld kwijt zijn en dat je dat later alleen met een tweede bouwronde terughaalt.

Aanbeveling

De rationale, kort

• Het wiel lost je hoofdklacht schoner op dan D2. Dat is de belangrijkste uitkomst van dit huiswerk. Van juli naar maart: nu 4 tikken, in D2 2 tikken, op een maandwiel 1 veeg. Op de 29 plekken waar je het maandbeeld niet nodig hebt, is het wiel dus niet alleen vertrouwder — het is ook objectief minder werk.
• W3 is de vondst. Ik ging op zoek naar "kan een periode met wielen" en vond iets beter dan een periodekiezer: door een periode te definiëren als start + lengte houdt "eind vóór start" op te bestaan. De vier verschillende noodgrepen die ik in deel 1 vond, verdwijnen niet doordat we ze centraliseren maar doordat het probleem verdampt. Dat had ik met een kalender-periodekiezer (D2/W1) nooit gekregen.
• W3 en T3 zijn hetzelfde idee. "3 augustus + 7 nachten" en "09:00 + 1 uur". Daarmee is de ene ontwerptaal die je vroeg geen opmaakafspraak meer maar een regel: een periode is een startpunt plus een lengte. Consistentie die je voelt doordat je een fout niet meer kunt maken, is sterker dan consistentie die je ziet.
• W1 wijs ik af, maar niet als stroman. Twee wielensets in één sheet is de meest letterlijke lezing van je klacht en volledig geldig. Hij verliest op twee harde dingen: hij past niet op een kleine telefoon of bij 1,5× letters (~550 px), en twee gelijkende wielenbanken laten je stil de verkeerde draaien. Als je duur-semantiek niet vertrouwt, is W1 wél de veilige keuze — zeg het en we doen W1+W2.
• D2 er niet uitgooien is 3 dagen waard. Beide bodies achter dezelfde wrapper kost ~11 dagen in plaats van ~8. Daarvoor krijg je: de dagelijks gebruikte schermen goed bediend, een vangnet als we een plek verkeerd inschatten, en een verdeling die later verschuift zonder de 55 aanroepen aan te raken. Dat is de goedkoopste verzekering in dit voorstel.
• Per situatie, langs één regel — niet app-breed. "Is deze datum een gegeven dat je weet, of een keuze die je afweegt?" Dat is in één zin uit te leggen, en het chroom van de sheet blijft identiek, dus het leest als één kiezer met twee gezichten in plaats van twee producten. De wissel-knop maakt onze gok omkeerbaar.
• De wrapper is nu de spil, niet de nette bijzaak. In versie 1 was hij een migratietruc. Nu draagt hij de hele keuze: twee bodies, drie periodestanden en een per-situatie-tabel, allemaal op één plek. Dat is de reden om hem als eerste te bouwen en niet als laatste.

De twee eerlijke tegenargumenten

1 · Aantal is niet gebruik. Die 31 wiel-plekken zijn grotendeels formulieren die je één keer per polis invult; de 11 maandgrid-plekken zijn agenda, taken en maaltijden — dagelijks. Als je op frequentie weegt in plaats van op aantal, is de kalender de hoofdvorm en het wiel de uitzondering. Ik kies toch voor het wiel als hoofdvorm omdat jij dat vertrouwd vindt en omdat het de maandsprong beter oplost, maar je moet weten dat de telling niet zo eenduidig is als "31 tegen 11" suggereert.

2 · Op agenda krijg je grid + wiel in één formulier. Datum als maandgrid, tijd als wiel, onder elkaar. Dat is een oneffenheid. Ik accepteer hem omdat de spiegelbeeldige keuze (tijdraster naast datumwiel) het probleem alleen verplaatst, en omdat de wissel-knop wie dat wil alles op wielen laat zetten. Maar het is geen vlekkeloze uitkomst en ik wil niet doen alsof.

En als je het goedkoop wil houden

Dan is het antwoord wielen + W3/W2, zonder D2: ~8 dagen. Elke datum en elke tijd wordt een wiel, periodes worden start+duur met een Van/Tot-ontsnapping, en agenda/taken/maaltijden verliezen hun maandbeeld. Dat is een consistente, verdedigbare app — en als het gezin het maandbeeld gaat missen, is D2 er later bij te bouwen als tweede body zonder één aanroep aan te raken. Dat is precies waarom de wrapper eerst komt.

Over externe pakketten — bewust niet

Er zijn pakketten die dit doen (omni_datetime_picker, board_datetime_picker, table_calendar). Ik stel er geen voor, en dat is een afweging, geen dogma:

• table_calendar is een inline kalender-widget, geen kiezer-dialoog. Hij heeft geen maand/jaar-kop en geen periodelogica die past; je bouwt de sheet, de snelkoppelingen en de range-regels alsnog zelf. Je krijgt dus 30% en erft 100% van de afhankelijkheid.
• omni_datetime_picker / board_datetime_picker doen wél single + range + tijd, maar brengen hun eigen vormtaal mee die je vervolgens gaat overrulen — en ze zouden een interactie dragen die op 55 plekken in de app zit. Raakt zo'n pakket achterop bij een Flutter-upgrade, dan staat je hele invoer stil. Voor een randfunctie is dat een prima ruil; voor de kern van elk formulier niet.
• Het component dat ik voorstel is naar schatting 350–450 regels en leunt voor maandnamen, eerste weekdag en 12/24-uursweergave op MaterialLocalizations — het risico dat je zelf draagt is dus vooral opmaak, niet logica.

Eén nuance nu je voor wielen kiest, want er is wél iets kant-en-klaars: Flutter levert CupertinoDatePicker en CupertinoTimerPicker mee, gratis en zonder pakket. Waarom ik die alsnog niet voorstel:

• CupertinoDatePicker is niet te thematiseren naar Tendlo's huisstijl (vaste iOS-kleuren en -typografie), en op Android voelt hij als een vreemd eiland.
• Hij heeft geen vierde kolom en geen ruimte voor een duurregel — W3 is er dus niet mee te maken, en dat is juist de vondst waar dit hele voorstel op rust.
• Wat we wél gebruiken is de onderliggende bouwsteen: ListWheelScrollView, ook uit Flutter zelf. Dat is de motor van elk wiel, geeft hetzelfde vertrouwde gevoel (magnetisch inklikken, dezelfde vertraging), en laat zich volledig in onze eigen kleuren en teksten zetten. Het wiel dat ik voorstel is dus geen namaak-iOS-wiel — het is hetzelfde mechaniek in onze vormgeving.

3Hoe dit app-breed wordt doorgevoerd

Eerlijk over de omvang: 55 aanroepen in 44 bestanden. Dat klinkt als een berg, en dat is het ook — maar de vorm van het werk maakt het beheersbaar, op één voorwaarde.

De veilige volgorde, in zes groepen

Wat dit bij elkaar kost

Wat de omvang meevalt: de testkoppeling. Slechts 2 testbestanden raken de kiezers, dus de migratie breekt bijna niets. Wat de omvang tegenvalt: de 55 aanroepen zijn nu allemaal net iets anders geconfigureerd (elk eigen firstDate/lastDate/initialDate-berekening, soms met eigen klem-logica zoals add_sport_event_sheet.dart:164-171). Die eigenaardigheden moeten één voor één worden gelezen en overgezet — dat kun je niet met zoeken-en-vervangen.

Wat ik van jou nodig heb voordat er code in gaat

Hieronder de acht vragen zoals ze voorlagen. 1, 2 en 6 zijn hierboven beslist en blijven staan als vastlegging van de afweging; 3, 4, 5, 7 en 8 zijn nog open en geen van alle blokkerend voor de eerste uitrolgroep.