![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
在这充满了 iPad、iPhone、 Android 及应用程序为中心的设备的世界上，现在说 “我的 Web 站点是静态的” 已经过时了。如果没有高级搜索功能、至少三个购买选项、两个有高级 Ajax 交互的页面，您的站点会被认为 “太 1998 了”。许多开发人员都在竭尽全力满足管理需求：加入更多互动性！赶上 Amazon.com 或 Bing 或 IBM！让 Web 站点成为 ... Web 应用程序。但是，如果这些效果都实现了，结果可能是失去重点，有时会有功能缺失，Web 展现效果减弱。
Web 站点与 Web 应用程序完全不同。如果您在构造 Web 应用程序，您应当知道与 Web 站点之间的差别。另一方面，如果您习惯于构造静态的、JavaScript 较少的页面，您可能要将站点转换成 Web 应用程序。
通过本文，做出明智的决定，支持 Web 最终目标。了解 Web 站点与 Web 应用程序的区别，了解这两个概念如何在很大程度上不尽相同。理解主要差异后，您将会准备好做出决定 — 或至少影响 — 您的 Web 样式。
您也许会遇到这样的情形，已经有了 Web 站点，并没有 好的理由要转换成 Web 应用程序。或者是这样，人们在 Web 应用程序上花费大量时间只是转动鼠标轮而已。最好把这些都省略掉，用一个相对简单的 Web 站点代替。本章将概括介绍 Web 站点和 Web 应用程序的区别。
纯静态 Web 站点的最简单的定义是：提供信息的。一个典型例子就是 Wikipedia，它是用来完全提供信息的。Wikipedia 不花哨，不令人兴奋，也没有充满弹出图片和全屏地图。只有原始信息，看上去像带超链接的字典，如图 1。
图 1. Wikipedia 例子
信息的最佳沟通方式是通过简单的静态 Web 站点。如果您的目的是宣传产品或服务信息，甚至是信息本身，Web 站点是个好的起点。 当然，Web 站点也有很大限制。它们不花哨，没有 Twitter 一样的效果。尽管如此，大多数人在探索新问题时第一站是去 Wikipedia，因此静态网站显然有真正的价值。
大多数博客其实是 Web 站点。即使博客站点是程序驱动，如 WordPress 或 Movable Type，结果是信息驱动站点基本是扁平的、非交互式页面。这一点表明一项重要区别：Web 站点不是通过站点如何创建来定义的；Web 站点是通过用户如何使用站点信息和功能来定义的。理解这一点可帮助您集中关注用户对 Web 样式的体验。
在早期阶段，应当集中关注用户体验。用户不关心站点后台是 HTML 和 CSS，或 ColdFusion，或 PHP，或 Perl。用户只根据他们所看到的进行评判。想要知道正在构造或查看的是哪种站点，请暂时停止编程。打开浏览器，导航到您的网站，做出评估。
如果您的站点主要不是提供信息的，则很有可能是交互性的。这就意味着用户不是被动使用者，而是积极参与者。用户会搜索、点击按钮、填写表单、购买物品，通常是不停地操作键盘鼠标。
想一想交互性最强的电脑游戏。游戏中，用户是完全积极的，且不停互动。无论是射击僵尸还是穿越雷区，用户总是不停点击按钮，进行决策，进而点击更多次按钮。当然，多数站点还未达到那种程度的交互性。
大多数 Web 站点，某种程度上，兼而有之。例如，看看图 2 中显示的 Amazon.com 主页。Amazon.com 兼有两者，但仍是信息站点。
图 2. Amazon.com
上面的屏幕中显示了很多信息。书籍、作者、价格、类别都是各种信息。尽管如此，用户在该页面的主要目的是进行交互。用户会导航到更具体的分类。或者，他们会深入查看具体某本书，并购买。用户会进行搜索，或看看购物车里有什么。这一切都是交互。
假设所有 Web 站点都会展示一些 信息，目标是确定其平衡。主要是交互，还是阅读？在页面上花费 30 秒，还是 10 分钟？如果主要是进行交互，且花费时间较少，那么您正在访问的是一个交互性网站。
目前为止，我们讨论了用相对简单的二分法评估站点。要么是信息性，要么是交互性。非黑即白。
大多数交互性网站实际兼而有之。如果没有信息，那实际上就没有东西来交互。想象一下，Amazon.com 没其他东西，只有按钮 — 没有书籍，没有 DVD。这毫无意义。需要有信息，才能对其作出反应。因此，即使是交互性网站也是兼而有之：信息和交互的混合。
您也许会想，为什么要关注其区别，或者说，要把信息性和交互性这两者分开来。对主要用于发布信息的站点和主要用于创建交互的站点分别考虑，这是有实际价值的。这种分开考虑方式，实际上，将驱动很多设计决策。即使要构造一个纯信息性，或纯交互性站点，确定站点趋向哪个方向也很关键。
如果您的站点倾向信息性，这也就标示了您的用例：向用户提供信息。问题就是如何实现。假设用户想要获取信息，如何才能以最佳方式发布呢？如何最好地传递数据？这通常是大批量在线阅览。
此时，人们开始开发电子书、增强版本，同时下一代出版物已呼之欲出。信息应当呈现给下一代媒体主导的读者，对吗？我们有新方法来呈现信息：浮动说明、点击弹出窗口显示额外信息以及嵌入式视频。
这种思考方式的问题是，似乎暗示历史并不久远，而且用户不存在某种习惯。人们习惯于 阅读书籍、阅读字典条目、阅读 Wikipedia。阅读这些资料的方式主要是从上到下，很多语言中是从左到右。他们阅读大量文本，而且通常是连续阅读，不会打断。事实上，他们希望 阅读不被打断。
信息性站点不应成为最耀眼、最性感、功能最全的站点。尽管有一个用图片来阐述事物的好例子，您还是应该先看看现在最流行的网站：dictionary.com、Wikipedia 和其他高度文本化网站。当然可以考虑可视化元素，试试不同字体，努力实现易于访问和容易理解的导航。您只是提供信息，任何削弱或分散该目标的内容都应舍弃。
如果您试图构造交互，这与发布信息有什么不同呢？如果信息站点是寻求最小化中断，那么交互性站点就是寻求最大化 中断。您的站点不断激起让用户点击、拖拉、高亮显示的愿望。您在创造一种环境，它不是一种方式，而是两种方式。这让用户不再被动地阅读文本或查看图片；他们要做 某些事情来延伸其体验。
它们与交互一致，然后是采用中断。您要故意制造交互点。如果导航到站点的路径是完全 通过超链接的，那说明您的信息和交互设计没做好。另一方面，如果用户需要点击按钮填写表单，然后出现收缩的信息区域，那么基本上就做对了。
另一个解决在网站中加入交互的方法是加入网站序列图。看看特定页面的屏幕截图，然后指出您希望自己网站的下一步 页面或视图是什么样子。 然后下一步、下一步，直到有四到五个连续步骤的屏幕截图，让用户从 A 点到 B 点。
确定用户如何从一个屏幕移到下一个。简单点击链接？点击按钮？他移动鼠标距离多长？屏幕上产生多少动作？用户在做 什么？这是算出中断的好方法。多久需要用户参与其中？如果用户不参与，提供多少中断？
为了了解序列图有什么帮助，我们通过案例学习。看看一家高端汽车生产商 Web 站点的屏幕序列。由于其价格很高，网站必须 吸引用户并让用户惊呼 “wow”！
图 3 显示的是访问 Audi.com Web 站点时打开的页面。网站很花哨，在交互之前就是如此。
图 3. Audi.com 打开的页面
用户可以立即与网站交互。下一个屏幕，如图 4，只包含一个鼠标单击。单击汽车下方的颜色块就会立即改变车的颜色。不需要菜单搜索，或到处寻找，用户就可以立即与页面交互。
图 4. Audi 前台图片对用户点击做出响应
现在 Audi.com 开始使用一些相对旧的技术。下拉和鼠标悬停菜单没什么新东西，用过 DreamWeaver 的人都会。但 Audi 想要有交互性。因此，不是用下拉然后单击，而是显示完整图片、规格表，相当于一个嵌套页面。
图 5 看上去更像内部页而非前台页。Audi.com 的菜单功能远远超过纯粹导航。菜单悬停不仅是点击选项，还有完整图片和选项列表。
图 5. 菜单悬停显示完整图片和选项列表
这种交互方法很聪明。用户无需点击很多，但网站给出很多反馈 — 而且是可视化反馈。感觉上 很多事在进行。交互不总是需要复杂的 Flash 动画或操纵杆。有时候放得恰到好处的图片，如 Audi 网站，就非常完美。
图 6 揭示了交互性另一关键方面：简单。这是基于文本的菜单，看上去没什么特别。但下拉菜单很简洁，当前选项高亮显示。这不是革命性的，但对于网站上的其他内容，只要花费最少时间阅读或辨识。相反，鼠标移过菜单，移到选项，并单击。不会疑惑。您一直都知道自己在做什么。
图 6. 导航菜单很简单，用于点击
图 7 是内部页。与效果华丽的前台页不同，内部页要差一些，真实感少一些。有很多选项，都是可点击的，都会影响中间图片。每个模型的页面都有很多图片，会基于用户输入做出响应。颜色、轮胎类型、内部格局都会产生立即变化。
图 7. 可视化内部页面涉及的点击比阅读多
显然，这个网站涉及很多工作、设计和编程。这不是很多网站会采用的交互模型。尽管如此，关键是顺序：用户被迫加入网站处理过程。更多的交互产生更多信息，最终得到网站的响应。
打印出的屏幕截图很容易看出，用户如何交互，以及交互根据体验生成哪些。花点时间体会一下。似乎把屏幕截图打印得到处都是的做法很笨，但这比起用户对网站感到厌倦并快速离开要好得多。
有了交互式方法，一个大问题是放在屏幕上哪里。 这不是仅仅讨论 “小部件放在左上角？还是沿右边放？”。有两种基本方法（其中一个不太好）：
- 交互不一定要放在前端中间，但要在用户处理过程中。用户必须交互才能继续。
- 交互围绕着信息。交互时吸引注意，而不需要参与网站流程。
偏向第一种方式。交互不是附加在现有网站上的东西。原因何在？交互并不适合围绕 信息。相反，它是信息本身固有的。以上的图 5、6 和 7 显示出交互已嵌入到信息本身— 菜单选项。无法将一个与另一个分开。
回到两者兼有的构想，即使最具交互性的网站，也会在某种程度显示信息。想想电子游戏，它根本不是网站：游戏不时借助过场动画或幕间片段让玩家被动接收必要的信息。
反过来讲，最具信息性的网站也会让您点击或搜索。想象一下 Wikipedia 所保存全部信息只用一页！即使这样，用户还要滚动鼠标；最基本的，滚动鼠标也是交互。所有网站都是兼而有之。大多数网站不是两个极端，有 90% 信息或互动，只有 10% 另外的。大多数网站在 75/25 范围内。您要做决策在互动网站上增加信息，还是在信息网站上增加互动。希望做出的是正确的决策。
也许您做的互动很美妙，但信息也要足够好。也许您信息方面设计很棒，但在某种程度上也要加入互动。
问题核心在于：无论您有多擅长交互，最好信息设计也要足够好。如果您是世界级信息设计师，还要学习如何构造合理的交互。很难两方面都做得足够好。很多人擅长其中一个，从而网站会偏向其强项。奇怪的是在某一方面（交互或 信息）做得很好的网站在另 一方面往往很糟糕。目标当然是两者都好，但往往是做成很好的网站或应用程序。
首先，只关注交互性而不顾信息性设计，或者反过来，都是不足取的。可能一方有余而另一方不足。您的目标应当是在某一方面非常努力，然后另一方再根据需要改进。如果在一个网站上两方面投入比例是 75/25，那么在 75 那部分投入的努力就要是 25 那部分的 3 倍。这当然就是设计的基准。
下一步是完成各自任务。不断设计网站，构造交互性。一般来说，用业余时间开发 Web 站点的设计师要比用业余时间学吉他的设计师要好。
最后，要加强薄弱之处。如果您的网站里塞满了信息，那么看看有没有什么地方能加入点交互性。加入点 JavaScript 和 jQuery 以增加点活动区域。减少一点信息内容使信息和交互比例趋向 60/40。反过来也是如此：在交互性网站上看看能不能加点信息。在合适的地方加入边栏和文本框，比平常多提供一点信息。改进您的弱项。
此刻，也许您会对作者要说的这些显而易见的事情不感兴趣。请先稍微坚持一会儿。
使用您的网站，尽量多地使用。
听上去很简单，是不是？但是，就像很多演员不想看自己的表演，很多音乐家不想听自己的 CD，许多 Web 设计人员也不会再花时间看自己开发的网站。他们编码、设计、上传，然后忘记。他们不会知道他们的网站将如何被使用。他们开发出的是想象的用例，以及看不到和不存在的用户。这不是好习惯。
因此使用您的网站。如果您不喜欢，您的用户也不会喜欢。不要草率忽略这个问题，“噢，我了解系统。” 或是 “所有用户都和我一样”。好的做法是：“我如何才能为用户改进网站，不管用户是否和我一样？” 这点额外的想法能极大改善网站的样子。
好的 Web 设计不在于您是否引用这篇文章 — 或其他东西 — 而在于长期的程序设计和 JavaScript 编码。反过来，您应当评估和记住本文提到的设计原则，以此为基础，总结出您自己的设计原则。当您认真思考过本文后，您的网站和应用程序应当有所改进，当然，如果只是盲目照搬，那当然不行。
通过本文，您了解了一些原则来判断您的 Web 网站功能更像 Web 站点还是 Web 应用程序。无论你决定其样式更具信息性，还是交互性，还是现在刚刚好，重要的是考虑 现在正在做的。现在是在知情的情况下做出决策，而不是在毫不知情的情况下做决策。
现在，打破一些规则，或与本文作者争论一下。我是说，您可以指出哪些东西对您是最适用的。您的具体环境与我不同，与其他任何人也不同。您需要 “编写自己的教程”，这才是最适合的。这是好事。同时，我也希望本文能激发出好的想法。请在本文底部发表评论，可以让我知道哪些是对的，哪些是错的。期望得到您的回复，并了解您的具体环境 — 以及您的 Web 样式如何与具体环境相匹配。
学习
- 可以在 Jakob Nielsen 的 Web 站点 进行任何关于 Web 可用性的讨论，其中有大量文章和资源。
- 可用性与可访问性紧密联系。可用的站点总是可访问性很强的。在 Web Accessibility Initiative (WAI) 上了解更多可访问性知识。
- “User-Centered Design and Web Development”（1998 年 7 月）是篇老文章，但讲解了本文简介部分中重要的细节内容。
- Wikipedia 中的 用户中心设计 有很多拓展阅读的参考和链接。
- Head First HTML with CSS & XHTML（Robson 与 Freeman，O'Reilly Media, Inc.） 是一本介绍 XHTML 和 CSS 的概念丰富的很棒的教程。
- Head First Web Design（Wattral 与 Siarto，O'Reilly Media, Inc.）是一本适合初学者的 Web 设计方面的书，它深入介绍了可用性、颜色、布局、导航，甚至知识产权。
- 查看 HTML5 专题，了解更多和 HTML5 相关的知识和动向。
- developerWorks 技术活动和网络广播：随时关注 developerWorks 技术活动和网络广播。
- developerWorks 按需演示：观看演示，从为初学者准备的产品安装，到为经验丰富的开发人员准备的高级功能。
- 快速获取答案：访问 Web 2.0 应用程序论坛。
获得产品和技术
- Prototype：最佳的 JavaScript 框架，可用于页面设计，能自动化 JavaScript 动作、集成页面效果。
- script.aculo.us：另一个必备工具，script.aculo.us 是一个效果库，可以实现移动、变形、动画以及为 Web 页面添加 GUI 神奇效果。这是 Prototype 驱动网站的理想插件。
- MooTools：轻量级，相当华丽，moo.fx 给 MooTools 添加的内容就像 script.aculo.us 给 Prototype 增加的一样。这是最出色的屏幕效果。
- Fundraiser Insight：Fundraiser Insight 提供几种适合 Web 的温度计，可满足您在网站中加入 fundraising 风格的小部件的需要。
- PHP Fundthermo：这个 PHP 图片生成器专门针对 fundraising，但可根据过程指示轻松调整。
- 以最适合您的方式评估 IBM 产品：下载产品试用版，在线试用，在云环境中使用产品，或花点时间在 SOA Sandbox 中学习如何高效实现 Service Oriented Architecture。
讨论
- 加入 developerWorks 中文社区。
- Web 开发人员可在 Web 开发小组分享您的经验与知识。
- 分享您所知道的：加入关注 Web 话题的 developerWorks 小组。
- Roland Barcia 在博客中谈论 Web 2.0 和中间件。
- 查看 developerWorks 成员的 Web 话题的共享书签。
Brett McLaughlin 是当今企业编程方面的领先权威之一。他曾在 Nextel Communications 和 Allegiance Telecom, Inc. 设计、搭建和实现过企业解决方案，并帮助开发过 Lutris Enhydra 开源 J2EE 应用服务器。他撰写过有关 XML、Java、数据绑定和企业应用程序方面的书籍，亦是 50 余篇企业编程文章的作者。此外，Brett 还是时下所有可用的开源 J2EE 应用服务器 JBoss、Enhydra 和 OpenEJB 的忠实成员。他还是 Apache Turbine 项目 JDOM API for Java and XML 的创始人之一，并参与过大量其他的开源项目。他目前在全球领先的技术类书籍出版社 O'Reilly & Associates 撰写和编辑相关书籍。
