Lijsten: doorzoek het hele magazijn, niet alleen de rijen op je scherm
Het paginatiecontract achter elke hoofdlijst, en waarom een lege pagina nooit mag liegen over je voorraad.
Een operator typt een serienummer in de voorraadzoekbalk en krijgt niets. De asset bestaat. Hij staat op pagina veertien. Het zoeken keek alleen naar de vijfentwintig rijen die de browser geladen had, en de operator gelooft nu dat het apparaat nooit ontvangen is. Een half uur en één ongemakkelijk telefoontje later blijkt van wel. Die faalmodus is de reden waarom elke hoofdlijst op het platform één regel volgt: eerst zoeken, dan pagineren.
Het contract
Zoeken en filters worden toegepast op de volledige dataset van de lijst voordat de pagina gekozen wordt. Wat je ziet, is de huidige schijf van alles wat matchte, nooit een filter over een schijf. De lijst zegt dat ook: het totaal aantal treffers, het huidige bereik, pagina X van Y, directe sprongen naar nabije pagina’s en een keuze voor paginagrootte. De standaard paginagrootte is een instelling voor de hele tenant onder Instellingen > Weergave en lijsten, zodat een team dat liever honderd rijen per pagina heeft, dat één keer beslist, voor iedereen.
De adresbalk onthoudt
De URL draagt de zoektekst, de filters, de sortering, de pagina en de paginagrootte. Ververs, en je staat waar je stond. Stuur de link naar een collega en die ziet dezelfde werkset. Open een asset, corrigeer zijn grade, kom terug — zelfde pagina, zelfde filters, zelfde volgorde. Een lijst die haar staat bij elke omweg vergeet, is een lijst waar mensen na één ochtend niet meer op vertrouwen.
Twee soorten leeg
“Geen records” en “geen treffers” zijn verschillende zinnen, en het platform zegt de juiste. Een tenant die nog geen enkele asset ontvangen heeft, ziet een eerste-keer-lege-staat die naar receiving of een inbound manifest wijst als eerste operationele stap. Een tenant met tienduizend assets en een filter dat er geen enkele raakt, ziet een geen-resultaten-staat die vraagt om ruimer te zoeken. En een paginanummer voorbij het einde van de lijst — een verouderde bookmark, een gedeelde link na een opruiming — mag nooit doen alsof de tenant geen data heeft. Een lege pagina is een antwoord, geen beschuldiging.
Kiezers spelen volgens dezelfde regel
Operationele kiezers die als een voorraadlijst aanvoelen — bronassets kiezen voor een demanufacturing-job, vrije voorraad selecteren voor een outbound order — zoeken over elke kandidaat en niet alleen over wat op het eerste scherm past, en starten vanaf dezelfde standaard paginagrootte. Kan een kiezer voorbij een handvol records groeien, dan gedraagt hij zich als een lijst, want voor wie op de vloer staat is het er een.
De twee uitzonderingen, bij naam
Grote feed-achtige schermen zoals de audit trail onder Activity gebruiken cursor paging — nieuwer, ouder — als expliciete uitzondering, want een totaal over miljoenen events is daar niet de vraag die iemand stelt. Kleine, begrensde configuratielijsten die volledig geladen zijn — de palletformaten van een tenant, zijn zonetypes — mogen in de browser filteren, want er valt op een volgende pagina niets te missen. Al de rest pagineert zoals hierboven beschreven. Geen stille terugval op “vorige / volgende” waar een echt totaal mogelijk was.
Rijen die je zonder muis opent
Elke rij in zo’n lijst is één benoemde link naar het detail. Tab landt op de rij, Enter opent hem, en een schermlezer hoort de naam van het record één keer — “Acme BV, link” — niet één keer per cel en niet enkel “link”. Acties die verschijnen wanneer een muis over een rij zweeft, verschijnen ook bij toetsenbordfocus. De lijst is het werkoppervlak van de dag; ze werkt met welke hand er ook vrij is.