后天就是大年三十喽，传统意义上的新的一年就要来到了。也许八天长假也不是太长，不过我还是在这八天中计划好了一个不小的计划，那就是想去实现一个偷来的创意。

从去年开始工作以来一直希望能在工作中学到更多的知识，从团队中学到更多的经验，不过似乎这个愿望一直就没有真正的实现过，人人都在忙于完成的 自己工作而没有精力去学习和分享。不说别人，就算是我自己，也总是关注在如何去完成手头的工作而很大程度上忽略了学习。慢慢的，就觉得自己在工作中力不从 心了，出来混的，迟早是要还的。

去年年底公司的Trend Wish活动时，我的愿望”To have a better platform where Trenders can share their knowledge”被选为了最佳愿望之一。那时我也想过去建立怎么样的一个平台是一个最好的分享知识的平台。最先想到的是Wiki，所以就在自己机器上 用MediaWiki建了一个自己用的Wiki，但后来发现，作为一个协作平台Wiki是很好的，但作为知识分享平台，它存在不少的问题。最重要的一点就 是读者反馈非常的不直接，除了讨论页上可以讨论外，很难直接的知道自己分享的知识对别人是不是有用。作为读者，也难从大量的信息中找到对自己有用的信息。

最近，一个创意跃入我的脑海，我决定自己来搭建一个“我知道”的知识分享平台，这个创意其实是从豆瓣网 偷来了，在豆瓣上，大家可以分享“我看”（电影），“我听”（音乐），“我读”（书籍）等一系列的信息。我希望通过“我知道”这个平台，能让大家一起到上 面写下自己的知识，然后读者可以从中找到对自己有用的信息，并把这些信息进行记录，同时给发布者相应的反馈。虽然“我知道”这个平台与“百度知道”用了同 样的“知道”一词，不过我想他们是有明显的区别的，百度知道重在提问与回答，而“我知道”则是重在主动的知识共享。我也不知道是不是已经有成熟的平台可以 直接实现我这个创意，所以还是打算自己先按自己的想法实现一下试试效果。

由于自己对PHP的学习还是处在初级阶段，加上现有的条件也只有一个ASP空间，所以还是打算用非自由的ASP技术来实现我自己这个创意。如果 必要，可能会用到AJAX，不过这个技术我也还是不太了解，只是想尝试一下。风格上肯定会做得很朴素，就像豆瓣一样。功能上，也一定会是用迭代式的开发， 慢慢的去完善它。不过在设计上还是打算下一点功夫，争取可以有比较好的扩展性，也希望以后必要的时候可以移植成PHP重新实现一下。

添加了评论的功能。目前这个功能是针对每个页面来做的，在哪个页面上发表的评论就会出现在哪个页面上。所以如果要对文章评论，请进入相应文章的页面，不然就都堆在首页上了，谢谢合作，呵呵:)

工作一直紧张，但今天还是岔出了一件事情，就是对我负责的模块进行用户可用性测试。两个小时的测试还是有点收获，小记之。

刚刚从公司的培训课程中学到了”Usability Test”，没想到这么快就用到了实践中，虽然这次的可用性测试不是很正式的从公司外部请用户来做，也没有用单面透视玻璃对用户行为作“暗访”，但同样达到了一定的效果，找出了产品中的一些问题。

今天的测试是请用户按照产品的文档完成产品的安装和一个Kernel模块的安装。在写那份文档的时候，我已经自以为很充分的考虑了各种情况，为不同的用户，不同的场境进行了描述，原以为问题不会太大，没想到测试的结果很让我惊讶。

• 用户根本不看文档。如果作为一个有经验的用户，也许在拿到软件包时就是自信的打入./configure && make && make install来完成安装。原以为这次用户在我们强调了文档的情况下用户会看文档，结果用户还是没有看，只有在遇到问题时才会想到文档。准备了 README和INSTALL两个文档，原以为用户会看INSTALL，没想到用户总是喜欢挑短的README看，有详细步骤的INSTALL就不愿意 看。
• 当用户发现做不下去要看文档时，我们发现用户只喜欢看文档中列出的命令，而对于命令前后的解释性文字一率是视而不见。但用户有时又无法分辩到底他 看到的是句子还是命令。如果文档中列出的命令用户不熟悉，或者看不懂，他操作起来会很没有信心。用户有时无法区分”INSTALL”文件和”make install”这条命令中的install有什么区别。
• 用户无法看到文档中的重点，当大篇的文字出现在屏幕上时，用户无法找到文章中的重点，三位测试人员不约而同的对文档中对他们完全没有用处的一段文字表现出极大的“兴趣”。
• 用户不看屏幕的提示，屏幕用大写字母打出WARNING时，用户仍然不加思索的回答yes，继续有危险的步骤。
• 用户记不住自己做过的事情和屏幕上的信息，仅管文档提醒用户要记住一行提示，用户仍然不会去记它。
• 如果不在文档开始的地方提醒用户可以把文档打印出来看，用户想不到把文档打印出来放在手边。
• 用户对终端上出现的彩色的字符比较敏感，如果把上面那用户看不到的大写WARNING改成闪动的红色字符也许就很容易引起他们的注意。
• 如果用户在努力很久后，完成了安装过程，但产品却没有正常工作，用户会非常沮丧。
• 当用户第一次失败时，他会认为是自己的错误，如果连续两次失败，他会对产品失去信心。
• 如果用户的相关经验可以指导他直接完成任务，事情会很顺利。如果他的经验无法让他直接得到正确的结果，他完成任务的效率会比没有经验的更差。
• 用户如果不熟悉命令行，让他做命令行的操作会非常痛苦，给他命令依样画葫芦也没用。
• 用户希望文档可以步骤更清楚，而不一定要列出太多的信息。用户希望有Wizard形式的安装过程来代替文档。

其实当我列出这些条条来后，反而感觉不是那么惊讶了。这些不都是我们平时在用软件时的一些习惯吗？只不过怎么在做软件时真正把用户的这些体验设 计进去，真正做到以用户体验为中心的设计，这才是真正很难做到的。程序员总是在写程序时把程序的思路放进产品，而很难把用户的体验放进去。

实话说，我一直觉得自己在做程序时是很注重用户体验的，但经历今天的可用性测试才发觉，可用性和良好的用户体验存在于产品的每一个角落。以前我 总是太Focus在一些细节的地方，精确到每一个快捷键的设计、图片一个像素的位移这些很细微的角落，有时却忽视了整体上的可用性。

同时，可用性的实现，尤其是一些细节上的东西，往往会跟产品的开发周期和Schedule形成相互的制约，怎么在这种相互的制约下达到一个最好的平衡，也是一个要在实践中反复体会的话题。

意外的收到CSDN Blog编辑的邮件，建议我继续使用CSDN的Blog，并对最近CSDN Blog的改版给用户带来的不好体验进行了道歉，其实我搬家完全不是因为CSDN的改版，只是因为自由软件综合症的原因。但也许是被他的诚恳打动，也许是一种怀旧的情绪。我决定在主力经营自己的Blog同时，也保持CSDN Blog的继续更新。废话文章往自己那里贴，有点意思的文章两边贴。Live Spaces嘛，不想经营了。

鉴于对读者负责的态度，还是在VMWare中开了一下Windows看看这个页面在Windows IE中的效果。

结果发现字体难看，或者就是页面显示成为空白。前者是因为CSS有问题，我只是偷了人家一个CSS，没有加工就自己用了……后者是因为网页编码的问题，右键把编码设成UTF-8就好了，原因还不详，呵呵。

鉴定完毕，再次Ctrl+C，Ctrl+P，关机睡觉:)