广告

为协同工作设备设计用户接口的挑战及对策

2007-07-13 Niall Murphy 阅读:
为一种设备设计一个便宜、灵敏、有趣和迅捷的用户接口是个挑战。但若有多台设备需要相互配合工作,其挑战性会急遽增加。本文探讨了嵌入式应用中诸如向后兼容、应用整合、主辅设备、易用性、数据同步、状态同步、协同用户认证、速率差异和图形接口等为用户接口设计带来的挑战及相应的解决之道。

为一种设备设计一个便宜、灵敏、有趣和迅捷的用户接口是个挑战。但若有多台设备需要相互配合工作,其挑战性会急遽增加。

随着有线和无线通信硬件变得越来越便宜,需设计通信设备的机会将越来越多。例如,手机内的Java程序可控制用户家中的安全系统。数码录像机利用红外遥控可选择由卫星电视公司提供的机顶盒上的频道。车内仪表盘上的控制设施可遥控装在用户兜内的手机进行通话。每对设备都为用户提供了两套用户接口,且这些用户接口必须最终一道组成一个合理系统。

早期用户也许陶醉于那些保证其各式各样的玩意能相互通信的各种设置和设定。但更主流的用户希望能减少他们对是在控制不止一台设备这样一个事实的记挂。典型的居室问题是有3个遥控器,其中每个都能控制音量,但只有一个可控制所有系统。该问题在组合设备必须协同工作的许多场合都存在。

这些情况,使用户在操控两种不同设备时,必须面对两种不同的用户接口。设计师必须试图确保两种或更多种设备最终为用户呈现一个和谐一致的系统。若你在设计两种设备,你就想要使这两种设备有类似的体验。

我最近曾进行过有两个不同图形用户接口(GUI)的设计,其中一个是全屏触摸屏,另一个是小些的不常使用的“帮助”屏。小屏与全屏看起来需协调一致。简单地通过滚显小显示器来显示在大的显示器上显示的全部信息的手法对设计师来说是种懒惰的作法。必须仔细选择,以使那些一般可通过大屏获得的信息就不在小屏上显示了。采用类似的字体及背景色可使大小显示器有整体上一致的感觉,但大小屏在物理尺寸上的对比感觉,使用户自然明白,小屏不会是该设备的主要界面。

带遥控器的电视是另一种需设计两个接口的例子。对在电视本体和遥控器上都设置的按键来说,设计师选择系统符号和标识的意义并不大。一个通用遥控器必须容忍不同电视间的差异。设计师要面对折中方案,例如:为高级特性设置额外的按键,对没有这些特性的普通电视来说,这些按键不起作用。另一种选择是,使通用遥控器具有最小的按键集,它不具备某些更复杂的电视遥控器上的按键。

向后兼容能力

有许多情况,一种设备在你的控制之下,但第二种设备却早已存在。例如,若你设计一台数字视频录像机(DVR),则你也许不得不假设用户业已拥有一台机顶盒。更糟的是,你不得不假设,基于其服务提供商,他们的产品可能是众多机顶盒中的任一种。实际上,当他们在购买你产品时要使用的机顶盒甚至可能尚没被设计出,所以,你甚至无法确定你是否能在用户家中将这些需要协同工作的设备整合在一起进行测试。

若只有一台机顶盒需整合进你的产品,你需在机顶盒上建模DVR接口,以确保它们能协同工作。另一种选择是,将DVR特性集最小化,将功能尽可能多地放在机顶盒上,但该方法同样不令人满意。DVR可能采用机顶盒已不用的模拟调谐器,所以,在这种模式下,它必须支持全部功能。

许多DVR采用红外线(IR)来遥控机顶盒,如图1所示。DVR遥控器生成与机顶盒遥控器一样的IR信号。例如,当到了设定的该录制节目的时间时,DVR会利用IR遥控器来传输想要的频道。理论上,由一台设备控制切换另一台设备的想法很简单。麻烦通常在细节实施。若DVR支持1到999个频道,而有人推出的机顶盒却采用4位频道表示(1到9999),那时会发生什么情况?正是诸如此类的不匹配使各种设备间的兼容变得困难。

图1:本图显示了用户使用两个遥控器的情况:一部用于STB,另一部用于DVR,后者也向STB发射IR信号。
图1:本图显示了用户使用两个遥控器的情况:一部用于STB,另一部用于DVR,后者也向STB发射IR信号。

从PC应用整合中汲取经验

看一看不同的PC应用整合,会获得不少启发。它与你将在嵌入式设备中采用的模式有某种相似性。例如,许多代码编辑器允许你在源码控制工具内进行文件注册(check in)或退出(check out)。通常,这种注册、退出及特性读取由编辑器的按键提供。该接口是完整板控制接口的一个子集,因为它并不提供诸如得到更老或标记版本等更高级的特性。这里,另一个限制是,若有些事出现问题,则在第二个接口显示的出错信息的质量一般比在主要接口上看到的讯息或警示的质量差。

对一款嵌入式设备来说,考虑警示讯息也很重要。若主要接口有若干专用警示LED,而在次要的设备上并没有它们,则你必须考虑是否可用其它替代方法中继(relay)这些警示信息。

主辅相成

在某些情况,一个接口将提供系统可用的全部功能,而第二个接口将仅提供一个子集。例如,Fossil推出的一款支持蓝牙的手表提供一个连至手机的接口。手表显示来电号码并使用户可挂断一个来电,但它并不试图提供手机上可用的全部功能。

在电视遥控器的演进中,遥控器最初是作为不包含类似调整电视等不常用功能的辅助接口的。最近的电视发展趋向于将全部功能都放在遥控器上,有时仅将最少的功能放在电视本体。

当设计第二个接口时,要考虑是否将全部功能或其中一个子集放在其上。若仅实现一个子集,则第二个接口对用户和设计师都变得简单了。用户会理解为什么其中一个接口仅提供较少的特性。原因可能是,该接口体积更小、或预计不会频繁使用到它、或简单地就是因为一些特性是放在其它接口上的。

提高易用性

在某些情况,混合用户接口高度依赖于第二个接口的一个特殊特性。我曾研制过一个通过手机文本短信进行通信的系统。它需要用户拨打一串出现在其手机文本短信中的号码。当时,大多数摩托罗拉手机允许用户一键式拨出这些号码。但诺基亚和其它一些品牌的手机要先选择“使用号码”菜单选项,然后再选取号码。因经常会用到这种特性,所以除少数手机外,其余的在进行这种操作时,都显得很笨拙。还有一些手机根本就不允许你使用该号码,它要求用户牢记该号码并重新拨打。

在某些情况下,为注明能与多种设备兼容,设计师要绞尽脑汁。若在使用一款伙伴设备时感到困难,最好是根本就免谈兼容性,或为这些设备找到替代的通信途径。

数据同步问题

许多PDA、手机及其它设备会涉及到与PC同步的问题。一些设备具有专门在PDA上镜像数据的应用。还有一些与PC上常见的应用(如Microsoft Outlook)同步。一些手机允许你将手机日历中的约会与Outlook日历中的约会同步,如图2所示。

图2:用户日历同时在PC和PDA上显示。因条目存储在两个地方,所以可能发生冲突。
图2:用户日历同时在PC和PDA上显示。因条目存储在两个地方,所以可能发生冲突。

这种同步方式的挑战之一是要决定PC或手机上的约会谁有优先级。若手机上有个约会,而PC上没有,则该约会将被复制到手机上。反之亦然。但当发生用户取消约会的情况时,这种安排会导致在同步后,被取消的约会还会出现的情况。

若PC和手机上都有该约会,则用户既可在PC又可在手机对该约会的描述进行编辑。理想的情况是,修改有时间标志,而同步软件采用最新的约会设置。但若你用类似Outlook这样的工具进行同步,你将发现所需的历史信息并不存在。这是因为,最初在设计Outlook时,它不是为了与外部设备协同工作而设计的。任何独立的应用都会发生类似问题。在此,为与手机协同工作而专门编写的应用的优势就体现出来了——该应用可被设计成可处理所有同步事宜。

当试图整合先前存在的应用时,会发生其它兼容方面的问题。例如,许多诺基亚手机允许你在日历上为一个约会设置一个提醒。同样,Outlook也可在约会前提醒你。与约会一道,传输与提醒相关的数据是有用的。但是,PC和手机上提醒的本质是不同的。手机会发出响铃提起你的注意,它假定当提醒被触发时,你并没看到。就PC讲,提醒就更微妙,它假定你已在电脑前。用户将见到弹出的提示并听到简短的嘟嘟声。

若你在Outlook上设置一个延续至全天的约会(如生日)时,会很有趣。当设置“太太的生日”约会时,若你没输入具体时间,则Outlook假定它是个全天约会,它意味着从这个午夜到下个午夜的整24小时。缺省的提醒设置是在约会前10分钟提醒你,对全天约会来说是在午夜前的10分钟。快速同步将相同的生日复制到手机上。所以,作为生日前的“款待”,我太太会在她生日前一天夜里午夜前的10分钟被我的手机吵醒。因要直到按下手机的按键,它发出的提醒才会停止,在我摸索着从床边找到手机并将其扔出窗外前,太太将不得不忍受我的诅咒和折腾。

在我的PC上,提醒将一直等待直到我那天第一次开机。而手机上的提醒则会更多事。这样,当将一个背景下的数据更换为另一种时,会有危险。

描述的第一个问题是数据完整性—我们试图确定哪个约会数据版本是最新的。这是个可由技术方案处理的技术问题。将提醒从一个系统复制到另一个系统是第二个问题,它不是技术性问题,而是与各个设备的用法相关。因并不总存在明显的对错,这些问题解决起来可能困难得多。同步的用法之一是它会询问用户是否想保持存在PC还是PDA中的提醒设置。但若对每个不同的约会都如此问用户,将是一件乏味的事。

状态同步

当两个设备通信时,其中一个设备常常需要了解另一设备的状态。例如,若我使用一台带机顶盒的电视机,操控机顶盒的某些命令仅当电视打开时才有意义。但机顶盒却没法知道电视的状态。同样,DVR可被设成在特定时间录制节目,但要在开启机顶盒时才可能,甚至要取决于机顶盒被设置在想要的频道。若从DVR到机顶盒的通信是单向的(例如前面讨论过的IR遥控),则DVR没有办法检测机顶盒的状态、也没法改变这种状况或向用户通报此问题。

机顶盒其它可能的状态也可引发问题。以用户进入电视向导模式为例。机顶盒收到的下一个数字可能被解释为要在向导上显示的频道。电视将显示当天的节目但不会切换频道播出节目。若用户使机顶盒处在该状态,DVR不会觉察到。稍后,当定时器告诉DVR开始录制时,它将把频道数发给机顶盒。但是,这只会显示频道向导而没能录制节目。

若你的设计遭受这种状态同步问题,解决方法之一是在发送期望的命令前,总是将第二台设备复位为已知状态。例如,在任何切换频道命令前,都先发出一个退出向导模式的命令。当机顶盒不在向导模式时,退出向导命令不起任何作用。但当用户在向导模式,则设备就恢复至一个已知状态,而这正是频道切换命令功能所预期的。另一种作法是,先用IR遥控器将机顶盒关闭然后再打开,此举肯定使机顶盒处在确定的启始状态。

状态同步问题是个技术问题。将单向通信改为双向通信等类似技术方案是可行的。采取这种作法,用户将完全感觉不到该问题。在前述的约会同步例子中,可用性问题更难解决。考虑当DVR想要录制节目而用户却在机顶盒上浏览电视向导这样一种情况。这时,DVR将试图控制电视从而中断用户的浏览。一个集成系统有能力显示一个信息来询问用户——他是想继续其目前的行为还是开始录制?若DVR不了解机顶盒目前的状态,则这种方案就不可能。

若与PC应用协同工作的设备是你的兴趣所在,则很有必要读一读《内外兼修的设计(Designing from Both Sides of the Screen)》这本书。该书讨论了许多有关编写必须与PC及PDA协同工作的应用的挑战。

协同设备认证

若你的系统与许多协同设备一道工作,则用户或许不得不对其系统进行设置以便能与任何使用的协同设备进行通信。考虑能用于连接手机的串行连接这样一种情况。第一台设备必须了解进行通信的RS232设置是什么。许多手机厂商出售可将手机上的串行接口外扩为DB9连接器的线缆,使用这种电缆,手机就可被用作调制解调器或发送文本信息。

不同手机的速率和握手信号设置可能各异,所以宿主设备必须能对端口进行设置。方法之一是让用户输入波特率、寄偶校验等参数以完全设置该串口。这种手动设置方式对那些不得不从其用户手册中查找串口设置的新手来说,会感到很隔膜。

第二种方式是让用户输入手机的制造商和型号,然后宿主设备从一个内部数据库中选取相应的串口设置。这种多项选择方法对用户来说更简单,但当手机型号不全时就无能为力。而下一年推出的新手机就不在表内。若宿主设备支持互联网,则通过定期下载新的兼容设备清单就可解决此问题。

第三种方案是自动辨认。宿主设备会尝试多种设置,直到一种能工作,然后发出一个要求手机进行自我确认的命令。

还有其它场合可应用这三种方式。在某些情况,有不止一种选择可用;所以,若因设备不在表内,从而多项选择不起作用时,用户还可选择手动方式设置该接口。

速率差异问题

若与用户交互的设备必须与第二台通信,就将总会引发一定延迟。在许多情况下,与人机交互相比,因设备间通信的速率快得太多,所以用户意识不到这种延迟。但也有例外。若通信是通过互联网,则速率可有明显差异。以DVR为例,当使用红外遥控器时,遥控器发射每位频道数的速率等同于人们按键的速率,所以,发射一个三位频道数的用时会超过1秒。当这种延迟发生在家中没人且DVR打算录制节目时,它不会是个问题。但当用户使用DVR遥控器搜索频道时,每个命令都将先从遥控器到DVR然后再接送至机顶盒。这样,从用户改换频道到新频道出现在电视上之间就会有显而易见的延迟。

若数据需以图形化实时显示,则通信延迟和吞吐量问题会限制该功能。在医院重病看护室,常见的做法是将几个病人监视器连至一个中心站以显示收集到的数据。在某些情况,宿主设备可将病人的关键症候表现为图形。但是,连至中心监视器的吞吐率也许不会允许显示一个连续的时间图。由采样间隔超过200ms的像素点组成的图形看起来将开始出现抖动。辅助设备可显示一个上升或下移的单一条图,它不需要象时间图表那样频繁的更新。若你需进行如此要求的一个设计且需要辅助设备提供宿主设备上所有的完全接口,这时要切记:要保证通信连接足够快以使辅助设备有与宿主设备接口采样数据速率相同的数据访问速率。

用图形“说话”

拥有图形接口可使呈现给用户的接口具有更多种变化。一些通用遥控器具有提供看起来与被仿真的遥控器型号相象的图形显示。这意味着所有名称和符号可与原型遥控器所用的术语和图示规范相匹配。

PictBridge是一种支持将数码照片从照相机通过USB总线直接发送至打印机打印的通信技术。该技术利用了全部兼容PictBridge的照相机都有LCD显示器这样一种便利,该特性允许用户在照相机上浏览一系列菜单。虽然可与打印机通信的照相机的种类很广,但其共性都是可在其用户接口中提供菜单。

图形支持通信两端的任一设备对被显示的用户接口元件进行定义。在一个由菜单驱动的系统中,菜单内容既可事先确定,又可在运行时由一台设备定义后再发至另一台设备进行显示。但若用户接口必须服务于除英语外的其它多种语言,则会引发有趣问题。因需采用适当的语言生成菜单项,所以在两个设备的通信协议中约定具体语言是重要的。

HTML允许一个支持浏览器的设备显示一个完全由远端设备控制的接口且不需事先整合任何设备。但HTML接口存在其它问题,我在其它文章中,曾对这些问题进行更详尽的论述。

利用图形可解决某些问题,但它又会带来新问题。若用户接口是由一台设备为在另一台设备上进行显示而创制的,则在分辨率和色彩深度方面会有许多变异。这些变异意味着不同设备间的用户体验可能会有许多差异。基于显示能力,设备间的协议也许会涉及到沟通,在沟通后,一方也许会拒绝与不具备最低显示能力的设备进行交互。

若在你的领域内,互操作性问题是个实在挑战,则就有必要考虑是否存在一个整合方案市场。带内置DVR的机顶盒可解决这里描述的许多问题。当然,在许多场合,并无法提供一个点对点的方案。

作者:Niall Murphy

nmurphy@panelsoft.com

本文为EET电子工程专辑 原创文章,禁止转载。请尊重知识产权,违者本司保留追究责任的权利。
您可能感兴趣的文章
相关推荐
    广告
    近期热点
    广告
    广告
    可能感兴趣的话题
    广告
    广告
    向右滑动:上一篇 向左滑动:下一篇 我知道了