[转] WEB设计准则

字号：大 中 小

Web设计介绍

规则：设计者不是用户。

规则：用户不是设计者。

规则：为共性设计，但应该考虑差异。

规则：站点的运行应该接近没有错误。

规则：了解和注意Web及因特网媒体的限制。

规则：适当的时候，Web站点应该遵守GUI原理。

规则：导航系统只不过是达到目标的手段。

规则：外观会显著影响用户开始对站点的价值判断。

规则：站点的综合印象分受外观、内容、技术、可用性及用户满足程度的综合影响。

规则：不要用界面去打造品牌。

规则：没有一种“正确”的Web设计符合所有的站点。

规则：控制权应该给予或至少看起来给予了用户。

规则：所见即所想（WYSIWYW）。

Web设计进程

建议：在设计之前尽可能地收集站点内容。

规则：外观设计应该采用自顶而下，从主页到子页，最后是内容网页。

建议：在开发外观组合图时，一定要考虑浏览器窗口的边界效果。

规则：和原型设计保持距离。倾听用户并润色设计。

规则：站点总会存在一些问题，好好测试你的站点。

规则：测试应该设计站点的各个方面，包括内容、外观、功能和目标。

规则：用户测试是最重要的测试形式，不要在最后才进行。

规则：站点开发是一个持续的过程：规划、设计、开发和发布，如此周而复始。

为用户设计

定义：可用性是指在特定的使用环境下，一个站点可以被一组用户有效、高效且满意地实现某个目标所能达到的程度。

规则：不存在关于什么是可用的站点的绝对观点。可用性在用户访问站点时会有很大的变化。

规则：可用性依赖于使用的媒体。

规则：可用性依赖于站点的类型和用户对它的熟悉程度。

规则：可用性和用户满意度是直接相关的。

规则：浏览器不使用网站。使用网站的是人。

建议：不存在一个共性的人。始终设想是一个真正的人在访问你的站点。

建议：不要将具有相似色调的文本、图像和背景色一起使用。

建议：不要将具有相似饱和度的文本、图像和背景色一起使用。

规则：保持较高的对比度。不要将具有相似亮度的文本、图像和背景色一起使用。

建议：避免使用繁杂的背景图案。

规则：确信用来区分条目（如链接体）的颜色在两个方面有显著的差别，如色调和亮度。

规则：用户试图以最小的工作量取得最大的收益。

规则：识别比记忆容易，因此不要强迫用户记住信息。

规则：不要使访问过和未访问过的连接具有相同的样式和颜色，这样会强迫用户记住是否曾访问过这个链接体。

建议：既然形象记忆较容易，那么将那些需要记住的网页做得看起来和其他网页不同。

建议：把相似的选项限制在5~9个。

建议：只寄希望于用户能记住三个连续的项目。

规则：用户所愿意等待的时间正比于他所能得到的回报。

规则：当响应时间如网页加载超过30s时，试图给用户提供你自己的反馈信息如加载进度条。

规则：时间对用户来说比下载的字节数更重要。

建议：在用户的思考时间里预加载，可以提高Web网页的响应时间。

建议：在访问线型结构的网页时，使用预加载。

建议：如果网页上的元素不同，就让它们有明显差异。

建议：尽量限制同一网页上的干扰因素，把网页上不和谐的对象分开，以免它们在视觉上相互干扰而用户不能专注于他们感兴趣的内容。

规则：感觉适应确实也在Web上发生。如果想得到用户的完全注意，必须经常显著改变这些事物。

规则：尽量优化站点中所有网页的键盘优化访问，而不仅仅是形成网页。

规则：在连续的选择之间，尽量缩小鼠标移动距离。

规则：尽量减少在屏幕的主要活动区和返回按钮之间的鼠标移动量。

规则：保证可点击区域的足够空间，以便于用户的快速移动和精确点击。

建议：始终要记住，需要把站点带入用户的世界，而不是别的地方。

规则：考虑用户访问站点的可能环境的措施。

建议：创建具有自适应能力的站点是为了满足新手、中间级和高级用户的需求。

建议：如果不能设计自适应的用户界面，那么就为一般能力的用户设计。

规则：用户把过去的关于世界、软件和Web的知识带到站点。必须让站点符合他们的期望。

规则：不要偏离主流站点确定的通用界面规则。

建议：尽量早地且经常性地与用户一起测试。

建议：在进行不严格的可用性测试时，尽量避免谈得太多或引导用户。

建议：不要让可用性问题成为削弱或避免站点的其他方面如外观、技术或经济的借口。

建议：实践“拉斯韦加斯”式的Web设计。为用户提供一个振奋的仿佛有无数选择的愉悦体验，但应该始终严格地控制局面。

网站类型和体系结构

定义：公共网站点、因特网站点和外部网站点，或者一个简单的Web站点并不明显地仅仅限于特定类型的用户。

定义：一个企业内部站点通常运行在专用网上而不是因特网上，它是特定组织的专用网络。

定义：企业外部网站点通常只能为一部分用户访问，但可以通过公共因特网访问。

定义：交互站点是该站点用户能够直接和站点内容或该站点的其他用户进行信息交流。

定义：静态站点的内容是相对固定的，其他用户是不能影响他们浏览数据的形式和范围。简言之，访问者与站点内容有很少的交互，他们主要是选择命令去浏览站点内容。

定义：动态产生的站点是指站点的网页是根据需求或用户的浏览次数产生的。

定义：个人化站点的内容是直接针对特殊用户，并且这些用户通常能清晰地决定在一个网页内包含的内容、外观或技术。

前提：对用户来说，一个Web站点的逻辑结构比它的物理结构更加重要。

规则：任何可能的情况下，都不要暴露站点文件的物理结构。

规则：站点的逻辑文档结构不必直接映射到与物理结构相匹配。

建议：以三次点击找到内容为目标。

建议：每次点击都提供显示达到目标的进展的正面反馈信息，如果最多只需要三次点击，则不需要反馈信息。

建议：即使对很宽的站点结构来说，考虑每页采用25~81个链接而链接用群理想地组织在一起。

前提：页越重要，指向它的链接应该越多。

建议：站点中的冗余连接不应该超过页面的全部退出链接的百分之十到百分之二十。

前提：任何商业站点的最主要目的是以某种公司直接或间接收益的方式服务于用户。

前提：娱乐站点找到新奇的事物或令人惊奇的东西比结构和一致性更有用。

定义：门户站点是用户在网上冲浪的起始站点，该站点帮助人们查找信息。门户站点经常试图提供尽可能多的信息，为用户的尽可能多的任务提供服务，鼓励他们留在该站点或至少继续浏览该站点。

前提：新用户喜欢采用可预见性的结构，并且可以容忍多次点击或缺乏控制以达到满意的平衡。

前提：能力强的用户或经常光顾站点的用户需要控制并喜欢提供更多导航选择的结构。

导航理论和实践

规则：使用简单的和能记忆的URL去改善导航。

规则：不隐藏URL——复杂的或简单的——除非你尽力让人们避免直接链接。

规则：在站点内利用连贯的和清楚的网页标签标识所有网页。

规则：在点击时，站点边侧的标签图标或组织名或标识应该始终让用户返回站点主页。

建议：按钮状态应被认为是网页标签的第二种形式，并且选择状态应该总是凹的，而不是凸的。

建议：当使用颜色代码来指示节位置时，保证使用的颜色彼此有明显的不同。

建议：不要过分热衷于主题的位置暗示，以免掉入设计者定义的隐喻中。

建议：不要试图在链接中模仿浏览器的历史机制。

规则：避免将连接简单地命名为“回退”，通常要精确地表示链接要退回到哪里。

规则：避免创建使用浏览器回退按钮不能回退的页。

定义：cookies是站点分发给用户，并存储在用户系统中的少量的文本信息。

规则：用户把他们的起始页记作永久的标志，把站点的主页当作半永久性的标志。正因为如此，这些页面在生存期应该保持稳定，但要和其他访问的页面有显著的不同。

建议：避免在屏幕的底部放置主要的导航，为辅助或增强导航保留这一区域。

建议：避免把主要导航放在屏幕的最右侧。

建议：主页和其他标志页应该考虑采用面向中心的导航方式，以区分同一站点的其他页面。

规则：导航的布置应和页面的布局保持一致。

规则：导航应该是一致的，元素在位置、次序和内容上应当是稳定的。

建议：用当前屏幕的位置来区别导航的选择项时，要明白这四个位置是最顽固的障碍。

建议：一有可能就应该将导航引导页竖放在屏幕上，就像所有其他页上基本导航的放置一样。

建议：把基本Web导航按钮和回退按钮间的距离最小化。

建议：对连续的选择应使鼠标移动的距离最小。

建议：避免把帧用于布局，而在导航设计时使用它。

建议：当使用帧的时候，要使小帧控制相邻的大帧。

建议：除非显示器的分辨率给出了很好的说明，不要关掉帧的尺寸设置和滚动。

建议：不要把远程作为导航的强制形式。

规则：在导航中尽可能地限制滚动和鼠标的移动。

规则：在得到结果之前最多装载三个页面。

链接：文本、按钮、图标和图形

建议：偶尔在文本文件中提供一些非结构性的链接以促进探索和思考。

定义：静态链接中，目标文件被文档作者通过编码的形式确定。

定义：动态的链接没有一个固定的目标。目标文件是在浏览页的时候根据环境和浏览者的需要确定的。

建议：当使用长页或带有图形按钮的页时，要在页面的底部提供文本链接。

规则：不要彻底改变已访问过的链接的指示。

规则：避免改变链接的颜色。

规则：避免在Web文件中对非链接文本加注下划线——对这种情况采用斜体或粗体。

建议：避免自动关掉下划线。如果这样做了，加入另一种指示形式。

建议：在未选中和选中状态下图形按钮应该最小。经过和按下状态可考虑为选择项。

建议：提供表明内容形式的好的标签。考虑用图表显示内容类型。

建议：确切地显示链接是否带他们在一个页面内跳转，在一个站点内跳转或者跳到一个外部的站点内。不要隐藏URL，以免用户自己推论。

建议：通过显示URL或用图标表明一个外部链接。如果启动一个下载，要标明文件尺寸。

建议：用一个图标和记号，或在链接之前弹出一个警告对话框。

建议：避免改变已访问过的链接颜色。

建议：使用一个新图标或在需要的地方加入最新修改的日期。

建议：如果内容有潜在的冒犯性，就使用警告或用明显的标签警告。

建议：使用状态条信息，当外部链接时，考虑提供文本的URL信息。

规则：断开链接被认为是灾难性的故障。

建议：避免因为404错误而自动重定向。

搜索与设计

定义：Web目录是人为编辑和组织的收藏集，它包括网站链接和相关信息的描述和回顾。

定义：搜索引擎是网站信息的自动收集者和组织者，用户可以依赖它来运行搜索命令。

规则：结合用户使用搜索引擎的经验，并使用类似的布局和标签设计本地搜索引擎，但要避免模仿那些不可控制的公共搜索引擎的设计方法。

规则：不要一味地为吸引搜索引擎设计网页，毕竟网页最终是为用户设计的。

规则：如果一个网站有规则的格式化数据、非常难以理解的数据或超过100个页面，就应该包含一个本地搜索引擎。

规则：一个站点如果为了迎合熟练访问者或者经常的回头客，那么就应该提供一个搜索机制。

建议：当在站点上使用搜索时，请在所有的页面上包含一个搜索按钮或搜索区。

规则：搜索窗体和搜索结果页面应同站点的外观和感觉保持一致。

规则：搜索窗体应该同搜索的内容相匹配。

规则：主搜索文本框的大小最好是辅助搜索文本框的两倍。

建议：最好将搜索限制在一个主题、分类或观点上，而不是整个站点内容上。

规则：高级的搜索工具应提供操作指导和样例。

规则：结果页面应该提供尽可能多的信息，以便用户能够决定更进一步地阅读条目。

规则：搜索结果的格式应该适应返回的数据。

规则：否定结果页面必须包括关于查询为什么失败及潜在的修改该查询的信息。

网页类型和布局

规则：设计的网页尺寸要与目的和内容相符。

规则：避免宽的页面，尤其是需要用鼠标向右滚动的宽页。

规则：尽量把重要的项如主导航作为第一屏的内容。

建议：注意屏幕的“折页”，并且在第一屏的内容后面设法给出提示。

规则：在任何情况下，避免分辨率的限制。

规则：当设计WebTV的时候，将网页宽度定义成严格的544像素。

建议：用假定的屏幕尺寸来做设计，要保守些，并给自己留下多达10%的可用区域。

建议：允许用户随心所欲地放大和缩小网页，不要强行让网页符合可用的分辨率，除非布局在不增加尺寸时会丢失。

建议：当应用固定的网页尺寸时，应当确保使网页居中以改善大显示器上剩余空间的感觉。

建议：当内容少的时候，尽量避免使用可伸展性的网页设计。

建议：如果可能的话，尽量把内容在高度上限制为3~5屏。

建议：要么控制网页边距，要么利用网页布局预留因子来考虑它们的变化程度。

提示：遗憾的是，某些Netscape浏览器在上下部还各有一个像素的网页边距。

建议：提供明显地可以用来跳过飞出主页的链接。

提示：确保只对初次访问者显示飞出网页。

提示：用飞出网页来安装或预下载站点内容。

规则：主页与站点里的其他网页相比应具有截然不同的外观。

规则：主页应当设定站点的外观和导航的基调。

规则：主页应当下载得很快，但应该十分生动以引起用户注意。

规则：主页应该清楚地展示该站点的内容。

建议：站点在发生变化时，主页应当提供重要的信息并且给出明显的提示。

建议：如果某一子页作为标志使用，或者作为像区段主页那样的通用登录网页使用，就应该把此页面的外观设计得与其他子页有差异。

规则：至少在精神上，子页应当服从于主页的导航及风格。

建议：如果长度合理的话，把FAQ网页制作成易于打印的单一文件。

建议：为了设计或检查过去用于站点上的法律术语网页，应当咨询专业法律人员。

建议：在网页上添加最后更新的提示。

规则：如果已经收集了敏感个人信息，就应当提供一个易于访问、易于理解的隐私声明。

规则：完整的联系信息应当在站点的所有网页上都可以快捷而有效地得到；最低限度的信息如Email地址也应该出现在每一页上。

建议：告诉用户屏幕上所见到的与打印出的有差异，或者直接给出打印版本。

建议：在打印优美的复杂资料时，请使用Acrobat PDF文件，这些资料包括数据表格、工业制图及复杂的财经或数学信息。

建议：用文本或图标明确提示Acrobat文件并提供使用这些文件的信息。

规则：在退出网页上提供返回站点的途径。

规则：让用户安静地退出。避免使用“请不要离开”或“最后一次机会”这样的弹出式窗口。

建议：当使用基于文本的设计时，请不要只提供上下文链接，还应该提供导航条。

建议：在下载速度或显示灵活性是首要因素的站点上，请考虑使用文本设计原理。

建议：在站点上避免使用隐喻设计，尤其当用户是专业用户或频繁访问站点的用户时。

建议：在任务驱动或频繁使用的站点上，请避免设计非常规的或过分重视艺术的界面。

建议：基于内容的站点应当使用标题页脚设计，在常见的一般内容中更应如此。

规则：在Web设计中始终要从中求异。

文本

建议：在网页中避免使用两端对齐的文本。

规则：增加线的高度以提高联机文本的可读性。

建议：利用文本的不同颜色、尺寸、格式及位置来创建分类以提高页的可读性。

规则：一个站点的细节问题可能最影响综合印象值。

建议：避免小的反走样文本。

建议：每页考虑使用三种字体：一种用于页标记和标题；一种用于主体文本；一种用于导航。

规则：网页中文本的栏应该从不上、下换行。

规则：基于导航的页比内容页通常需要更少的文本空白空间。

规则：经常使用空白空间以辅助信息的使用。

建议：小心使用那些在Web中改变了意思的单词。

颜色、图像和背景

规则：为了确保产生赏心悦目的颜色，除了基本颜色如白色、黑色、红色等，始终在命名的颜色上使用十六进制值。

建议：为了安全突破216色限制，请使用预颤动图案或所谓的混合色。

建议：由于很差的跨浏览器支持，应当避免使用<BASEFONT>元素来设置文档的字体值——尤其是在要考虑颜色的地方。

规则：总是把图像储存在一个单独的目录里。

规则：合乎逻辑地命名图像，按照目的或使用的情况将它们分组。

规则：没有SRC就不要使用<IMG>标签。

建议：ALT文本应当尽量增强重要图形的意思；如果图像并不传递实质性的意思，将ALT置为“空”，要比用不必要的“工具提示”把页搞得一团糟要好得多。

规则：始终要使用<IMG>标签里的HEIGHT和WIDTH属性。

规则：在HTML里，任何时候都不要用HEIGHT和WIDTH属性来用HTML重新定义图像的尺寸。如果需要一个较小的图像，请用正确的HEIGHT和WIDTH属性创建较小视野的图像。

规则：除非有特殊的设计原因，通常把图像的BORDER属性置为零。另外要记住，没有BORDER属性链接的图像将显示默认的彩色边界。

建议：在其他格式被普遍支持之前，请将网页图形的格式限制为JPEG和GIF。

建议：链接和信息图形中不要只依靠颜色做提示。

规则：当用分割图像和表格创建布局时，请确保图像和表格单元的WIDTH和HEIGHT值相加后的和总是恰当的。

规则：为了使分割图像和表格作为布局相互匹配，一定要把表格的CELLPADDING和CELLSPACING属性值设为0。

建议：不要把背景平铺的高度或宽度做得太小(如1~2个像素)，否则可能发生令人烦恼的监视器闪烁。

利用GUI特性创建交互性

建议：为了提高站点的“粘度”，请提供有用的且很难在其他站点上找到的服务。

建议：提供联机文档(或在某些情况下，提供打印的文档)，但是不要寄希望于用户去访问它。

建议：避免修改用户主浏览器窗口的外观。

规则：当使用全屏显示的窗口时，请通知用户怎样退出这种模式，或为用户提供一个关闭按钮。

建议：在没有征询用户意见的情况下，请不要采取全屏模式。

规则：不要创建普通的模态窗口。将模态窗口保留给警告、提示及确认信息。

建议：用警告来通知用户重要信息而不是普通的信息。

建议：使用确认对话框，以证实执行不可撤销的操作或重要的任务如窗体提交。

建议：只用提示对话框来请求用户提供简短的词，或者简单问题的数字答案。不要询问那些导致多行答案的问题。

建议：合理设置文本区的长度以符合所提供的数据。

规则：始终要为文本区设置MAXLENGTH。

规则：只有在超过了屏幕的实际可用区域，且输入的数据比可用的屏幕区域大时，才允许文本区滚动。

规则：不要允许密码文本框的滚动。

规则：限制密码文本区的长度以使之与密码长短相符。

规则：不要使用密码字的默认值。

规则：在多行文本区域中将文本设成可换行的。

建议：考虑纵向排列相关的复选框以减少鼠标的移动量。

规则：无论何时都要用默认的方式校验初始单选按钮。

规则：是非问题中请使用单选按钮，而不要使用下拉式菜单或复选框。

建议：一个按钮组中避免超过8个选项。

建议：在多选一的选择过程中，如果多于8个选项，就像这条规则所声明的那样，使用下拉式菜单以节省屏幕的实际空间。

规则：不要使用单选按钮去导航。

建议：避免使用SIZE属性来改变唯一选项的下拉式菜单的显示。

规则：通过前后关系、标签及可能的启动按钮使下拉式菜单的导航目的明确。

规则：当JavaScript关掉的时候，确保下拉式菜单是逐级退化的。

规则：如果“继续”按钮和下拉式菜单导航在屏幕上同时出现，确保用户能实际点击它。

规则：当用户退出了页或选择了分隔项时，请复位下拉式菜单。

建议：如果考虑其它可替换的浏览器环境，请避免使用滚动式列表，而是用复选框代替。

规则：当使用滚动列表时，请确信为初级用户提供怎样选择多个项目的建议。

建议：不要用缺省的窗体样式按钮来导航；相反，保留它们用于别的动作。

建议：可以考虑将复位按钮从提交按钮处移开。

规则：在提交重要的信息或开始一项无法恢复的任务之前，请提供最后一次机会。

建议：将提交按钮保持在格式的底部，或者居中或者位于左侧。

建议：用脚本为图像按钮提供退化的状态或关掉图像。

规则：在使用文本上载控制之前，一定要考虑使用环境。这对那些没有储存文件的用户来说，可能没有什么意义。

建议：通常从上到下布置窗体单元，但是基于请求的信息情况，考虑从左到右的布局。

建议：当格式化表格单元时，考虑保持表格边界，因为它们与标签和文本区有联系。

建议：如果用户很熟悉的话，就直接模仿现实世界的表格；否则，着重于减少数据的项目数。

规则：使表格键盘变得友好些。

规则：限制表格单元之间的鼠标移动。

规则：使用星号或单词“所需的”仔细的标记要求填写的文本区。

建议：添加TABINDEX属性以改善表格的导航。

建议：应马上聚焦到窗体页的第一文本区。

规则：既不要覆盖也不要屏蔽浏览器加速键。

建议：对那些重复使用的表格使用加速键。

建议：用ToolTips提供关于文本区的使用和格式的额外信息。

建议：使用状态条来提供关于文本区使用的信息。

建议：在复杂的表格文本区附近提供对上下文敏感的帮助按钮。

规则：尽可能地在客户端校验窗体。

规则：始终要在服务器端提供备份的确认。

建议：尽量在人们输入或每完成一个文本区后就隐蔽地进行校验。

规则：在窗体校验的过程中，请为哪个文本区有错误及怎样去校正错误提供一个清楚的提示。

规则：马上聚焦到错误所在的文本区。

建议：屏蔽文本区已限制输入字符的类型。

建议：将特定上下文中不必要的文本区失效或隐藏掉。

建议：当把文本区设成只读时，应改变外观或提示用户文本区的状态。

建议：提供缺省值，并为大多数输入提供适当的值。

建议：用简单而常见的名字来命名文本区，以充分利用浏览器的自动完成特性。

规则：当使用树形控制时，确保打开和关闭状态有区别。

规则：不要把二进制的Java applet放在Web页界面里，避免混合复杂的GUI界面。

Web技术以及其对Web设计的影响

规则：没有足够的理由请勿使用代价过高的技术。

规则：对公开出版的浏览器使用数据一定要谨慎；探索在站点上切实可行的浏览器使用方案。

规则：用户通常不会因为简单的错误而责备浏览器——他们要责备的是站点。

建议：为了保证成功，对浏览器的基本概况使用服务器端探测。

规则：可能的话，就给出技术能力的概况，否则假设最糟糕的情形。

建议：为HTML选择一种大小写样式，并坚持做下去。

建议：对待属性值的大小写一定要小心，尤其是文件名。

规则：校验所有的HTML页。

建议：为了未来的网页，请在今天考虑遵守XHTML规范。

规则：在HTML中把结构与表示分离，可能的话，使用CSS。

规则：仔细地测试CSS规则。

建议：在任何可能的时候采用外部样式单。

规则：总是给出样式规则的注释，以避免被老的浏览器解释。

建议：避免只依赖于样式单来布局，除非不支持CSS的浏览器能够得到限制或检测，并能得到适当处理。

建议：用CSS来代替HTML显示单元如<FONT>。

建议：用最合适的方式创建HTML和CSS文档，而不要只依赖于一种工具或一种方法。

建议：在HTML文档中使用注释。

建议：创建并使用页模板。

规则：在HTML文件命名方面更要一致——选择.htm或.html并坚持它。

建议：尽量依赖标准的XML语言而不是内部开发的语言。

建议：把XML用作中性存储格式，并且用于交换。

规则：在站点中既考虑使用客户端的技术，又考虑使用服务器端的技术，不要只考虑使用其中的一个。

规则：仔细监视服务器方面技术的响应性。

规则：当使用服务器端技术时，要创建一个容量计划。

建议：为了改进CGI执行，考虑重写或编译大量使用的程序。

建议：用复杂的URL使用服务器端编程技术可能会使用户迷惑。

规则：为所有的客户端编程技术提供可撤退的状态。

建议：当翻译为本地Web形式不实际的情况下，请考虑helper应用程序。

建议：除非能执行自动安装，否则注意只使用更为流行的插入件技术。

提示：尽管插入件能在网页的任何部分显示，但还应当用样式单限制插入件的特定区域。

建议：使用带有插入件的<NOEMBED>语法。

规则：为插入件和Helpers提供安装帮助。

规则：如果在公众站点上使用ActiveX，就为Netscape或其他浏览器提供可替换方案。

建议：与对象技术相关的保密性问题应让用户明白并以诚相待。

规则：当使用对象技术如Java时，请仔细考虑终端系统的性能。

建议：在使用二进制技术如Java或ActiveX的网站界面中，避免创建GUI界面。

建议：应通过测试来观察一个脚本能否在该语言的所有版本均可行。

规则：在所有的脚本里请使用对象，方法及版本探测。

规则：处理不支持脚本的浏览器时，将脚本注释掉并使用一个<NOSCRIPT>元素。

规则：始终为JavaScript添加一个错误处理器。

建议：在可能的时候，请使用链接文本而不要使用内置的方式。

规则：在用JavaScript编写代码时，采用好的编码标准和连贯的样式。

建议：用易于发现的隐私策略或是用声明来通知用户cookies是干什么的。

建议：避免使用大量的cookies。

建议：为不愿意提供接受cookies的用户提供另外一种方法。

规则：当竭力吸引用户的注意力时，避免动画之间的竞争。

规则：避免连续循环地放映动画。

建议：当与演讲或音频广播片断建立链接时，通常要指示声音文件的长度、格式及尺寸。

建议：为下载和播放发送，对低质量的音乐、声音效果或演讲使用WAV。

建议：对长的背景音乐文件，尤其当带宽受限制时，请使用MIDI文件。

规则：采用今天的协议和用法，无法保证在Internet上传输可预测到的和没有错误的实时数据。

建议：不要假设每一个环境都支持音频。通常为重要的基于音频的内容提供可替换的访问方式如文本。

规则：始终允许用户关闭连续播放的声音。

建议：除非信息在视频媒体中得到了改善，否则避免使用视频。

网站的发送和管理

规则：创建页面所要发送的字节数并没有用户感知页面的速度重要。

建议：尽量在一页中保持单独对象数要少些，以减少HTTP请求的个数。

建议：使要发送的数据类型、项目数及数据对象的尺寸与用户的链接速度相匹配。

规则：Internet中可预测的和无错误的实时数据发送并不能有今天的协议和可用性得到可靠的保证。

建议：为站点提供大量的域名格式。

建议：确保网站的域名服务是快速且健壮的。

建议：不要吝啬Web服务器的硬件，把重点放在有高速硬驱、大量存储器及好的网络接口的系统。

建议：为Web服务器选择操作系统不要只基于流行性；要考虑总成本和开发的适应性以及长期的维护。

规则：尽力减小站点和用户之间的网络距离。

建议：当安全性和控制是主要考察点时，选择自己的宿主环境。

建议：使用一种监视工具或服务以确保站点对用户来说是持续可用的。

规则：除了简单的防火墙外，创建、执行并测试完整的站点安全性策略。

建议：文件名中避免使用下划线，应考虑使用破折号或者字间无空格。

建议：文件名或目录名中请不要使用大小写混用或大写的字母。

规则：选择.htm和.html中的一种作为文件扩展名，并坚持它。

建议：不要接到命令才更新。创建一套定期更新的方案。

规则：不要直接在正在运行的站点上工作！

规则：不间断地检查站点的链接。

建议：定期检查页的细节问题包括拼写、法律术语及字体的使用。如果有必要就做打印测试。

建议：为用户提供地址webmaster@yourdomainname.com以使用户在提供建议或发现错误时和你联系。

建议：不要在站点上设置可视化的页计数器。

规则：仔细分析日志文件，并用它们去改善站点或衡量其效率。

规则：不要只依赖于日志文件来了解站点的效率。你仍然不得不与站点的用户进行交谈。

规则：如果收集敏感的或私人化的信息，请提供一条容易访问和理解的隐私声明。

规则：如果内容无论如何都是有疑问的，使它有PICS评分功能。

Web设计的未来

预言：HTML在很长时间仍然将以某些形式或另外的形式存在。

预言：CSS将最终被普遍使用，代替了HTML的显示功能。

预言：可下载字体将变得普及。

预言：由于HTML变得更为结构化并遵守有关的规则，手工编辑HTML将变得越来越少见。

预言：严格将Web内容分离成结构、逻辑和显示将变得越来越重要。

预言：数据库将继续存储大量的Web内容。

预言：XML语言将作为中性交换语言而得到很好的接受。

预言：理解XML是缓慢的，采纳XML所遇到的障碍将通过用户达成一致意见来克服。

预言：以用户为中心的设计将继续占有主流地位。

预言：宽带介入将增加多媒体的使用，但下载仍是个问题。

预言：随着带宽的增加，接口将更具响应性并更加丰富，但大量的带宽将用于内容。

预言：简单的文本将因为它的灵活性而继续作为重要的内容形式。

预言：不基于PC的Web浏览将日益增长，并要求有不同的接口设计上的考虑。

预言：浏览器不再受用户关注。

预言：无线Web访问将集中于对地区和时间敏感的信息。

预言：可视化界面将受限于数据集合分析，并且不会被大多数的用户用于导航。

预言：在最近的将来，机器人软件对基本任务是有用的，但带有任何明显意义的智能代理还远未实现。

预言：用户在实践Web生活方式时，将变得越来越没有耐心，并且越来越不原谅站点的缺点。