You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
[Discussion] OpenViking WebConsole 设计现状、问题与优化方案讨论
大家好，想发起一个关于 OpenViking WebConsole 的设计讨论。
最近看了一下当前 Console 的实现和使用方式，感觉它已经具备了一些很好的基础能力，比如：
ls/tree/stat/read）但整体上，它更像一个“面向开发者的 API 控制台 / 调试面板”，距离一个真正好用、可扩展、可对外展示的 WebConsole，还有比较大的优化空间。
这篇 Discussion 想集中讨论三件事：
一、我对当前 WebConsole 的整体判断
我认为当前 Console 的优点是：
但目前也存在一个比较明显的问题：
它更偏“功能集合页”，而不是“围绕用户任务设计的产品界面”。
也就是说，现在的 Console 更像是把已有 API 能力逐项放进页面里了，但还没有形成一个清晰的产品心智模型：
如果这些问题不先想清楚，后面功能越堆越多，Console 只会越来越像“调试后台”，而不是 OpenViking 的正式控制台。
二、当前存在的问题
1. 产品定位不够清晰
现在的 WebConsole 混合了几种不同角色的需求：
这些角色关注点完全不同，但目前都被放在同一个壳里，导致：
问题本质：产品定位没有收敛。
2. 功能组织方式偏 API 导向，而不是任务导向
当前模块像是：
这套结构从实现角度很好理解，但从用户角度未必自然。
例如一个真实任务可能是：
用户想的是“任务链路”，不是“先点 Find 再点 Monitor 再点 Settings”。
问题本质：功能是按接口拆分的，不是按工作流组织的。
3. 信息呈现仍然偏“原始响应”，可读性和决策支持不足
当前 Console 的一个明显特点是：很多操作最后落到统一 Result 面板，展示原始 JSON 或接近原始数据。
这对调试很有帮助，但对产品化不够友好：
一个成熟 Console 应该优先展示：
原始 JSON 更适合作为二级信息存在，而不是主信息层。
4. 缺少围绕 OpenViking 核心价值的“可视化工作台”
OpenViking 不是普通 CRUD 系统，它最有价值的点包括：
但当前 Console 对这些能力的呈现还不够“产品化”。
例如检索相关能力，理想状态下应该能看到：
如果只是显示结果列表或原始返回，价值没有被真正放大。
5. 写操作安全性有基础，但交互体验还不够完善
目前写能力更多依赖：
这已经是好的开始，但从控制台产品角度，还可以更进一步：
否则用户很容易出现“我以为只是看看，结果其实能改”的认知偏差。
6. UI 已经有基础风格，但还偏工程化，缺少产品层级
当前 UI 并不差，已经有统一的暗色风格、侧边导航、结果面板、表格和状态标签。
但整体体验仍然偏“开发工具感”：
简单说：能用，但还没到“好用、清楚、让人愿意持续使用”的程度。
三、我建议的新方案
我建议把 OpenViking WebConsole 从“功能集合页”升级为：
一个面向开发者 / 运维 / 管理员的统一控制台（Control Plane + Workspace）。
它不只是调用 API，而是帮助用户完成以下核心任务：
四、建议的新信息架构
我建议把一级导航调整为更贴近任务的结构：
1. Overview
用于展示系统总览：
这会让 Console 第一次真正有“首页”。
2. Data Explorer
整合当前的 FileSystem + Content Read：
目标是把“浏览数据”做成一个完整工作台，而不是一个纯表格页。
3. Retrieval Lab
整合当前 Find，并强化成检索实验台：
这是 OpenViking 最值得做深的页面之一，因为它最能体现系统差异化价值。
4. Ingestion Center
整合 Add Resource / Upload / 处理状态：
现在的 Add Resource 更像表单，新方案应该更像“导入任务中心”。
5. Memory Workspace
把 Add Memory 从一个简单 textarea 升级为更完整的 memory 工作区：
6. Tenant & Access
聚焦多租户和权限管理：
这个模块建议保持“强管理后台”的风格，和数据浏览场景适度区分。
7. Observe & Diagnose
整合当前 Monitor，并扩展成观察诊断页：
这里应该成为“出了问题先来看这里”的页面。
五、UI 层面的设计原则建议
1. 从“结果面板”改成“工作台 + 详情面板”
不要让所有结果都堆到统一输出区。
建议改为三层结构：
这样既保留调试能力，又不会让原始输出压过主界面。
2. 原始 JSON 降级为二级信息
默认先展示：
再提供：
这样能兼顾产品体验和开发调试。
3. 强化状态设计
建议统一设计这些状态：
Console 不是单纯“能点按钮”就够了，状态设计会直接决定可用性。
4. 强化“当前上下文”感知
例如在顶栏或页面头部长期展示：
这样能显著降低误操作和理解成本。
5. 让新用户也能用，而不只是熟悉 API 的人
可以增加：
现在的 Console 更适合“知道自己要调用什么的人”，未来应该也适合“想通过界面理解 OpenViking 的人”。
六、建议的演进原则
我建议下一版不要一次做成“大而全”，而是分阶段推进：
Phase 1：先统一定位和信息架构
先回答清楚：
这是最重要的一步。
Phase 2：优先重做 3 个高价值页面
我建议优先投入：
因为这三块最能体现 OpenViking 的价值，也最容易让用户感受到产品提升。
Phase 3：补全管理与可观测性
再逐步完善：
七、我个人的核心建议
如果只说一句话，我的建议是：
下一版 WebConsole 不要继续沿着“给每个 API 做一个面板”的方向演进，而应该转向“围绕关键任务流设计工作台”。
也就是从：
转向：
八、想请大家一起讨论的问题
欢迎大家围绕这些问题讨论：
Beta Was this translation helpful? Give feedback.
All reactions