随着企业intranet和国际internet的迅速发展，越来越多的工作流程，商务交易，教育、培训、会议和讲座，以及个人消费娱乐都被转移到所谓的万维网（World Wide Web，以下简称WEB）上来了。与此相对应的是交互操作的复杂性越来越高。

　　随着Browser/Server模式的日渐流行，很多操作都是在浏览器环境下的网页上完成的，并不是只有失效的链接和意外的出错才会使操作者感到烦恼，即便是一次完整的成功操作过程，也可能因为操作的繁复性过高或者使用上的不方便而给操作者带来不愉快的体验。

　　本文试图阐述WEB交互页面设计的一些指导性原则，这些原则有利于避免发生不愉快的操作体验。这些原则是用户友好性的，是在完成同一种操作要求下，使用户最感到轻松、简单、舒适的WEB交互界面设计原则。我们假定我们讨论的WEB页面都是功能正常的，符合美学观点的。需要说明我们讨论的原则可能会和设计上的美学观点以及既有的功能设计有所冲突。如果发生这种情况，基于“实用的就是美的”观点，我们会建议您酌情放弃原先的美学观点与功能设计。

　　1． 输入控件的自动聚焦和可用键盘切换输入焦点

　　使用JavaScript实现页面加载完成后立即自动聚焦(focus)到第一个输入控件。可用TAB键（IE缺省实现）或方向键切换聚焦到下一个输入控件。

　　输入控件指WEB页面表单(<form>)中显式的，需要用户进行修改、编辑操作的表单元素。对于这些控件，如果没有自动聚焦操作，不可避免的出现一次用户鼠标定位操作（如果用户此前处于键盘输入操作状态或鼠标定位后需要进行键盘输入操作，实际上是键盘鼠标切换操作）。如果鼠标定位后需要进行键盘输入操作，如果不能键盘切换输入焦点，那么不可避免的在切换输入焦点时需要反复的键盘鼠标切换操作，这是很繁琐的。

　　如果实现了页面加载完成即自动聚焦到第一个输入控件，并且可以键盘切换输入焦点标定位操作，那么对于用户来说整个页面的输入操作可能都不需要鼠标操作，或次数较少，这是一种便利。毕竟频繁的键盘鼠标切换操作是比较累人的。

　　对于有输入栏的对话框或网页，在不干预的情况下就应将当前控制焦点定位在待输入的输入栏上；如果输入栏在一般情况下不需要更改其中的内容，则应直接将焦点定在“确定”按钮上；在几个输入栏之间应支持tab，shift+tab切换操作，“确定”和“取消”应该是切换操作的终点，与具体所在位置无关。

　　2．可用Enter（或Ctrl＋Enter）键提交，确保和点击提交按钮的效果是相同的

　　不要在提交按钮上加入onClick=”…”这样的JavaScript代码。

　　用Enter键提交页面是原则1的自然延伸，而且这也是浏览器所缺省支持的。只所以单独列出来是因为实际上有些设计者设计的页面不能达到这种效果，结果导致使用Enter键提交和点击“确定”按钮提交带来的效果不一样。大部分情况下是设计者在“确定”按钮上加入了onClik=”…”这样的代码，通过点击“确定”按钮后，会执行一段JavaScript代码，比如对某些hidden类型的input元素设值。而使用Enter键提交时就不会执行这段代码。

　　正确的做法是把这段代码移到表单标签<form>中，以onSubmit=”…”属性引入。

　　对于<textarea>表单元素，它会消耗Enter键，因此会使得Enter键提交失效。可以引入JavaScript代码捕捉Ctrl+Enter复合键，一旦捕捉到即执行表单的submit()方法。对于需要频繁提交的场合，比如BBS上，这种代码是很有必要的。

　　3． 鼠标动作提示和回应

　　对用户的鼠标定位操作，当移动到可响应的位置上时，应给予视觉或听觉的提示。

　　动作回应的最简单形式就是鼠标ICON变成手状。浏览器只对具有href属性的HTML标签会自动进行这种变换ICON的行为。对于没有href属性（或没有设置href属性）的标签，可以通过JavaScript设置style属性的cursor为hand。

　　目标区域发生变化是更为主动的响应形式。当鼠标指针移到目标区域，此时指针图形改变或文字颜色发生改变均能较大的减轻用户搜索定位目标区域的注意力负担。在按钮上增添直观的图形，尽可能的增大按钮面积；按钮间保持适当的距离，太近增加了用户区别它们之间界限以防误操作的负担，太远增加了用户搜索定位按钮的负担。

　　4．尽可能早的在客户端完成输入数据合法性验证

　　输入数据的合法性检验应该在客户端使用JavaScript进行验证。除非验证只能在服务器端完成，否则验证工作应在最早能完成的情况下进行。

　　在客户端完成数据合法性验证，可以避免一次服务器请求和回复通讯，这种通讯是需要用户等待的，如果用户等待很长时间后从服务器返回的结果提示出现的错误是在输入时即可发现的，那么这种设计就是不友好的。诸如密码长度限制，用户名允许字符限制等等，显然应该在客户端提交前就应该进行验证。

　　5． 根据应用场景决定在表单页面和提交后返回页面间是否使用中间过渡页面

　　根据应用场景，决定是否显示接收表单页面（表单页面和提交后返回页面间的中间过渡页面），以及使用何种方式显示接收表单页面。

　　表单页面和接收表单页面是大部分WEB交互操作赖以实现的配合模式。关于表单页面和接收表单页面的相互关系的设计，要做如下几个方面的考虑。

　　一，对于需要频繁操作的场合，从操作便利和快捷性出发，尽可能的减少服务器和客户端交互次数，应该避免使用中间过渡页面。提交完毕直接返回原来的表单页面或默认页面。在这种情况下要考虑到数据安全和可恢复性。

　　如果因为用户输入的数据不合格，需要重新输入，那么，去除中间页面，把错误信息直接显示在原表单页面上的设计方式，将是最简洁的处理方式。用户只需要根据错误提示进行更正即可。当然这样做稍微增加了编程负担。在表单接收页面上需要包含原表单页面的内容，而且输入数据项都必须用服务器端代码或客户端JavaScript设置成用户输入的值。为了开发快捷，可以这样做：表单页面和接收表单页面用同一个服务器端脚本页面实现。这个页面按如下流程完成原来两个页面的工作：

　　页面脚本初始化

┃检查“提交”变量是否设置┠已设置，做数据验证┃ 验证通过－>业务逻辑处理－>使用包含页面方式或重定向方式返回到特定页面 ┃ 验证不通过－>保存用户输入的数据－>退出表单提交处理到表单页面流程中┗未设置，做表单页面流程，如有来自提交流程中产生的用户输入数据，则显示出来

　　其中，使用包含页面方式返回到特定页面可以避免一次客户端重定向过程，比客户端重定向过程还要快捷和稳定一些。但是有些情况下因为代码变量冲突或其他原因，使用包含页面方式可能并不方便，这时候可以使用服务器端重定向技术，在ASP里是Server.Transfer方法，在Java Servlet里是RequestDispatcher.forward()方法。不要使用Response.Redirect或者HttpServletResponse.sendRedirect()这种客户端HTTP重定向方法。不使用中间过渡页面也就意味着用户不能后退浏览原先已经填好的表单页面，因为使用的是同一个URL。所以在验证不通过情况下保存用户输入的数据就是必不可少的。

　　不使用中间过渡页面带来的另一个问题就是使用包含页面方式或服务器端重定向方式返回会使得URL和页面内容不能一一对应。对于用户可能会直接用这个URL（会收藏这个URL）访问返回页面的情况，他会发现实际上到达的是表单页面，不是他想要的那个返回结果页面。所以，去除中间过渡页面，确实会带来URL和内容含混不清的情况，因而不适合需要URL和页面内容一一对应的场合。

　　二，从技术角度考虑，使用中间过渡页面能保证URL和页面内容一一对应，简化页面开发工作。

　　为了保证页面内容总是和固定的URL联系起来，必须使用客户端重定向：

           提交                   业务逻辑处理  （中间过渡页面）

表单页面