CSS的定义 所有的单独字体样式一定要编辑在CSS式样表里，出现以下情况你需要使用标记<style>来声明你的样式，而且最标准的做法是添加type=”text/css”这个属性值，而且把所有的这种样式定义代码放到<head>标记之中进行预处理。因为如果你放到body去定义样式的话，有可能会出现样式没有被处理或加载的现象。一般什么情况需要使用这种定义方式呢？第一种情况是你需要定义一些只有单个文件有效的样式，比如id选择器的样式，单页面标记空间位置定义样式这些典型的样式都可以采用这种方式去定义。第二种情况就是你希望通过后加载来改写一些公用样式的行为。正如前面提到的那样，这种定义方法能够让某些公用样式在当前页面变面。在<style>标记中使用@import标记第二种引用方式如下:<styletype=”text/css”> @import“css/sample”;</style>代码2.18在<style>标记中使用@import标记引用样式文件当然使用这种方法引入的话，<style>标记也应该放到<head>标记里面去管理。实际上，@import标记还能够使用在css文件的内部，这样可以造成css文件的相互调用，不过值得注意的是:1)小心交叉调用的情况。就是文件1调用文件2，同时文件2调用文件1。这种可是死循环，所以后果大家可想而知。在css文件内部使用@import标记时，必须放到文件的最开始，否则会失效。就是你要先import完所有需要导入的css文件，之后才开始去定义你自己的选择器。javascript模块化我们编写了一个dojotest.mydojo.helloworld方法。注意，方法的前缀必须是dojotest.mydojo，就是文件的路径和文件名，然后才到您需要定义的方法名字。这样命名是为了防止重名。因为在一个大项目里面，不同模块都会有很高几率出现同名方法，dojo意识到这点，所以建议大家用长名字的命名规则，而且这样页面的维护人员也可以很方便地找到方法的存储文件，方便维护。本
规范
编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载
适用于UI界面的
设计
领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计
和制作过程，暂为试行，不排除有修改或增删的可能，实际应用时，本着严格遵守，但也要机动灵活的原则，活学活用，具体情况，具体分析。规范包含5个方面的约束：1.用户界面设计2.目录结构3.原型（XHTML）4.样式表（CSS）5.脚本（JS）用户界面设计1.Logo设计中使用矢量格式，并禁止使用描边效果，注意Logo应用场合的多样性。2.文本颜色与背景色要有强烈对比，以便于阅读。3.每一个界面都要设计明确而清晰的导航。目录结构1.首页命名为index.html2.建立Theme目录，样式的组织以“主题”为单位，默认在Theme目录下建立Default目录，和默认样式相关的文件都放在这个目录下,其中样式相关的图片要单独建立一个Pic目录，放在Pic目录里。如果系统有多套皮肤，则为每套皮肤建立目录，与Default目录同级，以主题名称来命名，下属目录结构与Default相同。如下图所示：网页在引用样式时，只需调用Import.css，其它的样式通过Import.css来调用，即：Import.css只包含对其它样式的引用；同时建立Global.css，包含对全局标签的样式定义；其它的样式表，则要具体情况具体分析，但总的原则是：按功能模块来划分样式表的构建，比如系统有3个（表现形式上差异很大的）主要模块，则除建立Import.css和Global.css之外，还需要对每个模块建立单独的CSS文件，每个CSS文件包含对所定义模块的标签的具体样式定义。3.建立Js目录，在Js目录下建立Common.js，包含在页面中涉及的全局函数或事件，至于是否建立其它JS文件则视具体情况而定。4.建立Files目录，将一些页面图片（划入内容的范畴，与主题无关）和其它的一些相关文件（如需用户下载的文件）放置到此目录下。5.建立Library目录，这个目录倒并非系统必须，如果你用DW编辑网页，则最好利用此目录建立库文件（相当于ASP中的Include文件），方便原型的维护；程序员也可以直接将此目录下的文件拿走做Include代码文件。原型1.所有的页面都应该声明文档类型，如下所示：<!DOCTYPEhtmlPUBLIC“-//W3C//DTDXHTML1.0Transitional//EN”“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”><htmlxmlns=”http://www.w3.org/1999/xhtml”>2.视具体情况，加入Meta标签（主要用于SEO）：<metahttp-equiv=”Content-Type”content=”text/html;charset=utf-8″/><metahttp-equiv=”Generator”content=”BXNA/V0.05a”/><metaname=”author”content=”LeXRus”/><metaname=”keywords”content=”aggregator,blueidea,xml,news,xhtml,css,webstandards,flash,aggregate”/><metaname=”description”content=”BlueideaXMLNewsAggregator.AggregatesYourIdeas.”/>3.使用Link链接样式表，如果是多主题，则用Link的rel来区分。4.在页面中载入js/common.js，然后在页面的底部调用InitPage函数。5.每个页面有唯一的H1，可以是这个页面的主标题。6.页面的XHTML书写要有良好的语义和可扩展性。为关键的和不可重用的区块儿定义ID，为可重复利用的区块儿定义Class。7.为Body定义ID，相当于定义了命名空间，多页面元素的多样化展示很有好处。8.按层级层层定义元素的显示，比如第一层命名为Area，第二层命名为Panel…9.命名按照语义命名，不允许出现Left,Red等诸如此类的命名，命名规则为大写第二个单词的首字母，如：userInfo。尽量使用全称，也可以按照约定缩写一些单词。10.页面的编码，如果只考虑中文应用，则采用GB2312，如果考虑到国际化应用，则采用UTF8编码。11.灵活应用H2,H3,H4,H5,H6，作为每一个区块儿的标题。12.为所有的原型界面做一个界面说明，包括每个原型界面的文件名和目录结构。样式表1.gloabal.css中包含全局标签的样式定义（包括body,h1,form,img,ul,ol,dl…）。2.在模块单独的样式表中，分2个区域，一个区域是IDSheet，一个区域是ClassSheet。其中IDSheet区域包含所有ID的样式定义，Class区域则包含所有Class的样式定义。3.对主要的样式加注释，必要时可用一定符合区分4.尽量减小样式表的体积，能缩写就缩写，比如可以写“color:#FFF”，就不写“color:#FFFFFF”。5.尽量不使用不符合规范的CSS样式，比如只有IE支持的CSS滤镜。6.样式表中允许在顶部写入作者的署名，和更新日期。7.关于如何使用CSSHack以让样式表适应所有的浏览器，请参见网上文章。脚本1.将页面中可能涉及到的JS函数都放在common.js中，方便维护。2.页面中也可以视具体情况引入其它的JS文件。撰写和执行设计规范，是一件让人头疼的事情。往往一个项目做到可以抽象出规范的时候，也是这个项目正在全力冲刺的时候，要不要抽出2到5天的宝贵工作时间，来写一堆貌似多余的文字，这是大家一直争论不休的问题，这可以总结成：“什么时候写规范？”。规范之所以让人觉得多余，最重要的原因是认真阅读并执行规范的人实在是太、太、太少了，大部分的规范要么就成了电脑里永不被打开的文件，要么就成了书架上落满灰尘的纸，这可以总结成第二个问题：“如何执行规范？”不过我们在讨论这两个问题之前，需要先搞清楚，“在理想状态下，规范有什么用处？”一、满足用户需要用户在使用产品的时候，总是凭着直觉去使用，不到万不得己，不会求助于所谓的“帮助系统”（如果这个产品有的话）。这一点在互联网产品上更加突出。而保持产品概念、界面元素、视觉风格的一致，能帮助用户：1、快速了解产品的运作方式。2、建立精确的心理模型。2、降低培训和支持成本。3、减少犯错误的概率。Shneiderman在1998年提出的“交互设计8项黄金法则”中的第一条，就是“力求一致性”，由此可见“一致性”在设计中的重要地位。“一致性”带来的最直接的好处就是：用户“认识”你的产品了。这种认识纯粹是一种主观的认识，用户可能没有认真想过这种“熟悉感”，只是隐隐觉得产品很亲切，很可靠。设计规范正是对所有元素的运行规则的一种提炼和抽象。因此，一份撰写完善的设计规范，能划出产品的正确轨迹，帮助产品在正常范围内运转。二、满足协作需要产品的设计和开发从来都不是由一个团队完成的。通常情况下，一个产品的最终交付环节是开发团队，而在实际工作中，这个环节甚至会具体到某个开发人员。这也就意味着，专注于功能逻辑的同事，很难也没有时间去理解并执行你在产品设计阶段中反复强调的概念、界面、视觉等因素，所以才有“最终产品只实现了当初设计70%”甚至更低的现象发生。另外，由同一个产品团队长期、持续地维护同一个产品的情况很少出现，一般的产品人员都同时兼顾多个项目，一个产品上线后，立刻转而关注其它产品。产品上线后的命运通常是交给运营团队或执行团队去维护，那些在设计过程中被反复讨论、验证过的设计思路，很难通过无声的界面传递下去，结果就是慢慢地变形。我曾经遇过几个产品设计师，在面试时展示自己的Web产品，一般都要强调一下：“我走了以后又改过版了，当初我的设计是……”。所以在团队协作方面，需要有一个载体，用来
记录
混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载
设计时的思路和规则，这个职责，也同样落到设计规范身上。三、提高团队效率创意是一件很累的事，不管是产品创意还是视觉创意。如果每一个界面、每一个功能，都要创建新的规则，那么从事产品设计这个工作的人恐怕很少能幸存下来。事实上，在创意过程中，我们对所使用过的东西都是茶壶煮饺子──心中有数的，但是这些“数”通常只存在于我们的潜意识里。把这些颇有价值的概念记下来并传达给其它设计人员，能避免大家做重复劳动。同时，发动同僚一起来总结规则，一方面可以节省他们的精力和时间，另一方面他们也能帮助你完善这些规则。这样的一个协作平台，也是通过设计规范来完成的。当然，以上这三点都是一个理想化的状态，我们姑且称之为“设计规范的理想”。为了实现这个理想，我们需要做的事情还有很多很多。从业这几年，自己写过的和帮人参谋的所谓“设计规范”不少了，这个东西大概在中国的决策层眼里是这么回事儿-一帮农民在一块田里种粮食，起先天气不错，土地肥沃，但是不久天气变差了，虫子多了，土地沙化严重，还有几个缺心眼的内鬼偷粮食，这下必须立定一个规范，挑头的告诉他们该在哪儿种，收多少麦子算合格，哪部分的地是留到下一季种的，种出什么样的麦子给奖金，偷懒不干活的怎么处理……但我理解的规范不是简单的把一个设计做成一个“行业套路”的量化指标，而是一个综合的品质评估的参考，甚至是一个设计能否面市的决定因素。为此，我们需要拟定一些表格，文档备案，图形参考，交互模板。同时，设计规范还要成为设计部门或者一个公司对于设计品质的共同价值观，让大家伙都知道这样做出来的是好设计，通过这样的规范教育和交流，形成对设计品质的统一认识。设计规范不是规定要做什么，而是提出这样做是正确的，但是有更好的地方可以改进。国外设计师管这种做法叫设计工具，是模板化应用的方法（stencil），我们称之为规范，更多的偏向于规则（regulation），却只学习到了量化指标的简单部分。说的严重点吧，我们中国人向来就特别擅长给自己搞个框架（紧箍咒），来约束人的作为与想法，可能有三个原因：1.我们不太擅长找到解决问题的严谨逻辑，甚至是已有现成教训的；2.我们始终缺乏对于团队成员之间的信任，哪怕是共同合作了多年的；3.我们的企业无法承担某些错误带来的后果，甚至是很小风险的。我们一开始就把一个工具性的东西变成了制度，因此问题便出来了。对于成长期的设计团队来说，建立设计规范需要的是确立一套可用工具，然后在工具的基础上发展成为部门设计品质建设的roadmap，如果只是弄个“导航按钮间距不得超过10px”这样的规范，就跟小时候尿尿要听到“嘘~~~~”声一样，尿得更快。我不是跟这儿扯谈，在我看来咱们现在行业里面瞧得见摸得着的优秀的设计规范不多，现在来说说，和大家交流一下：1.设计规范达不到预期效果的原因总是出现问题和错误后才开始拟定和修改规范，缺乏预见性；规范制定出来后，执行不到位，缺乏力度和奖惩措施，监督控制节奏拖沓缓慢；在产品设计过程中，不对设计规范做进一步的修订，甚至之前出现的错误也不去改正；完全教条的根据设计规范设计，比如有些团队做的还是通用设计规范，很多设计师就照着里面的要求重复设计类似的页面，类似的广告，类似的动画，完全豪无特色，没有差异化。-用心的话，你可以看看现在各个互联网产品的相似程度有多少？我不得不说，那些恶劣的设计规范要负一定的责任。2.设计规范最常见的错误让部门领导者制定设计规范-设计规范是共同讨论出来的，在迭代中改进修正，由于国内设计师大多数有“领导恐惧症”，因此这样的规范就算制定出来也是空头支票，甚至有不少领导是很少参与一线工作的。照搬国外成功团队的设计规范-这样的事情多半发生在喜欢“洋为中用”的设计团队中，国内外的设计环境差异很大，产品差异很大，面对的市场差异也很大，所以不要照搬，更不要直接翻译。把设计规范打印出来贴在座位旁边-这是“大字报”，还是“表决心”啊？从我认识的设计师朋友来说，经常看座位旁边的东西只有2种，一是日程表，二是检查手机电池是否充满了。3.设计规范的本质是做好人的工作在我看来，中国的企业只要是有设计部门的，做这个设计规范，最重要的是要和企业管理，团队文化建设绑定到一起，做人的发展建设工作。我们的设计师老实说没那么成熟，也没有过多的设计锻炼，整个不良的规范在哪儿杵着只会让设计师更加不愿意沟通-“有啥好聊的？不是有规范么，照着做就行了”设计部门如果真的沟通紧密，在设计过程中有共同价值观，这一个设计的流程是顺水推舟的，也是自然就形成的“规范”，不需要过多的文字描述。我还见过某些公司的设计规范中赫然写着：“一旦出现上述设计制作中A-C问题，设计师个人考评-5分”，OMG，原来你家的产品原来就值5分。4.优秀的设计规范要达到什么目的A.量化指标：确定一般可用性原则和审美常识下的避免犯错的方法，以及一旦出现错误后的补救
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
。规范的第一个目的是减少设计过程中出错的次数，一般这是针对新手设计师的，好的量化指标是告诉他经验，比如：建议html文件输出后在ie6,ie7,firefox,safari中做至少2次不同分辨率测试，并将结果添加到《设计规范-参考数据》中；而不是规定他方向，比如：根据产品部要求进行测试修改。B.确认设计关键点：获得该设计规范针对范围内的关键点，包括设计方向和设计元素，以通过项目设计的过程，达到团队成员的更加密切的配合效果。它是一份检验文件，记录过程中的错误，留作以后的经验。并在此可以做出项目和产品设计的里程碑。C.规范设计原则：这个原则有可能是针对单个项目的，也有可能是整个设计团队的指导原则，这个原则要被反复强调，反复实施，团队人员要共同为这个原则负责，比如：“确保在任何项目结束时间前4小时，完成设计输出”，“绝不允许设计粗糙的界面方案，如下图所示说明：XXXXX”等。D.设计规范本身也需要可用性：描述同一个设计要求，可以说：“S级设计师针对该项目phase1部分工作，可控时间不超过2.5循环周期，输出交付件供ISO000459号程序评审”；但这样描写，能够明白的人会更多“界面设计师XXX设计该项目界面高保真原型，需在10个工作日内完成，5月22日下午14：00在5号会议室评审”。千万不要把事情搞复杂，能把事情做简单的人是伟大的，设计规范也是如此。建立规范的目的是信息的有效传递：先举个例子，同事去买烟；“哥们，帮我带瓶水回来。”结果这个新来的同事帮我带了瓶矿泉水回来。而如果是老同事的话，一定会给我带一瓶可口可乐回来。事情的原因在于我没有清楚的说出，我要的是什么。可能规范的目的，就是避免这样理解错误的发生。从最开始的一段就可以看出，如果只是为了快速的开发，那么最需要的是开发人员间的配合，而非规范。有些时候，这些规范反而会影响到开发人员个人的开发效率。虽然在理想的状态下，规范可以帮助建立默契，但是规范往往是在第一代或者是某一代开发人员默契的配合下形成的，这个先后的关系在很大的程度上制约了规范在这个已经形成的团队中来发挥这个功能。结合上两段表述的内容，规范真正要建立的不是本身开发人员中的默契和快速开发，而是为了建立一个传承。让后来的人能在应用种快速的和原来的队伍形成一种默契。甚至可以有这样一种理解，如果一个规范被推出以后，而且比较合理，成为真正的规范，对于后来的人来说，按照这个规范来作事情，可以节省很多的思维时间。在这里，规范才真正体现了其快速开发的意义。由此可说规范是必须的，在一定程度上，两个人之间传递的信息，往往会因为个人的习惯不同而产生不同理解，规范在很大程度规范了表达的方式，使得不同习惯的人之间的沟通的信息更加有效。当然，这如果扩展到了两个团队之间，一个团队的规范，可以帮助其他的团队按照这个团队之间的沟通方式快速的组建起来，这更是规范在宏观上的意义。规范必须是细化的可执行的：去年我们分管编辑部分的高层给下面一个操作规范，上面写的东西是，编辑要尽量多的添加该频道的资料，资料要尽量的于频道的核心有关系，资料要尽量的对用户有帮助。看到这个规范，我的第一个反应是想痛打他一顿。诚然，这些都没有错，但是确是完全没有办法执行的，因为所说的所有东西，每个人都有不同的理解；因此，这个东西只能是一个规则或者是原则，拿给编辑部的主管（当时没有）看看还成。但是拿个普通编辑就……。一个成文的规范，必须是没有理解歧义，并且是完全的可以执行的规范，如果在任何一个角度，这个条目可以细化下去，那么必须将它细化下去，否则规范在给新人看的时候，他们依然会按照自己的理解去细化这个规范，理解上难免就会有所偏差，起不到传承的目的。规范的建立是团队的作品：现在建立规范的方法，往往是一个团队种某个领导人的思路，当然，这可以使得规范文件迅速的形成，但是副作用就是，这个规范文件很可能被尘封。第一点原因是，建立规范的领导是往往是按照自己的习惯建立规范的，这个是不是符合多数人的习惯是一个问题。第二点是按照正常的理解，领导的能力往往是比被领导的人是要强的，其建立规范的时候往往是很难考虑员工的理解能力和在这样条件下的发挥能力。第三点也是最重要的一点是一个人建立的规范，就很难是完全合理的，虽然领导是比较有权利的，但是在这些不合理的地方存在的时候，员工们看待这样规范时的厌恶感情，要求领导必须时刻注意才能推广这样的规范，尤其是在新人进入的时候，而领导往往不是这么有时间来作这样的事情。所以规范应该是一个公司第一代或者是某一代员工默契配合，
工作总结
关于社区教育工作总结关于年中工作总结关于校园安全工作总结关于校园安全工作总结关于意识形态工作总结
的结果。而并不是什么人强制下去的结果。当然，在有一个合理规范的时候，对于后加入的员工，这个规范能很好的起到传承前一代员工思想和协作的工具。什么样的规范形式更适合网站产品？在以往的软件产品上，因为系统的庞大，也因为版本更新不能过于频繁，我们经常会制定非常系统和完整的“应用规范系统”，以保证不要因为一些小的问题经常去要求用户对产品进行更新。通常我们会在“制定和形成规范”的环节花费大量的时间和人力，而且由于整个规范系统会很庞大和繁杂，往往在规范的执行上成本很高而且效率很低。到最后我们经常发现：所谓的规范系统就是一个摆设，为开发库添加了一堆多余的信息而已。网站产品的迭代过程很短，更新和反复很快。将以往软件产品上的规范做法直接拿到这里后，我们发现维护和更新规范的成本要远远高于其带来的协作效率。这也导致了一些早期用软件开发方式制定界面应用规范的互联网企业，都相继放弃了这个工作环节。但这不能说明界面应用规范在网站上就失去了意义，准确的总结应该是说“软件产品的规范形式在网站产品上很不适用”。于是，我们需要寻找更加适合网站产品的界面应用规范的表现形式和方法。在网站产品上规范的形式要更加自由、更加低成本，应用上要更加的方便简单，越华丽的形式反倒越不利于后期的应用。另外，如果是一个迷你型团队，我建议你把规范作的越简单越好。比如我曾经有一个规范只是建了一个文件夹，里面有各种场景下的不同界面和一个”*.txt”文件。文件的内容是这样的：1、所有通用的二级展示页面，布局规则参考“news.jpg”；2、所有警告类的弹出窗口参考“xxx.jpg”3、…当然，这样的“规范”其实只是一两个设计师之间的“设计备忘”。一般的中型团队还是需要一个简单的大概几页纸的示范文档作为规范记录。.4、网上有很多人公布的界面规范，我看到了很多形式和很多不同方式的内容，可我们团队人很少没有时间整理这么多的东西，而且有些我还不理解是什么（比如，“情感化设计规范”是什么意思？）。怎么办？不办。别管他们的叫法和形式。动手作你认为对的，然后不断完善和调整。只要动手作了，就会有好处。什么都还不了解的时候不要试图作一个“博识”，选择作一个实战者你的老板会更喜欢你。和在IM加好友一样，看到别人那么多分类不知道自己怎么分的时候就别分，人多了再分，再调整。没有万能的规范和准则，只有最适合你的。那就是你自己慢慢“修炼”出来的。.5、工程师对于界面上的很多东西往往并没有设计师那么敏感，经常和设计的差别很大。特别是一些“小问题”，比如在我们设计师看来18的行距和22的行距有着天壤之别，但他们无所谓。这个时候怎么办？（合理来说，你的界面制作人员应该在设计团队而不是开发团队）首先，必须自我检查一下。“我的界面规范是不是太复杂太多，给工程师在应用的时候增加了太多成本？”。然后，想办法让你们的规范简单再简单，应用起来方便更方便。比如，不要用太多的文档“写规范”，而用图片“画”规范，把间距等等问题标示在图片上，让工程师更容易“阅读”。比如，把你的网站规范写成HTML的，把元素的代码放出来方便工程师直接拷贝，减少应用成本。（如这里的第二种方式）。再后，如果你的规范足够简单，应用足够方便。再去和工程师进行更多的沟通，看看是不是他们现在打心理根本还很小视重视界面的问题。还不行，把实现的效果和设计效果对比给他们看。同时请你的老板帮忙督促。.6、我们公司只有我一个设计，从交互到美工全活。没有规范行不行？不行。1>就算是你一个人，时间长了没有一个被记录在案的“规则”，你的设计一样会乱。可以考虑让规范的形式简单更简单（如只留一个PSD文件或者TXT文件说明），但不可少。这个事情很简单，别偷懒。2>规范不只是为了今天看的，后面的设计执行、以后产品的维护和优化都需要用到。3>作为设计师要养成良好的工作习惯。图形用户界面(GraphicUserInterface)如Windows是以图形界面方式操作的，因为你可以用鼠标来点击按钮来进行操作，很直观。而DOS就不具备GUI，所以他只能输入命令。GUI是GraphicalUserInterface的简称，即图形用户界面，通常人机交互图形化用户界面设计经常读做“goo-ee”，准确来说GUI就是屏幕产品的视觉体验和互动操作部分。GUI是一种结合计算机科学、美学、心理学、行为学，及各商业领域需求分析的人机系统工程，强调人—机—环境三者作为一个系统进行总体设计。这种面向客户的系统工程设计其目的是优化产品的性能，使操作更人性化，减轻使用者的认知负担，使其更适合用户的操作需求，直接提升产品的市场竞争力。GUI即人机交互图形化用户界面设计。纵观国际相关产业在图形化用户界面设计方面的发展现状，许多国际知名公司早已意识到GUI在产品方面产生的强大增值功能，以及带动的巨大市场价值，因此在公司内部设立了相关部门专门从事GUI的研究与设计，同业间也成立了若干机构，以互相交流GUI设计理论与经验为目的。随着中国IT产业，移动通讯产业，家电产业的迅猛发展，在产品的人机交互界面设计水平发展上日显滞后，这对于提高产业综合素质，提升与国际同等业者的竞争能力等等方面无疑起了制约的作用。GUI准则减少用户的认知负担保持界面的一致性。满足不同目标用户的创意需求用户界面友好性图标识别平衡性图标功能的一致性建立界面与用户的互动交流1.3.定义术语定义： 效果图：由界面设计人员设计的页面效果图，综合了概要设计的业务需要和整个站点的风格，它规定了页面布局上的每个细节。 容器：即HTML标记的嵌套结构，如在表格->行->单元格内放置图片，那么可以认为单元格是放置图片的容器。 样式表：即级联式样式表CSS，它是W3C机构在HTML标记语言上扩展的格式语言。非标准交互控件：是通过标准控件组合、扩展等方法以提高特定业务执行效率而进行封装的控件，或概括为用户根据以往的*作经验不能够直接领会出*作方式的交互控件。 2. 界面设计规范细则 总体目标 以规范作为基本原则，在此框架内进行合理的扩展和变化，将站点内的每个模块服从于整个站点，模块页面与“高内聚”的控制代码紧密的结合在一起，同时对应于应用程序基于系统的架构分析。 2.1.通用原则 1.界面色彩要求：计算机屏幕的发光成像和普通视觉成像有很大的不同，应该注意这种差别作出恰当的色彩搭配。对于需用户长时间使用的系统，应当使用户在较长时间使用后不至于过于感到视觉疲劳为宜。例如轻松的淡彩为主配色，灰色系为主配色等等。切忌色彩过多，花哨艳丽，严重妨碍用户视觉交互。 2.界面平面版式要求：系统样式排版整齐划一，尽可能划分不同的功能区域于固定位置，固定的格式，方便用户导航使用；排版不宜过于密集，保留一定的“留白”区域，减轻查看时的视觉疲劳。 3.数据显示集中原则：各种列表在页面中往往是传递信息的核心，尽量集中的表现出来，并提供必要的关联数据、表等恰当的组织起来，并且在视觉上使用户很容易察觉数据之间的关系，并方便查看、编辑等；冗长拖沓的数据组织形式可能给用户带来非常低的维护效率。 4.主次分明原则：页面中同时分布较多栏目的情况下，按照页面（Flow）的伸展方向，即由上到下，有左到右，根据浏览的方向，重要的内容应该在左边最易注意的位置，导航等置于页面头部固定位置。使导航等重要内容始终处于用户的视野（Sight）之中.页面右边一般是一些当前页面主要*作的扩展、选项等内容。5.变化（对比）原则：在页面主体内容部分往往有很多文本信息，它是需要用户认真阅读的部分，只在文本字体、色彩上增加格式的变化，如加粗、下划线、行前导符、链接文本的不同状态定义（link\hover\visited）等，就可以将冗长的文档、表格等组织的很有条理；冗长的内容“层次“就有了变化，更容易辩识(Readable)；在美学角度增加了相临部分间的对比。 6.页面留白：页面留白同时也是一种增加可读性（Readable）的方式。在文字区域防止用户读完一行无法定位下一行的位置的麻烦，在整体布局上，它可以减轻用户的视觉疲劳。 7.即时响应原则：每一个交互动作应该能够马上看到*作的结果，并且用色彩、文字粗细、闪烁、弹出、页面布局的明显变化等突出方式告知用户。 8.鼠标最短距离移动原则：交互按钮控件等根据执行前后关系及表单中状态的控制等合理的组织起来。 2.2.显示（版式）设计 1．页面布局基于表格Table建立完全符合设计效果图。2．文字容易阅读。行间距、字体大小等通过样式表统一控制。3．页面链接根据不同功能、不同状态用不同颜色、状态标志，增加页面层次。4．基于表格Talbe的布局（Layerout）控制，便于控制实现不同分辨率下的适应，和页面上下方向的自动扩展；表格作为控件“容器”规范外观和规格，不同页面中的行列分布基本一致。5．使用样式表修饰页面表格Table,如表格单元格、背景，表格内字体等，方便今后对于整个站点的维护和扩展。6．页面分组页面查询区域、数据列表、详细信息、编辑区域等根据不同功能分组，所在区域主题（Title）标注该区域的名称，类似功能页面间布局保持一致。7．建立数据表格关系包含数据的表格使用户在视觉上理解相互间关系，如序列、父子表等。8．页面留白页面有明显留白区域，且不同群组之间距离保持一致。9．分辨率适应页面布局以保证在低分辨率[800*600]下的正确显示为前提，适应高分辨率情况使用表格宽度等参数使用百分比方式自动适应；a) 控件控制 1 第三方服务器端控件的使用要保证具有广泛兼容性和安全性，且具有完备的接口指定外观属性和交互方式。2 复杂的应用程序中非标准交互控件给出详细的*作方法的提示。3 页面中尽量使用统一的导航类型，如使用基于点击“图形”的链接、“文字”的链接或文字图形混合其中一种方式。 举例： 4、页面按钮作为基本交互控件，提倡使用有鼠标响应状态变化和禁用状态的BUTTON按钮，除特殊界面需要，不提倡使用图形按钮，而且保证同一应用程序内只使用一种外观的按钮。5、拖放的服务器端控件在页面表格 Table 里在执行过程中不能破坏页面原布局。如.NET中CANLENDAR控件建议在弹出的子窗体内独立使用。6、包含数据的表格使用中没有数据的情况有文字标注[无**数据]]，表头字段名用区别于数据行的格式显示。7、分栏目的主题名称使用用户容易理解的，以用户第一人称角度的命名方式，减少生硬的称谓给用户带来的不友好感。8、B/S应用程序允许含有类似拖放*作的非标准交互控件，但是需增加*作的说明。 b) 表单控制 1、页面内部有必要的前后文帮助信息，将页面主要任务目标、注意事项等描述在表单前申明，便于用户及时获得导引。2、页面在交互控制中添加完整的状态控制，*作中灰显特定组合的控件来实现用户的准确*作，及时的刷新表单中遗留的数据。3、表单内任务无关的信息、较少使用的选项等可以通过DHTML技术、服务器端控件的隐藏等减少用户*作中的干扰因素。4、表单内在特定的字段域附近给出必填信息提示，并用醒目颜色标注，提醒用户注意，验证的错误提示要给出准确恰当的指导；为提高用户填写的效率，建议使用客户端验证；复杂逻辑的验证使用服务器端验证。 5、信息显示过滤可能出现的用户不能识别的HTML特殊字符。6、表单中用户在交互过程中保证用户方便的切换编辑、浏览状态，方便用户用最快的速度获取需要的信息，提高*作效率。7、经常使用的工具按钮（如新增、编辑等功能按钮）保证在页面经单向拖曳浏览后，不需来回拖曳滑竿即可*作；长页面可以考虑页首、页尾均放置工具按钮。8、主详细表及父子表关系的查看方式使用联动式导航到下级数据，即点选主项目或父项目记录时系统自动查询并显示出关联的详细信息、子表数据，无需点选任何按钮。 c) 窗体控制 1.使用具有广泛兼容性的javascript控制客户端交互和简单导航,，除服务器控件部分自动扩展到客户端的Jscript外，程序员手动控制脚本不推荐使用Jscript和VBscript。2.*作过程中有清晰分界的子任务使用弹出窗体实现，保证完成后向主任务窗体返回必要的结果，及时刷新主任务窗体，使用户看到*作完成的结果，并且通过控件获取焦点等措施突出显示该结果。3.弹出窗体的页面主题、栏目标题（Title）等资料与关联的父窗体保持上下文一致，方便用户理解并做出处理策略。4.采用框架结构的应用程序，要充分考虑不同分辨率下的自动扩展，不同框架之间同步通讯及时，方便用户快速切换目标导航，观察数据之间的关系等。5.窗口主题显示标志用户当前所在模块或子系统名称，子任务窗体主题使用“动词+名词”的语法结构指明用户当前的任务； 2.5.输入设计 1、高效率的输入方式，特定的字段内容的输入方式选用使用效率最高，不容易发生错误的方式。如录入日期使用用户点选弹出的日历控件，并无须干预的自动返回正确的格式。2、方便的获取到必要的信息，无须用户记忆中间结果。3、表单格式尽量保持业务原始票据的格式或字段排列顺序，方便用户的集中录入过程。4、表单字段左对齐。5、输入控件的宽度基本符合数据库能够容纳的宽度，暗示系统能够接受的字符容量。 2.6.提示信息 1.错误*作的提示信息使用非专业的、易理解的名词告知用户。2.以第二人称“你”或“您”称呼用户，强调用户的主导能力。3.对用户宽容的语气。4.严重的警告信息使用弹出信息框提示，不严重的在页面前后文处直接输出，弹出不宜太频繁的使用。5.可能对系统导致破坏性的*作要给出警告信息和用户确认（Confirm）按钮，用户可以取消*作，防止意外的错误*作造成损失。6.复杂步骤在完成后给出完成成功的提示。 2.7.出错处理及出错画面的转向 1.系统的内部状态变化对于用户有较大影响的情况，给出用户明显的解决方案提示，或给出自动的导航，使用户快速的恢复工作状态。2.例如用户SESSION过期，用户无法进行*作时，系统自动跳转至登录界面。3.提供应用程序级错误截获，在不可预见的情况下仍给用户告知当前情况。4.提供页面间自动导航控制[Flow Controler],以更宽容的方式接受用户*作，协助用户处理复杂的交互任务。1.1．UI设计规范的作用接触UI设计这么长时间下来，很明白UI并不仅仅体现在界面设计上，更大一部分是关于可用性的设计。而现在我觉得我所完成的UI设计规范的作用更多的是在提高公司各项目的产品化，而这一点也跟我们老大的期望保持一致（因为我们公司前一代的产品线在界面上实在是太不统一了），作为整体解决方案的不同部分，我觉得界面的规范统一从另一个方面也能提供用户的界面学习性，同时在外部宣传上也是一大优势。（呵呵，说白了就是一个产品化规范，当然相对于公司落后的基础还有很长一段路要走）2．UI设计规范的可用性（可执行性）白鸦的文章里面提到了很多对于规范可用性的思考，这也是我最近在考虑的一个问题。虽然现在规范出台了，项目组也都收到了，但是在后续的跟踪过程中却没有看到任何改善的痕迹。其实大家都明白，开发人员往往只关注功能的实现，而没有按照规范设计界面的习惯。所以在和经理的交流过程当中，他有提到规范因强制而成规范这个观点，而规范文档也需要提高其一定的规范性来保证执行。不过，经理和我都认可一种理想化状态：就是如果能够在开发前期按照具体规范设计完所有界面，而程序员只需要负责具体的功能实现。但是，以后的升级修改的时候谁来保证呢？如果是这样的话，UI设计规范的目标读者是不是只是针对界面设计人员呢？3．UI设计规范的细化程度也许和我现在所处的项目都是基于Windows平台的C/S系统有关系，所以我对于界面的认识往往主要集中在Windows窗体上。看到白鸦文后附的那么多规范示意，有些东西我在写规范之前有做过，但是最后编写规范的时候发现意义不大。比如工具栏的间距，比如消息框的结构，这可能和公司采用Windows的标准相关吧。
浙公网安备 33021202002483