Files
webmanager-mvp/project_docs/ROW_SELECTION_WITHOUT_CHECKBOX_V1.md
T
2026-03-12 12:46:48 +01:00

173 lines
7.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Row Selection Without Checkbox v1
## 1. Doel
De huidige lijstweergave gebruikt tegelijk een checkbox, een mediaslot, row highlight, current row styling en active pane styling. Functioneel werkt dat, maar het kost horizontale ruimte in precies het deel van de UI waar de gebruiker het meest kijkt: de naamkolom. Een compactere lijst zonder checkbox kan de dual-pane file manager rustiger en dichter bij klassieke file manager workflows maken, zolang selectie nog steeds duidelijk en voorspelbaar blijft.
Deze stap gaat daarom niet over nieuwe selectie-logica, maar over de vraag of de bestaande selectie-interacties voldoende sterk zijn om de checkbox uit de rij te verwijderen zonder bruikbaarheid of regressieve verrassingen.
## 2. Scope
Voor deze v1-ontwerpstap is de scope expliciet:
- checkbox verwijderen uit de browse-lijst
- selectie zichtbaar maken via bestaande row highlight, current row en active pane styling
- geen backendwijzigingen
- geen nieuwe dependencies
- geen herontwerp van selectie-state tenzij strikt nodig
Niet in scope:
- nieuwe selectie-features
- backend batch-semantiek
- nieuwe keyboard shortcuts
- drag selection
- shift-click range selection
- checkbox-vervanging door een andere control in dezelfde kolom
## 3. Bestaande selectiepatronen die leidend blijven
De bestaande interacties blijven leidend en worden niet opnieuw ontworpen:
- gewone rij-click = single select
- Cmd+klik op Mac / Ctrl+klik op niet-Mac = toggle selectie
- Shift + ArrowUp / ArrowDown = range-selectie
- Space = toggle selectie op current row
- Escape = clear selection
- directorynaam blijft openen
- Enter/open-gedrag blijft intact
- wildcard-selectie blijft intact
- activePane, currentRowIndex, selectedItems en selectionAnchorIndex blijven de basis
De kern van deze UX-slice is dus: is de checkbox nog nodig als deze bestaande patronen al aanwezig zijn?
## 4. UI-gedrag zonder checkbox
Zonder checkbox moet selectie volledig leesbaar blijven via styling van de rij zelf.
Aanbevolen visuele opbouw:
- current row blijft een subtiele focus-/cursorstaat
- selected rows krijgen een duidelijkere maar nog compacte achtergrond en/of inset accent
- current row + selected moet samen zichtbaar kunnen blijven
- active pane blijft via pane border/outlining zichtbaar, niet via zware pane-achtergrond
- mediaslot links van de naam blijft bestaan en schuift op naar de plek waar nu checkbox + mediaslot samen ruimte innemen
Aanbevolen onderscheid:
- current row: lichte focusband of outline
- selected row: duidelijke achtergrondtint of accentvlak
- current row + selected: gecombineerde staat met iets sterker contrast
- inactive pane selected rows: nog steeds leesbaar, maar iets rustiger dan in active pane
Multi-select moet zonder checkbox nog steeds scanbaar blijven. Dat vraagt om consistente row highlight over de hele breedte van de lijstregel, niet alleen rond de naamtekst.
## 5. Click-target gedrag
Dit deel is kritisch, omdat de checkbox nu nog een heel expliciete select-control is.
Aanbevolen gedrag zonder checkbox:
- klik op directorynaam = open directory
- klik op file-naam = single select, niet openen
- klik op rij buiten de naam = single select
- Cmd/Ctrl+klik op rij buiten de naam = toggle selectie
- Cmd/Ctrl+klik op file-naam = toggle selectie als dat aansluit op bestaande flow, of expliciet dezelfde single-select-regel houden; dit moet consistent zijn
- directorynaam moet navigatie blijven en mag niet per ongeluk selecteren
Veilige v1-richting:
- behoud het huidige onderscheid tussen naam-click en row-click
- maak de row het primaire selectiedoel
- laat directorynaam expliciet het navigatiedoel blijven
- verander zo min mogelijk aan bestaande event routing
## 6. Discoverability en usability-risico
Wat verloren gaat als de checkbox verdwijnt:
- een direct zichtbaar affordance voor “dit item kan geselecteerd worden”
- een bekende multi-select cue voor minder keyboardgerichte gebruikers
- een expliciete toggle-target die modifier-free multi-select intuïtiever maakt
Wat ervoor terugkomt:
- meer ruimte voor naam, thumbnail/icoon en metadata
- rustiger lijstbeeld
- sterker file-manager gevoel als row highlight en current row goed zijn uitgewerkt
Belangrijk risico:
- muisgebruikers die modifier-click niet kennen, verliezen een zeer duidelijke multi-select affordance
- wildcard-selectie, Space, Shift+Arrow en Cmd/Ctrl+klik bestaan al, maar zijn minder zelfverklarend dan een checkbox
Daarom is een kleine hint waarschijnlijk nodig als de checkbox ooit verdwijnt, bijvoorbeeld:
- compacte helpertekst in een settings/shortcuts context
- of subtiele onboarding/hint buiten de lijst zelf
Voor de lijst zelf is het onwenselijk om extra tekst of badges toe te voegen; dat eet de gewonnen rust meteen weer op.
## 7. Thumbnail/interactie relatie
De thumbnail/icon-slot links van de naam maakt checkbox-verwijdering visueel aantrekkelijker, omdat die linkerkant van de rij dan eenvoudiger wordt:
- mediaslot
- naam
- overige kolommen
Dat levert echte UX-winst op:
- meer ruimte voor langere bestandsnamen
- minder visuele ruis links in de rij
- thumbnails en iconen krijgen een natuurlijkere positie
Voorwaarde is wel dat de mediaslot zelf geen select-control wordt. Het slot moet gewoon onderdeel van de rij blijven, niet een nieuwe semi-knop met onduidelijke semantiek.
Aanbevolen regel:
- mediaslot blijft decoratief/informatief
- rij zelf blijft het selectiedoel
- directorynaam blijft het open-doel
## 8. Regressierisico
Belangrijkste risicos:
- multi-select wordt minder discoverable voor muisgebruikers
- selectie zonder checkbox voelt minder expliciet bij gemengde file/directory lijsten
- current row en selected row kunnen visueel te dicht op elkaar komen
- modifier-click gedrag moet consequent blijven, anders voelt selectie fragiel
- bestaande flows als copy/move/delete/rename kunnen indirect onduidelijker worden als selectie minder zichtbaar wordt
Laag-risico observatie:
- technisch is checkbox-verwijdering waarschijnlijk klein, omdat de bestaande selection state al volwassen genoeg is
- UX-matig is het risico groter dan technisch, vooral voor discoverability en vertrouwen
## 9. Teststrategie
Als deze stap later geïmplementeerd wordt, moeten minimaal deze gevallen opnieuw expliciet getest worden.
UI smoke/regressie:
- checkbox-elementen ontbreken uit browse-rows
- mediaslot blijft aanwezig
- lijst blijft renderen met current row, selected row en active pane
- directorynaam blijft klikbaar
- file-naamgedrag blijft intact
Handmatige validatie:
- single select met muis
- Cmd/Ctrl+klik multi-select
- Shift+Arrow range-selectie
- Space toggle
- Escape clear
- wildcard-selectie
- current row zichtbaar in combinatie met selected rows
- copy/move/delete/rename op selectie
- directory-open via naam zonder onbedoelde selectie
Specifiek opnieuw te testen selectiegevallen:
- exact 1 geselecteerde file
- exact 1 geselecteerde directory
- meerdere files
- meerdere directories
- gemengde selectie
- parent entry `..` blijft buiten gewone selectie
## 10. Aanbeveling
Aanbevolen v1-richting met laag regressierisico:
- checkbox-verwijdering nu nog niet uitvoeren
- eerst thumbnails/settings stabiliseren en de huidige lijstpresentatie laten settelen
- checkbox-verwijdering alleen doen als aparte UX-slice met expliciete handmatige validatie op multi-select discoverability
Expliciete beoordeling:
- technisch is checkbox-verwijdering waarschijnlijk haalbaar
- UX-matig is het nu nog borderline te vroeg
- de bestaande selectie-engine is sterk genoeg
- de grotere onzekerheid zit in begrijpelijkheid voor muisgebruikers en in het verlies van een duidelijke multi-select affordance
Daarom is de aanbevolen richting:
- checkbox-verwijdering pas uitvoeren in een aparte, doelbewuste slice
- daar tegelijk current-row/selected-row styling en click-targets definitief aanscherpen
- niet stilzwijgend meenemen in een andere feature
Kort oordeel:
- verantwoord, maar niet zonder aparte UX-focus
- dus: nog niet nu, wel als gerichte vervolgstap met laag technische maar middelmatig UX-risico