最近在写UI部分的API文档。在写的过程中，发现产品在技术实现上的许多不足和缺陷，重新思考了一些功能的实现技术以及可行性，并和底层的工程师做了探讨。有一些方法和技术，不但可以提高产品的质量，提高开发效率，更可能极大的改善产品的体验。虽然想法是好的，也确实可以尝试或者应该那样去实现，但受限于技术水平，公司目前没有这样的技术能力去实现。其实，我主要想到的是PHP和Flash技术。这是两样再常见不过的技术了，但公司目前没有人掌握。我想，这基本上会成为我后面这段时间要去学习的东西。
抛开公司的一些具体情况不谈，做交互设计，在技术领域应该掌握哪些东西，掌握到什么程度，我有一些思考。
交互设计，我的一个初略的理解，就是把实现模型转变为心智模型。既然交互设计是实现模型和心智模型的纽带和桥梁，那技术能力应该成为交互设计师的一个必备能力和基本素质。
Cooper在给同行的话中也说到：“交互设计师通常不是来自各级程序员，尽管如此，他们也是精通技术的人。非技术人员无法想象计算机能为我们做的美好新事物。非技术人员无法理解CPU的时间与用户下次击键之前计算机迅速地完成千万次指令的精细平衡。”
看一看微软亚洲研究院交互设计中心对原型工程师的招聘要求，有这么一条：“Proven record of developing SW applications for Windows. Must master C++ (or Java), Python, and web development languages. Will be great to have strong programming experiences on Macromedia Flash and Director.”
Cooper也说到：“（交互）设计师很少编程，除非你可以完全控制你的项目，否则你同时设计和开发将对不起你的用户，这存在利益冲突。”
我理解这个利益冲突，因为这两年我就一直处在这样的冲突中。我想有好的设计，我同时想有好的技术实现。我曾经为走设计的路还是走程序的路而思考辗转过很长时间。当时一个让我不能放弃程序的理由就是，担心两年的程序经验浪费了。当时不理解设计，不理解交互设计，所以当时有那么一条理由。现在看来，没有浪费，很有用，而且还不够用。
那么对技术的精通哪里来？我认为还是从实际开发中来。在设计的时候，你不需要考虑某个功能的代码具体怎么写，但你知道应该怎么去实现，我想，掌握到这个程度应该就够了。所以不经历实际的开发过程，不经过亲手敲出自己思考的代码的过程，怎么实现那个功能就不会思考那么清楚，精通就远谈不上。
那是不是交互设计师都是从事过开发工作的人？这个我不清楚。我认为对技术的掌握，是做交互设计的必要条件。如果有一个设计团队，那团队里需要精通技术的人。如果没有团队，只有你一个人，那你就必须掌握技术。
很多小公司都有这样的人，要做设计要做开发，一定都有和我一样的困惑。公司不懂设计，公司需要你这样一个多面手。在设计和开发之间，这个平衡很难把握，把握住的结果那也是你的设计一般般，你的程序也一般般，做的糟糕的话还很有挫败感。毕竟做全才很难。怎么办？振之曾经跟我建议过，这时候的重心不是在设计，程序实现最重要，更重要的是，让全体开发人员都有为用户着想的意识，把这个意识带到通常那种边设计边开发的过程中去。交互设计和用户体验不是一个人来抗，一个人也抗不好。看过白鸦一篇文章，是对公司是否应该成立设计团队的讨论，结论是对于一些小公司，不如没有设计团队。这里面有一些道理是相同的。
我有一些完美主义情结，所以我以前的做法是，把设计和开发分开，其实就是把我自己分开，做设计的时候就只管设计，做开发的时候就只管开发，以为这样就遵循了所谓正确的产品开发流程。但实际的结果和理想相差甚远，最后的结果就是产品很糟糕，设计糟糕，程序也糟糕。现在，我改变了一些做法。像振之建议的那样，要让开发人员具有为用户思考的意识。我会经常发一些博文给他们看，发一些成功的产品例子给他们看，然后在休息的时候引发大家来讨论，有时候甚至是争论和辩论。我也给头头讲一些我对产品开发和项目管理的分析，说出一些不合理和可以改进的地方，也给他看成功产品的设计，让他明白设计的重要性和设计的力量，然后头头就会在开会的时候又引发大家来讨论。这些小动作带来的影响是潜移默化的，也是有效的。整个开发团队，包括你自己，都会受益。而对于自己，要不断的学习和提高，不仅在设计上，也在技术上，因为你是连接用户和工程师的桥梁。
Cooper 说，“ 设计师不仅要成为用户服务的倡导者，还要成为组织内部革新的倡导者”。所以，有与我一样困惑的同志们，抛开那些困惑，思考一下怎样能把产品做好，怎样能做出一个成功的产品，让你的思考影响你周围的人，然后做你所能做的。这样，用来思考困惑的精力就转移到做产品上来，转移到自我学习和提升上来，这比困惑的心情要好的多，也许会找到久违的成就感。
PS：我不是什么专家型人物，上面的看法和建议是最近的个人感受。
Read more...
Apr 25, 2008
Apr 18, 2008
2008-04 UCDChina 南京书友会：排序
排序，是大家常见的功能，无论在文件系统中、在网络商城中、在数据表格中，按照类型排序，按照时间排序，按照价格排序，还有自由排序，等等。
排序，就是把一个集合中的对象，按照属性来进行划分，然后按照一定的顺序进行排列。表格，是大家最常见的加以排序功能的载体。如淘宝的商品列表，按照价格高低、卖家所在地、信用等级排序。Excel、财务管理等数据处理软件，按照数据大小排序。详细信息视图下的文件系统，按照文件大小、文件类型、修改时间排序。如果不是详细信息视图，而是平铺、缩略等视图，那也是以大小、时间、类型属性为标准来进行排序，只是这些属性在视图上是隐藏的。
那为什么要排序呢？大体来看有两个目的。第一点，很显然，排序就是比较，比较就是为了选出目标对象。第二点，就是把集合中的对象按照一定的有序方式输出，得要一个有序的结果。那要这个有序的结果干什么呢？也是给别人看的，也是为了让别人能方便快捷的寻找到有用的目标对象。这样看来，第二点和第一点的最终目标是一致的：用户的直接目标是寻找和选择自己想要的对象。排序是辅助用户达到这个目标的有效手段。很显然，电脑要比人工强大的多，所以集合中的对象越多，排序的作用就越大和越明显。
那怎么排序？或者说排序的标准是什么？当然，这里不会讨论程序和数据结构。前面说了，排序就是按照对象的属性来进行划分，那么属性就是排序的标准。一个集合中的对象，都有共同的属性。理论上来说，有多少属性，就有多少种排序方式。以文件系统为例，文件的属性有大小、类型、修改时间、创建时间等。再看mp3歌曲的属性，有艺术家、唱片标题、发行年、曲目号码、流派、歌词、来源、音频持续时间、位速、频道、音频采样级别等等。每一种属性都可以用来排序，那是不是太多了？是的，如果所有的属性都按照列表的方式排列开来，那太夸张了。所以，大部分属性是隐藏的，也不提供对这些属性的排序功能。一般只提供基本属性的排序，就如详细视图下的文件列表。
哪些是基本属性呢？这个就要看目标用户了，对目标用户有用的属性就是基本属性。以mp3来说，我们将用户划分为三类。第一类，只管听，不管这歌是谁唱的，什么时候出的专辑，不管是港台的、大陆的还是英伦的，好听就行。第二类，除了听，还有高一层次需求的，要听××歌手的，要听××年代的，要听××风格的。第三类，更有追求了，是玩音乐的，除了上面两类的要求，还要知道音频采样、频道、位速等等专业的东西。按照cooper对用户的划分，可以分为初、中、高级用户。中间用户永远是占大多数的，所以中间用户的需求，放到排序这里，他们所需求的属性，就是软件、网站、信息系统所提供的排序方式。看看文件系统，确实是那么几项。初级用户虽然暂时用不到按这些属性来排序，但初级用户会成长为中间用户，到时候会用到。而高级用户，那些玩音乐的，真实太少了。那也只有他们在玩音乐的时候才用到那些属性来排序，而当他们听音乐的时候，也就和中间用户，甚至初级用户一样。所以，按照目标用户，以中间用户的需求选择属性，来做为基本的排序方式，对于初级用户，提供基本视图，隐藏或简化排序功能，对于高级用户，提供高级视图，提供更全面的排序方式。
下面扩展一下对象的属性。除了那些固有属性，还有没有其他动态的属性、变化的属性？有，比如说频率。按照某个对象的使用频率、点击频率来作为排序的对象。在网上商城的一个典型例子就是按照关注程度来排序，按照商品的好评程度来排序，还有大家常见的Tag，也是按频率来排序的。这个机制和搜索引擎有些类似的地方，在网上商城很常见，那在文件系统中是否也引进一下呢？再扩展一下，不但属性是动态的，对象也是动态的。就比如歌曲排行，新歌在不断的加入，而歌曲的点击率也在不断变化，排行榜要实时显示。这个应该是技术上的问题了。
再扩展一下，属性的格式化和标准化。常见的排序属性，基本都是以关键字排序，也就是把属性字符化，然后对符号进行排序。是否可以避开这个过程，直接对属性进行比较呢？举个例子，本命年，要买红色的东西。我想看看有哪些红色的东西。怎样按颜色来排序？按颜色排序，那就要按颜色的标准码来。但标准码怎么来呢？卖家贴出商品的时候填上颜色码？不好弄。系统自动识别？有难度。所以，按颜色来排序，就不大好实现。如果所有的属性都以二进制流的方式来识别，那将来可排序的属性可能会更多。再来看标准化，比如按照尺寸排序，卖家张三填的是长×宽×高，而卖家李四填的是长×高×宽，那排序后用户做出的选择必然会有差错。属性没有标准，那错误就必然发生。所以对象属性的格式化和标准化是排序的重要方面。
在有了标准和格式的情况下，那排序的方式有哪些呢？手动？自动？自动排序，我们可以理解为默认排序，也就是以一个基本属性为标准，上面说的按照频率等来自动化的排序也是这样。这个很容易理解。手动，那就是用户自己选择一个属性作为标准。也很容易理解。扩展一下，用户不想以那些属性来排序，用户就要自己来排。这种排序比较常见的就是文件系统，用户可以把文件图标随意排放。还有就是blog里大家对友情链接的排序，对文章分类的排序。Wordpress里有专门的插件，可以通过拖拽来排序。Blogbus里用的是让用户输入数字来排序。这些都代表了自由排序。
再扩展一下，现在常见的排序都是一维的，也就是按照一个属性来排序，能否按照两个、三个甚至更多属性来同时排序呢？那就需要二维、三维和多维空间。举个二维的例子，按照物品的生产时间和重量这两个属性来排序，那就要画出一个二维坐标，X轴，Y轴，物品在这个二维的坐标中以点的方式来呈现。三维的也可以这样。当然维数越多，技术上越困难，并且也不利于用户做出选择了。
下面来看一看一些常见的产品，看看它们和排序的关系。
先来看手机通讯录。我的手机是S40系统。S40系统的通讯录排序，是按照姓名，按照数字和字母顺序来的。我常常遇到这样的情况，我要发同一条信息给几个人。第一个人，我可以通过查找调出他的名字。而第二个、第三个人，我查找不起来了，只能按顺序在通讯录里去一个一个往下按。而S60做的比较好，可以查找后选中checkbox，然后继续查找，再选中。那能否按照联系频率来给通讯录排序呢？S40中有一个“最近常用联系人”，但也只有15个，而且是常通话的联系人，不是常短信的联系人。对于按字母排序，能否按字母块再多一级上级排序呢？比如我要找G开头的一个人的名字，能否让我直接跳到G开头呢？而不是仍然要从A到G按顺序这么一个一个按下去。
再来看手机九宫格菜单。S40和S60都无法排序。每次进入S40的九宫格，都是默认选中的多媒体文件夹，如果我要发信息，那要按一下左，再按一下上，这就多了两次按键操作。按照我的想法，九宫格菜单应该和桌面电脑的图标一样，可以自由排序，或者按照使用频率排序，而不是固定格式。iPhone我没用过，我想应该可以。
来看看IM。QQ、MSN、GTalk、百度Hi，都是只有默认按照名字来排序，好像没有其他排序方式。QQ有个最近联系人，但不清楚它的排序方式是什么。如果你的IM里联系人很多，而你要找一个人，给他发个消息，而你又记不得他的IM号码，也记不得他的昵称，那就老老实实的去按顺序找吧。如果给IM软件加上自由排序，或者加上按照联系频率等排序方式，是否更好用呢？
看看网络相册，Flick和又拍，就有比较好的自由排序机制。而windows live spaces的相册，只能按照创建和上传的默认时间排列。
还有输入法。智能ABC，估计大家都不用了吧，其实一点都不智能。字是固定的排列，每次都要翻着找。Google输入法就智能了，按照使用频率自动往前排。
大家可以看看Silverlight的宣传片，从里面可以看出一些排序的应用。
总结一下，排序，三个要素：集合、对象、属性。然后在这三个属性中变幻吧。当然，前提是，要对用户有用。
Read more...
排序，就是把一个集合中的对象，按照属性来进行划分，然后按照一定的顺序进行排列。表格，是大家最常见的加以排序功能的载体。如淘宝的商品列表，按照价格高低、卖家所在地、信用等级排序。Excel、财务管理等数据处理软件，按照数据大小排序。详细信息视图下的文件系统，按照文件大小、文件类型、修改时间排序。如果不是详细信息视图，而是平铺、缩略等视图，那也是以大小、时间、类型属性为标准来进行排序，只是这些属性在视图上是隐藏的。
那为什么要排序呢？大体来看有两个目的。第一点，很显然，排序就是比较，比较就是为了选出目标对象。第二点，就是把集合中的对象按照一定的有序方式输出，得要一个有序的结果。那要这个有序的结果干什么呢？也是给别人看的，也是为了让别人能方便快捷的寻找到有用的目标对象。这样看来，第二点和第一点的最终目标是一致的：用户的直接目标是寻找和选择自己想要的对象。排序是辅助用户达到这个目标的有效手段。很显然，电脑要比人工强大的多，所以集合中的对象越多，排序的作用就越大和越明显。
那怎么排序？或者说排序的标准是什么？当然，这里不会讨论程序和数据结构。前面说了，排序就是按照对象的属性来进行划分，那么属性就是排序的标准。一个集合中的对象，都有共同的属性。理论上来说，有多少属性，就有多少种排序方式。以文件系统为例，文件的属性有大小、类型、修改时间、创建时间等。再看mp3歌曲的属性，有艺术家、唱片标题、发行年、曲目号码、流派、歌词、来源、音频持续时间、位速、频道、音频采样级别等等。每一种属性都可以用来排序，那是不是太多了？是的，如果所有的属性都按照列表的方式排列开来，那太夸张了。所以，大部分属性是隐藏的，也不提供对这些属性的排序功能。一般只提供基本属性的排序，就如详细视图下的文件列表。
哪些是基本属性呢？这个就要看目标用户了，对目标用户有用的属性就是基本属性。以mp3来说，我们将用户划分为三类。第一类，只管听，不管这歌是谁唱的，什么时候出的专辑，不管是港台的、大陆的还是英伦的，好听就行。第二类，除了听，还有高一层次需求的，要听××歌手的，要听××年代的，要听××风格的。第三类，更有追求了，是玩音乐的，除了上面两类的要求，还要知道音频采样、频道、位速等等专业的东西。按照cooper对用户的划分，可以分为初、中、高级用户。中间用户永远是占大多数的，所以中间用户的需求，放到排序这里，他们所需求的属性，就是软件、网站、信息系统所提供的排序方式。看看文件系统，确实是那么几项。初级用户虽然暂时用不到按这些属性来排序，但初级用户会成长为中间用户，到时候会用到。而高级用户，那些玩音乐的，真实太少了。那也只有他们在玩音乐的时候才用到那些属性来排序，而当他们听音乐的时候，也就和中间用户，甚至初级用户一样。所以，按照目标用户，以中间用户的需求选择属性，来做为基本的排序方式，对于初级用户，提供基本视图，隐藏或简化排序功能，对于高级用户，提供高级视图，提供更全面的排序方式。
下面扩展一下对象的属性。除了那些固有属性，还有没有其他动态的属性、变化的属性？有，比如说频率。按照某个对象的使用频率、点击频率来作为排序的对象。在网上商城的一个典型例子就是按照关注程度来排序，按照商品的好评程度来排序，还有大家常见的Tag，也是按频率来排序的。这个机制和搜索引擎有些类似的地方，在网上商城很常见，那在文件系统中是否也引进一下呢？再扩展一下，不但属性是动态的，对象也是动态的。就比如歌曲排行，新歌在不断的加入，而歌曲的点击率也在不断变化，排行榜要实时显示。这个应该是技术上的问题了。
再扩展一下，属性的格式化和标准化。常见的排序属性，基本都是以关键字排序，也就是把属性字符化，然后对符号进行排序。是否可以避开这个过程，直接对属性进行比较呢？举个例子，本命年，要买红色的东西。我想看看有哪些红色的东西。怎样按颜色来排序？按颜色排序，那就要按颜色的标准码来。但标准码怎么来呢？卖家贴出商品的时候填上颜色码？不好弄。系统自动识别？有难度。所以，按颜色来排序，就不大好实现。如果所有的属性都以二进制流的方式来识别，那将来可排序的属性可能会更多。再来看标准化，比如按照尺寸排序，卖家张三填的是长×宽×高，而卖家李四填的是长×高×宽，那排序后用户做出的选择必然会有差错。属性没有标准，那错误就必然发生。所以对象属性的格式化和标准化是排序的重要方面。
在有了标准和格式的情况下，那排序的方式有哪些呢？手动？自动？自动排序，我们可以理解为默认排序，也就是以一个基本属性为标准，上面说的按照频率等来自动化的排序也是这样。这个很容易理解。手动，那就是用户自己选择一个属性作为标准。也很容易理解。扩展一下，用户不想以那些属性来排序，用户就要自己来排。这种排序比较常见的就是文件系统，用户可以把文件图标随意排放。还有就是blog里大家对友情链接的排序，对文章分类的排序。Wordpress里有专门的插件，可以通过拖拽来排序。Blogbus里用的是让用户输入数字来排序。这些都代表了自由排序。
再扩展一下，现在常见的排序都是一维的，也就是按照一个属性来排序，能否按照两个、三个甚至更多属性来同时排序呢？那就需要二维、三维和多维空间。举个二维的例子，按照物品的生产时间和重量这两个属性来排序，那就要画出一个二维坐标，X轴，Y轴，物品在这个二维的坐标中以点的方式来呈现。三维的也可以这样。当然维数越多，技术上越困难，并且也不利于用户做出选择了。
下面来看一看一些常见的产品，看看它们和排序的关系。
先来看手机通讯录。我的手机是S40系统。S40系统的通讯录排序，是按照姓名，按照数字和字母顺序来的。我常常遇到这样的情况，我要发同一条信息给几个人。第一个人，我可以通过查找调出他的名字。而第二个、第三个人，我查找不起来了，只能按顺序在通讯录里去一个一个往下按。而S60做的比较好，可以查找后选中checkbox，然后继续查找，再选中。那能否按照联系频率来给通讯录排序呢？S40中有一个“最近常用联系人”，但也只有15个，而且是常通话的联系人，不是常短信的联系人。对于按字母排序，能否按字母块再多一级上级排序呢？比如我要找G开头的一个人的名字，能否让我直接跳到G开头呢？而不是仍然要从A到G按顺序这么一个一个按下去。
再来看手机九宫格菜单。S40和S60都无法排序。每次进入S40的九宫格，都是默认选中的多媒体文件夹，如果我要发信息，那要按一下左，再按一下上，这就多了两次按键操作。按照我的想法，九宫格菜单应该和桌面电脑的图标一样，可以自由排序，或者按照使用频率排序，而不是固定格式。iPhone我没用过，我想应该可以。
来看看IM。QQ、MSN、GTalk、百度Hi，都是只有默认按照名字来排序，好像没有其他排序方式。QQ有个最近联系人，但不清楚它的排序方式是什么。如果你的IM里联系人很多，而你要找一个人，给他发个消息，而你又记不得他的IM号码，也记不得他的昵称，那就老老实实的去按顺序找吧。如果给IM软件加上自由排序，或者加上按照联系频率等排序方式，是否更好用呢？
看看网络相册，Flick和又拍，就有比较好的自由排序机制。而windows live spaces的相册，只能按照创建和上传的默认时间排列。
还有输入法。智能ABC，估计大家都不用了吧，其实一点都不智能。字是固定的排列，每次都要翻着找。Google输入法就智能了，按照使用频率自动往前排。
大家可以看看Silverlight的宣传片，从里面可以看出一些排序的应用。
总结一下，排序，三个要素：集合、对象、属性。然后在这三个属性中变幻吧。当然，前提是，要对用户有用。
Read more...
Apr 17, 2008
[转]RIA技术概览
《程序员》杂志05年第二期原文，个人网站转载请注明作者（王林/Azure）和出处（中国RIA开发者www.riacn.com）并且保留这段版权说明，商业网站转载需要得到CSDN的许可。
互联网已经日益成为应用程序开发的默认平台，传统的Web应用程序（Web Application）是基于HTML页面、服务器端数据传递的模式。而HTML是适合于文本的，随着Web应用程序复杂性越来越高，传统的Web应用程序已经渐渐不能满足Web浏览者更高的、全方位的体验要求了，这就是被Macromedia公司称之为的"体验问题"（"Experience Matters"）。此时一种被称为Rich Internet Application（简称RIA，中文翻译作"丰富互联网应用程序"）的具高度互动性和丰富用户体验的网络应用程序出现了。Macromedia公司也借此机会开发了相关的技术和开发工具，促进RIA的开发和普及。
1. RIA的产生背景
企业级应用程序经历了几次系统架构方面的重要转变，在此过程中，客户端的表现能力有起有落。图1显示了Rich Internet Application的发展过程：
图1.Rich Internet Application的发展（摘自Macromedia Flex：创建企业Rich Internet
Application 的表示层解决方案）
RIA 是集桌面应用程序的最佳用户界面功能与Web应用程序的普遍采用和快速、低成本布署以及互动多媒体通信的实时快捷于一体的新一代网络应用程序。RIA中的 Rich Client（丰富客户端）提供可承载已编译客户端应用程序（以文件形式，用HTTP传递）的运行环境，客户端应用程序使用异步客户/服务器架构连接现有的后端应用服务器，这是一种安全、可升级、具有良好适应性的新的面向服务模型，这种模型由采用的Web服务所驱动。结合了声音、视频和实时对话的综合通信技术使RIA具有前所未有的网上用户体验。
下图就是RIA的应用程序模型：
图2.RIA的应用程序模型
3. RIA的优势
RIA 具有的桌面应用程序的特点包括：在消息确认和格式编排方面提供互动用户界面；在无刷新页面之下提供快捷的界面响应时间；提供通用的用户界面特性如拖放式（drag and drop）以及在线和离线操作能力。RIA具有的Web应用程序的特点包括如：立即布署、跨平台、采用逐步下载来检索内容和数据以及可以充分利用被广泛采纳的互联网标准。RIA具有通信的特点则包括实时互动的声音和图像。
客户机在RIA中的作用不仅是展示页面，它可以在幕后与用户请求异步地进行计算、传送和检索数据、显示集成的用户界面和综合使用声音和图像，这一切都可以在不依靠客户机连接的服务器或后端的情况下进行。
对于企业来说，部署RIA的好处在于：
1）RIA可以继续使用现有的应用程序模型（包括J2EE和.NET），因而无需大规模替换现有的Web应用程序。通过Rich Client技术，可以轻松构建更为直观、易于使用、反应更迅速并且可以脱机使用的应用程序。
2）RIA可以帮助企业提供多元化的重要业务效益，包括产提高销量、提高品牌忠诚度、延长网站逗留时间、较频繁的重复访问、减少带宽成本、减少支持求助以及增强客户关系等。
4. RIA目前的发展态势
在过去的两到三年中，Web开发人员一直是想构建一种比传统HTML更丰富的客户端：这是一个用户接口，它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA技术的出现允许我们在因特网上以一种像使用Web一样简单的方式来部署富客户端程序。无论将来RIA是否能够如人们所猜测的那样完全代替HTML应用系统，对于那些采用C/S架构的胖客户端技术运行复杂应用系统的机构和采用基于B/S架构的瘦客户端技术部署Web应用系统地机构来说，RIA确实提供了一种廉价的选择。下面介绍一下目前出现的几种比较有实力或者有特点的RIA客户端开发技术：
1） Macromedia Flash/Flex
Flash 从6.0开始Flash就逐步具备建立窗体风格的应用程序的功能。据Macromedia称已经有98％以上的桌面系统的浏览器都安装了 Macromedia Flash Player。这使得以Macromedia Flash Player为客户端的RIA可以支持种类广泛的平台和设备。
Flex是为满足希望开发 RIA的企业级程序员的需求而推出的表示服务器和应用程序框架，它可以运行于J2EE和.NET平台。Flex表示服务器提供基于标准的、声明性的编程方法和流程，并提供运行时服务，用于开发和部署丰富客户端应用程序的表示层。Flex开发者使用直观的基于XML的MXML来定义丰富的用户界面。该语言由 Flex服务器翻译成SWF格式的客户端应用程序，在Flash Player中运行。
2） Laszlo
Laszlo 是一个开源的RIA开发环境。使用Laszlo平台时，开发者只需编写名为LZX的描述语言（其中整合了XML和Javascript），运行在J2EE 应用服务器上的Laszlo平台会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说，Laszlo的本质和Flex是一样的。Flash是任何浏览器都支持的展示形式，从而一举解决了浏览器之间的移植问题。而且，在未来的计划中，Laszlo还可以将LZX编译成Java或.NET本地代码，从而大大提高运行效率。
3） Avalon
Microsoft的Avalon是下一版本的 Windows（代号"Longhorn"）的一部分，是一个图形和展示引擎，主要由新加到.NET框架中的一组类集合而成。Avalon定义了一个在 Longhorn中使用的新标记语言，其代号为"XAML"（可扩展应用程序标记语言）。可以使用XAML来定义文本、图像和控件的布局，程序代码可以直接嵌入到XAML中，也可以将它保留在一个单独的文件内。这与Flex中的MXML或者Laszlo中的LZX非常相似。不同的是：基于 Avalon的应用程序必须运行在Longhorn环境中，而Flex和Laszlo是不依赖于平台的，仅仅需要装有Flash播放器的浏览器即可。
4） Java SWT
Java 已经出现几年了，并且完全支持创建基于窗体的用户界面。除了Java基础类（JFC/Swing）中的用户界面组件之外，开发人员还可以使用来自于 Eclipse Project的SWT工具箱和许多第三方工具箱进行开发。对于图形来说，可以采用Java 2D API：一个非常完整且非常复杂的图形API。你可以通过一个Web浏览器使用Java插件软件，或使用Java运行时环境中较新的Java Web Start技术来部署应用程序。使用Java建立Rich Client的主要缺陷是它的复杂性（即使对简单的窗体和图形也要求编写非常烦琐的代码）和Java浏览器插件的低市场占有率。
5） XUL
XUL （念作"zool"）是一种基于XML的用户界面语言，它来自于Mozilla的开放源码项目。它可用于建立窗体应用程序，这些应用程序不但可以在 Mozilla浏览器上运行，而且也可以运行在其他描述引擎上，如Zulu（一个Flash MX组件）和Thinleys（一个Java实现）。XUL描述引擎都非常小（100K以下），它可以使用XML数据也可以生成XML数据。XUL的一个主要缺点在于它目前还没有获得一个主要商业实体的支持。XUL最大的优点在于它与Gecko引擎的集成（打开了通向大量Web标准的大门），以及与大多数其它XML用户界面描述语言相比它是一种非常具有表达力和简洁的语言。
6） Bindows
Bindow 是用Javascript和DHTML开发的Web窗体框架。Javascript用于客户端界面的显示和处理，XMLHTTP用于客户端与服务器的信息传输。Javascript在客户端的表现力不容置疑，利用Javascript几乎可以实现Windows应用程序所能干的大部分事情，XMLHTTP 一直以来常被用于实现"无刷新"的Web页面，它和 Javascript配合，可以完成数据从服务器和客户端的传输。Bindows的一个主要的缺点是它采用一次全部载入的方式来实现脚本库，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。这点Bindows根本没有遵循"用多少去多少"的准则。另外，内部大量利用了IE6 的技术，没有考虑到非IE的浏览器，限制了Bindows的流行。
5. RIA未来的发展预测
就目前RIA的使用情况来说，离"RIA时代"还有很远的一段距离。今后几年时间内传统的Web应用程序和RIA将会共存。笔者认为真正具有实力担当起普及丰富客户端应用重任的只有基于Flash Player的Flash/Flex应用程序和Microsoft的基于Avalon的应用程序。短期时间内（估计2-3年时间）可能是 Flash/Flex应用程序在新兴的网络应用程序市场上占有主导地位。随着时间的推移，Flash/Flex应用程序的市场占有率可能会慢慢被基于 Avalon的应用程序所蚕食。当然，Flash Player和Flex以后也会不断推出新版本，相对于升级操作系统或安装Avalon运行环境，人们肯定更愿意升级Flash Player。Flash/Flex应用程序也有其本身固有的软肋，Flash Player的执行效率和对本地资源的操作限制是无法和Avalon相比的，相对于浏览器中的插件而言，Avalon的应用程序拥有更加广阔的可操作空间和更高的执行效率。
目前Microsoft还在推广一种叫做Smart Client（智能客户端）的客户端程序技术，Microsoft称Smart Client是比Rich Client更优秀的客户端，因而采用Smart Client的应用程序算不算RIA目前我个人还无法作答。这里我们之所以提及Smart Client，是因为Smart Client的特性跟我们谈的Rich Client有太多的相似之处。Smart Client拥有自动更新、离线状态下的数据处理和可以使用本地资源等特征，其中的可使用本地资源这一项无疑是一大卖点，因为浏览器中的 Flash/Flex应用程序目前还无法操作本地的一些资源，比如Flash/Flex应用程序无法将网上的文件保存到本地或者修改本地文件。虽然 Macromedia的Central1.5已经可以对本地文件进行简单的操作，并且flex1.5开发的RIA也能够运行于Central上，但是如何使Central能够得到大范围推广还是个问题。相对于轻量级的Rich Client，Smart Client更接近C/S架构中的客户端程序。Rich Client和Smart Client的定位还是有所区别的：Rich Client更适合作为轻量级的基于浏览器的网络应用程序客户端；Smart Client更适合作为Windows桌面应用程序的智能客户端。
不管我们今天称之为的RIA今后会不会成为主流应用程序，人们对开发具有高度互动性、丰富用户体验以及功能强大的客户端的追求是不变的。有理由相信，拥有成熟技术和极高市场占有率的Flash客户端将会在RIA道路上越走越远。Microsoft未来的重量级武器：Avalon和Smart Client能否后来者居上让我们拭目以待。
Read more...
RIA技术概览
互联网已经日益成为应用程序开发的默认平台，传统的Web应用程序（Web Application）是基于HTML页面、服务器端数据传递的模式。而HTML是适合于文本的，随着Web应用程序复杂性越来越高，传统的Web应用程序已经渐渐不能满足Web浏览者更高的、全方位的体验要求了，这就是被Macromedia公司称之为的"体验问题"（"Experience Matters"）。此时一种被称为Rich Internet Application（简称RIA，中文翻译作"丰富互联网应用程序"）的具高度互动性和丰富用户体验的网络应用程序出现了。Macromedia公司也借此机会开发了相关的技术和开发工具，促进RIA的开发和普及。
1. RIA的产生背景
企业级应用程序经历了几次系统架构方面的重要转变，在此过程中，客户端的表现能力有起有落。图1显示了Rich Internet Application的发展过程：
图1.Rich Internet Application的发展（摘自Macromedia Flex：创建企业Rich Internet
Application 的表示层解决方案）
- 基于主机的应用程序：应用程序提供基于文本的非图形化用户界面，只有内部人员才能进行访问。
- 客户机/服务器（Client/Server，简称C/S）应用程序：二十世纪九十年代随着Windows的出现和客户端处理能力的增强，出现了客户机/服务器应用程序，它们采用图形用户界面，客户端的数据处理能力比较强。但由于客户端应用程序需要进行不断的更新，因此部署成本比较高，只能为少数人所使用。
- 浏览器/服务器（Browser/Server，简称B/S）应用程序：九十年代中期，互联网飞速发展，出现了浏览器/服务器应用程序，Web的广泛使用解决了C/S应用程序部署、和更新的困难。但由于采用了HTML页面形式的用户界面，客户端的数据处理能力较C/S应用程序有所回落。
C/S架构的缺点主要是部署、更新的问题。B/S架构的缺点主要是受制于HTML的限制，无法像C/S那样使用丰富的效果来展示数据，用户体验比较糟糕。另外，稳定的客户端/服务器连接，也是必要条件，网络中断将使B/S程序无法运行。从C/S到B/S，这两者受限于技术本身分别发展成了重客户端和重服务器端的模式，而RIA的出现给我们带来重新在客户端和服务器端进行更好的平衡的机会。
2. 什么是RIA
2. 什么是RIA
RIA 是集桌面应用程序的最佳用户界面功能与Web应用程序的普遍采用和快速、低成本布署以及互动多媒体通信的实时快捷于一体的新一代网络应用程序。RIA中的 Rich Client（丰富客户端）提供可承载已编译客户端应用程序（以文件形式，用HTTP传递）的运行环境，客户端应用程序使用异步客户/服务器架构连接现有的后端应用服务器，这是一种安全、可升级、具有良好适应性的新的面向服务模型，这种模型由采用的Web服务所驱动。结合了声音、视频和实时对话的综合通信技术使RIA具有前所未有的网上用户体验。
下图就是RIA的应用程序模型：
图2.RIA的应用程序模型
3. RIA的优势
RIA 具有的桌面应用程序的特点包括：在消息确认和格式编排方面提供互动用户界面；在无刷新页面之下提供快捷的界面响应时间；提供通用的用户界面特性如拖放式（drag and drop）以及在线和离线操作能力。RIA具有的Web应用程序的特点包括如：立即布署、跨平台、采用逐步下载来检索内容和数据以及可以充分利用被广泛采纳的互联网标准。RIA具有通信的特点则包括实时互动的声音和图像。
客户机在RIA中的作用不仅是展示页面，它可以在幕后与用户请求异步地进行计算、传送和检索数据、显示集成的用户界面和综合使用声音和图像，这一切都可以在不依靠客户机连接的服务器或后端的情况下进行。
对于企业来说，部署RIA的好处在于：
1）RIA可以继续使用现有的应用程序模型（包括J2EE和.NET），因而无需大规模替换现有的Web应用程序。通过Rich Client技术，可以轻松构建更为直观、易于使用、反应更迅速并且可以脱机使用的应用程序。
2）RIA可以帮助企业提供多元化的重要业务效益，包括产提高销量、提高品牌忠诚度、延长网站逗留时间、较频繁的重复访问、减少带宽成本、减少支持求助以及增强客户关系等。
4. RIA目前的发展态势
在过去的两到三年中，Web开发人员一直是想构建一种比传统HTML更丰富的客户端：这是一个用户接口，它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA技术的出现允许我们在因特网上以一种像使用Web一样简单的方式来部署富客户端程序。无论将来RIA是否能够如人们所猜测的那样完全代替HTML应用系统，对于那些采用C/S架构的胖客户端技术运行复杂应用系统的机构和采用基于B/S架构的瘦客户端技术部署Web应用系统地机构来说，RIA确实提供了一种廉价的选择。下面介绍一下目前出现的几种比较有实力或者有特点的RIA客户端开发技术：
1） Macromedia Flash/Flex
Flash 从6.0开始Flash就逐步具备建立窗体风格的应用程序的功能。据Macromedia称已经有98％以上的桌面系统的浏览器都安装了 Macromedia Flash Player。这使得以Macromedia Flash Player为客户端的RIA可以支持种类广泛的平台和设备。
Flex是为满足希望开发 RIA的企业级程序员的需求而推出的表示服务器和应用程序框架，它可以运行于J2EE和.NET平台。Flex表示服务器提供基于标准的、声明性的编程方法和流程，并提供运行时服务，用于开发和部署丰富客户端应用程序的表示层。Flex开发者使用直观的基于XML的MXML来定义丰富的用户界面。该语言由 Flex服务器翻译成SWF格式的客户端应用程序，在Flash Player中运行。
2） Laszlo
Laszlo 是一个开源的RIA开发环境。使用Laszlo平台时，开发者只需编写名为LZX的描述语言（其中整合了XML和Javascript），运行在J2EE 应用服务器上的Laszlo平台会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说，Laszlo的本质和Flex是一样的。Flash是任何浏览器都支持的展示形式，从而一举解决了浏览器之间的移植问题。而且，在未来的计划中，Laszlo还可以将LZX编译成Java或.NET本地代码，从而大大提高运行效率。
3） Avalon
Microsoft的Avalon是下一版本的 Windows（代号"Longhorn"）的一部分，是一个图形和展示引擎，主要由新加到.NET框架中的一组类集合而成。Avalon定义了一个在 Longhorn中使用的新标记语言，其代号为"XAML"（可扩展应用程序标记语言）。可以使用XAML来定义文本、图像和控件的布局，程序代码可以直接嵌入到XAML中，也可以将它保留在一个单独的文件内。这与Flex中的MXML或者Laszlo中的LZX非常相似。不同的是：基于 Avalon的应用程序必须运行在Longhorn环境中，而Flex和Laszlo是不依赖于平台的，仅仅需要装有Flash播放器的浏览器即可。
4） Java SWT
Java 已经出现几年了，并且完全支持创建基于窗体的用户界面。除了Java基础类（JFC/Swing）中的用户界面组件之外，开发人员还可以使用来自于 Eclipse Project的SWT工具箱和许多第三方工具箱进行开发。对于图形来说，可以采用Java 2D API：一个非常完整且非常复杂的图形API。你可以通过一个Web浏览器使用Java插件软件，或使用Java运行时环境中较新的Java Web Start技术来部署应用程序。使用Java建立Rich Client的主要缺陷是它的复杂性（即使对简单的窗体和图形也要求编写非常烦琐的代码）和Java浏览器插件的低市场占有率。
5） XUL
XUL （念作"zool"）是一种基于XML的用户界面语言，它来自于Mozilla的开放源码项目。它可用于建立窗体应用程序，这些应用程序不但可以在 Mozilla浏览器上运行，而且也可以运行在其他描述引擎上，如Zulu（一个Flash MX组件）和Thinleys（一个Java实现）。XUL描述引擎都非常小（100K以下），它可以使用XML数据也可以生成XML数据。XUL的一个主要缺点在于它目前还没有获得一个主要商业实体的支持。XUL最大的优点在于它与Gecko引擎的集成（打开了通向大量Web标准的大门），以及与大多数其它XML用户界面描述语言相比它是一种非常具有表达力和简洁的语言。
6） Bindows
Bindow 是用Javascript和DHTML开发的Web窗体框架。Javascript用于客户端界面的显示和处理，XMLHTTP用于客户端与服务器的信息传输。Javascript在客户端的表现力不容置疑，利用Javascript几乎可以实现Windows应用程序所能干的大部分事情，XMLHTTP 一直以来常被用于实现"无刷新"的Web页面，它和 Javascript配合，可以完成数据从服务器和客户端的传输。Bindows的一个主要的缺点是它采用一次全部载入的方式来实现脚本库，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。这点Bindows根本没有遵循"用多少去多少"的准则。另外，内部大量利用了IE6 的技术，没有考虑到非IE的浏览器，限制了Bindows的流行。
5. RIA未来的发展预测
就目前RIA的使用情况来说，离"RIA时代"还有很远的一段距离。今后几年时间内传统的Web应用程序和RIA将会共存。笔者认为真正具有实力担当起普及丰富客户端应用重任的只有基于Flash Player的Flash/Flex应用程序和Microsoft的基于Avalon的应用程序。短期时间内（估计2-3年时间）可能是 Flash/Flex应用程序在新兴的网络应用程序市场上占有主导地位。随着时间的推移，Flash/Flex应用程序的市场占有率可能会慢慢被基于 Avalon的应用程序所蚕食。当然，Flash Player和Flex以后也会不断推出新版本，相对于升级操作系统或安装Avalon运行环境，人们肯定更愿意升级Flash Player。Flash/Flex应用程序也有其本身固有的软肋，Flash Player的执行效率和对本地资源的操作限制是无法和Avalon相比的，相对于浏览器中的插件而言，Avalon的应用程序拥有更加广阔的可操作空间和更高的执行效率。
目前Microsoft还在推广一种叫做Smart Client（智能客户端）的客户端程序技术，Microsoft称Smart Client是比Rich Client更优秀的客户端，因而采用Smart Client的应用程序算不算RIA目前我个人还无法作答。这里我们之所以提及Smart Client，是因为Smart Client的特性跟我们谈的Rich Client有太多的相似之处。Smart Client拥有自动更新、离线状态下的数据处理和可以使用本地资源等特征，其中的可使用本地资源这一项无疑是一大卖点，因为浏览器中的 Flash/Flex应用程序目前还无法操作本地的一些资源，比如Flash/Flex应用程序无法将网上的文件保存到本地或者修改本地文件。虽然 Macromedia的Central1.5已经可以对本地文件进行简单的操作，并且flex1.5开发的RIA也能够运行于Central上，但是如何使Central能够得到大范围推广还是个问题。相对于轻量级的Rich Client，Smart Client更接近C/S架构中的客户端程序。Rich Client和Smart Client的定位还是有所区别的：Rich Client更适合作为轻量级的基于浏览器的网络应用程序客户端；Smart Client更适合作为Windows桌面应用程序的智能客户端。
不管我们今天称之为的RIA今后会不会成为主流应用程序，人们对开发具有高度互动性、丰富用户体验以及功能强大的客户端的追求是不变的。有理由相信，拥有成熟技术和极高市场占有率的Flash客户端将会在RIA道路上越走越远。Microsoft未来的重量级武器：Avalon和Smart Client能否后来者居上让我们拭目以待。
Read more...
Subscribe to:
Posts (Atom)
