昨天又跑去新华书店。不是去买书，而是去思考后面的学习重点，或者发展方向。因为书店里书的种类很全，提供了几乎所有不同的领域方向，所以借助不同图书，可以为自己的计划提供参考。
不过昨天和以往不一样，我没看多长时间，就出了书店。原因，也许是以往看的时间够长了，有哪些书都知道了。其实，最主要的是想明白了几个问题，记录一下。
1、排除一切干扰，专心学一样东西，然后一个一个来。又想起一位朋友的那句话：“心静如水，别让任何事打乱你的步伐。让自己有大块的时间去完成一件事情，别让自己生活在零碎的时空里。” 如何做到专心，推荐大家看看这个：一心一意，每次只执行一件事。
2、优秀的架构需要优秀的代码，优秀的代码支撑优秀的架构。所以要先学会写优秀的代码，架构层的东西，自己要有意识，而减少一些研究。没有优秀代码的经验 做基础，架构的东西会大打折扣。所以，先从OOP开始，接着再来UML、设计模式。其实是由这一点想到上面一点的。
3、OOP、UML，不仅仅是技术，更是观察和分析问题的思维。就像绘画一样，画出一个逼真的东西，那只是表面，真正厉害的是对事物锐利的观察能力。所以，OOP、UML和绘画一样，原理是想通的，掌握这三样，会对人的思维分析能力很有帮助。
想明白了上面三个问题，觉得轻松了很多，前一段时间的烦恼和压力似乎都消失了。其实，道理还是那些道理，为什么时常走回头路呢？有些可笑。关键的，也许应该将那些道理培养成自己真正的习惯。态度决定一些，习惯改变命运嘛，呵呵。
推荐给大家一个很好的blog：褪墨，是一个关于时间管理，个人提升和演讲技巧的博客。目标是：做好每一件事。你会受益很多哦^_^
Read more...
Sep 10, 2008
Sep 9, 2008
你如何选择技术类图书？
当你想学一门编程语言，一种软件设计方法，一种设计思想的时候，如何选择合适的、通俗易懂的、能高效阅读的书呢？面对书架上玲琅满目的同类书籍，是否有些眼花，是否选书是比较耗时间的事情？今天谈一谈我选书的经历。
我个人选书的标准是：经典的>获奖的> 国外的>畅销的>国内的。这个标准其实很有问题，度量标准就不一样。事实上，通常经典的=获奖的=国外的=畅销的。这里没有鄙视国内作者的意 思，现实就是这样。国内也有些的很好的书，但相比老外的，实在是少的很。
有了大概的标准，怎么选书呢？豆瓣！豆瓣确实是个好东西。去搜吧，搜出一箩筐来。
首先看介绍。凡是有“经典”、“奖”、“畅销”字样的介绍，都要重点考虑。还有就是看版本，发行的版本越高，那就是越经典了。通过介绍，来了解这本书是否适合自己的水平，不要选个高深的来做入门教材，那效果可不好。
然后就是看读者评价。通常的评价是关于内容和翻译的。对于个别人关于翻译的评价，个人觉得不要太在意，每个人的阅读水平不同。当然，如果一致评价翻译的太差，那建议找原版的，只要你的E文够好。对于内容的评价也要重视，这是对图书介绍很好的补充，也许你就能从内容评价中找到自己想要的重点。这里有一点，所有网上书店也有评价系统，但那些评价里，托儿比较多，还是豆瓣实在。
接下来呢，找一张纸，抄下你要的书，去书店吧。实际看一看，内容是否真的符合自己的需要，翻译的水平如何。当然，如果你没时间，如果你对前面的了解很有把握，这一步可以省略。实际看书的时候，注意一下封底的推荐，老外的书都有一些大牛的推荐语录，国内现在也流行，看看那些大牛的推荐，也很有参考价值。
买书嘛，建议还是网上买，就图个便宜。就到豆瓣上去看吧，个人喜欢卓越。
以上是我个人的选书过程。下面介绍一下JOLT。JOLT大奖，号称软件业的奥斯卡，呵呵。以下摘字百度知道：
看到JOLT这个关键字，你得高度重视哦。 大家熟知的《About Face》和《CSS实战手册》，就是获奖书目。CSDN读书频道有相关专题。大家都属于IT人士，所以里面很多书是值得好好读的。个人感觉面向对象的分析与设计、UML，是应该好好学习的，除了可以帮助你开发出好的软件，更重要的是，这所提出的分析问题的思维方式，而不仅仅是为写软件。
你在选书方面有什么心得体会呢，欢迎交流^o^
Read more...
我个人选书的标准是：经典的>获奖的> 国外的>畅销的>国内的。这个标准其实很有问题，度量标准就不一样。事实上，通常经典的=获奖的=国外的=畅销的。这里没有鄙视国内作者的意 思，现实就是这样。国内也有些的很好的书，但相比老外的，实在是少的很。
有了大概的标准，怎么选书呢？豆瓣！豆瓣确实是个好东西。去搜吧，搜出一箩筐来。
首先看介绍。凡是有“经典”、“奖”、“畅销”字样的介绍，都要重点考虑。还有就是看版本，发行的版本越高，那就是越经典了。通过介绍，来了解这本书是否适合自己的水平，不要选个高深的来做入门教材，那效果可不好。
然后就是看读者评价。通常的评价是关于内容和翻译的。对于个别人关于翻译的评价，个人觉得不要太在意，每个人的阅读水平不同。当然，如果一致评价翻译的太差，那建议找原版的，只要你的E文够好。对于内容的评价也要重视，这是对图书介绍很好的补充，也许你就能从内容评价中找到自己想要的重点。这里有一点，所有网上书店也有评价系统，但那些评价里，托儿比较多，还是豆瓣实在。
接下来呢，找一张纸，抄下你要的书，去书店吧。实际看一看，内容是否真的符合自己的需要，翻译的水平如何。当然，如果你没时间，如果你对前面的了解很有把握，这一步可以省略。实际看书的时候，注意一下封底的推荐，老外的书都有一些大牛的推荐语录，国内现在也流行，看看那些大牛的推荐，也很有参考价值。
买书嘛，建议还是网上买，就图个便宜。就到豆瓣上去看吧，个人喜欢卓越。
以上是我个人的选书过程。下面介绍一下JOLT。JOLT大奖，号称软件业的奥斯卡，呵呵。以下摘字百度知道：
“Jolt 大奖素有“软件业界的奥斯卡”之美誉，共设通用类图书、技术类图书、语言和开发环境、框架库和组件、开发者网站等十余个分类，每个分类设有一个“ 震撼奖”（Jolt Award）和三个“生产力奖”（Productivity Award）。一项技术产品只有在获得了Jolt奖之后才能真正成为行业的主流，一本技术书籍只有在获得了Jolt奖之后才能真正奠定经典的地位。赞助商 Jolt可乐的广告词是“震撼全世界”，Jolt奖就让我们看到，是谁在震撼着我们今天的世界。虽然Jolt并不起决定作用，但代表了某种技术趋势与潮流.”
看到JOLT这个关键字，你得高度重视哦。 大家熟知的《About Face》和《CSS实战手册》，就是获奖书目。CSDN读书频道有相关专题。大家都属于IT人士，所以里面很多书是值得好好读的。个人感觉面向对象的分析与设计、UML，是应该好好学习的，除了可以帮助你开发出好的软件，更重要的是，这所提出的分析问题的思维方式，而不仅仅是为写软件。
你在选书方面有什么心得体会呢，欢迎交流^o^
Read more...
Aug 18, 2008
2008-08 UCDChina 南京书友会：产品设计
这一期的话题是产品设计和用户体验设计。看到这个话题的时候，我是十分感兴趣的。特别是产品设计。这个词是我在工作时接触到的，在斟酌考研方向时逐渐了解，然后在后续的工作中经常围绕其思考和实践的词。
1、关于产品设计
一个成功的产品由哪些东西决定呢？我还是十分认同Larry Keely提出的三个要素：技术可能性、商业可能性、设计期望性。Agla在“设计的价值”一文中也指出过这三个要素。这三个要素的交集，就是令人满意的、好用的、可构建的成功产品。对应不同的产品，比如工业产品、软件产品，每一个要素都有不同的内容。
如果一个较弱，产品难以经受住时间的考验。Novell强调技术，很少考虑期望性，他的竞争能力就不强；Apple重视用户期望和体验，但在业务上曾经不够成熟，但对用户的关注所创造的忠诚度很大程度上维持了其发展；而Microsoft的业务运营能力很强，但其产品难以高度满足用户期望，这个薄弱点给其他竞争者提供了机会。
所以，一个成功的产品，三个要素缺一不可，并且要平衡发展。
2、关于产品设计流程
我觉得没有最好，只有最合适。在实际工作中我先后实践了两种观点，一个就是UCD，一个是ACD（以活动为中心的设计）。
UCD的理想的设计流程大家都清楚，但这个理想的设计流程未必都适合大家。我是在看了Copper的《About Face》后知道了这个流程，并按照这个流程在项目中去实践。结果是在第一步用户调查就出了问题，无法正真准确的获得和把握用户的真实需求，导致后续的流程混乱，难以并最终无法进行下去。这和公司的组织结构、团队协作有很大关联。有很多人也和我相似，在这里受到挫折，遇到困难。
后来看了《一目了然》之后，作者以自己的实际经验对UCD的流程做了变通，强调了ACD。我也实践了，调整了流程，跳过了用户调查。我不知道，也无法知道用户需要什么，但我知道怎样做会带来良好的使用体验。以此作为设计的依据来完善每一个功能的设计。这个实践是有效的，但仍然有很多地方是可以改进和完善的。
Normal自己对UCD的质疑激起了很多人对UCD的激烈讨论。我认为不管是UCD，还是ACD，其实就是用户需要什么和我能给用户什么之间的一个平衡，不同的公司环境所能把握的重点是不同的，但都是以目标为导向，最终都是为了产生良好的用户体验。设计师应当灵活的把握这两方面的平衡，而不是偏向于哪一种。
3、关于产品创新
很多人的观点还是创造一个新的产品，我也是。我以前一直这么认为，也天马行空的想过，也想着如何把公司的产品做成那样。但实际发现，并不行。对产品功能上的创新远没有对流程、业务模式上的改进创新更有实效，更长远。
Kelley的一篇访谈中谈到了创新的几点，我觉得很有道理，我在实践中的认识也与此相吻合。
第一，创新不是创造新产品，因为这个世界模仿的太快，这在中国尤为突出。而是应该着重在可能为企业带来持久优势的创新，例如渠道、品牌、客户体验、流程、服务系统、业务模式等等。这些远比一个全新的产品意义重大。而且没有这些坚实的基石，创造一个全新的产品也很难，很没保障。
第二，创新不是脑力激荡。那往往会陷入混乱、偏离正规，表面上是创新，其实是乱闯。创新应当依据正确的方法、正确的程序，分轻重缓急来创新。
第三，创新要从“望闻问切”，而不是从打破常规开始。要有的放矢，从对市场需求、新技术的价值、公司和竞争者的分析来判断，才能生产出顾客需要、竞争对手忽视、企业力所能及的产品。这一点和第二点是一致的。
产品设计是一个很大很广的领域，对于设计师，我觉得在不同理论的指导下去实践，会有更多的收获。
Read more...
1、关于产品设计
一个成功的产品由哪些东西决定呢？我还是十分认同Larry Keely提出的三个要素：技术可能性、商业可能性、设计期望性。Agla在“设计的价值”一文中也指出过这三个要素。这三个要素的交集，就是令人满意的、好用的、可构建的成功产品。对应不同的产品，比如工业产品、软件产品，每一个要素都有不同的内容。
如果一个较弱，产品难以经受住时间的考验。Novell强调技术，很少考虑期望性，他的竞争能力就不强；Apple重视用户期望和体验，但在业务上曾经不够成熟，但对用户的关注所创造的忠诚度很大程度上维持了其发展；而Microsoft的业务运营能力很强，但其产品难以高度满足用户期望，这个薄弱点给其他竞争者提供了机会。
所以，一个成功的产品，三个要素缺一不可，并且要平衡发展。
2、关于产品设计流程
我觉得没有最好，只有最合适。在实际工作中我先后实践了两种观点，一个就是UCD，一个是ACD（以活动为中心的设计）。
UCD的理想的设计流程大家都清楚，但这个理想的设计流程未必都适合大家。我是在看了Copper的《About Face》后知道了这个流程，并按照这个流程在项目中去实践。结果是在第一步用户调查就出了问题，无法正真准确的获得和把握用户的真实需求，导致后续的流程混乱，难以并最终无法进行下去。这和公司的组织结构、团队协作有很大关联。有很多人也和我相似，在这里受到挫折，遇到困难。
后来看了《一目了然》之后，作者以自己的实际经验对UCD的流程做了变通，强调了ACD。我也实践了，调整了流程，跳过了用户调查。我不知道，也无法知道用户需要什么，但我知道怎样做会带来良好的使用体验。以此作为设计的依据来完善每一个功能的设计。这个实践是有效的，但仍然有很多地方是可以改进和完善的。
Normal自己对UCD的质疑激起了很多人对UCD的激烈讨论。我认为不管是UCD，还是ACD，其实就是用户需要什么和我能给用户什么之间的一个平衡，不同的公司环境所能把握的重点是不同的，但都是以目标为导向，最终都是为了产生良好的用户体验。设计师应当灵活的把握这两方面的平衡，而不是偏向于哪一种。
3、关于产品创新
很多人的观点还是创造一个新的产品，我也是。我以前一直这么认为，也天马行空的想过，也想着如何把公司的产品做成那样。但实际发现，并不行。对产品功能上的创新远没有对流程、业务模式上的改进创新更有实效，更长远。
Kelley的一篇访谈中谈到了创新的几点，我觉得很有道理，我在实践中的认识也与此相吻合。
第一，创新不是创造新产品，因为这个世界模仿的太快，这在中国尤为突出。而是应该着重在可能为企业带来持久优势的创新，例如渠道、品牌、客户体验、流程、服务系统、业务模式等等。这些远比一个全新的产品意义重大。而且没有这些坚实的基石，创造一个全新的产品也很难，很没保障。
第二，创新不是脑力激荡。那往往会陷入混乱、偏离正规，表面上是创新，其实是乱闯。创新应当依据正确的方法、正确的程序，分轻重缓急来创新。
第三，创新要从“望闻问切”，而不是从打破常规开始。要有的放矢，从对市场需求、新技术的价值、公司和竞争者的分析来判断，才能生产出顾客需要、竞争对手忽视、企业力所能及的产品。这一点和第二点是一致的。
产品设计是一个很大很广的领域，对于设计师，我觉得在不同理论的指导下去实践，会有更多的收获。
Read more...
Aug 1, 2008
一目了然的感觉真好
对此书有相见恨晚的感觉，四天时间通读，又重读重点做笔记。都是利用上班时间读的，但并非和工作无关，相反给我目前的项目很大的启发和帮助，让我在界面设计、软件功能、软件架构以及项目开发方式上有了不少新的想法。我将这些想法用于改进原先的项目计划，希望以一种更合理的方式开发出更合理的软件，提升软件的质量。目前的改进是有效果的，改进将持续进行下去。
书中的几个观点给我印象十分深刻：
1、走出UCD的困惑。亲近用户、和用户打成一片的理念非常好，但常常并不需要这样。时间限制、预算、兴趣缺失及其他事情都会相伴左右。而就理念本身，过度听从呼声最高的部分用户方而会给使用产品的所有人带来困难。所以，有必要相信自己能设计出好的Web软件，而不是依赖不可能得到的真实的用户数据。
2、 功能并不是关键，最关键的地方才应该被关注。一份显性的软件意识一份专注的软件。它易于为人所理解，因为它自身目标明确，从不会游移，每一个功能都设计的支持对应的活动。 坚持做重要的事情，好的创意可以搁置一旁。留下你认为产品应该拥有的，把功能削减到只剩下最重要的为止，如此循环。
3、不断地改进精简是通往简介的唯一途径。“精简”是减少软件的功能，直到剩下必须的为止。“不断的改进”是不断的重复，不要停止。保持不断重复，再评估，使设计更有条理，更精简，并且更精致。“简洁”是设计原则。专注的软件，通过简洁清晰的用户界面提供最需要的功能，轻文字描述，重当前任务。这些品质构成了简洁的用户体验，通过避免思维和操作上的混乱来减少软件的复杂度。
4、改良比创新更重要。大多数时候，公司和软件产品并不需要伟大的创意，他们需要的是那些能立竿见影的细小改进。
不敢说对Web设计人员，只说对我的启发是巨大的，理清了很多想法，更新了很多观念，正如书名，“一目了然”。强烈推荐大家读这本说。具体内容我做了书摘，感兴趣的朋友可以看看。
Read more...
书中的几个观点给我印象十分深刻：
1、走出UCD的困惑。亲近用户、和用户打成一片的理念非常好，但常常并不需要这样。时间限制、预算、兴趣缺失及其他事情都会相伴左右。而就理念本身，过度听从呼声最高的部分用户方而会给使用产品的所有人带来困难。所以，有必要相信自己能设计出好的Web软件，而不是依赖不可能得到的真实的用户数据。
2、 功能并不是关键，最关键的地方才应该被关注。一份显性的软件意识一份专注的软件。它易于为人所理解，因为它自身目标明确，从不会游移，每一个功能都设计的支持对应的活动。 坚持做重要的事情，好的创意可以搁置一旁。留下你认为产品应该拥有的，把功能削减到只剩下最重要的为止，如此循环。
3、不断地改进精简是通往简介的唯一途径。“精简”是减少软件的功能，直到剩下必须的为止。“不断的改进”是不断的重复，不要停止。保持不断重复，再评估，使设计更有条理，更精简，并且更精致。“简洁”是设计原则。专注的软件，通过简洁清晰的用户界面提供最需要的功能，轻文字描述，重当前任务。这些品质构成了简洁的用户体验，通过避免思维和操作上的混乱来减少软件的复杂度。
4、改良比创新更重要。大多数时候，公司和软件产品并不需要伟大的创意，他们需要的是那些能立竿见影的细小改进。
不敢说对Web设计人员，只说对我的启发是巨大的，理清了很多想法，更新了很多观念，正如书名，“一目了然”。强烈推荐大家读这本说。具体内容我做了书摘，感兴趣的朋友可以看看。
Read more...
Jul 29, 2008
2008-07 UCDChina 南京书友会：浏览器
本期的话题是浏览器。这个话题大家都熟悉，但似乎又没有那么多好谈的。对标准的支持、扩展、插件、开发者友好、内存、速度，IE、Firefox、Maxthon、Opera。作为业内人的我们，一开始想到的大概都是这些话题。
一开始大家还围绕着这些话题来展开交流，不过思维很快扩展开来，谈到未来浏览器的发展，Web OS，以浏览器取代OS，进而谈到各种终端，还有极具科幻色彩的人类终极发展展望。虽然有些跑远了，但这样的交流也很有意思，很拓展思路，呵呵。
下面说说我的观点吧。
1、浏览器，并没有说是Internet浏览器。这就没有限制在IE、Firefox、Maxthon、Opera等网络浏览器上。浏览器，顾名思义，就是用来浏览信息的。这也是网络浏览器的本义。但这个名词似乎已经过时了。人们使用浏览器已经远远不是简单的来浏览信息了。就像Web 2.0的到来，带来的是人与信息更广泛层面上的交流与互动。不光是网络浏览器，explorer虽然是一个进程，但其实就是一个本地的浏览器，一个窗口。所以，浏览器是人与机器、人与信息的交互沟通的工具，可以泛泛的理解为人与机器之间的窗口。
2、以云计算为代表的未来信息存储处理模式所带来的改变，以及大家谈到的多种终端浏览器，推荐大家看两个视频：
Nokia Morph Concept (long)
Office Labs: Future of personal health concept
浏览器就是人机交互的界面，好的界面是需之即来挥之即去，就如这两个视频所描绘出的场景，应该能很好的描述大家对于信息浏览终端在未来的发展。当然 关于Web OS、浏览器取代OS的情况，那也是很复杂，对计算机硬件、网络的影响都是巨大的，我觉得需要对计算机底层的东西有很好的了解和掌握才能有相对正确的思考方向，还要材料科学、生物科学等等等等，很多问题不是想象的那么简单。
3、现实一些，不要那么遥远。我觉得除了一开始大家想到的方面，可以从网络浏览器的易用性来谈一谈。经常有朋友请我帮忙看看他们的IE，出了种种问题。其实在Internet属性-程序-重置Web设置，这个选项能解决不少问题，但这样一个很有用的功能怎么会藏这么深，很多人不知道呢？那IE的其他设置选项，是不是大家都会使用呢？答案显然不是。Firefox的情况好一些，但对普通用户来说也不容易对浏览器进行相关设置。有人提到浏览器个性化，或者说有针对性的浏览器，比如老年人使用的浏览器、年轻人使用的浏览器、儿童使用的浏览器。我觉得这样个性化的浏览器完全没有必要单独开发。不管是IE还是Firefox，一款浏览器的核心是相同的，只是应用不同。我想到了 MVC架构，道理有些类似。如果能够提供十分方便易用的浏览器设置方式，个性化可以很容易的由用户自己实现。具体怎么实现，我觉得Web方式就很不错，有很大的空间来提供易用的解决方案。那么多设置干嘛局限于一个小小的WinForm窗口呢？具体就不展开说了，观点就是现在浏览器的易用性还有很多可以改进的地方。
4、浏览器的不兼容性一直是大家痛恨的地方。这里建议大家参考一些重构和设计模式方面的知识，利用一些成熟的开源开发库，这些库对各种浏览器的差别做了很好的重构和封装，能较好的避免不兼容问题。《Ajax实战》一书对这方面做了较好的介绍，大家可以参考。
书友会照片，来自JunChen的大脚：http://footbig.com/photo/191175
Read more...
一开始大家还围绕着这些话题来展开交流，不过思维很快扩展开来，谈到未来浏览器的发展，Web OS，以浏览器取代OS，进而谈到各种终端，还有极具科幻色彩的人类终极发展展望。虽然有些跑远了，但这样的交流也很有意思，很拓展思路，呵呵。
下面说说我的观点吧。
1、浏览器，并没有说是Internet浏览器。这就没有限制在IE、Firefox、Maxthon、Opera等网络浏览器上。浏览器，顾名思义，就是用来浏览信息的。这也是网络浏览器的本义。但这个名词似乎已经过时了。人们使用浏览器已经远远不是简单的来浏览信息了。就像Web 2.0的到来，带来的是人与信息更广泛层面上的交流与互动。不光是网络浏览器，explorer虽然是一个进程，但其实就是一个本地的浏览器，一个窗口。所以，浏览器是人与机器、人与信息的交互沟通的工具，可以泛泛的理解为人与机器之间的窗口。
2、以云计算为代表的未来信息存储处理模式所带来的改变，以及大家谈到的多种终端浏览器，推荐大家看两个视频：
Nokia Morph Concept (long)
Office Labs: Future of personal health concept
浏览器就是人机交互的界面，好的界面是需之即来挥之即去，就如这两个视频所描绘出的场景，应该能很好的描述大家对于信息浏览终端在未来的发展。当然 关于Web OS、浏览器取代OS的情况，那也是很复杂，对计算机硬件、网络的影响都是巨大的，我觉得需要对计算机底层的东西有很好的了解和掌握才能有相对正确的思考方向，还要材料科学、生物科学等等等等，很多问题不是想象的那么简单。
3、现实一些，不要那么遥远。我觉得除了一开始大家想到的方面，可以从网络浏览器的易用性来谈一谈。经常有朋友请我帮忙看看他们的IE，出了种种问题。其实在Internet属性-程序-重置Web设置，这个选项能解决不少问题，但这样一个很有用的功能怎么会藏这么深，很多人不知道呢？那IE的其他设置选项，是不是大家都会使用呢？答案显然不是。Firefox的情况好一些，但对普通用户来说也不容易对浏览器进行相关设置。有人提到浏览器个性化，或者说有针对性的浏览器，比如老年人使用的浏览器、年轻人使用的浏览器、儿童使用的浏览器。我觉得这样个性化的浏览器完全没有必要单独开发。不管是IE还是Firefox，一款浏览器的核心是相同的，只是应用不同。我想到了 MVC架构，道理有些类似。如果能够提供十分方便易用的浏览器设置方式，个性化可以很容易的由用户自己实现。具体怎么实现，我觉得Web方式就很不错，有很大的空间来提供易用的解决方案。那么多设置干嘛局限于一个小小的WinForm窗口呢？具体就不展开说了，观点就是现在浏览器的易用性还有很多可以改进的地方。
4、浏览器的不兼容性一直是大家痛恨的地方。这里建议大家参考一些重构和设计模式方面的知识，利用一些成熟的开源开发库，这些库对各种浏览器的差别做了很好的重构和封装，能较好的避免不兼容问题。《Ajax实战》一书对这方面做了较好的介绍，大家可以参考。
书友会照片，来自JunChen的大脚：http://footbig.com/photo/191175
Read more...
Jul 14, 2008
失望
上头跟我说：“忘掉你的想法吧，就按照他们要求的来。” 连理由都没有。
我很失望，这应该是多次交涉的最终结果，那就是听他们的，完全否定我对产品的设计的想法和建议，否定我提出的方案。我知道上头也有些无奈，谁让客户牛逼呢？
我有些生气，我积极争取的东西无影无踪。你们提的东西明明很多不合理，还有硬伤，为什么还那么坚持？我们提的东西你们认真考虑了没有？要我们给建议和方案，又完全不理会，连理由都没有。浪费时间，欺骗感情。
我在怀疑，我是做UI的吗？我是在做设计吗？干脆直接给出原型让我直接写code好了，还费那个劲让我白设计一番干嘛。也许做个纯粹的程序员没有那么些烦心的事，技术相比人心、商业、需求、设计、市场，更简单直接。
这是第三个项目了，第三次让我失望。在前两个项目中没人重视我的意见，总是以各种所谓现实的理由来应对我。“你的想法是好的，但是...” ，总是有那么多但是。我的想法很乌托邦吗？这次客户牛逼，直接否定。我是底层，我上面还有很多层，我没有权利，小鬼一个。每次都满怀热情和希望的开始，每次都冷冷的进行和结束，我找不到一点成就感。
想到前两天看的两部电影，《Pirates Of Silicon Valley》和《AntiTrust》，第一个有些纪实性质，就是乔布斯和盖茨的起家故事，第二部中将乔布斯和盖茨合为一个人。两部电影中，微软和盖茨都是反面角色。一个是偷盗技术的卑鄙小人。一个表面上是慈善的、青年才俊型的CEO，但背后为了自己利益，不但偷盗别人的代码，更为了打击对手而杀害对方的主要程序员。这两部电影影响了微软和盖茨在我心里的形象，我一直是很喜欢微软的，“Your Potential. Our Passion.”。更难以接受的是那些大公司的光鲜技术、激情的工作演说、诱人的福利待遇、巨大的财富背后，商业竞争的不择手段，让我很寒心。乔布斯的偏执也让人很难理解和难以接受。这又让我想到毕业前去南大听华为的宣讲会一样，多少稚嫩的毕业生被那些激情的演说打动。现在感觉一切都是那么的假。
也许我的想法太小孩了，也许我还没见识过所谓的复杂，也许打击才刚刚开始。也许我现在的心态比较消极，也许我现在的心态不对。我要静一下，我要好好想想。
Read more...
我很失望，这应该是多次交涉的最终结果，那就是听他们的，完全否定我对产品的设计的想法和建议，否定我提出的方案。我知道上头也有些无奈，谁让客户牛逼呢？
我有些生气，我积极争取的东西无影无踪。你们提的东西明明很多不合理，还有硬伤，为什么还那么坚持？我们提的东西你们认真考虑了没有？要我们给建议和方案，又完全不理会，连理由都没有。浪费时间，欺骗感情。
我在怀疑，我是做UI的吗？我是在做设计吗？干脆直接给出原型让我直接写code好了，还费那个劲让我白设计一番干嘛。也许做个纯粹的程序员没有那么些烦心的事，技术相比人心、商业、需求、设计、市场，更简单直接。
这是第三个项目了，第三次让我失望。在前两个项目中没人重视我的意见，总是以各种所谓现实的理由来应对我。“你的想法是好的，但是...” ，总是有那么多但是。我的想法很乌托邦吗？这次客户牛逼，直接否定。我是底层，我上面还有很多层，我没有权利，小鬼一个。每次都满怀热情和希望的开始，每次都冷冷的进行和结束，我找不到一点成就感。
想到前两天看的两部电影，《Pirates Of Silicon Valley》和《AntiTrust》，第一个有些纪实性质，就是乔布斯和盖茨的起家故事，第二部中将乔布斯和盖茨合为一个人。两部电影中，微软和盖茨都是反面角色。一个是偷盗技术的卑鄙小人。一个表面上是慈善的、青年才俊型的CEO，但背后为了自己利益，不但偷盗别人的代码，更为了打击对手而杀害对方的主要程序员。这两部电影影响了微软和盖茨在我心里的形象，我一直是很喜欢微软的，“Your Potential. Our Passion.”。更难以接受的是那些大公司的光鲜技术、激情的工作演说、诱人的福利待遇、巨大的财富背后，商业竞争的不择手段，让我很寒心。乔布斯的偏执也让人很难理解和难以接受。这又让我想到毕业前去南大听华为的宣讲会一样，多少稚嫩的毕业生被那些激情的演说打动。现在感觉一切都是那么的假。
也许我的想法太小孩了，也许我还没见识过所谓的复杂，也许打击才刚刚开始。也许我现在的心态比较消极，也许我现在的心态不对。我要静一下，我要好好想想。
Read more...
Jun 20, 2008
QOC（Questions, Options, Criteria），设计管理的方法
在设计的时候，常常会有这样的情况：自己和小组成员，以及与其他小组成员之间，包括销售人员、开发人员、用户等，进行讨论的时候，这些来自各方的观点在讨论中自由地流动。大家会在白板上画满彩色的草图；会在白纸上迅速地写写画画，而后随机撕掉；各种各样的即时贴贴的到处都是；各种草图、示意图到处都是。
在这种情况下，很容易忽略一个好的建议或是一时设计的历史记录，包括那些进行的步骤和得到设计的一些推理。当设计不断取得进展的时候，怎样帮助设计人员捕捉下设计记录及背后的设计思考。方法很多，QOC是其中一个。
QOC是一种对设计决策过程及各种方案的评估进行完整记录的设计方法（MacLean等，1989）。
包含三个要素：
QOC用图表的方式来呈现，用线条将选择和标准连接起来。实线表示一个肯定的评估，即选择符合标准；虚线表示否定的评估，即选择不符合标准。
在考虑选择的时候，要同时向用户提供他们可能感兴趣的地点和时间信息。过于详细的补充内容不要放在主屏幕上，但要能通过主屏幕访问到它们。
在实际项目中，我还没有用到过这个方法，这个方法提及了设计管理方面的问题，如何让设计更有效率和实效，在设计的过程中不断向前稳步推进，这是值得思考和关注的问题。
参考：
《移动设备交互设计》104页
《Experience of UserCentred Design in Nomadic Media》Juhani Heinilä（2005）.
Read more...
在这种情况下，很容易忽略一个好的建议或是一时设计的历史记录，包括那些进行的步骤和得到设计的一些推理。当设计不断取得进展的时候，怎样帮助设计人员捕捉下设计记录及背后的设计思考。方法很多，QOC是其中一个。
QOC是一种对设计决策过程及各种方案的评估进行完整记录的设计方法（MacLean等，1989）。
包含三个要素：
- Q（Questions）问题：设计点
- O（Options）选择：问题可能的答案或解决方案
- C（Criteria）标准：评估备选方案的方法
QOC用图表的方式来呈现，用线条将选择和标准连接起来。实线表示一个肯定的评估，即选择符合标准；虚线表示否定的评估，即选择不符合标准。
在考虑选择的时候，要同时向用户提供他们可能感兴趣的地点和时间信息。过于详细的补充内容不要放在主屏幕上，但要能通过主屏幕访问到它们。
在实际项目中，我还没有用到过这个方法，这个方法提及了设计管理方面的问题，如何让设计更有效率和实效，在设计的过程中不断向前稳步推进，这是值得思考和关注的问题。
参考：
《移动设备交互设计》104页
《Experience of UserCentred Design in Nomadic Media》Juhani Heinilä（2005）.
Read more...
Jun 17, 2008
移动设备交互设计初步体会
最近在研究移动设备的交互设计。一开始没有资料，对于移动设备的设计设想了很多，设想的依据是 iPhone、Nokia、HTC等先进的交互设计以及概念产品，心里也没底。在看了《移动设备交互设计》这本书的三章后，想法开始收敛。结合前段时间做用户调查和角色设计的试验，小结几个观点。
1、不要狭隘的设想未来的移动设备是随身携带的功能超强的手机。移动设备具有专用性，并不是所有功能就集成在一起就是好东西。要确定一套为数不多的、一致的并且用户确实需要的功能，然后以简单直接的方式表达出来。
2、新技术对移动设备的设计和使用会有很大的影响，要关注新技术的发展，考虑现有的设计在新技术的加入下会有怎样的变化。但同时要防止滥用所有新技术。
3、移动设备的设计和传统的桌面应用、web应用设计有很大的区别，不仅仅是以效用和任务为中心。在将传统应用迁移到移动设备上时，要考虑人们对这种应用和服务的需求有多少是依赖于其非移动的应用背景的。
一个重要方法：自由讨论
让想象力自由发挥，促进不同组织和文化的互相理解，从社会学角度洞察人们的生活，寻找是什么驱动着他们，他们珍视些什么。当每个新的创意产生之后，指定正反方。正方应当对该建议大肆宣扬，从风设想怎样将其扩展；反方应当关注该建议的缺陷，指出其不切实际的地方，以及一些过于乐观的小团体思想。
虽然这里说的是移动设备交互设计，但和通常的交互设计道理是一致且相同的。
Read more...
1、不要狭隘的设想未来的移动设备是随身携带的功能超强的手机。移动设备具有专用性，并不是所有功能就集成在一起就是好东西。要确定一套为数不多的、一致的并且用户确实需要的功能，然后以简单直接的方式表达出来。
2、新技术对移动设备的设计和使用会有很大的影响，要关注新技术的发展，考虑现有的设计在新技术的加入下会有怎样的变化。但同时要防止滥用所有新技术。
3、移动设备的设计和传统的桌面应用、web应用设计有很大的区别，不仅仅是以效用和任务为中心。在将传统应用迁移到移动设备上时，要考虑人们对这种应用和服务的需求有多少是依赖于其非移动的应用背景的。
一个重要方法：自由讨论
让想象力自由发挥，促进不同组织和文化的互相理解，从社会学角度洞察人们的生活，寻找是什么驱动着他们，他们珍视些什么。当每个新的创意产生之后，指定正反方。正方应当对该建议大肆宣扬，从风设想怎样将其扩展；反方应当关注该建议的缺陷，指出其不切实际的地方，以及一些过于乐观的小团体思想。
虽然这里说的是移动设备交互设计，但和通常的交互设计道理是一致且相同的。
Read more...
Apr 25, 2008
关于交互设计与技术，以及小公司的一些思考
最近在写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...
抛开公司的一些具体情况不谈，做交互设计，在技术领域应该掌握哪些东西，掌握到什么程度，我有一些思考。
交互设计，我的一个初略的理解，就是把实现模型转变为心智模型。既然交互设计是实现模型和心智模型的纽带和桥梁，那技术能力应该成为交互设计师的一个必备能力和基本素质。
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 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...
Mar 17, 2008
2008-03 UCDChina 南京书友会：帮助
这次参加的朋友又多了好多，我也“忽悠”了一个做设计的中学好友一起参加。这次讨论的话题是：怎样设计“帮助”更有效？
由于晚到，没有听到振之关于主动帮助和被动帮助的观点，轮到我发言时，我又罗嗦了一通，实际就是表达的这个意思。这是我对于“帮助”的基本认识。在听完大家一圈的发言之后，我又有了新的观点。
话题，怎样设计“帮助”更有效，所以就不说好的设计不需要帮助之类的话了。
听大家的发言，发现大家把“帮助”的含义扩展开来，认为整个网站的设计其实就是“帮助”，教会用户如何使用网站也是“帮助”，还有一些导航和提示也划为“ 帮助”的范畴。其实，我不赞成这样的广义的“帮助”，这些广义的帮助有的应该属于网络营销、网站推广的范畴，这样很容易又和广义的“设计”放在一起讨论，反而不够清晰。
我的理解是，“帮助”就是针对“困难”来的，就是用户在完成一个目标任务的过程中遇到困难时，有问题时，需要知道如何解决问题所需要的那部分知识。这种知识的表现形式，就是我们所要设计的。
有哪些表现形式呢？JunChen在文章中提到了常见的“帮助”形式：文档型帮助、情景式帮助、演示型帮助等等，以及这些形式的优缺点。
我觉得要设计帮助的形式，首先要看是什么样的产品。这里我大概分“普通”和“高级”两类产品。
“ 普通”的，就是用户不以学习如何使用为目标，而是以直接完成任务为目的，这类产品常见的有网站、IM软件等，用户的目标很直接，也许就是想注册一个帐户，也许就是想加一个好友。用户在执行这些任务的过程中，遇到困难，那需要得到即时的直接的帮助。这时应该以主动帮助为主。对用户操作过程和行为的监控，对相关数据信息的分析，系统能够对当前用户遇到的困难做出“尽可能准”的判断，告诉用户“出了什么问题”，然后以直接的方式，告诉用户，“你应该怎么办 ”。以此来缩短执行目标任务的时间。用户无需知道“为什么”，只需要知道“怎么样”，从而继续任务的执行。通常这样的任务或产品在逻辑和结构上是简单的，情景式帮助和演示型帮助是比较好的形式。
“高级”的，那就是用户以学习如何使用为目标，这样的用户属于专家用户。常见的产品有图像处理、动画制作、文档处理等等软件。专家用户不会只满足“怎么样 ”，需要知道“为什么”。这样的帮助需要全面和深入。常见的就是帮助文档，而实际中，帮助文档是不够的，用户往往会看专业书籍，那书也成了帮助系统。通常这样的任务或产品在逻辑和结构上是很复杂和庞大的，目前看来，也只有详细而全面的文档才能有效的辅助用户。这样的帮助更多的是被动帮助。
以上就是听了大家的发言后产生的一些观点。
在发言中，发现大家普遍的在表达不够流畅，不能完全清晰的表达出自己的观点，有些朋友还不知道该说什么，我也是这样，发言的时候浑身很不自然，说话罗罗嗦嗦。我想有几个原因吧。设计师的性格原因，做设计的人，多是内向和敏感性的人，想法很多，但不一定善于综合总结和表达。这样的性格在众多生面孔面前，更加突出。对于第一次参加的朋友尤为这样。还有就是话题的发散性，发散性会引出很多想法，但想法多了，就难于归纳和总结，所以表达的时候也就缺乏条理。也许问题在具体一些，再详细一些，大家会表达的更到位。
我觉得语言表达能力对于一个设计师很重要，光有想法不行，表达不出来，坏的脑子里，不能有效的表达出来，别人弄不明白，那同样没用。现在的设计强调的是团队协作，设计师要与用户、与管理人员、与工程人员交流，表达不清楚，误解的几率增多，工作的效率可就下降了。
貌似我上面的话也没表达清楚，哈哈。慢慢来吧，写博客就是一个不错的训练方法，多交流更重要。
Read more...
由于晚到，没有听到振之关于主动帮助和被动帮助的观点，轮到我发言时，我又罗嗦了一通，实际就是表达的这个意思。这是我对于“帮助”的基本认识。在听完大家一圈的发言之后，我又有了新的观点。
话题，怎样设计“帮助”更有效，所以就不说好的设计不需要帮助之类的话了。
听大家的发言，发现大家把“帮助”的含义扩展开来，认为整个网站的设计其实就是“帮助”，教会用户如何使用网站也是“帮助”，还有一些导航和提示也划为“ 帮助”的范畴。其实，我不赞成这样的广义的“帮助”，这些广义的帮助有的应该属于网络营销、网站推广的范畴，这样很容易又和广义的“设计”放在一起讨论，反而不够清晰。
我的理解是，“帮助”就是针对“困难”来的，就是用户在完成一个目标任务的过程中遇到困难时，有问题时，需要知道如何解决问题所需要的那部分知识。这种知识的表现形式，就是我们所要设计的。
有哪些表现形式呢？JunChen在文章中提到了常见的“帮助”形式：文档型帮助、情景式帮助、演示型帮助等等，以及这些形式的优缺点。
我觉得要设计帮助的形式，首先要看是什么样的产品。这里我大概分“普通”和“高级”两类产品。
“ 普通”的，就是用户不以学习如何使用为目标，而是以直接完成任务为目的，这类产品常见的有网站、IM软件等，用户的目标很直接，也许就是想注册一个帐户，也许就是想加一个好友。用户在执行这些任务的过程中，遇到困难，那需要得到即时的直接的帮助。这时应该以主动帮助为主。对用户操作过程和行为的监控，对相关数据信息的分析，系统能够对当前用户遇到的困难做出“尽可能准”的判断，告诉用户“出了什么问题”，然后以直接的方式，告诉用户，“你应该怎么办 ”。以此来缩短执行目标任务的时间。用户无需知道“为什么”，只需要知道“怎么样”，从而继续任务的执行。通常这样的任务或产品在逻辑和结构上是简单的，情景式帮助和演示型帮助是比较好的形式。
“高级”的，那就是用户以学习如何使用为目标，这样的用户属于专家用户。常见的产品有图像处理、动画制作、文档处理等等软件。专家用户不会只满足“怎么样 ”，需要知道“为什么”。这样的帮助需要全面和深入。常见的就是帮助文档，而实际中，帮助文档是不够的，用户往往会看专业书籍，那书也成了帮助系统。通常这样的任务或产品在逻辑和结构上是很复杂和庞大的，目前看来，也只有详细而全面的文档才能有效的辅助用户。这样的帮助更多的是被动帮助。
以上就是听了大家的发言后产生的一些观点。
在发言中，发现大家普遍的在表达不够流畅，不能完全清晰的表达出自己的观点，有些朋友还不知道该说什么，我也是这样，发言的时候浑身很不自然，说话罗罗嗦嗦。我想有几个原因吧。设计师的性格原因，做设计的人，多是内向和敏感性的人，想法很多，但不一定善于综合总结和表达。这样的性格在众多生面孔面前，更加突出。对于第一次参加的朋友尤为这样。还有就是话题的发散性，发散性会引出很多想法，但想法多了，就难于归纳和总结，所以表达的时候也就缺乏条理。也许问题在具体一些，再详细一些，大家会表达的更到位。
我觉得语言表达能力对于一个设计师很重要，光有想法不行，表达不出来，坏的脑子里，不能有效的表达出来，别人弄不明白，那同样没用。现在的设计强调的是团队协作，设计师要与用户、与管理人员、与工程人员交流，表达不清楚，误解的几率增多，工作的效率可就下降了。
貌似我上面的话也没表达清楚，哈哈。慢慢来吧，写博客就是一个不错的训练方法，多交流更重要。
Read more...
Feb 24, 2008
[转]以用户为中心设计思维考问中国IT企业
一直在想，一些企业是怎么开展UCD的，他们到底是怎么做的。看到大连海事大学中国欧盟可用性研究中心的一份调查，对国内企业的UCD状况有了一些了解。
转自：http://news.ccw.com.cn/digital/htm2008/20080129_375543.shtml
【计世网 独家】（作者 大连海事大学中国欧盟可用性研究中心 刘正捷 郭志伟 钱凯 魏慧玲）
近年来，随着中国经济的发展和市场全球化，用户体验正为越来越多的人所认识，市场竞争的重点正在从技术转向用户体验，消费者对用户体验的要求越来越高，厂商对可用性的关注也与日俱增。为了更进一 步认识中国可用性行业和从业人员的现状及面临的问题，以利于行业今后的顺利发展，大连海事大学中国欧盟可用性研究中心开展了关于中国IT企业以用户为中心 设计（UCD）实践状况的调查研究。其结果值得中国IT企业深思。
作为可用性工程的核心方法论，以用户为中心的设计方法（UCD）自20世纪80年代末在北美、欧洲发达国家的IT业界开始实际应用，并在实践中不断 完善和成熟，在提高产品可用性质量和用户体验方面取得了明显成效。国内企业起步较晚，但近年来发展迅速，国内各大知名企业纷纷成立用户体验/可用性 /UCD部门，一些规模较小的创新型企业也在这方面有所动作。可用性与用户体验研究正在国内迅速崛起，并逐渐形成一个新兴行业。
作为可用性工程的核心方法论，以用户为中心的设计方法（UCD）自20世纪80年代末在北美、欧洲发达国家的IT业界开始实际应用，并在实践中不断 完善和成熟，在提高产品可用性质量和用户体验方面取得了明显成效。国内企业起步较晚，但近年来发展迅速，国内各大知名企业纷纷成立用户体验/可用性 /UCD部门，一些规模较小的创新型企业也在这方面有所动作。可用性与用户体验研究正在国内迅速崛起，并逐渐形成一个新兴行业。
大连海事大学中国欧盟可用性研究中心选择了在可用性和UCD方面已经有一定积累或比较领先的13家中国企业，开展 了关于中国IT企业UCD实践状况的调查研究。调查对象主要为大型企业，也包括少数创新型中小企业，地理和行业分布如图1和图2所示。在每个企业中选取1 名可用性从业人员作为受访者，均有一年以上的可用性从业经验，总体平均从业时间为两年半，其中33%的受访者为普通可用性从业人员，67%为UCD部门主 管。
为了全面系统地了解企业在UCD方面工作开展的状况，调查参照了可用性成熟度模型(UMM)(INUSE, 1998)(Bevan & Earthy, 2001)的以人为中心程度衡量尺度——UMM∶HCS（如表1所示）。
该尺度用来衡量组织的可用性成熟度，即保证产品可用性质量的能力水平，它所涉及的领域包括：关于使用质量的培训、 用户信息收集、与现有流程的融合及使用质量在企业制度上的保障等方面。根据这个模型，调查工作的侧重点包括可用性的员工培训及认识水平、用户参与程度、 UCD的不断完善、UCD与原有流程的融合和UCD方法应用状况这五个领域。
国内UCD部门现状
目前，大多数企业的UCD部门都隶属于产品线下的研发部，少数直接隶属于企业级领导，或位于研究、支撑平台或市场部门下。绝大多数部门都是从美工或者界面设计部门演变过来，少数是由企业高层直接组建。部门成员背景以设计、计算机居多，搭配少数的心理学与社会学。其中大型企业的UCD部门员工背景有比较明显的多学科交叉特点。
大多数被调查企业的可用性相关工作较多集中在设计阶段，工作主要是用户研究和产品设计。这些企业中的UCD部门已 经受到公司领导的重视，并且越来越得到其他部门的认可，部门人员有扩充的趋势，专业化水准有所提升，分工也越来越细，用户研究工作也逐渐渗透到产品生命周 期中除设计之外的其他阶段。
员工培训及认识水平
大多数被调查企业都还没有针对用户体验的培训内容，主要限于UCD部门内部交流。个别企业已经在整个企业范围内针对用户体验进行比较系统的培训，接受培训的人员主要是部门级的管理人员及部分对可用性感兴趣的员工。
从培训效果来看，只有和UCD部门合作过的员工才能在方法层面上有一些认识。大部分被调查企业的普通员工对于UCD的整体理解仅仅停留在用户界面层面，少 数企业的员工会认识到UCD与整个产品的架构和功能设计有关。在这方面，互联网行业对UCD与整个系统有关的意识较高。
在多数被调查企业中，普通开发人员在进行某个设计方案选择时，首先会考虑到自己的工作量和工作绩效，其次才会考虑 用户体验。而互联网企业对用户关注的意识较高，因为员工通过对用户行为数据的监控分析，会直观感受到自己的每个决策在用户体验上的最终效果，比较容易在自 己的工作与用户体验之间建立联系。
用户参与程度
在对用户参与产品设计开发的认识方面，大部分被调查企业的管理层都已经意识到需要关注和改进产品可用性，有的企业甚至已经通过制度化来保障用户信息的收集，并把产品可用性作为一项系统质量因素来评估产品。
但受访企业中仅有一家企业对部分产品进行了可用性定量测试并据此建立产品可用性基准。没有采用可用性基准的企业主 要有两种情况：一种是以硬件提供商为代表的企业，虽然有意开展基准测试，但由于方法掌握程度和技术手段的限制，没法得到准确和有意义的定量数据；一种情况 是互联网企业，更倾向于采用点击率等数据去衡量产品的成败，通常不使用可用性定量基准。
在产品设计开发过程中进行持续可用性评估方面，只有少数企业能够在早期开展持续的迭代设计和评估，过程中则较少采 用基于原型的用户测试，而是更多地依靠行业/领域专家的评估。被调查的互联网企业基本上都不采用持续的测试评估，都是在产品上线后再做评估和改进；传统软 件企业当中，个别企业受瀑布开发模型与CMM体系的影响，不太愿意接受产品的持续变更与改进。正是由于没有反复迭代的设计过程，所以大部分企业内部也没有 相应的设计方案变更管理。
UCD的不断完善
超过三分之一的被访企业拥有自己的可用性实验室，有的企业甚至购置了眼动跟踪仪和专业分析软件来提升研究能力，也 有企业通过在不同地点建立多个可用性实验室来加强对公司产品线的支持。有超过三分之一的企业建立了UCD活动的文档模板，这些基础设施的建设表明企业对于 UCD工作积累的重视。
在UCD部门的自我提高与完善方面，多数企业普遍采用的办法是部门内部在项目之后的经验总结和分享。在部门今后发 展规划与员工技能发展方面，多数企业的UCD部门主管都对UCD部门员工的技能发展进行规划，其主要实施形式有三种：1.部门内部交流学习制度化; 2.外聘专家培训; 3.组织员工参加业界交流活动。
在有关UCD的对外合作方面，目前国内企业采用外包或外聘专家的并不太普遍，但大多数对外包持接受态度。主要原因 是企业UCD开展程度还不够深，对于UCD的理解和掌控能力不足。在受访企业中主要有三种情况：1.完全不接受外包策略，这主要是受到中国企业普遍的“自 己做（DIY）”文化的影响，喜欢什么事情都自己来做；2.能够接受外包策略，但由于自身可用性成熟度不高，对UCD整体流程的理解不足，不知道流程当中 的哪些环节可以外包，或不知道外包之后如何去进行过程和质量监控以及结果的验收和利用；3.出于企业商业与技术保密考虑，害怕外包会泄漏机密。
UCD与原有流程的融合
受访企业普遍认为可用性是重要的产品质量因素，但多数企业并没有将可用性融入到自身的质量管理体系中去，而更多的是由UCD部门自己来控制; 个别实施较好的企业采取在质量管理部门下面建立用户体验分部的做法，做法超前的企业已经将可用性作为重要考查指标纳入质量体系。
目前受访企业中UCD部门与其他部门，尤其是开发部门的沟通已基本没有太大的问题，但在制度和授权上，还不能保证UCD部门在用户体验方面的主导性和权威性，这在很大程度上还要依赖于具体可用性人员的专业水平和沟通能力。
总的来说，目前企业开发流程上对UCD提供的空间不够，企业还没有找到把UCD有效和高效地结合到开发流程中的办法。
UCD方法运用状况
对企业在产品设计中常用的UCD方法进行调查，结果如表2所示。我们可以看出，被调查企业使用的UCD方法比较广 泛。使用比较多的UCD方法有竞争产品研究、原型法（高保真）、用户满意度调查、文案分析法、用户访谈、可用性测试（发现问题为主）、专家评估、焦点小 组。比较少用的方法包括可达性评估、远程可用性研究、眼动跟踪方法、日志法、认知走查法。
在被调查的企业中，UCD方面均开展了大量的尝试和实践，积累了一定的经验，对有些方法的运用已经相当纯熟，甚至 开始结合自己的需要探索一些方法的创新。但这些企业的可用性成熟度总体上还没有达到较高水平。他们对比较经济有效的可用性方法使用较多，而对其他方法则使 用较少，从业人员对UCD方法的把握能力还有待提高。
受调查企业在选择和运用可用性方法的能力上差别较大。一部分企业在对一些常规可用性方法的认识和掌握方面尚有所欠缺。在方法的选择上，主要是受到项目资源和员工认识水平的限制；在方法的具体运用上，更多的限制则是源于员工技能和经验的不足。
成熟度评估
为了对国内企业的可用性成熟度发展水平有一个总体上的了解，我们还根据可用性成熟度模型的以人为中心程度衡量尺度——UMM∶HCS（如表1所示），对受调查企业进行了非正式的可用性成熟度评估。通过对调查数据的整理和分析，各受调查企业关于UMM∶HCS各个属性和实践的状况如表3所示。这里采用的评分尺度为：N——没有达到，P——部分达到，L——大部分达到，F——完全达到。
从结果中可以看出，现阶段国内硬件提供商在可用性成熟度方面相对较好，处于UMM五个成熟度级别的第三级或第四 级，即已实施级或已融合级，这也许是由于消费电子产品领域竞争激烈，企业比较容易直接感受到可用性对最终用户的影响，使得他们迫切体会到可用性的重要性， 从而在这方面大力投入的结果; 软件提供商和用户定制的解决方案提供商在UMM五个成熟度级别中多处于第二级，即已考虑级，这可能是由于软件行业较多受到传统软件工程思想的制约，影响到 他们对UCD的接受和实践；服务提供商则多处于UMM五个成熟度级别的第一级，即已意识级，由于服务提供商行业市场变化迅速的特点，企业需要及时迅速地做 出反应，所以很多互联网服务提供商只能根据自身特点，在开发流程中适当融入了一些可用性活动。
从业人员的看法
从调查中可以看到，在UCD方面领先的中国企业已经有两到三年的UCD实践历史，UCD部门也达到了一定的规模，而且正在发展多学科交叉的特点；一些企业 开展的UCD工作取得了很好的效果，得到了管理层和其他部门的认可；从业人员对前景比较乐观，对现状普遍感到满意。这反映出中国企业在面对市场竞争压力时 积极进取的态度，对先进技术和开发方法的敏感和接受能力，也展现出企业应对这些挑战的勇气和能力。
关于可用性行业未来发展面临的问题和挑战，受访者提到以下几点：企业管理层对UCD的重视程度以及普通员工的认识 水平还有待于进一步提高；从业人员的素质和数量以及专业人才的培养能力与实际需求之间还有较大差距；行业发展不够规范，缺乏对应有的专业和技能水准的衡量 和认定，这不利于行业今后的健康发展; 缺乏与可用性领域国际发展前沿和学术界的交流渠道，企业汲取和更新UCD知识和技能的能力不足，还需进一步提高整个社会对用户体验的认识和诉求。
链 接
如何改善UCD部门现状：
根据对可用性专业的理解和对国内工业界实际情况的认识，我们认为可以从以下几个方面努力：
1. 加强整个企业范围的UCD普及培训，特别是提高管理层对UCD的认识，这是保证UCD理念在企业文化中扎根的关键；
2.加强业界同行的相互交流、加强与专业机构和学术界的交流与合作，进行系统规范的UCD培训，使得从业人员可以系统规范地掌握UCD的知识和技能；
3. 将UCD与现有流程的融合制度化，保证用户在开发过程各个阶段的参与，以及用户研究结果在开发过程中的应用；
4. 尽可能让开发人员有机会亲自参与到用户研究活动中，从而保证UCD部门与开发部门沟通的顺畅和以用户为中心开发理念的建立；
5. 建立产品可用性质量基准，明确可用性设计目标，衡量UCD工作效果，并提高UCD价值的可见性；
6. 改造现有开发流程，使其更好地接纳UCD的反复设计和评估活动；
7. 在产品设计开发早期引入UCD活动，以支持未来产品创新；
8. 建立可用性活动文档模版，在有条件的情况下建立可用性实验室，提高UCD活动的效率和规范性；
9. 围绕人才培养开展校企合作，保证培养的专业人才更适合工业界的需要；
10. 在高校IT类专业普遍开设人机交互有关课程，为UCD的进一步推广提供土壤。
Read more...
Jan 29, 2008
自我们分析-产品的原则和方向
开发人员经常不理解产品需求。“××功能有用吗？”
开发人员经常在争论某个功能的具体设置。“××要显示吗？还是不显示吧。还是显示吧。”
开发人员经常怀疑自己所做产品的价值。“这东西做出来有人买吗？”
开发人员经常羡慕人家做的东西。“哇，××做的真强～”
设计人员经常对设计方案左右不定。“这样比较好，那样也有道理。”
。。。。。。
上面这些情况仅仅针对我所在的环境，其他公司我不清楚。这些问题看起来似乎很好笑，开发者似乎都在为产品经理着想，似乎都在为设计师着想，设计师似乎搞不清自己到底该设计什么样的东西出来。自己都不认可自己的产品和设计，怎么能做出让用户认可的产品和设计呢？
“怎样能做出成功的产品呢？”我常绕着这个问题胡思乱想。我们没有完整的团队，只是一个开发组，我也没做过××经理，“没有调查，就没有发言权”，所以从个人理解来说说。
先说说我觉得一个产品应该怎么去做。
第一，定出产品的原则和方向。由谁去定？产品经理嘛。定义一个产品的信息来源是啥？从市场， 从他对产品所在行业的理解，从他对用户的理解，最好还有他对产品创新的理解。看千鸟的《产品经理的责任》中有句话，“合格的产品经理才是产品合格的根源”，十分赞同。
第二，产品的原则和方向出来了，那就开工吧，交给项目组。项目经理要做的，是依据产品的原则和方向去实施，去全力的带动整个项目团队来做好产品。这里边包括N多东西，要考虑时间、流程、成本、人力、质量等等一堆要考虑的东西。
第三，下面就是项目组成员。简单的分就是设计师、工程师。设计又分，体验设计、交互设计、视觉设计；工程又分，前端开发、后台开发、测试。如果涉及到硬件，还要有硬件工程师和工业设计，这个我暂时还不了解。项目组成员在项目经理的协调下，各司其职，融合的协作来做出产品。
这么多职能划分，至少差不多这么多人。人不是机器，不会机械的去按照任务做事，去写代码，去测试，去设计。每个人对产品都有自己的想法。大多数人都有一种心理，要证明自己的观点是正确的，希望自己的观点能够影响别人或者某样事情。也许自己并没有察觉，这是一种潜意识。这样的心理带来的是辩论，在形式上可能就是开会。就如《Don't make me think》里说的，web设计团队讨论可用性是在浪费时间，项目组成员讨论产品的方向也是在浪费时间。“没有调查，就没有发言权”，这句话用在这里挺恰当，因为每个人都是从自己的个体角度去谈产品的方向。
大家有想法，很好。一时间，大家似乎都有市场眼光，都有为用户考虑的心。但想法要有个约束，有个方向。没有方向，那就成了发散式的个人观点。这个方向就是产品的原则和方向。如果项目组成员对产品的原则和方向不清楚，不认可，不理解，那问题就大了，带来的是项目进行过程中的混乱，最终产品可能失败。
产品的原则和方向是产品经理来敲定，敲定就结束了吗？不，原则和方向的传达更重要。我们不能只得到一句“以家庭和SOHO用户为目标的××”和一张功能列表，我们要知道为什么是这个原则和方向，为什么是这些功能。不仅仅是告诉我们“要怎样”，还要告诉我们“为什么这样”。让所有成员认可、理解产品的方向，打消大家的疑虑。从项目经理到项目组成员，都要对产品有一致的认识。这样带来的好处有这么些：
对产品，在传达产品原则和方向的过程中，团队成员一样会从技术的角度、从设计的角度提出自己的观点。产品经理也许出身技术、设计或者市场，他们的观点也是有不完善的。这样，产品经理与工程师、设计师的观点相互碰撞、融合，可能会弥补这种缺陷，对产品的完善是很有帮助的。
对个人，“噢～，我是要做这么一个产品，它会带来××样的价值，会××的影响使用者的工作和生活，我的辛苦和努力是有意义的”。
对团队，心往一处想，劲往一处使，把上面那句话里的“我”改为“我们”，“噢～，我们要做这么一个产品”。这对于团队的融洽协作十分的好。
对设计师，在解释什么是这个原则和方向，为什么是这些功能的时候，将给设计师提供十分重要的信息，这些都是重要的设计依据。
“合格的产品经理才是产品合格的根源”，产品原则和方向的准确传达是产品顺利开发的前提要素。
PS：想起上上次UCD书友会的时候，我说出我们团队的困惑，振之分析出我们的问题出在交流和沟通上，当时一下子清晰了很多，现在越想越是这个问题。我们貌似没有产品经理，好像项目经理就是在做产品经理的事，问题是，一年也只有一次和项目经理短暂的面对面会议交谈，因为他在台湾。项目的实质进程管理都是由开发组组长在管。这是一个大问题，下次再探讨。
Read more...
开发人员经常在争论某个功能的具体设置。“××要显示吗？还是不显示吧。还是显示吧。”
开发人员经常怀疑自己所做产品的价值。“这东西做出来有人买吗？”
开发人员经常羡慕人家做的东西。“哇，××做的真强～”
设计人员经常对设计方案左右不定。“这样比较好，那样也有道理。”
。。。。。。
上面这些情况仅仅针对我所在的环境，其他公司我不清楚。这些问题看起来似乎很好笑，开发者似乎都在为产品经理着想，似乎都在为设计师着想，设计师似乎搞不清自己到底该设计什么样的东西出来。自己都不认可自己的产品和设计，怎么能做出让用户认可的产品和设计呢？
“怎样能做出成功的产品呢？”我常绕着这个问题胡思乱想。我们没有完整的团队，只是一个开发组，我也没做过××经理，“没有调查，就没有发言权”，所以从个人理解来说说。
先说说我觉得一个产品应该怎么去做。
第一，定出产品的原则和方向。由谁去定？产品经理嘛。定义一个产品的信息来源是啥？从市场， 从他对产品所在行业的理解，从他对用户的理解，最好还有他对产品创新的理解。看千鸟的《产品经理的责任》中有句话，“合格的产品经理才是产品合格的根源”，十分赞同。
第二，产品的原则和方向出来了，那就开工吧，交给项目组。项目经理要做的，是依据产品的原则和方向去实施，去全力的带动整个项目团队来做好产品。这里边包括N多东西，要考虑时间、流程、成本、人力、质量等等一堆要考虑的东西。
第三，下面就是项目组成员。简单的分就是设计师、工程师。设计又分，体验设计、交互设计、视觉设计；工程又分，前端开发、后台开发、测试。如果涉及到硬件，还要有硬件工程师和工业设计，这个我暂时还不了解。项目组成员在项目经理的协调下，各司其职，融合的协作来做出产品。
这么多职能划分，至少差不多这么多人。人不是机器，不会机械的去按照任务做事，去写代码，去测试，去设计。每个人对产品都有自己的想法。大多数人都有一种心理，要证明自己的观点是正确的，希望自己的观点能够影响别人或者某样事情。也许自己并没有察觉，这是一种潜意识。这样的心理带来的是辩论，在形式上可能就是开会。就如《Don't make me think》里说的，web设计团队讨论可用性是在浪费时间，项目组成员讨论产品的方向也是在浪费时间。“没有调查，就没有发言权”，这句话用在这里挺恰当，因为每个人都是从自己的个体角度去谈产品的方向。
大家有想法，很好。一时间，大家似乎都有市场眼光，都有为用户考虑的心。但想法要有个约束，有个方向。没有方向，那就成了发散式的个人观点。这个方向就是产品的原则和方向。如果项目组成员对产品的原则和方向不清楚，不认可，不理解，那问题就大了，带来的是项目进行过程中的混乱，最终产品可能失败。
产品的原则和方向是产品经理来敲定，敲定就结束了吗？不，原则和方向的传达更重要。我们不能只得到一句“以家庭和SOHO用户为目标的××”和一张功能列表，我们要知道为什么是这个原则和方向，为什么是这些功能。不仅仅是告诉我们“要怎样”，还要告诉我们“为什么这样”。让所有成员认可、理解产品的方向，打消大家的疑虑。从项目经理到项目组成员，都要对产品有一致的认识。这样带来的好处有这么些：
对产品，在传达产品原则和方向的过程中，团队成员一样会从技术的角度、从设计的角度提出自己的观点。产品经理也许出身技术、设计或者市场，他们的观点也是有不完善的。这样，产品经理与工程师、设计师的观点相互碰撞、融合，可能会弥补这种缺陷，对产品的完善是很有帮助的。
对个人，“噢～，我是要做这么一个产品，它会带来××样的价值，会××的影响使用者的工作和生活，我的辛苦和努力是有意义的”。
对团队，心往一处想，劲往一处使，把上面那句话里的“我”改为“我们”，“噢～，我们要做这么一个产品”。这对于团队的融洽协作十分的好。
对设计师，在解释什么是这个原则和方向，为什么是这些功能的时候，将给设计师提供十分重要的信息，这些都是重要的设计依据。
“合格的产品经理才是产品合格的根源”，产品原则和方向的准确传达是产品顺利开发的前提要素。
PS：想起上上次UCD书友会的时候，我说出我们团队的困惑，振之分析出我们的问题出在交流和沟通上，当时一下子清晰了很多，现在越想越是这个问题。我们貌似没有产品经理，好像项目经理就是在做产品经理的事，问题是，一年也只有一次和项目经理短暂的面对面会议交谈，因为他在台湾。项目的实质进程管理都是由开发组组长在管。这是一个大问题，下次再探讨。
Read more...
Jan 16, 2008
学习从HTML过渡到XHTML
XHTML使用XML的特性来定义和HTML 4.01标准几乎完全相同的标记语言。XHTML比HTML使用起来框框要多很多。
大多数情况下，创建XHTML文档和创建HTML文档没有什么区别。要创建XHTML文档，需要做和知道下面几件事情。
1、声明文档类型
为了能让XHTML浏览器可以正确地解析和显示XHTML文档，XHTML文档首先要声明文档类型，告诉浏览器创建文档所使用的XML版本。然后说明在文档中定义元素的XHTML DTD的版本。
2、理解名称空间
XML DTD定义了任意数量的元素和属性名称。这些元素和属性名称都存储在DTD唯一的名称空间（namespace）中。浏览器在读取和解释文档时，会在名称空间中寻找这些元素和属性的使用方法，这样才能正确解释。
XML可以使用多个DTD，因此需要多个名称空间。在创建过渡版本的HTML文档时，如果要同时包含其他符合XML的元素，就要声明其他的名称空间。使用 xmlns（XML namespace的缩写）属性来定义一个或多个可供选择的名称空间。
XHTML文档中至少应该包含一个xmlns属性，以指定整个文档所使用的主要名称空间。
标签是依据MATH版本来显示成除法等式，还一句XHTML版本来解释为层。
如果在每次都要显示为除法等式，那这样的xmlns定义效率就低了。更好的方法是在文档的开始处确定和标注名称空间，然后在需要改变的元素前标注一个前缀来调用。如：
3、XHTML比HTML严格之处
XHTML和HTML的最大区别是，XHTML格式良好。
3.1 正确地嵌套元素
就是必须按照打开标记元素的顺序关闭他们。这个很容易理解，不多解释。
XHTML有一个嵌套限制，如下：
<a>标签不能包含其他<a>标签。
<pre> 标签不能包含<img>、<object>、<big>、<small>、<sub> 或<sup>标签。
<button> 标签不能包含<input>、<select>、<textarea>、< label>、<button>、<form>、<fieldset>、<iframe> 或 <isindex>标签。
<label>标签不能包含其他<label>标签。
<form>标签不能包含其他<form>标签。
3.2 结束标签
就是每个宝航其他标签或内容的标签都必须有对景的结束标签。这个也很容易理解，不多解释。
3.3 处理空元素
对于空白标签使用空格加斜杠的格式来表示，如<br />。这个也很容易理解，不多解释。
3.4 区分大小写
XHTML严格区分大小写，使用小写字母定义所有的HTML标签和属性。其他大写或混写标签和属性都不符合规范。
3.5 引用的属性值
所有属性值必须加上双引号。
3.6 明确的属性值
在XHTML中，每个属性都必须有一个值。没有只的属性必须使用自己的名称作为值。例如checked=”checked”。
3.7 处理特殊字符
对于在文章的Javascript和CSS声明中使用的< 和&字符，XHTML要严格的多。因为XML浏览器会简单地删除掉文档中所有<!--和-->中的注释内容，所以隐藏的焦痕和样式表将被删除。虽然可以将脚本放在CDATA中，但旧的浏览器不认识，也会将脚本忽略。所以推荐将脚本和样式保留在外部文件中，然后在文档中使用适当的外部链接来调用他们。
此外，在XHTML中，属性值中的特殊字符一定要用对应的实体。例如&一定要写成&。大于号和小于号一定要写成<和>等。
3.8 id和name属性
id和name属性都用来允许为文档中的任何元素关联一个标识符，以便可以被超链接或脚本调用或使用。
XHTML给id属性非常高的优先权，所以建议使用id属性来绑定文档中的元素。弱国必须要在某个标签中使用name属性，最好在其中也加入相同的id属性。
4、XHTML 1.1
XHTML1.1是以XHTML 1.0的严格的DTD开始的，在这个基础上进行了修改。1.1版本消除了所有不赞成使用的元素，以及仍在web上得到广泛使用的说哦有浏览器扩展。
要注意两个地方：第一，lang属性已经从每个元素中去除，应该使用 xml:lang属性；第二，name属性已经从<a>和<map>中除去，应该使用id属性。最后1.1标准定义了一组新的元素，称为“ruby”文本的印刷功能。这个我没见过，也没怎么弄清楚怎么使用，以后再说明。
以上就是XHTML使用需要知道和注意的地方，其实和HTML区别不大。
至于是否需要和应该使用XHTML，这个已是大势所趋，显然。网上关于web 2.0的介绍和讨论中经常会说到，就不说了。
最后是一个最小化的XHTML文档的例子。
参考：《HTML & XHTML权威指南》
Read more...
大多数情况下，创建XHTML文档和创建HTML文档没有什么区别。要创建XHTML文档，需要做和知道下面几件事情。
1、声明文档类型
为了能让XHTML浏览器可以正确地解析和显示XHTML文档，XHTML文档首先要声明文档类型，告诉浏览器创建文档所使用的XML版本。然后说明在文档中定义元素的XHTML DTD的版本。
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">这里使用的是过渡版的DTD。可以声明为严格版的DTD和过度版的DTD。
2、理解名称空间
XML DTD定义了任意数量的元素和属性名称。这些元素和属性名称都存储在DTD唯一的名称空间（namespace）中。浏览器在读取和解释文档时，会在名称空间中寻找这些元素和属性的使用方法，这样才能正确解释。
XML可以使用多个DTD，因此需要多个名称空间。在创建过渡版本的HTML文档时，如果要同时包含其他符合XML的元素，就要声明其他的名称空间。使用 xmlns（XML namespace的缩写）属性来定义一个或多个可供选择的名称空间。
XHTML文档中至少应该包含一个xmlns属性，以指定整个文档所使用的主要名称空间。
<html xmlns="http://www.w3.org/1999/xhtml">如果要定义其他名称空间，比如需要使用数学标记，可以再次使用xmlns来定义。
<html xmlns="http://www.w3.org/1998/Math/MathML>x2/X</div">这种情况下，与XML兼容的浏览器会使用http://www.w3.org/1998/Math/MathML名称空间来判断
标签是依据MATH版本来显示成除法等式，还一句XHTML版本来解释为层。
如果在每次都要显示为除法等式，那这样的xmlns定义效率就低了。更好的方法是在文档的开始处确定和标注名称空间，然后在需要改变的元素前标注一个前缀来调用。如：
<html xmlns:math="http://www.w3.org/1998/Math/MathML">现在math命名空间可以在随后的文档中简写成“math”，如：
<math: div>x2/X</div>绝大多数XHTML文档都不需要定义多个名称空间，但应该知道和理解存在着多个名称空间。
3、XHTML比HTML严格之处
XHTML和HTML的最大区别是，XHTML格式良好。
3.1 正确地嵌套元素
就是必须按照打开标记元素的顺序关闭他们。这个很容易理解，不多解释。
XHTML有一个嵌套限制，如下：
<a>标签不能包含其他<a>标签。
<pre> 标签不能包含<img>、<object>、<big>、<small>、<sub> 或<sup>标签。
<button> 标签不能包含<input>、<select>、<textarea>、< label>、<button>、<form>、<fieldset>、<iframe> 或 <isindex>标签。
<label>标签不能包含其他<label>标签。
<form>标签不能包含其他<form>标签。
3.2 结束标签
就是每个宝航其他标签或内容的标签都必须有对景的结束标签。这个也很容易理解，不多解释。
3.3 处理空元素
对于空白标签使用空格加斜杠的格式来表示，如<br />。这个也很容易理解，不多解释。
3.4 区分大小写
XHTML严格区分大小写，使用小写字母定义所有的HTML标签和属性。其他大写或混写标签和属性都不符合规范。
3.5 引用的属性值
所有属性值必须加上双引号。
3.6 明确的属性值
在XHTML中，每个属性都必须有一个值。没有只的属性必须使用自己的名称作为值。例如checked=”checked”。
3.7 处理特殊字符
对于在文章的Javascript和CSS声明中使用的< 和&字符，XHTML要严格的多。因为XML浏览器会简单地删除掉文档中所有<!--和-->中的注释内容，所以隐藏的焦痕和样式表将被删除。虽然可以将脚本放在CDATA中，但旧的浏览器不认识，也会将脚本忽略。所以推荐将脚本和样式保留在外部文件中，然后在文档中使用适当的外部链接来调用他们。
此外，在XHTML中，属性值中的特殊字符一定要用对应的实体。例如&一定要写成&。大于号和小于号一定要写成<和>等。
3.8 id和name属性
id和name属性都用来允许为文档中的任何元素关联一个标识符，以便可以被超链接或脚本调用或使用。
XHTML给id属性非常高的优先权，所以建议使用id属性来绑定文档中的元素。弱国必须要在某个标签中使用name属性，最好在其中也加入相同的id属性。
4、XHTML 1.1
XHTML1.1是以XHTML 1.0的严格的DTD开始的，在这个基础上进行了修改。1.1版本消除了所有不赞成使用的元素，以及仍在web上得到广泛使用的说哦有浏览器扩展。
要注意两个地方：第一，lang属性已经从每个元素中去除，应该使用 xml:lang属性；第二，name属性已经从<a>和<map>中除去，应该使用id属性。最后1.1标准定义了一组新的元素，称为“ruby”文本的印刷功能。这个我没见过，也没怎么弄清楚怎么使用，以后再说明。
以上就是XHTML使用需要知道和注意的地方，其实和HTML区别不大。
至于是否需要和应该使用XHTML，这个已是大势所趋，显然。网上关于web 2.0的介绍和讨论中经常会说到，就不说了。
最后是一个最小化的XHTML文档的例子。
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/TR/xhtml1" xml:lang="en" lang="en"> <head> <title>Your document title</title> </head> <body> ...your content goes here... </body> </html>
参考：《HTML & XHTML权威指南》
Read more...
Subscribe to:
Posts (Atom)
