简介这份Desigo CC用户界面手册由西门子中国有限公司提供是楼宇自动化系统Desigo CC中文培训资料面向需要掌握系统操作与界面配置的工程师、运维人员和集成商。手册聚焦用户如何借助摘要栏、系统浏览器、主窗格与操作窗格完成设备监控、事件处理和日常管理帮助读者在无重叠窗口的工作流概念下快速定位功能并高效处理警报。资源包为1个PDF文件压缩后约2.41MB便于离线查阅或打印适合作为班组培训及现场操作参考。目前已有1577人浏览学习反映出该手册在楼控项目实施和运维场景中的实用价值。内容覆盖GUI布局、过滤与事件处理、系统浏览器自定义视图、最近浏览窗格等核心模块并附有大量界面截图和说明读者可据此快速掌握用户界面各组件之间的调用关系提升日常操作与故障响应效率。1. 先搞清楚这份UI手册解决什么问题Desi GO CC控制中心的用户界面分册02-UserInterfaceBA-CN中文本说直白点就是一份把“屏幕长什么样、页面怎么跳、操作完有什么反馈”全部固定下来的用户界面设计约定。CC即Control Center这一册讲的是控制台前端的全部界面设计规范。很多新人拿到手册习惯从头翻截图实际断断续续看两周既记不住布局也找不回字段定义。这份手册真正有用的读法是把它当成一份多方对账协议产品、前端、测试、实施在同一个界面上吵架时翻手册说话。它解决的是控制台项目里最磨人的口径问题。同一台设备产品文案叫“运行中”接口返回叫“online”实施验收时看到页面上显示的却是灰色状态块三方各执一词。手册把页面布局、交互设计、字段文案、权限矩阵全部落到书面任何一个环节有歧义都能在对应章节找到最终答案。适合刚接手控制台项目的人快速建立整体信息架构认知更适合正在做界面走查、被验收问题反复折腾的工程师把它当检查清单逐页打勾。2. 从导航和布局读手册先建立你的界面地图拿到手册不要急着往后翻页面截图先把前两个部分看完整体界面布局和页面层级关系。控制中心类产品的用户界面设计有一个通用骨架几乎所有监控、运维、设备管理类系统都长一个样Desi GO CC只是在这个骨架上换了业务皮肤。先看懂骨架后面每一个页面的细节才能挂到正确的位置上否则你读到的全是孤立的界面设计稿串不起来。2.1 用户界面的三段式框架侧栏、顶栏、内容区控制中心最常见的用户界面布局是三段式左侧导航栏承担全局菜单和模块切换顶部栏放全局环境切换、用户信息、通知入口和主题模式中间内容区承载当前页面的主体操作。好消息是这份手册的界面设计几乎沿用了这个成熟框架坏消息是越成熟的框架越容易让人忽略约束条件。布局区域核心职责手册里通常会规定的细节实施时最常见的坑侧栏导航模块入口与层级定位菜单层级上限、分组名称、折叠行为菜单超过三层用户迷路顶栏全局状态与用户操作环境标识、通知角标、主题切换位置关键信息被折叠进“更多”内容区当前页面业务操作页面标题、面包屑、Tab切换子页面没有返回入口先说侧栏。手册会规定一级菜单和二级菜单的命名与顺序这个顺序通常不是随便排的而是按照业务操作频率从高频到低频。我一般建议开发直接把手册里的菜单顺序做成配置项不要写死在路由文件里后面调整顺序不用发版。菜单层级方面超过三层的导航在控制中心里几乎必翻车用户点着点着就不知道自己在哪个模块下如果手册里出现了四级菜单你要做的第一件事是找产品确认能不能合并。顶栏最容易被忽略的是环境标识。控制中心经常区分开发环境、测试环境、生产环境如果顶栏没有醒目的环境色带值班人员很容易在生产环境上点了测试按钮。手册里如果给了环境切换交互的规范实施时一定要把环境标识做成全局常量任何页面都不能覆盖它。内容区的面包屑路径要和侧栏菜单严格对应跳转后高亮状态不能丢。2.2 页面层级与信息架构用页面地图定位该读哪一章信息架构部分通常是手册里最薄但最值钱的内容。它会把整个控制中心的页面关系画成一张站点地图。我拿到手册的第一件事是把这张地图抄成一份页面清单每个页面一行记录页面名称、所属模块、入口位置、可见角色。后面做权限核对、走查验收、接口联调全部以这张表为底稿。模块页面名称入口位置可见角色备注仪表盘工作台侧栏一级菜单全部角色登录后默认页监控中心实时监控侧栏-监控中心运维/管理员支持大屏模式监控中心告警记录侧栏-监控中心运维/管理员列表分页设备管理设备列表侧栏-设备管理运维/管理员支持批量操作系统设置用户管理侧栏-系统设置管理员关联角色分配抄这张清单的价值在于用户界面分册不是从第一页读到最后一页的它是按需查阅的参考文档。你需要查“告警记录页的空态怎么设计”先通过页面清单定位到监控中心模块再翻到对应页面编号直接看交互设计说明。没有这张地图你会在几百页的界面设计文档里反复迷失最后放弃翻手册凭感觉开发。页面清单还有一个隐藏用途验收时的覆盖面检查。测试或实施拿这张表逐页点过去能清楚地知道哪些页面还没走查、哪些页面改了但没通知到验收方。我遇到过不止一次开发改了设备详情页的字段布局但验收手册上的截图还是旧的最后以手册为准还是以线上为准吵了一下午。提前把页面清单同步给所有角色这类冲突能少一半。2.3 界面布局的栅格、间距与密度为什么同一种布局在不同分辨率下会走样界面布局出了问题是控制中心项目里最像玄学的一类故障。同一套页面布局在1920宽度的显示器上一切正常换到1366的笔记本上图表被压缩得没法看表格列宽互相挤压按钮换行。多数原因是栅格系统没读透手册。控制中心一般用12列或24列栅格每个页面模块的宽度用列数表达而不是像素才能在不同分辨率下等比缩放。密度档位行高参考间距基数适用场景舒适40px8px工作台展示型页面默认36px8px列表页、表单页紧凑32px4px数据密集的监控表格手册里通常会给出间距基数常见是4的倍数。按钮间距、卡片内边距、表格单元格间距都应该从间距基数推导而不是每个页面单独定义。如果手册没有明确写密度档位我一般建议按“默认”档位开发同时给CSS变量预留切换入口后续要切成紧凑模式只需要改一个变量。分辨率适配的另一个高频坑是缩放。很多时候不是在真实分辨率下出的问题而是用户手动把浏览器缩放到80%或125%。栅格系统用百分比或列宽计算时缩放没有问题一旦某个容器写死了固定像素宽度缩放后就会溢出或者挤压相邻模块。排查这类界面布局问题先看浏览器控制台里哪个元素宽度超过了预期阈值再去找对应组件的样式来源多半是混用了栅格和固定像素。提示读手册里的栅格章节时关注的是它定义了几列、间距基数是多少、有没有断点要求而不是某张截图里的视觉比例。截图比例会随截图尺寸变化栅格定义才是不会被缩放的真相。3. 工作台与监控页仪表盘卡片、实时数据与刷新策略控制中心的用户界面好不好用第一印象全在工作台。值班人员登录后第一屏能不能在三秒内看出“现在有没有异常”决定了这套系统是锦上添花还是核心依赖。手册里工作台和监控页的内容值得逐行读这里既是UI设计最出彩的部分也是实施阶段最容易因为刷新策略和状态色理解不一致而返工的部分。3.1 工作台卡片有哪几类顺序和尺寸怎么定工作台是仪表盘的载体通常由若干卡片组成。卡片类型大致分五类统计卡、状态卡、图表卡、列表卡、快捷操作卡。统计卡给总量和变化趋势状态卡给关键设备的在线离线情况图表卡展示时序趋势和分布列表卡滚动最新告警快捷操作卡放高频入口。控制中心的工作台不会把五类卡片全堆上去一般选三类左右避免首屏信息过载。卡片类型典型内容栅格参考宽度刷新频率建议统计卡设备总数、在线率、今日告警数占4列60秒状态卡关键设备在线/离线占4列10-30秒图表卡CPU趋势、流量分布占8列60秒列表卡最新告警记录占8列30秒快捷操作卡常用功能入口占4列静态卡片排序有一条默认逻辑异常优先高频其次统计最后。也就是说告警状态卡和关键设备状态卡要放在首屏最显眼的位置统计数字往下放。这个排序逻辑应该在手册的交互设计部分有说明如果没有实施时按这个原则和产品确认一遍不要直接按原型图从左到右排。栅格宽度上统计卡做窄幅四列图表卡做宽幅八列保证首屏不滚动就能看到核心状态。工作台的另一个要确认的点是卡片能否自定义布局。控制中心面向不同角色时关注的指标差异很大管理员看整体健康度运维看告警列表。如果手册里定义的是固定布局多角色共用一套布局会造成一部分人的核心信息被挤到下方。我一般建议至少提供两到三套预设布局方案按角色分配或者支持卡片拖拽调整顺序并记住用户偏好。3.2 监控页的阈值配色与刷新策略监控页用的状态色是全站通用的语义体系手册里一定有专门的章节定义。通常的约定是绿色代表正常、运行中、在线黄色代表预警、离线、待确认红色代表严重、故障、告警灰色代表未知、停用、未接入。这套颜色语义不仅用于监控页工作台的状态卡、列表页的状态标签、详情页的字段值着色全部保持一致。状态颜色语义典型业务场景实施时的注意点正常绿色设备运行中、连接正常不能与成功提示蓝色混用预警黄色指标超过软阈值、设备离线需要配套文案说明原因严重红色设备故障、告警触发闪烁动画要克制未知灰色设备未接入、数据缺失不能替代加载中的状态刷新策略是监控页最容易被低估的参数。实时监控页的轮询间隔通常设为10到30秒工作台的统计卡和数据卡片可以放宽到60秒。一个坑是刷新间隔写死在页面里没有做成可配置项业务人员提出“告警需要更快感知”时每次都要發版调整。正确做法是把轮询间隔放到页面的配置文件或后端下发参数中至少预留调整入口。阈值配色还有一个常见争议颜色判断在前端做还是后端做。我见过某个项目里前端拿接口返回的数值自己算颜色结果后端调整了阈值口径前端没同步更新大屏上一片红色误报。规范做法是后端返回的是状态枚举值前端只负责把枚举映射成颜色阈值计算全部收敛在后端前端不做业务判断。3.3 数据没刷新怎么排查UI手册里的状态文案是线索值班人员报“页面卡了数据不涨”这类问题多数是黑匣子。其实用户界面手册里的字段定义表就能帮你快速定位是哪一层出了问题关键在于找到几个关键的状态字段。控制中心监控页一般都有“最后更新时间”字段这个字段是排查刷新问题的最重要线索。现场现象先看哪个字段判断结论数据不涨最后更新时间不动最后更新时间前端轮询或接口异常最后更新时间在走数据不涨数据源标识下游数据源停采页面报错但旧数据还在错误状态提示前端保留旧数据策略生效部分卡片更新部分不更新各卡片数据源字段单卡片接口超时排查顺序一般是这样先看最后更新时间是否在走如果时间在走说明前端轮询和接口链路是通的问题在下游数据采集如果时间停住了打开浏览器开发者工具看接口请求是否在持续发出再确认是前端定时器被挂了还是后端接口超时。UI设计手册里对“数据加载失败时保留旧数据还是显示错误态”通常有明确规定这条定义直接决定用户在故障时的感知。状态文案也是线索。比如某个页面显示了“暂未收到心跳数据”这背后说明前后端之间有明确的心跳机制约定。如果手册里写了这个文案但开发的系统里没有心跳逻辑那一定是前后端实现没对齐。这类排查不需要读代码读界面设计文档里的状态说明就能发现实现缺口。4. 配置与管理页表单校验、列表操作和权限矩阵工作台是门面配置与管理页是里子。控制中心里真正高频使用的其实是设备管理、用户管理、告警规则配置这类后台页面。用户界面手册在配置管理页面上投入的交互设计细节最多但很多开发只看了截图忽略了列表操作约定、字段校验规则和权限矩阵这三块核心内容。这三块恰恰是实施阶段扯皮最多的地方。4.1 列表页的筛选、排序、批量操作怎么定配置管理类页面大多数是列表页结构。列表页的交互设计看似简单实际约定很多筛选项放哪些字段、最多显示几个、超过几个怎么折叠默认排序字段是什么、升序还是降序批量操作按钮放在表格左上角还是右上角行内操作放哪几个按钮。手册里会给出这些交互设计的默认答案开发要做的第一件事是先和产品确认这份默认答案是否直接可用而不是边开发边猜。列表交互项常见默认约定为什么这么定筛选项数量最多5个直接展示超过5个用户注意力分散默认排序按创建时间倒序用户最关心最新数据批量操作表格左上角选中后激活操作入口靠近数据源行内操作编辑、删除、详情高频操作不藏进下拉操作反馈成功/失败用顶部提示条不打断当前列表浏览位置操作按钮的文字描述一致性是小问题大影响的地方。同一套系统里“编辑”和“修改”混用、“删除”和“移除”混用用户会对是否同一个功能产生怀疑。手册里如果有操作名词术语表全局统一按术语表走没有的话实施时自己建一张操作词表列清楚每个操作的触发条件和确认弹窗文案。批量操作还有个必须注意的边界如果列表页跨页选中了数据翻页后之前勾选的是保留还是清空手册没写就趁早确认这个问题在验收时一定会被问。列表页的加载状态也值得核对。翻页加载、筛选加载、删除后的列表刷新分别应该是什么交互状态手册里都有对应的加载动画和空态设计。我见过一个项目实施时把列表加载写成了全屏loading每次翻页都把整个页面遮住用户操作节奏被无情打断。列表页局部加载是控制中心的基本交互设计素养遮罩加载只留给表单提交这类完整事务操作。4.2 表单页的必填规则与校验表达式表单页是开发与UI设计文档“拉扯”最多的地方。一个设备名称字段要不要允许特殊字符端口号范围是1到65535还是1到1024IP地址是否允许通配符这些在开发自测时都测不出来等用户真输了一个特殊字符后端落库失败再回来翻手册才发现校验规则早写了。手册里的字段定义通常包含完整的必填规则和校验表达式实施时直接摘出来映射到前后端校验逻辑。// 控制台用户界面手册中设备管理表单的典型校验表达式示例 const validationRules { // 设备IP四段十进制每段0-255禁止前导零 ip: /^((25[0-5]|2[0-4]\d|1\d{2}|[1-9]?\d)\.){3}(25[0-5]|2[0-4]\d|1\d{2}|[1-9]?\d)$/, // 端口号1-65535不含0和大于65535的非法值 port: /^([0-9]|[1-9]\d{1,3}|[1-5]\d{4}|6[0-4]\d{3}|65[0-4]\d{2}|655[0-2]\d|6553[0-5])$/, // 设备名称字母数字下划线中划线最长32位 name: /^[A-Za-z0-9_-]{1,32}$/, // 告警阈值0.1到100的数值最多两位小数 threshold: /^(100(\.0{1,2})?|(\d{1,2})(\.\d{1,2})?)$/ };这段校验表达式是从手册的字段定义部分摘出来的典型写法实际项目里正则可以原样复制到前端的校验逻辑中。注意ip的正则最后一段不允许前导零意味着“192.168.01.1”会被判定格式错误这是控制中心设备管理的常见约定避免用户把八进制写法当合法IP提交。port正则是手工枚举了从0到65535的区间边界写法看起来很笨重但直接排除掉了大于65535的非法端口比单纯的数字范围判断更精确。字段长度限制通常与数据库字段宽度一一对应。name字段限制32位是因为后端表结构里字段类型就定义了32字节前端如果只做必填校验而不做长度校验输入超长后后端会直接报数据库异常用户看到的就是一个没有友好提示的500错误。threshold字段的写法需要注意的是它只允许0.1到100之间的数值这个范围来自业务语义而不是数据库约束定义这个字段前先确认业务上是否需要大于100的阈值。注意前端校验永远只是体验层。同样的校验规则必须同步在后端实现一份因为绕过前端直接请求接口的调用方式始终存在。手册里的表单校验规则不是写给前端看的是写给整个接口链路看的。4.3 权限矩阵菜单显隐、按钮可用和字段读写控制中心很少有单角色系统通常至少区分普通运维、管理员、审计三类角色。用户界面手册里的权限矩阵定义了每一类角色能看到哪些页面、能操作哪些按钮、能读写哪些字段。实施时很多人只实现了菜单显隐漏掉了页面内按钮级别的权限控制结果就是某角色虽然看不到系统设置菜单但直接输入URL还是能打开用户管理页面或者看得到删除按钮但点了之后后端报权限不足。角色可见页面可执行操作字段读写边界普通运维仪表盘、监控中心、设备管理查看、告警确认、设备详情只读设备参数可写告警备注管理员全部页面全部操作全字段读写审计仪表盘、告警记录只读不可见设备凭据类字段权限矩阵落地的标准做法是前端做菜单和按钮显隐后端做接口数据过滤两层必须都做。前端只解决“界面看不看得到”的用户体验问题后端决定“数据能不能拿到”的安全边界。手册里如果写了“某角色看不到某个按钮”这个描述只完成了UI设计的一半实施时要把它翻译成后端接口的角色校验逻辑否则任何用户直接调接口都能绕过界面限制。字段读写边界是最容易漏掉的细节。比如工单详情页普通运维可以填写处理意见但不能修改工单的优先级和指派人这两个字段在界面上要么置灰要么隐藏。前端实现机会主义做法是将字段设置为disabled但disabled的字段值依然会随表单提交规范做法是提交前剔除无权限字段再由后端二次校验。权限矩阵不能只当文档看实施时要单独做成一份前后端都能读的配置表建议在接口层用拦截器统一校验而不是在每个接口里散落判断逻辑。5. 界面落地常见问题与排查照着手册做反而翻车的现场手册本身没有错但“照着做”这三个字在控制中心项目的落地过程中经常在几个固定环节翻车。这一章写的是我见过最多的三类现场全部按现象、原因、解决的顺序展开你在自己项目里遇到同款问题时可以直接对照着排查。以下内容不含源码分析讲的是定位思路。5.1 权限类菜单不刷新、按钮消失和路由残留现象管理员修改了某角色的权限该角色用户退出后重新登录菜单还是旧的一套新增的菜单入口看不到已回收的菜单却还在。另一个相关现象是按钮权限控制混乱某些角色能看到按钮但点击后报无权限另一些角色看不到按钮。原因菜单和路由被前端缓存了。很多控制台前端框架在登录时会把菜单和路由一次性拉下来存到本地状态后续角色权限变更后用户再次登录时走的是缓存而不是重新请求权限接口。按钮消失类问题多半是权限码比对逻辑写反或者前端判断用的是角色名称而接口返回的是角色ID两边对不上。解决登录成功的回调里强制重新拉取当前用户权限和菜单配置不能用缓存。路由表在权限变更后重建并替换不要做增量更新。按钮级权限建议用统一的权限指令或高阶组件封装全局只维护一份权限码映射表不要在每个页面里手写判断。排查按钮消失又恢复的间歇性问题时先确认前端拿到的角色标识和后端返回的是同一套编码体系。5.2 数据类保存成功但列表不动、翻页把新数据丢了现象新增一条设备记录接口返回200页面弹出“保存成功”但列表里看不到新增数据。另一种情况是列表停在第三页操作完某条数据后刷新第一页的数据变了但当前页面仍然停留在旧的第三页。原因写操作成功之后没有触发列表重新加载。很多前端的列表页数据只在初始化时加载一次后续操作成功只做提示没有主动刷新列表数据。翻页丢数据的问题属于刷新策略设计缺位新增数据默认排在列表最前面刷新后数据应该回到第一页但前端直接在当前页码重新请求而当前页已经超出新数据的总页数于是列表渲染为空或者保持旧数据。解决写操作成功的回调里统一调用列表刷新函数并且把页码重置到第一页。如果产品要求保存后停留在当前浏览位置需要后端支持基于游标的分页返回当前页在整体排序中的位置。排查时先确认列表数据是从接口拉取还是本地拼接本地拼接的数据在多人协同场景下会互相覆盖这已经不属于UI层能解决的范畴。5.3 样式类主题不一致、缩放走样、状态色对不上现象系统提供深色主题页面主体部分切换正常但弹窗、下拉列表、日期选择器还是白底。另一个常见现象是浏览器缩放后布局溢出、按钮叠行。状态色方面监控页的告警显示红色但导出报表里同一状态显示成了橙色。原因弹窗类组件默认挂载在页面根节点之外脱离了主题作用域容器。如果主题变量只作用在某个页面的根节点上弹窗自然不会继承主题。缩放走样是因为栅格布局里混用了固定像素宽度的容器。状态色差异往往来自两套颜色定义一套在UI设计手册里另一套在图表组件或报表组件的默认主题里。解决主题变量提升到HTML根节点页面和弹窗都通过CSS变量引用不要在不同组件里写死颜色值。缩放的排查重点是用浏览器开发者工具找出哪个元素的实际渲染宽度超出了预期然后把固定像素改成栅格比例或百分比。状态色统一的做法是建一张颜色映射表前端组件、图表、导出报表共用同一个枚举映射不允许各写各的颜色值。我见过某个项目在导出功能里把警告色写成了橙红前端页面里用的是纯红最后统一到同一张映射表才消停。排查这类界面问题有一个固定顺序先看浏览器控制台有无报错再看接口返回是否正常最后才怀疑前端渲染。大多数“页面不动了”“显示不对了”的问题最终查下来都是数据层或缓存层的问题前端渲染只是背锅侠。6. 用手册做一次可复制的界面走查三张表就够了界面走查最忌讳逐页对着截图比颜色。我拿到手册后习惯先建三张表把整个界面的检查工作变成可复制的流程而不是每次靠肉眼碰运气。第一张表是页面清单把前面说的站点地图抄成表格每行一个页面记录入口、可见角色、页面类型。第二张表是交互状态表对每个关键操作检查四种结果成功、失败、权限不足、网络异常每个结果页面上有没有对应提示。第三张表是字段与权限核对表把配置管理页的每个字段列出来对照手册确认必填规则、校验表达式、可见角色、可写角色。页面空态设计加载态设计错误态设计权限不足提示结论设备列表无数据插图局部骨架屏顶部错误条按钮隐藏待补空态告警记录无数据插图局部骨架屏页面错误态页面不可见通过用户管理无数据插图列表内loading顶部错误条菜单隐藏通过三张表建好后走查就是从第一张表开始逐页把另两张表过一遍每发现一个问题就在结论列标注。测试和开发之间的沟通从“感觉哪里不对”变成“设备列表空态缺失见走查表第3行”效率提升非常明显。这套方法不依赖某个具体项目的特殊配置任何拿到用户界面设计文档的人都能直接用。我之前接过一个设备管理Demo类的小项目开发说手册里没有空态设计结果列表没数据时页面上只显示一个空白的表格区域客户截图反馈“页面坏了”。后来我把手册通读一遍才发现空态设计在交互设计说明的通用章节里不在具体页面的截图中。从那以后我养成了一个习惯拿到任何一份UI手册先抄页面清单和状态清单再看具体页面。欠的文档债最后一定会换算成联调和验收的加班时间还回来。希望帮到你。本文还有配套的精品资源点击获取