Current Issue
The Bull’s-Eye: A Framework for Web Application User Interface Design Guidelines(2) - 26 September 2006
by Betsy Beier and Misha W. Vaughan
Read this article in Chinese (translated by Heli Lv, proofread by Shuzhong Zhao)
CONTENT & STRUCTURE OF THE GUIDELINES
We have laid out the challenges, as well as the framework and its multi-tiered approach, which is similar to other efforts to document UI patterns in web application flows and structures [e.g., 14, 15] A more detailed discussion of the structure and composition of the guidelines follows.
Figure 3. Sample Guidelines Components, Page Template, & Page Flow
Components
Component guidelines, the first level of guidelines, outline specific UI widgets that have multiple interaction possibilities and options, depending on the content or functionality required by an application. Components can be simple UI elements, i.e., buttons, standard Web widgets, instruction text. They can also be more complex UI elements, i.e., tab navigation structures, table configurations and behaviors, and tree components, similar to the notion of idioms [13]). Figure 3 provides examples of several components covered in the guidelines, including Branding, Action/Navigation Buttons, Global buttons, Tabs and Navigation, and Tables. There are currently over 37 component guidelines, ranging from simple to complex.
Examples of additional Components include Advertising, Locator Elements (e.g., Train, Breadcrumbs), Headers/Subheaders, Links, Content Containers, Hide/Show widgets, and a Page Footer.
Page Templates
At the next level are Page Templates. Page templates are comprised a combination of Components on a page. For example, an Attachments Page shows the UI components for situations when documents or notes need to be added to an object in an application. Within each Page Template guideline there may be multiple Component choices and layout options, each slightly different but all satisfying the same overall goal of consistency. The multiple options help satisfy the requirements for the broad range of users and applications supported. Figure 3 shows an example of an Update Page Template. This template indicates the
placement of general components (e.g., Page Headers, Breadcrumbs) as well as specific components (e.g., attribute tables).
There are currently 30+ Page Templates in the guidelines. Examples of additional Page Templates include, Home Page Template, Overview/Summary Page Template, Search Page Template, Object List Templates, Object Templates, and a Step by Step/Wizard Page Template.
Page Flows
Page Flows are the third level in the Bull’s-Eye, and consist of combinations of Page Templates (i.e., Add an Attachment Flow). This level of guideline outlines a combination of Page Templates with contents that form a common task flow. There are currently 20+ page flows in the guidelines. One example of a Page Flow is the Create/Add/Update/Delete an object Page Flow (Figure 3).
This Page Flow handles the scenario of a user viewing a summary list of objects, then selecting an action and drilling down to the appropriate update, duplicate, or delete page. These are similar to notion of UI patterns Other types of Page Flows include: Search and View results, Browse and Find an Object, Update Preferences,
Manage Attachments, Export/Import, Customization of Tables, Intra-Application Navigation, and Inter- Application Navigation.
Interaction Models and Patterns
After Page Flows are Interaction Models and Patterns.
These are groups of Page Flows that support a particular genre of application, such as ecommerce, portal, or administration applications. Each of these UI Models is a base consisting of a combination of common Page Flows and Page Templates, along with customizable aspects. For instance many ecommerce applications share a common set of tasks that can be supported by a base set of Page Templates and Page Flows. For example, the base UI model for an ecommerce application includes a Home Page Template, a Browse and/or Search Page Flow, an Item Detail Page Template, a Shopping Cart Page Template, a Purchasing Page Flow, and a Confirmation Page Template.
These models emerge as we work with teams to apply the guidelines and find a consistent set of commonalties. By creating these UI Models, we ease each team’s initiation of their design process; we are able to indicate to a team the set of Page Templates and Page Flows that are most likely to relate to their application.
Overarching Features and Principles
Surrounding the entire Bull’s-Eye are Overarching Features and Principles. These guidelines provide heuristics and standards that are used throughout the concentric circles to maintain a consistent user experience from component to UI Model.
Examples of these Features and Principles include Object versus Action Orientation, Art Direction Standards, Language in the UI, and Accessibility Standards.
Object Versus Action Orientation
The overall structure of an application implementing the Bull’s-Eye is an object-centric model. Content in applications is grouped around objects (or groups of objects) that form large functional areas of the application.
Actions are surfaced from within the page contents, and/or the context of the object(s).
Art Direction Standards
The Art Direction standards (Figure 4) are composed of a Language Guideline, a Color Palette Guideline, Art Direction Guidelines, Ancillary Graphic Style Guidelines, and Cascading Style Sheet Text Standards. The highlights of the standards include:
Figure 4. Sample Art Direction Standards
A predominantly blue and white palette with beige accents
- Complementary round and square shapes throughout
- Visual hierarchies of information displayed through
size and navigation depth - Sans-serif typeface
- Minimizing rendered icons
- Simplified, stylistic graphics in content
- Common terminology and grammar rules
Support of Other Standards
The guidelines also had to adhere to other standards within the company. For instance, applications are translated into 28 languages. The guidelines must follow common translation and natural language support heuristics. Other standards that needed to be supported were the Federal Accessibility guidelines (i.e. Section 508 compliance), corporate Abbreviation guidelines, and corporate Keyboard Shortcut standards.
Common Code Standards
As mentioned earlier, in order for the Bull’s-Eye to achieve its goal of creating a common look-and-feel across Oracle applications, it needed a unifying integration point with all applications — a common code base supporting the UI standards. Common code that supports each individual UI guideline greatly reduces variance and divergence from the standards. This code base was driven in part by the development schedule of the guidelines, but also by demand for the common code from all of the product teams.
The need for a common code base also drove, in part, the need to develop the guidelines from the inside out, i.e., starting with Components. It would be difficult to start coding common Page Templates or Page Flows, without having common Components already in place.
Structure of a Guideline
Each of the guideline levels mentioned above, Components, Page Templates, Page Flows, UI Models and Patterns, and Overarching Features and Principles, are communicated in a consistent format (Figure 5). This format eases use and maintenance of the guidelines.
Each guideline is documented in HTML, and posted as part of a complete guidelines Web site (publicly available at: http://otn.oracle.com/tech/blaf/). Each guideline is composed of several sections, including:
- A general description of the guideline.
- Guideline attributes, including a contact person from the UI group, a list of contributors, version number, products or product families using the guideline, and links to related guidelines.
- Interaction and usage scenarios for the guideline, including general principles of use, options for the given component/template/etc., and page flows indicating how the component/template relates to other parts of the guidelines.
- Visual specifications for the guideline that detail the color, size, minimum/maximum values, etc., and provide visual examples of the options for this component/template/flow.
- Usability data where test results validate components, templates, or flows. These tests may be product specific tests, or guidelines-wide tests. Usability tests are ongoing and their data are incorporated into each guideline as results are available.
- Open and closed issues pertaining to the guideline.
Earlier we mentioned the value of tying the guidelines to UI code. A coding team meets with our lead guidelines designer in an on-going basis, and tracks the development of each component to an actual guideline.
Figure 5. Structure of a Guideline
VALIDITY OF THIS APPROACH
On its face, we believe the structure and content of the guidelines (in particular the multi-tiered nature of the guidelines) to be valid because they were developed with the assistance of UI designers, usability engineers, product managers, and development managers across the company.
The process involved each team sending a representative to a standing, weekly meeting to discuss new requirements with the lead guidelines developer. New requests would be examined to determine if they could be met using existing guidelines. If not, then they were tracked to determine how broadly they ranged across applications, i.e., one team’s need for a UI widget might reflect a larger need for the component. If multiple instances of the need were apparent, then the lead guidelines designer would work with all impacted teams and UI designers to develop a solution.
Several heuristics were used to assess and refine the solution:
- Was it compatible with or did it break the existing UI design guidelines?
- Was it scalable and extensible, i.e., could it handle very small sets of objects as well as very large sets of objects?
- Was it accessible to a screen reader?
- Could it be internationalized, e.g., did it handle 30% expansion for other languages and bi-directionality?
- Was it technically feasible from a coding perspective?
- Was it a usable design?
As each team indicated its requirements and participated in the design process, the multiple-levels of the guidelines took shape.
However, each team agreeing on the final output was not an indication that the designs in the guidelines were actually usable. To assess this more empirically, we conducted usability testing in both a top-down and bottom-up fashion, as another check on the guidelines validity.
From the top down, we targeted specific guidelines for usability testing. These tests had to be eneralizable to the entire product suite and range of users. To accomplish this we did the following: a) recruited three to four users per user type from across the different domains, b) developed tasks and content that were domain agnostic (e.g., working with human resources data or an employee directory), and c) developed our test plans, prototypes, and conducted our testing under constant peer-review. Various Page Components (e.g., page-level buttons), Page Templates (e.g., table personalization), and Page Flows (e.g., the save model) have been subjected to this kind of guidelinetargeted usability testing.
From the bottom-up, we monitored our on-going product usability testing for guidelines issues. If we identified a potential usability issue with a guideline, then that issue was flagged by the usability engineer and communicated outward. Other engineers with products that had implemented similar components, pages, or flows, then determined if this was a recurrent issue. A guidelinespecific test could be called for to design and test a new
solution.
Finally, we can assess the validity of our approach by the
degree of buy-in from upper management, and the degree of adoption by product teams. In December of 1998, Oracle had products with no common look-and-feel. In February of 2000, upper management called for use of the guidelines for all Web-based applications. By December of 2000, teams across all Web-based products were using the guidelines; over 100 Web-based applications have been implemented using the guidelines. In addition, the guidelines were published on the Oracle Technology
Network (http://otn.oracle.com/tech/blaf/) so that customers could build matching custom applications that integrate with Oracle applications.
LESSONS LEARNED
One challenge in growing the guidelines has been the tension between maintaining consistency across applications versus designing for each applications’ unique needs. We address these requests by requiring that teams provide validation (e.g., documentation, usability data, user requirements data) that their needs are indeed unique.
Another challenge was the sheer task of maintaining the guidelines documentation. With each modification of the guidelines, a ripple of changes must be made throughout the documents. What began as a one-person project, has now grown to include three full-time personnel, plus cross-group collaborators. This team exists as a Standards group within (and is funded by) Usability and Interface Design.
A third challenge has been incorporating the requirements of external groups (e.g., system performance, accessibility compliance, and cross-browser compatibility) into the guidelines. To develop guidelines that are responsive to these external forces, we recruited allies throughout the organization with special knowledge in each of these areas to provide consultation and insight.
CONCLUSION
The Bull’s-Eye framework and the resulting set of guidelines are a step forward from where we started. The levels of the Bull’s-Eye provide a framework for thinking about how all the types of guidelines work together, from the general principles to the specific components. With this framework we bridged the gap left by other guidelines and standards, as well as designed for a wide range of users and application domains.
ACKNOWLEDGMENTS
We would like to thank the anonymous reviewers of this paper, as well as, Dr. Elizabeth Boling, Lawrence Najjar, Michelle Bacigalupi, Daniel Rosenberg, Dr. Anna Wichansky, and Irene Wong for feedback and comments. In addition, this work would not be possible without the often invisible, but always invaluable, hard labors of our fellow user interface designers, usability engineers, product managers, and developers at Oracle.
REFERENCES
1. Apple Computers, Inc. Macintosh Human Interface Guidelines. Addison-Wesley, Reading, MA, 1992.
2. Gale, S. A collaborative approach to developing style guides, in Proceedings of CHI ’96 (Vancouver Canada, April 1996), ACM Press, 362-367.
3. Henninger, S. Haynes, K., Reith, M. W. A framework for developing experience-based usability guidelines, in Proceedings of DIS ’95 (Ann Arbor MI, August 1995), ACM Press, 43-53.
4. IBM Corporation, Object-Oriented Interface Design: IBM Common User Access Guidelines. QUE, Carmel, IN, 1992.
5. McFarland, A. & Dayton, T. Design Guidelines for Multiplatform Graphical User Interfaces [Document # LP-R13]. Bellcore, Piscataway, NJ, 1995. Available at: http://telecom-info.telcordia.com/site-cgi/ido/index.html
6. Microsoft Corporation, The Windows Interface Guidelines for Software Design. Microsoft Press, Redmond, WA, 1995.
7. Miller, A. Integrating human factors in customer support systems development using a multi-level organisational approach, in Proceedings of CHI ’96 (Vancouver Canada, April 1996), ACM Press, 368-375.
8. Najjar, L. J. E-commerce user interface design for the Web, in M. J. Smith, G. Salvendy, D. Harris, & R. J. Koubek, Usability evaluation and interface design: Cognitive engineering, intelligent agents, and virtual reality, Vol. 1, Erlbaum, Mahwah, NJ, 2001, 843-847.
9. Ohnemus, K. R. Web style guides: Who, What, Where, in Proceedings of SIGDOC ’97 (Snowbird UT, Month 1997), ACM Press, 189-197.
10. Oracle Corporation. Oracle Applications User Interface Standards Release 11. [Part # A58193-01]. Redwood Shores, CA, 1998.
11. Roszenweig, E. Design guidelines for software products: A common look and feel or fantasy? Interactions, 3(5), (September/October 1996), 21-26.
12. Sun Microsystems, Inc. Java Look and Feel Design Guidelines [2nd ed]. Palo Alto, CA, 2001. Available at: http://java.sun.com/products/jlf/
13. Sun Microsystems, Inc. Java Look and Feel Design Guidelines: Advanced Topics [2nd ed]. Palo Alto, CA, 2001. Available at: http://java.sun.com/products/jlf/
14. Tidwell, J. UI Patterns and Techniques: About Patterns. May, 2002. Available at: http://timetripper.com/uipatterns/about-patterns.html
15. van Duyne, D. K., Landay, J. A., & Hong, J. I. The Design of Sites. Addison Wesely, 2002.
16. Weinshenk, S. & Yeo, S. C. Guidelines for Enterprise-Wide GUI Design. John Wiley & Sons, New York, NY, 1995.
17. Zhu, W. Designing and evaluating a Web-based collaboration application: A case study, in M. J. Smith, G. Salvendy, D. Harris, & R. J. Koubek, Usability evaluation and interface design: Cognitive engineering, intelligent agents, and virtual reality,
Vol. 1, Erlbaum, Mahwah, NJ, 2001, 838-842.
Since Betsy Beier and Misha W. Vaughan published it on ACM in April,2003, this article has been cited numerous times as a classic article in user interface guidelines design. It is published in uiGarden including two parts, and this is the second one.
Comments made
Possible Related Articles:
Latest Comments