2.9 分割的设计阶段

　　原型设计阶段对大多数Web设计人员来说是最有趣的，因为它开始让项目成型。在这个阶段，应该同时开发外观和技术上的原型系统。无论如何，在建立原型系统之前，应该尽可能收集更多的内容。内容本身会影响站点并帮助指导它的形成。如果内容的基调非常严肃而外观却非常有趣和随意，站点对用户来说会非常奇怪。预先看内容有助于统一技术和内容。同时，也应该考虑到收集内容是站点设计中最慢的一个方面。Web项目的参与者很积极地参与集体会议，但一旦需要他们在内容方面上做工作时，却很难找到他们。缺少内容在Web项目中绝对是个大问题。应该预先准备好处理这个问题。

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

2.9.1 块的组合

　　设计应该自顶而下进行。首先考虑一下用户是如何访问站点，又如何结束访问站点的。在大多数情况下，这意味着首先设计主页，再设计子页，最后是内容网页。规则：外观设计应该采用自顶而下的方式，从主页到子页，最后是内容网页。首先在纸上创建以块形式存在的模拟网页，如图2 - 5所示。块的组合允许设计者专注于对象的类型，以及不必在网页上考虑精确的位置和细节的组织。块分区法能有助于设计者创建网页模板，它会使后来的实现更加容易。确信你所创建的合成块是满足Web浏览器窗口的约束条件的。浏览器边界的影响是一个非常重要的因素。网页块的组合效果图在h t t p : / / w w w. Web d e s i g n r e f . c o m . / c h a p t e r 2 /中可以找到。一旦网页块的组合设计好后，其他类型的网页也可以按同样的方式设计。如果完整的方案已经很详细，应确信到每个网页块的路径是合乎逻辑的。这样，就可以继续下一阶段。

2.9.2 屏幕和纸张的组合图

　　下一设计阶段就是纸张或屏幕原型阶段。在这个阶段，设计者应画出草图，或实现站点某个典型网页的组合。无论是在纸上或屏幕上，一定要确定考虑了浏览器窗口或者屏幕的尺寸。块组合阶段使用的带有浏览器窗口轮廓的纸张可以用来做草图。建议：在开发外观组合图时，一定要考虑浏览器窗口的边界效果。画出各种各样效果的按钮、标题以及特征网页的草图，如果可能，在网页中提供一些文本说明，即一些缩写文本，或者真实文本。注意很多设计者在屏幕组合中仅使用一些类似文本的东西。尽管这种方法更有利于设计者专注于设计网页的要素，但如果可以得到真实的文本，应尽量使用它，这样有助于模仿最终的效果。

　　组合阶段提供了很大的创造空间，但应该提醒设计者在Web的可能限制下进行创作，并且同时考虑Web规范说明书中的外观需求，考虑到文件的大小、颜色支持情况以及H T M L样式可能受限制，这可避免设计者提出外观极好但无法实现的网页。尤其是要防止为了追求艺术性而重新设计站点结构的行为。记住，站点规划会清楚地说明外观需求，包括市场营销的限制。第1章已讨论了在形式、功能、目标和内容之间进行平衡的困难，当设计者企图在Web技术、用户能力和站点需求等约束条件下满足自己的创造欲望时，这种平衡的困难会变得更加明显。典型的网页组合图如图2 - 6所示。

　　在创建原型时，应创建一个显示整个屏幕包括按钮、图像和文本的单个图像。把这个图像保存为G I F或J P E G的图像格式，并用浏览器加载测试在典型环境下它的效果。在这个阶段，应该尽量避免完全用H T M L实现网页。你有可能不得不废弃设计，再次实现会很浪费。一旦纸上或屏幕上的原型完成，就应该和用户一起测试。问一些用户，为了完成特定任务哪些部分会被点击，哪些按钮会被选择。确信不只是向一个用户显示原型系统，因为个体的品位是决定原型的接受程度的重要因素。如果用户对网页有太多的负面评价，应该考虑重新返回原来的设计阶段。在原型阶段，不能太关注你的作品。如果是这样，站点就不会以用户为中心，而是以开发者为中心。记住以下的设计规则：

规则：和原型系统保持距离。倾听用户并提炼的设计。

　　一旦提出了一个可以接受的主页设计，就继续进行子页设计和内容网页设计。一个典型的子页组合图如图2 - 7所示。

　　对于高度交互的站点，可能必须为特定的任务如购买或下载的每一步骤设计原型网页。这种类型的网页必须设计得更加详细，应该包括如窗体输入框的标题等其他非常有用的细节。一个交互性更强的纸上组合物的例子如图2 - 8所示。

　　尽管不是所有的站点都需要技术原型，高度交互的站点不应该只考虑界面原型，应该包括显示诸如数据库查询、个性化、电子商务等如何运作的概念原型。不幸的是，大多数情况下，直到界面完成时才会考虑技术原型，这通常会导致工作的重复。

2.9.3 模拟站点

　　在完成所有原型后，就到了创建模拟站点或a l p h a站点的时候。模拟站点的实现始于把组合体拆分再用H T M L把网页组合在一起，也可能用层叠样式单。尽量用模板，这样整个站点的组合会快一点。尽量采用符号代替文本，除非有些地方需要用真实的文本测试方案。一旦模拟站点组合好，站点应该完全可以浏览，尽管虽然包含的只是一些空的内容和空洞的交互。一个模拟站点的例子可以在h t t p : / / w w w. Web d e s i g n r e f . c o m / m o c k s i t e中找到。在这个意义上，让一些用户来试一试这个模拟站点是个好主意。看看站点是否易于浏览以及响应是否快。如果用户在完成一些任务时存在困难，最好考虑废弃设计并返回软件开发的前一阶段。一般来说，这种情况不会发生，除非站点超安全设计或站点很少接受用户的反馈信息。

2.10 Beta版站点实现

　　一旦模拟站点可以接受，就可以着手实现真实的站点。真实的内容应该放在网页上，后端构件和交互的要素也应该与最后的外观设计集成为一个整体。这里要讨论的技术和实现问题太多，第1 0章到第1 3章会单独讨论这些问题。尽管实现看起来是项目最消耗时间的方面，但如果所有的构件已经收集好并且已经实现好原型，实际的站点实现做起来会比较快。

2 . 11 测试

　　对大多数程序员来说，测试可能是Web开发过程中最不喜欢的一个方面。在完成了所有艰苦的任务如规范说明书、设计和实现后，大多数程序员只是准备好发布。应该防止这种冲动。对积极的用户综合印象来说，测试是非常关键的。在发布后，不要促使用户测试站点。如果他们在实现好的站点上遇到一个问题，他们是不会原谅的。一定要记住以下设计规则：规则：站点一定会存在一些问题，必须好好测试你的站点。

　　不幸的是，Web站点的测试经常就是简单的归为用浏览器快速地访问站点，或者检查站点的链接体。问题一定会在站点中存在，无论是什么样的。不幸的是，大多数开发者认为只要站点的外观看起来没有问题，它就是没有问题的。记住第1章中所说的，站点设计不只是仅仅包括外观设计：必须同时测试站点的其他方面，就像以下规则所综述的：

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

　　附录B详细讨论了站点的评估和测试，尤其是针对完成的站点。这里简单综述一下Web的测试。 1. 外观可接受度测试外观可接受度测试可以保证Web的外观与设想的一致。浏览站点的每个网页，确信它们在样式、颜色和风格上一致。用不同的浏览器和分辨率或与真实用户一致的浏览环境来浏览网页。用浏览器快速地访问站点，看看样式是否一致。在浏览站点的同时，注意寻找样式不规则的地方。外观可接受度测试可能要求每一个网页都打印出来。记住不要专注于为在线消费设计的打印测试网页。 2. 功能测试既然大多数网页的基本功能就是在屏幕上显示自己，功能测试和外观测试在某种意义上经常重叠。然而，大多数站点至少包括导航这样的基本功能。确信检查了站点上每个链接体并校正了每个断开的链接体。断开的链接体应该当作一个非常严重的错误。确信测试了诸如窗体这样的交互元素。通常采用现实情况和极端情况这两种测试条件。通过输入明显的错误来测试窗体。记住，用户不会按照你所想的行事，尽量考虑一些不可预料的情况。 3. 内容验证站点的内容细节很重要。确信所有的内容都是合适的且词语的用法保持一致。检查诸如产品名、版权日期和商标等细节。一定要记住检查单词的拼法。客户和用户会仅因为一个印刷错误而认为整个站点很糟糕。这种重要性怎么强调也不过分。进行测试的最好办法是把每一个网页打印出来并认真阅读每一行。 4. 系统和浏览器兼容性测试在开发时可能就考虑到了系统和浏览器的限制，但测试时一定要验证。在浏览站点的时候，一定要用用户会使用的同样类型的系统和浏览器。不幸的是，大多数情况下测试用的系统比用户采用的系统一般要强大些。项目规划应该有详细的浏览器需求，一定要让站点用指定的浏览器访问时非常顺利。 5. 发送测试检查一下站点发送得是否充分。在用户的真实条件下浏览站点。如果站点是为“美国在线”的调制解调器用户设计的，建立一个“美国在线”用户账号，用调制解调器测试站点发送速度。为了模拟站点流量，考虑用测试软件创建虚拟用户点击站点。这会模拟出站点的响应速度。测试时一定要用真实的服务器和大致相同的系统。一定不能低估站点发送的影响。在设计规范说明书时，如果对此考虑得不够充分，整个项目可能偏离轨道。关于发送条件的更多信息，请参看第1 4章。用户接受程度测试用户接受程度测试应该在站点看起来正常后进行。对于软件，这种测试通常成为B e t a测试。让用户使用站点，并做最后一次的评价。不要直到明显的错误被校正后再进行这种测试，就像下面规则所说的。

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

　　因为用户测试最接近真实的用户，所以它是最重要的测试形式。如果问题没被发现，你可能不立刻纠正错误。如果问题不是很大，你仍可发布站点，而迟些时候再纠正。然而，如果发现了严重的问题，最好延期发布直到问题被纠正。

2.12 发布和以后的问题

　　如果站点准备发布，不要放松—你还没有发布。实际上，你的工作仅仅开始。现在是观察站点实际运作情况的时候了。站点是否符合用户的期望？站点的开发目标是否已达到？是否还需要其他的校正？底线是站点必须继续运行。新的特征可能需要，为了适应技术更新而升级是不可避免的。为了满足市场需要而改变外观也非常可能。这样就开始了被成为维护的持续开发过程。一旦瀑布模型的最后阶段完成，就应该重新返回起始阶段，正如以下规则所述：

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

2.13 欢迎来到真实世界

　　尽管站点的开发过程看起来非常直观，但它并不是一直都很顺利。对真实世界来说，存在太多的变化。例如，考虑为某个人如老板或客户设计站点。如果某个人为创建某个站点掏钱，你可能需要把他的想法掺杂进去，而不管需求是否与用户的想法一致。一定要劝说别人在做决定时考虑用户的想法。一定要显示设计理论的优越而不是鼓吹规则。做好举一些你的想法的例子的准备。然而，必须做好接受你的想法被别人抛弃的准备。

　　注意有经验的设计者会准备很多站点组合以备讨论。与为顾客准备的发型书相同，用户所想的是很难用词语描述。

　　大多数站点项目容易存在争端问题。不要指望任何人都同意。公司的部门会争夺控制权，这种情况经常出现在技术部门和市场部门之间。会有数不清的自称Web专家的人给出建议，这会激起更多麻烦。如果某人的兄弟的朋友声称用微软的F r o n t P a g e自动化工具在一小时内建好一个站点，不要感到惊讶。解决争端的唯一方法是耐心并尽量地说服别人。没有一个适当而清晰的规范说明书，开发者会发现自己处于一个容易受到攻击的不稳定位置。

　　一定要记住，遵循某个进程模型的目的是减少Web项目中出现的问题。然而，一个进程模型不能考虑现实世界中的所有问题，尤其是关于人的问题。经验是处理很多问题的唯一老师。Web 项目中缺少经验的开发者会被鼓励摸滚打爬，从而在克服障碍时获得经验。

2.14 小结

　　建立一个现代的站点非常具有挑战性，所以站点开发者应该采用一种方法学或进程模型来指导开发过程，从而有希望减小风险和管理的复杂性，并且改进最终结果。诸如修正瀑布模型的软件工程进程模型在大多数Web项目中很容易应用。然而，有时候，由于缺乏项目管理经验或清晰的目标，应该采用一种原型驱动方法或联合应用方法。通常，基于原型的方法更适合站点的自然特性，减少不必要的风险，在开发出合适的站点之前反复进化。在站点开发早期阶段进行规划，可以减小风险并提高最后的开发质量。应该撰写一个包括站点目标、访问者、任务分析、内容需求、站点结构、技术需求和管理考虑的内容设计文档。设计文档应该指导站点的实现。在站点实现时，应该利用块结构图、纸张模拟图、情节说明图板、甚至模拟站点来减小后来重新设计站点的可能性。在规划详细且原型实现好后，实现就应该很快速，而需要重复的工作量很小。然而，一旦完成，不要急于实现在线访问—充分的测试是必要的。长时间的维护是必要的，持续的警惕也是必要的，否则你的站点会开始恶化。