慧视HuiVision体验打磨手记：微交互与“看不见的美学”

在前两轮迭代中我们完成了首页、设置、出行、会视四个页面的无障碍视觉重构打造了一套高对比度、强视觉重心的暗色霓虹界面。但很快我们意识到——一个真正“趁手”的辅助工具光有静态界面远远不够。交互反馈的质量决定了视障用户对系统的信任感。这一次我们把刀锋对准了三块体验短板识别结果展示、按钮状态反馈、危险等级提示。一、残视者的美学为什么一款盲人App也要“好看”不止一次有成员问“为盲人做的应用有必要在美学上花这么多心思吗”我们的答案是有必要而且美学本身就是无障碍的一部分。视障群体中仅有不到10%是全盲绝大多数人保有不同程度的残余视力。对他们而言模糊的视野中一个高对比度、大尺寸、发光明确的按钮就是安全感本身。更极致的色彩、更考究的动效不是为了炫技而是为了在那片混沌中争抢哪怕百分之一的辨识度。另外任何辅助技术的使用者都不希望自己“显得特殊”。当旁人瞥见一个设计精良、充满科技感的界面时投来的不是同情而是欣赏。让辅助工具变美也是在捍卫使用者的尊严。正是带着这样的理解我们开始打磨每一个微小的交互瞬间。二、结果详情面板拒绝干瘪弹窗构建“可听可感”的信息容器之前的识别结果我们使用wx.showModal直接弹出一段文字。对于明眼人来说这只是一个简陋的模态框但对于视障用户这意味着信息不可追溯弹窗关闭后内容就消失了无法再次审阅。无语音控制如果用户想重听只能重新拍照识别。视觉毫无重心系统默认的细黑字在户外强光下几乎看不见。2.1 半屏浮层熟悉的心智模型我们设计了一个从底部滑出的半屏面板最大高度 70vh。这种形式与 iOS/Android 系统通知、音乐控制面板一致用户无需学习即可掌握“向下滑动关闭”的手势意图。面板采用了与整套界面统一的深色渐变毛玻璃底板顶部有一条细窄的拖拽指示条。这个看似装饰性的横条在屏幕阅读器下会提示“可滑动的面板”是重要的触觉锚点。2.2 信息分层摘要先行细节在后面板内部分为两个信息层级摘要区青蓝底色的半透明卡片字号 34rpx加粗展示前 50 字关键描述。这是用户语音播报后仍想“回看一眼”的核心信息。详细区暗色底卡片展示完整识别文本字号略小供需要确认细节时滚动阅读。这种递进式设计借鉴了新闻写作的“倒金字塔”结构让用户在最短时间内获取最重要的内容。2.3 语音播放控件看得见的波形为了看不见的时刻面板底部集成了一套完整的语音播放控件我们将测试用界面完整实现为后续接口对接做好准备。控件包括模拟波形条8 根竖条通过 CSS 动画模拟音频波动。播放时波形活跃跳动暂停时静默低频。对于低视力用户波形是“声音正在播放”的视觉替代对于旁观的家人/陪护他们可以直观判断设备是否在正常播报。进度条与时间当前时间和总时长分别显示在进度条两侧字体 24rpx低权重但可辨。进度条使用微信原生slider并设置了醒目的青蓝色激活轨道。播放/暂停按钮大圆形播放时青蓝渐变暂停时橙红渐变。按钮尺寸达到 100rpx即使手指粗糙也可轻松命中。语速调节0.8x / 1.0x / 1.2x 三档胶囊按钮选中态用青蓝背景高亮。这是我们在调研中发现的一个刚需——视障用户常需要根据环境噪声调整播报语速安静时 1.0x 舒适嘈杂时 1.2x 才能听清。这一整套语音控件理念上完全为听觉设计但视觉上同样提供了完整的状态映射。这就是我们坚持美学的原因——当听觉通道被占用如用户在与旁人交谈时视觉通道必须能独立承担信息传递的功能。三、按钮微交互状态必须“说”出来3.1 加载态让等待不再焦虑之前的拍照按钮点击后虽然会弹出系统loading但按钮本身毫无变化。如果用户网络较差会出现“点了没反应”的错觉导致重复点击甚至怀疑应用卡死。我们为按钮增加了三种状态的联动正常态青蓝渐变文字“快速分析”图标“◎”。加载态按钮整体变灰透明度降至 0.6文字变为“识别中...”图标变为“⏳”。同时通过bindtap{{isLoading ? : quickAnalysis}}动态解绑点击事件从根源上防止重复提交。恢复态请求结束无论成功/失败按钮瞬间恢复。这个看似微小的改动涉及data中isLoading字段的定义、uploadAndAnalyze中请求前后setData的调用、WXML 中类名/事件/文字的动态绑定以及 WXSS 中.btn-disabled样式的编写。一个加载态要打通 JS 数据层、WXML 模板层、WXSS 样式层三方协作这是小程序开发中典型的状态管理实践。3.2 危险闪烁当眼睛看不见光还能穿透在出行场景中如果前方识别到悬空物或深坑系统需要以最强烈的方式警告用户。之前我们只用了震动wx.vibrateLong但震动的缺点在于——如果手机放在包里或桌面触觉通道将失效。我们增加了一条视觉-触觉双重通道当危险等级为warning或danger时整个界面闪烁红色。具体实现WXML 最外层容器动态绑定danger-flash类。CSS 使用keyframes定义 0.5 秒一个周期的红影闪烁重复 3 次。红影采用外扩发光 内阴影双方案在屏幕边缘形成一圈80rpx 宽的红光晕同时背景微微泛红。JS 在解析到危险等级后自动setData({ dangerFlash: true })并在 1.5 秒后自动清除。这个功能的难点在于闪烁的强度必须足以穿透残余视力用户的感知阈但又不能过于刺激导致光敏不适。我们反复调整了rgba的透明度、扩散距离、动画速度最终选择了一个“明显但不刺眼”的平衡点。同时闪烁结束后没有残留效果避免干扰后续操作。四、组件化思维一次封装全应用复用结果面板并不是仅在首页使用——出行页、会视页也都需要展示识别结果。我们将面板设计为微信小程序自定义组件放置在components/result-panel/下通过properties接收visible、summary、detail、audioUrl、level参数通过triggerEvent(close)向父页面通知关闭。这意味着未来任何页面只需引入组件、传入数据即可拥有完整的展示和语音能力无需重复编写 UI 逻辑。这是我们在项目中期着重要建立的工程化习惯——让代码可复用、可维护。五、工作量不大心力不少改动项涉及文件说明结果面板组件新建 4 个文件WXML / WXSS / JS / JSON完整语音控件首页集成面板修改 index.js / wxml / wxss新增 6 个 data 字段修改 uploadAndAnalyze添加组件标签按钮加载态修改 index.js / wxml / wxssisLoading 状态流转动态绑定类、事件、文字危险闪烁修改 index.js / wxml / wxssdangerFlash 字段CSS 动画自动清除定时器模拟模式调试用新增 simulateResult 方法便于无后端时测试面板效果接后端后可删除错误修复修正 index.wxml 嵌套错误光环位置偏移、多余闭合标签等问题所有这些工作代码量加起来不过两三百行但涉及的状态变量、生命周期、动画时序、组件通信都需要极为细致的调试。尤其是小程序对 WXML 标签闭合的严格检查让我们在调整 DOM 结构时屡屡碰壁——但每一次报错修复都是对“严谨”二字的再认识。六、下一步展望从“听见”到“看见”构建义眼般的视觉叠加层此次优化后慧视的交互框架已基本成形用户拍照 → 浮层展示结果 → 语音播报。但一个更激进的想法始终在我们的路线图上盘旋——能否像赛博朋克2077中的义眼扫描一样将大模型识别出的物体用彩色矩形实时圈选在相机取景器上闭上眼睛想象一个场景视障用户举起手机实时画面通过大模型理解后在屏幕上的垃圾桶周围画一个红色框、标注“障碍物”在门把手的位置画出绿色矩形、标注“入口”。旁人可以从屏幕上直观看到系统的“思考过程”而用户听到的语音播报也将获得更精确的空间锚点——“在你屏幕的左上方红色框标记了一个悬空物。”6.1 技术可行性分析从工程角度看这一效果可以在不依赖原生 AR 引擎的前提下较简单地实现。微信小程序已经提供了画布能力canvas标签我们的思路是层叠布局在camera组件之上覆盖一层全透明、等大小的canvas。相机实时帧虽不能在小程序内直接逐帧拿取但我们可以在用户触发“快速分析”或“实时引导”时获取当前图像并上传。坐标回归大模型分析该图像时不仅返回文字描述还返回物体边界框的相对坐标。例如{objects: [{label: 垃圾桶, confidence: 0.92, bbox: {x: 120, y: 340, width: 180, height: 220}}]}。这里的x, y是相对于图片尺寸的像素坐标width, height是框的大小。画布绘制前端拿到这些坐标后根据画布与屏幕的缩放比例进行映射调用CanvasRenderingContext2D的方法strokeStyle、lineWidth、strokeRect在canvas上绘制出对应矩形和标签文字。动画与过期矩形可以设置为高亮霓虹色如 00f2fe并附带短暂的呼吸动画或闪烁持续几秒后淡出避免干扰正常视野。整个流程不涉及任何复杂的 AR 标定本质上就是“上传一张图 → 拿回一堆框 → 画在图上”。实现复杂度中等但视觉冲击力极强。6.2 更深层的无障碍价值物体边界框不只是“酷炫”的装饰它对视障辅助有着非常具体的意义为残余视力用户提供空间锚点一个有形状的彩色框远比文字描述“左前方有障碍物”更直观。用户可以根据框在屏幕上的位置下意识调整手机朝向。为陪护者提供信任中介视障用户的家人或陪护可以通过界面上画的框直观看到系统“看到了什么”从而建立对人机协作的信任。为后续的精准导航打基础如果框能够稳定地在画面上跟踪物体如移动的车辆、静止的电线杆那么未来甚至可以扩展出“通过语音引导用户将手机对准某个特定物体”的交互——“请慢慢向右转直到屏幕中央的绿色框变大。”6.3 挑战与规划当前面临的主要挑战有大模型的框坐标精度通义千问等视觉模型虽然支持目标检测但返回的边界框精度在日常拍摄的模糊画面下可能达不到像素级。我们需要额外的坐标平滑或置信度阈值过滤。实时帧获取限制小程序camera组件不支持逐帧回调实时绘制只能配合“每隔几秒拍一张照片”的定时分析模式无法做到真正的 AR 级帧率。但 1-2 秒刷新一次的“扫描感”依然成立。性能消耗频繁的图片上传和 Canvas 绘制需要关注 GPU 占用防止低端机型卡顿。这些都在我们的技术预研列表中。我们预计在下一阶段先实现一次拍照后绘制矩形框的静态版本验证模型输出格式和画布绘制的流畅度再进一步探索定时刷新和动画效果。视觉可以有光也可以没有。但无论有没有光我们的设计都要在有光和没有光的边界上划出最清晰的那道线。技术的温度既体现在“听懂”也体现在“看见”。奇思的义眼才刚刚睁开。