设计界面的十二条简单的原则

误区：除了游戏等少数需要炫耀外观的软件之外，大多数软件的界面设计其实并不等同于通常意义上的平面设计。
应当说，要描述和展现用户界面设计方案，最直观的方法就是把界面的样子画出来(类似 Visio里的用户界面绘制功能)。在程序员看来，白板或稿纸上的一张界面示意图往往就能说明所有问题。不过，当我们需要在不同的开发环境中交换设计方案，或是要管理和检索界面设计文档的时候，图片信息就不如格式化的文本信息那样方便了。为此，人们陆续设计出了许多“用户界面描述语言”。利用这些语言，我们可以像编写程序那样“编写”用户界面。比如说，Delphi 中用来描述窗体特性*.dfm 文件，其中的文本内容就是一种相当不错的用户界面描述语言。与其他描述性语言类似的是，用户界面描述语言也有标准化和 XML 化的倾向。迄今为止，人们已经提出了AAIML、AUIML、XIML、XUL、UIML 等一系列基于 XML标准的用户界面描述语言
①W3C 正在制订的 XForms 标准
②也是 XML 家族的一员，它很可能成为未来设计和开发Web 用户界面的核心技术之一。

 

非界面设计专业人员设计界面可以参考的几个基本原则
(1)在用户界面好看不好看的问题上，“东施效颦”的做法通常比“推陈出新”更为有效。
这很容易理解，一个在窗口布局、色彩搭配、字体风格等方面处处模仿微软 Windows 的程序员虽然很少能享
受到艺术创新的快感，但他开发出的软件却总是有着和Office 或 IE 一样“好看”的界面。
(2)主窗体布局
主窗体是图形用户界面的核心。主窗体中有菜单、工具栏、对话框、客户区、状态栏等各式各样的界面元素。对普通程序员来说，安排这些界面元素的规则只有一条：
如果在流行的商业软件（特别是微软的软件）中找不出你使用的布局方式，那么千万别犹豫，赶快否定自己的
设计吧。
(3)控件排列
一定要整齐，任何不整齐的用户界面都不是好界面。窗口和对话框中的所有控件都必须整齐排列
(切忌:滥用 GroupBox 的界面)
(4)窗体留白
如果窗体边缘或窗体中的某个区域有大量空白，那你就应该重新考虑窗体的大小和控件的排列方式。
很多程序员喜欢在窗体（特别是对话框）的四边留下大量空白。这种“宽边”窗体事实上很不招人喜欢。仔细
看一下 Office 等商业软件中每个对话框的边缘设计，边缘紧凑、线条简洁才是今天的主流风格。
一些懒惰的程序员习惯于简单地从上到下或从左到右摆放控件，而不顾及这种做法会在窗体中留下多少空白区
域。那些简单地把控件由上至下排列，结果在右上角留下大量的空白，一眼看上去整个对话框有向
左倾斜的趋势（这种左重右轻的错觉在平面设计中可以被归入视觉心理学的研究范畴）。
(5)主菜单
把菜单项按逻辑关系组合在一起。菜单的层数不要超过两层。
合理安排菜单项对于软件的最终用户来说非常重要。
很多用户使用软件时，都是依靠菜单而不是联机帮助来熟悉每一项软件功能的。一般来说，菜单的编排都有业界的标准或惯例
(6)工具栏
确保工具栏中所有按钮都可以对应到主菜单中的某个菜单项。
这个原则的重要性在于，如果在主菜单找不到工具栏里提供的某项功能，用户就只能用鼠标来触发该功能了。；
(注意:如果你一定要用汉字来注明按钮的功能，可以使用用更规范的做法ToolTip 提示)
(7)图标
没学过美术就不要自己画图标。只要不侵权，使用别人的劳动成果既能省力，又不会出差错。
用户界面中的许多元素，比如菜单、工具栏、树形图、列表框都可以配上图标。现在网上有很多免费的图标库可供下载，那些无处不在的老面孔（比如磁盘、打印机、望远镜这样的图标）更不会引发什么版权纠纷。
不过，使用图标要有统一的风格，千万别混用不同风格、不同类型的图标。
(8)上下文菜单
这里的上下文菜单是指点击鼠标右键后弹出的菜单。
上下文菜单的内容一般和鼠标点击的对象相关。设计上下文菜单的注意事项和设计工具栏类似：
把最常用的、与特定对象相关的操作放在上下文菜单中，同时，确保这些操作也可以通过主菜单实现。
[注意]很多程序员爱犯这样的错误：
只在上下文菜单中提供与特定对象相关的操作，主菜单和工具栏都不再重复提供这些功能。这么做的后果是，如果用户不知道鼠标右键可以打开上下文菜单，那就永远也找
不到这些功能了。很显然，上下文菜单只是用户操作方式的一种，在用上下文菜单为鼠标操作开辟绿色通道的同时，我们也应当利用主菜单为键盘操作提供方便。
(8)字体
只使用最常见的，或是用户点名要用的字体。
既然不是专业的平面设计师，我们程序员还是别在这方面卖弄为好。
最稳妥的方法是：只使用“宋体”、“黑体”等常见字体，只使用 Windows 系统默认的字号大小。尽量少用斜体、下划线等修饰手段。当然，用户决定一切。当用户在字体方面有特殊需求（比如为了醒目起见加大某些文字的字号）时，我们当然应该照办不误了。
[常见错误]是字体和容纳该字体的控件大小不匹配，如输入框的大小和框内的字号相比差距过大
(9)色彩搭配
色彩搭配是一门很深奥的学问。如果你不准备深入学习相关的理论知识，那最好别在界面中使用和系统配色方
案差别太大的色彩。
WIN32 API 用 COLOR_BACKGROUND 、COLOR_BTNTEXT 等宏定义来表示系统缺省配色方案中
的每一种色彩，用户可以通过改变 Windows 外观来改变这些色彩组合。严格按照系统配色方案的要求使用这些色彩，可以保证界面中的色彩组合既符合 Windows 风格的要求，又能在 Windows 外观改变时与其他程序的色彩搭配保持一致。
如果你一定要用鲜艳的颜色（比如红色）来提醒用户某件重要的事情，那么记住，这些颜色用得越少越好——
如果不经专业技法处理，大面积的红色、绿色、紫色或者橙色都很容易让人产生视觉疲劳以及眩晕、恶心等不适症状。
(10)错误信息
笼统或技术性太强的错误信息只会让用户深陷泥潭。
当然，完全忽略技术信息又不利于专业人士对系统故障的诊断。
常见的做法是把技术信息记录在系统日志里，界面上只告诉用户“系统出现故障，请联系⋯⋯”。那些把友善的提示语和专业的技术信息结合在一起的做法也非常值得推荐：
(11)分辨率
用户的显示器可能在不同的分辨率下工作，你的软件界面必须能适应分辨率的变化。
有不少程序员开发的软件都只能在某种特定的分辨率（比如 1024×768）条件下保持界面的美观。许多
程序员为了省事，干脆就按用户通常使用的分辨率大小，把窗体中所有控件摆放到合适的位置。在大多数情况下，这种软件的用户界面非常整洁，可一旦用户改变分辨率，窗体中的控件就立即东倒西歪，有的甚至无影无踪了。
测试软件时，你做过分辨率方面的实验吗？你的软件界面（GUI 或 Web 页面）能在 Sony W 系列笔记本的超宽屏幕（1280×768）上靓丽如初吗？要是移植到联想天玑掌上电脑的袖珍显示屏（320×240）上呢？
从技术上讲，适应不同的分辨率，不过是要在响应每个窗体的 WM_SIZE 消息时，调整好相关窗体的大小。应
该说，这项工作并不十分困难，任何聪明、勤快的程序员都可以做得到。
(12)总结
上述的几条原则我个人认为还是很不错的,要感谢王咏刚先生的<<设计“好看”的用户界面>>,这都是他的,我只是转贴,呵呵.但希望对爱好编程的朋友有所启发.也希望大家都来总结一些好用的经验!