同心圆 :Web应用软件界面设计指南的构架(1)

来源:百度文库 编辑:神马文学网 时间:2024/04/27 10:00:34
用户界面指南(user interface guidelines), 标准(standards), 通用风格指南(corporate style guides), 企业风格指南(enterprise style guides), Web应用软件(Web applications)
引言
挑战
在为一系列Web应用软件创建用户界面设计指南时,我们和很多公司一样面临着困难。我们力图设计出丰富多样的,基于web的软件产品来满足不同用户群体的需要,而作为参考的只有桌面应用程序的相关指南。我们知道技术的限制影响着我们的指南,我们同样希望能使软件易获得、兼容各种浏览器并可本地化。这篇文章将会探讨我们遇到的,也是其他公司经常提出的问题,以及我们如何去克服它们。
我们首先面临的挑战就是Oracle已有的UI指南。它关注的是Java而不是Html,并且适用于窗口层,因此没有提供用例(use-cases)、多重选项、高级组件组合(如模板或者流程),也没有相关例子说明使用方法。我们将使用其他的指南作为范本,放弃原有的指南,因为它太过空泛无法具体、一致地应用到产品中。
其次,新的指南需要适应不断发展的技术——Web应用软件。Web应用软件指南可以从桌面应用程序的UI指南得到借鉴,但这种方法受到其使用性限制。Web应用软件通过浏览器传输,与桌面软件(如:窗口和菜单)相比受控于不同的表现形式(如:以网页为中心)。另外,为了支持跨浏览器的兼容性、国际标准和无障碍性的访问标准,这种基于Html的用户界面在交互性上要弱于桌面应用程序。
第三个问题是基于web的产品的适用范围。我们的设计需要满足100多个不同领域开发的基于web的产品,服务于多种多样的用户群体。
第四,我们缺乏强制和支持来设计和执行一系列的指南。很多开发团队已经在快速开发他们具备独特的外观感受的产品。
为了应对开发Html 界面设计指南的困难,我们制定的指南不仅要能灵活的应用于大量不同的实例和问题,在细节上也要满足所有团队的需要。
我们的解决方案——The Bull’s Eye(同心圆)
我们设计了Bull’s-Eye(同心圆)来解决我们面临的四个挑战。 Bull‘s-Eye(图1)表示了指南的同心圆结构,每一层都是其相邻圆开始由内向外的延伸。在Bull’s-Eye(同心圆结构图)的中心是组件部分,紧接着的是网页模板和网页流程。交互模型或模式在网页流程的上面。Bull’s-Eye(同心圆结构图)最外部的结构是总体特征和原则。

图1:同心圆(The Bull’s-Eye):Web应用软件界面设计指南构架
缺乏HTML的界面设计基础
在形成Bull‘s-Eye的概念和制定标准之前,我们评估了我们已有的设计指南,以及其他软件的指南。对于制定风格指南[2,3,7,11]、图形化用户界面(GUI)指南[1,4,6,16,12,13,5]以及网页风格指南[9] 的考察显示,现有的资源不是过于概括就是过于具体。现有的方法提供的一系列用户界面设计原则(如,设计指南和启发),过于概括而难以在具体的项目上应用,或者它们提供一些标准(如在UI组件或控件层),太过狭隘而无法应用到我们团队所面对的多种多样的项目上。由于篇幅有限,本文中我们无法就此分析做出更多的探讨。现有设计指南的明显不足,促使我们决定制定能适应从UI组件到总体特征的多层次指南。从组件层到流程的多层次指南的概念,成为Bull’s-Eye (同心圆结构图)表现形式的基础。
Web应用软件
作为Web设计指南调查的一部分,我们研究了现有的Web表现形式。我们检查了现有的Web应用软件和Web站点,以及能在Web浏览器环境下运行的桌面元素。在这个过程中,制定出了一系列关于Web应用软件UI设计指南的通用概念,比如:纵向网页 (对应于横行网页), 基于浏览器的分级网页结构, 自由式布局 (对应于GUI风格的窗口、面板和工具条), 和web导航结构,如标签(tab)导航和侧边导航(对应于菜单结构和多重对话界面)。我们发现这些概括性的说法和其他人取得了一致,其他很多人也做出了同样的努力。如Web设计顾问Najjar’在Viant所做的工作 [8], 消费Web应用软件设计师们的工作,以及Zhu在微软的工作[17]. 随后我们将这些结论应用到Bull‘s-Eye(同心圆结构图)中不同层次的指南上。
设计Web应用软件的第二个问题是,基于浏览器的UI界面需要能够支持对各种浏览器的兼容性、国际化和无障碍性。 为了解决这个问题,我们选择了减少界面中一些特定的交互操作,只能在非常有限的情况下使用Javascript,而且基本上不能使用Java applets。
广域、多样的产品线和用户群
我们的产品序列范围从服务器技术、开发工具,到客户关系管理(CRM)、企业资源预算(ERP),一直到商务智能化。多样化的产品和与之相应的用户群体,对于什么是软件经常进行的典型任务,常常衍生出非常不同的界面诠释(图2)。例如,用来筛选产品的操作像“Search”在各个不同的程序中,其外观和操作都是不同的。获取和显示搜索条目与搜索结果列的网页流程设计,在各个软件中并非一致。对于基本对象(如从购买订单到数据库对象)的显示和导航在不同的程序中也是大不相同的;它们在外观和交互行为上都没有任何共同之处。甚至于一些简单的操作,如查看报告在不同的程序中也是各式各样的。对产品序列的检查,显示了程序和划分中UI的不一致性,并且这种问题在网页和网页流程上最为显著。然而,我们确信创建一个跨平台的通用外观是可行的[例如,5]。
同时,我们要面对各式各样的用户群体。例如自助式保险金软件定义其用户为“在公司里能使用鼠标的任何雇员”。从看门人到CEO的任何人,都可以为了他们的保险金而登陆使用该产品。而相反的却是数据库产品,其定义的用户“初学者到专家数据库管理员”——他们都需要有比较高的电脑技术。
为了使不同的程序能具有通用的外观和感受,我们再次转向制定多层指南的概念。指南不仅覆盖网页上单独的UI组件(如搜索网页上的图标),也包括页面布局和网页流程(如搜索网页模板和通用的搜索流程)。
在这一点上,Bull’s Eye(同心圆结构图)解决了在广泛的产品组中创建通用的用户体验的大体问题,但并没有解决在这些产品组中用户群体的多样性问题。如一个基本的搜索网页模板和搜索流程能满足很多程序的需要(和潜在的一些用户群体),但却不能满足所有程序的要求或适应不同用户的技术水平。很明显,指南的每个层次的多重选项需要满足这种多样性。

图2:多样的外观和Oracle的不同产品
缺乏强制和支持
1999年我们收到上级管理部门的一个CEO级别的命令,要求我们采用通用的外观和感受。为使UI指南和标准能够实现,我们需要开展三种适当的基础性的实践:
培训 协调 沟通
培训的范围是从对开发产品的团队提供咨询建议到指南内容的课堂教学。早期在推广这些信息的时候,指南的主要设计者使用了大范围的演讲来介绍指南的所有独立部分。这些演讲常常针对的是特定领域,比如,人力资源领域。在推广的过程中,UI团队为产品团队提供了一对一的咨询建议。这包括将产品的信息结构和工作流程转换为适应指南的界面设计。最后,为那些我们无法开展面对面咨询的开发者开设了一个基于Web的自学课程。
协调所采取的形式包括:
a) 收集产品和用户群的需求;
b) 开发可复用的UI代码;
c) 对指南进行可用性测试,以及
d) 个别产品评测
需求的收集是每周一次,持续不断的跟踪需求的变化,识别出现有指南的提升点,将新的需求增加到的下一版本指南中。开发了一个可复用的UI代码库,用以简化指南的使用,并且增强指南实现的一致性。一个小组被指派到Oracle来开发基于指南的可重用UI代码。与该小组的密切合作成功地采用了指南代码(至于如何定义“成功”容后再述)。为了检查指南的有效性,与可用性工程师合作,这样就有机会不仅对某产品,而且可以对某指南细节进行可用性测试。最后,在各个层面上都进行了产品UI评测,从UI设计师的非正式的评测,到部门副主管的正式评测。
沟通的部门不仅仅是可用性和界面设计部门,还有他们支持的产品团队。定期的指南更新会通过会议和email通知UI设计师、可用性工程师、产品经理、开发人员、主任和副主管们。有了这些适当的基础,我们就完成了指南第一个版本。