As a user creating a new document I want the same split-panel edit view as on existing documents, so I can enter metadata next to the file preview #294

Closed
opened 2026-04-20 19:08:54 +02:00 by marcel · 1 comment
Owner

Problem

/documents/[id]/edit and /enrich/[id] have been migrated to the split-panel layout (DocumentEditLayout — PDF preview on the left, metadata form on the right, sticky top + action bars). The /documents/new route still uses the old single-column form with a collapsible "Weitere Details" section (see frontend/src/routes/documents/new/+page.svelte).

That inconsistency means users get two very different experiences depending on whether they land on the "new" page or come in through enrich/edit, and they lose the side-by-side view of file and metadata while a new document is being created.

Goal

Bring /documents/new in line with the other two routes by rendering it through DocumentEditLayout (frontend/src/lib/components/document/DocumentEditLayout.svelte).

Design question to resolve first

DocumentEditLayout takes a Doc prop and loads its file via /api/documents/{id}/file. On the new-document page no document exists yet, so we need to decide how to bridge the gap. Options:

  1. Create placeholder on load / first interaction: POST a PLACEHOLDER document up front (or on file drop), then drive the rest of the flow through the same layout — effectively the new page becomes a redirect-into-edit flow.
  2. Teach DocumentEditLayout a pre-upload mode: accept an optional doc, show the UploadZone on the left until a file is chosen, and submit everything as one multipart form at the end (current /documents/new behaviour).

Option 1 aligns the flow with enrich (which already assumes a PLACEHOLDER). Option 2 keeps the single-submit UX of the current new page but makes the layout more polymorphic.

Pick one (or propose a third) before implementing.

Acceptance criteria

  • /documents/new uses the same split-panel layout as /documents/[id]/edit and /enrich/[id].
  • Filename-derived suggestions (title / date / sender) that the current page already handles keep working.
  • Existing tests (frontend/src/routes/documents/new/page.svelte.spec.ts, +page.server.ts actions) are updated or replaced to cover the new flow.
  • No regressions in /documents/[id]/edit or /enrich/[id] (they share the layout).

Out of scope

  • Backend changes, unless option 1 is chosen and a dedicated "create empty placeholder" endpoint is needed.
  • Visual redesign of DocumentEditLayout itself.
## Problem `/documents/[id]/edit` and `/enrich/[id]` have been migrated to the split-panel layout (`DocumentEditLayout` — PDF preview on the left, metadata form on the right, sticky top + action bars). The `/documents/new` route still uses the old single-column form with a collapsible "Weitere Details" section (see `frontend/src/routes/documents/new/+page.svelte`). That inconsistency means users get two very different experiences depending on whether they land on the "new" page or come in through enrich/edit, and they lose the side-by-side view of file and metadata while a new document is being created. ## Goal Bring `/documents/new` in line with the other two routes by rendering it through `DocumentEditLayout` (`frontend/src/lib/components/document/DocumentEditLayout.svelte`). ## Design question to resolve first `DocumentEditLayout` takes a `Doc` prop and loads its file via `/api/documents/{id}/file`. On the new-document page no document exists yet, so we need to decide how to bridge the gap. Options: 1. **Create placeholder on load / first interaction**: POST a `PLACEHOLDER` document up front (or on file drop), then drive the rest of the flow through the same layout — effectively the new page becomes a redirect-into-edit flow. 2. **Teach `DocumentEditLayout` a pre-upload mode**: accept an optional `doc`, show the `UploadZone` on the left until a file is chosen, and submit everything as one multipart form at the end (current `/documents/new` behaviour). Option 1 aligns the flow with enrich (which already assumes a PLACEHOLDER). Option 2 keeps the single-submit UX of the current new page but makes the layout more polymorphic. Pick one (or propose a third) before implementing. ## Acceptance criteria - `/documents/new` uses the same split-panel layout as `/documents/[id]/edit` and `/enrich/[id]`. - Filename-derived suggestions (title / date / sender) that the current page already handles keep working. - Existing tests (`frontend/src/routes/documents/new/page.svelte.spec.ts`, `+page.server.ts` actions) are updated or replaced to cover the new flow. - No regressions in `/documents/[id]/edit` or `/enrich/[id]` (they share the layout). ## Out of scope - Backend changes, unless option 1 is chosen and a dedicated "create empty placeholder" endpoint is needed. - Visual redesign of `DocumentEditLayout` itself.
marcel added the featureui labels 2026-04-20 19:08:58 +02:00
Author
Owner

Superseded by #317. The split-panel migration for /documents/new is now scoped together with the bulk-upload extension — they share the same route and the same split-panel layout decision.

The three items from this issue that weren't explicitly captured in #317 have been posted there as a carry-over comment: #317#issuecomment.

Closing.

Superseded by #317. The split-panel migration for `/documents/new` is now scoped together with the bulk-upload extension — they share the same route and the same split-panel layout decision. The three items from this issue that weren't explicitly captured in #317 have been posted there as a carry-over comment: [#317#issuecomment](http://heim-nas:3005/marcel/familienarchiv/issues/317). Closing.
Sign in to join this conversation.
No Label feature ui
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#294