426 lines
13 KiB
Markdown
426 lines
13 KiB
Markdown
# EmboFlow Information Architecture And Key Screens
|
|
|
|
## Goal
|
|
|
|
Define the primary navigation model, main screens, and key interaction patterns for EmboFlow V1.
|
|
|
|
The UI should feel like a serious data workflow product, not a generic low-code canvas. The most important interaction is the relationship between assets, workflows, runs, and outputs.
|
|
|
|
## Information Architecture
|
|
|
|
Top-level product areas:
|
|
|
|
- Workspace switcher
|
|
- Project selector
|
|
- Projects
|
|
- Asset Workspace
|
|
- Node Registry Workspace
|
|
- Canvas Workspace
|
|
- Explore Workspace
|
|
- Label Workspace
|
|
- Admin Workspace
|
|
|
|
## Navigation Model
|
|
|
|
### Global Header
|
|
|
|
Recommended global header content:
|
|
|
|
- workspace switcher
|
|
- project switcher
|
|
- language switcher for Chinese and English
|
|
- search entry
|
|
- run notifications
|
|
- user menu
|
|
|
|
### Primary Sidebar
|
|
|
|
Recommended primary navigation:
|
|
|
|
- Projects
|
|
- Assets
|
|
- Nodes
|
|
- Workflows
|
|
- Runs
|
|
- Explore
|
|
- Labels
|
|
- Admin
|
|
|
|
This keeps the product model explicit:
|
|
|
|
- assets are inputs
|
|
- workflows define transformation logic
|
|
- runs represent execution history
|
|
- explore is where users inspect outputs and raw inputs
|
|
|
|
## Screen 1: Workspace And Project Entry
|
|
|
|
Purpose:
|
|
|
|
- choose personal or team workspace
|
|
- choose or create project
|
|
- view recent projects and recent workflow runs
|
|
|
|
V1 should emphasize project-level organization because all major resources are project-scoped.
|
|
|
|
The current implementation now matches this with:
|
|
|
|
- a dedicated `Projects` sidebar entry
|
|
- a header-level active project selector
|
|
- project cards that let the user open a project directly into workflow authoring
|
|
|
|
## Screen 2: Asset Workspace
|
|
|
|
Purpose:
|
|
|
|
- upload or import raw assets
|
|
- inspect asset type and status
|
|
- review probe summary
|
|
- launch preview or workflow entrypoint
|
|
|
|
Core regions:
|
|
|
|
- asset list with filters
|
|
- import actions
|
|
- asset status and source type
|
|
- probe summary card
|
|
- recommended next actions
|
|
|
|
Key actions:
|
|
|
|
- upload file
|
|
- upload archive
|
|
- import object storage prefix
|
|
- register storage path
|
|
- open preview
|
|
- create workflow from asset
|
|
|
|
The current V1 runtime extends this screen beyond raw assets and treats project data management as one combined workspace:
|
|
|
|
- raw asset registration
|
|
- storage connection creation for `local`, `minio`, `s3`, `bos`, and `oss`
|
|
- dataset creation from selected source assets into a selected storage connection
|
|
|
|
## Screen 3: Asset Detail / Explore Entry
|
|
|
|
Purpose:
|
|
|
|
- inspect one asset deeply
|
|
- browse folder structure
|
|
- inspect metadata and detected format
|
|
- preview representative files
|
|
|
|
Suggested panels:
|
|
|
|
- left: file tree or asset structure
|
|
- center: preview surface
|
|
- right: metadata, probe report, warnings, recommended nodes
|
|
|
|
This screen should support both:
|
|
|
|
- raw asset view
|
|
- canonical dataset summary view when available
|
|
|
|
## Screen 4: Canvas Workspace
|
|
|
|
This is the core authoring surface.
|
|
|
|
### Layout
|
|
|
|
Recommended layout, aligned with the Xspark reference pattern:
|
|
|
|
- left: node library and workflow tools
|
|
- center: canvas
|
|
- right: node configuration panel
|
|
|
|
### Left Panel
|
|
|
|
Contains:
|
|
|
|
- source nodes
|
|
- transform nodes
|
|
- inspect nodes
|
|
- annotate nodes
|
|
- export nodes
|
|
- utility nodes
|
|
- search/filter
|
|
|
|
### Center Canvas
|
|
|
|
Supports:
|
|
|
|
- drag-and-drop node placement
|
|
- edge creation
|
|
- zoom and pan
|
|
- mini-map
|
|
- node badges for validation status
|
|
- run-state overlays when viewing an executed version
|
|
|
|
The current V1 implementation is simpler than the target canvas UX, but it already follows the same persistence model:
|
|
|
|
- load the latest saved workflow version when the editor opens
|
|
- load project assets and datasets so the run entrypoint can bind a concrete input source
|
|
- keep an unsaved draft in local editor state
|
|
- allow node add and remove operations on the draft
|
|
- save the current draft as a new workflow version
|
|
- auto-save a dirty draft before triggering a run
|
|
- run a workflow-level preflight check against the latest saved version and selected bound asset or dataset before execution
|
|
|
|
The current runtime implementation now also renders the center surface as a real node canvas instead of a static placeholder list:
|
|
|
|
- free node dragging on the canvas
|
|
- left-panel node drag-and-drop into the canvas, in addition to click-to-append
|
|
- drag-to-connect edges between node handles
|
|
- zoom and pan
|
|
- dotted background grid
|
|
- mini-map
|
|
- canvas controls
|
|
- persisted node positions and viewport in `visualGraph`
|
|
- localized inline validation feedback when a connection is rejected
|
|
|
|
The current V1 runtime header in the workflow editor now also treats run input selection as a first-class control:
|
|
|
|
- choose input source type as `asset` or `dataset`
|
|
- choose a concrete project asset or dataset inside that type
|
|
- pass the selected source through preflight and run creation
|
|
- show the resolved source again in run detail as `input sources`, `input assets`, and `input datasets`
|
|
|
|
The current V1 authoring rules intentionally keep the graph model constrained so the workflow stays legible and executable:
|
|
|
|
- source nodes do not accept inbound edges
|
|
- export nodes do not emit outbound edges
|
|
- duplicate edges are blocked
|
|
- self-edges are blocked
|
|
- ordinary nodes may only keep one inbound edge
|
|
- set-operation utility nodes may accept multiple inbound edges
|
|
- cycles are blocked
|
|
|
|
Custom nodes follow the same rule system, but the decision is contract-driven. When a custom Docker node is added to the canvas, the editor seeds its runtime defaults into the draft immediately; if that contract declares `inputMode=multi_asset_set`, the node is treated like a multi-input utility node from the first connection attempt.
|
|
|
|
The current built-in node library also exposes Docker-first runtime defaults in the editor. Most built-ins now render with `docker` preselected, while still allowing the user to override the executor, image, and optional Python code hook from the right-side configuration panel.
|
|
|
|
The runtime header also now exposes a visible `中文 / English` language toggle and the main shell plus workflow authoring surface are translated through a lightweight i18n layer.
|
|
|
|
The workflow entry surface that leads into this editor is also now template-aware:
|
|
|
|
- the Workflows page lists reusable workflow templates for the active project
|
|
- the user can create a project workflow from a template
|
|
- the user can still create a blank workflow directly
|
|
|
|
## Screen 4A: Node Registry Workspace
|
|
|
|
Purpose:
|
|
|
|
- create project-level custom nodes
|
|
- choose Docker image or Dockerfile source
|
|
- declare input and output contract
|
|
- publish the node into the workflow editor node library
|
|
|
|
Core regions:
|
|
|
|
- top: contract summary and authoring guidance
|
|
- left/top: creation form
|
|
- bottom/right: existing custom node list for the active project
|
|
|
|
The creation form should validate node definitions before submit, not only after an API round-trip. In the current V1 direction the UI and API share the same rules for required names, valid image or Dockerfile sources, mandatory `FROM` instructions in Dockerfiles, and invalid category-contract combinations such as `Source + multi_asset_set`.
|
|
|
|
The current V1 direction treats custom nodes as project-scoped runtime extensions, not global plugins. That keeps tenancy and lifecycle simpler while still giving teams a controlled way to bring containerized processing into the canvas.
|
|
|
|
### Right Configuration Panel
|
|
|
|
The right panel is schema-driven.
|
|
|
|
It should render:
|
|
|
|
- node title
|
|
- node description
|
|
- config fields
|
|
- input/output schema summary
|
|
- executor selection
|
|
- runtime policy
|
|
- code hook editor if supported
|
|
- validation errors
|
|
|
|
This panel is critical. It should feel like a structured system console, not a generic form dump.
|
|
|
|
The current right panel also includes a workflow-level `Save As Template` section so an edited graph can be published back into the project template library.
|
|
For project-scoped custom nodes, the right panel should also surface the declared contract summary directly from the node definition, including input mode, output mode, artifact type, and whether the backing runtime came from a Docker image or Dockerfile definition.
|
|
The current V1 direction now also renders the standard EmboFlow input and output envelope preview for selected custom nodes, so container authors can see the exact JSON shape expected by the runtime without leaving the editor.
|
|
|
|
## Screen 5: Workflow Run Detail
|
|
|
|
Purpose:
|
|
|
|
- inspect execution state
|
|
- view DAG progress
|
|
- open task logs
|
|
- inspect task outputs
|
|
- retry failed nodes
|
|
|
|
Recommended layout:
|
|
|
|
- top: run summary and status
|
|
- top: bound input source summary and links back to input assets or datasets
|
|
- center: workflow graph with execution overlays
|
|
- bottom or side drawer: logs and artifacts for selected node
|
|
|
|
V1 run detail should render the selected task as a stable operations panel, not just a raw document dump. The panel should show:
|
|
|
|
- task status and executor
|
|
- task duration and timestamps
|
|
- a concise execution summary
|
|
- separated stdout and stderr sections
|
|
- appended log lines
|
|
- artifact links into Explore
|
|
- a lightweight result preview for quick inspection
|
|
|
|
The run header itself should also show an aggregated summary:
|
|
|
|
- run duration
|
|
- run-level task counts
|
|
- total stdout/stderr line counts
|
|
- failed task ids when present
|
|
|
|
V1 run detail should expose direct operator actions:
|
|
|
|
- `Cancel Run` while queued or running
|
|
- `Retry Run` after a run reaches a terminal state
|
|
- `Retry Task` on a selected failed or cancelled task
|
|
|
|
## Screen 6: Explore Workspace
|
|
|
|
Purpose:
|
|
|
|
- inspect raw or processed outputs outside the canvas authoring context
|
|
- compare source and transformed outputs
|
|
- validate whether a run produced expected results
|
|
|
|
V1 renderer set:
|
|
|
|
- directory tree renderer
|
|
- JSON renderer
|
|
- video renderer
|
|
- dataset summary renderer
|
|
- quality report renderer
|
|
|
|
This workspace should open from:
|
|
|
|
- asset detail
|
|
- workflow node output
|
|
- artifact detail
|
|
|
|
## Screen 7: Label Workspace
|
|
|
|
Purpose:
|
|
|
|
- process annotation tasks
|
|
- review results
|
|
- attach annotations to data outputs
|
|
|
|
V1 should keep this lightweight:
|
|
|
|
- frame labels
|
|
- clip labels
|
|
- temporal segment labels
|
|
- quality tags
|
|
|
|
The label workspace should be able to open from an artifact or dataset version, not only from a workflow node.
|
|
|
|
## Screen 8: Admin Workspace
|
|
|
|
Purpose:
|
|
|
|
- manage members
|
|
- manage storage connections
|
|
- manage plugin enablement
|
|
- inspect audit and runtime settings
|
|
|
|
Suggested sections:
|
|
|
|
- members and roles
|
|
- workspace settings
|
|
- storage connections
|
|
- plugin registry
|
|
- executor policies
|
|
- audit log viewer
|
|
|
|
## Key UX Principles
|
|
|
|
### 1. Separate authoring from inspection
|
|
|
|
Do not overload the canvas with deep preview or annotation workflows. The canvas configures process. Explore and Label workspaces handle dense interaction.
|
|
|
|
### 2. Keep lineage visible
|
|
|
|
Users should be able to move across:
|
|
|
|
- asset
|
|
- workflow
|
|
- run
|
|
- task
|
|
- artifact
|
|
- annotation
|
|
|
|
without losing context.
|
|
|
|
### 3. Prefer explicit system terminology
|
|
|
|
Use consistent object names in the UI:
|
|
|
|
- Asset
|
|
- Dataset
|
|
- Workflow
|
|
- Run
|
|
- Task
|
|
- Artifact
|
|
|
|
## Current Runtime Implementation Notes
|
|
|
|
The current local runtime now exposes these surfaces as a real React application:
|
|
|
|
- Assets list and asset detail
|
|
- Workflows list and workflow editor
|
|
- Runs list with project-scoped history
|
|
- Run detail
|
|
- Explore artifact detail
|
|
|
|
The current implementation uses direct API-driven page loads, lightweight route handling, and incremental polling for active run detail views instead of a deeper client-side state framework.
|
|
|
|
The workflow editor surface now reflects persisted workflow versions instead of a hardcoded sample graph. It exposes draft status, node add and remove actions, reload-latest behavior, asset selection for run binding, and version-save / run-trigger controls against the live API. The right panel also now includes the first writable runtime controls for executor override, runtime target, artifact title, and Python code-hook source. The Runs workspace now exposes project-scoped run history, selected-task artifact links into Explore, and the frozen executor/code-hook snapshot for the selected task.
|
|
|
|
Do not rename the same concept differently across pages.
|
|
|
|
### 4. Make validation obvious before execution
|
|
|
|
Before users run a workflow, the editor should visibly show:
|
|
|
|
- which project asset is currently selected as the run input
|
|
- missing config
|
|
- invalid schema connections
|
|
- unsupported executor choices
|
|
- permission or plugin issues
|
|
|
|
### 5. Keep the product usable on standard screens
|
|
|
|
The canvas and right configuration panel must work on laptop-sized displays. On narrower screens, the right panel may collapse into a drawer.
|
|
|
|
## V1 Visual Direction
|
|
|
|
The UI should communicate:
|
|
|
|
- precision
|
|
- observability
|
|
- traceability
|
|
- strong operator control
|
|
|
|
It should feel closer to a workflow control console than a consumer productivity app.
|
|
|
|
## V1 Non-Goals
|
|
|
|
V1 UI does not need:
|
|
|
|
- real-time multi-user cursor collaboration
|
|
- advanced canvas commenting systems
|
|
- highly customized renderer marketplace UX
|
|
- heavy design polish ahead of workflow clarity
|