随着移动计算设备和各种传感器的普及,应用程序和服务的新资源——通常统称为情境感知计算——正在为设计师和开发人员所用。在本文中,我们考虑了在新通信服务中利用情境感知的潜在好处和问题,这些服务包括 VoIP(IP 语音)和传统信息技术的融合。
为了使讨论更具体,我们描述了 IBM 在过去几年中开发和部署的两项服务,以帮助人们更有效地沟通。我们研究了已被证明有效的方法,以及仍然存在的问题。这两项服务具有略微不同的重点。第一项服务名为 Grapevine,它通过聚合和过滤的一组情境信息,帮助一个人与另一个人进行交流。第二项服务是 IBM Rendezvous Service,它帮助人们在电话上会面和交谈。虽然人们今天显然在没有情境感知服务的额外帮助下也在做这些事情,但这些服务的目标是让人们做出更好的沟通选择,进行更丰富和更有价值的互动,并减少完成互动所花费的时间,同时为企业节省大量成本。
许多人注意到,计算早已扩展到桌面之外。例如,IBM 阿尔马登研究中心的 Thomas P. Moran 和加利福尼亚大学的 Paul Dourish 在 2001 年写道:
计算现在被封装在各种设备中。更小更轻的笔记本电脑/笔记本电脑,与传统的个人电脑一样强大,将我们从单一桌面的束缚中解放出来。手持个人管理器等专用设备足够便携,可以随时随地携带。无线技术使设备能够与电子世界完全互连。相机和录像机正在被数字等效物所取代,而我们越来越多地在数字和固态设备上听音乐。手机实际上是联网的计算机。通信和计算之间的区别正在模糊,不仅在设备中,而且在计算允许我们进行通信的各种方式中,从电子邮件到聊天到语音到视频。1
正是在这种背景下,情境感知计算几乎令人着迷的前景出现了:手机知道何时保持安静;传感器可以判断何时是打断的合适时机。接下来会是什么?也许是一张公司信用卡,如果即将发生的费用不可报销,它可以发出警告?虽然智能设备的梦想在计算机科学界已经存在了一段时间,但它尚未对我们用来完成工作的应用程序和服务产生深远的影响。为什么没有呢?
简单的答案是因为很难做得好——甚至足够好。毕竟,桌面是一个相对受控的环境,而现实世界是动态且复杂的。技术可以“理解”为情境与人们理解情境之间的差距是巨大的。事实上,一些批评家断言,情境感知计算在试图将人类从创建智能自主设备的控制回路中移除时犯了一个根本性错误。2另一种策略是捕获情境,但将其结果呈现给人类以决定采取什么行动。IBM 研究在将情境感知应用于 IBM 员工每天使用的一些通信工具时,就采取了这种策略。它尚未产生我们认为可能(也许是不可避免的)的深刻影响,在这里我们考虑造成这种结果的一些原因。
Grapevine 服务(最初在 2004 年 2 月的 期刊中描述)3于 2001 年开始在 IBM 内部使用,研究项目于 2005 年完成。其最有用的功能已被吸收到 IBM 产品中。简而言之,Grapevine 通过嵌入到流行的现有应用程序(如电子邮件、即时消息、企业目录、网站等)中的新动态程序元素,向观察者揭示用户的上下文。这个程序元素以带有实时信息的名片形式呈现给最终用户,称为 Grapevine 电子名片。图 1 是电子名片的示例。
电子名片提供了有关所有者当前情境和活动的信息。这使得潜在的沟通者可以利用情境信息来决定何时发起联系以及通过哪个渠道。Grapevine 使用的情境来源是个人电脑、移动无线 PDA、电话和运动探测器。从这些设备中提取和衍生出的情境包括物理位置、计算机应用程序活动(例如,用户当前是否正在使用 IM 或电子邮件?)和电话活动。
使用户的活动对其他人可见会引发隐私和控制问题,因此 Grapevine 还提供了一个简单的模型,用于为用户的电子名片指定默认的情境感知级别,以及用于允许更大程度“情境透明度”的个人或组特定机制。这如何帮助人们沟通?人们如何应对潜在的问题?
一个人当前或最后已知的物理位置是 Grapevine 服务提供的最有用信息。观察者使用对象的位置不仅来选择合适的沟通方式(即时消息、电子邮件、走到办公室),而且有时还决定与谁沟通。例如,如果您发现您想沟通的人一小时前最后一次已知是在该国家的另一边,您可能会选择另一个人进行咨询。请注意,此人最后已知的位置与该对象最后一次已知在该位置的时间相结合。时间戳可以使“过时”的位置信息有用。
位置与其他信息相结合,以支持沟通决策。例如,一位同事可能会观察到您在清晨在家上线,然后您离线。这位同事推断(正确地)您正在去办公室的路上,并决定不打电话,而是等到您到达时与您亲自交谈。
在推出 Grapevine 服务时,我们努力确定哪些计算机活动与沟通决策相关。例如,Grapevine 情境代理监视用户笔记本电脑上 IM 和电子邮件应用程序、编程工具、演示工具等的活动。每当代理观察到活动变化时,它都会向中央情境聚合服务报告。我们相信,观察者(在所有者的许可下)将能够使用此信息来做出更明智的沟通决策。
在有限的程度上,提供这种情境确实像我们想象的那样发挥了作用。例如,积极使用编程工具的人报告说,他们希望同事在那段时间内避免用不必要的即时消息打断他们。然而,大多数用户并没有发现应用程序活动情境有用,原因有很多。
首先,用户通常不希望别人知道他们在做什么。Grapevine 服务提供了对谁可以观察哪些情境元素的完全控制,用户通常会阻止所有人随时查看他们的计算机活动。虽然该服务允许按观察者进行阻止,但很少使用。这是一个需要进一步研究的领域。
其次,人们使用应用程序的目的不止一个。这使得很难通过查看一个人对计算机应用程序的使用情况来确定他的情况。有两个例子很突出。Grapevine 情境不仅可以检测到人们正在使用 PowerPoint,还可以区分编辑模式和演示模式。因此,观察者可以看到用户是“正在编辑幻灯片”还是“正在演示幻灯片”。虽然这有望成为沟通决策的有用指南,但在实践中,人们通常在演示模式下查看幻灯片(并且在编辑模式下演示幻灯片也很常见);因此,观察者无法可靠地确定用户何时真正进行演示。
即使考虑到这种不确定性,当用户处于演示模式时,Grapevine 自动抑制传入即时消息的功能可能有助于防止消息在演示期间弹出到投影屏幕上的潜在尴尬。因此,用户可能容忍错过一些 IM,即使是在演示模式下私下查看幻灯片时也是如此。多用途应用程序的另一个例子是 IBM 公司电子邮件应用程序 Lotus Notes。由于 Notes 环境除了电子邮件之外还支持各种应用程序,因此当您观察到 Grapevine 用户正在使用 Lotus Notes 时,您无法可靠地断定该用户正在进行电子邮件操作。
更广泛的观察是,许多人并不关心另一个人在想与他沟通时在做什么。最重要的问题通常是“我可以使用即时消息吗?”或“我可以打电话吗?我应该用哪个号码?”我们从 Grapevine 使用情况中收集的数据无法确定为什么会这样。也许这与技术的关系不大,而与个人习惯或文化的关系更大,但这个领域需要更多的研究。
Grapevine 服务在其生命周期中经历了三个主要修订版本。我们放弃了未使用的功能,并加强和引入了我们认为有用的新功能。以下是一些经验教训,这些经验教训普遍适用于情境感知系统:
不要期望用户做任何额外的事情来提供情境。依赖于手动用户操作的情境将不可靠。
必须有一种简单、强大且直观的方式,让用户在情境信息的可见性方面获得安心感(从而获得控制权)。否则,用户将简单地选择退出允许使用他们的情境信息。相当多的用户对其他人跟踪他们的物理位置和/或与计算机相关的活动的能力表示担忧。我们提供了一些简单且侵入性最小的方式供用户控制其情境信息的可见性,但似乎没有一种方式流行起来。人们没有广泛使用它们,并且他们对预测和管理公开个人信息的后果感到不舒服。
人们期望从即时消息中获得实时情境。虽然 Grapevine 服务允许将电子名片嵌入到电子邮件和网页中,但大多数用户发现,瞥一眼他们的 IM 客户端以查看增强的情境是快速了解另一个用户当前情境的最方便和最有用的方式。
低级传感器和程序可以检测到的信息与一个人与他人沟通的高级能力和意愿之间存在巨大的语义差距。4计算机科学家通常所说的情境通常与技术的关系比与工作情境、人或心境的关系更大。虽然低级信息很有用,但它只是用户社交情境的粗略指标。这种模糊性在社交上可能是有用的;5然而,在界面中呈现和标记传感器数据时必须谨慎。使用 Grapevine,我们倾向于对最终用户的整体或高级活动做出假设,而这些假设是低级传感器数据无法保证的。情境感知系统的构建者应仔细考虑如何将传感器数据映射到最终用户视图中。
IBM Rendezvous 服务允许人们使用电话(在电话上“会合”)和/或提供电话功能的计算机应用程序进行小组交谈。这类似于音频会议,该服务似乎是音频会议之上的一个层。但是,IBM Rendezvous 服务的用户实际上不是直接拨入音频会议,而是拨打他或她的公司日历,从中选择一个会议,并与受邀参加该会议的人进行多人对话。该服务的目标是 IBM 员工中高度移动的人群,他们可能经常在无法方便地访问其正常 IT 资源(例如,高带宽访问、笔记本电脑、公司应用程序等)的情况下工作。
Rendezvous 项目比 Grapevine 项目更新(在撰写本文时,Rendezvous 已被大约 700 人使用,从公司高管到技术人员,持续了两到六个月),因此对于用户会发现哪些功能有帮助,了解的还不多。
Rendezvous 系统包含个人情境的两个主要用途:一个系统是方便人们进入他们的电话会议,尤其是在他们移动时;另一个系统是一种情境感知形式,它添加了有关通话中的其他人以及通话本身状态的信息。情境感知通过称为电话会议代理的可视化来提供。
首先,由于大多数人通过非 VoIP 硬件(即,通过由麦克风、扬声器和标准键盘组成的“普通”电话设备)使用 Rendezvous,因此情境用于使人们尽可能快地进入他们的会议,并尽可能少地与 Rendezvous IVR(交互式语音应答)系统(昵称“菜单先生”)交互。有效利用情境使人们在几秒钟内进入他们的会议,并有助于解决当今企业环境中常见的沟通问题。以下是我们的一些技术:
呼叫设备的凭据有助于识别和验证用户。这可能像用户个人电话的来电显示(例如,他的手机)一样简单,或者是由充当电话的软件(所谓的“软电话”)发起的呼叫可以提供的更明确的信息。由于使用 IVR 识别和验证呼叫者可能需要 20 秒或更长时间,因此这对用户来说是一个很大的便利。
一天中的时间用于选择用户日历上最合适的起点。对于许多用户来说,这很容易,因为他们的日历是按时间顺序排列的稀疏事件列表。更高级别的员工倾向于将会议重复预订到同一时间段,并且使用一天中的时间作为起点来允许滚动浏览当天的事件似乎是一种有效且易于理解的技术。
会议主席的日历用于检测已推迟或重新安排的会议。移动用户对会议的时间或日期的更改感到惊讶的情况并不少见。通过呼叫情境感知日历服务,此类用户无需收听几分钟的等待音乐来发现会议已被重新安排。相反,可以立即告知呼叫者主席已重新安排会议,而不会浪费时间或打断他人。(有趣的是,数据显示,相对较高比例的电话会议只有一个用户。此类通话不仅对组织造成成本,而且还浪费了用户的时间。)
呼叫者的公司或社交网络可以解决有关会议或访问问题的困惑。IBM Rendezvous 服务的用户必然依赖于他们的公司日历作为他们与会议的链接;实际上,如前所述,日历提供的情境允许更轻松地验证身份和访问会议。但是,如果由于某种原因,Rendezvous 系统未能让用户进入电话会议怎么办?Rendezvous 服务允许此类用户向可能能够帮助解决问题的同事发送即时消息。此服务称为 iHelp(即时帮助),将在下一节中详细说明。
这些技术描述了 Rendezvous 服务如何与公司资源(如来电显示、日历和即时消息)集成。通过采用这种方法,Rendezvous 有可能通过提高电话会议运行的会议的效率来为用户实现价值,但这只有在其能够像通常查找电话会议号码和密码并拨号的方法一样高效地让人们进入他们的通话时才能实现。初步评估数据表明,该系统在这方面正在满足用户的期望。6
除了轻松进入通话之外,Rendezvous 的大部分附加值是通过电话会议代理(图 2)传达的,这是一种在通话期间可以供访问笔记本电脑的用户使用的可视化。电话会议代理提供有关通话及其参与者的信息。具体而言,代理显示:(1)会议剩余时间;(2)通话中的已验证用户、会议主持人(星标姓名)、谁在讲话(姓名旁带有语音气泡的用户)以及谁处于静音状态(灰色姓名,未显示);(3)哪些参与者尚未到达;以及(6)最近的操作。此外,用户可以访问通话中任何人的公司目录信息(4,5)或发起即时消息会话(通过双击姓名)。会议主持人可以“锁定”会议,以便没有人可以再加入。
Rendezvous 的目标是繁忙的公司用户,他们可能不愿意在手机上“啄”出即时消息。因此,Rendezvous 提供了一种从普通旧电话使用即时消息的方式,而无需大量“啄”。iHelp 服务使用呼叫者的公司网络、社交网络和日历来确定一组可管理的人员,他们可能能够在任何给定日期帮助呼叫者获取有关即将到来(或正在进行中)的会议的信息。当 Rendezvous 服务的呼叫者要求发送即时消息以寻求进入会议的帮助时,该服务会确定一组适度大小的可能能够提供帮助的人员。然后,要求 Rendezvous 呼叫者在其电话键盘上按下三个键,对应于 IM 接收者姓氏的前三个字母。在极少数情况下,两个或三个姓名与三键序列匹配,则使用额外的提示来选择目标姓名。
一旦确定目标,预编译的即时消息就会发送给该人。(允许请求帮助的人将简短的语音片段附加到即时消息的明显扩展已经计划好,但目前未向 Rendezvous 服务的用户提供。)即时消息标识了请求帮助的人,并为响应者的固定操作提供了条件,这将导致沟通。这些固定操作允许发生以下情况之一:
尽管 Rendezvous 服务的使用时间还不足以确定 iHelp 对大量人群的价值,但人们已经使用它来解决有关待定会议的问题。此外,这似乎是一项功能,可以在通常不配对的设备(即,普通旧电话和笔记本电脑)之间提供通信,并且可以用于解决不涉及会议调度的通信问题。我们希望在这个领域做更多的研究。
IBM Rendezvous 是一个早期示例,它允许使用普通旧电话的 IBM 员工访问其他公司资源,如日历和即时消息。由于普通旧电话上的用户界面比个人电脑或 PDA 上的用户界面更受限制,因此使用情境来简化用户体验就显得尤为重要。虽然功能更强大的 PDA 和具有更丰富的数据应用程序的手机提供了访问相同资源的另一种方式,但在当前的部署环境中,以及在可预见的未来,需要一种允许用户从普通旧电话参与的解决方案。这使得 Rendezvous 能够在最广泛的情况下适应移动用户。
解决情境感知应用程序和服务的难题和前景取决于技术、组织、社会和文化因素在不断变化的格局中的复杂相互作用。这些因素包括在技术上可行的可用情境信息类型;在设备、带宽和成本的分布和性质方面可以做出的实际可行的假设;在我们的想象力约束范围内什么是可能的;以及用户将感知为有价值的,以及在社会和文化上适当的事物。因此,在现实规模上部署真实应用程序和服务的经验至关重要。
正如 Moran 和 Dourish 雄辩地指出:
情境感知计算的一个目标是获取和利用有关设备情境的信息,以提供适合特定人员、地点、时间、事件等的服务……然而,这不仅仅是收集更多关于复杂情况的情境信息的问题。更多信息不一定更有帮助。此外,收集有关我们活动的信息会侵犯我们的隐私。情境信息只有在可以被有用地解释时才有用,并且必须以敏感的方式对待……情境感知在理论上是好的。研究问题是如何使其在实践中发挥作用。
我们完全同意。
JIM CHRISTENSEN 于 1983 年加入 IBM 的 Thomas J. Watson 研究中心,在那里他从事编程环境、理解程序执行的工具、数字成像和联合多媒体库以及帮助人们沟通的情境感知应用程序的项目。他曾在 IBM 担任管理和工程职位,并获得过无数奖项。
JEREMY SUSSMAN 是 IBM Thomas J. Watson 研究中心的研究人员,他是社交计算组的成员。他目前的工作涉及设计、构建和评估 CMC(计算机介导的通信)系统,以支持团体和组织。他拥有加州大学圣地亚哥分校的计算机科学硕士和博士学位,以及普林斯顿大学的计算机科学学士学位。在研究生工作之前,Sussman 曾从事 CASE 工具的基于对象的存储库工作。他的研究兴趣包括 CSCW(计算机支持的协同工作)、用户界面设计、容错和分布式计算。
STEPHEN LEVY 是 IBM Thomas J. Watson 研究中心的咨询设计产品工程师。他于 1979 年加入 IBM,担任通用系统部门的系统工程师,为 IBM Series/1 开发电话和语音存储转发产品。目前,他正在开发新的会议应用程序和用户界面,以支持作为 Rendezvous 项目一部分的会议。
WILLIAM BENNETT 是 IBM Thomas J. Watson 研究中心的研究人员。他于 1977 年加入 IBM,担任电气工程师,并担任过许多技术和管理职位。他的专业技术兴趣包括个人通信系统中情境的使用、分布式系统中的系统架构和网络以及自动化部署和管理。Bennett 拥有辛辛那提大学和波士顿大学的三个工程学位。
TRACEE VETTING WOLF 是 IBM Thomas J. Watson 研究中心的设计师。她在视觉传达、建筑和交互设计方面拥有 18 年的专业设计经验。她在 IBM 研究院工作了近六年,在此期间,她一直是社交计算组的首席设计师。她的研究兴趣包括了解如何在在线环境中创造场所感,以及如何在这些空间中适当地支持互动,重点是在线社交环境中的协作体验。她最近加入了 IBM 研究院的学习部门,以从事自适应学习模拟的研究。她拥有明尼苏达大学的图形设计学士学位和建筑学硕士学位。
WENDY KELLOGG 是 IBM Thomas J. Watson 研究中心社交计算组的经理,她的工作重点是用于支持组织工作的计算机介导的协作系统。她拥有俄勒冈大学的认知心理学博士学位。她是 IEEE 和 编辑委员会的成员,并于 2002 年当选为 会士。
最初发表于 Queue 第 4 卷,第 6 期—
在 数字图书馆 中评论这篇文章
Vinnie Donati - 推动组织可访问性
在本文中,我们将探讨 Microsoft 如何在其整个组织中推动可访问性,并且我们将仔细研究促进包容性文化的基本框架和实践。通过检查诸如意识建设、战略发展、可访问性成熟度建模等方面,我们旨在为开始其可访问性之旅的组织提供指南。我们的想法是分享我们学到的知识,希望您可以借鉴它,对其进行调整以适应您公司的目标,并以一种不仅仅是勾选复选框活动的方式培养可访问性,而是真正融入您的文化。
Shahtab Wahid - 设计系统是可访问性交付工具
设计系统是为消费者(设计师和开发者)构建的基础设施,他们致力于应用程序的开发。一个成功的设计系统能够帮助组织内的消费者快速扩展跨应用程序的设计和开发,提高生产力,并建立一致性。然而,许多消费者并没有准备好构建无障碍功能。组织是否可以使应用程序的无障碍支持构建变得可扩展、高效和一致?本文探讨了设计系统如何成为支持无障碍的重要载体。
Juanami Spencer - 移动应用的可访问性考量
在创建移动应用程序时,考虑可访问性至关重要,以确保尽可能广泛的受众可以使用并享受它们。与桌面体验相比,移动可访问性有其独特的考量因素,但它为那些在日常活动中依赖移动设备的用户提供了巨大的价值。通过牢记这些考量因素,移动产品开发团队可以更好地支持和提升所有用户的生活。本文探讨了移动应用程序的一些关键可访问性考量因素,并重点介绍了 Bloomberg Connects 应用程序如何在产品和流程中支持可访问性的几种方式。
Chris Fleizach, Jeffrey P. Bigham - 系统级可访问性
本文通过我们使 iPhone 能够使用 VoiceOver 屏幕阅读器进行非视觉操作的工作,阐释了系统级可访问性。我们为非视觉使用重新构想了触摸屏输入,引入了适用于屏幕阅读器控制的新手势,并且对于输出,我们添加了对合成语音和可刷新的盲文显示器(输出触觉盲文字符的硬件设备)的支持。我们添加了新的可访问性 API,应用程序可以采用这些 API,并且我们的用户界面框架默认包含它们。最后,我们添加了一个可访问性服务,以桥接这些新的输入和输出与应用程序。