我们已经指出了困难，还有框架和它的多层次方法，像web软件流程与结构的UI模式文档一样，付出了很大的努力[比如14, 15]。接着会对指南的结构和组成进行更加详细的论述
组件
组件指南，是指南的第一层，概括了具体的UI 控件，它们根据应用程序所需要的内容或功能,具有多重交互可能和选项。组件可以是简单的UI元素，例如按钮，标准Web 控件,说明文字。也可以是较复杂的UI元素，即标签导航结构，表格结构和行为，以及树状结构，相似于约定俗成的概念 [13]。图3提供了指南中的多个组件实例，有品牌标识、动作/导航按钮、全局按钮、标签和导航以及表格。目前有超过37个组件指南，从简单的到复杂的。附加的组件例子包括广告、定位元素（例如顺序,面包屑路径（Breadcrumbs））、标题/副标题、链接、内容容器、显示/隐藏控件和网页底部。
网页模板
下一层是网页模板。网页模板是由网页上的组件组合组成的。比如，在一个应用程序中向一个对象加入文档或注释，附属网页就要在适当的位置显示UI组件。每个网页模板指南可以有多个组件选择和布局选项，每一个稍有不同，但所有都符合一致性的总体目标。这些多重选项支持应用程序来满足大范围的用户需求。图3是一个更新网页模板的例子。这个模板显示了一般组件的放置位置(比如，标题，面包屑路径（Breadcrumbs）)，也有特殊组件(如属性表格)。
目前在指南中有超过30个网页模板。附加的网页模板例子包括主页模板、总览/摘要网页模板、搜索网页模板、对象列表模板、对象模板和分步的/向导模板。
网页流程
网页流程是Bull’s Eye的第三层，由各个网页模板组合而成(举例：增加一个附件的流程)。指南中的这个层次阐述了网页模板的组合，它们所载的内容形成了一个通用任务流程。目前指南中有超过20个网页流程。网页流程的一个例子是创建/添加/更新/删除一个对象的网页流程(图3)。这个网页流程处理了这样一个情景：用户查看对象概要列表，然后选择行为并转到适当的更新、复制或删除页面。这和UI模式的概念相似。
其它类型的网页流程包括：搜索和查看结果、浏览和查找对象、更新属性、管理附件、输出/输入、表格定制、应用程序内导航和跨应用程序导航。
交互模型与模式
网页流程之后是交互模型与交互模式。它是网页流程组，能够支持特定类型的应用程序，比如电子商务、门户或管理程序。这些UI模型基本上是由通用网页流程组合和网页模板组成的，并带有可定制的外表。比如很多电子商务程序共享一个通用任务集，它就可以由一系列基本的网页模板和网页流程来支持。例如，电子商务程序的基本UI模型包括主页模板、浏览和/或搜索流程、项目详细信息模板、购物车模板、购物流程和确认模板。
当我们以团队形式应用这些指南，并探寻众多软件的一致性时，这些模型显现了出来。通过创建这些UI模板，我们可以简化每个团队设计过程的开始部分；我们可以为团队指明这一系列的网页模板和网页流程的集合与他们的应用程序最有关系。
总体特点和原则
围绕整个Bull’s-Eye的是总体的特点和原则。这些指南提供了贯穿同心圆的探索和标准，从而保证了从组件到UI模式的用户体验的一致性。这些特征和原理的例子有对象导向vs行为导向、美术指导标准、UI中的语言和无障碍性标准。
对象导向vs行为导向
一个全局结构上实现了了Bull’s-Eye的应用程序，是一个以对象为中心的模板。应用程序中的内容是围绕对象组成的(或对象组)，组成了应用程序大的功能性区域。行为是网页内容和/或对象的语境的表面。
美术指导标准
美术指导标准(图4)包含了语言指南、颜色指南、美术指导指南、辅助图形风格指南和CSS文字指南。标准中的重点包括：
对其它标准的支持
指南也必须与公司内其它的标准相关联。比如，应用程序被翻译成28种语言。指南必须遵循通常的翻译和自然语言支持探索。其它需要被支持的标准有联邦无障碍指南(即508部分的兼容性)、通用缩写指南和通用键盘快捷键标准。
通用代码标准
在较早的阐述中，为了让Bull’s-Eye达到建立一个通用的跨Oracle应用程序的感观，需要一个集成所有应用程序的统一点－一个支持UI标准的通用代码基础。通用代码支持各个单独的UI指南，很大程度上减少标准中的不同和分歧。这个代码基础由指南的开发进度驱动，但也由所有产品团队对于通用代码的需求驱动。
对于通用代码基础的需求也地驱动了开发从内到外的指南的需求，例如从组件开始。如果不用已有的通用组件，对通用网页模板或网页流程进行编码将会非常困难。
指南的结构
以上阐述的各个指南的层次、组件、网页模板、网页流程，UI模型和模式和总体特点和原则，都是以一致的格式进行交互的。这个格式简化了指南的使用和维护。
各个指南是以HTML做文档，作为完整的指南网站的一部分(可在以下网址获得公开资料：http://otn.oracle.com/tech/blaf/)。各个指南由几个部分组成，包括：
之前我们提到了把指南和UI代码捆绑的价值。一个编码团队和我们的首席指南设计师保持持续的基础会谈，并跟踪一个实际的指南的各个组件的开发。
我们相信指南的结构和内容(尤其是指南的多层次性)是有效的，因为它们是在整个公司的UI设计师、可用性工程师、产品经理，以及开发经理的协助下完成的。
这个过程需要各个团队派出一名代表参加固定每周一次的会议，和首席指南开发师探讨新的需求。并检验新的请求在现有的指南下能否得到满足。如果不能，就要跟踪确定它们在应用程序的影响范围，例如一个团队对UI控件的需求可能会反映出对组件的需求。如果出现多个需求的情况，首席指南设计师就会会同所有受到影响的团队和UI设计师来开发一个解决方案。
几个启发性问题会用来评估和优化方案：
各个团队指出需求并加入到设计过程中，从而形成了指南多层次的格局。
但是，各个团队同意最终成果并不能证明指南的设计是有用的。要进行更有根据性的评估，我们以两种方式进行了可用性测试，从上至下和从下至上，作为另外的指南的有效性测试。
从上至下，我们针对明确的指南进行了可用性测试。这些测试必须是可以在整个产品组和用户范围内可推广。要达到这个目的，操作如下：
a)招募了三到四个用户，每个用户来自不同的领域；
b)开发的任务和内容是未知的领域(比如，要使用人力资源数据或雇员名单)；
c)制定我们的测试计划、原型，以及建立我们固定的一对一评估测试。
不同网页组件(例如，网页上的按钮)、网页模板(例如，个性化表格)和网页流程(例如，保存模式)，都要接受这种针对指南的可用性测试。
从下至上，我们监控了正在进行的针对指南问题的产品可用性测试。如果我们指出了指南中一个潜在的可用性问题，那么这个问题就会被可用性工程师标明并与外部人员进行沟通。然后由创建了类似的组件、网页或流程的其他工程师来决定，这个是否是一个要重新进行的问题。一个具体指南的测试，可能导致一套新的设计和测试的解决方案。
最后，我们通过高级管理层的认可程度和产品团队的接纳程度，来评估我们方法的有效性。1998年的12月，Oracle的产品没有一致的外观和感受。2000年2月，管理层决定把指南应用于所有的网络应用程序。至2000年12月，所有的网络产品团队都在使用指南；有超过100个已实现的网络应用程序使用了指南。另外，Oracle技术网络上(http://otn.oracle.com/tech/blaf/)发布了指南，因此客户可以开发能够集成Oracle应用程序的自定应用程序。
开发指南时的一个问题是，维持跨程序平台的一致性与满足各个应用程序的独特需求之间的矛盾。我们指明，让提出这些需求的团队来提供这些需求是独一无二的确认(比如文档、可用性数据、用户需求数据)。
另一个问题是保证指南文档的纯粹的任务。文档的每个修改，会波及到整个文档中。刚开始时是一个人的工作，现在已经发展成包括三名全职职员，外加跨团队的协作人员。这个团队作为一个标准组存在于（并受资助于）可用性和界面设计团队。
第三个问题是引入了外部组(比如系统性能、无障碍兼容和跨浏览器能力)的需求到指南中。要开发出能回应这些外部压力的指南，我们招募了公司内拥有这些领域相关知识的盟友，来为我们提供咨询和见解。
Bull’s-Eye框架和指南的成果是一个跨越。Bull’s-Eye的层次提供了让所有类型的指南一起运作的框架，从总体的原则到具体的组件。有了这个框架，我们补充了其它指南和标准的空缺，也能够为广泛的用户和应用程序领域进行设计。
联系客服
