Existing Software UI Redesign
已有软件和上位机界面如何改版：保留操作流程与状态反馈
已有软件能正常使用，界面改版应先记录常用任务、角色权限、输入输出与异常反馈，再明确本次调整到哪一层。页面可以重新组织、控件可以更新，但原有业务判断和操作结果需要有依据地保留。对于上位机和设备监控软件，界面升级不默认包含PLC、DCS、设备驱动或控制逻辑改造。
阅读目录7 个章节
先保存旧页面，也保存完成任务的全过程
仅有几张正常状态的截图，不足以说明原软件怎样工作。可以选择一组高频任务，例如查询一条记录、切换设备、查看告警、填写备注或导出结果，按实际角色走一遍，记录操作入口、输入条件、返回信息和完成标志。还要保留取消、无权限、数据为空、网络中断等分支。
建议把基线整理成“角色—任务—原入口—操作步骤—预期结果—特殊状态”清单，并关联经授权的截图或录屏。快捷键、扫码输入、焦点顺序、默认筛选、表格列和打印格式等习惯也应记录。不能只因某个入口不够美观，就在新版中删除它承载的工作。
例如这张检测工作台案例图把图像、连接状态与启停状态分开组织。若评估同类软件的界面升级，就需要分别问清：切换相机时哪些内容跟随变化、未连接时哪些入口可用、保存的是哪张图像。截图能帮助发现要核对的入口，实际行为仍需结合原软件与接口说明确认。
把美化、信息组织、交互调整与前端替换分开报价
“界面升级”可能是统一视觉，也可能要重写前端。先说清哪类变化被纳入，设计与开发才能使用同一份范围；只做视觉稿时，也应交付必要的状态说明，便于原开发团队准确实现。
左右滚动表格，查看完整对照内容。
| 改版层次 | 可以包含的工作 | 需要额外确认的边界 |
|---|---|---|
| 视觉美化 | 字体、间距、色彩、图标与组件外观统一。 | 保留状态含义和可读性；改变颜色前核对原有业务约定。 |
| 信息组织 | 导航、页面分组、字段层级、表格与详情布局。 | 旧入口对应到哪里，筛选、定位与返回路径是否仍可用。 |
| 交互调整 | 减少重复输入，补充校验、反馈、确认与错误恢复路径。 | 审批、权限和业务规则的变化是否属于本次需求。 |
| 前端替换 | 实现新版页面，连接约定接口并适配目标运行环境。 | 旧框架、组件、接口和本机依赖是否可用；后台、驱动及控制改造另列范围。 |
不必因界面老旧就默认重写全部系统。先选择一个代表页面验证现有框架能否支持目标设计，再决定保留、局部替换或重新实现哪些部分。反过来，如果显示逻辑与设备通信紧密耦合，也不能仅凭效果图承诺“只换皮肤就能完成”。
完整设计加载、失败、禁用与等待反馈的状态
正常页面只说明理想条件。实际改版至少应为每个关键任务标明当前状态、可执行动作、需要等待的反馈及下一步。按钮外观可以统一，但不同原因导致的不可操作状态应让用户理解。
左右滚动表格，查看完整对照内容。
| 状态 | 新版应表达什么 | 对照原系统检查什么 |
|---|---|---|
| 加载中 | 正在读取哪个对象；已有内容是否暂时保留。 | 切换对象后，旧结果会不会被误认为新对象的数据。 |
| 空数据 | 当前条件无记录，或数据尚未提供。 | 不能把接口失败、无权限都显示成“暂无数据”。 |
| 失败 | 失败发生在哪一步，已知结果与可继续路径。 | 重试是否可能重复写入；状态不明时先查询结果。 |
| 禁用或无权限 | 缺少什么权限或前置条件，是否有查看原因的入口。 | 权限判断与原系统一致，不只是把按钮变灰。 |
| 已提交、待反馈 | 请求已发出，但业务结果或设备反馈尚未确认。 | 不因点击成功就显示任务完成，也不盲目重复提交。 |
| 告警知悉、确认与恢复 | 分别显示原系统提供的事件与处置状态。 | 不能把关闭弹窗、确认收到、采取措施和异常恢复合成一个状态。 |
以OPC UA报警模型为例，Part 9的AcknowledgeableConditionType区分AckedState与可选的ConfirmedState。其确认模型说明用后者区分“已经知悉事件”和“已采取应对措施”；AlarmConditionType另用ActiveState表达异常是否仍然存在。
这些术语用于说明状态不应混淆，并非要求所有软件照搬字段名，也不表明案例使用OPC UA。改版时应以原系统的状态字典和实际接口为准，把状态转换、可操作条件和文案一起核对，避免视觉统一后丢失业务含义。
用一个虚构任务，检查改版是否保留了行为
以下是教学用交互对照，不是客户改版成果。假设操作员需要查找一条记录、打开详情并保存备注，可用相同角色和样例逐步比较：
左右滚动表格，查看完整对照内容。
| 假设原交互 | 拟调整的呈现方式 | 必须保留或共同确认的行为 |
|---|---|---|
| 筛选项分散，查询后显示结果列表。 | 将常用条件集中，显示当前筛选摘要。 | 查询范围、默认条件与返回结果不因重排改变；返回列表保留已选条件。 |
| 点击记录后弹出详情，加载时暂时空白。 | 显示记录身份与加载提示，完成后呈现详情。 | 快速切换记录时，迟到响应不能覆盖当前选中对象。 |
| 点击保存备注后等待返回结果。 | 区分待提交、提交中、成功和失败。 | 保存内容、权限和返回结果保持对应；超时结果不明时先核对，不默认再次提交。 |
对照的重点是相同输入能否得到约定结果，以及原来必须经过的确认、校验和权限判断是否保留。若准备减少步骤或调整默认条件，应把它作为明确的交互变更让业务人员确认，再更新回归用例，不能藏在“美化”范围里。
适配目标终端，同时保留可读与可操作的路径
旧上位机可能运行在固定窗口、触摸屏或特定操作系统中，业务软件也可能包含扫码、键盘、打印和本地文件操作。改版前应记录实际运行环境；若希望从桌面程序改为浏览器访问，需要另行验证这些依赖，不从软件外观判断技术栈。物理尺寸、输出比例与观看距离可继续按分辨率与屏幕适配指南准备。
对于Web界面，W3C的WCAG 2.2 Reflow说明强调缩小视口或放大内容时不丢失信息和功能；需要二维布局才能理解或使用的图、表等内容有相应例外。例外只针对需要二维布局的部分，不能据此让整页说明文字也难以阅读。
因此，可以给复杂流程图或数据表保留独立查看区域，让说明、表单和反馈信息正常换行。触摸端还要实测按钮、滚动和弹窗是否互相遮挡；键盘使用场景要核对焦点与返回路径。具体适配能力以目标终端测试为准，不能只展示一张设计稿就认定所有终端已通过。
先替换一组页面，再用同一任务逐批核对
选择有代表性、依赖关系清楚的一组页面，先完成设计与运行验证，再决定扩展范围。可以按下面的顺序推进：
- 确定试点：选定角色、页面、输入样例、必须保留的功能及本次允许调整的行为，保存旧版基线。
- 验证设计：覆盖正常与异常状态，让实际使用人员确认字段位置、操作顺序与提示含义。
- 完成运行对照：在约定测试环境中，用同一角色、样例和任务核对旧版与新版的结果、权限、日志及失败路径。
- 确认切换条件：记录版本、影响页面、切换窗口、未解决问题与回退条件；批次之间保留已验证的公共组件和行为约定。
新旧页面并行查看可以帮助对照，但会写入业务数据或影响设备的操作应由指定入口执行，避免为了比较而重复触发。涉及后台数据结构变化时，还应确认兼容与回退条件；保留一份旧页面文件，不等于一定能恢复完整业务环境。
可约定的成果包括页面与行为清单、原型和可编辑设计稿、组件状态说明、约定页面的前端实现、测试记录与切换说明。实际交付取决于仅做设计、设计加实现或还包括其他改造，不能把这些选项写成每个项目已交付的固定清单。
北京泓珊科技可结合已有大屏、业务软件和上位机资料评估界面设计与开发范围，服务不限定行业。可以先看只做设计、已有界面改版与前端实现的合作范围；需要调整业务功能时，再对照软件定制服务。提供经授权的旧页面、常用任务、目标终端与最想改善的问题，即可沟通界面改版范围。
常见问题
没有原软件源码，还能做界面改版吗？
可以先做流程盘点、原型与视觉方案，但能否直接修改运行页面取决于现有界面的扩展能力、接口和授权条件。需要原开发方配合或重新实现的部分，应在评估后明确，不能仅凭截图承诺直接替换。
只想让界面更清楚，必须更换后台或设备控制程序吗？
不一定。可以先在保留既有业务与控制职责的前提下评估视觉、布局和状态提示。若实现依赖后台、驱动或控制逻辑变化，再把相应工作单独确认。
怎样判断新版更方便，同时没有丢失原功能？
用相同角色、样例和任务走通新旧页面，核对结果、权限及异常状态，并记录完成步骤、误操作和使用人员反馈。便利性与功能保留应分别有依据，不能只以视觉偏好判断。