[转] ARS：Palm Pre，体验webOS（二）

By Jon Stokes [url=yangjianhua@gmail.com]猪油伴饭[/url]译，译文授权ifanr全文发布，转载请注明ifanr译文链接。此文同步发于译言http://www.yeeyan.com/articles/view/7196/51016 在本次Palm Pre体验的第二部分（第一部分为黑莓杀手），我们将深入研究手机的软件部分。webOS这一操作系统真的能够使Pre成为一部Palm公司宣称的“云”消息手机吗？本部分还包含了日历、浏览器、联系人、提醒、拨号盘以及其他的手机特性的介绍。 在关于Palm Pre和webOS第一部分的体验中，我试图通过分析证明其是一部基于云消息处理的设备。该部分的重点是为了说明Palm将社交网络（SNS）、BlackBerry的云消息处理机制如商业邮件和iPhone的便携媒体特性整合到一部手机之中的野心。经过分析之后，得出的结论是，Palm意在从RIM一统天下的商务市场中分得一杯羹。 但不可否认的是，无论Palm对于基于webOS手机的最终规划和期望是怎样的，消费者都会把Palm Pre拿来和iPhone进行对比。而这也是恰当的，因为Pre是第一款真正将iPhone的用户体验作为一个基准点进行设计并试图提升iPhone体验的手机，而不仅仅是简单的界面模仿。 因此，在本部分中，我们暂时把Pre和BlackBerry的对比放在一边，而更多的关注Pre和iPhone的较量。Pre和iPhone的对比不仅仅包括UI，还包括可用性分析，这是因为webOS设计的意图是借鉴iPhone良好的用户体验，并且将之应用到另外一种完全不同的信息管理模式之下（详情见下文）。 最后，我们放下所有和BlackBerry及iPhone的对比，回到Pre的主题上来：云通讯设备和基于移动多任务的应用平台。将会有另外一部分专题描述Pre的媒体处理能力（照片、蓝牙立体声、音频和视频播放、媒体播放等等）以及在其iLife生态系统中处理的好的或不好的部分，如果有需要的话，我将会写第三部分。 开始 本体验第一部分的诸多回复是一个极好的例证，证明了人们对一个设备当前关注的热点和该设备下一代产品的设计方向，与其最初的设计初衷是密不可分的。以iPhone为例，不管其如何演化，其设计初衷是十分简单直接的，正如乔布斯在第一次发布iPhone的时候所说的那样，iPhone是如下产品的融合：触屏控制的宽屏iPod、电话以及互联网通讯设备。于是，人们对iPhone的最终印象就成了宽屏、网络媒体播放器，还有其他的功能如电话和互联网等等。 相比之下，Rubinstein在介绍Pre的时候称之为一个云消息设备，同时还包含一些其他功能，如媒体播放等。就如同提起iPhone OS会让人马上想起多媒体一样，提到webOS，人们第一时间想到的就是面向消息的特性。 我们可以做一个回顾，以便使我们更好的在连接和同步、界面和多任务处理等各个方面对iPhone和Pre进行对比。 iPhone OS 连接和同步：绑定到特定的电脑（后来绑定到MobileMe帐号），并且保存到特定的应用程序的数据竖井，该数据存储保存的是结构性的数据，用于组织和浏览； 界面：单一的触摸屏，用于浏览、显示以及操作； 多任务：iPhone认为你同时只需要运行一个任务； webOS 连接和同步：数据均来自服务，而非特定存储； 界面：既有物理键盘，也有触屏，期望用户进行检索、过滤、通过查询定位信息； 多任务：在任何时候都是多任务的，因为通讯应用程序总是作为后台进程运行； 通过以上的对比，可以清晰对两种设备设计的优缺点均有一个了解；但以上的对比同时蕴含了一些更深层次、更基础的理念，这些理念触及到就是我们组织和发现信息的核心方法。 Yahoo、Google和Web的螺旋形进化 过去五十年间，计算机的发展告诉我们一个事实，就是同一个基本问题总是以不同的形式不断的出现，因此，科技的进步很少是按一条直线顺利向前的，而是曲折不断的，每一次的曲折所呈现出的都是同一个问题的另外一个角度。 网络的发展也正是如此，以我15年的互联网使用经验，我发现信息的发现和管理总是在两种截然不同的模式之间跳转。第一种模式的典型就是早期的Yahoo!目录结构，我称之为结构-浏览模式。这种模式的核心思想对于较少的数据，通过对数据进行结构化然后对数据进行管理。Yahoo!使用人工的方式对网页进行专门的分门别类，为互联网创建了为数巨大的卡片分类信息。如果需要查询信息的话，你就可以按照Yahoo!形成的分类结果进行查找和浏览。 但是随着数据量的急剧增加，这种方式遇到了瓶颈并且最终使得结构-浏览模式失败，与此同时，第二种模式——我称之为收集-查询模式——开始出现，成为了处理海量非结构化数据的最好的解决方案。这种模式的最好例证就是Google，Google以大容量的存储（也就是收集）、带宽和计算周期（也就是查询）代替了传统的人工整理，从而使得数据的整理变得更加快速，而且其成本也比人工要低廉得多. iPhone OS和webOS在日益廉价的处理器、带宽和存储的驱动下，再次上演了Yahoo!和Google的轮回。 从本体验的前一部分我们就隐约可以看到，iPhone，甚至包括其他所有的Apple系统，均假定你的联系信息存在于某一个信息存储之中，要么存在于你的Mac之中，要么存在于你的MobileMe服务器上。取决于你主动的更新该存储，管理结构并且进行浏览。 结构-浏览模式在进行管理的时候工作量大，消耗的时间也长（譬如媒体文件），Apple在其全线产品（包括iPhone）对这种方法不断进行完善。实际上，Apple的所有产品，从Finder到iTunes到iPod再到iPhone，其所采用的均是浏览结构化数据的方式。 相比之下，Palm OS的核心设计理念是基于收集-查询模式的，目前Pre的大多数应用程序，都假定你的所有动作均开始于在物理键盘上键入然后查询。或许你希望查找的是联系人、应用程序或者网页历史记录，无论是任何东西，即使是在你可以浏览的情况下，webOS也希望你可以从输入开始。 这种尝试的核心就是全局搜索栏，Rubenstein在其CES展示中也做了很好的阐述。当你打开Pre并且开始输入的时候，Pre的全局搜索开始搜索联系人、Web书签以及其他设备字典；如果找不到信息的话，他会提示你去搜索Google、维基百科或者是Twitter。 (webOS全局搜索屏幕) 注意如果你开始输入的字母键同时也是数字键的话，则可以直接拨打电话。 如上图所示，搜索框将输入的内容同时解释为数字“5”和字母“F”。 当我们体验完Pre的主要特性的时候，我们会发现收集-查询模式在不同的应用程序中会不断的出现，而在少数功能上，没有使用收集-查询模式，我们会明显的感到别扭。 启动应用程序 在webOS中，第一个键入比浏览更快捷的地方就是当你启动应用程序的时候，在桌面视图中，当键入某个应用程序的第一个字母，应用程序将会按照该字母进行过滤。 键入第二个字母将会在屏幕底部同时出现联系人，应用程序的显示窗口同时变窄。 在打开键盘的情况下，这是启动较少使用的应用程序的最好的方法；否则的话，你就只能在webOS的程序管理器界面上通过滚动翻屏图标直到找到该应用程序为止。 上图可以为你解释应用程序管理器如何管理应用程序。 首先，你可以向下翻屏以显示更多的图标，翻屏图标在屏幕的下方。该图标右边的两条白线和iPhone程序管理器底部的白点有同样的效果，告诉你还有两页应用程序。 在不同的页之间浏览应用程序的方式和iPhone是一样的，通过向左或向右滑屏来实现。和iPhone类似，应用程序工具条始终都在屏幕的最下方保持不动。 webOS的卡片模式和Apple受限于Windows3.1的MDI思路 webOS和iPhone OS 3.0相比最大的一个优点是其将技术隐藏在操作之后，或许Apple的手机最终会支持多任务，然而webOS的卡片模式已经给了用户一种很好的同时操作多应用的方法。 当程序启动后，webOS从屏幕下方产生了一个“活动卡片”，这些卡片以垂直的形式在界面上展示，用户可以通过向左或者向右拖动卡片来切换任务。同时，还可以通过按住卡片不动将之缩小，然后可以重新排列卡片的位置。 webOS的卡片和Mac上的窗口极其类似：一个应用程序可以产生多个卡片，这些卡片是平级的，并没有任何一个卡片是“主程序窗口”。在下面的截图中，可以看到我依次启动了一个浏览器打开Ars网站、一个日历，以及另外一个浏览器打开Google新闻 通过上图你会发现，webOS的卡片模式和iPhone启动Safari浏览器之后的多网页浏览窗口切换模式是类似的。但是，Apple的这一操作模式和Windows操作系统下的“多文档窗口”非常类似，不过，Apple的操作有点让人觉得“拧巴”：首先，你必须要启动Safari主界面，然后，这一主界面就可以产生多个子窗口。——继承于Windows的这一多文档窗口模式是广为诟病的。 由于iPhone到目前为止并没有做到真正的多任务，所以我尚无法看到Apple如何避免多文档窗口(MDI)模式。 当然，webOS的活动卡片并不是完美的，最大的问题就是Palm在屏幕的顶部提供了一个卡片的选项按钮，通过点击该按钮可以打开当前应用程序的下拉菜单，该菜单允许用户编辑应用程序的参数，以及拷贝/粘贴或者其他的应用程序指定的功能。 这个选项按钮太小了，非常难以点击，我几乎总是要多点几次才能点中。当启动日历等程序的时候尤其容易点错，因为日历程序本身又有一个选项按钮，点击的时候会弹出“跳转到其他日期”的功能，和卡片的选项按钮非常容易混淆。 既然Palm已经在偷用Apple的把戏了，那么它应该把Dashboard的“翻转部件进入配置界面”的功能也拿过来，每个活动卡片应该有一个背面，在背面上，包含所有的部件功能选项。 最低限度，如果Palm仍然希望保留选项按钮的话，那么应该给用户一个新的手势以启动该选项页面。 手势区域 Palm的手势区域是一个非常了不起的创意，而且其潜力无限，目前的webOS在手势区域上仍可大做文章。这个区域是触摸屏可见区域下面的扩展部分，用户通过各种手势可以与系统进行交互。 尽管这部分只不过是一块轨迹板而已，但它的真正好处是webOS通过几种轻打、拍、滑动等几种简单的手势就可以变换屏幕窗口，从而节省了屏幕的空间。 我发现Palm的backward swipe动作——也就是webOS通用的浏览器后退方法——真是非常好用，以至于我在iPhone上都偶尔想使用这个手势。在卡片的子窗口中——比如说是卡片的参数窗口——这个手势可以返回到主窗口；如果你已经在主窗口的话，这个手势可以缩小所有的卡片并使你选择。 和backwards swipe相关的是上推手势，如果你在某一个应用程序子窗口——比如，在Pre的备忘录程序中写备忘的话，上推手势会缩小卡片从而使你可以切换其他打开的卡片；如果你已经在缩小模式的话，上推手势将会返回到应用程序界面。在程序管理器上推的时候会关掉它，和使用backward swipe一样。 最后，是著名的“波浪”手势，Palm称之为“快速启动”，快速启动手势轻敲手势区域，然后向上移动手指到可见区域，将会调用应用程序工具条，从工具条可以启动电话、联系人、邮件、日历或者其他的应用程序。我发现我自己使用这个手势非常多，它同时也强调了webOS系统界面设计的一个原则：同一个事件可以有多种操作方式，你可以自然而然的使用其中任何一种。有时候，你可以通过几个手势返回到桌面窗口，并且调用出快速启动栏；或者你可以可以通过简单的快速启动（“波浪”）手势来做到这一点。 手势区域尽管很酷，但其仍然没有做到利用最大化。Palm可以增加一些其他的手势，或者允许开发人员或者最终用户自行设置手势，我打赌如果Palm肯开放的话，人们会利用这里做出很多让我们惊奇的效果。 地址本：对比明显 iPhone地址本，和iPod应用类似，希望用户在启动之后就马上浏览相应的记录。当然也可以通过搜索功能进行搜索然后得到结果，但是操作步骤较繁琐：首先要点击搜索窗口调出软键盘，然后开始键入搜索的内容。初始的调用软键盘步骤是必要的，因为整个设备的设计思路是围绕着结构-浏览模式进行设计的，因此，iPhone的缺省用户交互模式就是浏览某一个结构化的集合（联系人、音乐或者应用程序等） 浏览Pre的地址本，正如其他试用者所指出的那样：简直就是乱七八糟。webOS希望展现的记录是一个联合服务查询的集合，而不是一个结构化的、仅供浏览的数据存储。所以，只要将某服务——Google、Exchange、Facebook、AIM——增加到Pre上，它就会把这些服务的所有的联系人都取下来，形成一个大的按照字母排序的列表（我的大概有450个条目） 当你启动Pre的地址本的时候，Pre希望你通过在物理键盘上输入联系人的名称开始，webOS会将范围缩小到指定的记录上。如果你希望浏览以找到联系人的话，那么你是在浪费时间，因为数据并不是为这种方式设计的。Pre希望你查询一个服务，而不是浏览一个存储。 或者可以这样说更为准确：Pre希望你首先增加联系人服务，然后它通过联合查询将记录返回到手机上，然后你再通过查询功能定位到某个联系人。 Pre使用查询从Fackbook（Google、Exchange）上下载你的好友的电话号码、生日和其他的信息，然后将这些信息登记为同一个用户的条目。如果联系人有图片的话，也会通过这种方式下载并且存储到联系人卡片上。 链接、查询和webOS地址本 Pre的地址本让我们从各种云服务中获取联系人信息，这是个非常不错的方法，但这种方法也有其缺陷。特别需要说明的是，webOS在地址本处理的问题上，文笔并不在于“查询”模式，而是在于“收集”方面。重要的是，以下我所指出的问题是Palm选择的这种模式下不可避免的问题，也就是说，Palm选择的这种模式面临着一定的挑战。 首先，我们先来谈一下webOS的“链接”的概念，为了讲清楚这个概念，我们还是来举一个例子。下图是我的联系人的一个截图，联系人是我的好友Taylor Guillory，在Facebook上名为Mr. Britches。 我通过邮件、即时通讯和Facebook和Taylor进行联系，Pre将以上三个帐号的所有资料都已经收集到了上面的一个条目上。然而，在Facebook上，Taylor并没有使用他的真名，在其资料中显示的名字为“Mr. Britches”。更头疼的是，他在Google和Facebook上的电子邮件地址也是不一样的。然而，不知道为什么，Pre在收集了Google和Facebook的信息之后，Pre认为这两个资料属于同一个人的资料，将之链接到同一个人的条目中。 如果在我的450个联系人中有其他的电子邮件地址也是属于Taylor，我就可以通过点击“Link more profiles”按钮，找到新的地址，然后手动将之添加到Taylor的档案中。 现在，在上面的案例中，存在两个问题：一个是自动链接的问题，另一个则是手动链接的问题。 档案链接问题 首先，关于自动创建链接的问题，我不太确定Pre是如何做到的，我也不清楚我的第一部Pre（已经坏掉了）为什么没有对Taylor做自动链接。在我的第一部Pre上，Taylor和Mr. Britches是两个单独的条目，没有链接到一起。 更神奇的是，webOS错误的将我的资料和另一个随机的朋友链接到了一起，尽管我们之间没有任何相同的联系信息。我于是将我的Google帐号从手机上删除，然后对我的Google联系人进行了整理，再将Google帐号绑定到Pre上，这一次，Pre没有将我们链接在一起。 所以，自动创建链接的问题就是：它不是100%准确的，而其链接的算法对终端用户来说是不可知或者不可控的。所以，当我在我的联系人信息中查找我的朋友Alan，并为之增加邮件地址和号码的时候，我完全不知道Pre将会如何处理。不过我对我自己如何想倒是清楚的，那就是“欢迎来到收集-查询的世界，在这里你可以查询信息，但我们不能保证信息的准确性。” 现在是手动链接档案的问题，那就是：由于Palm Profiles并不备份这些链接，这些手动链接的信息无法保存和导出。所以，如果我花费了很多时间在Pre上建立了各种档案的链接的时候，如果我的Pre坏掉了（就像我的第一部那样），我将丢失这些手动链接。 Palm有可能会计划备份这些链接以便于可以跨设备使用，但由于Pre的联系人概念是一个纯粹的基于服务的联系人列表，所以，这样做看起来并不容易。 不备份搜索结果而仅仅备份结果之间的链接是不可能的，所以，Palm Profiles如果想要备份链接的话，就必须要同时备份联系人。如果Palm确实要这么做的话，那么它一定要非常小心，以免陷入非法存储第三方服务的联系人信息的危机之中。 总而言之，Palm致力于基于服务的联合搜索以降低用户搜索次数，但其webOS的档案链接确实一个漏洞。Palm一方面将搜索到的联系人的关联关系以结构化的形式存储到Pre的缓存中；但另一方面，保存的却仅仅是一小部分，且仅一次。所以链接这种方式是基于非结构化数据查询的一种妥协的做法。 地址本的“最终幻想” 以上是关于地址本的抽象描述，那么，具体操作起来Palm Pre的方便性如何呢？这么说吧，我晚上花了45分钟的时间整理我的Google联系人，不停的对联系人进行删减和合并的工作，以便尽量少的使Palm Pre出现错误的识别——尽管这样，我还有很多Gmail的旧的邮件地址没有清理。 尽管如此，我还是比较喜欢Palm Pre在联系人管理方面的这一尝试，从大量的整理好的联系人数据库中搜索，总比浏览一个只有少量联系人的地址本要好，而且Facebook、Google联系人和Exchange这样的服务或许总有一天会意识到这种联合使用的模式，并且为这种应用模式找到一种清晰的解决方案。 消息、提醒和一元化 webOS其中一个最大的优点就是它的提醒系统，我在本文的第一部分中已经做了介绍，并且类比于移动版本的OSX的应用——Growl。和Growl一样，Palm Pre的提醒系统在不打扰你工作的时候提醒你到来的消息和警报；也和Growl类似，有时候你也会希望它住嘴然后滚蛋。 webOS的Synergy（联合）功能可以收集信息并且将之展现给用户，这造成一个结果就是一定程序的消息过剩，这在Palm Pre上是经常出现的。现在，在我的提醒中，有一个垃圾信息、一个来自于未知号码（可能是某个公关人员）的语音邮件、以及一个来自于Ars总编辑Eric Bangeman的即时消息。其中只有一个提醒是有用的，但我必须要看完/听完所有的消息之后提醒才会消失。事实上，webOS预先假设你已经在服务端设置了一定的过滤信息，否则的话，你就不得不查看每一条信息，包括像植物伟哥之类的垃圾邮件。 webOS需要一个方法取消你不想看到的提醒信息（我刚刚获知你可以用手指将提醒信息滑出屏幕消除它，所以这个问题已经解决了），它还需要对提醒按照类型进行轻重缓急的分级。例如，我确实不使用语音邮件，所以我希望自己可以设置哪些提醒是最重要的。一言概之，对于Palm Pre通过Synergy（ifanr译为协合）获取的信息，应该给用户一个控制的权利。我会在“takes away”这一环节进行详细的描述。 在使用Pre体验各种提醒，包括报警、日程、语音邮件、即时通讯、电子邮件、Twitter更新等的时候，我开始意识到不知不觉中，我更喜欢按照应用/服务的类型来对消息和联系人管理进行分类。比如说，如果我想看某个人在Facebook上说了什么的话，我更喜欢在我的iPhone浏览器上登录Facebook；如果想看Twitter的话，我则会启动Twitter的客户端，诸如此类。 事实上，在Windows、Mac、iPhone、Android等多数平台上，云通讯被应用和/或URL分成了不同的数据竖井。所以，纵然在Twitter、即时通讯和Fackbook状态更新上的是同一个人，但他的这三种消息类型也代表了他在这三个不同网络上的不同档案。 在iPhone上，提醒信息会在不同的应用程序上以圆形、红色的图标予以标记，所以你不会将所有的提醒混杂在一起。你可以看一下iPhone的屏幕哪一个应用程序有更新或者消息，然后手工选择应用程序查看信息。所以即使在3.0上提供了推送信息（push）的功能，你仍然需要拉出（poll）应用程序以查看更新。如果你有很多低优先级的消息的话，就会发现这种“拉出程序”真的是太好了。 Palm应该更好地考虑一下如何改进提醒系统，因为如果Facebook、FriendFeed以及其他的云消息和社交网络应用程序全部都在Pre屏幕上一起提醒的话，那将会是一团糟。 解决这个问题的方案就是让用户通过过滤和分级工具来控制提醒系统，不过Palm最终如何做还有待观察。

转载于:https://www.cnblogs.com/scope/archive/2009/07/27/1532536.html