语音内容与可用性:对话式界面设计全解析

本文深入探讨语音界面设计的技术实现与内容策略,涵盖交互式语音应答系统、屏幕阅读器和语音助手等关键技术,解析语音内容在对话式界面中的特殊挑战与解决方案。

语音内容与可用性

对话不是新界面。它是最古老的界面。——Erika Hall,《对话式设计》

我们进行对话已有数千年历史。无论是传递信息、完成交易还是简单问候,人类通过口语对话交谈比划了无数代。直到过去几千年我们才开始将对话付诸文字,而过去几十年我们才开始将其外包给计算机——这种机器对书面交流的亲和力远高于口语的随意性。

计算机的困境

计算机遇到困难是因为在口语和书面语之间,言语更为原始。为了与我们成功对话,机器必须处理人类言语的混乱:不流利和停顿、手势和肢体语言,以及词汇选择和方言差异,这些甚至可能阻碍最精心设计的人机交互。在人与人之间的场景中,口语还享有面对面接触的特权,我们可以轻松解读非语言社交线索。

相比之下,书面语言在记录时立即具体化,并在口语交流中早已过时后长期保留用法(例如称呼“敬启者”),生成自己过时术语和短语的化石记录。由于书面文本往往更一致、精炼和正式,机器解析和理解起来从根本上要容易得多。

口语则没有这种便利。除了用强调和情感语境装饰对话的非语言线索外,还有语言线索和发声行为以细微方式调节对话:如何说,而不是说什么。无论是连珠炮式、低音调还是高分贝,无论是讽刺、生硬还是叹息,我们的口语传达的内容远超过书面文字所能企及。因此当涉及语音界面——我们进行口语对话的机器——作为设计师和内容策略师,我们面临着激动人心的挑战。

语音交互

我们与语音界面交互有各种原因,但根据Michael McTear、Zoraida Callejas和David Griol在《对话式界面》中的说法,这些动机大体上也反映了我们与他人发起对话的原因。通常,我们开始对话是因为:

  • 我们需要完成某事(如交易)
  • 我们想知道某事(某种信息)
  • 我们是社交生物,想找人交谈(为对话而对话)

这三类——我称之为交易性、信息性和亲社会性——也基本上描述了每个语音交互的特征:从开始到结束的单个对话,为用户实现某种结果,从语音界面的第一次问候开始,到用户退出界面结束。请注意,我们人类意义上的对话——导致某种结果并持续任意时长的人与人之间的聊天——可能连续包含多个交易性、信息性和亲社会性语音交互。换句话说,语音交互是对话,但对话不一定是单个语音交互。

在大多数语音界面中,纯粹亲社会性的对话更像是噱头而非吸引人,因为机器尚不具备真正想知道我们近况的能力,也无法进行人类渴望的那种热情问候。关于用户是否实际上更喜欢从亲社会性语音交互开始并无缝转换到其他类型的有机人类对话,也存在持续辩论。事实上,在《语音用户界面设计》中,Michael Cohen、James Giangola和Jennifer Balogh建议通过模仿用户与其他语音界面的交互方式来坚持用户期望,而不是过于努力地拟人化——可能在此过程中疏远用户。

这就留下了我们可以彼此进行、语音界面也可以轻松与我们进行的两类对话:实现某种结果的交易性语音交互(“购买冰茶”)和教我们新事物的信息性语音交互(“讨论音乐剧”)。

交易性语音交互

除非你在外卖应用上点击按钮,否则当你点一份额外菠萝的夏威夷披萨时,你通常在进行对话——因此也是语音交互。即使我们走到柜台点餐,对话也会从最初的邻里闲聊迅速转向手头的真正任务:点披萨(应该慷慨地加上菠萝 toppings)。

Alison: 嘿,最近怎么样?
Burhan: 嗨,欢迎来到Crust Deluxe!外面很冷。我能帮你什么?
Alison: 我能要一份额外菠萝的夏威夷披萨吗?
Burhan: 当然,什么尺寸?
Alison: 大号。
Burhan: 还要别的吗?
Alison: 不用了,就这些。
Burhan: 喝点什么?
Alison: 我要一瓶可乐。
Burhan: 好的。总共13.55美元,大约十五分钟。

这种交易性对话中的每个渐进披露都越来越多地揭示了交易的期望结果:提供的服务或交付的产品。交易性对话具有某些关键特征:直接、切题且经济。它们迅速处理了客套话。

信息性语音交互

同时,有些对话主要是为了获取信息。虽然Alison可能访问Crust Deluxe的唯一目的是下单,但她可能实际上根本不想带着披萨走出去。她可能同样感兴趣他们是否提供清真或犹太菜肴、无麸质选项或其他东西。在这里,虽然我们开头再次有一个亲社会性的迷你对话以建立礼貌,但我们追求的是更多。

Alison: 嘿,最近怎么样?
Burhan: 嗨,欢迎来到Crust Deluxe!外面很冷。我能帮你什么?
Alison: 我能问几个问题吗?
Burhan: 当然!请讲。
Alison: 你们菜单上有清真选项吗?
Burhan: 绝对有!我们可以应要求制作任何披萨为清真。我们也有很多素食、蛋奶素和纯素选项。你在考虑其他饮食限制吗?
Alison: 无麸质披萨呢?
Burhan: 我们绝对可以为你做无麸质 crust,没问题,无论是我们的深盘披萨还是薄脆披萨。还有什么我可以为你解答的吗?
Alison: 暂时就这些。很高兴知道。谢谢!
Burhan: 随时欢迎,尽快再来!

这是一个非常不同的对话。这里的目标是获取特定的事实集合。信息性对话是对真相的调查探索——收集数据、新闻或事实的研究考察。信息性语音交互可能必然比交易性对话更冗长。回答往往更长、信息量更大,并仔细传达以便客户理解关键要点。

语音界面

语音界面的核心是使用语音支持用户实现目标。但仅仅因为界面有语音组件并不意味着每个用户交互都通过语音介导。由于多模态语音界面可以依赖屏幕等视觉组件作为拐杖,我们在本书中最关注纯语音界面,它完全依赖口语对话,没有任何视觉组件,因此更加细致且具有挑战性。

尽管语音界面长期以来一直是科幻小说中人类想象未来的组成部分,但直到最近这些崇高愿景才在真正的语音界面中完全实现。

交互式语音应答系统

尽管书面对话界面几十年来一直是计算的固定设施,但语音界面最早出现在1990年代初,包括将书面文本大声朗读的文本转语音听写程序,以及为用户提供地址指示的语音启用车载系统。随着交互式语音应答系统的出现,旨在替代负担过重的客户服务代表,我们熟悉了第一个进行真实对话的真正语音界面。

IVR系统允许组织减少对呼叫中心的依赖,但很快因其笨拙而臭名昭著。在企业界常见,这些系统主要设计为隐喻式交换台,引导客户找到真正的电话代理(“说Reservations预订航班或检查行程”);当你致电航空公司或酒店集团时,你很可能会与其中一个进入对话。尽管存在功能问题且用户因无法立即与真人交谈而感到沮丧,IVR系统在1990年代初 across 各种行业激增。

虽然IVR系统非常适合高度重复、单调且通常不偏离单一格式的对话,但它们的对话比我们在现实生活中(甚至科幻小说中)习惯的对话 less 刺激。

屏幕阅读器

与IVR系统演进并行的是屏幕阅读器的发明,这是一种将视觉内容转录成合成语音的工具。对于盲人或视障网站用户,这是与文本、多媒体或表单元素交互的主要方法。屏幕阅读器可能代表了今天我们拥有的最接近开箱即用实现通过语音传递内容的等价物。

最早以该名称知名的屏幕阅读器之一是1986年伯明翰大学视障教育研究中心开发的BBC Micro和NEEC Portable屏幕阅读器。同年,Jim Thatcher为基于文本的计算机创建了第一个IBM屏幕阅读器,后来为具有图形用户界面的计算机重新创建。

随着1990年代网络的快速增长,对网站无障碍工具的需求激增。得益于2008年开始引入语义HTML尤其是ARIA角色,屏幕阅读器开始促进与网页的快速交互,表面上允许残疾用户将页面作为听觉和时间空间而非视觉和物理空间遍历。换句话说,网络的屏幕阅读器“提供了将视觉设计结构——接近度、比例等——转化为有用信息的机制,”Aaron Gustafson在A List Apart中写道。“至少当文档经过深思熟虑编写时是这样。”

尽管对语音界面设计师具有深刻的指导意义,但屏幕阅读器存在一个显著问题:它们难以使用且 relentlessly 冗长。网站和网页导航的视觉结构不能很好地转化为屏幕阅读器,有时导致笨拙的发音,命名每个可操作的HTML元素并宣布每个格式更改。对于许多屏幕阅读器用户来说,使用基于网络的界面需要付出认知代价。

在《Wired》中,无障碍倡导者和语音工程师Chris Maury思考了为什么屏幕阅读器体验不适合依赖语音的用户:

从一开始,我就讨厌屏幕阅读器的工作方式。为什么它们被设计成那样?先视觉呈现信息,然后,且仅然后,才将其翻译成音频,这毫无意义。所有为应用创建完美用户体验投入的时间和精力都被浪费了,或者更糟,对盲人用户的体验产生不利影响。

在许多情况下,精心设计的语音界面可以比冗长的屏幕阅读器独白更快地将用户引导到目的地。毕竟,视觉界面用户受益于在视口中自由穿梭以查找信息,忽略不相关的区域。与此同时,盲人用户有义务聆听每一个合成为语音的发音,因此珍视简洁和效率。长期除了使用笨拙屏幕阅读器别无选择的残疾用户可能会发现,语音界面,尤其是更现代的语音助手,提供了更简化的体验。

语音助手

当我们想到语音助手(现在在客厅、智能家居和办公室常见的语音界面子集)时,我们许多人立即想到《2001太空漫游》中的HAL或听到Majel Barrett在《星际迷航》中作为全知计算机的声音。语音助手类似于个人礼宾,可以回答问题、安排约会、进行搜索和执行其他常见的日常任务。而且它们因其辅助潜力正迅速获得无障碍倡导者的更多关注。

在最早的IVR系统在企业界取得成功之前,苹果于1987年发布了一个演示视频,描绘了Knowledge Navigator,这是一个能够转录口语并在很大程度上准确识别人类语音的语音助手。然后,在2001年,Tim Berners-Lee和其他人 formulated 他们对语义网“代理”的愿景,该代理将执行典型差事,如“检查日历、安排约会和查找位置”。直到2011年,苹果的Siri才最终登场,使语音助手成为消费者触手可及的现实。

由于今天有大量语音助手可用,某些语音助手相对于其他语音助手的可编程性和可定制性存在相当大的差异。在一个极端,除了供应商提供的功能外,其他所有功能都被锁定;例如,在发布时,苹果Siri和微软Cortana的核心功能无法扩展到其现有能力之外。即使在今天,也不可能编程Siri执行任意功能,因为除了预定义的任务类别(如发送消息、叫共享车、进行餐厅预订和某些其他任务)外,开发人员无法在低级别与Siri交互。

在频谱的另一端,像Amazon Alexa和Google Home这样的语音助手提供了一个核心基础,开发人员可以在其上构建自定义语音界面。因此,对于感到受Siri和Cortana限制束缚的开发人员来说,易于定制和扩展的可编程语音助手正变得越来越受欢迎。亚马逊提供Alexa Skills Kit,一个为Amazon Alexa构建自定义语音界面的开发框架,而Google Home提供编程任意Google Assistant技能的能力。今天,用户可以在Amazon Alexa和Google Assistant生态系统中的数千个自定义构建技能中选择。

随着亚马逊、苹果、微软和谷歌等公司继续划定自己的领土,它们也在销售和开源前所未有的工具和框架阵列,旨在使构建语音界面尽可能容易,即使没有代码也是如此。

通常出于必要,像Amazon Alexa这样的语音助手往往是单渠道的——它们与设备紧密耦合,无法在计算机或智能手机上访问。相比之下,像Google的Dialogflow这样的许多开发平台引入了全渠道功能,因此用户可以构建单个对话界面,然后在部署时表现为语音界面、文本聊天机器人和IVR系统。我在这本以设计为重点的书中不规定任何特定的实现方法,但在第4章中,我们将探讨这些变量可能对你构建设计工件的方式产生的一些影响。

语音内容

简而言之,语音内容是通过语音传递的内容。为了保留使人类对话如此 compelling 的首要因素,语音内容需要自由流动和有机、无上下文且简洁——书面内容所不具备的一切。

我们的世界充满了各种形式的语音内容:屏幕阅读器朗诵网站内容,语音助手快速读出天气预报,以及由IVR系统管理的自动电话热线响应。在本书中,我们最关注以听觉方式传递的内容——不是作为选项,而是作为必需品。

对于我们许多人来说,首次涉足信息性语音界面将是为用户传递内容。只有一个问题:我们已有的任何内容都没有为这个新 habitat 做好准备。那么,我们如何使困在网站上的内容更具对话性?我们如何编写适合语音交互的新副本?

最近,我们开始以前所未有的方式切片和切块我们的内容。网站在许多方面是我称之为宏内容的巨大宝库:冗长的散文,可以在浏览器窗口中无限滚动数英里,就像报纸档案的缩微胶片查看器。早在2002年,远在语音助手普及之前,技术专家Anil Dash将微内容定义为永久链接的内容片段,无论环境如何(如电子邮件或短信)都保持可读性:

一天的天气预报、飞机航班的到达和离开时间、长篇出版物的摘要或单个即时消息都可以是微内容的例子。

我会更新Dash对微内容的定义,以包括所有超越书面通讯的 bite-sized 内容示例。毕竟,今天我们在界面中遇到微内容,其中一小段副本单独显示,脱离浏览器,如文本机器人确认餐厅预订。微内容提供了最佳机会来评估你的内容如何被拉伸到其能力的边缘,为既有的和新的传递渠道提供信息。

作为微内容,语音内容是独特的,因为它是内容如何在时间而非空间中体验的示例。我们可以瞬间瞥一眼地下的数字标志,知道下一班火车何时到达,但语音界面会 captive 我们的注意力一段时间,我们无法轻易逃脱或跳过,屏幕阅读器用户对此再熟悉不过。

由于微内容基本上由孤立的 blob 组成,与它们最终将到达的渠道没有关系,我们需要确保我们的微内容真正作为语音内容表现良好——这意味着专注于强大语音内容的两个最重要特征:语音内容可读性和语音内容可发现性。

从根本上说,我们语音内容的可读性和可发现性都与语音内容在感知时间和空间中的表现方式有关。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计