OpenSocial规范、实现现状与展望
OpenSocial为构建跨多个网站的社交应用程序提供了一组通用 API。开发人员可以使用标准 JavaScript 和 HTML 创建应用程序,用以访问社交网络里的朋友并更新对应的Feeds。本文是对本次QClub活动内容的一个简短总结,希望对没有到现场参会的读者了解OpenSocial有所帮助,也希望能引起大家更多的讨论。

作者 Dave Churchville译者 胡键 发布于 2007年5月14日 上午3时9分
复杂用户界面开发(本文用作UI开发),为敏捷开发提供了某些独特的挑战。与那些功能大部分是自动运行业务规则或计算薪水的项目不同,因为由用户培训或生产力缺失引起的各种问题,UI开发项目往往不能承受剧烈的变动,尤其是那些经常被使用的应用程序(如呼叫中心、E-mail阅读器或数据登记系统等)。
许多敏捷项目通过“下次迭代再修改”的方法防止做出错误的决定。它的思想是快速地失败,却仍然相对便宜。但是,UI开发项目的最终用户需要经常进行关于系统使用的充分培训,因此就用户体验来说,不能容忍巨大的改变。
用户体验方法,如交互式设计,鼓励更多的预先设计过程,用来研究和捕捉用户目标,试图在开发之前最优化软件工作流。这有点与敏捷方法相冲突——对于重要的(non-trivial)项目预先分析和设计往往需要花费几个月的时间,随着项目的开展,用户的目标可能会转变。
但是,面对限制用户界面改变的程度,以及早期迭代交付不合适用户界面的高风险,敏捷开发者打算做什么呢?
这个问题的解决办法需要快速地检查一下敏捷基础。很多敏捷开发的实践是朝减小风险和降低变更成本的方向去调整。在UI开发时,因为考虑到最终用户的再培训和生产率的降低,增量改变和部署的成本比我们期望的高。我们同样也会有初始交付错误用户界面的风险,但是这受限于我们可以在多大程度上改变它。
注意到这些,降低初始交付“离题”用户界面风险的方法,将会在正确的方向上给我们开个好头。如果我们一开始就得到正确的用户界面,那么在随后迭代中我们所做的改变,对用户几乎不会造成伤害,兼具更低的部署和培训成本。通过理解最重要和公共的用户目标,完成支持这些目标的初始界面并根据它有效地导航、适当地反馈、最小化偏差,我们将有获得正确设计的最佳机会。与更详细的需求不同,随着项目的进展,用户目标会倾向于更加稳定。
保持敏捷的精神,理想上来说,我们需要这个方法让我们可以快速地获得用户反馈,快速地迭代用户界面,指出在哪处我们可以放心。这样,我们的初始开发成果将交付用户所需的东西。
交互设计是通过研究软件目标用户的领域和环境,关注于创造最优用户体验的方法。传统方式,这是由预先研究和分析用户角色和目标完成的,通过辨识系统主要用户,他们需要什么,接下来考虑次要因素(如重复使用,对错误的敏感性等等)。
更敏捷的交互设计迭代自旋将会是:先对用户目标进行“刚刚足够”的研究,然后猜测软件将如何工作,最后用真实的用户去测试它。尽管不彻底,它允许快速地转变和在过程早期进行验证,而不是更长的预先分析。
简而言之,只要不阻止开发尽可能早的开始,为更好的理解用户目标而进行一些起码的预先设计还是有显著价值的。根据团队的组成和哲学,可以采用以下形式之一:
一种发现用户目标的快速技术是使用“角色”——即可能使用系统的真实人群的大体概要,他们的任务是什么,甚至他们的感情观。例如,就某个邮件系统来说,我们可能有一个这样的角色:
John是一位就职于某财富500强公司的忙碌执行官。他不十分擅长电脑,但使用电子邮件作为他的主要应用程序。John每天大约收到100封邮件,通常发送不到10封。他不喜欢使用软件,更愿意亲自给他的同事打电话。
一个完整的角色描述可能会更详细,但是它是为了使用而非为了给用户“定型”,角色是一个有某种目标的用户的特定实例,描绘这个你所期望的最终用户是有代表性的。根据系统类型,你可能需要几个角色代表不同种类的用户。
一旦你定义了角色,你就可以开始分析角色目标的种类。目标实际更接近于他们期望出现的产出,而不是他们要执行的任务。目标与任务比较的例子:
目标:我想与我的同事通宵达旦弄明白过去的谈话。
任务:我需要检查我的收件箱,通过联络查看过去的谈话。
最终,你需要提出明确的任务来帮助你的用户,以他的偏好和需要,达到他的目标。通过由目标开始,你可以将它们作为参考,考虑不同的技术可行性。仅仅因为今天用户执行某种任务,并不意味着那些是达到他们目标最简单或最有效的方式。
关于角色的更详细说明,可以参考Alan Cooper和Robert Reimann 的著作About Face 2.0 - 交互设计精髓。
有一本整本专门讨论这个主题的书籍——纸上原型法,作者是Carol Snyder,它是这项技术及其权衡利弊的优秀参考书籍。
纸上原型的主要优点:

尽管纸上原型法的好处是可被用于快速反馈,但有时它不太实用。如,如果你有远程客户,纸上原型会话即使不是不可能,那也会变得困难。
一种可替换的技术是使用HTML编辑器、表现层软件或专用工具,将数码照片、扫描纸张、白板画链接这些进入一个交互式的模型。这种方法仍然具有使用纸张建模的优点,但允许发送拷贝给远程用户,或使用电话会议或webinar交互式讨论它们。

另一个选择是为每个原型屏幕创建主干HTML页面,只有描述它们目的的文字,以及屏幕上需要动作的链接。Web设计者称这个方法是“接线框”。
作为最后一招,你还可以使用如VB或你喜爱开发语言的IDE创建一个原型。很多这样的产品都具有快速原型特性,创建对话框和屏幕而无需任何编程。当然,主要缺点是,这些原型看上去就像是“成品”或与目标应用程序技术非常接近。正因为看上去真实,最终用户可能倾向于讨论实现细节,而非工作流(比如“这个按钮难道不能是左对齐的吗?它看上去真的很难看”)。
就某些项目而言,你可能没法通过简单地作图来交流复杂的界面或组件。此时,创建一个“穿刺(spike)”实现会很有用。“穿刺(spike)”是功能的狭长切片,端到端的,类似将长钉敲入地面。
例如,如果你在构建新类型的日历组件或梦幻动画工具条,那么非常有必要花费几天创建一些与真实事物相近的事物,这样你可以示范精巧的行为以获得反馈。
通常,敏捷技术在后台系统和非琐碎用户界面时工作非常好。但是,还是有很多来自其它方法的有用技术可以带来显著的价值。尤其是,来自交互设计的技术,在为编码而投入时间之前,帮助设计和测试用户界面想法。当然也是在这些系统产品化之前,界面变化可能受培训和生产力因素制约:
结合用户体验设计技术与敏捷开发过程,可以创建强大的优势互补,这将产生被最终用户喜爱的更好软件,同时交付业已为人称道的敏捷商业价值。
查看英文原文:Agile User Interface Development译者简介:胡键,自2000年西安交通大学硕士毕业后一直从事软件开发。2002年开始使用Java,在项目开发中经常采用OpenSource工具,如Ant、Maven、Hibernate、Struts等,目前正在研究信息集成方面的规范和技术。可以通过jianhgreat AT hotmail.com与他联系,或访问博客:http://foxgem.javaeye.com/。与InfoQ中文站分享内容,请邮件至china-editorial@infoq.com。
OpenSocial为构建跨多个网站的社交应用程序提供了一组通用 API。开发人员可以使用标准 JavaScript 和 HTML 创建应用程序,用以访问社交网络里的朋友并更新对应的Feeds。本文是对本次QClub活动内容的一个简短总结,希望对没有到现场参会的读者了解OpenSocial有所帮助,也希望能引起大家更多的讨论。
Ruby 1.9的纤程(Fibers)和非阻塞I/O越来越收到关注了。我们对来自NeverBlock项目的Mohammad A. Ali和来自Revactor项目的Tone Arcieri进行了访谈。
InfoQ中文站有幸与Google中国的产品经理杨巍先生在一起探讨了OpenSocial的相关话题,包括OpenSocial的初衷、构成要素、实现方式、以及要实现它的技术储备等等。
Ryan Cooper对Amr Elssamadisy的新书发表了评价,并认为书中提供了一种为实施敏捷量身定做的框架。本书并没有给出一种人人可用的敏捷方法,而是为读者提供一些模式和工具,用以找出哪些敏捷实践可以最有效地达到该组织机构的特定目标。
这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。
本视频主要对OpenSocial进行了分析,并对实现的方式进行了介绍。其中包括:OpenSocial的开发经验、Container Provider的技术准备、平台的构成要素、具体的规范、以及对未来的展望。
Memcached在大型网站被应用得越来越广泛,但是Java客户端并不多,本文作者基于现有的开源客户端进行了封装优化,并翔实记录了这一过程。
在他们文章的第二部分,作者探讨了动态业务应用的架构并介绍了资源容器的概念。他们示范了如何在JEE之上构建这个架构,以及它如何影响实现生产力。
没有回复
回复