webmanager-mvp/project_docs/UI_F6_PURE_MOVE_V1.md

UI_F6_PURE_MOVE_V1

1. Doel

F6 moet in de UI een expliciete pure Move-actie worden.

Waarom:

• F2 heeft nu een eigen rename-flow
• daarmee is de oorspronkelijke gecombineerde Rename/Move-semantiek in de UI niet meer nodig
• een pure Move-flow maakt de functietoetsen voorspelbaarder:
  • F2 = Rename
  • F6 = Move
• dit sluit beter aan op klassieke file-manager verwachtingen en vermindert cognitieve ruis in de popup-flow

Belangrijk bestaande context:

• move-functionaliteit bestaat backendmatig al
• move-functionaliteit bestaat UI-matig al
• file move, directory move binnen huidige scope en batch move binnen huidige scope werken al
• deze stap gaat dus niet over nieuwe move-capaciteit, maar over het vereenvoudigen van de UI-flow rond de bestaande move-actie

2. Scope

De pure Move-flow in v1 moet de bestaande move-scope UI-matig netjes afdekken voor zover die al ondersteund wordt.

In scope:

• exact 1 file
• exact 1 directory
• meerdere files
• meerdere directories
• gemengde selectie van files + directories

Voorwaarde:

• alleen binnen de bestaande huidige move-scope
• alles wat backendmatig al geblokkeerd is, blijft geblokkeerd
• de UI mag dat duidelijker presenteren, maar mag de scope niet verbreden

Niet in scope:

• nieuwe backend move-capaciteit
• nieuwe tasksemantiek
• nieuwe batch-semantieken buiten de bestaande backend
• rename binnen F6

3. Gewenst gedrag

F6 en de Move-knop moeten exact dezelfde frontendflow gebruiken.

Kernregel:

• F6 keyboard shortcut = pure move-flow
• Move-knop in functiebalk = exact dezelfde pure move-flow
• beide gebruiken dezelfde centrale frontendhandler

Popupregel:

• de bestaande move-popup wordt een pure move-popup
• geen rename-invoerveld in deze flow
• geen naamwijzigingssemantiek in deze flow
• de popup richt zich alleen op doelpad of doelmap voor verplaatsen

Interactie:

• Enter bevestigt
• Escape annuleert
• X sluit popup

Gedragslijn per context:

• exact 1 item: popup toont expliciete move-context voor dat item
• meerdere items: popup toont batch move-context
• popuptekst en labels moeten spreken in termen van Move, niet Rename/Move

4. Relatie met bestaande move-scope

Wat al bestaat en alleen hergebruikt moet worden:

• single file move
• single directory move binnen de huidige scope
• batch move binnen de huidige scope
• task-based move
• bestaande validaties en blokkades

Dat betekent:

• de pure Move-popup hoeft geen nieuwe backendbeslissingen te nemen
• de frontend mag alleen een duidelijkere presentatie en dispatchlaag geven
• validatiefouten zoals cross-root blokkades, subtree-blokkades, mixed-root blokkades en bestaande destination-conflicten blijven door de bestaande backend en bestaande UI-validatie worden afgevangen

Pragmatische consequentie:

• de move-popup moet vooral destination-gericht zijn
• submit moet direct de bestaande move-logica aanroepen
• geen impliciete keuze meer tussen rename en move in deze flow

5. Relatie met F2 Rename

Na invoering van pure F6 Move geldt:

• F2 blijft exclusief voor rename
• Rename-knop blijft exclusief voor rename
• F6 wordt exclusief voor move
• Move-knop wordt exclusief voor move

Belangrijk ontwerpprincipe:

• geen gedeelde rename/move-popup meer
• F2 en F6 krijgen elk een eigen, semantisch heldere popupflow
• dit maakt toekomstige onderhoud en UX-consistentie eenvoudiger

6. UI-semantiek

Welke contextinformatie is nuttig

Voor een pure move-popup is nuttig:

• broninformatie: welk item of hoeveel items geselecteerd zijn
• destination-informatie: waarheen wordt verplaatst
• bij batch move: doelmap in plaats van volledig doelpad per item

Default destination

Aanbevolen defaultvoorstel:

• gebruik het current path van het inactieve paneel als destination-basis

Voor exact 1 item:

• toon een destination pad of destination map duidelijk, afhankelijk van de bestaande implementatierichting
• aanbevolen: toon volledig destination path, vooraf ingevuld op basis van het inactieve paneel + itemnaam
• dit houdt aan bij de bestaande move-aanroepsemantiek voor single-item move

Voor batch move:

• toon aantal geselecteerde items
• toon doelmap = current path van het inactieve paneel
• geen rename-achtige tekst of naamveld per item

Foutmeldingen en blokkades

Compact tonen in de popup of bestaande errorzone:

• destination exists
• mixed roots not allowed
• destination inside source not allowed
• cross-root directory move not supported
• andere bestaande backendfouten

Belangrijk:

• foutmeldingen moeten move-gericht geformuleerd zijn
• geen verwijzing naar rename of gecombineerde semantiek

7. Regressierisico

Belangrijkste risico's:

• per ongeluk opnieuw bouwen van bestaande move-functionaliteit in plaats van die te hergebruiken
• verwarring tussen oude gecombineerde popup en nieuwe pure move-popup
• inconsistente keyboard- en knopwiring tussen F6 en Move
• onbedoelde impact op de al werkende F2 Rename-flow

Mitigatie:

• F6 en Move één centrale pure move-handler laten delen
• bestaande backend move-calls intact laten
• F2 volledig gescheiden houden
• popup-tekst en labels expliciet move-only maken
• geen backendwijzigingen in deze stap

8. Teststrategie

UI smoke/regressietests:

• functiebalk bevat Move met F6
• F6 wiring blijft aanwezig
• Move-knop gebruikt dezelfde handler als F6
• move-popupcontainer aanwezig en move-only geëtiketteerd
• rename-popup blijft apart aanwezig voor F2

Handmatige validatie:

• exact 1 file -> F6 opent pure move-popup
• exact 1 directory -> F6 opent pure move-popup binnen huidige scope
• meerdere files -> batch move-popup blijft logisch werken
• meerdere directories -> batch move-popup blijft logisch werken binnen huidige scope
• gemengde selectie -> bestaande batch move-scope en blokkades blijven correct
• F2 Rename blijft volledig los en ongewijzigd

Bestaande regressies die bewaakt moeten blijven:

• single file move same-root
• single file move cross-root
• single directory move binnen huidige scope
• batch move file-only
• batch move met directories binnen huidige scope
• blokkades voor mixed roots, subtree en symlink source

9. Aanbeveling

Aanbevolen v1-richting met laag regressierisico:

• maak F6 en Move UI-semantisch puur move-only
• verwijder rename-semantiek uit de F6-popupflow
• behoud en hergebruik alle bestaande move-logica, validaties en backendcalls
• houd F2 Rename volledig apart

Waarom dit de veiligste richting is:

• maximale herbruik van bestaande backend en UI-logica
• minimale semantische overlap tussen Rename en Move
• duidelijkere functietoetsbetekenis
• laag regressierisico omdat de verandering vooral UI-opschoning is, geen capability-uitbreiding