汽车|干货 | 软件定义汽车模式下车载软件的正向设计方法( 四 )


汽车|干货 | 软件定义汽车模式下车载软件的正向设计方法
本文插图

图8
或者是:{元服务来源:{元服务类型} , {内容格式} , {元服务内容}}
比如天气查询服务就可能描述为:服务商名字+天气服务+文本+“内容” 。
3.3 交互
一个完整UESP产品的交互是由多个相似周期组成的 , 其结构可以描述为:
{交互周期1;交互周期2;交互周期3;...} , 每一个交互周期的结构是:
{输入单元 , 输出单元} 。 综合到一起就是:
汽车|干货 | 软件定义汽车模式下车载软件的正向设计方法
本文插图

图9
三个周期只是UESP的典型结构 , 并不是每一个UESP产品都必须有这三个周期 , 有的可能只有一个 , 也有的可能需要四个 , 甚至更多 。 UESP产品所包含的交互周期的数量 , 可以称为交互层级或者交互深度 。 (有关交互深度的研究不在本文范围中) 。 交互设计的目标是让交互周期数量越少越好 , 也就是交互层级越少越好 。 无论UESP有几个交互周期 , 第一个交互周期始终是存在的 , 而且是比较特殊的 , 因为它代表着用户对UESP的发起 。
输入单元是使用者或者场景识别算法对车提供输入的环节 , 属于车辆感知范畴 , 出现在场景判断中 , 用于功能或者服务的触发 。 UESP的发起必然通过两种方式 。 第一种方式是用户主动表达自己的意愿 , 依靠的手段包括但不限于实体按键 , 遥控(遥控器或者手机) , 语音命令 , 手势识别等等控制 。 第二种方式是用户没有主动表达意愿情况下 , UESP根据场景识别的算法判断出设计的场景已经出现 。 这两种情况在输入单元中都会涉及 , 但本文主要分析第一种情况 。
输出单元是车辆对用户提供输出的环节 , 作为用户输入的反馈 , 出现在功能或服务提供的过程中 , 用于确保UESP按照用户意愿去提供服务 。 输出单元主要用于询问用户是否确定提供服务(确认) , 或者是对不同服务选项的选择(多项选择) , 以及服务过程本身(提供服务) 。
从UESP的交互结构图可以看出来 , 一共有四种类型的输入和输出单元 , 分别是功能发起输入单元 , 意愿选项输出单元 , 意愿选项输入单元 , 服务内容输出单元 。
功能发起输入单元只会出现在第一个交互周期 , 通常用于功能的发起 。 意愿选项输出单元大多是要求用户确认意愿或者为用户提供服务选项 , 可以出现在除了最后一个交互周期的任何一个交互周期中 。 意愿选项输入单元通常用于用户对意愿或者服务选项进行确认或选择 。 服务内容输出选项则是开始提供服务 。
3.3.1 功能发起输入单元可以抽象为:
{目标功能;输入方式;输入点} 。
先谈谈输入方式 。 第一大类输入方式是物理按键输入 , 包含实体按键和屏幕软键两种方式 。 实体按键和屏幕软键都可以出现在车载上 , 遥控器上 , 手机上或者智能家居的设备上 。 而按键形式可以包含开关 , 挡位选择 , 旋钮 。 第二大类输入方式是语音输入 , 这也是目前非常流行的输入方式 , 原因当然是它属于人类最自然的交互方式之一 。 第三大类输入方式是身体姿态输入 , 包括手势识别 , 眼动识别或者其他目前还没有发明的用人体姿态变化来实现输入的方式 。
虽然功能发起输入单元属于第一交互周期 , 但是这三大类输入方式在其他交互周期的中也是一样的 。
输入点是指具体的输入方式中承载明确输入目的的某个按键 , 某句语音指令 , 某个手势动作或某个眼球注视角度 。
所以功能发起输入单元实际上就是把一个UESP功能的发起分配给某种(或者某几个)输入方式的某一个(或者某几个)输入点 。
输入方式见图10 。
汽车|干货 | 软件定义汽车模式下车载软件的正向设计方法


推荐阅读