AUTO-MAS 的 UI 设计与用户交互存在许多问题

[XcantloadX]

严重的问题

• 缺少拖拽提示
  这个列表支持拖拽排序，但是视觉上完全看不出来。用户只有把光标移上去后，光标改变，才会意识到这里可以拖拽。

  

  这里更混乱了，外层卡片列表可拖拽，内层子列表也可拖拽，而且都没有任何提示。

  

  一般情况下会在 list item 的最左侧加上图标，暗示用户这里可以拖拽。

  

  例如

  

• 可拖拽区域过宽
  目前整个 item 都会触发拖拽行为。即便用户点击是的 item 上的一个可交互元素，也会触发整个 item 的拖动动画。

  

  更合理的设计应该是加上前面的拖拽图标后，仅允许图标以及周围一部分区域触发拖拽行为。

不严重的问题

以下是个人偏好比较强的观点，不喜可跳过。

• 1 无用 Tooltip
  图标和按钮文本的含义已经足够明确了。
  

• 2 无用 Toast
  Toggle 按钮本身的状态就足够提示当前是否开启了。除非出错，否则没必要提示。
  而且开关这个也不是什么特别重要的事情，完全没必要特地弹出提示。
  

• 3 风格不统一
  例如这里的阴影。
  

  例如这里的光标。
  
  

  （PS：个人倾向于 ？图标不使用手型，除非点击后会弹出更进一步的提示）

  以及这里的光标。对于拖拽暗示，一个是手型，一个是移动型
  
  

  还有这里的容器。
  前面有边框，后面无边框。
  

• 4 动画浮夸
  过于滥用放大与浮动动画导致 AI 味非常浓。
  
  

  这个表单有两列，在窗口最大化的情况下往往会变得非常宽。用户如果要读完所有信息，视线需要不断左右来回移动。如果改成单列，视线只需要上下移动，效率更高。
  （不过完全改成单列会导致横向空间利用不足，这里需要平衡一下）

  不过我觉得这里更严重的问题是 label 和表单元素几乎一模一样，导致阅读效率更低了。

  又比如：
  

  新增、删除和重命名都属于”元编辑“（PS 这个词是我刚造的，不用太在意），编辑的是元数据而不是计划本身。
  设计的一条原则之一就是相关的东西放一起，不相关的东西不应该放一起。
  我个人认为这三个操作是高度相关的，理应放在一起，而不是现在这样散开。

  再例如：
  切换调度，与增删调度隔了这么远。
  用户第一次看见这里的 UI 时，由于从左往右、从上往下读，第一眼往往看到的是 Tab，然后就继续往下看内容，很可能忽略掉右侧的两个按钮，导致认为调度不能增删。
  

• 6 滥用标签（Tag）
  （这好像也是 AI 喜欢做的事？）

• 5 布局不合理
  例如这里：
  

  Tag 往往是可枚举的，即只有有限的可能性。下面这些都不适合用 Tag：
  
  
  

• 7 可交互元素但是看起来就像不可交互
  例如，这里完全看不出来可以修改
  
  

• 8 自相矛盾
  第一眼看上去很迷惑，到底是成功了还是失败了？
  

  「完成」根本不需要。如果调度进行中，放一个 loading 或 spinner 动画，完成后不展示动画即可。
  

  个人观点，这里全部用图标可能比较好，而不是 Tag。

• 9 有些地方缺少 loading 态
  比如这里
  

• 10 拖拽动画不合理
  这个列表，拖拽 item 时有两个「虚影」，一个是 placeholder item，一个是用户抓住的 item。这是混杂了两种不同风格的拖拽动画。
  

  可以在下面的两个风格里二选一
  https://atlassian.design/components/pragmatic-drag-and-drop/design-guidelines/#drop-indicator
  
  https://angular.dev/guide/drag-drop#create-a-list-of-reorderable-draggable-elements
  

• 11 面包屑导航不合理
  编辑脚本和编辑用户是两个完全不相干的功能。
  无法从编辑脚本页面进入编辑用户，但是你却可以通过编辑用户页面的面包屑导航退回到编辑脚本页面。
  

• 12 本末倒置
  这是「选择配置模板」对话框。绝大部分人只关心自己的脚本能不能用，只有没事干人的才会刻意看现在支持了多少个脚本。
  因此应该强调搜索框，弱化搜索结果数量提示。
  

• 13 冗余步骤
  确定（甚至包括取消）完全是多余的。直接设计为点击分类后自动进入下一步即可，不然用户还要多点一次按钮。
  

---

最后，我知道维护一个美观且 UX 良好的 UI 非常耗精力，大部分精力可能都放在了实现主要功能上。写这些也不是挑刺，我是真心希望 AUTO-MAS 能成为一个好用的多脚本管理工具。我一直也都想写一个类似的东西来着，如果有现成的工具我就不用重复造轮子了。

[ClozyA]

非常感谢提出问题～
后续版本会逐步修复这些问题的

[DLmaster361]

猜对了，由于项目组里没有一个前端高手，以及我们需要快速拿出一个可用、高性能且美观的界面，这个项目的前端的AI含量是100%。

当前前端含有大量我们自己都不满意的UI设计，但要如何修改才能更合适，我们没有多少头绪，非常感谢您的帮忙（如果能帮忙捯饬一下前端代码，那就太感谢了）。

受限于精力与部分底层库限制，这些问题不会立刻得到解决，甚至无法解决，我们会尽可能修正一些错误，但对于一些问题（如 6、 7 ），我们即使意识到这里存在缺陷，也不清楚应当如何设计改进，希望您能加入交流群或继续通过issues提供指导~

目前我唯一认为没有必要修改的是 3 中的最后一项，模拟器的设置卡片是可编辑信息卡片，而模拟器实例表单只是一个展示页，不可编辑，因此在界面上进行区域划分并使用了不同的样式，这是正常的。

感谢您为我们提供了这些改进意见。

[XcantloadX]

的确有些问题不是很好改，不管是从设计上还是实现上。我不是设计方面的专业人士，即便这里我指出了一些设计问题，怎么解决仍然没太大的头绪。如果之后我想到了合适的设计，我会在这下面回复（或者新开 issue）。

刚才看了下代码，其实代码也挺多问题的，不少页面都有一两千行了。
如果之后有空我可能会尝试先解决一些简单的问题。

---

偏个题，不知道你们知不知道 Vue Devtools，可以查看 vue 组件树、查看与修改组件状态、查看路由、路由跳转、路由历史录制。如果你用了 pinia 来管理全局状态，也能一起查看与修改。（PS 项目里目前装了 pinia 但是没用）

Vue Devtools 入口我记得在常规 Web 项目里是直接展示在页面上的，不知道这里 Electron 项目为什么没有。

https://devtools.vuejs.org/guide/standalone

或者

https://www.electronjs.org/docs/latest/tutorial/devtools-extension （未验证）

[XcantloadX]

Vue Devtools 入口我记得在常规 Web 项目里是直接展示在页面上的，不知道这里 Electron 项目为什么没有。

我知道为什么了，需要配置 Vite 插件才行，现在项目里没配置。

https://devtools.vuejs.org/guide/vite-plugin

[ClozyA]

Vue Devtools 入口我记得在常规 Web 项目里是直接展示在页面上的，不知道这里 Electron 项目为什么没有。

我知道为什么了，需要配置 Vite 插件才行，现在项目里没配置。

https://devtools.vuejs.org/guide/vite-plugin

感谢提醒~明天我试试看

[Alirea10]

的确有些问题不是很好改，不管是从设计上还是实现上。我不是设计方面的专业人士，即便这里我指出了一些设计问题，怎么解决仍然没太大的头绪。如果之后我想到了合适的设计，我会在这下面回复（或者新开 issue）。

刚才看了下代码，其实代码也挺多问题的，不少页面都有一两千行了。 如果之后有空我可能会尝试先解决一些简单的问题。

偏个题，不知道你们知不知道 Vue Devtools，可以查看 vue 组件树、查看与修改组件状态、查看路由、路由跳转、路由历史录制。如果你用了 pinia 来管理全局状态，也能一起查看与修改。（PS 项目里目前装了 pinia 但是没用）

Vue Devtools 入口我记得在常规 Web 项目里是直接展示在页面上的，不知道这里 Electron 项目为什么没有。

https://devtools.vuejs.org/guide/standalone

或者

https://www.electronjs.org/docs/latest/tutorial/devtools-extension （未验证）

你所说的Devtools在开发环境里面是有的。我们的发行版项目默认没有给Vue devtools
如果你使用npm run dev来启动我们的项目，你将能看到一个调试面板，具有部分devtools功能
至于pinia，是的，确实没用，当时用AI做出了大量的页面，后面遇到了一些问题，发现pinia可以很好的处理这个数据传递的问题，但是事已至此，我们只是引入了但没广泛使用。
总而言之，我们的前端页面确实有许多问题，总体是一个能用的水平，我们十分欢迎各种建议和pr，甚至是重构。

会有人想用Element Plus重构一个新UI吗（？