布珞阁 ² » goodUI

ignore the code: Realism in UI Design

bruce — Sat, 23 Jan 2010 14:11:02 +0000

January 21, 2010

Realism in UI Design

The history of the visual design of user interfaces can be described as a gradual change towards more realism. As computers have become faster, designers have added increasingly realistic details such as color, 3D effects, shadows, translucency, and even simple physics. Some of these changes have helped usability. Shadows behind windows help us see which window is active. The physicality of the iPhone’s user interface makes the device more natural to use.

In other areas, the improvements are questionable at best. Graphical user interfaces are typically full of symbols. Most graphical elements you see on your screen are meant to stand for ideas or concepts. The little house on your desktop isn’t a little house, it’s «home». The eye isn’t an actual eye, it means «look at the selected element». The cog isn’t a cog, it means «click me to see available commands».

Details and realism can distract from these concepts. To explain this, I’ll take a page from Scott McCloud’s «Understanding Comics», a book which should be required reading for all designers.

The image on the left is a face of a specific person. The image on the right is the concept «face»; it could be any person. When designing user interfaces, we rarely ever want to show a specific entity; typically, we want to convey an idea or a concept. Details can easily distract from that idea or concept.

At the same time, it’s obvious that some details are required. Too few details, and the user won’t recognize the idea at all.

The circle on the left clearly shows a face. The circle on the right isn’t recognizable as a face anymore.

Let’s look at a symbol we actually see in user interfaces, the home button. Typically, this button uses a little house as its symbol.

The thing on the left is a house. The thing on the right means «home». Somewhere between the two, the meaning switches from «a specific house» to «home as a concept». The more realistic something is, the harder it is to figure out the meaning. Again, if the image is simplified too much, it’s not clearly and immediately recognizable anymore.

The thing on the left is a home button. The thing on the right might as well be an arrow pointing up; or perhaps it’s the ⇧ key.

Let me explain this concept using an entirely unscientific graph:

People are confused by symbols if they have too many or too few details. They will recognize UI elements which are somewhere in the middle.

The trick is to figure out which details help users identify the UI element, and which details distract from its intended meaning. Some details help users figure out what they’re looking at and how they can interact with it; other details distract from the idea you’re trying to convey. They turn your interface element from a concept into a specific thing. Thus, if an interface element is too distinct from its real-life counterpart, it becomes too hard to recognize. On the other hand, if it is too realistic, people are unable to figure out that you’re trying to communicate an idea, and what idea that might be.

The button on the left is too realistic. The button on the right does not have enough details to be immediately recognizable as a button.

The same applies to these toggles. Shadows and gradients help the user figure out what he’s looking at and how to interact with it. Adding too many details, however, ends up being confusing. The toggle switch is no longer just a toggle switch that is part of a user interface, it is clearly recognizable as a photograph of a specific toggle switch; it loses its meaning. It’s no longer a symbol, it has become a specific thing.

An Exception

There is at least one specific area where more details are good: Application icons. You want your icon to depict one specific idea: Your application.

Coda’s leaf isn’t a representation of the idea of a leaf; it’s a very specific leaf, the Coda leaf. Acorn’s acorn isn’t just any acorn, it’s the Acorn. Adding details moves these images from a generic concept towards a specific entity, and in the case of an application icon, this is exactly what you want.

Conclusion

Graphical user interfaces are full of symbols. Symbols need to be reduced to their essence. This helps avoid cluttering the user interface with meaningless distractions, and makes it easier for people to «read» the symbol and figure out the meaning of an interface element. Realistic details can get in the way of what you’re trying to communicate to your users.

The goal is not to make your user interface as realistic as possible. The goal is to add those details which help users identify what an element is, and how to interact with it, and to add no more than those details. UI elements are abstractions which convey concepts and ideas; they should retain only those details that are relevant to their purpose. UI elements are almost never representations of real things. Adding too much realism can cause confusion.

Thanks to Max Steenbergen and Cameron Kenley Hunt for helping me form a coherent opinion on this topic.
The second house icon is from Dellustrations’s icon set «Dellipack».

If you require a short url to link to this article, please use http://ignco.de/240

If you see a typo, a spelling mistake, an error, or any other issue, please tell me about it by opening a case in my issue tracker or by sending me an e-mail.

If you feel like reading something else, may I recommend:

zz:Microsoft Expression 2

bruce — Thu, 31 Jul 2008 10:12:51 +0000

忍不住，用Cyberarticle快速发布了个界面赏析，参见

原文:http://tinyurl.com/6q7m9k

微软匆忙出了这个Expression 2

感觉没啥变化，没想到微软现在出个产品都变得如此毛糙

很明显是3套不同框架实现的

Bland、Design、Encoder是.net实现的简单UI框架

Media不知道买的谁的，还不如以前的Office里面的一个图像管理工具

而由Office里面的FrontPage改过来的Expression Web则被改得跟陀屎一样，很明显是个半成品，为了改界面，改成黑的，框架还是Office2003/VS2005的风格，主程序外观非要改得像Office2007，又不像，Vista风格？

一个字乱

不过封面还是蛮好看的。

Bland

Design

Encoder

Media

Web

XSetup

TopMost窗口中ListView控件的Tooltip被主窗口隐藏的问题解决

bruce — Sun, 04 Nov 2007 02:32:42 +0000

C# Winform中发现。

窗口中的listview控件，如果设置了ShowItemToolTips=true

鼠标移到Item上时显示Item的Tooltip。

如果窗口topmot属性，会发现tooltip不显示了，原因是窗口会置顶，把tooltip遮住了，而不是隐藏。

解决的办法其实也很简单，拖一个ToolTip控件到窗口上，设置一下

toolTip1.SetToolTip(listView1, “caption”);

即可解决了。相当于自绘了个ToolTip窗口，样式可以随便改，取代了系统自身的Tooltip，而且父窗口是Topmost的窗口也不会被盖住。

结论: C# Winform就是这么easy

WEB中的多选

bruce — Fri, 04 May 2007 15:29:32 +0000

html中的select控件multiple属性似乎是为程序员偷懒而设计，
目前用户提出质疑后，再仔细推敲,确实这种多选交互方式不可选。
虽然程序实现起来方便，但对于一个只会点超链接的浏览者，让他拖选，或者按个ctrl键多选，实在是要写太多的操作说明：

而改用下面的复杂方式实现，确实加大了不少代码逻辑，但对于熟悉Window操作的gui用户实在是方便很多

Windows界面设计标准

bruce — Fri, 02 Feb 2007 06:34:19 +0000

1.1. Windows 界面设计标准

1.1.1 . 易用性

 界面元素的名称、标签应该易懂，用词准确，避免使用模楞两可的字眼，要与同一界面上的其他元素易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作作。

 disable 而不是not visible。

 完成相同或相近功能的按钮用GoupBox框起来，常用按钮要支持快捷方式。

 完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。

 按功能将界面划分局域块，用GoupBox框括起来,并要有功能说明或标题。

 界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。

 界面上首先应输入的和重要信息的控件在Tab order中应当靠前,位置也应放在窗口上较醒目的位置。

 同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。

 分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab

 默认按钮要支持Enter选定及鼠标选择操作，即按Enter后自动执行默认按钮对应操作。

 可写控件检测到非法输入后应给出说明并能自动获得焦点。

 Tab 键的顺序与控件排列顺序要一致，总体遵守从上到下，同时行间从左到右的方式。

 复选框和选项框按选择几率的高底而先后排列。

 复选框和选项框要有默认选项，并支持Tab键选择。

 界面空间较小时使用下拉框而不用选项框。

 选项数较少时使用选项框，相反使用下拉列表框。

 专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

1.1.2 . 规范性

 通常界面设计都按Windows界面的规范来设计

 小型软件可以不提供工具栏。

 常用菜单要有命令快捷方式。

 完成相同或相近功能的菜单用横线隔开放在同一位置。

 菜单前的图标能直观的代表要完成的操作。

 菜单深度一般要求最多控制在三层以内。

 工具栏要求可以根据用户的要求自己选择定制。

 相同或相近功能的工具栏放在一起。

 工具栏中的每一个按钮要有及时提示信息。

 一条工具栏的长度最长不能超出屏幕宽度。

 工具栏的图标能直观的代表要完成的操作。

 系统常用的工具栏设置默认放置位置。

 工具栏太多时可以考虑使用工具厢。

 工具厢要具有可增减性，由用户自己根据需求定制。

 工具厢的默认总宽度不要超过屏幕宽度的1/5。

 状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息，如果某一操作需要的时间较长，应该显示进度条和进程提示。

 滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。

 状态条的高度以放置五号字为宜，滚动条的宽度比状态条的略窄。

 菜单和工具条要有清楚的界限;

 菜单要求凸出显示，这样在移走工具条时仍有立体感。

 菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。

 右键快捷菜单采用与菜单相同的准则。

 如果菜单和按钮将使用户进入一个新的界面，则在标签文本之后加上三句点的省略号 “…”

1.1.3 . 帮助设施

 系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

 帮助文档中的性能介绍与说明要与系统性能配套一致。系统作修改时，相应的帮助文档也应该保持同步更新。

 操作时要提供及时调用系统帮助的功能。常的热键是F1。

 帮助要有即时针对性，在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。

 最好提供目前流行的联机帮助格式或HTML帮助格式。

 用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。

 如果没有提供书面的帮助文档的话，最好有打印帮助的功能。

 在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

1.1.4 . 合理性

 屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

 父窗体或主窗体的中心位置应该在对角线焦点附近。

 子窗体位置应该在主窗体的左上角或正中。

 多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。

 重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。

 错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。

 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。

 对可能造成数据无法恢复的*作必须提供确认信息,给用户放弃选择的机会。

 非法的输入或*作应有足够的提示说明。

 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。

 提示、警告、或错误说明应该清楚、明了、恰当。

1.1.5 . 美观与协调性

 界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

 统一色调，针对软件类型以及用户工作环境选择恰当色调。

 长宽比或宽长比接近黄金点比例，切忌长宽比例失调。

 布局要合理, 不宜过于密集，也不能过于空旷，合理的利用空间。

 相邻或同组的按钮大小相同，同界面上所有的按钮高度相同。

 按钮的大小要与界面的大小和空间要协调。

 避免空旷的界面上放置很大的按钮。

 放置完控件后界面不应有很大的空缺位置。

 字号的大小要与界面的大小比例协调, 字体大小根据系统标准字体来，例如 MSS字体8磅，宋体的小五号字(9磅）五号字（10.5磅)。

 使用正规字体，中文采用标准字体 “宋体”，英文采用标准 Microsoft Sans Serif，不考虑特殊字体(隶书、草书等,特殊情况可以使用图片取代)，除非是需要艺术处理或有特殊要求的地方。

 前景与背景色搭配合理协调，反差不宜太大，常用色考虑使用Windows界面色调。

 如果使用其他颜色，主色要柔和，具有亲和力，坚决杜绝刺目的颜色。Graphtalk程序建议以下按钮的风格：

 “确定” 按钮文本颜色设为深蓝

 “取消” 按钮文本颜色设为深红

 “帮助” 按钮文本颜色设为深绿

 大型系统常用的主色有”#E1E1E1″、”#EFEFEF”、”#C0C0C0″等。

 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。

 有标准的图标风格设计，有统一的构图布局，有统一的色调、对比度、色阶，以及图片风格。

 底图应该融于底图，使用浅色, 低对比，尽量少的使用颜色。

 鼠标光标样式统一，尽量使用系统标准。

 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。

 对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

 如果需要缩放对话窗，建议以下方式调整每个控件的attachment属性：

 不必变宽的控件，如按钮、静态文本等、采用左上锁定，右下不锁定。

 数据控件，如编辑框、下拉框等，尽可能排放于每行的最右边，采用左上角锁定，右边弹性粘附，

 多行式控件放置于界面最下面端，采用左上右下角全部锁定；

 通常父窗体支持缩放时，子窗体没有必要缩放。

 如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

1.1.6 . 菜单

 菜单位置按照按功能来组织。

 菜单通常采用“常用–主要–次要–工具–帮助”的位置排列，符合流行的Windows风格。

 常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。

 下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。

 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。

 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，次要的放在后边。

 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。

 菜单深度一般要求最多控制在三层以内。

 对常用的菜单要有快捷命令方式，组合原则见6.1.8。

 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。

 菜单前的图标不宜太大，与字高保持一直最好。

 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。

 主菜单数目不应太多，最好为单排布置。

1.1.7 . 独特性

如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

 安装界面上应有单位介绍或产品介绍，并有自己的图标。

 主界面，最好是大多数界面上要有公司图标。

 登录界面上要有本产品的标志，同时包含公司图标。

 帮助菜单的 “关于” 中应有版权和产品信息。

 公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

1.1.8 . 键盘快捷方式

在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快，在Windows及其应用软件中快捷键的使用大多是一致的。

菜单中：

 面向事务的组合有:

Ctrl-D 删除；Ctrl-F 寻找；Ctrl –H替换；Ctrl-I 插入；Ctrl-N 新记录；Ctrl-S 保存 Ctrl-O 打开。

 列表:

Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。

 : 编辑:

Ctrl-A 全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消*作；Ctrl-Y恢复*作。

 文件操作:

Ctrl-P 打印；Ctrl-W 关闭。

 系统菜单

Alt-A 文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。

 MS Windows 保留键:

Ctrl-Esc 任务列表；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用；Enter 缺省按钮/确认操作；Esc 取消按钮/取消*作；Shift-F1 上下文相关帮助。

 按钮快捷键

可以根据系统需要而调节，以下只是常用的组合。

Alt-Y 确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。

这些快捷键也可以作为开发中文应用软件的标准, 但亦可使用汉语拼音的开头字母。

1.1.9 . 安全性

在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路, 并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

 排除可能会使应用非正常中止的错误。

 应当注意尽可能避免用户无意录入无效的数据。

 采用相关控件限制用户输入值的种类。

 当用户作出选择的可能性只有两个时, 可以采用单选框。

 当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。

 当选项特别多时，可以采用列表框，下拉式列表框。

 在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。

 对可能引起致命错误或系统出错的输入字符或动作要加限制、屏蔽和处理。

 对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。

 对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。

 对错误操作最好支持可逆性处理，如取消系列*作。

 在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的*作。

 对可能造成等待时间较长的操作应该提供取消功能。

 与系统采用的保留字符冲突的要加以限制。

 在读入用户所输入的信息时，根据需要选择是否去掉前后空格。

达梦数据库的界面设计

bruce — Wed, 20 Dec 2006 15:17:47 +0000

达梦数据库管理系统(DM)是起步最早的基于关系模型的国产数据库管理系统，经过达梦人二十多年来的努力，DM的功能和性能日臻完美。一个好的产品总是全方位发展的，在被许多软件同行忽视的界面设计方面，DM经过不断的摸索和沉淀，形成了自己独特的风格。

DM产品的界面设计背景
DM属于通用软件，与用户业务需求明确的应用软件不同，在通用性方面要求严格，设计应满足大部分用户习惯。DM又是系统软件，和Office、杀毒等软件不同，他的用户有特殊的知识背景。系统本身实现的复杂性及用户的特殊性决定了界面设计的特殊要求。
为在不同OS上提供数据服务，DM采用了跨平台设计，服务器使用标准C开发，并有着标准的控制台交互界面，如交互式工具isql，备份、恢复工具等,使用这些命令行工具和字符交互界面就可以完成所有系统功能。DM也遵循SQL标准和业界编程标准接口实现了各类开发接口；为了简化用户操作，DM提供了图形化的客户端工具，采用java技术做到了图形化工具的跨平台；同时，也提供了远程管理web客户端。

图1. DM用户界面结构图

在早期版本开发过程中，开发组将重点放在功能实现、性能提升上，在用户体验方面投入略为缺乏，经常因界面细节的忽视导致用户无法接受产品。对产品的循环造成很不好的影响。随着产品的成熟，产品化工作逐步被重视，DM在界面方面逐步加强，不但有了稳定的客户端团队也有了自己的UI团队，根据用户的需求共同改善DM的界面。

由谁来做界面设计？
界面设计怎样做才能做好？由谁来做？在产品开发中，这一直是一个棘手的问题。
程序员做界面往往喜欢按个人的喜好实现一些怪异的界面，随意的堆砌控件，东拼西凑找些图标来做装饰，并在对话框上写上各式各样的提示信息。这样做出的界面可想而知。这时不少人把期望放在美工头上，但即使有了美术人员参与，艺术手段绘制的界面实现起来繁杂，做出的东西确华而不实。同时，开发者和美工之间相互工作不理解，沟通也相当成问题。
DM团队认为，界面设计本身是门学问，不是简单的技术实现和艺术加工就可以做好的，它需要一个复合型的团队来共同完成。在产品设计阶段就相当重视。由专人制定界面标准，开发组明确分工，专人分析用户体验提出明确需求，由开发者实现。

如何做好界面设计？
1. 确定统一的标准
首先，遵循业界界面标准，制定界面设计规范，每类窗口、控件的大小、字体、布局、对齐、字体、用词表达等各方面都加以约束，各类有经验人员参与定制过程，充分考虑了用户、实现、美观各方面因素。有了统一的设计规范和检验标准，最终界面的一致性才得以保障，绝大多数让人费解的界面缺陷得以回避。
规范中要求尽量遵循操作系统的界面标准，减少自定义控件，一来可以降低用户学习成本，二来可以减少代码维护量。使团队能将大多数精力集中在功能实现上，而又可以做出符合用户习惯的专业界面。像DM这样的系统软件，客户端的开发人力占比例相对较少，而客户端功能繁多，往往一个人负责多个客户端模块，如果没有易于维护、易于测试、统一的界面标准，很难做出可用性高，又易于使用的客户端工具。
一开始达成共识后，需求人员、开发人员、美术人员之间的配合自然就默契很多。当然，有了标准还不够，标准的执行上，还是需要项目监督和控制、界面测试等各种机制，DM参考CMMI标准展开的软件过程改进工作正为此提供了保障。

2. 设计良好的结构
客户端设计方面，DM团队充分遵循分层和复用的原则，将界面层与其他层分离，小组内可做到分工明确、易于维护。界面的调整尽可能少的影响其他模块，因此，DM的新客户端能同时提供基于SWING和SWT的实现，并能提供WEB远程交互方式。

3. 因用户体验而改变
基础工作做好以后，再根据功能考虑用户使用习惯，考虑易用性，总体原则是保证用户最高效的完成操作。一方面参考同类产品好的设计思路，另一方面内部模拟用户使用场景，加强用户体验的测试，寻求最合理的操作方式。同时注意收集用户的反馈，让界面层开发人员了解用户使用习惯。例如，以往的客户端，大部分用户使用总觉得很慢，又很另类。经过分析，这是客户端基于SWING框架实现造成的，客户端界面的迟钝造成用户对服务器性能的怀疑，和ＯＳ风格的不一致，大家才会对产品的美观品头论足。当时以保证跨平台界面一致性选用SWING，像Oracle一样维护自己风格的界面库，但实际用户证明，基本上很少有用户同时使用Windows、Linux等不同的操作系统，保证不同平台下的界面一致反倒不如让客户端和操作系统风格一致。因此小组在新客户端开发上大胆的选用基于 OS native实现的SWT改造客户端，显示速度，用户感觉上有了明显改善。

4. UI设计师的参与
UI设计团队，并不能简单的定位为美工，这也是DM没有外包UI设计，而是选择自己培养的原因。UI设计师的艺术修养和表现手法固然重要，但如果他对产品特点、用户群体不深入了解，就很难做出能留下印象的设计。
DM这种系统软件不需要花哨的界面，但其中的图像元素必须能让人迅速领悟，任何摆放在界面上的图像都不能光是花架子，必须有其含义。这样对UI设计师要求就很高了。DM的UI设计师除了需要知道美术基础知识、通用的软件GUI知识以外还必须具备基本的数据库知识、开发实现原理，同时他还必须是DM的高级用户。
UI设计师在规范制定阶段，针对用户群的心理特点、产品的特征，定义整体的风格、配色表，同时设计典型元素图像，一开始就保证了他们在风格（色调、绘制手法、视角）上的一致。
例如，依据DM这种企业级软件给用户第一眼感觉应该是稳重、可靠，所以色调应该偏灰暗，不抢眼，不疲劳。DM标志性图像也是依据数据库的象征图形演化而来，充斥在各种插图、图标、印刷品、网站上，给人一目了然，整体一致的感觉。

图2. DM的典型元素

有了各种标准，配套的网站、产品包装、宣传资料的设计就有了目的性，产品也就有了统一的形象，才能给人留下专业的印象。
总结
只有有了配合默契的团队，高效的工作方式，才能快速做出一致的交互界面。产品被用户接受后，才能去研究用户的使用习惯，进一步优化界面设计。进行下一阶段突破。
界面设计作为DM产品化工作的重要组成部分，和用户文档工作、用户教育工作、技术支持工作一起为DM用户更便捷、更高效的使用DM高级功能提供了保障。
DM的下一代产品DM v5.6提供了更高级的功能特性，更智能的性能优化，客户端界面上在效率、表现方式、整体风格等各方面也有了更大的提高。2007年敬请期待。

首发《程序员》杂志 http://dameng.org/p/21
短时间逼出来文字，软文不好写呀，要写到不被骂又能看出点名堂又字数限制，可真的很难

在线翻译工具(小白翻译)

bruce — Sun, 19 Nov 2006 16:53:35 +0000

背景：

google translate非常不错，用统计法，但老是开网页麻烦。
词霸2007也出来了，不想装那么大个。
google.com上的语法：fy 词语也不是经常出来，来自Dr.eye
还有soffmm

早上一起来，就想做这个程序，居然折腾了一天，用最快的方法写出了这个东东：

个人感觉挺有意思。操作上特别留意了使用方便性

下载地址：http://oldsoft.com/mysoft/2006.11.19.translate/translate.1.1.zip

解压后47K　绿色环保，还可以加公益

老树新花,邮件精灵垃圾过滤

bruce — Wed, 06 Sep 2006 10:28:01 +0000

Frank兴致一来，给邮件精灵加上了垃圾识别功能。自动将规则匹配的垃圾标志为删除

使用的LUA外部脚本解析。

试了一下，挺管用，尤其是对付英文垃圾，当然规则还不完美，这个lua脚本自己可以改，也可以在以后的程序中自动添加规则。

点这里下载精简版

虽然我推崇所有邮件转发到gmail，然后用gtalk做桌面通知。

但邮件精灵可以解决一些没有垃圾过滤、没有转信功能的企业邮箱辅助。

是POP3+SMTP，快速预览邮件，快速回复邮件。就这

这曾经是我用MFC玩弄GUI的巅峰之作啊。现在老了。