Yongwei Wu wrote:
>
> 做界面很烦、很枯燥，也很容易出错。在上面工作的自由软件开发人员似乎远远
> 不够啊。单靠成就感，帮助别人的满足感，和对自由软件的追求，还是……
>   
一方面说，在界面上肯下功夫的自由软件人员（未必是开发人员，很多易用性专家
并不直接开发）确实太少了。

另外一方面，一点题外话，谈谈界面设计。做界面很有挑战性，因此很有趣。这又
是一个黑客通常见不到的领域。如果真有时间，即使没有兴趣，我也推荐看一些这
方面的内容，比如Software For Use (Larry L Constantine etc)。主要是避免形
成界面简单的偏见。界面的理论和实际技术可以展现出很可观的深度；浅的方面看
每一个按键的位置和语言都充满了暗示和原理，深度地看，易用性专家可能认为整
个一个良好设计的界面的存在本身就是界面设计错误之一。

比较好的令人看到界面设计的深度的地方，是请实习生实际来参与设计，看看人家
是如何进行界面设计的分析过程的。通过分析学习知道为什么一种界面设计好，另
外一种不好（提示：好坏绝不是一个简单原则而非理论加实践能推出的）。

黑客不关心界面设计的原因用黑客的话说得不到点子上（即这项工作比较烦且似乎
没用），使用界面设计自身的理论比较能说到点子上，即对于黑客这一类特殊用
户，偏好对系统模型(System Model)一致的使用模型，建立了从系统模型考虑使用
模型的思维定势，因此无法胜任使用模型不同于系统模型的设计任务，尤其是使用
模型是近一步在业务模型上基于对其理解建模的，更是使黑客对用户模型的设计无
从下手。

上面的易用性理论如果听起来像咒语，那么考虑一下当一位黑客对易用性专家说：
“类型推导虽然要求变量、常量或操作符显示声明类型，但是这样彻底避免了很多
隐式转换时产生的不易观察到的程序错误，并且这些错误发生时，找出发生隐式转
换的位置也很麻烦；最后，有很多隐式转换占用大量资源，在程序中隐藏这一点不
利于优化性能。”这样的话会不会使易用性专家觉得你在说咒语？同样是说咒语，
同样是隔行如隔山，但是从来没有见易用性专家觉得黑客的工作没有意思或没创造
性的，倒常常是黑客觉得易用性专家的工作是没有创造性的。

我因为工作特殊和所有层面的IT相关人员打交道，不得不经常有这样的感受，即在
开发人员、系统管理员和客户支持人员最容易产生偏见，对自己的一行很了解，认
为自己那一部分是最为有深度的部分，其它人的工作都肤浅；而培训师、后端销售
代表、咨询师、客户经理等人甚少产生这种偏见。于是我有时候甚至觉得偏见产生
的程度和与人打交道的程度成正比，越是与不同性格的人打交道、与不同工作类型
的人打交道，越是能了解多个方面的深度和复杂度，反之则认为只有自己所在的领
域复杂深度。

所以觉得消除偏见的方法之一是走出去，真诚与各种人交往，尤其是和你完全不一
样的人。

上面说的工作的事，我觉得可以多少套用到开源领域，那就是自由软件、开源软件
开发人员常有知道的东西远多于知道的人的现象，从而使知道的东西蔽了眼睛，为
自己知道的束缚了眼界。

zhangweiwu at realss.com wrote:
> 我因为工作特殊和所有层面的IT相关人员打交道，不得不经常有这样的感受，即在
> 开发人员、系统管理员和客户支持人员最容易产生偏见，对自己的一行很了解，认
> 为自己那一部分是最为有深度的部分，其它人的工作都肤浅；而培训师、后端销售
> 代表、咨询师、客户经理等人甚少产生这种偏见。于是我有时候甚至觉得偏见产生
> 的程度和与人打交道的程度成正比，越是与不同性格的人打交道、与不同工作类型
>   
真是错词满堂，应为：“于是我有时候甚至觉得偏见产生的程度和与人打交道的程
度成反比”

2009/1/12  <zhangweiwu在realss.com>:
> Yongwei Wu wrote:
>>
>> 做界面很烦、很枯燥，也很容易出错。在上面工作的自由软件开发人员似乎远远
>> 不够啊。单靠成就感，帮助别人的满足感，和对自由软件的追求，还是……
>>
> 一方面说，在界面上肯下功夫的自由软件人员（未必是开发人员，很多易用性专家
> 并不直接开发）确实太少了。
>
> 另外一方面，一点题外话，谈谈界面设计。做界面很有挑战性，因此很有趣。这又
> 是一个黑客通常见不到的领域。如果真有时间，即使没有兴趣，我也推荐看一些这
> 方面的内容，比如Software For Use (Larry L Constantine etc)。主要是避免形
> 成界面简单的偏见。界面的理论和实际技术可以展现出很可观的深度；浅的方面看
> 每一个按键的位置和语言都充满了暗示和原理，深度地看，易用性专家可能认为整
> 个一个良好设计的界面的存在本身就是界面设计错误之一。
>
> 比较好的令人看到界面设计的深度的地方，是请实习生实际来参与设计，看看人家
> 是如何进行界面设计的分析过程的。通过分析学习知道为什么一种界面设计好，另
> 外一种不好（提示：好坏绝不是一个简单原则而非理论加实践能推出的）。
>
> 黑客不关心界面设计的原因用黑客的话说得不到点子上（即这项工作比较烦且似乎
> 没用），使用界面设计自身的理论比较能说到点子上，即对于黑客这一类特殊用
> 户，偏好对系统模型(System Model)一致的使用模型，建立了从系统模型考虑使用
> 模型的思维定势，因此无法胜任使用模型不同于系统模型的设计任务，尤其是使用
> 模型是近一步在业务模型上基于对其理解建模的，更是使黑客对用户模型的设计无
> 从下手。
>
> 上面的易用性理论如果听起来像咒语，那么考虑一下当一位黑客对易用性专家说：
> "类型推导虽然要求变量、常量或操作符显示声明类型，但是这样彻底避免了很多
> 隐式转换时产生的不易观察到的程序错误，并且这些错误发生时，找出发生隐式转
> 换的位置也很麻烦；最后，有很多隐式转换占用大量资源，在程序中隐藏这一点不
> 利于优化性能。"这样的话会不会使易用性专家觉得你在说咒语？同样是说咒语，
> 同样是隔行如隔山，但是从来没有见易用性专家觉得黑客的工作没有意思或没创造
> 性的，倒常常是黑客觉得易用性专家的工作是没有创造性的。
>
> 我因为工作特殊和所有层面的IT相关人员打交道，不得不经常有这样的感受，即在
> 开发人员、系统管理员和客户支持人员最容易产生偏见，对自己的一行很了解，认
> 为自己那一部分是最为有深度的部分，其它人的工作都肤浅；而培训师、后端销售
> 代表、咨询师、客户经理等人甚少产生这种偏见。于是我有时候甚至觉得偏见产生
> 的程度和与人打交道的程度成正比，越是与不同性格的人打交道、与不同工作类型
> 的人打交道，越是能了解多个方面的深度和复杂度，反之则认为只有自己所在的领
> 域复杂深度。
>
> 所以觉得消除偏见的方法之一是走出去，真诚与各种人交往，尤其是和你完全不一
> 样的人。
>
> 上面说的工作的事，我觉得可以多少套用到开源领域，那就是自由软件、开源软件
> 开发人员常有知道的东西远多于知道的人的现象，从而使知道的东西蔽了眼睛，为
> 自己知道的束缚了眼界。

几乎完全同意！

我个人的思考习惯也是从系统出发，从语言的结构出发，从程序的结构出发，从
逻辑和推导出发，而非从业务模型出发。结果就是，作了一些零零碎碎的贡献，
能写出很"好"的程序，但没有写出过一个大受欢迎的程序。不过，我多多少少地
认识到了自己的缺陷，而你的这个帖子也算是给这种情况做了个小结。

所以，现在老老实实，别人收集需求，我给别人做架构设计。 :-)

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/

其实我觉得一般用户是用不到在Writer里做小册子之类的吧，大家一般都没切纸机。。。出血这名词还真第一次听说。MSO里有这个功能么?知道的同学烦请指出，我没怎么用过MSO...

On 01/13/2009, Yongwei Wu <wuyongwei at gmail.com> wrote:
> 2009/1/12  <zhangweiwu at realss.com>:
>> Yongwei Wu wrote:
>>>
>>> 做界面很烦、很枯燥，也很容易出错。在上面工作的自由软件开发人员似乎远远
>>> 不够啊。单靠成就感，帮助别人的满足感，和对自由软件的追求，还是……
>>>
>> 一方面说，在界面上肯下功夫的自由软件人员（未必是开发人员，很多易用性专家
>> 并不直接开发）确实太少了。
>>
>> 另外一方面，一点题外话，谈谈界面设计。做界面很有挑战性，因此很有趣。这又
>> 是一个黑客通常见不到的领域。如果真有时间，即使没有兴趣，我也推荐看一些这
>> 方面的内容，比如Software For Use (Larry L Constantine etc)。主要是避免形
>> 成界面简单的偏见。界面的理论和实际技术可以展现出很可观的深度；浅的方面看
>> 每一个按键的位置和语言都充满了暗示和原理，深度地看，易用性专家可能认为整
>> 个一个良好设计的界面的存在本身就是界面设计错误之一。
>>
>> 比较好的令人看到界面设计的深度的地方，是请实习生实际来参与设计，看看人家
>> 是如何进行界面设计的分析过程的。通过分析学习知道为什么一种界面设计好，另
>> 外一种不好（提示：好坏绝不是一个简单原则而非理论加实践能推出的）。
>>
>> 黑客不关心界面设计的原因用黑客的话说得不到点子上（即这项工作比较烦且似乎
>> 没用），使用界面设计自身的理论比较能说到点子上，即对于黑客这一类特殊用
>> 户，偏好对系统模型(System Model)一致的使用模型，建立了从系统模型考虑使用
>> 模型的思维定势，因此无法胜任使用模型不同于系统模型的设计任务，尤其是使用
>> 模型是近一步在业务模型上基于对其理解建模的，更是使黑客对用户模型的设计无
>> 从下手。
>>
>> 上面的易用性理论如果听起来像咒语，那么考虑一下当一位黑客对易用性专家说：
>> "类型推导虽然要求变量、常量或操作符显示声明类型，但是这样彻底避免了很多
>> 隐式转换时产生的不易观察到的程序错误，并且这些错误发生时，找出发生隐式转
>> 换的位置也很麻烦；最后，有很多隐式转换占用大量资源，在程序中隐藏这一点不
>> 利于优化性能。"这样的话会不会使易用性专家觉得你在说咒语？同样是说咒语，
>> 同样是隔行如隔山，但是从来没有见易用性专家觉得黑客的工作没有意思或没创造
>> 性的，倒常常是黑客觉得易用性专家的工作是没有创造性的。
>>
>> 我因为工作特殊和所有层面的IT相关人员打交道，不得不经常有这样的感受，即在
>> 开发人员、系统管理员和客户支持人员最容易产生偏见，对自己的一行很了解，认
>> 为自己那一部分是最为有深度的部分，其它人的工作都肤浅；而培训师、后端销售
>> 代表、咨询师、客户经理等人甚少产生这种偏见。于是我有时候甚至觉得偏见产生
>> 的程度和与人打交道的程度成正比，越是与不同性格的人打交道、与不同工作类型
>> 的人打交道，越是能了解多个方面的深度和复杂度，反之则认为只有自己所在的领
>> 域复杂深度。
>>
>> 所以觉得消除偏见的方法之一是走出去，真诚与各种人交往，尤其是和你完全不一
>> 样的人。
>>
>> 上面说的工作的事，我觉得可以多少套用到开源领域，那就是自由软件、开源软件
>> 开发人员常有知道的东西远多于知道的人的现象，从而使知道的东西蔽了眼睛，为
>> 自己知道的束缚了眼界。
>
> 几乎完全同意！
>
> 我个人的思考习惯也是从系统出发，从语言的结构出发，从程序的结构出发，从
> 逻辑和推导出发，而非从业务模型出发。结果就是，作了一些零零碎碎的贡献，
> 能写出很"好"的程序，但没有写出过一个大受欢迎的程序。不过，我多多少少地
> 认识到了自己的缺陷，而你的这个帖子也算是给这种情况做了个小结。
>
> 所以，现在老老实实，别人收集需求，我给别人做架构设计。 :-)
>
> --
> Wu Yongwei
> URL: http://wyw.dcweb.cn/
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe at zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org


-- 
Notes:
1. Feel free to EMail me and I'll feel free to ignore you
2. Use English or STANDARD Chinese (Traditional preferred, but
Simplified is also acceptable), or I'll certainly ignore you.
3. Use plain text, because I've gotta no rich-text processing system.
4. CheungTiFan at gmail.com is the ONLY email account I'll check everyday.
Web: http://difan.org.cn/

cheungtifan at gmail.com wrote:
> 其实我觉得一般用户是用不到在Writer里做小册子之类的吧，大家一般都没切纸机。。。出血这名词还真第一次听说。MSO里有这个功能么?知道的同学烦请指出，我没怎么用过MSO...
>   
我不用MSO近五年了，在2004年开始停止使用它的。我的情报是：2004年以前，MSO
Professional Edition里的MS Publisher支持出血。

Yongwei Wu wrote:

>
> 几乎完全同意！
>
> 我个人的思考习惯也是从系统出发，从语言的结构出发，从程序的结构出发，从
> 逻辑和推导出发，而非从业务模型出发。结果就是，作了一些零零碎碎的贡献，
> 能写出很"好"的程序，但没有写出过一个大受欢迎的程序。不过，我多多少少地
> 认识到了自己的缺陷，而你的这个帖子也算是给这种情况做了个小结。
>
> 所以，现在老老实实，别人收集需求，我给别人做架构设计。 :-)
>   
向你请教一下： 如何能够锻炼自己 构架设计 的能力？

能不能在理论和实践等方面给我一些好的建议？
谢谢;p

2009/1/13 Kermit Mei <kermit.mei在gmail.com>:
> Yongwei Wu wrote:
> 
>>
>> 几乎完全同意！
>>
>> 我个人的思考习惯也是从系统出发，从语言的结构出发，从程序的结构出发，从
>> 逻辑和推导出发，而非从业务模型出发。结果就是，作了一些零零碎碎的贡献，
>> 能写出很"好"的程序，但没有写出过一个大受欢迎的程序。不过，我多多少少地
>> 认识到了自己的缺陷，而你的这个帖子也算是给这种情况做了个小结。
>>
>> 所以，现在老老实实，别人收集需求，我给别人做架构设计。 :-)
>>
>
> 向你请教一下： 如何能够锻炼自己 构架设计 的能力？
>
> 能不能在理论和实践等方面给我一些好的建议？
> 谢谢;p

这个问题很难，如果我的回答非常管用的话，也许我应该考虑去做培训师而不是
架构设计。:-)

从我的个人经验来说，也许可以考虑下面这些方面：注意细节，注意结构上的优
化，熟悉设计模式，消除代码复制，确保灵活性和可扩展性（你的代码也许可以
重构；你要改接口的话，和你合作的人会很痛苦），虚心听取别人的需求，写清
晰、"有用"的文档。

总的来说，这是实践的艺术。多看别人设计的好的架构，多看好的文档，多多练
习，也许是最有用的方法。

-- 
Wu Yongwei
URL: http://wyw.dcweb.cn/

Yongwei Wu wrote:
> 2009/1/13 Kermit Mei <kermit.mei在gmail.com>:
>   
>> Yongwei Wu wrote:
>> 
>>     
>>> 几乎完全同意！
>>>
>>> 我个人的思考习惯也是从系统出发，从语言的结构出发，从程序的结构出发，从
>>> 逻辑和推导出发，而非从业务模型出发。结果就是，作了一些零零碎碎的贡献，
>>> 能写出很"好"的程序，但没有写出过一个大受欢迎的程序。不过，我多多少少地
>>> 认识到了自己的缺陷，而你的这个帖子也算是给这种情况做了个小结。
>>>
>>> 所以，现在老老实实，别人收集需求，我给别人做架构设计。 :-)
>>>
>>>       
>> 向你请教一下： 如何能够锻炼自己 构架设计 的能力？
>>
>> 能不能在理论和实践等方面给我一些好的建议？
>> 谢谢;p
>>     
>
> 这个问题很难，如果我的回答非常管用的话，也许我应该考虑去做培训师而不是
> 架构设计。:-)
>
> 从我的个人经验来说，也许可以考虑下面这些方面：注意细节，注意结构上的优
> 化，熟悉设计模式，消除代码复制，确保灵活性和可扩展性（你的代码也许可以
> 重构；你要改接口的话，和你合作的人会很痛苦），虚心听取别人的需求，写清
> 晰、"有用"的文档。
>
> 总的来说，这是实践的艺术。多看别人设计的好的架构，多看好的文档，多多练
> 习，也许是最有用的方法。

达到艺术状态的东西往往都很难。我感觉构架的能力已经不单单是技术上的东西，而更
多的是我们应如何认识具体的业务，如何从一个过程中抽象出各种对象，并组织这些对
象之间的关系，尽量消除各个对象之间的多米诺骨牌效应，让可能出现的问题局部化。

唉，艺术上总是很容易理解，但是很难去实现，呵呵。

Thank you!