297 lines
5.7 KiB
Markdown
297 lines
5.7 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
|
|
- Asset Workspace
|
|
- Canvas Workspace
|
|
- Explore Workspace
|
|
- Label Workspace
|
|
- Admin Workspace
|
|
|
|
## Navigation Model
|
|
|
|
### Global Header
|
|
|
|
Recommended global header content:
|
|
|
|
- workspace switcher
|
|
- project switcher
|
|
- search entry
|
|
- run notifications
|
|
- user menu
|
|
|
|
### Primary Sidebar
|
|
|
|
Recommended primary navigation:
|
|
|
|
- Assets
|
|
- 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.
|
|
|
|
## 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
|
|
|
|
## 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
|
|
|
|
### 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.
|
|
|
|
## 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
|
|
- center: workflow graph with execution overlays
|
|
- bottom or side drawer: logs and artifacts for selected node
|
|
|
|
## 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
|
|
- Plugin
|
|
|
|
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:
|
|
|
|
- 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
|