设计用户体验
s适用于：SDK v4
可以创建具有各种特征的机器人，例如，以轮播或列表格式显示的文本、按钮、图像和丰富卡片等。 然而，每个通道最终都控制着其消息传递客户端呈现功能的方式。 即使多个通道均支持某个特征，每个通道也可能以略有不同的方式呈现该特征。 如果消息包含某通道本身不支持的功能，则该通道可能会尝试将消息内容向下呈现为文本或静态图像，这可能会显著影响消息在客户端上的外观。 某些情况下，通道可能根本不支持特定功能。 例如，GroupMe 客户端无法显示键入指示器。
富用户控件
“富用户控件”是常用的 UI 控件，例如按钮、图像、轮播和菜单。机器人可以将这些控件提供给用户，然后用户即可用其来传递选择和意向。 机器人可以使用 UI 控件集来模拟应用，甚至可以在应用中以嵌入方式运行。 机器人嵌入应用或网站后，可以利用托管它的应用的功能来呈现几乎任何 UI 控件。
应用程序和网站开发人员依赖于 UI 控件让用户能够与其应用程序交互。 这些相同的 UI 控件在机器人中同样有效。 例如，可以通过按钮为用户提供简单的选择。 让用户通过选择标记为“Hotels”的按钮来传达“Hotels”的意思比强制用户键入“Hotels”要容易，且更快速。例如，在移动设备上用户通常更喜欢选择而不是键入。
卡片
使用卡，可以向用户呈现各种视觉对象、音频和/或可选择消息，并有助于协助对话流顺畅进行。 如果用户需要从固定的一组项目中进行选择，则可以轮播的方式显示多张卡，每张都包含图像、文本说明和单个选择按钮。 如果用户有一组针对单个项的选择，则可显示较小的单个图像和一组按钮，并提供可供选择的各种选项。 他们是否要求提供某个主题的详细信息？ 卡可以使用音频或视频输出提供深度信息，或者提供详细介绍其购物体验的回执。 卡的使用范围很广泛，可以为用户和机器人之间的聊天提供指南。 所用卡的类型取决于应用程序的需求。 让我们更仔细地看看卡及其操作和一些建议的用途。
Azure AI 机器人服务卡是可编程的对象，包含标准化的集合，而这些集合中的富用户控件可以跨多种通道进行识别。 下表介绍了可用卡的列表，并针对每种类型的卡提供了使用方面的最佳做法建议。
| 卡类型 | 示例 | 说明 |
|---|---|---|
| AdaptiveCard | 
|
一种开放式卡交换格式，以 JSON 对象方式呈现。 通常用于跨通道部署卡。 卡会适应每个托管通道的外观。 |
| AnimationCard | 
|
一种可播放动态 GIF 或短视频的卡。 |
| AudioCard | 
|
一种可播放音频文件的卡。 |
| HeroCard | 
|
包含单个大图像、一个或多个按钮和文本的卡。 通常用于以视觉方式突出显示可能的用户选择。 |
| ThumbnailCard | 
|
包含单个缩略图图像、一个或多个按钮和文本的卡。 通常用于以视觉方式突出显示可能的用户选择的按钮。 |
| ReceiptCard | 
|
一种让机器人能够向用户提供收据的卡。 它通常包含要包括在收据中的项目列表、税款和总计信息以及其他文本。 |
| SignInCard | 
|
允许用户登录的卡。 它通常包含文本以及一个或多个按钮，用户可使用这些按钮来启动登录过程。 |
| SuggestedAction | 
|
为用户提供一组表示用户选择的卡操作。 在选中任何建议的操作以后，此按钮会消失。 |
| VideoCard | 
|
一种可播放视频的卡。 通常用于打开 URL 并流式传输提供的视频。 |
| CardCarousel | 
|
一个可水平滚动的卡集合，可以让用户轻松地查看一系列可能的用户选择。 |
可以通过卡对机器人设计一次，然后就可以让机器人跨各种通道使用。 但是，并非所有卡类型在所有可用通道中都受到完全的支持。
有关如何向机器人添加卡的详细说明，可参阅添加富卡媒体附件和向消息添加建议的操作。
有关示例代码，请参阅 Bot Framework 示例存储库中的以下示例机器人。
示例 名称 描述 6 使用卡 演示如何使用所有卡类型。 7 自适应卡 演示如何使用自适应卡片。 8 建议操作 演示如何使用建议的操作。 15 附件 演示如何接受用户提供的附件。
设计机器人时，请勿因为常用的 UI 元素不够智能而自动放弃使用它们。 如对话用户体验中所述，在设计机器人时，应该尽可能以最佳、最快和最容易的方式解决用户的问题。 避免一冲动就纳入自然语言理解，因为这通常是不必要的，会引入不必要的复杂性。
提示
一开始尽量使用最少的 UI 控件，只要机器人能够解决用户的问题就可以了。如果以后这些控件不够用了，再添加其他元素。
文本和自然语言理解
机器人可以接受用户的文本输入，并尝试使用正则表达式匹配或自然语言理解 API 对该输入进行分析。 自然语言理解不一定是好的解决方案，具体取决于用户提供的输入类型。
在某些情况下，机器人可能会向用户提出特定问题。 例如，如果机器人问“你叫什么名字？”，则用户可能会使用只指定名称的文本“John”回答，或者使用句子“我的名字是 John”回答。
提问具体的问题可以缩小机器人正常情况下可能会收到的响应的范围，降低对响应进行分析和理解所需的逻辑的复杂性。 例如，考虑提问下述宽泛的、没有固定答案的问题：“你感觉怎样？”。 对于这样的问题，了解潜在答案的各种可能的排列组合是一项复杂的任务。
与之相反，对于“你觉得痛吗？是/否”和“你感到哪里痛？胸/头/手臂/腿”这样的具体问题，则需要更具体的回答，机器人不需实施自然语言理解就可以分析和理解这些回答。
提示
尽可能提出一些不需要自然语言理解功能来分析响应的具体问题。 这样就会简化机器人，提高机器人理解用户话语的成功率。
其他情况下，用户可能会键入特定的命令。 例如，允许开发人员用来管理虚拟机的 DevOps 机器人可能会被设计成接受特定的命令，如“/STOP VM XYZ”或“/START VM XYZ”。 将机器人设计成接受这样的具体命令可以提供很好的用户体验，因为该语法易于学习，而每个命令的预期结果很清楚。 另外，机器人不需自然语言理解功能，因为用户的输入可以通过正则表达式轻松地进行分析。
提示
将机器人设计成要求用户提供具体命令通常会提供好的用户体验，同时也不需自然语言理解功能。
对于知识库或问答式机器人，用户可能会提问一般性问题。 例如，假设一个机器人可以根据数千个文档的内容回答问题。 Azure AI 服务和 Azure 搜索都是专门针对此类场景设计的技术。 有关详细信息，请参阅设计知识库机器人和语言理解。
提示
如果设计的机器人可以根据数据库、网页或文档中的结构化或非结构化数据来回答问题，请考虑使用专门针对此类场景设计的技术，而不要尝试使用自然语言理解来解决问题。
在其他情况下，用户可能会键入基于自然语言的简单请求。 例如，用户可能会键入“我需要意大利辣肠比萨”或“我住所 3 英里内现在是否有素食馆开放？”。 自然语言理解 API 最适合此类场景。
机器人可以使用此类 API 提取用户文本的关键组件，以便确定用户的意向。 在机器人中实现自然语言理解功能时，请为用户可能在其输入中提供的内容的详细程度设置务实的预期。
提示
生成自然语言模型时，请勿假定用户会在其初始查询中提供所有必需的信息。 请将机器人设计为明确请求所需的信息，根据需要提问一系列问题，引导用户提供该信息。
语音
与用户沟通时，机器人可以使用语音输入和输出。 如果将机器人设计为支持没有键盘或监视器的设备，则与用户沟通时，语音是唯一的方式。
在富用户控件、文本和自然语言、语音之间进行选择
就像人们彼此交流时组合使用手势、声音和符号一样，机器人也可以在与用户交流时组合使用富用户控件、文本（有时包括自然语言）和语音。 这些沟通方式可以一起使用；不需非此即彼。
例如，假设有一个可以为用户提供食谱帮助的“烹饪机器人”，该机器人在提供说明时，可以播放视频，也可以显示一系列的图片，目的是说明需要做的事情。 某些用户在按照食谱烹饪时，可能倾向于以翻页的方式浏览食谱，或者使用语音向机器人提问。 另一些用户可能倾向于触摸设备的屏幕，而不是通过语音与机器人交互。 考虑到要支持的具体用例，在设计机器人时，纳入的 UX 元素应该支持用户与机器人交互时偏好使用的方式。