Skip to main content

​
TL;DR

The external-projects surfaces now follow two distinct workflows:
  • The root workspace owns the canonical registry and workspace bindings through a searchable control tower.
  • Each bound workspace edits content in a split-view studio with a content rail, focused editor, and live preview.

​
Root Control Tower

  • Use the registry search and adapter filter to find canonical projects quickly.
  • Keep project edits in the registry cards so adapter, delivery profile, and recommended collections stay visible while editing.
  • Use the sticky action panel on the right for two jobs:
    • create a new canonical project
    • bind or unbind a destination workspace
  • Recent binding audits stay below the registry so operational changes remain visible after edits.

​
Workspace Studio

  • The left rail is the primary navigation surface for collections, filters, and record selection.
  • The center column keeps collection settings inline and uses a compact active-item summary instead of forcing every edit into the page body. Secondary explanations belong in tooltips on actions and controls, not as permanently visible helper text on every card.
  • Each selected item opens in a near-fullscreen editor dialog.
    • Use the rail cards to jump directly into item editing.
    • New draft items should open into the same editor immediately after creation so admins can stay in one flow.
  • Keep rail cards visually dense. Use small thumbnails, tight metadata chips, and 2-3 line excerpts rather than large preview tiles that push the list below the fold.
  • Live preview is on demand instead of permanently visible.
    • Open it from the sticky action bar when you need a rendered or payload check.
    • Rendered reflects the current draft immediately in the UI.
    • Payload fetches the real preview delivery response from GET /api/v1/workspaces/:wsId/external-projects/delivery?preview=true.
  • Import, save, publish, and unpublish actions stay explicit in the sticky action bar. There is no autosave.

​
Implementation Notes

  • The preview source of truth is the existing preview delivery API, not a duplicate client-side payload builder.
  • The workspace studio still uses the existing internal API helpers for entry, block, asset, import, publish, and binding operations.
  • Preview now opens in a sheet so the default workspace stays focused on navigation and editing first.

​
Team Guidance

  • When changing external-project authoring UX, keep the live preview wired to the preview delivery endpoint instead of inventing a second payload contract in the client.
  • For dense admin surfaces, keep collection-level controls inline but move item-level authoring into a dedicated editor page or near-fullscreen dialog. Do not render the same heavy editor twice in both the page body and an overlay.
  • In split-view admin pages, prefer one compact selected-item summary in the main column and keep preview as an explicit secondary action when it would otherwise crowd the default workspace.
  • Use tooltips for secondary control explanations so the default layout stays compact, especially in sticky action bars and collection controls.
  • Add any new user-facing copy to both apps/web/messages/en.json and apps/web/messages/vi.json, then run bun i18n:sort.