GUI界面如何设计??|Mixlab指南推荐

2023-11-01 21:20

本文主要是介绍GUI界面如何设计??|Mixlab指南推荐,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

GUI设计

本文将重点介绍语音交互的GUI。设计的对象主要包括语音助手的GUI容器语音助手和用户之间的对话流、语音助手的当前状态和播报内容,以及显示用户说话内容的ASR区域。

干货提前收藏!公众号改版后推送不会按顺序展示。把mixlab设为星标,每一期干货,都会被微信置顶!

⬇️ 点击下方,即可关注星标 ⬇️

总的来说,无论是手机、带屏智能音箱、智能电视或者车载系统,显示语音交互任务的GUI容器分为两种设计方式,分别是占满全屏和不占满全屏,以iOS 13和iOS 14的Siri为示例,请看图1:

图1 iOS 13(左)和iOS 14(右)

 

图1的左侧两张图中,iOS 13的Siri占据了整个屏幕大小,该设计被笔者称为“应用级语音交互”。语音交互容器占据整个屏幕的好处是语音交互流程和其他界面分隔开,实现逻辑相对简单,同时能有更多的空间显示语音播报内容和对话流。在2018年以前的大部分智能手机和带屏智能音箱的语音助手都采用了该设计方式,还有本书出版前的蔚来汽车、荣威汽车等车载系统的语音助手也是如此。

 

图1的右侧两张图中,iOS 14的Siri占据了屏幕的一部分显示相关内容,它的好处是比占满全屏的语音助手看起来轻量得多,但是它跟后者没有本质差别,因为它还是和其他的界面分隔开,双方的数据和交互任务基本做不到互通。最早采用该设计方式的设备是大屏设备和电脑设备,例如Android TV上的Google Assistant和MacOS上的Siri,因为语音助手显示的内容较少,无需占满整个屏幕,相关细节请看下图2和图3。由于绝大部分的语音交互任务无需显示太多信息,所以截至本书出版前,iOS 14的Siri、Android10版本以上的Google Assistant、MIUI 12版本以上的小爱同学以及带屏智能音箱的小度在家和天猫精灵都采用了该设计方式。

图2 位于Android TV底部的Google Assistant

 

图3 位于MacOS右上角的Siri

 

是否需要展示用户和语音助手的对话流会直接影响语音助手的当前状态、播报内容和显示用户ASR内容的界面布局。最常见的对话流设计是社交应用常用的左右结构布局,即界面左右两侧分别显示对方输出的内容以及用户自己输入的内容;而最新消息显示在界面底部,包括用户即将输入的内容,以图4 Google Allo中的Google Assistant为例。

图4 Google Allo中的GoogleAssistant(左)和用户(右)的对话流

 

在Google Allo中,Google Assistant的播报内容显示在左侧,用户敲打键盘或者语音转换的文字显示在界面的右侧,如果需要用户交互或者确认的内容例如选项列表,则通过另外一种显示形式穿插在双方的对话历史中,该显示方式更多是单张卡片或者由多张卡片组合而成的列表。

 

另外一种对话流的设计可以参考iOS 13的Siri设计。Siri可以通过上下滑动的方式查看历史对话记录,但整个设计弱化了“你问我答”的方式,并强调Siri给出的对话结果;即使对话结果不需要一屏展示,Siri也会将上一轮对话内容顶上去,如图5所示。这样设计的好处是对话结果有更大的面积展示,同时减少上一轮对话对当前的干扰,但缺点也很明显,如果上一轮对话和当前对话处于同一任务中,两轮对话之间的关联会被削弱,如图6所示,图6-1和图6-2之间的关系明显不如图6-1和图6-3。该问题在iOS 14中尤其明显,因为在iOS 14中,Siri的容器不占满全屏,同时Siri会将上一轮对话出现的卡片直接消失,如图7所示。

图5 iOS 13 Siri 对话流1

 

图6 iOS 13 Siri 对话流2

 

图7 iOS 14 Siri 对话流

 

这里有个细节需要注意的是,前文提到语音交互是线性不可逆的,所以一般而言对话流只做对话历史展示,没有其他作用。如果双方进行了好几轮对话后,用户回过头对之前的ASR或者某个卡片进行编辑和选择,整个对话的上下文很可能发生改变,后续的对话内容会直接作废,所以读者在设计对话流时需要考虑是否将对话流中的操作选项置灰并且设置不可操作。

 

语音助手的状态类型包括唤醒状态、聆听状态、网络等待状态、语音播报状态、长连接通信状态和结束至默认状态,具体的视觉和动效设计请参考Siri、Google Assistant、小爱同学等语音助手的设计。手机、电视的语音助手当前状态一般显示在界面底部,这能降低状态切换时动画效果对用户的干扰,让用户保持良好的阅读体验;相反,车载系统的语音助手当前状态一般放在对司机来说一眼就能看到的区域,例如蔚来汽车的语音助手除了在中控屏幕上方显示当前状态,还会在座舱前方中央放置一个实体机器人Nomi;而小鹏汽车G3和P7的语音助手小P也会显示在中控屏幕的上方。

 

如果不考虑对话流,语音助手显示在顶部或者底部都没问题,一旦考虑对话流,语音助手显示在顶部会存在一个问题:对话流中的最新内容是从上往下排序,还是从下往上排序?一般而言,用户在社交应用的界面底部输入内容,从就近原则来说,刚发出去的内容显示在对话流底部以及输入框的附近比较符合用户的心理预期。现有绝大部分语音助手的状态显示会和ASR在位置上强绑定,因此它们相当于一个输入框。如果输入框显示在上方,而最新的内容显示在底部,用户很有可能会觉得困扰。如果最新内容显示在输入框的下方,最新内容从上往下排序,这样的设计很有可能不符合用户的心理预期,因为笔者暂时没有看到有这样的对话流设计。目前只有新闻的信息流会将最新信息显示在界面顶部,但概念上和对话流有着较大的差异。因此,笔者不建议将语音助手的当前状态和ASR内容显示在界面顶部的同时加入对话流的设计。

 

在2021年以前,无论是手机、带屏智能音箱、电脑、电视或者车载系统,绝大部分的语音助手附近都会显示ASR内容,除了iOS 14的Siri以及苹果历代Carplay中的Siri。是否一定要显示ASR内容?答案是否定的,因为不带屏的智能音箱没办法显示ASR内容也能正常使用。在带屏设备上,显示ASR内容是否会更佳?笔者认为是的,主要原因如下:第一,用户能更清晰地知道对话上下文是什么,详情请对比图6和图7。第二,当语音交互任务无法如愿完成,用户检查ASR可以知道问题出自哪。如果ASR和用户说的内容不一致,说明有可能是自己的发音或者环境噪音的问题导致语音识别出错,用户可以重新发起语音或者直接编辑ASR中的内容;如果ASR和用户说的内容一致,说明是语音助手自身的问题,与用户无关。因此,在带屏设备上显示ASR内容有利于对话的推进。在界面设计时,通常做法会在语音助手的状态显示附近预留1-2行的位置显示ASR内容,如果内容超出了预留空间,系统会自动对ASR的前面内容做截断处理。

 

以图8为例,我们参考一下Google Assistant是如何设计ASR的。当用户激活Google Assistant时,由于用户还没开始说话所以ASR内容为空。从体验和商业两个维度进行考虑,这时候为用户提供一些提示词是有好处的;而且提示词也属于用户想说的内容,所以提示词可以直接利用显示ASR的区域,如图8中的第一张图。当用户不点击提示词而开始说话的时候,ASR区域内的提示词会自行消失并实时显示用户说的内容,如第二张图。当发现用户停止说话时,系统会将ASR内容和搜索结果一并显示在第三张图中,此时ASR区域会清空文字并显示相关的提示词引导用户发起下一轮对话。

图8 Google Assistant的ASR设计

 

语音助手播报的内容分为两种类型,第一种类型是播报并跳转到其他应用,后续交互流程由该应用承接;第二种是在语音容器中播报并显示内容,它们分别为纯文本、图片、图文并排的内容、选项列表和网页五种形式。iOS 13的Siri通过卡片样式承载了图片、图文并排的内容、选项列表和网页四种内容,有效统一了容器中整体的设计风格,视觉效果如图9所示。

图9 iOS 13 Siri的对话以纯文本和卡片的形式展示结果

 

有些语音交互的GUI设计还会考虑其他细节,例如智能座舱的语音交互存在双音区、四音区和全音区三种概念。双音区是指语音助手识别到语音交互发起人为驾驶员时,车内的麦克风阵列会将拾音方向设定为左侧方向,这时候即使右侧的副驾和后排乘客发出指令,麦克风也无法获取他们的声音。四音区是指车内的麦克风阵列会锁定主驾、副驾、后排左侧和后排右侧四个方向,锁定后其他用户无法发出指令。全音区是指麦克风不会锁定某个方向,所有乘客都能发起语音指令。双音区和四音区能有效避免其他乘客或者车外环境产生的噪音对当前语音交互流程的影响,但有些时候其他乘客想加入到对话过程中却无法进行对话,这会引起该用户的困扰,因为这种定向声场对他们来说是无形的。为了解决该问题,小鹏汽车P7在语音交互过程中,界面底部的左、右两侧和中间分别显示蓝色波浪效果,以表示当前处于锁定左、右音区和不锁区即全音区的状态,效果如图10所示。除此之外,当语音助手小P完成一系列交互任务后,如果头顶上还显示着拾音图标和“继续说”时,说明小P仍处于聆听状态,这时候用户无需通过唤醒词即可继续发起新一轮语音对话。

图10 小鹏P7 语音交互流程展示

 

以上是公众号发布关于语音交互的所有内容,内容较多需要读者的慢慢消化。总体而言,语音交互除了考虑对话的设计,还需要考虑语音助手的人设、声音、GUI等问题,设计师需要思考的问题和设计的内容远多于移动互联网应用。无论是国内还是国外,当前语音交互处于发展前期,现阶段仍有太多问题需要探索和解决,所以它对设计师的综合素质要求较高。如果读者对语音交互感兴趣,不妨多了解这方面的知识和设计,为后续基于多模交互的体验设计提前做好准备。

*待续

一个人的探索有些孤单,

一群人的探索会更有意思。

  关注本号,加入社群

参与更多跨界交流

这篇关于GUI界面如何设计??|Mixlab指南推荐的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/325813

相关文章

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了

防近视护眼台灯什么牌子好?五款防近视效果好的护眼台灯推荐

在家里,灯具是属于离不开的家具,每个大大小小的地方都需要的照亮,所以一盏好灯是必不可少的,每个发挥着作用。而护眼台灯就起了一个保护眼睛,预防近视的作用。可以保护我们在学习,阅读的时候提供一个合适的光线环境,保护我们的眼睛。防近视护眼台灯什么牌子好?那我们怎么选择一个优秀的护眼台灯也是很重要,才能起到最大的护眼效果。下面五款防近视效果好的护眼台灯推荐: 一:六个推荐防近视效果好的护眼台灯的

Java 创建图形用户界面(GUI)入门指南(Swing库 JFrame 类)概述

概述 基本概念 Java Swing 的架构 Java Swing 是一个为 Java 设计的 GUI 工具包,是 JAVA 基础类的一部分,基于 Java AWT 构建,提供了一系列轻量级、可定制的图形用户界面(GUI)组件。 与 AWT 相比,Swing 提供了许多比 AWT 更好的屏幕显示元素,更加灵活和可定制,具有更好的跨平台性能。 组件和容器 Java Swing 提供了许多

怎么让1台电脑共享给7人同时流畅设计

在当今的创意设计与数字内容生产领域,图形工作站以其强大的计算能力、专业的图形处理能力和稳定的系统性能,成为了众多设计师、动画师、视频编辑师等创意工作者的必备工具。 设计团队面临资源有限,比如只有一台高性能电脑时,如何高效地让七人同时流畅地进行设计工作,便成为了一个亟待解决的问题。 一、硬件升级与配置 1.高性能处理器(CPU):选择多核、高线程的处理器,例如Intel的至强系列或AMD的Ry

智能交通(二)——Spinger特刊推荐

特刊征稿 01  期刊名称: Autonomous Intelligent Systems  特刊名称: Understanding the Policy Shift  with the Digital Twins in Smart  Transportation and Mobility 截止时间: 开放提交:2024年1月20日 提交截止日

基于UE5和ROS2的激光雷达+深度RGBD相机小车的仿真指南(五):Blender锥桶建模

前言 本系列教程旨在使用UE5配置一个具备激光雷达+深度摄像机的仿真小车,并使用通过跨平台的方式进行ROS2和UE5仿真的通讯,达到小车自主导航的目的。本教程默认有ROS2导航及其gazebo仿真相关方面基础,Nav2相关的学习教程可以参考本人的其他博客Nav2代价地图实现和原理–Nav2源码解读之CostMap2D(上)-CSDN博客往期教程: 第一期:基于UE5和ROS2的激光雷达+深度RG

基于51单片机的自动转向修复系统的设计与实现

文章目录 前言资料获取设计介绍功能介绍设计清单具体实现截图参考文献设计获取 前言 💗博主介绍:✌全网粉丝10W+,CSDN特邀作者、博客专家、CSDN新星计划导师,一名热衷于单片机技术探索与分享的博主、专注于 精通51/STM32/MSP430/AVR等单片机设计 主要对象是咱们电子相关专业的大学生,希望您们都共创辉煌!✌💗 👇🏻 精彩专栏 推荐订阅👇🏻 单片机

SprinBoot+Vue网络商城海鲜市场的设计与实现

目录 1 项目介绍2 项目截图3 核心代码3.1 Controller3.2 Service3.3 Dao3.4 application.yml3.5 SpringbootApplication3.5 Vue 4 数据库表设计5 文档参考6 计算机毕设选题推荐7 源码获取 1 项目介绍 博主个人介绍:CSDN认证博客专家,CSDN平台Java领域优质创作者,全网30w+