人机交互(HCI)技术在汽车工业中日益普及。 本文的主要目的是发现如何在车辆中使用用户界面(UI)来提高司机在驾驶时使用手机和其他电子设备的安全性。 在本文中，我们提出了一种可分为三个阶段的概念设计。 第一阶段“分析”侧重于信息检索和结构化。 第二阶段的“设计”基于“分析”阶段的结果提供了一个具体的实现接口。 第三阶段“评估”对实施执行的可用性测试。 在“分析”中，我们开发了一个PACT分析。 在“设计”中，我们解释了界面的元素，并使用图片来对它们进行说明。 在“评估”中，我们使用纸质原型在假想的驾驶情况下执行可用性测试。
关键词： 人机交互设计; 交互框架; 驾驶员安全模型; PACT分析
01
简介
几年前，当这款手机推出时，只有几个人使用它。 而今天，即使是10岁的年轻人也经常带着它到处走。 根据诺基亚公司的一项调查，80%的欧洲人口袋里都有手机。 在任何情况下，这并不是人们唯一的电子设备，他们还携带有智能手机和相机、平板电脑。 由于这些电子设备的过度使用，现代生活中的对电子设备的需求也将日益增加。
从某种角度来看，比如电子设备的可用性可能是有益的，但在某些情况下同样也是危险的。在开车时使用手机会极大程度地占据司机真正的驾驶任务。如果司机需要用手来控制电子设备，或者在编写即时消息时需要使用设备，这种情况尤其危险。大多数的事故和死亡率都是由于在驾驶和行走时使用手机和短信书写造成的。
我们知道有一部分人已经认识到这个问题，但依然在开车时使用手机。我们每个人都不愿意错过电子设备提供的功能，与上述使用风险相比他们别无选择。我们认为，将电子设备的控制纳入车辆控制可以减少中断的程度，并通过这种方式提高安全性。驾驶辅助系统可以帮助驾驶员在某些特定环境下控制驾驶行为。
在本文中，我们提出了一个使用人机交互技术的交互设计框架。本设计是根据车辆的结构在UI上工作限制中断的程度。它应该能让司机控制他们手机的所有必需功能。同样，我们需要说明如何从UI的角度来确认驱动帮助框架，以便能够更好的改善这个功能。
我们认为手机以某种方式与车辆相关联，并赋予车辆控制所限制的专门能力。手机控制的连接是技术性的，我们假设一旦驱动程序进入，连接就自动建立车辆。
为了实现框架设计的目标，我们考虑了三个主要步骤：(1)分析，(2)设计，(3)评价。
在分析阶段，我们调查了目前市场上可用的技术，并通过问卷调查发现潜在的用户需求。之后，我们提出了研究结果的PACT框架。
在设计阶段，我们根据调查结果和任务分析提出一个物理设计。在评估阶段，我们在可用性测试的帮助下测试原型，并突出我们的想法中存在的问题。
本文的其余部分结构如下。第2节展示了关于用户的数据。第3节重点讨论了PACT分析，而第4节则探讨了XOR或约束的转换和验证。第4节介绍了需求部分，而第5节讨论了可用性因素。第6节描述概念设计，第7节探讨任务分析。最后，第8节阐述相关工作;第9节提供了结论和未来的方向。
02
关于用户
在我们开始设计用户界面之前，我们需要一个重要的输入，那就是这个系统的潜在用户提供的体验和意见。
问卷一
a) 内容
我们需要找出哪些设备和功能是我们的界面能够处理的，这其中哪些又是最重要的。
因此，我们制作了一份问卷，首先是询问人们正在使用哪些设备和功能，其次询问他们将来可能会考虑使用哪些设备和功能，最后询问他们出于安全原因目前不使用哪些设备和功能。此外，也有一些问题是围绕着被提问群体的个性来呈现的。
我们把问卷随机分发给我们认识的人。问卷通过电子邮件发送，我们在一周内接收答案。我们选择让人们用自由方式回答，因为我们不想要有限的选择，而是允许超出我们预期的想法。通过生成一个包含核心意见的表格，并根据人数对答案进行人工评估。本次评估的结果可以在以下图表中看到。每个人都有几个可能的答案。
b) 结果
本节将讨论透视图的问题和答案。这些问卷显示了详细的答案，这将有助于开发一个设计安全的概念，而产生了不同的问题和答案如图
以下结论不仅受到图表的影响，还受到从自由文本中抽象出来的信息的影响。接受调查的人大多来自德国和法国，年龄主要在20至25岁之间。
如今，大约有一半的人在开车的时候使用手机，主要用于接听和接听电话，也用于阅读和编写短信。只有极少数人使用免提套。此外，他们使用音频播放器。所有这些设备都需要至少用一只手进行使用，包括眼睛会把注意力集中在设备上。因此，人们肯定会在驾驶过程中分心。
在那些出于安全原因会避免在车内使用此类设备的人中，仍有大约一半的人会在车外使用这类设备。因此，有一个潜在的设备需要，能够在车内使用并且它可以安全地执行操作。这里提到的另一个设备就是电脑。
在未来，大约四分之一到三分之一的人可以想象也会使用互联网和电子邮件，也会使用导航（但由于我们有开放的答案，人们可能只是没有想出这个想法，但会使用它）。
有意思的是，三分之一的人会在紧急情况下扔掉手机或挂断电话，以恢复对汽车的控制。如果所需的时间可以通过使用一个允许完全控制的系统来消除，这将是我们的一个重要收获。
在关于驾驶辅助系统的问题中，我们看到了一个明显的分别，即乐意接受辅助系统的人和拒绝任何电子辅助的其他人。
问卷二
a) 内容
作为进一步的步骤，用户对驾驶辅助系统的想法很感兴趣。目前已经有ABS或ESP这样的系统在使用，但它们对驾驶行为的影响不是很明显。未来的系统可能会自动中断或比保持赛车在赛道上的干扰要大得多，我们想了解驾驶员对此的看法。特别是我们想知道在多大程度上，与移动设备的相关性，这样的系统是否是有利的。
最后一个问题的重点是关于界面的通知，应该给我们一个小的指引，为我们的用户界面提物理设计的建议。最后，我们允许以自由的方式评论。
这一次，我们将问题分配给比第一次更多人的组。我们再次通过电子邮件发送请求，但这一次实际的问卷实现为一个网页。最后一个问题允许有几个答案，但所有其他问题只有一个。这次的结果表是由软件程序自动生成的。因此，评估非常直接，结果完全由图表显示。
结果
在本节中，将讨论人们的视角问题和答案。
图 10 - 19 显示了某些调查问卷的不同结果，以了解不同年龄组的需求。
群体的变化可以从被调查群体的个人因素的细微变化中看出。三分之二的人已经回答了第一份问卷。
从结果中可以看出一点，就是意见传播。许多人希望在某些情况下驾驶辅助系统能够主动干预，以防止发生事故。但当系统做出反应时，他们也需要反馈。可提及的部分只需要反馈。但我们无法确定人们是否看到移动设备的使用与驾驶辅助系统的激活之间存在关联。
关于系统激活的问题，人们的意见分成三组：希望系统一直处于激活状态的人，希望按需手动激活和停用系统的人，以及希望系统始终处于停用状态的人们。因此，手动激活和停用的功能将符合大多数人的要求。
关于不同表示的图表清楚地显示了明确的首选项，以视觉通知为首，排在其次的是非语言声音通知。
在评论中，相当多人表示担心，在这种情况下，他们不信任电子系统。有的人要求电子系统必须非常成熟，他们才愿意使用它。
●
●
●
03
PACT分析
一个因素是根据用户标准设计用户界面：为了完成这项任务，计划进行预调查研究，对当前的功能和缺失的功能给出了清晰的概念。有了这一点，用户身份也至关重要。为了实现这一点，PACT分析是伴随着几个用户需求、可用性因素和指导方针进行的。
图20：PACT分析
PACT 分析为我们提供了有关用户、活动、上下文和技术的明显场景。要求在设计界面方面起着非常重要的作用，所有要求都是根据用户的需求而制定的。图20显示了 PACT 分析的详细方面。
04
要求
在我们的设计中，我们必须考虑三种技术，方向盘上的命令，文本到语音系统的语音识别，以及显示器屏幕上和挡风玻璃上的显示屏。
表1列出了用户应该能够控制与汽车内置接口的功能。在关联中，我们提出了两个相关的估计。一个是关于使用频率，它告诉我们哪些功能应该更容易到达最后的界面。另一个显示由于逻辑原因和分心，每个功能的驱动程序控制是可能的。但是，所有这些功能都应由共同驱动程序控制。
交叉意味着控制方式是可能的，破折号意味着不可能。蓝色十字架表示该功能是新的，它不存在在市场上，绿色表示已经可用的控制功能。有三个频率级别：低、中和高。所有高级功能都应通过用户界面快速访问。
05
可用性因素
有几个可用性因素需要考虑，但我们列出了下面列出的最重要的因素。
a ）适用性
在我们的项目中，我们不能开发所有可用的设备任务，首先是因为我们不知道所有的设备，因为它可能是太复杂和太危险的用户使用所有这些设备。通过第一个问卷，我们知道用户想要做什么样的任务，所以我们只会开发最重要的任务。无论如何，用户仍然可以使用他的设备来完成任务。
B ）学习的难易程度
轻松的学习是这个项目最重要的因素之一。用户应该能够学习如何做，说什么，按哪个按钮，而不需要阅读手册或看界面。用户需要把注意力集中在路上而不是界面上，这就是为什么对于任何任务，系统都应该帮助用户在不失去注意力的情况下执行任务。
C ）任务效率
频繁使用的用户可能要求更高，有不同的期望。我们需要仔细考虑频繁使用者可能遇到的所有情况。在所有这些情况下，接口应该是有效的。
d ）容易记忆
在这个项目中，容易记忆也是非常重要的。用户应该记住按哪个按钮，说什么，而不看方向盘或菜单。使用者越容易记住，就越能专注于道路。语音命令应该很好记而且它的方向盘上不应该有太多的按钮。
e ）主观满意度
主观满意度很重要，因为如果用户不喜欢这个系统，他不会使用它，而是使用他的设备。在这种情况下，这将是危险的用户和其他司机。
f ）可理解性
用户应该了解系统正在做什么，重要的是要通知用户采取的行动，如打电话或发送短信。
g）坚固性
在遇到无效输入时，坚固性是系统的弹性。压力大或被某事分心的驱动程序可能会滥用用户界面。这绝不能造成伤害。更重要的是，驱动程序应该能够轻松地留下一个意想不到的，恼人的系统状态（例如，太大声的音乐）。
h）合作方面
当可用时，驾驶员应该能够将完整的设备控制提供给副驾驶员。
06
设计概念
我们需要提出在UI中工作的车辆计划，以限制中断的百分比。它应该使司机能够控制他们手机的所有所需功能。我们还需要说明如何从 UI 的角度确认驾驶帮助框架，以帮助获得最佳活动。
我们期望手机以某种方式或以某种方式与车辆相关联，并赋予专门的能力，以受车辆控制的限制。承认这种联系和控制无疑是专门的，而不是这项任务的一部分。图21显示了系统的概念设计。
图21：使用HCI技术的交互式系统的概念设计
为了有一个简单的学习界面，我们的结构模型必须与驾驶者的心理模型惊人的相同。此外，司机很可能会试图以与手机连接类似的方式与系统联系。然而，这个框架必须能够更快、更简单地使用。所以我们需要在设备和简单设备之间找到正确的模型。
SePelt等人提到了我们应该考虑的一些令人感兴趣的心理模型的客观事实。
最重要的是，单是看心理模型是不够的，这容易让我们忽视了其中微妙之处。所以我们可以忘记某些方法，而不脱离心理模型。
如果模型不协调，个体的运行能力和记录能力就会受到严重限制，所以个体将会面临一些挑战，来让我们去发现另一种方法。心理模型没有严格的限制，可比的设备和活动被容易被误认。心智模型是封闭的。个人乐于制止错误并重新开始，而不是试图弥补错误。批评、放弃和重新开始都是非常重要的。
如上所述，用户将尝试发现设备和界面之间的相似性。结构模型必须具有特定的智能、共享的特性，并使用与设备类似的术语。
我们期望驾驶员的手机能以某种方式与车辆相关联，并提供受车辆控制限制的专用容量。我们建议在设备和车辆之间建立远程连接，因为这样可以为用户提供舒适感。此外，我们建议对专用控制接口进行标准化，以便每个设备都能与每辆车配合使用。控制界面必须能够控制驾驶者在驾驶时所需的每一个手机元件。这样一个控制接口所提供的能力被直接整合到我们的接口中。图22显示了交互式设计。
图22：使用现代控制系统的交互式设计
在UI组件附近出现了一些控制驱动帮助框架的开关。更重要的是，车辆配备了双向声音框架。扬声器框架用于播放声音和提供声音输入或数据。接收器框架用于记录用户的声音，这些语音将在特定焦点下进行解释。
A)操作设计
图形菜单对于移动设备来说是常见的。我们的图形显示就像市场上的许多菜单，因此应该很容易学习。连接到汽车的设备会自动集成到菜单中-每个设备一个条目。显示屏是触摸屏，可以按下设备名称以输入设备菜单。设备菜单中的项目表示可通过界面控制的功能。一切都可以通过图形菜单进行控制。
菜单始终只显示显示所有设备和设备菜单或子菜单的菜单。等级中的实际路径也显示并可触摸，以始终显示用户在菜单上的位置，并给出在等级中获得更高位置的方法。
菜单的结构使用户能够建立一个心理模型，并将用于界面的其他部分。通过触摸屏控制所有内容的可能性，使驾驶员能够使用副驾驶员并放弃控制设备的任务。
除了触摸屏幕，驾驶员还可以使用安装在方向盘上的操纵杆在菜单中导航。用法表示从左到右的层次结构。纵轴改变菜单项。右方向进入子菜单，而左方向返回到更高的菜单。为了支持系统的固定性，任何动作都不能用操纵杆本身执行操作。这意味着在导航菜单时不会发生意外。最后执行一个菜单项，可以执行附加按钮“执行”可用。例如一个人可以选择从电话的地址簿给她打电话。
不过，驾驶员并不打算在开车时看菜单。因此，每一个菜单项都是通过扬声器系统读取的，所以司机一旦有了菜单的心理模型，就不需要看界面了。
B)具象设计
本文提供的菜单只能被看作是一个大纲。我们只使用了非密集的颜色，司机不应该被他们吸引到，因为他不打算看显示。在用操纵杆导航菜单时，选中的菜单项会高亮显示。不同颜色的字体有助于区分不同的设备。虽然，重要的是要确保与背景有足够的对比。显示器可自动调整对比度和强度，以适应环境的亮度。
图23：手机导航菜单
图24：音乐播放器的导航菜单
图23、24、25 显示了手机、音乐播放器和拨号号码的菜单。输入设备子梅努后，突出显示代表设备的符号。菜单项的字体颜色与主菜单中设备条目中的字体颜色相对应。此外，请注意顶部显示的层次结构路径。为了让用户知道，有比电话簿中显示更多的项目，箭头显示在顶部和底部。
图25：拨号号码的导航菜单
**执行特定操作时，状态显示会通知用户当前情况。**
图26：样本拨号号码
图27：示例接触
图28：呼叫样本联系人
图26 到28 显示了要呼叫的联系人菜单。菜单发展是留在这种状态，它主要用于副驾驶，并给司机一个菜单等级的精神模型，他可以用它来处理控制没有视觉接触的菜单。如果驾驶员忘记操作接口的其他部分，它也可以作为退回解决方案。这是一种有保证且通常易于操作所有功能的方法。
屏幕本身位于汽车仪表板的中间。
C)语音命令的操作设计
没有使用菜单，而是向驾驶员提供快捷方式。这提高了任务效率，并给更高级的用户一个更令人满意的替代方案，通过菜单的很长的路要走。"做/接受"按钮具有两种功能。首先，我们专注于"做"。每当他想采取行动，他可以按下"做/接受"按钮。然后，播放音频的音量会自动暂时减少，他可以说出语音命令。这可以是"打电话给安德鲁"。系统重复命令被理解，如果命令被正确识别，因此驱动程序同意他可以再次按下"执行"按钮。如果他不同意，他可以按下取消按钮。
菜单项的每个执行都与语音命令关联，例如"呼叫Andrew"。这是一个短语音命令，几个设备可能有等于短语音命令，特别是同类型（两个mp3播放器）的多个设备，我们的系统支持。因此，还有一个额外的独特的长语音命令。它等于在图形菜单中看到的菜单层次结构中的路径加上短语音命令，例如“MobilePhone-dialled Numbers-Andrew-Call Andrew”长语音命令可以被看作是语音菜单导航。为了让用户学习并记住短语音，在执行相应操作时，系统始终会发出短语音，这可以通过使用触摸屏、导航杆或如上所述使用语音命令来完成。
当驱动程序尝试使用模棱两可的短语音命令执行操作时，系统会告诉驾驶员可用的长语音命令与短语音命令的可能操作，让其相匹配。
司机提出行动的想法并不总是这样。也可能是由于计划路线上即将发生的交通堵塞，有传入的信息或传入的呼叫或导航系统提供重新确定车辆路线的情况。这可能需要此人立即对情况作出反应。接受/拒绝选择适合我们能想到的最实际的情况。所以按钮“do/accept”现在被用来接受来电，或者让系统通过文本语音合成器通过麦克风读取来电信息。按钮“取消/拒绝”拒绝呼叫或储存在手机上的信息，而不阅读它。
当"做/接受"按钮诱导一个积极的动作，它的颜色与绿点，而"取消/拒绝"按钮导致负行动，因此用红点着色。这些颜色通常使用此含义，因此它应帮助用户直观地了解或回忆按钮的功能。
由于两个按钮具有相反的含义，因此不应被用户混淆。为了避免这种情况，我们把它们放在转向的不同侧面。应该很容易学习和记住下意识地将两只手分别与消极者联系起来，使行动取得积极成果。
因为这些按钮比其他大多数按钮更重要，所以它们更大。由于他们的联合，他们是平等的形状。
07
任务分析
为了说明驾驶员与系统的预期交互，我们执行涵盖重要操作的任务分析。与设计一样，本节在描述所有可能的操作时并不是完整的。它有助于我们想象使用情况并持续开发其他活动。
手机任务分析：
向上滑动阅览
- 使用语音识别进行呼叫
1.1 按下按钮接受/操作（音频播放器音量自动减少）
1.2 选择1.2.1 或1.2.2
1.2.1 说"呼叫"+ 联系人的姓名
1.2.2 说"打电话"+电话号码
1.3 等待确认（系统重复"呼叫"+目标）
1.4 按下按钮接受/做
1.5 执行普通电话
1.6 按下按钮拒绝/取消（音频播放器音量自动重置）
0.打个电话
1. 按下按钮接受/操作（音频播放器音量自动减少）
2. 执行普通电话
3.按下按钮拒绝/取消（音频播放器音量自动重置）
0. 拒绝呼叫
1.按下按钮拒绝/取消
- 阅读新短信
1. 按下按钮接受/做
2.听
0.发送短信（未实施错误识别更正）
1. 按下按钮接受/做
2.输入电话号码
2.1. 说"创建短信"
2.2. 等待确认
2.3.按下按钮接受/做
3. 说出短信内容
4.按下按钮接受/做
5.说"发送到"+联系人的姓名
6. 等待确认
7.按下按钮拒绝/取消
mp3播放器的任务分析：：
0. 播放音乐（计划做1或2）
1. 使用语音识别
1.1. 按下按钮接受/做
1.2.说"MP3 播放器"
1.3. 说"播放"+标题或艺术家或专辑或流派或什么都没有的名字（播放最后一首歌）
1.4. 等待确认
1.5. 按下按钮接受/做
2.使用方向盘按钮（做2.1或2.2）
2.1. 按下按钮播放/暂停（播放最后一首歌）
2.2. 选择歌曲与音频下一个/音频以前的按钮
- 停止音乐（计划做1或2）
- 使用语音识别
1.1. 按下按钮接受/做
1.2. 说"MP3 播放器"
1.3. 说"停止"
1.4. 等待确认
1.5. 按下按钮接受/做
2.使用方向盘按钮
2.1. 按下按钮播放/暂停
0.下一首歌（计划做1或2）
1.使用语音识别
2.1. 按下按钮接受/做
2.2. 说"MP3 播放器"
2.3. 说"下一个"
2.4. 等待确认
2.5. 按下按钮接受/做
2.使用方向盘命令
2.1. 按下旁边的按钮/最后一个按钮
- 使用语音识别重复音乐
- 按下按钮接受/做
- 说"MP3 播放器"
- 说"重复歌曲"或"重复所有"
- 等待确认
- 按下按钮接受/做
- 调整音乐音量
- 按下按钮+/-
- 打开语音识别（自动关闭）
- 按下按钮接受/做
08
相关工作
目前的车辆有无数的用户界面，从确定与场合到车辆的第二次控制，以允许使用的数据和转移。这一领域的大多数勘探都以手动驾驶为标识。随着机器人化车辆的不断进步，用户在识别计算机化车辆时，对用户连接的考虑也有所扩大。在调查手动驾驶和机器人驾驶的人力机器连接时，争论的焦点是如何建立安全的车内关联，帮助驾驶员完成驾驶任务，就像允许驾驶员实现不同的非驾驶差事一样。在计算机化车辆中，人机协会将逐步允许客户恢复时间，目标是将精力投入到非驾驶任务中。鉴于大多数车辆完全自动化不是太晚，因此还需要研究如何使驾驶员在各种计算机化方法之间切换。
随着计算机技术时代的发展，人机交互技术创新经历了“命令行界面”、“图形 UI ”和“通用 UI ”的改进周期。本工作调查了Kinect身体传感器的利用，在接近个人习惯的原因，让用户与虚拟场景漫游框架有特色地协作。利用创新后的Kinect骨架，通过联合聚焦之间的相对情况来感知人的立场，并利用四种自特征的姿态来控制相机视图边缘的差异，从而实现虚拟场景漫游。这是基本战略的计算，它理解人与计算机之间的定期通信，并参考了相关框架的发展。
人工智能（AI）的进步概述了UI 结构的机会和困难。二十多年来，人类-PC协作网络一直在讨论人-人工智能协会的标准，但考虑到人工智能的推动以及人工智能在人类对抗应用方面的发展应用，还需要进行更多的调查和发展。这项工作调查了18项关于人与AI合作的适当规则。这些规则通过多轮评估获得批准，包括客户集中与49 名计划专家谁尝试了规则对20 个众所周知的AI 注入项目。结果确认了规则在一系列合作情况中的重要性，并发现了我们洞察力上的漏洞，为额外的检查打开了大门。
无人机 Chi 是一种太极推动的-无人机连接体验。作为一个计划设计的研究项目，安排在一些美学的关联结构中，其中一个重点主题是发展真实和有形的感激，以提高人们的满意度。Drone Chi 通过半有序的结构周期记录，探索了自我管理的微型四轴飞行器作为身体美学 HCL 计划材料的能力。采用适度的开放式结构研究方法，从身体美学、项目规划、建筑学角度对创业进行了迭代式的构建，并大力借鉴了规划类比的象征手法来激励创业者。这提高了有限的设计边界和易用性的必需品之间的身体的影响。
交互式机器学习
希望通过将这些品质与PC 的计算力和速度紧密结合来补充人类的认知和知识。直观的周期旨在包括来自用户的贡献，但是不需要基础信息或经验，这些信息或经验对于处理更习惯的人工智能程序可能很重要。
在IML 周期下，非专家可以在任何不方便的数据集中应用其空间信息和理解来发现阴谋示例或创建复杂的信息驱动应用。这个周期是相互适应的，取决于对人和机器之间协作的谨慎管理。UI 配置是实现此方法的核心，但在如何执行此类接口方面缺乏固化标准。本工作从智能框架的角度对交互式机器学习进行了逐项审核和定性。作者提出并描绘了一个总结的IML 框架的基本和行为模型，并区分了为IML 构建强大接口的排列标准。可以想象，这些由上下文上下文的不断上升的排列标准是广泛的人类-PC引用更多的关联写作。
09
结论
本文采用人机交互技术，以及保护驾驶员通过支持用户界面使用移动设备，提出了概念设计和物理设计。这将有助于司机消除他的恐惧，而驾驶，因为这种界面提供了一定程度的安全。我们还讨论了可用性问题，包括使用系统与任务肛年。在这里，可用性取决于概念设计和物理设计。进行概念设计是为了捕捉用户与界面通信的模型。用户的模型和我们的设计模型可能是相同的。同样，物理设计模型向用户介绍了界面的可视化情况。作为今后的工作，我们将提出该项目所需的第二轮迭代开发，应开发其他几轮分析、要求和设计。
ABOUT US
参考文章：
作者：Asadullah Shaikh
译者：嗜酸菌
原文请戳【阅读原文】
为尊重版权和译者
转载请联系我们