HP OpenView Application Style Guidestudent.ing-steen.se/unix/hp-ux/J1261-90001.pdf · 2 Legal...

HP OpenView Application Style Guide

Edition 1

J1261-90001

HP-UX, Solaris, and Windows NT® Operating Systems

November 1998

© Copyright 1998 Hewlett-Packard Company

2

Legal NoticesHewlett-Packard makes no warranty of any kind with regard to thismanual, including, but not limited to, the implied warranties ofmerchantability and fitness for a particular purpose. Hewlett-Packardshall not be held liable for errors contained herein or direct, indirect,special, incidental or consequential damages in connection with thefurnishing, performance, or use of this material.

Warranty. A copy of the specific warranty terms applicable to yourHewlett- Packard product and replacement parts can be obtained fromyour local Sales and Service Office.

Restricted Rights Legend. All rights are reserved. No part of thisdocument may be photocopied, reproduced, or translated to anotherlanguage without the prior written consent of Hewlett-PackardCompany. The information contained in this document is subject tochange without notice.

Use, duplication or disclosure by the U.S. Government is subject torestrictions as set forth in subparagraph (c) (1) (ii) of the Rights inTechnical Data and Computer Software clause at DFARS 252.227-7013for DOD agencies, and subparagraphs (c) (1) and (c) (2) of theCommercial Computer Software Restricted Rights clause at FAR52.227-19 for other agencies.

HEWLETT-PACKARD COMPANY3404 E. Harmony RoadFort Collins, CO 80528 U.S.A.

Use of this manual and flexible disk(s), tape cartridge(s), or CD-ROM(s)supplied for this pack is restricted to this product only. Additional copiesof the programs may be made for security and back-up purposes only.Resale of the programs in their present form or with alterations, isexpressly prohibited.

Copyright Notices. © Copyright 1983-98 Hewlett-Packard Company,all rights reserved.

Reproduction, adaptation, or translation of this document without priorwritten permission is prohibited, except as allowed under the copyrightlaws.

Contains software from AirMedia, Inc.

3

© Copyright 1996 AirMedia, Inc.

Trademark Notices

Java™ is a U.S. trademark of Sun Microsystems, Inc.

Microsoft® is a U.S. registered trademark of Microsoft Corporation.

Windows NT® is a U.S. registered trademark of Microsoft Corporation.

Windows® and MS Windows® are U.S. registered trademarks ofMicrosoft Corporation.

Netscape™ and Netscape Navigator™ are U.S. trademarks of NetscapeCommunications Corporation.

Oracle® is a registered U.S. trademark of Oracle Corporation, RedwoodCity, California.

Oracle7™ is a trademark of Oracle Corporation, Redwood City,California.

OSF/Motif® and Open Software Foundation® are trademarks of OpenSoftware Foundation in the U.S. and other countries.

Pentium® is a U.S. registered trademark of Intel Corporation.

UNIX® is a registered trademark of The Open Group.

Contents

5

1. Introduction and General Principles for HP OpenView Style

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

HP OpenView Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

User Approaches to Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Exception Driven Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Task Based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28User Guided Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Important Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Web Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Application Design Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Principles for General Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Principles for Information Presentation . . . . . . . . . . . . . . . . . . . . . . . .36Principles for Access to Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Principles for Representing Relationships . . . . . . . . . . . . . . . . . . . . . .38

2. Web Applications

Introduction to Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Launching Web Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45HP OpenView Web Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45Launcher Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Graphics Used in Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51Launcher and Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Launcher and Session Information . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Use of Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Type of Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

6

Contents

Web Applications and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Basic Security Measures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59User Roles and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

General Guidelines for Web Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 60Named Web Browser Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Using Color and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Using Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Using Graphics and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Scrolling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Navigating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Updating Application Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Web Applications Based on HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Using HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Using Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Using Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Using Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Components of Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Title Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Context Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Scope Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Results Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Control/Status Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3. HP OpenView Presentation Managers

Object Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Task Presentation Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Information Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Multiple Purpose Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . 96

Contents

7

4. Using Windows

Windows in the HP OpenView Environment. . . . . . . . . . . . . . . . . . . . .101Scope Pane Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101Single Pane Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104Multiple Pane Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

Split Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106

Creating New Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

5. Window Components

Identification of Window Components . . . . . . . . . . . . . . . . . . . . . . . . . .113

Title Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

Menu Bar and Pop-Up Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117Menu Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117Pop-Up Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124Context and Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125Menu Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127Number of Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128Menu Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129Menu Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130Cues for Types of Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130Menu Separators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131Menu Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131Menu Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132Help on Menu Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133

Toolbar Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134When to use Toolbars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Content of Toolbars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134User Control and Support for Toolbar Use . . . . . . . . . . . . . . . . . . . . .135Tool Buttons in the Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136

8

Contents

Toolbar Structure and Customization . . . . . . . . . . . . . . . . . . . . . . . . 137Context Control Within the Toolbar. . . . . . . . . . . . . . . . . . . . . . . . . . 138Context and Toolbar Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Description Bar Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Context Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Scope Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Scope Panes With Hierarchies of Items . . . . . . . . . . . . . . . . . . . . . . . 145Scope Panes with Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Results Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Presentation Formats for the Results Pane. . . . . . . . . . . . . . . . . . . . 156Graphical Presentation Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Tabular Presentation Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Chart Presentation Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Form Presentation Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Navigation Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Status Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6. Objects and Symbols

Iconic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179When to Represent Objects with Symbols . . . . . . . . . . . . . . . . . . . . . 179Levels of Symbol Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Special Types of Objects and Views . . . . . . . . . . . . . . . . . . . . . . . . . . 187Layout Algorithms for Iconic Views . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Guidelines for Assigning Symbols to Objects . . . . . . . . . . . . . . . . . . . . 193Symbols and Symbol Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Assigning Symbols to Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Assigning Symbols to Connections and Relationships . . . . . . . . . . . 195Assigning Symbols to Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Contents

9

Symbol Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198Symbol Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198Symbol Subclasses (Graphics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206

User Modification of Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218Changing Symbol Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .218User Addition of Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .219

Creating NNM Submaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220Shared vs. Exclusive Submaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220Using an Existing Shared Submap . . . . . . . . . . . . . . . . . . . . . . . . . . .221Persistent and Transient Submaps . . . . . . . . . . . . . . . . . . . . . . . . . . .221Submap Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .222Submap Window Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .224Submap Window Overlay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226

7. Object Selections, Grouping, and Drag and Drop

Selection Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231Basic Selection Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231Multiple Selection Across Views in a Window . . . . . . . . . . . . . . . . . .234Recursive or Group Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238Selection Lists in Applications Integrating into PresentationManagers240Providing Access to HP OpenView Windows Selection List . . . . . . .241Modifying the HP OpenView Windows Selection List . . . . . . . . . . . .242

Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244Guidelines for Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244Groups and Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .247

Drag and Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248Visual Cues for Drag and Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .248Guidelines for Specific Types of Drop Targets . . . . . . . . . . . . . . . . . .249Use of HP OpenView Window’s Drag and Drop . . . . . . . . . . . . . . . . .253

10

Contents

8. Visual Presentation

General Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Notification of Object Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Visual Cues versus Alarm Messages . . . . . . . . . . . . . . . . . . . . . . . . . 258Use of Status Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Source of Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263When to Use Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Guidelines for Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Text Annotation for Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Highlighting Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Flashing Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Transparent Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Executable Symbol Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Partially Filled Connection Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

9. Dialog Boxes and Controls

Dialog Box Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Title Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Menu Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Fonts for Dialog Boxes and Windows. . . . . . . . . . . . . . . . . . . . . . . . . 280Default Size for Dialog Boxes and Windows . . . . . . . . . . . . . . . . . . . 281Resizing Dialog Boxes and Windows . . . . . . . . . . . . . . . . . . . . . . . . . 282User Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283General Guidelines for Controls in Dialog Boxes . . . . . . . . . . . . . . . 283Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Input Validation and Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 288

Contents

11

Default Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289

Guidelines for Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291Push Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291Option Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296Radio Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298Check Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .300Text Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301Combo Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305Spin Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307Sliders and Gauges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .309List Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311Tree List Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314Tables and Grids. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320Tab Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327Grouping Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332

10. Miscellaneous Guidelines

Internationalization and Localization of the User Interface. . . . . . . . .341Localization of the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . .342Helpful Hints for Internationalizing HP OpenView Applications. . .342

11. Guidelines for Product Documentation

Structure of the Documentation Set. . . . . . . . . . . . . . . . . . . . . . . . . . . .347Types of Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347A Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348Grouping the Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349Recommendations for the Documentation Set . . . . . . . . . . . . . . . . . .350

Structure of Individual Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352Recommendations for Information Access . . . . . . . . . . . . . . . . . . . . .352Recommendations for Information Understanding . . . . . . . . . . . . . .353

12

Contents

Recommendations for Localization . . . . . . . . . . . . . . . . . . . . . . . . . . 354

A. HP OpenView Launcher Categories

Object Tab Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Task Tab Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Information and Reporting Tab Categories . . . . . . . . . . . . . . . . . . . . . 360

Tool Tab Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

B. Mnemonics and Accelerators

C. Color Mapping and Palettes

Using Color in Web Page Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368Color Palettes Used in HP OpenView . . . . . . . . . . . . . . . . . . . . . . . . 368Palette Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Using the Limited Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Color Values in the Limited Color Palette . . . . . . . . . . . . . . . . . . . . . 369

Using the Expanded Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372Color Values in the Expanded Color Palette . . . . . . . . . . . . . . . . . . . 372

D. Bibliography

Figures

13

Figure 2-1 . Launcher Window with the Task Tab Selected . . . . . . . . . .46

Figure 2-2 . Icons for categories and for leaf level items . . . . . . . . . . . . .52

Figure 2-3 . Web Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Figure 3-1 . Object Presentation Manager . . . . . . . . . . . . . . . . . . . . . . . .84

Figure 3-2 . Task Presentation Manager with a Task Presented in aWizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Figure 3-3 . Task Presentation Manager with Task Presentedin a Tab Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87

Figure 3-4 . Visual Cues and Task Completion Feedback in a TaskPresentation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Figure 3-5 . Related Task Tab in a Task Presentation Managerwith a Tab Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

Figure 3-6 . Example of an Information Presentation Manager. . . . . . .94

Figure 3-7 . Multipurpose Presentation Manager . . . . . . . . . . . . . . . . . .96

Figure 4-1 . Scope Pane Window with Network Hierarchy . . . . . . . . . .102

Figure 4-2 . Scope Pane Window with Categories to be Matched . . . . .103

Figure 4-3 . A Multiple Pane Window . . . . . . . . . . . . . . . . . . . . . . . . . .105

Figure 4-4 . A Split Scope Pane Window . . . . . . . . . . . . . . . . . . . . . . . .108

Figure 5-1 . Window with Its Components Identified . . . . . . . . . . . . . .113

Figure 5-2 . Sequence for Items in Menu Bars Using OSI Menus . . . .123

Figure 5-3 . Sequence for Items in Menu Bars Using an Action Menu 123

Figure 5-4 . A Menu Bar Using Object-Based Menus . . . . . . . . . . . . . .124

Figure 5-5 . A Cascading Toolbar Button . . . . . . . . . . . . . . . . . . . . . . . .137

Figure 5-6 . Description Bar over the Scope and Results Panes in aWindow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .140

14

Figures

Figure 5-7 . Context List in a Close and Open State . . . . . . . . . . . . . . 142

Figure 5-8 . Context Tabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Figure 5-9 . Two Examples of Scope Panes Showing Hierarchies . . . . 146

Figure 5-10 . Expansion Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Figure 5-11 . Visual Cues in the Scope Pane . . . . . . . . . . . . . . . . . . . . 150

Figure 5-12 . A Scope Pane with Filters . . . . . . . . . . . . . . . . . . . . . . . . 153

Figure 5-13 . The Results Pane in an Application Window . . . . . . . . . 155

Figure 5-14 . A View Showing an Iconic Presentation Format . . . . . . 158

Figure 5-15 . Pictorial Presentation Format. . . . . . . . . . . . . . . . . . . . . 160

Figure 5-16 . A View Showing a Tabular Presentation Format. . . . . . 161

Figure 5-17 . A View Showing a Chart Presentation Format . . . . . . . 164

Figure 5-18 . A View Showing a Form Presentation Format . . . . . . . . 165

Figure 5-19 . Navigation Tabs with Images of Stick Pins on Them . . 168

Figure 5-20 . Tab States and Appearance . . . . . . . . . . . . . . . . . . . . . . . 169

Figure 5-21 . Navigation Tabs Showing a Change in Task Status . . . 173

Figure 5-22 . A Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Figure 6-1 . Expansion Controls in a Hierarchy of Objects . . . . . . . . . 180

Figure 6-2 . X.25 Application Using a Combined Approach . . . . . . . . 185

Figure 6-3 . Item in a Property Box with a Link Symbol. . . . . . . . . . . 189

Figure 6-4 . Split Window Showing Objects at Linked Location . . . . . 190

Figure 6-5 . Symbol Class and Subclass for an Object . . . . . . . . . . . . . 193

Figure 6-6 . Symbol Class and Subclass for a Connection . . . . . . . . . . 194

Figure 6-7 . Change Symbol Type Dialog Box . . . . . . . . . . . . . . . . . . . 219

Figures

15

Figure 7-1 . Selection List for Scope Pane that AllowsMultiple Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236

Figure 7-2 . Visual Cues for Recursive Selection . . . . . . . . . . . . . . . . . .239

Figure 8-1 . Symbol Alert in the Results Pane of a Window . . . . . . . . .263

Figure 8-2 . Symbol Alert in the Scope Pane of a Window . . . . . . . . . .263

Figure 8-3 . Pop-up Menu Associated with Symbol Alerts . . . . . . . . . .267

Figure 9-1 . Push Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292

Figure 9-2 . Push Button with Location Cursor and Default ActionIndicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296

Figure 9-3 . Option Button in Closed and Open State. . . . . . . . . . . . . .296

Figure 9-4 . Radio Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .298

Figure 9-5 . Single and Multi-line Text Boxes . . . . . . . . . . . . . . . . . . . .302

Figure 9-6 . Drop-down Combo Box in Closed and Open State. . . . . . .306

Figure 9-7 . Spin Box with Labels Required . . . . . . . . . . . . . . . . . . . . .308

Figure 9-8 . Spin Box with Labels Optional . . . . . . . . . . . . . . . . . . . . . .308

Figure 9-9 . Slider with a Default Setting and Current Value Shown .309

Figure 9-10 . Gauges for Setting a Value and Displaying a Value . . . .309

Figure 9-11 . Visual Cues for a Multiple Selection List Box . . . . . . . . .313

Figure 9-12 . Single Selection Tree List and Multiple SelectionTree List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315

Figure 9-13 . Visual Cues for Recursive Selection . . . . . . . . . . . . . . . . .318

Figure 9-14 . Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321

Figure 9-15 . Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .321

Figure 9-16 . Tab Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328

16

Figures

Figure 9-17 . Vertical Tabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Figure 9-18 . Scrollable Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Figure 9-19 . Dialog Box with a Separator Line . . . . . . . . . . . . . . . . . . 333

Figure 9-20 . Dialog Box with a Group Box . . . . . . . . . . . . . . . . . . . . . 334

Figure 9-21 . Window with Two Panes . . . . . . . . . . . . . . . . . . . . . . . . . 335

Figure 11-1 . Organizing Information into Modules . . . . . . . . . . . . . . 349

Tables

17

Table 2-1. Defined Color Usage for HTML Based Applications . . . . . . .62

Table 2-2. Defined Java System Color Variable Usage . . . . . . . . . . . . . .64

Table 5-1. Required Visual Cues for Menu Items . . . . . . . . . . . . . . . . .130

Table 6-1. Obsolete Symbol Types and Their Replacements. . . . . . . . .195

Table 6-2. Existing Symbol Class Shapes. . . . . . . . . . . . . . . . . . . . . . . .199

Table 6-3. Internal Graphics Cues . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203

Table 6-4. Visual Cues Used in Existing Graphics . . . . . . . . . . . . . . . .207

Table 8-1. Default Status Colors Defined for HP OpenView. . . . . . . . .260

Table 9-1. Recommended Dialog Box Title Formats . . . . . . . . . . . . . . .279

Table 9-2. Labels and Definitions for Push Buttons . . . . . . . . . . . . . . .294

Table 9-3. Guidelines for Showing Buttons as Unavailable . . . . . . . . .295

Table B-1. Common Accelerator Key Assignments inHP OpenView. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364

Table B-2. Common Mnemonic Access Key Assignments in HPOpenView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364

Table C-1. Color Values in the Limited Color Palette . . . . . . . . . . . . . .370

Table C-2. Color Values in the Expanded Color Palette . . . . . . . . . . . .372

18

Tables

19

ConventionsHP OpenView supports multiple operating system platforms, withdiffering file structures. To simplify your use of the product and make thedocumentation more readable, the HP OpenView products include anoptional script that defines environment variables common to alloperating system platforms. These environment variables create“universal” path and file names that apply to HP OpenView directoriesand files, regardless of the structure of the underlying file system.

NOTE HP OpenView documentation is written with the assumption that youhave activated the universal pathnames.

Further information on universal pathnames is available in the HPOpenView Network Node Manager Products Installation Guide.

The following typographical conventions are used in this manual.

Font What the Font Represents Example

Italic For book or manual titles, and formanpage names.

Refer to the OVW Developer’s Guide.

To provide emphasis. You must follow these steps.

To specify a variable that you mustsupply when entering a command.

At the prompt type: rloginyour_name where you supply yourlogin name.

Bold For glossary terms. The distinguishing attribute ofthis class...

20

Computer Text and items on the computerscreen.

The Root map window ...

The system replies: Press Enter

Command names Use the grep command ...

File and directory names. /usr/bin/X11

Process names. Check to see if pmd is running.

Window/dialog box names In the IP Internet map window...

ComputerBold

Text that you must enter. At the prompt, type: ovstatus .

Keycap Keyboard keys. Press Return .

[Button] Buttons on the user interface. Click [NET] . Click on the [Apply]button.

MenuItems

A menu name followed by a colon (:)means that you select the menu,then the item. When the item isfollowed by an arrow (-> ), acascading menu follows.

Select Locate:Objects->byComment

Font What the Font Represents Example

21

Contact Information

Technical Support Technical support information can be found on the HP OpenView WorldWide Web site at:

http://www.hp.com/openview/support.html

________________________________

DocumentationFeedback

Your comments on and suggestions for the documentation help usunderstand your needs and better meet them.

You can provide feedback about documentation via the HPdocumentation site at:

http://www.docs.hp.com

Or you can fill out the form provided in electronic form with NNM:

• on Windows NT operating systems:\OpenView\ReleaseNotes\nnm_doc_reply.txt

• on UNIX systems:/opt/OV/ReleaseNotes/nnm_doc_reply.txt

Fill out one form per manual and email it to: [email protected]

If you encounter serious errors in the documentation that impair yourability to use NNM, please contact the HP Response Center or yoursupport representative so that your feedback can be entered into STARS(HP’s Software Tracking and Reporting System).

________________________________

Training Information For information on current HP OpenView training available, see the HPOpenView World Wide Web site at:

http://www.hp.com/openview/support.html

Follow the links for Training to obtain information about scheduledclasses, training at customer sites, and class registration.

23

1 Introduction and GeneralPrinciples for HP OpenViewStyle

24 Chapter 1

Introduction and General Principles for HP OpenView Style

This chapter discusses:

• The vision for HP OpenView products.

• The different types of approaches that users take when doingnetwork, system and service management.

• General design principles for all applications.

Since numerous and varied applications are integrated into HPOpenView, the application developers need to keep these points in mindwhile developing an application. This will help ensure cooperation andinteroperability between applications, providing the user with anintegrated, cohesive interface from which to access these applications.

Chapter 1 25

Introduction and General Principles for HP OpenView StyleOverview

OverviewHP OpenView is a family of tools and services for managing the ITinfrastructure associated with a company. The tools and services in theHP OpenView family cover management for desktop computers,distributed systems, data, applications, local and wide area multivendornetworks, etc. HP OpenView provides tools for creating multivendorsystem, network, software, and service management applications.Applications are perceived by the user as being part of the HP OpenViewfamily, to the extent that they provide a common appearance andbehavior. This style guide provides a summary of the recommendedappearance and behavior for applications in the HP OpenView family.Except where specifically indicated, the style recommendations areapplicable regardless of the technology on which the application is builtor the operating systems on which it is presented.

The style for HP OpenView products is in accordance with the generalprinciples in the The Windows Interface Guidelines for Software Design.

This guide is designed to:

• Present a subset of the guidelines from The Windows InterfaceGuidelines for Software Design that need emphasis or specialinterpretation for products in the HP OpenView Family.

• Introduce style guidelines that are unique to HP OpenView products.

26 Chapter 1

Introduction and General Principles for HP OpenView StyleHP OpenView Vision

HP OpenView VisionThe platforms and applications that are part of the HP OpenView familyshould strive to realize the following vision:

• Multiple products look like one.

• Product boundaries disappear.

• Consistent style; looks and behaves the same.

• Customer receives instant value.

• Works right out of the box, with no modifications required.

• Addresses real world problems.

• Products work intuitively, while offering guidance.

• Interactions match typical user expectations.

• Users are guided through their activities.

• Products are adaptable.

• Customizable to fit user needs and their environment.

• Extensible to match users’ changing needs.

Chapter 1 27

Introduction and General Principles for HP OpenView StyleUser Approaches to Management

User Approaches to ManagementWhen doing network, systems, and service management, a user willtypically take one of three approaches to his work. The choice ofapproach will depend on the user’s job and the way work is structuredwithin his organization. The user may also move back and forth betweenthese approaches, depending on the requirements of the work he istrying to accomplish. HP OpenView applications should be designed toallow for one or more of these approaches to management.

Exception Driven ApproachIn the exception driven management approach, the user might have atrouble ticket system, message browser, or graphical presentation thatnotifies him of problems in his management domain. He receives anotification, after which he begins the task of troubleshooting, resolving,and documenting the problem that caused the notification.

Exception management is frequently used in help desks and operationscenters.

User interfaces present an exception driven approach by presenting auser with exceptions, along with the necessary resources, to enable himto handle these exceptions. Exceptions are not always problems thatoccur in the current service, network, and system environment; they canbe a request for new services or for equipment to be placed in theenvironment. Some exceptions can be handled by predefined automaticactions (task based interactions that use the exception as the context fordefining the parameters of the task) or by user guided steps.

The exception based approach requires the tracking of performancerelative to goals for preventing and/or handling exceptions.

HP OpenView applications facilitate the exception driven approach tomanagement through the presentation of alarms or messages andgraphical views of objects which show status and symbol alerts. SeeChapter 8, “Visual Presentation” for information on visual cues that canbe used to support the exception based approach.

28 Chapter 1


Task Based Approach A task is the performance of a piece of work that results in a selfcontained desired outcome. Tasks can be defined at multiple levels (thatis, complex tasks which consist of multiple subtasks or simple tasks thatinvolve a single step). Tasks can involve the manipulation of singleobjects or of multiple objects.

Network, systems, and service management often involves well definedtasks that need to be accomplished either on a periodic basis or on anevent driven basis. In a task based approach, a user goes through a set ofdefined steps to complete that task. For tasks which will be repeated anumber of times by different users or by the same user, it is possible todefine an optimum sequencing of a task’s steps to achieve the best userperformance.

The task based approach is frequently used in setting up new equipment,in making changes to configurations, and in resolving routine problemsor doing routine jobs.

User interfaces present a task based approach by guiding a user throughthe steps required to accomplish a task or allowing users to configurepolicies that will automatically handle the tasks. In some complex tasks,a task based approach may be provided for a portion of the task, but theuser may need to utilize a user guided approach to accomplish the rest ofthe task.

HP OpenView applications facilitate the task based approach tomanagement through the presentation of tasks in task presentationmanagers, wizards and in the configuration of policies. Task presentationmanagers allow users to start tasks from a list of available tasks and tocomplete task steps with the aid of a wizard. (See Chapter 3, “HPOpenView Presentation Managers.”)

User Guided ApproachBecause the problems being dealt with in network, systems, and servicemanagement are complex, and because IT and telecommunicationsgroups vary in the equipment they are managing and the processes theyare using for management, there is a need for unconstrained access toinformation and functionality. The user guided approach in userinterfaces allows maximum freedom for a user by enabling him to accessmultiple tools and capabilities with limited constraints.

Chapter 1 29


The user guided, information seeking approach is frequently used inplanning for modifications to a network and system infrastructure, inlooking at the health of a specific object or set of objects, and in resolvingcomplex problems that have not previously been encountered orpredicted.

User interfaces present a user guided approach by offering clearly visiblefunctionality that a user is allowed to access to accomplish his goals.Frequently, user guided interfaces use an object action paradigm inwhich a user first selects the object on which he wants to act, followed bythe action he wants to take. This selection constrains the functionality tothose actions which are appropriate for the object (for example, menugraying); the user then chooses from the constrained subset of availablefunctionality.

HP OpenView applications facilitate the user guided approach tomanagement through the object action paradigm in object presentationmanagers. In these presentation managers, a user can select objects andthen access functionality for acting on these objects from menus andtoolbars. To prevent cognitive overloading of the user, the functionality iscontext specific; available functionality is constrained to the context inwhich the objects are presented.

30 Chapter 1

Introduction and General Principles for HP OpenView StyleImportant Concepts

Important ConceptsHP OpenView has a number of important concepts on which the userinterface style is based. These concepts are briefly explained in thefollowing sections.

Presentation ManagersPresentation managers are windows which present users with views ofmanaged objects, access to functionality for manipulating objects,guidance in accomplishing tasks and/or a means of presentinginformation on managed objects. Presentation managers aredistinguished from other windows in that they are designed to suit theuser’s needs and to minimize the number of windows that the user needsto navigate through in order to accomplish their goals. Typicallypresentation managers will allow the integration of other relatedapplications so that users can access necessary information for a givenmanagement area or task from within a single window. Microsoft’sManagement Console (MMC) and Network Node Manager both provideframeworks on which presentation mangers can be built.

HP OpenView provides a set of presentation managers into whichapplications can integrate. These presentation managers providecapabilities that can be used by integrating applications (for example,NNM Network Presenter, Manage X). Integration into a presentationmanager can minimize the development effort required of theintegrating applications. For example, applications can use the discoveryand multiple selection capabilities of NNM and Manage X.

Developers can also choose to create their own independent presentationmanagers.

See Chapter 3, “HP OpenView Presentation Managers” for guidelinesregarding presentation managers.

Web LauncherHP OpenView provides a web launcher into which applications canintegrate. The web launcher provides a single access point on the web;from which the user can:

• Start all HP OpenView web applications.

Chapter 1 31


• Access object presentation managers, which provide both views ofmanaged objects and various actions on these objects.

• Access tasks that can be performed in a guided manner via wizards,property sheets and task presentation managers.

• Obtain information related to various tools and reports.

• Obtain information and reports.

The launcher also provides security for web applications so that a usercan log in just once and have his authorization for functionality accessbased on this single login. This ensures that the information andcapabilities provided by HP OpenView are available only to authorizedindividuals. Having a centralized point for security minimizes the needfor a user to do separate logins to different applications. See Chapter 2,“Web Applications,” for guidelines regarding the launcher.

ContextContext is an abstract concept which can be applied to the user interfaceto filter the information that is presented and to provide a view ofinformation from different perspectives. Contextual information such aswho the user is, the user role, recent user actions, or events and alarmscan be used to filter the functionality and objects presented in the userinterface. This allows the user to focus on information that is relevant tothe current task. This same type of information can be used byapplications to vary the way information is presented. This enables theinformation presentation to match the preferences and needs of the useras he interacts with the management system. Sharing of contextualinformation, allows independently developed applications to appear tothe user as highly integrated applications that work closely together.

Context can also be used to maximize user productivity. Contextualinformation such as the currently visible view or recent user actions canbe used to set defaults that minimize the need for user input. This sameinformation can be used to filter irrelevant information or steps so thatusers can more quickly reach their goals. By passing contextualinformation between components within an application and between oneapplication and others, the need for the user to duplicate his actions isminimized.

HP OpenView currently provides a number of components which supportthe use of context to aid the user. These components are described in thenext six sections.

32 Chapter 1


HP OpenView Launcher and Session ContextThe HP OpenView Launcher for web applications provides contextualinformation at the session level. This information can be shared acrossapplications. Examples of session level context information availablefrom the launcher includes:

• Identification of the user who is accessing the application (user login).

• The user roles assigned to the person who has accessed theapplication.

• The language locale specified for this session.

The functionality presented in the HP OpenView Launcher is filteredto restrict the functionality to match the roles associated with theuser who started the session. Applications can obtain the sessioninformation on user login and user roles. They can then create animplementation that uses this information to filter the functionalityand objects that they present.

Context Controls and Management ContextThe context controls provided in presentation managers provide userswith an explicit mechanism for filtering information and changing theperspective from which information is presented. In presentationmanagers, context changes are typically associated with a change in themanagement hierarchy, and/or type of management functionality. Forexample, in an object presentation manager, users could change betweenmanagement hierarchies for the IP Internet and File Sharing using thecontext list box in the toolbar. In a task presentation manager, userscould change between tasks for Asset Management to tasks for FaultManagement and Diagnosis. A change in the management context willlikely result in a change in the functionality that is available in themenus and toolbars, in the objects, tasks, or tools available in the scopepane, and in the views that can be presented in the results pane.

See Chapter 5, “Window Components,” for more information on contextcontrols.

Open Object and ContextThe object that is open within the scope pane will define context, bydetermining the view that is presented to a user in the results pane. Aview consists of two components: the data to be presented to the user andthe presentation formats for that data. A view typically will have both a

Chapter 1 33


default presentation format (for example, an icon view) as well as otherpresentation formats that the user can access for changing the way theinformation is presented (for example, a tabular view).

Each view determines which menu and toolbar items are available to theuser for acting on the objects in that view. See “View/Submap Context”below.

View/Submap ContextView context, also referred to as submap context, filters the menu itemsso that only menu items relevant to the current view are presented.Using view/submap context, application developers can determine whichmenu items and toolbar items to associate with a particular view orsubmap. View context allows:

• Smaller menus and toolbars, because menu items are defined to occuronly in the specific contexts they are applicable to.

• The elimination of continuously grayed-out menu items that wouldoccur if menu items were not specific to a given context defined by aset of views.

For each view that is created, a view context must be specified.

If no context identifiers are provided for a view/submap, thatview/submap will only contain generic menu items or undefined menuitems that have no menu placement rules identified. See Chapter 6,“Objects and Symbols,” for guidelines on setting View/Submap context.

NOTE View context is a very flexible concept and, in the future, could be usedfor other purposes than menu item specification (that is, determiningwhether a given object would appear in a view or accessing related viewscontaining a specified object).

Menu Placement RulesMenu placement rules are specifications that work in conjunction withview context identifiers to determine if a menu item will be presentedwith a given view. See Chapter 5, “Window Components,” for informationand recommendations about specifying menu placement rules.

34 Chapter 1


Selected ObjectsAny currently selected objects and their capabilities help to set thecontext for which menu items will be available or grayed-out andunavailable. If the capabilities of the selected objects do not match thoserequired by a menu item or a toolbar button, the menu item or buttonwill be grayed-out.

GroupsGroups contain arbitrary sets of objects and/or other groups. Groups canbe defined by applications or by end users. They have a variety of usessuch as:

• Setting up security.

• Allowing a user defined hierarchy of objects and relationships.

• Allowing a user action taken at a group level to propagate down to allthe members of the group.

• Grouping objects for viewing.

• Grouping objects for selection, which:

• Allows users to act on multiple objects at one time.

• Provides a means of setting up a global selection list.

Further information and guidelines on groups are presented in Chapter7, “Object Selections, Grouping, and Drag and Drop.”

Chapter 1 35

Introduction and General Principles for HP OpenView StyleApplication Design Principles

Application Design PrinciplesWhen designing an application, keep in mind the underlying concept ofHP OpenView Windows, which is to provide an environment in whichthere is cooperation and interoperability between a variety ofapplications.

Principles for General UsabilityTo enhance user interaction and productivity in this kind ofenvironment, each new HP OpenView application should be designed tobe integrated, intelligent, and consistent. These goals can be achieved bykeeping the following principles in mind when designing the application:

• Make functionality visible to users.

• Allow users to customize the functionality to suit their individualwork environments.

• Make the application extensible by allowing users to addfunctionality that they have developed in their own organizations.

• Minimize the users’ work load by automating any tasks that can beautomated (discovery and data access, for example).

• Use terminology that is common throughout the HP OpenViewenvironment and which is consistent with terminology used by endusers.

• Minimize the users’ cognitive load by providing information that anapplication can obtain for itself.

• Eliminate the need for users to hold information in their short termmemory. Use menus, lists, check boxes, and other user interfacecontrols (which are based on recognition instead of on recall).

• Eliminate the need for users to make decisions, by providing defaultsor by automating unnecessary decisions.

• Design to facilitate user tasks.

• Minimize the number and complexity of steps within a task.

• Keep user tasks simple. The implementation of a task should notincrease its difficulty.

36 Chapter 1


• Provide connections between all dialog that are required tocomplete a task. Do not require users to go back to the menu barin order to locate the next dialog required for their task.

• Support user productivity.

• Provide and use accelerators wherever possible to support powerusers’ access of functionality in fewer steps.

• Allow users to repeat actions in dialog boxes (for example, providean [Apply] button) if they will want to make multiple sets ofchanges or additions at a single time.

• Minimize the amount of information users are required to provide.

• Support the success of users of an application.

• Provide cues and prompts to guide users to their next action ortask step.

• Provide feedback to users.

• Provide context sensitive help for users.

• Design for user error.

• Prevent errors when possible.

• When errors cannot be prevented, anticipate and minimize theconsequences of these errors for the user and his tasks.

Principles for Information PresentationUse the following principles to ensure consistency in the presentation ofinformation across applications.

• Do not require users to translate data to use it; present allinformation in a directly applicable form.

• Allow users to filter unnecessary information.

• Order information along a meaningful dimension.

• Present information graphically if that would make the data moremeaningful.

Chapter 1 37


• If color coding is used, provide other redundant cues so that colorblind users will be able to differentiate different color codes from oneanother. Allow users to configure colors so that they can bedifferentiated.

• If auditory cues are used, take into account changes in hearing due to:

• A user’s age (higher tones become more difficult to detect).

• The environment in which a user works (in a open office occupiedby multiple users, for example, auditory cues should beminimized).

• If shapes are used, select shapes that are different enough from eachother to be easily distinguishable.

• If multiple sizes of shapes are used, be sure that the shapes aredistinguishable at their smallest size.

Principles for Access to ActionsUse the following principles to ensure that user access to actions isconsistent across applications.

Keyboard AccessKeyboard equivalents are the mechanism by which a specializedsoftware vendor or application developer can provide support for endusers with different types of disabilities. This enables users withdisabilities to access all the capabilities of an application. This samemechanism can also be used as an accelerator or quick access mechanismby users without disabilities.

Use of Special KeysIf the keyboard contains hard labeled keys for various actions providedin an application’s user interface, make sure that the application’ssoftware does allow those keys to be used to access the indicated actions.For example, if an application’s interface allows users to delete items in alist, make sure they can actually use the Delete Line or Delete keys on thekeyboard to accomplish this action.

38 Chapter 1


Quick AccessFrequently used actions should be available to users through a quickaccess method, such as a toolbar button, a menu accelerator, or a pop-upmenu.

But, be sure to provide other access methods for the functionality inaddition to these quick access methods. Quick access methods are simplya faster way of doing an action that can be done using another slower,but more obvious, method.

Labeling ActionsSimilar actions must use similar terminology in their labels. Forexample, use the term “Delete” consistently in action labels which causea deletion result (that is, use Delete User and Delete Printerinstead of Remove User and Delete Printer ).

Labels chosen for user actions should be based on user terminology. Forexample, use the term “Save” rather than “Write”.

Principles for Representing RelationshipsRelationships can be represented either graphically or textually. Use thefollowing principles to represent relationships between elements of anapplication.

ContainmentContainment relationships can be represented:

• Graphically by an exploding symbol that leads to a view with thecontained items presented in the child view.

• Graphically using a tree list where parent items can be expanded intothe lower level items contained within.

• Textually using a hierarchical list with indentation. The containerwould be at a higher level in the list, and the contained items wouldbe indented under the container.

Chapter 1 39


ClassificationThis type of relationship is one in which objects are related to oneanother because they can be placed in the same category or class basedon attributes that are shared across all of the objects in the class.Classification relationships can be represented:

• Graphically by an exploding symbol that leads to a graphical viewwith the member of the class presented in the graphical view.

• Graphically via a tree layout with the category label on top andcontained objects being presented beneath under the category label.

• Textually within a table. One column can contain the object namesand another column can contain the category to which the objectbelongs. Alternatively, each column can represent a separatecategory, and the cells under the category headings can indicate themembers of each category.

• Textually within a list with a category name as a label for the list. Ahierarchical list can be used for multiple categories.

Lower level objects in a classification relationship should not beportrayed as being connected to one another. Instead, it is recommendedthat they be presented in a row/column layout.

ConnectionConnection relationships can be represented graphically using thevarious layout algorithms to represent different types of connections ofthe objects. See section, Layout Algorithms for Graphical Views. fordetailed guidance on the use of the layout algorithms.

Recommended It is difficult to meaningfully represent connection relationships in atextual format. Therefore, a graphical format is recommended.

Recommended If design constraints force the use of a textual format, connectionrelationships can be represented in a table with one of the table columnslisting objects connected to the object in question.

PeerPeer relationships can be represented:

• Graphically by a ring layout with all objects either arranged in acircle or connected to one another.

40 Chapter 1


• Graphically by a tree layout with all objects being at the same level.

• Textually in a hierarchical list. All objects at the same level in thehierarchy would be peers.

• Textually within a table, with peers presented as rows within acolumn of the table.

Temporal RelationshipsSometimes events or actions need to presented in terms of when theyhave occurred or when they will occur in time.

Temporal relationships can be represented:

• Graphically by the sequence in which the symbols representingevents are presented. (In western countries, this sequence should bedisplayed either top to bottom or left to right with the earliest eventsor actions at the top or left side of the display and the most recentevents or actions presented at the bottom or right side of the display.)

It is also beneficial to present lines with arrows between the events.The direction of the arrows should indicate the flow of time from earlyto later.

• Textually in a list or a table with the event or action in one columnand the time associated with that event or action presented inanother column.

Recommended If the temporal relationships are complex with multiple dependenciesand/or simultaneously occurring events and actions, it is better toportray these relationships graphically.

41

2 Web Applications

42 Chapter 2

Web Applications

This chapter discusses:

• The HP OpenView Launcher which is a new integration point for webapplications.

• The trade-offs to be considered in deciding whether to present theapplication in a Java frame or a Web browser window.

• Guidelines for when to remove the controls from a browser windowused to present an application.

• Security considerations for web applications.

• General guidelines for the development usable web applications.

• Guidelines for application layout when presented in a web browserwindow.

Chapter 2 43

Web ApplicationsIntroduction to Web Applications

Introduction to Web ApplicationsSince numerous and varied applications are integrated into HPOpenView, the application developers need to keep these points in mindwhile developing an application. This will help ensure cooperation andinter-operability between applications, providing the user with anintegrated, cohesive interface from which to access these applications.

Designing an application for the web is not significantly different thandesigning an application for any other technology. Certain principles ofuser interface design remain valid, regardless of the underlyingtechnology, because they relate to the way humans receive and interactwith information. These design principles are based on cognitive science,human physiology, and visual and auditory perception.

Other aspects of user interface design are dependent on the controls andwidgets that a developer has available to him. Different technologiesallow for the use of different sets of controls and widgets. Differences inthe availability of controls require trade-off decisions on what to use inplace of a control that does not exist, and when to use a new control thatis enabled by the technology. Unless the technology is changing thefundamental way a control or widget works, the design principles forgood usability associated with a given control are consistent acrosstechnologies. The web provides many of the same controls that areavailable in traditional development environments tied to the desktop orwindowing system of a given computer.

Sometimes a given technology changes the response time, visualappearance, and/or behavior of a control to such an extent that it nolonger represents the previous class of controls. Instead, it becomes adifferent type of control. When this happens, the design principlesassociated with the control must be redefined in order to achieve highusability. This chapter is primarily intended to address user interfacecomponents and controls that are modified as a function of being in theweb environment.

With these considerations in mind, the style for HP OpenView productsis based on the concept that all HP OpenView products should have aconsistent look and feel regardless of the underlying technology. Webapplications are expected to follow the general style for HP OpenView

44 Chapter 2

Web ApplicationsIntroduction to Web Applications

products as described in other chapters of this style guide. This chapterdiscusses those areas that need special attention, given that anapplication will be based on web technologies (such as HTML or Java).

Chapter 2 45

Web ApplicationsLaunching Web Applications

Launching Web ApplicationsIf users are accessing a large number of web applications in the processof doing their management tasks, it becomes cumbersome when they arerequired to set bookmarks for each of the applications. Use of webapplications becomes much easier for users when all of their webapplications are available from a single access point. This is the intendeduse of the HP OpenView Web Launcher.

HP OpenView Web LauncherThe HP OpenView Launcher is a new integration point for webapplications. The launcher provides login security for web-based HPOpenView applications and provides a central location from which theuser can launch all of the applications that have integrated into the HPOpenView web environment.

The launcher is a small window that is divided into two parts.

46 Chapter 2


Figure 2-1 Launcher Window with the Task Tab Selected

The top part of the window presents management functionality in ahierarchical tree list. The management functionality area contains a setof tabs indicating categories for types of management operations. Eachcategory is indicated by a small icon that is presented on the tab. Usersclick on the tabs to access functionality in the different categories. Theinitial list of tabs provided by the launcher is:

• Objects

• Tasks

• Information and Reports

• Tools

• Management Area <Administrator Configurable>

• Help

Chapter 2 47


An active help area is presented beneath the functionality area. Thisarea displays a short help message explaining the operation of the itemover which the pointer has been placed.

There are top level categories defined for each of the predefined tabs inthe launcher. These categories are presented in Appendix A, “HPOpenView Launcher Categories.”

Launcher RegistrationThe HP OpenView Launcher allows for the integration of webapplications by means of a registration file. The entries in theregistration file determine the placement of the application entrieswithin the launcher.

Recommended The following types of web applications should be registered to belaunched from the launcher:

• Applications that take the role of a presentation manager in the HPOpenView environment. See Chapter 3, “HP OpenView PresentationManagers,” for more information.

• Stand-alone applications that are not dependent on a presentationmanager in order to provide their functionality to the user.

These applications may be available from one or more presentationmanagers but they provide independent mechanisms for the user tospecify necessary parameters (for example, selections) so that accessfrom a presentation manager is not required.

• Applications that integrate into the context list of an existingpresentation manager.

See Chapter 3, “HP OpenView Presentation Managers,” and “ContextControls” in Chapter 5 for more information.

Recommended In addition to being registered to be launched from the launcher, it isrecommended that:

• Web application be accessible from presentation managers inlocations where the functionality that they provide is appropriate tothe context.

48 Chapter 2


• Stand-alone web applications that do not have a native code versionhave registration files that allow them to be presented via the nativecode HP OpenView products (for example, Manage X, NNM NT orNNM UNIX).

This will allow users that have a native-code product running locallyon the system to access all of the functionality that is available viathe web.

Chapter 2 49


Required New launcher registration entries must not add tabs beyond thespecified set.

The tabs are intended to group functionality in ways that make it easierfor users to access the functionality when they are using the differentapproaches to management (Exception Driven, User Guided, and TaskBased), that are presented in “User Approaches to Management” inChapter 1.

Recommended New launcher entries should be defined so they fit within the predefinedlauncher categories presented in Appendix A, “HP OpenView LauncherCategories.”

Using the predefined categories will keep the launcher consistent andwill make it easier for users to find and access related functionality.

Recommended If categorization of the application is ambiguous and different users maylook for it under different tabs, multiple entries in the launcher shouldbe provided for the application.

For example a reporting capability for an application should beregistered to be accessed under the Information and Report tab and theTools tab of the Launcher. If the user is thinking of the report he wants tosee as information, he will look under the Information and Report tab. Ifthe user is thinking of the name of the application that provides thereport, he will look under the Tools tab.

Recommended In the Object tab, launcher entries should be provided down to the levelof the context entries for presentation managers. Entries should NOTbe provided for views contained within the context.

For example, a network application should register a launcher entry forthe IP internet under the “Network Views” category but should notregister entries for the networks and subnets within the IP internet.

NOTE It is a good idea for launcher entries on the object tab to correspond tothe items listed in the context control of the object presentation manager.For more information on context controls see “Context Controls” inChapter 5. For information on object presentation managers see “ObjectPresentation Managers” in Chapter 3.

Recommended In the Task tab, entries should be provided for categories of tasks and thetasks that users would want to do. Entries should NOT be provided forsubtasks within a task.

50 Chapter 2


For example, an application that provides service management shouldprovide task entries for creating and modifying service level agreementsbut should not include entries for modifying the service availabilityparameters in the service level agreement.

Recommended Entries made in the task tab should be stated in the form of a task.

For example, View Reports under Information Access and Reporting orView OV Users under Security Management.

NOTE It is a good idea to have the top level task categories on the task tab ofthe launcher, correspond to items in the context button of a taskpresentation manager. The applications entries into task tab of thelauncher should correspond to the tasks listed in the scope pane of thetask presentation manager. For more information on context controls see“Context Controls” in Chapter 5, for information on task presentationmanagers see “Task Presentation Managers” in Chapter 3.

Recommended In the Tools tab, entries should be provided for applications and for thetools provided by the application. Entries should NOT be provided foreach piece of functionality provided by the tool.

For example, the HP OpenView Network Node Manager should provide atop level entry for the Network Node Manager application and lowerlevel entries for the Network Presenter, SNMP Data Presenter, andAlarm Browser. Entries should not be provided for individual types ofinformation presented through the SNMP Data Presenter.

NOTE It is a good idea to have the entries in the tools tab of the launchercorrespond to the separate graphical user interfaces provided by theproduct.

Required Applications must NOT provide entries for the “Management Area” tab.This tab is intended to be configured by the HP OpenView administratorto match the type of management that is anticipated to be done and toprovide quick access to frequently used capabilities.

Applications can provide commented out entries for the “ManagementArea” tab to aid the HP OpenView administrator in setting up a tab thatwould be focused on a given type of management. For example a servicemanagement application could provide commented out registration filesto place views, tasks, and tools related to service management within asingle tab.

Chapter 2 51


Required When launched from a launcher entry, the application must presentfunctionality that directly corresponds to the label of the launcher entry.

For example, an application that provides views of objects has registeredlauncher entries for routers, printers, and web servers. When the userselects the router entry, the application comes up with the router viewdisplayed. When the user selects the printer entry, the application comesup with the printer view displayed.

Recommended When an application is currently open and the user selects a launcherentry that accesses that same application, the newly requestedinformation should be presented within the existing instance of theapplication rather than starting a new instance of the application.

Users do not want to have large number of windows open on theirdesktop. Rather than open new windows and new application instances,the current application instance and window should be reused.

Required All launcher entries are required to provide a help text string thatexplains the operation of the launcher entry and the type of functionalitythat is accessed by the entry.

Required Applications registered in the launcher must set the locale for theapplication based on the session locale set by the user. See HP OpenViewIntegration Series: OpenView Windows Developer’s Guide for moreinformation.

Graphics Used in LauncherThe HP OpenView Launcher provides a set of default icons that can beused by applications registered with the launcher. Applications also havethe option of supplying their own icons.

Recommended Categories in the launcher should be include icons that contain a folder.

A simple plain folder may be used or the folder can have a representationof the type of object contained in the category presented on top of thefolder. See Figure 2-2, “Icons for Categories and for Leaf Level Items.”

Required Leaf level items that provide application access from the launcher shouldbe include icons that represent the type of application functionality thatis being launched. See Figure 2-2, “Icons for Categories and for LeafLevel Items.”

52 Chapter 2


Figure 2-2 Icons for Categories and for Leaf Level Items

Recommended Icons used in the launcher should follow the guidelines for symbolspresented in Chapter 6, “Objects and Symbols.”

Launcher and SecurityThe HP OpenView Launcher provides login security and basic user rolesfor HP OpenView applications. The user roles determine the entries thatare presented in the launcher after the user logs in. These user roles canalso be used by the application for filtering the information andfunctionality that can be accessed.

By default the HP OpenView Launcher is shipped with the followinguser roles:

• Network Administrator

This role is intended for individuals who have a higher level ofknowledge of the network, how it functions and how to trouble shootproblems with the network. Applications that provide capabilities forconfiguration of the network and major connecting devices shouldspecify this as their associated user role.

• Network Operator

This role is intended for individuals who do routine trouble shootingand maintenance tasks associated with the network. Applicationsthat provide capabilities for monitoring the network and routinemodifications to the network and network devices should specify thisas their associated user role.

• NT Systems Administrator

This role is intended for individuals who have a higher level ofknowledge of NT systems, how NT systems function, and how totrouble shoot problems with the systems. Applications that providecapabilities for configuration of the NT operating system shouldspecify this as their associated user role.

Chapter 2 53


• NT Systems Operator

This role is intended for individuals who do routine trouble shootingand maintenance tasks associated with computer running the NToperating system. Applications that provide capabilities formonitoring NT systems and routine modifications to the systemsshould specify this as their associated user role.

• UNIX Systems Administrator

This role is intended for individuals who have a higher level ofknowledge of UNIX systems, how UNIX systems function, and how totrouble shoot problems with the systems. Applications that providecapabilities for configuration of the UNIX operating system shouldspecify this as their associated user role.

• UNIX Systems Operator

This role is intended for individuals who do routine trouble shootingand maintenance tasks associated with computer running the UNIXoperating system. Applications that provide capabilities formonitoring UNIX systems and routine modifications to the systemsshould specify this as their associated user role.

• HP OpenView Administrator

This role is intended for individuals who do configuration of HPOpenView environment and management applications. Componentsof management applications that are associated with configurationand customizing of the management application should specify thisas their associated user role.

The file in which the user roles are specified is the htgroup file.By defaulteach of the preconfigured user roles is available to all users. This allowsthe functionality to be accessed by all users until the HP OpenViewAdministrator modifies the htgroup file to restrict access to specificusers.

Recommended In the launcher registration file, applications should specify the user rolethat would typically be associated with the users of the application.

The specification of the user role will allow the HP OpenViewAdministrator to restrict access to the application if this is appropriate totheir application.

54 Chapter 2


Recommended The predefined user roles should be used whenever possible. Do not addnew user roles unless predefined user roles are inapplicable to theapplication.

Recommended If a new user role is defined in the htgroup file, the default specificationfor the user role should contain the “all” wildcard (“+”) so that all userlogins can access the functionality. Only the HP OpenViewAdministrator in the customer’s site should restrict the functionalityassociated with applications.

Launcher and Session InformationThe HP OpenView Launcher provides session level context informationincluding locale, user login and user roles. The functionality presented inthe HP OpenView Launcher is filtered to restrict the functionality tomatch the roles associated with the user who started the session.Applications can obtain the session information from the launcher. Theycan then create an implementation that uses this session information tofilter the functionality and objects that they present.

Required Applications must use the locale set by the user for the session.

See the The Integration Series: HP OpenView Windows Developer’s Guidefor information on how to access session information available from thelauncher.

Chapter 2 55

Web ApplicationsUse of Web Browsers

Use of Web BrowsersWhen developing an application using web technology, the role of theweb browser within the application must be established.

An application that is presented in a web browser can be so presentedwith full browser controls or with restricted controls. The advantage ofan application with full browser controls is that it can offer quick accessto other web-based information needed by a user. Conversely, the use offull browser controls can be detrimental to an application by creatingnavigation problems, difficulty in accessing controls or information dueto screen clutter, and restrictions on interaction style. In particular,navigation problems can occur when a user tries to use the navigationcontrols associated with the web browser and the results do not matchhis expectations. For example, the user has been navigating in ahierarchy of managed objects and accesses online help text associatedwith a given area; when he uses the [Back] button to return throughthe network of managed objects, he may at some point re-access the helptext that he had forgotten he had accessed, an action which will likelyconfuse him.

Java AppletsA Java applet can be presented either in a browser window or outside abrowser in a Java frame. Which method an applet uses is dependent onthe characteristics of that applet. The interaction style of an appletpresented within a web browser window is to some extent determined bythe web browser and the user settings within the browser. Presentationof an applet in a Java frame provides more flexibility. However,presentation of a Java applet in a Java frame can result in thepresentation of extraneous browser windows that must be kept aroundin order for the Java applet to continue running.

Recommended As more of the following criteria are met, the more appropriate it is forthe Java applet to be presented in a Java frame instead of inside abrowser window:

• Users want to resize the window (for example, the application isrunning over a long period of time, and information is presented in atree list that may expand).

56 Chapter 2


When Java applets are presented in a browser window, they stay aconstant size and do not change size when the user resizes thebrowser window unless specific coding is done to enable the applet tochange size.

• The applet has a large amount of functionality and will need topresent the user with a menu bar.

Java does not currently allow menu bars for applications presentedinside browser windows.

• The set of applets that make up the application can be implementedsuch that there is only a need for a single browser window to berunning in the user’s environment (not one browser window perapplet).

• The applet presents all the necessary navigational controls inside it,and there is no need for the navigational controls provided by thebrowser.

• There are numerous java applets running, and users may benefitfrom having an application-specific title bar when a window isminimized.

When running in a web browser window, the title bar always startswith the name of the web browser and the name of the object beingacted on (but the name of the application may not be visible when thewindow is minimized).

• The applet is running in an environment where the majority of theJava applets are running outside of a web browser window, and it willbe more consistent for the user to have all Java applets running intheir own windows.

Recommended As more of the following criteria are met, the more appropriate it is forthe Java applet to be presented in a browser window instead of inside aJava frame:

• Users will have no need to resize the applet (for example, the userinterface is up for only a short period of time, and all information canbe presented in a small amount of space).

• The applet has a limited amount of functionality that can be handledvia a toolbar or controls within the applet.

• The applet will be running under conditions that will require abrowser window to be associated with each applet.

Chapter 2 57


Presenting the applet in the browser window will save a user fromhaving two windows on his desktop when only one is required.

• The applet needs to use the navigational controls provided by thebrowser.

• There are few applications running in browser windows, and a userwill be able to easily identify each application window even whenthey are iconified.

• The applet is running in an environment where the majority of theapplication functionality is provided inside a web browser windows,and it will be more consistent for a user to have all Java appletsrunning in web browser windows.

Recommended Provide a window with a progress indicator that is presented when theJava applet is first accessed.

When a Java applet is first started, it may take a significant amount oftime for the applet to be downloaded onto the client system. A user mightbecome confused if there is no ongoing indication that the system isworking on his request. The progress window will provide the user withfeedback that the system is working and the applet is being loaded.

Optional Provide a picture above the progress indicator to make the window morevisually appealing to the user.

Recommended Automatically dismiss the in progress window when the Java applet isup and running.

Users do not want to be forced to dismiss the in progress window if itserves no other purpose after the main application window is presented.

Type of Browser WindowWhen an application is presented in a web browser with full controls, theapplication controls must compete for display space and user attentionwith the menus, toolbar, and other controls provided by the web browser.Consequently, the full set of browser controls should only be maintainedwhen they would benefit the user. On the other hand, presenting anapplication in a web browser with the browser controls removed mayrequire that the application duplicate some of the functionality that thebrowser controls were providing (for example, back).

58 Chapter 2


Recommended As more of the following criteria are met, the more appropriate it is forthe application to be presented in a browser window with full browsercontrols:

• A user’s primary job involves interacting with a variety of weblocations and unrelated applications that are accessed over the web.

• The interface is used on a periodic basis to access information, but isnot considered a primary tool for accomplishing the user’s tasks.

• The application is initially accessed from a web browser window withfull controls and the user would have no need to maintain the currentresults of the web browser window when the new application ispresented, that is, the new application can overlay the contents of thebrowser without interfering with the user’s tasks.

Recommended As more of the following criteria are met, the more appropriate it is forthe application to be presented in a browser window with the browsercontrols removed:

• The application presents all the necessary navigational controlsinside the frames it uses, or the application has limited functionality(for example, a single page of content) and no need for navigationalcontrols.

• The application would take up less display space if it were presentedin a web browser window with the controls removed.

• A user’s job primarily involves interacting with applications that donot require the use of the web browser’s location control for access (forexample, any necessary applications are accessed from a presentationmanager or from the HP OpenView Launcher instead).

• The environment in which a user is working is one in which browserscontrols are extraneous, and their removal will benefit user taskperformance.

• The application is initially accessed from a web browser windowwithout controls and the user would have no need to maintain thecurrent content of the web browser window when the new applicationis presented, that is, the new application can overlay the contents ofthe browser window without interfering with the user’s tasks.

Chapter 2 59

Web ApplicationsWeb Applications and Security

Web Applications and SecurityCustomers do not want all Internet users to be able to access theirmanagement applications and to manipulate the systems and networksthat are being managed. Because of the openness of the web, some formof security beyond the basic user login to the system is required for allweb applications.

Basic Security Measures

Recommended To protect both the user data and the network and system elementsbeing managed, web-based management applications should providesecurity based on logins and passwords.

Recommended For ease of use, users should only be required to log in once per session.

This login is recommended to be the one associated with the HPOpenView Launcher.

A user should not be required to give a login name and password forevery new URL or application that he accesses on the web. Since the HPOpenView Launcher provides a login for the user and then passes thisuser information on to applications, this should be the primarymechanism for controlling access to web applications. See “LaunchingWeb Applications” earlier in this chapter for more information on the HPOpenView Launcher.

User Roles and SecurityDifferent customer environments have different requirements forsecurity. Within the same customer environment, different users may bepermitted to have access to only a subset of the functionality that isprovided in a given application.

Recommended If an application provides the ability to configure different access rightsfor users, it should be developed so that users are not presented withlinks to which they do not have access. It is both confusing andfrustrating for a user to click on a link and then be told that he cannotaccess that link.

60 Chapter 2

Web ApplicationsGeneral Guidelines for Web Interfaces

General Guidelines for Web InterfacesWeb pages that present application functionality have the specificpurpose of enabling users to do their tasks. These types of web pages aredifferent from web pages intended for other purposes, such asinformation searches, advertisements, entertainment. The difference inpurpose requires specific guidelines for the application-focused webpages.

Named Web Browser WindowsUsing named browser windows can organize the user’s functionality intogroups and can allow for the simultaneous presentation of functionalityin different windows when this is appropriate to the users task. Javascript can be used to call named windows and this will allow the reuse ofbrowser windows for related functionality. This same use of Java scriptcan allow for the presentation of functionality in a new browser windowwhen this is appropriate.

Recommended All web applications presented in a browser should be presented innamed windows.

Recommended The names of the browser windows should be published so that otherapplications can use the appropriate named windows when calling thefunctionality.

The launcher registration file allows for the use of named windows andthese registration files can serve as a source for information about thenamed windows being used by other applications.

Recommended If the application provides a means of opening a new window containingthe same functionality as the current window, the new window will notbe named.

Leaving the new window unnamed will keep the copied window frombeing overwritten unless the user takes an action directly within thewindow. The original named window will be overwritten when relatedfunctionality is accessed in a separate window.

Recommended All of the following guidelines should be used in defining names for“named browser windows”:

Chapter 2 61


• All names should start with OvWww.

• Names should only contain alphanumeric characters.

Note: Spaces are not allowed.

• Each new word in a name should begin with a capital letter.

• Names should be related to the application or the presentationmanager that will be presented in the window.

Examples of named windows include:

OvWwwSnmpData Name for the window that presentsthe SNMP Data Presenter.

OvWwwHelpWindow Name for the full browser windowthat presents HTML help.

Using Color and PatternsColor is a very powerful visual cue that can be used by an application toconvey important information (for example, the status of managedobjects). But, if color is overused, it is no longer effective as a visual cueand can interfere with information reception. In addition, the overuse ofcolors can cause problems for users whose system displays might havelimited color maps.

Recommended Use color only to present important information to a user or as part ofthe symbols that represent objects. For additional recommendationsabout symbol design and the use of color, see Chapter 6, “Objects andSymbols,” and Chapter 8, “Visual Presentation.”

Recommended Verify that the colors used in an application will display as expected onall systems and browsers that the application supports.

Different browsers and browsers on different operating systems supportdifferent color ramps. The colors that an application can provide for itsgraphics may be dithered or may have different hues than expected.

Recommended If an application depends on user recognition of links for navigation,avoid changing the colors used for links.

Users of the web will have developed expectations based on theirprevious use of hyperlinks. If an application changes the colors it uses forits links, users may have difficulty in recognizing and using these links.

62 Chapter 2


Recommended Do not change the color of text that is presented in the main area of theapplication. Users will have trouble reading the text if there isinsufficient contrast between the background color and the color of thetext.

Required Any use of color should be consistent with the HP OpenView-definedstatus colors for objects. For additional information about status colors,see Table 2-1.

Table 2-1 Defined Color Usage for HTML Based Applications

ColorName

HexadecimalValue for

ColorDefined Color Use

white #ffffff 1) Background in scope pane2) Background inside tables that allow selection3) Text on title bar in application window4) Background for reports

black #000000 1) General text presented in application2) Labels for controls

navy #000080 1) Title bar for application

lightsteelblue #c0c0ff a 1) Highlight to surround selected items in thescope pane2) Highlight to surround selected items in a table

lightgrey #c0c0c0 1) Background for controls2) Background in tabbed controls or wizards3) General background in result area4) Background for toolbar area

lightyellow #ffffe0 1) Background for help text2) Alternative background to white or lightgrey

lightblue #add8e6 1) Alternating rows in reports used for highlight

green #00ff00 1) Normal status

red #ff0000 1) Critical status

yellow #ffff00 1) Minor status

orange #ff8000 a 1) Major status

Chapter 2 63


a. Hexadecimal values are different than the named colors for browsers.

Recommended Java applets and applications should use the Java System ColorVariables for setting the color of interface components. See Table 2-2 forspecific recommendations.

Use of the System Color Variables will enable an applets to appear as anapplication running natively on the client system.

cyan #00ffff 1) Warning status

ivory #ffffcc a 1) Unmanaged status

lightblue #0080ff a 1) Unknown status

darkred #640000 a 1) Disabled status

lightpink #ff80ff a 1) Acknowledged status

tan #ffbf66 a 1) Testing status

ColorName

HexadecimalValue for

ColorDefined Color Use

64 Chapter 2


Table 2-2 Defined Java System Color Variable Usage

System ColorVariable Name Defined Use In HP OpenView

background None

activeCaption 1) Highlight around label of selected items (iconviews, scope pane, full line in table views)

2) Highlight around label of selected menu items

3) Highlight around selected line in table

4) Background of window title bar with focus(active)

activeCaptionText 1) Text in label of selected items (icon views, scopepane, full line in table views)

2) Text in label of selected menu items

3) Text in selected line in table

4) Text in window title bar with focus (active)

activeCaptionBorder None

inactiveCaption 1) Background for title bar of window withoutfocus

(inactive window)

inactiveCaptionText 1) Text in title bar of window without focus

(inactive window)

inactiveCaptionBorder None

window 1) Background for scope pane

windowBorder None

windowText 1) Text in the status bar

2) Text in the scope pane

menu 1) Background for menu bar, pop-up menus, andpull-down menus

Chapter 2 65


menuText 1) Text for available menu items

text None

textHighlight None

textHighlightText None

textInactiveText 1) Text for unavailable menu items

2) Text for read only control labels

control 1) Background color for dialog boxes

2) Background for tabbed controls

3) Background for push-buttons

4) Background for read only text boxes

5) Background for inactive selectable lists

5) Background for read-only fields in grids

6) Background for toolbar

7) Background for icon presentation formats (forexample map)

controlText 1) Text for labels of available controls

2) Text inside read-write text boxes

3) Text in combination and option boxes

controlHighlight None

controlLtHighlight 1) Background for read-write text fields

2) Background for selectable lists

3) Background for tree lists

3) Background for read-write grid items

controlShadow 1) Surround color on selected icons in iconpresentation formats


66 Chapter 2


Recommended Do not present background patterns on an application’s web pages if thepages contain information that a user needs to read.

Displaying patterns adds clutter to the display and distracts the userfrom his intended task. Many background patterns also detract from thelegibility of any text presented in the display.

Using FontsIf an application manipulates the fonts on its web pages, keep in mindthat not all systems have the same fonts.

Recommended Do not specify specific fonts (for example, <FONT FACE=“Futura”> ) tobe presented unless it can be verified that these same fonts will beavailable on the user’s systems.

Ensuring that specific fonts are available on a user’s system may requirethe application to download the font for the user.

Recommended Do not change the font size for most text presented in the display. This isespecially true for extensive text that users will need to read.

Users may have their font sizes set to meet their individual preferencesor abilities. For example, users who have vision difficulties mayintentionally set an application’s fonts to larger sizes so they can moreaccurately see the information that they are trying to read.

Recommended If the font size for text presented in the browser is changed, it should bedone relative to the default font size rather than by setting an absolutefont size. Setting font size relative to the default allows users to maintaincontrol over the font size they are viewing (for example, <FONTSIZE=“-2”> ).

controlDkShadow None

scrollbar 1) Scrollbar

info None

infoText None


Chapter 2 67


Optional The font size of controls or buttons used in the screen can be set to allowthem to adequately fit in the display.

Using Graphics and Images

Recommended Use images on a web page only if the presentation of the image willimprove user performance over the presentation of simple text alone.

Images can lengthen the time to load a web page. In addition, too manynon- specific images can add clutter to the display and make it difficultfor a user to understand how to accomplish his tasks in the application.

Extraneous images with words like “NEW” and “Hot” have no place onapplication web pages.

Recommended Keep the size of displayed images small both in overall display size andin file size.

Larger images take longer to load than smaller images. They also takeup display space. When running an application in a web browser, displayspace is at a premium as the web browser already takes up a largeamount of the usable display space.

Recommended Provide an alternative textual means of presenting importantinformation for users who may have configured their browsers to notpresent graphical information.

Recommended Provide users with clear visual cues to indicate which images or portionsof an image have a link associated with them. Visual cues that users willassociate with links include the following:

• Presenting the images as three-dimensional controls that are similarin appearance to push buttons in regular application windows.

• Making any portions of images with links appear to be raised abovethe rest of the image.

• Presenting a band around the image that has the color used in links.

Recommended Do not use animated graphics or flashing images unless they are used inaccord with the guidelines for flashing discussed in Chapter 8, “VisualPresentation.”

68 Chapter 2


Scrolling

Recommended Minimize the need for users to scroll information in the screen.

Long web pages can cause some information to be hidden while otherinformation is visible. User testing suggests that users would prefer toaccess all needed information at a glance without the need to scrollthrough it.

A user’s willingness to accept scrolling is partially dependent on the typeof information that is being presented as well as on how he is trying touse the information. If users are managing a large number of objects ordealing with large amounts of information, it is difficult and notnecessarily meaningful to eliminate scrolling of the information. In suchcases where scrolling cannot be completely eliminated, the recommendedapproach is to view the screen from the point of view of the user and thetype of task that he is doing.

Recommended Make the most important information highly visible, and provide visualcues for accessing information that is currently not visible. Minimize thenumber of steps that a user must take to make the hidden informationvisible.

Even if content must be scrolled, a user should not need to scrollbackward or forward in the window to access the primary controls.

Recommended To minimize the need to scroll use one of the following mechanisms.

• Present controls in a separate frame that will make them constantlyavailable.

• If frames cannot be used, provide access to controls at both the topand bottom of the results pane.

NavigatingThe way users expect to navigate within an application is not the sameas when they are browsing for information on the web. User experiencewith applications has led them to expect tightly controlled navigationbased on their tasks. User experience with browsing for information onthe web has led them to expect navigation based on links and thesequence in which they have accessed these links.

Chapter 2 69


In a web-based application, users can benefit from having both thetightly-controlled application navigation presented in the applicationspace and sequential navigation presented through web browsercontrols. To make this strategy work well, adhere to the followingguidelines.

Recommended Make sure that navigation via the browser’s [Back] button leads to thelocations that would be anticipated by a user. Information that is notpart of the main interaction with the application should be presented ina separate window.

A user will likely become frustrated when the [Back] button takes himto help text or an error message when he was anticipating the previouspage in the application.

Recommended If an application consists of more than a single web page, providecontrols on all web pages that will allow users to navigate quickly toimportant application locations, using the following mechanisms.

• A [Help] button that will allow a user to access help information in aseparate web browser.

• A link or control that takes the user directly to the main applicationpage.

• A link or control to allow the user to move upward in the applicationspace if the application consists of hierarchically arranged pages.

• A frame that acts as a scope pane which allows the user to accessvarious application locations.

See guidelines in “Scope Pane” later in this chapter.

Recommended If an application uses frames, steps should be taken so that the use ofbookmarks takes a user to the information that was visible when thebookmark was set, and not to the location that was initially defined inthe frameset.

Updating Application InformationInformation on managed objects will not be useful to a user if it isinaccurate or out of date. Design the application so that it keeps anyinformation it presents adequately updated.

70 Chapter 2


Recommended Provide a visible timestamp in association with information that willchange dynamically. The timestamp should indicate the time at whichthe information was loaded into the browser.

NOTE When the information is updated, for example, the user reloads the webpage or the application automatically reloads information, thetimestamp should be updated.

Recommended Important information that changes dynamically and which needs to beaccurate should be automatically updated by the application, ratherthan being dependent on the user to refresh the displayed information.

It is recommended that this information be maintained via server pushmechanisms, which allow for faster presentation of a page’s subset.

Recommended Less dynamically changing information (or information that is lesscrucial to be accurate) can be handled either through:

• A [Refresh] button provided in the toolbar.

• Various client pull mechanisms that change the informationautomatically.

Chapter 2 71

Web ApplicationsWeb Applications Based on HTML

Web Applications Based on HTML

Using HTMLDifferent web browsers support different HTML commands, andsometimes present the same HTML in different ways. To be sure that anapplication is working as anticipated, test the interface on all of thesystem/browser combinations that the application will support. Beparticularly careful when using advanced HTML capabilities.

Using FramesFrames make use of the features of web browsers to structure anapplication’s functionality to better match the structure applicationswhich are presented outside of web browsers. The frames can be used toprovide a separation between the application and the web browser, tokeep user controls constantly visible, and to provide a quick-accessmechanism for navigating to different capabilities provided by theapplication.

Recommended The use of frames is recommended for most applications, unless theapplication is intended for users who will typically not have access to aweb browser with frame capabilities.

Recommended The use of frames is recommended for:

• Applications where users have functionality presented at two or morelevels of depth (such as an initial window, second-level functionality,and functionality below the second level).

• Applications that would have controls that could potentially scroll offthe screen if the information is presented without frames.

Using Tables

Recommended Minimize the number of borders presented in tables, as these borderscan cause visual clutter.

Recommended If tables are being used to provide an even layout of information ratherthan an actual table, specify the table to be without borders.

72 Chapter 2

Web ApplicationsWeb Applications Based on HTML

Recommended If the background of a table cell is to be used for indicating a selected oropen object, set the background to “lightblue”.

The color light blue allows text to be readable and allows the hyperlinkassociated with the text to be visible. See Table 2-1 for information on thespecific RGB values for colors.

Using FormsForms are the typical method for collecting user input in an HTML basedapplication. The guidelines for the design of forms in HTML are thesame as those for the design of dialog boxes when using Java or C++. Seerecommendations in Chapter 9, “Dialog Boxes and Controls,” forguidelines for how to design forms.

Recommended If a user is not required to fill in all fields on a form before submitting it,the [Apply] or [OK] button should be visible from all locations in theform.

Chapter 2 73

Web ApplicationsComponents of Web Applications

Components of Web ApplicationsGuidelines for windows and window components for Java applicationsand applets presented in Java frames as well as native applicationspresented in windows are presented in Chapter 4, “Using Windows,” andChapter 5, “Window Components.” This section covers the windowcomponents that should be provided by applications that are presentedinside a web browser.

Just as windows have different components associated with them, so doweb pages for applications have different components associated withthem. Maintaining a certain level of consistency across these keycomponents can aid a user both in learning to use various HP OpenViewapplications and in locating information within each application. Keycomponents to be used in applications presented inside a web browserinclude

• Title bar (required)

• Context area (optional)

• Toolbar area (optional)

• Scope pane (optional)

• Results pane (required)

• Control/status frame (optional)

Title Bar

Required A title bar is required for all HP OpenView applications presented in aweb browser. If an application uses frames, the title bar should bepresented in a separate frame.

The title bar provides contextual information that informs the user of hislocation within the application when a new web page is presented. Thetitle bar also provides the user with a visual cue that separates theapplication window from the web browser and its controls.

Recommended The title bar should use the colors specified in Table 2-1 or Table 2-2.

74 Chapter 2


Recommended The size of the title bar area should be approximately 30-40 pixels inheight, and it should extend across the entire page.

Recommended Graphics can be presented in the title bar if they will help identify theapplication. These graphics should be no more than 24 pixels in height.

Recommended The label in the title bar will depend on the style of window that is beingpresented in the web browser, how the page was accessed, and whetherthe contents of the window are associated with a single object or multipleobjects. Follow the recommendations in Chapter 5, “WindowComponents,” for the format and content of the title bar.

Context Area

Required If an application allows users to switch between different managementcontexts (different hierarchies of managed objects or different types ofmanagement capabilities like accounting versus systems management),then provide this ability to switch contexts through a context control.

Recommended The context control should be presented in a small frame on the left sideof the toolbar directly beneath the title bar, or as a control within thetoolbar.

Recommended The context control should determine what information or controls arepresented in the web page. A change in the context control may result ina change in all frames presented on the web page. See “Context Controls”in Chapter 5 for more information on context controls.

ToolbarSince there is currently no way to present a pull-down menu in anapplication presented in a web browser, most functionality associatedwith the web application should be presented in a toolbar frame or in toolbuttons in the results pane. The toolbar in the web browser, unlike thetoolbar in an application window, is not simply a quick-accessmechanism. It may be the only method for accessing functionality.

NOTE When functionality becomes available for true menus, web applicationsshould provide a menu pane for presenting the bulk of theirfunctionality.

Chapter 2 75


Recommended An application should provide a toolbar if the application presentsobjects in the results pane, and:

• Users will need to specify actions to take on those objects.

• Users will need to specify a different view of these same objects (forexample, graphic versus tabular view of objects).

Recommended If an application provides so much functionality that the toolbar willneed to scroll, the application should be created so that it runs in a Javaframe outside of the web browser and uses a menu.

Recommended The default location for the toolbar should be directly below the title bar.It is beneficial to allow users to configure the toolbar to be in a differentlocation.

Recommended Only display toolbar buttons in the toolbar frame which are applicable tothe current context.

Following this guideline will minimize the number of controls presentedin the toolbar at any one time.

Recommended Provide visual cues for the toolbar buttons to make it clear to users thatthey can be clicked on for accessing functionality.

Visual cues that can be used to inform users that the toolbar imagesaccess functionality include:

• Providing tool tips that indicate the functionality that can be accessedby the button.

• Making the images change on mouse over so that it is clear that theycan be activated, this is similar to the visual cues provide in theNetscape and Internet Explorer Browsers.

• Giving the images in the toolbar a three-dimensional appearance sothat they appear to users as if they can be pressed.

• Providing a label for the image that is underlined. Since hyperlinksare typically underlined, the underlining of the label will indicate tothe user that the image and label are a link to some otherfunctionality.

76 Chapter 2


Recommended If there is an HP OpenView-provided toolbar buttons for thefunctionality that is provided in the application, use a GIF image of theexisting toolbar button to provide access to that functionality. SeeChapter 6, “Objects and Symbols,” for more information.

Recommended If there are no HP OpenView-provided toolbar buttons that match thefunctionality of the application, develop a GIF image that looks like abutton and contains an image which clearly represents the action to beassociated with the button.

It is always a good idea to run user tests on the icons to be used in thetoolbar. Tests should evaluate both a user’s ability to associate the iconwith the functionality it represents and the user’s ability to recognize theicon once the association has been learned.

Recommended To aid users in recognizing and learning to use the tools in the toolbar,use one of the following mechanisms:

• Include labels under the toolbar buttons to define the functionalitythat will be accessed by clicking on the button.

• Provide pop-up messages that appear when the pointer moves overeach toolbar button.

These pop-up messages can be provided by specifying alternative textassociated with each of the images.

• Provide active help in the status area of the same window thatcontains the toolbar. The active help should change as the pointermoves over the various images in the toolbar.

Required Toolbar buttons should adhere to one of the following guidelines:

• Provide general functionality that does not require a selected object.

• Provide functionality that is applicable to any object presented in theresults pane.

• Appear grayed-out when the user selects an object in the results panefor which the toolbar button functionality is not available.

Chapter 2 77


Scope PaneThe scope pane is on the left side of the page under the context controland toolbar. Items presented in the scope pane should provide users withlinks to different sets of information that can be presented in the resultspane.

Recommended Provide a scope pane in an application window if the application consistsof multiple pages that a user would want to access and view.

Recommended The scope pane should be presented in a separate frame to the left of theresults pane.

Required The scope pane must be resizeable by the user.

The scope pane takes up space that would otherwise be used to presentthe content of the web page. Therefore, when a user has finished with thescope pane, he may want to redistribute the window space to better suithis task needs.

Recommended If a user changes the current context by means of the context control, thescope pane’s contents should also change to match this new contextsetting.

Required Any currently selected items in the scope pane should be marked by aselection indicator or by a selection toggle.

• If a selection indicator is used, it should be a block of colorsurrounding the item’s label. See Table 2-1 and Table 2-2 forinformation on the specific colors to be used.

• If a selection toggle is used, it should be either:

• A radio button (if all items in the scope pane are mutuallyexclusive).

• A check box (if multiple selection of items is allowed).

Recommended To minimize user actions, radio buttons or check boxes shouldautomatically be submitted when the user clicks on them. Users shouldnot be required to click on a submit button after making a selection via aradio button or check box.

78 Chapter 2


Recommended The location cursor in the scope pane should be indicated by one of thefollowing:

• A black rectangle outlining the item that the location cursor is on.

• An arrow pointing at the item’s icon or label and which is placed tothe left of the label.

Results PaneThe results pane is the area used for presenting both any managedobjects and the main functionality of the application.

Recommended When a user first enters the application window, the results pane shouldnot be empty. If there is a scope pane in the window, the results paneshould present the information associated with the first link in the scopepane or the last link that the user accessed within this applicationcontext.

Recommended If an application requires the selection of both an object in the resultspane and an action in the toolbar, a user should be able to select theobjects without taking a step to submit his selection. For example, theuser should not have to press a submit button after a selection beforethey can access actions in the toolbar.

Recommended If an application provides functionality that is applicable to some, butnot all, objects in the results pane, any toolbar buttons that areinapplicable to the currently selected objects should be grayed. If theseinapplicable toolbar buttons cannot be grayed, consider presenting theobjects in a table. Provide functionality that is applicable to only a subsetof objects in a column labeled “Operations,” as shown if Figure 2-3. Thisfunctionality should be presented in the row for an object only if it isapplicable to that object.

Chapter 2 79


Figure 2-3 Web Application

80 Chapter 2


Control/Status FrameThe use of a control/status frame is optional for HP OpenView webapplications.

Recommended If a control/status frame is provided, it should be presented beneath theresults pane in a separate frame.

Recommended The control/status area should be used to provide state informationrelevant to the objects or information presented in the results pane, or toprovide users with controls that need to be constantly visible but whichare too complicated or inter-related to be presented in the toolbar.

81

3 HP OpenView PresentationManagers

82 Chapter 3

HP OpenView Presentation Managers

Presentation managers are windows which present users with views ofmanaged objects, access to functionality for manipulating objects,guidance in accomplishing tasks and/or a means of presentinginformation on managed objects. Presentation managers aredistinguished from other windows in that they are designed to suit theuser’s needs and to minimize the number of windows that the user needsto navigate through in order to accomplish their goals. Typicallypresentation managers will allow the integration of other relatedapplications so that users can access necessary information for a givenmanagement area or task from within a single window.

This chapter discusses the various types of presentation managers thatare recommended for the HP OpenView environment and some of theguidelines associated with their implementation. The presentationmanagers described include:

• Object Presentation Managers

• Task Presentation Managers

• Information Presentation Managers

• Multiple Purpose Presentation Managers

Chapter 3 83

HP OpenView Presentation ManagersObject Presentation Managers

Object Presentation ManagersObject presentation managers present views of managed objects andprovide access to functionality for managing those objects. For anexample of an object presentation see Figure 3-1. Typically thesepresentation managers present object folders, object groups, containerobjects, and individual objects in the scope pane. In the results pane,they may present information related to the selected object.

Many of the more recent HP OpenView applications are objectpresentation managers or are integrated into object presentationmanagers (for example, Network Presenter or Manage X). Generalguidance on the style for object presentation managers is too detailed tobe presented in this chapter and can be found in chapters 4 through 8 ofthis style guide.

Recommended Object presentation managers are recommended for applications thatdeal with managed objects and want to provide views showingrelationships between objects and information on the attributes of theobjects (for example, status, properties).

Required The scope pane of an object presentation manager should only containobject folders, object groups, container objects (for example, subnet), orindividual objects.

For more information on guidelines for the scope pane see “Scope Pane”in Chapter 5. For more information on object groups, see “Groups” inChapter 77.

Required The information in the results pane of an object presentation managermust be directly related to the selected object in the scope pane. This caninclude any of the following.

• Graphical views related to the selected object or object groups (forexample, topological views of object relationships, pictures of theobjects back-plane or controls).

• Charts and graphs showing data relevant to the selected object or ifthe selected object is an object group or container, data on a subset ofthe contained objects may be shown.

84 Chapter 3

HP OpenView Presentation ManagersObject Presentation Managers

• Table of data relevant to the selected object or if the selected object isan object group or container, data on the contained objects may beshown.

• Tab control with the properties of the selected object group, containerobject or individual object.

• A wizard or tab control for a frequent task related to the selectedobject, container object, or individual object.

Recommended If a wizard or tab control is presented in the results pane of an objectpresentation manager, follow the guidelines on the use of wizards, use oftab control and the labeling of push buttons under “Task PresentationManagers” below.

Recommended Object presentation managers should provide menu access to otherpresentation managers related to the objects that they present.

Figure 3-1 Object Presentation Manager

Chapter 3 85

HP OpenView Presentation ManagersTask Presentation Managers

Task Presentation ManagersTask presentation managers provide user access to wizards and tabcontrols that guide the user through task steps and allow the user toquickly access related tasks. Typically these presentation managerspresent tasks folders and individual tasks in the scope pane. In theresults pane, they present lists of tasks, wizards or tab control foraccomplishing the task.

In addition to recommendations and requirements presented in thissection of the style guide, other guidance on the style for taskpresentation managers can be found in Chapter 2, “Web Applications,”Chapter 4, “Using Windows,” Chapter 5, “Window Components,” andChapter 9, “Dialog Boxes and Controls.”

Figure 3-2 Task Presentation Manager with a Task Presented in a Wizard

86 Chapter 3


Recommended Task presentation managers are recommended for applications want totake a task oriented approach for presenting their functionality andwhich have no need to allow users to access the functionality in terms ofthe object being acted on.

Required The scope pane of an task presentation manager should only containtask folders or individual tasks.

For more information on guidelines for the scope pane see “Scope Pane”in Chapter 5.

Required The information in the results pane of an task presentation managermust be directly related to the selected item in the scope pane. This caninclude any of the following.

• Graphical views of tasks if the selected item is a task folder (forexample, large or small icon views of tasks).

• Table of information on contained tasks if the selected item is a taskfolder (for example, task name and task description).

• Tab control or wizard for accomplishing the task if an individual taskis selected.

Recommended The task presentation manager should present the task as a wizard thatguides the user through the task using next and previous buttons whenone or more of the following are true:

• The task involves a set of steps or subtasks that the user must do in aproscribed sequence to successfully complete the task.

• The task involves a set of steps or subtasks and user’s must completeeach step or subtask to successfully complete the task.

• Users do the task infrequently and will need guidance to complete thetask.

Creation and initial configuration are examples of tasks that are bestpresented in a wizard. See Figure 3-2 for an example of a task presentedin a wizard inside a task presentation manager.

Chapter 3 87


Recommended The task presentation manager should present the task in a tab controlwhere the user can choose what tabs they want to access and modifywhen:

• The task allows users to complete actions or subtasks in anysequence.

• The task does not require user interaction for all subtasks or stepsand users may want to do only a subset of the task steps.

• The users will do the task frequently and may want to access the tasksteps in an unconstrained manner.

Modification of settings and new configurations based on a template areexamples of tasks that are best presented in a tab control. See Figure 3-3for an example of a presentation manager with a tab control.

Figure 3-3 Task Presentation Manager with Task Presented in a TabControl

88 Chapter 3


Recommended The labeling of buttons used at the bottom of tab controls presented in atask presentation manager should correspond to the behavior that willwould be expected based on the label:

• [Ok] should only be used if the wizard or tab control foraccomplishing the task will be removed when the button is pressed.The task presentation manager should not be closed when the userclicks on an [Ok] button.

• [Apply] or [Save] should be used in place of [Ok] if the tab controlor wizard will not be removed when the button is pressed.

• [Cancel] should only be used if the wizard or tab control foraccomplishing the task will be removed when the button is pressed.

• [Reset] should be used in place of [Cancel] if the wizard or tabcontrol for accomplishing the task will not be removed when thebutton is pressed.

Typically[Ok] and [Cancel] are only appropriate for multiple purposepresentation managers in which the wizard or tab control will bereplaced by a view of managed objects related to the task that wascompleted or canceled.

Recommended Task presentation managers should allow users to bring in selectionswhen they are launched from object presentation managers. They shouldalso allow users to access object presentation managers when users needto make a large number of selections.

Recommended When a user has started a task in the task presentation manager but hasnot completed it before starting a new task in the same presentationmanager:

• The users should be given a means of reaccessing the partiallycompleted task at a later time without the loss of entered data.

or

• Before the initial task is overlaid, the user should be presented with aconfirmation dialog box indicating that the data will be lost if the userchooses to proceed with the new task.

Chapter 3 89


Examples of mechanisms for reaccessing the partially completed taskwould include the use of navigation tabs (see “Navigation Tabs” inChapter 5) that allow access to the task (see Figure 3-4) or providing aback button that would take users back to the screen with the partiallycompleted data.

Figure 3-4 Visual Cues and Task Completion Feedback in a TaskPresentation Manager

Recommendation When there has been a change of state in an ongoing task, that is notcurrently visible in the task presentation manager, there should be avisible indication to the user of the change in state. When navigationtabs are provided:

• A check mark on the left side of the navigation tab is recommended asa visual indicator that the task was successful or there is a change instate that does not include an error.

• An exclamation mark in the appropriate status color (red=critical,orange=major, yellow=minor) is recommended as a visual indicatorthat there is a change in task status that includes an error.

90 Chapter 3


Providing a visual indication of a change in state, notifies the user thatthey should return to the task to determine what has happened. In theexample in Figure 3-4, the check mark in the navigation tab is indicatingthat the installation of the software have been completed.

Required When the user takes an action that successfully completes a task withinthe task presentation manager and the wizard or proprieties box is notremoved, a message must be given that indicates that the task has beensuccessfully completed.

Required When the user takes an action to complete a task within a taskpresentation manager and there is an error that prevents successfulcompletion of the task, an error message must be presented thatindicates what problems prevented the task from successfully beingcompleted.

Users expect to have feedback on the completion of a task. Taskspresented in a stand-alone wizard, have the wizard disappear when theuser presses the [Finish] button. Similar completion feedback isneeded in a task presentation manager. The presentation managershould not be dismissed when the user completes a task as the user maywant to start a new task or may have other tasks in progress. In general,in a task presentation manager that does not also present objects, thefeedback needs to be in the form of a message. See Figure 3-4 for anexample.

Recommended If a task presented in a tab control has related tasks that the user maywant to do after finishing the initial task, all guidelines below should befollowed:

• The last tab in the tab control should present users with informationon the related tasks and a means of accessing the functionality to dothe related tasks.

• In the Related Tasks tab, visual cues should be provided that allowdifferentiation between related tasks that are optional and relatedtasks that are required but may be deferred until a later time.

Related tasks that are required should be indicated by the word“(Required)” in parentheses following the task name. Related tasksthat are optional should be indicated by the word “(Optional)” inparentheses in following the task name.

Chapter 3 91


• If there are related tasks that are required for the user to achieve themost likely goals of the initial task, the related task tab shouldautomatically be presented to the user at task completion, instead ofa completion message.

Immediately taking users to the related task tab instead of giving acompletion message when related tasks are required helps prevent usererrors. When users are new to an application or when they do tasksinfrequently, they may not recognize the full sequence of tasks that areneeded to accomplish a larger goal. Users are not required to do therelated task from this tab. They can choose to put off related tasks thatare required until a more convenient time. See Figure 3-5 for an exampleof a tab for related tasks.

Even when related tasks are optional, having a related task tab providesbenefits to the user. This tab helps inform users about loosely relatedtasks and introduces users to other functionality that your applicationprovides.

NOTE Related tasks that are required and which cannot be deferred to a latertime should be presented as steps in the tab control or wizard.

92 Chapter 3


Figure 3-5 Related Task Tab in a Task Presentation Manager with a TabControl

Chapter 3 93

HP OpenView Presentation ManagersInformation Presentation Managers

Information Presentation ManagersLike object presentation managers and task presentation managers,information presentation managers minimize the number of windowsthat appear in the display by reusing the results pane. Informationpresentation managers may provide an integration point for tools thatact on similar types of objects. Information presentation managers alsohelp to eliminate menu clutter by allowing multiple tools to be accessedby means of a category name that represents all of the tools of a giventype. Information presentation managers can also increase usereffectiveness and efficiency by allowing the user to access a variety ofinformation on the objects included in the selection list without the needto return to the menus in an object presentation manager window. For anexample of a information presentation manager see Figure 3-6.

In addition to recommendations and requirements presented in thissection of the style guide, other guidance on the style for informationpresentation managers can be found in Chapter 2, “Web Applications,”Chapter 4, “Using Windows,” Chapter 5, “Window Components,” Chapter8, “Visual Presentation,” and Chapter 9, “Dialog Boxes and Controls.”

94 Chapter 3


Figure 3-6 Example of an Information Presentation Manager

Recommended Information presentation managers are recommended for:

• Multiple tools that are related to one another in the type ofmanagement information that they provide (for example, SNMPData, Reports).

• Tools that require the same capabilities in the objects on which theycan act (that is, the same selection criteria in the registration file).

Chapter 3 95


Required The scope pane of an information presentation manager should onlycontain folders or individual reports or types of information that can beaccessed.

For more information on guidelines for the scope pane see “Scope Pane”in Chapter 5.

Required The contents of the results pane of an information presentation managermust be directly related to the selected item in the scope pane. This caninclude any of the following.

• Graphical views of information or reports if the selected item is afolder (for example, large or small icon views of information).

• Table of data on contained reports or information if the selected itemis a folder (for example, report name and report description).

• Charts, graphs, tables of information and/or relevant descriptive textif the selected item is an individual report or information item.

Recommended Information presentation managers should allow users to bring inselections when they are launched from object presentation managers.They should also allow users to access object presentation managers formaking selections.

Recommended If information items or reports in an information presentation managerrequire a selection but are not applicable to the current selection, theyshould be shown as unavailable (that is, grayed).

Providing an error message after the user has selected the report orinformation item results in unnecessary user actions and can frustratethe user. The unnecessary user actions can be avoided by presenting theappropriate visual cues.

96 Chapter 3

HP OpenView Presentation ManagersMultiple Purpose Presentation Managers

Multiple Purpose PresentationManagersMultiple purpose presentation managers provide separate scope paneswhich present different types of items, that is, tasks, information, orobjects. These presentation managers allow users to switch between thedifferent types of scope panes using context tabs at the bottom of thescope pane.

Figure 3-7 Multipurpose Presentation Manager

Recommended Multiple purpose presentation managers are recommended for:applications whose functionality is implemented to allow the user tochoose the approach that he will want to take in accessing theapplication’s functionality (that is, task-oriented, object-oriented andinformation oriented).

Chapter 3 97


Required The multiple purpose presentation manager must provide context tabs toallow users to change between the types of items that it provides (i.e.,objects, information and / or tasks). A single scope pane should notprovide a mixture of tasks, objects and information.

For more information on context tabs, see “Context Controls” in Chapter5.

Required The behavior of multiple purpose presentation manager must conform tothe following guidelines:

• When the context tab is set to objects, the presentation managerbehaves like an object presentation manager.

• When the context tab is set to tasks, the presentation managerbehaves like a task presentation manager.

• When the context tab is set to information, the presentation managerbehaves like an information presentation manager.

98 Chapter 3


99

4 Using Windows

100 Chapter 4

Using Windows

This chapter covers the following topics:

• Types of windows that can be used in HP OpenView applications andguidelines on when to use each type.

• Guidelines for splitting application windows.

• Guidelines on when to create new windows as compared to usingexisting windows.

Chapter 4 101

Using WindowsWindows in the HP OpenView Environment

Windows in the HP OpenViewEnvironmentThe basic means by which an application presents managed objects andallows access to application functions is through primary windows anddialog boxes. Dialog boxes are discussed in Chapter 9, “Dialog Boxes andControls.” This chapter and Chapter 5, “Window Components,”coversguidelines associated with windows.

A variety of primary window styles are allowed in HP OpenView,including

• Scope pane windows

• Single pane windows

• Multiple pane windows

NOTE Microsoft’s Management Console (MMC) and Manage X both use MDIwindows. It is also possible that other future HP OpenView managementplatforms may use MDI windows. As a result, it is not recommended thatintegrating applications use MDI windows. This could potentially causea MDI window inside a MDI window.

Scope Pane WindowsScope pane windows are ones that have a scope pane and a results pane.Scope pane windows minimize the number of windows that appear in thedisplay by reusing the results pane to present different sets ofinformation (for example, managed objects, tasks, or information andreports). Scope pane windows allow users to select the objects, tasks ordata to be presented in the results pane by making a selection in thescope pane. The selection can be from a hierarchical listing of objects orfrom sets of categories that are matched to determine the objects that arepresented. These windows allow users to quickly move between differenttypes of data.

The management hierarchy that is presented in the scope pane providesnavigational cues to users so they are less likely to get lost in complexhierarchies. Returning to previously viewed information requires feweruser steps, as multiple locations at different levels in the hierarchy aresimultaneously visible and accessible. See Figure 4-1.

102 Chapter 4


Scope pane windows that present categories of information allow theuser to select multiple categories and to see data from the combination ofthese categories in the content pane. The categories act somewhat like afilter and allow users to quickly see different amounts of information.See Figure 4-2.

Figure 4-1 Scope Pane Window with Network Hierarchy

Chapter 4 103


Figure 4-2 Scope Pane Window with Categories to be Matched

When to Use

Recommended Scope pane windows should be used for the presentation of:

• Managed objects that fit within some type of hierarchy (for example,an IP Network hierarchy, a hierarchy of defined processes, or ahierarchy of levels within a correlation definition).

• Sets or groupings of loosely or tightly related objects or componentsthat can be grouped into categories or subsets of objects (for example,all components that can be configured as part of setting up a backup,or all components of an event correlation that can be grouped into the“compound correlation nodes” that contain them).

• Managed objects or information on managed objects where there arespecific well-known categorizations or filters that users would want toapply, based on the characteristics of the objects or data (for example,reports on objects that can be filtered).

104 Chapter 4


• Information on a hierarchy of managed objects or object components(for example, reports on managed objects).

• Information that can be grouped or categorized (for example,messages or events associated with managed objects).

• Online help information that has a hierarchy of topics or set ofrelated topics.

• Sets or groupings of tasks that can be categorized and presented tothe user.

• Sets of functionality that can be categorized and presented to the userin a meaningful hierarchy.

Single Pane WindowsSingle pane windows provide the user with a view of a single set ofobjects that is separated from other information which may or may notbe relevant to the user’s task.

Optional Single pane windows can be used for:

• Displaying objects or information when navigation, filtering, or accessto other objects are not necessary for the user’s task.

• Displaying tasks that can be completed in a single window ofinformation without any need to access other objects, information ortasks.

Recommended When possible, single pane windows should be integrated with otherapplications in a scope pane window.

Multiple Pane WindowsDevelopers can chose to have multiple window panes which used forpurposes other that navigation as in the scope pane or presenting asingle set of results as in the results pane of a scope pane window.

Recommended Multiple pane windows should be used only for complex activities wherethe user needs to carry out multiple types of activities simultaneouslyand the panes are needed to separate different types of information (forexample, navigation, controls, or summary information).

Chapter 4 105


Figure 4-3 A Multiple Pane Window

106 Chapter 4

Using WindowsSplit Windows

Split WindowsSplit windows are windows in which the number of panes beingdisplayed can change, based on actions taken by a user.

Recommended If a scope pane window can be split and if the contents of the split resultspane can be associated with different items in the scope pane, implementall guidelines below:

• Both the results pane and the scope pane should be split horizontally,so that there are two scope panes and two results panes.

• If there are context tabs, they would be presented in each of the twoscope panes.

• If there are navigation tabs, they would be presented in each of thetwo results panes.

Navigation and context tabs have visual cues that make them appearto be attached to the window contents. This may confuse users if thetabs are not contained within the pane in which they will change theinformation. See Figure 4-4 for an example.

Recommended If a scope pane window can be split but the contents of the split resultspane can only be associated with a single item in the scope pane, only theresults pane should be split.

Splitting only the results pane maximizes the amount of display spaceused for viewing the object, tool outputs, data set, or task.

Recommended If the mechanism for splitting of window allows a user to specify what isto be presented in the new pane:

• The top or left-half of the split should contain the requestedinformation.

• The bottom or right-half of the split should show the view that wasactive at the time the split was requested.

A pop-up menu that provides an item labeled Show in New Pane is anexample of a mechanism that allows users to choose what information ispresented at the time they request the split.

Chapter 4 107


Recommended If the mechanism for requesting the splitting of the window does notallow a user to specify what goes in the new pane, the split should resultin the presentation of the same information in both halves of the split.

Split controls in the scroll bars and a pull-down menu item for Split areexamples of mechanisms that do not allow users to choose whatinformation is to be presented at the time they split the window.

Recommended If functionality is provided for splitting a window, a means of changingthe information in the different split panes needs to be provided.

Examples of mechanisms for changing the information in split windowsinclude:

• Scroll bars in both halves of a split window provide a means ofviewing different locations within the same object, tool output, dataset, or task.

• Scope panes in both halves of a split window allow users to choosedifferent objects to be presented in the split results pane.

• Navigation tabs in both halves of a split scope pane window allowusers to navigate to different views.

• A context list tied to the active pane in a split window allows users topresent different information in each of the split panes.

Recommended In a split window, the contents of the menu items, toolbar items, andcontext list should be determined by the pane that is active (has thefocus).

Having the menu and toolbar items tied to the context of the active paneis intuitive for users. Different panes within the window are made activeby clicking in the pane. When a user selects an object within a pane, itshould make the pane active and set the menu context to the view in thatpane. This will result in a set of menus that is tailored to the objectswithin the active view.

In Figure 4-4, the top scope and content pane are currently active. Themenu bar and toolbar are specific to this pane. Users can use the contextcontrol to change the navigation hierarchy for one of these panes andleave the context for the other pane unchanged.

Recommended The active pane of a split pane window should provide visual cues to theuser to indicate that it is the active pane.

108 Chapter 4


Examples of visual cues to indicate that a pane is active include a blackbox surrounding the active pane or a more brightly colored selectioncursor.

Figure 4-4 A Split Scope Pane Window

Chapter 4 109

Using WindowsCreating New Windows

Creating New WindowsIt is very typical in web applications to access a link and have that newinformation or functionality overlay the current results pane. Similarbehavior occurs with scope pane windows. While it is generally a goodidea not to clutter the user’s display with numerous new windows, thereare occasions when the presentation of a new window will benefit theuser.

Adhere to the following guidelines when deciding whether or not topresent a new window.

Recommended If a user will want to have simultaneous access to an existing window’scontents as well as to any newly requested material, then present therequested information in a new window.

Examples of ways that users request new information includes selectingmenu items, pressing push buttons, or selecting links in webapplications.

Recommended If the information is likely to be used in a sequential manner with noneed for simultaneous viewing, present the information in the currentwindow.

Recommended If a user is working with an application and takes an action that willresult in the presentation of help information, and there currently is noopen window that is displaying help, open a new window containing therequested help information.

Allowing a user to look at the application window at the same time thathe reads the help information will provide the most benefit from the helpthat is presented.

Recommended If a user is working with an application and takes an action that willresult in the presentation of help information, and there currently is awindow that is displaying different help information, use the open helpwindow and overlay the displayed help information with the requestedhelp information.

Recommended If a user requests access to an application that is already running in aseparate window, bring the open window to the top displaying therequested functionality.

110 Chapter 4

Using WindowsCreating New Windows

For example, an application presents detailed information on objects in aseparate window. This allows users to simultaneously view the status ofvarious managed objects as well as the details for just a single object.The first time that the user requests details on a specific object(Object A), a new window pops up to present the detailed information.When the user requests details on a different object (Object B), thedetailed information on Object A is replaced with the information onObject B.

Recommended If a user presses a toolbar button to request the presentation of thecurrent view in a new window, present a new window that provides thesame information that was in the initial window.

111

5 Window Components

112 Chapter 5

Window Components

The windows used for HP OpenView applications have a number ofdifferent components, as shown in Figure 5-1. Maintaining a certainlevel of consistency across these key components can aid users inlearning to use various HP OpenView applications and in locatinginformation within them. Key HP OpenView window componentsdiscussed in this chapter are:

• Title bar

• Menu bar and pop-up menus

• Toolbars

• Context controls

• Description bar

• Scope pane

• Results pane

• Navigation tabs

• Status bar

Chapter 5 113

Window ComponentsIdentification of Window Components

Identification of Window ComponentsAt a minimum, every HP OpenView application must provide a title barand a results pane in their windows; the remaining components shownbelow are optional.

Figure 5-1 Window with Its Components Identified

114 Chapter 5

Window ComponentsTitle Bar

Title BarThe title bar provides the user with a means for distinguishing differentwindows that may be presented on the desktop. It also providescontextual information to inform a user of his location within theapplication. When an HP OpenView application window is presentedwithin a web browser, it provides the user with a visual cue (the title bar)that separates the application window from the web browser and itscontrols.

Required A title bar must be provided for all HP OpenView application windows.

The contents of the title bar will depend on the style of window, whetherthere are multiple instances of the window, how the window wasaccessed, and whether the contents of the window are associated with asingle object or multiple objects.

Recommended The title bar should contain specific fields in a specific sequence, asshown below in the syntax and in the example beneath the syntax:

icon object,_tool,_task,_item - application_name window_id

The sequence of these fields is intended to provide a user with as muchdefinitive information as possible when he first reads the title, or toidentify the window’s contents when it is minimized and the title istruncated.

icon: The icon should be a 16x16 graphic that represents theapplication or set of applications associated with thewindow.

object, tool, taskor item: This entry is intended to provide a user with

information that is related to where he is within theapplication and what he is currently doing. As the usernavigates within the window and changes theinformation presented in the window, this field withinthe title bar should change to match the currentlocation in the window:

Chapter 5 115


• If the results pane of the window is related to asingle object, that object’s name should appear inthis field (for example, as in an object presentationmanager).

• If the results pane of the window is displaying a setof data, the name for the data set should appear inthis field (for example, as in an informationpresentation manager).

• If the results pane of the window is presenting atask, the task’s name should appear in this field (forexample, as in a task presentation manager, dialogbox or wizard).

applicationname: The application name is required in the title bar

because there are typically multiple applicationsrunning in an HP OpenView environment. If a userencounters a problem or needs to accessdocumentation, he will need to know whichapplication’s documentation to read. To save space, it isrecommended that the application name be presentedin abbreviated format. Examples of application namespresented in abbreviated format are NNM, ITO, andITA.

window id: The window id is helpful to users for differentiatingbetween multiple open windows which contain thesame title. The window id would be a number such as1, 2, or 3. The window id is only used when the user hasopened new window which has the same content as anexisting window open on the display.

An example of a title bar for an object presentation manager focused on asingle object appears below:

An example of a title bar for an object presentation manager for whichthe user had accessed a second window with the same content as anexisting window is shown next:

116 Chapter 5


An example of a title bar for an information presentation mangershowing the routing table for one or more objects would look like thefollowing:

An example of a title bar for a task presentation manager where thecurrent tasks is setting up a new alarm would be this:

Chapter 5 117

Window ComponentsMenu Bar and Pop-Up Menus

Menu Bar and Pop-Up Menus

Menu BarMenu bars provide a means of making the application functionalityvisible to the user while occupying a minimal amount of display space.They minimize the clutter associated with the presentation ofapplication functionality. Unlike pop-up menus, the menu bar iscontinuously visible, and this provides a cue to the user about the type offunctionality that is potentially available. It is therefore much easier forusers to learn to use functionality provided in a menu bar than in pop-upmenus.

One of the fundamental concepts of HP OpenView is to prevent usererrors whenever possible. By using consistent cues in the menu labels,an application can give users information on how each item functionsbefore they select an item. And menus which are used in a consistentmanner will provide continuity between applications.

The menu bars within HP OpenView application windows should followthe following recommendations.

Optional Menu bars are optional for HP OpenView application windows. However,if a large amount of functionality is presented in an application’s window,a menu bar is recommended.

Recommended Do not specify application-specific menu items to be presented in themenu bar of an HP OpenView application window; this should be doneonly by the developer who is responsible for creating the navigationcontext that is presented in an application’s window. Instead, menuitems should be placed under the existing menu bar categories.

Recommended Developers who have created the hierarchy presented in theirapplication’s window should choose appropriate menu items from thecontainer, general-purpose, or managed-object menu subsets describedbelow.

118 Chapter 5


Container MenuThis type of menu should contain menu items that are related to theaccess and manipulation of the container itself. It also has menu itemsfor opening other containers of the same type and general functionality(such as printing). Examples of container menus are File, Map, Browser,and Process.

Required If there is a menu bar, there should be a container menu. This menushould always be the left-most menu item in the menu bar.

Required All application windows must have a Close menu item in the first menuin the menu bar (for example, File:Close or Map:Submap->Close ).

Recommended The name for the container menu should be chosen to reflect the types ofmanaged objects being presented and whether or not the managedobjects are contained in files.

In a context that presents network objects, for example, the name of thecontainer menu could be Map or Network. Other examples for this menumight be Processes (for a process management application) or Circuits(for an application that is used for building event correlation circuits). Inapplications that deal with files, it is recommended that the name of thecontainer menu be File.

Recommended If there is no meaningful container menu for your application, youshould use File as the container menu.

File is used as the container in a large number of applications. Users willnot be confused by having it as the first menu in your menu bar.However, they would become confused if there is no container menu atall in the application.

General-Purpose MenuTypically, general-purpose menus do not contain specific managementfunctionality. Instead, these menus provide generic functionality that isneeded by a variety of applications, regardless of the specific type ofmanagement functionality being provided by the application. While someof these menus will be used by all applications (for example, Help ), othergeneral-purpose menus (such as Edit ) will be needed only by a subset ofthe applications. When general-purpose menus are used, HP OpenView

Chapter 5 119


users will benefit from having consistent naming in the menu bar andconsistent placement of menu items under these menus so that they caneasily locate this common functionality.

When providing the general functionality that is not specific to a type ofmanagement, present the functionality under the appropriate genericmenu bar label as described below.

Edit Use for menu items that edit the content of the currentlocation in the managed object hierarchy and theproperties of managed objects. The Edit menu can alsocontain menu items that allow the user to locatesymbols, objects, or locations within the application.Examples of menu items to be presented under thismenu include New, Cut , Copy, and Paste .

View Use for menu items that affect the way the currentdata is presented. The View menu does not contain anyoption that alters the data itself. Examples of Viewmenu items are Toolbar, Pan and Zoom, andPresentation Formats .

Options Use for menu items that provide access to globalsettings which control the functionality associated withan application and the way it behaves. Use this menufor items relating to the configuration and customizingof an application.

Help Use for menu items that allow for access to online helpinformation, application documentation, versioninformation, and tutorials.

Tools Use for accessing generic services, utilities, andperipheral functionality that is less directly tied to themanaged objects presented in the current window.Items in the Tools menu should include only thosethat act on the objects being manipulated by theapplication, rather than on the managementapplication itself.

Window Use this menu item to provide quick access toimportant windows that users need to accessfrequently in the process of accomplishing their tasks.Do not place routinely-managed object locations in thismenu if they can be accessed by other mechanismswithin the current window, (for example, the scope

120 Chapter 5


pane). Important views should be placed under theView menu. When scope pane windows are used, thereis no need for this menu and it is recommended that itnot be used.

Recommended If menu item only allows the user to add specific managed objects, placethe menu item under the Edit menu and label this item in a way thatwill allow users to know the types of objects they can add.

For example, in a window in which the user can only add users, the labelfor the menu item should be New User , not New Object .

Required If an application allows users to change the presentation format of a view(for example, from graphic to tabular or to chart), menu items for eachavailable presentation format should be presented under the Viewmenu.

Recommended If a user can configure various aspects of the presentation format,provide this configuration in a properties box that is accessed from theView->Options menu.

Required All applications in HP OpenView which provide a menu bar must includea Help menu as the right-most item in the menu bar.

Required The Help menu must contain the following menu items: Overview,Tasks and About .

Recommended The Help menu should contain Online Manual and Glossary menuitems.

Optional If it will be beneficial to users’ tasks, the Help menu should provideaccess to reference documents using the menu item, Reference Pages .

Menus for Managed-Object FunctionalityThese menus provide the primary functionality for an application. Theyenable users to access actions which perform such management tasks asbacking up a system, obtaining data on a router, changing a system’shostname and IP address, or monitoring a service’s status.

OSI has defined a set of categories for classifying network and systemmanagement functionality: Performance, Configuration, Fault,Accounting, and Security.

Chapter 5 121


HP OpenView recommends that managed-object functionality beprovided by means of menus named for the OSI categories or by means ofan Action menu. Which of these two alternatives is most appropriate foryour applications functionality is dependent on the functionality beingprovided, types of objects that are being managed, the homogeneity ofthe objects that are presented at any given level within the managementhierarchy, and the variability in the types of functionality being madeavailable to users.

Recommended Use OSI category menus if any of the following are true:

• The application’s functionality is being integrated into an applicationarea that uses the OSI category menus.

• The application presents a hierarchy of managed objects in whicheach level in the hierarchy will typically contain a wide variety ofobject types. Applications that allow other applications to integratewith them via shared views typically have these types of hierarchies.

Recommended Use an Action menu if any of the following are true:

• The application is being integrated into an application area that usesthe Action menu.

• The application presents a hierarchy of managed objects in whicheach level in the hierarchy will typically contain homogenous types ofobjects, while different levels in the hierarchy will contain differenttypes of objects. Systems management applications are frequentlylike this in that they contain categories of objects at higher levels inthe hierarchy, while lower levels contain a relatively homogenous setof objects (for example, users, disks).

• The application is designed to provide a task or informationpresentation manager.

OSI category menus provide a categorization of menu items based on thetype of management capabilities that is being provided. Since there arefive different categories, this allows the application to spread out theirmenu items by placing them under categories that are related to a user’stasks.

122 Chapter 5


Performance Use for menu items which allow users to viewinformation associated with the performance of thenetwork or managed objects within the network. Alsouse for menu items directed at improving theperformance of the managed objects.

ConfigurationUse for menu items which allow users to view ormodify configuration settings associated with managedobjects.

Fault Use for menu items which perform troubleshooting anddiagnostics, and which fix network and systemproblems that are not associated with the configurationof managed objects.

Accounting Use for menu items which allow for the setting up ofaccounting, monitoring, and billing services associatedwith the usage of the network or managed objects.

Security Use for menu items which allow for the setting up ofsecurity services, the monitoring of security breachesand security configuration, and for any ongoingsecurity maintenance.

The Action menu provides a single location for all functionality whichact on the managed objects in the current window. This menu’s contentsmay vary as a function of the level in the managed object hierarchy andthe currently-selected item. But, because variation in the content of themenus is limited to specific menus (that is Action and Tools ), usersquickly learn about the variable nature of these menus.

Action Use for menu items which allow users to act on themanaged objects that are selected within the currentview or view hierarchy.

Required Action menu items which require the multiple selection of differenttypes of objects should be continuously available in the Action menu.Conversely, these menu items should be grayed if the current selectionsare inappropriate for making them available.

Recommended If there is both an Action and an Edit menu, the Action menu shouldnot include items associated with editing, adding, deleting, copying. Putthese items under the Edit menu instead.

Chapter 5 123


Some applications only have a small number of different types of objectsto present within their window or navigation hierarchy. Theseapplications can use either an Action menu or an object-based menu inthe menu bar.

<objectname> If an application window presents only one or twospecific types of objects, and they have a limitednumber of menu items, use object-based menu items inplace of the Edit and Action menus.

Examples of object-based menu items can be Printersand Queues (see Figure 5-4).

Recommended If an application is using object-based menus, it should not have an Editmenu. All menu items for manipulating the object (including adding anddeleting) should be under the object-based menu.

Recommended If an application is using object-based menus, it should not have both theobject-based menus and an Action menu in the menu bar at the sametime.

Sequence of Menu BarsTo provide consistency and ease of use, the sequence of menu bar itemsshould not vary across applications.

Recommended If a menu bar uses OSI category menus for presenting applicationfunctionality, the sequence of items in the menu bar should be the sameas shown in Figure 5-2:

Figure 5-2 Sequence for Items in Menu Bars Using OSI Menus

Recommended If a menu bar uses an Action menu to replace the OSI category menus,the sequence items in the menu bar should be the same as shown inFigure 5-3:

Figure 5-3 Sequence for Items in Menu Bars Using an Action Menu

124 Chapter 5


Recommended If a menu bar uses one or more object menus to replace the Edit menuand OSI category menus, all object menus except the container should bepresented before the View menu. In Figure 5-4, the object menusappearing before the View menu are Printers and Queues .

Figure 5-4 A Menu Bar Using Object-Based Menus

Pop-Up MenusMenu items in pop-up menus are presented when a user clicks the menubutton on the pointing device. These menus are sometimes referred to ascontext menus.

Required Pop-up menus are required for HP OpenView applications that presentsymbols which represent objects.

Recommended Menu items in pop-up menus associated with objects should be restrictedto object-specific or symbol-specific functionality.

Recommended General functionality should be presented in a pop-up menu associatedwith the background of the results pane of the window.

Recommended Whenever possible, items in pop-up menus should also be placed on thepull-down menu for the view.

The functionality presented in pop-up menus is hidden from the user.These menus are only visible when the user takes a specific action toaccess them. A user may not know how to access pop-up menus or notremember that they exist. If functionality is only available in a pop-upmenu, some users may never access it.

Optional If a menu item acts on the symbol only and does not affect the objectassociated with the symbol, it may appear on the pop-up menu only.

Recommended For guidelines on the pop-up menu for symbol alerts, see “Symbol Alerts”in Chapter 8. Pop-up menus should provide access to the properties of anobject by means of a Properties menu item; this item should be the lastone in the pop-up menu.

Chapter 5 125


Recommended Pop-up menus should not contain grayed menu items. If a menu item istemporarily unavailable, it should be removed from the pop-up menu.

NOTE This is in contrast to pull-down menus where items should be grayed ifthey are temporarily unavailable. Pop-up menu items are intended as aquick-access mechanism for experienced users. The graying oftemporarily unavailable menu items is primarily a learning aid.Experienced users do not require this learning aid, and it detracts fromthe performance benefits of keeping the pop-up menus short.

Context and Menu ItemsHP OpenView is a family of products that are frequently integrated withone another. In this broad environment, it is important that the menuitems match the types of objects and functionality that users wouldexpect within the current view. Users would overwhelmed if the menuitems for all integrated applications were simply appended together in asingle set of pull-down menus.

To aid users in their tasks, contextual information should be used forfiltering the menu items that will be presented. For pull down menus,this contextual information should be derived from the hierarchy ofobjects that are presented in the scope pane and from the view that iscurrently visible in the results pane. Pop-up menus should use this samecontextual information as a starting point and should add contextualinformation on the object or symbol that is under the pointer.

Recommended Items in the menu bar must be consistently maintained across all levelsin an object hierarchy. New menu items should not appear as a result ofnavigating to a lower level in the hierarchy, nor should existing menuitems be removed.

Required With the exception of the Tools and Action menus, menu contentsmust be consistently maintained across all levels in a hierarchy. If amenu item is temporarily unavailable because of the set of itemscurrently displayed in the results pane or because of the currentselection, this menu item should be grayed rather than being removedfrom the menu.

126 Chapter 5


Research shows that users become confused when menu items appearand disappear from the menus. Having a menu item visible, but grayed,lets users know where they need to go to access this functionality; it alsoprovides a visual cue to indicate that users must change the state of theapplication in order to access the menu item.

NOTE Restricting the changing menu items to the Action and Tools menuwill minimize learning difficulties for users. Experience across HPOpenView applications and applications integrated into Microsoft’sMMC will train users to expect menu items in these menus to bevariable.

Recommended If menu items in the Action menu require multiple selections of differenttypes of objects (for example, a router, and a PC), these menu itemsshould be continuously presented in the Action menu and be grayedonly when they are not applicable.

Required Pop-up menu items must be consistently maintained across all instancesof an object within a given view. Different pop-up menu items can bepresented in different contexts and views.

Optional Menu bar items, as well as the contents of menus, may be changed whena user changes to a different context via the context control in thetoolbar.

Recommended Menu items that are specific to a special-purpose window should only beavailable in the context of that specific window.

An example of a menu item for a special-purpose window is the AddSelected Symbols menu item in the Quick Navigator of NNM.

Application Registration FilesApplications that integrate with HP OpenView Network Node Managerdefine their menu items via the application registration files. Theseregistration files provide menu placement rules that will help determinethe views where menu items are placed. Menu placement rules areboolean expressions that will result in a value of TRUE when evaluatedwith the view context identifiers for the views in which menu items willappear.

NOTE In NNM, a submap is a type of view.

Chapter 5 127


The menu registration files have context identifiers that determinewhere menu items should be presented. The context identifiers allowappropriate functionality to be available for a user’s tasks, withouthaving the menu clutter that would exist if all menu items from allapplications were continuously available.

In addition to the guidelines on context and menu items presented above,follow the guidelines below when specifying the menu structure forpull-down menu items and pop-up menu items in applicationregistration files.

Recommended Specify placement rules for Help menu items which match theplacement rules associated with the functionality that the help isdescribing. This creates more context-specific help and to have itpresented in the appropriate submaps.

Optional Recheck the view context for the hierarchy of views where menu itemswill be placed. If the views do not have sufficient context identifiers tohandle the specificity of the menu items, add context identifiers.

Required Do not specify a menu placement rule of AllContexts unless a menu itemis applicable to all managed object hierarchies and all levels within thehierarchies. Examples of generic menu items that may be applicable forAll Contexts include print functions, generic graphing functions, andfunctions that allow actions on the map.

Menu StructureChanges to the menu structure of an application across releases can bedisruptive to the performance of the operators of the application in thatit will necessitate retraining. Therefore, it is best to define anapplication’s menu structure to handle its full functionality even thoughnot all of the functionality is provided in a given release.

Recommended Minimize changes to the menu structure across releases by positioningmenu items based on the anticipated functionality of the application.

In initial releases with less functionality, display only the menu itemsthat are available in that release. Be sure to position these items underthe same menus in which they will be located when the full functionalityis provided.

128 Chapter 5


For example, the initial release of an application may include the itemsnoted as Release 1 below, while the items noted as Release 2 are plannedfor, but not included in the initial release:

Therefore, the Release 1 menu would look like the following:

Systems: Add Delete

Number of ItemsThe number of menu items within a menu panel can either enhanceuser-task performance or it can interfere with performance. Using amenu is a search task where the user is searching to find the item thatwill provide the functionality that they need to access. Searchperformance is aided by minimizing menu depth and by providing visualand cognitive cues to aid the user.

Recommended Menus at a given level should contain between two and fifteen menuitems (eight is optimal).

Required Menus must not contain just one item.

Recommended If a menu will be created with only one or two menu items in it, considermoving the menu items to a higher level in the menu structure (but notinto the menu bar).

If possible in an application, use an approach similar to that provided inthe Network Node Manager menu bar where menu cascades with asingle menu item are pulled up to the menu level above. For example:

Configuration: Backup ->Schedule

becomes

Configuration: Backup: Schedule

Defined Menu Structure Release #

Systems: Change Password Add Delete Set Network Access

2112

Chapter 5 129


Menu Depth

Recommended Research indicates that the complexity of tasks increases sharply as soonas the depth of a menu structure exceeds three levels. Therefore youshould avoid adding menu items to menu bar beyond three levels:

• Level one: items in the menu bar (for example, Configuration )

• Level two: items in the pull-down menus under the menu bar (forexample, Backup )

• Level three: items that cascade from the pull-down menus (forexample, Schedule )

Thus,

Configuration: Backup ->ScheduleUtilities

is the recommended full extent of pull-down menus.

NOTE If necessary to avoid menu clutter, pull-down menus can have a 4th levelof depth, but they should never have 5 levels.

Recommended Pop-up menu depth should be restricted to two levels.

• Level one: items in the pop-up menu when it first appears (forexample, Delete ).

• Level two: items that cascade from pop-up menu (for example,Symbol).

Thus,

Delete ->SymbolObject

is the recommended full extent of pop-up menus.

Pop-up menus are intended for quick access. Having multiple cascadesoff of these kinds of menus detracts from their ability to provide quickaccess.

130 Chapter 5


Menu Labels

Recommended Choose a label for each menu item that clearly indicates the type offunctionality the menu item leads to and the extent of the item’s actions.Where ambiguity could arise, use a label to indicate if the function actson all objects or a subset of objects, a single symbol, or the actualresource being managed. For example:

Delete -> From This Submap From Multiple Submaps

NOTE Users need to be able to distinguish between operations that will affectthe actual resource being managed (such as files on a disk, data in adatabase, or network devices) and operations that will affect only thepresentation of information in the management application. In somecases, this distinction can be made explicit in the menu item name; inother cases this may be difficult to do. Be aware of the potential for userconfusion.

Recommended If a menu item does not provide clarification of the scope of its action, thescope should be set to just the current object/symbol in the currentcontext. It should not affect all instances of the object in all contexts.

Cues for Types of Menu Items

Required Provide cues on each menu label about the type of menu item. The cuespresented in Table 5-1 should be standard across all menu items in theHP OpenView environment.

Table 5-1 Required Visual Cues for Menu Items

Type of MenuItem Cue Explanation

Unavailable graylabel

Menu items that are temporarily unavailable should havetheir menu labels grayed.

Dialog box ... An ellipsis following the label indicates that the itemleads to a dialog box that will require further user inputbefore the requested action can be carried out.

Chapter 5 131


a. Command menu items result in the direct execution of an action, such as Print .b. Application menu items result in the direct presentation of an application window,

such as SNMP Configuration .

Menu SeparatorsMenu separators are lines drawn across the menu that act to separatemenu items from one another. When overused, menu separators can addvisual noise to the menus and can have a negative affect on userperformance.

Recommended Minimize the use of menu separators. Menu separators should only beused when menu items are highly different from one another. If you havea number of individual and very different menu items, do not presentthem with separators between each item; instead, treat them as a groupof different items with a single separator between them and other menuitems.

Menu MnemonicsMenu mnemonics are designators that allow a user to move the selectioncursor to a menu item through a keyboard mechanism. A mnemonic is asingle character which is contained in the label for the menu item andwhich supports ease of learning and use.

When the location cursor is within a menu or a menu bar, pressing themnemonic key for a menu item within the menu moves the locationcursor to that item and activates it.

The following are guidelines for the use of mnemonics in menus.

Required Mnemonics should be supplied for every pull-down and pop-up menuitem.

- Command a

- Applicationbnone A label followed by no symbol or by an accelerator is used

for access to a command or application.

Cascading -> An arrow following the menu item indicates that it leadsto a new menu.

Type of MenuItem Cue Explanation

132 Chapter 5


Required Mnemonics for menu items that are added into an existing menustructure should be chosen so they do not conflict with the mnemonics forany existing menu items.

Recommended Mnemonic characters should be chosen for ease-of-location within thetext of a label. Whenever possible, use the first character of the label. Ifthat is not possible, try to use the last character of the label or, if there ismore than one word, the first character of the second word.

Required All mnemonics at a given level in the pull-down menu must be unique.

Required When specifying mnemonics, make them case insensitive.

See Appendix B, “Mnemonics and Accelerators,” for a listing of HPOpenView Mnemonics.

Menu AcceleratorsIf an application uses keyboard accelerators, follow the guidelines for theplatform on which the application will be delivered.

Recommended Limit keyboard accelerators to frequently used functions. Pull-downmenu items which are infrequently used or which lead to destructiveactions should not have accelerators.

Recommended If an application provides accelerators, each accelerator’s keycombination should be displayed to the right of the label of the menuitem.

Recommended If an application is being integrated into another HP OpenViewapplication, do not redefine any of the standard accelerators provided bythe platform application or the operating system on which an applicationwill be delivered.

Recommended Do not redefine accelerators that are typically found in applications thatwill coexist with the application being developed.

NOTE Should two or more applications use the same accelerators whenintegrating into NNM, the menu for the application that is firstencountered by NNM will use the defined accelerators. Theseaccelerators will be invalid in the other applications that use them.

Chapter 5 133


Recommended Choose accelerators that are meaningful across applications. Forexample, CTRL - v is the standard accelerator for the menu item Paste .

See Appendix B, “Mnemonics and Accelerators,” for information on thestandard mnemonics used in HP OpenView.

Help on Menu Items

Recommended Users should be able to access help on all of an application’s menu items.

Recommended Provide access to context-sensitive help via F1 when the pointer is over amenu item that the user wants to have explained.

Recommended In the help text for menu items, indicate what functionality is suppliedby the menu item, the types of objects on which the menu item acts, theconditions under which the item is unavailable, and any other relevantinformation.

134 Chapter 5

Window ComponentsToolbar Guidelines

Toolbar GuidelinesThe toolbar is a set of graphic controls. It provides quick access tofunctionality that is already available to the user by other methods. Itmay give the user access to frequently used menu items and tools, mayprovide navigation shortcuts, or may enable the user to change thepresentation format of data. Toolbar access can simplify the number ofsteps needed to perform common operations.

Toolbars can be statically attached to the window in a single location, orthey can be designed like dockable tool palettes (where they can bedetached from the window border, float within the window, and bedismissed when they are no longer needed).

When to use ToolbarsToolbars are optional for HP OpenView applications. However, decisionsabout whether to add tools to the standard toolbar or to provide aseparate dockable toolbar should be based on the following guidelines.

Recommended Applications should add tools to the standard toolbar if these tools willimprove usability by enhancing user access to common operations. Forexample, an application which provides a new presentation format for aview of managed objects should add this presentation format to thestandard toolbar.

Recommended Provide dockable toolbars for times when a user will benefit by havingquick access to a set of capabilities to use over a period of time and thendismiss when he goes on to other activities. Applications which provideseveral large menus can improve their usability by providing quickaccess to frequently used menu items via a dockable toolbar.

Content of ToolbarsToolbars are intended only for frequently accessed functionality, not forall of the functionality in an application. Dockable toolbars can be moreextensive since a user can choose different sets of tools and dismiss themwhen he has finished using them.

Chapter 5 135


Recommended Keep the number of toolbar buttons to a minimum by placing onlyfrequently used functions in the toolbar. Make toolbar buttonsunavailable or remove them when they are no longer applicable to agiven view or selection.

Recommended Make sure the functionality in the toolbar is also available through thepull-down menus. When the standard toolbar is turned off or thedockable toolbars are dismissed, the user will need another mechanismfor accessing the functionality provided in the toolbar.

Recommended If an application allows multiple different presentation formats forobjects presented in the scope pane, provide access to those presentationformats through buttons in the toolbar.

Recommended If a history is kept of the views that are presented in the results pane of awindow, provide users with a [Back] button in the standard toolbar sothey can quickly access the last ten views that they visited.

Recommended If an application uses dockable toolbars, provide tool buttons for all of themajor capabilities that users will want to access when doing their tasks.

User Control and Support for Toolbar Use

Recommended The default location for the toolbar should be directly below the menubar. It is desirable to allow users to move toolbars and to dock them atany border within the window to which they are attached.

When toolbars contain only graphic representations of objects, it cansometimes be difficult for users to associate the graphics with thefunctionality that they represent. Also, when items are presented onlygraphically, they cannot be made accessible to the visually impaired viaaccessibility software.

Recommended To aid users in recognizing and accessing the tools in the toolbars, useone of the following mechanisms:

• Provide pop-up messages or tool tips that pop up when the mousepointer rests on the tool button.

• In the window’s status bar present context sensitive active help forthe toolbar button currently under the pointer.

• Include labels under every graphic to indicate what they represent.

136 Chapter 5


Caution should be used in providing labels under icons. If the label ispart of the graphic, the graphic will need to be redrawn in order to belocalized.

Recommended Enable users to hide the toolbar. While the toolbar is beneficial to someusers, it takes up display space that other users may want to use foranother purpose.

Required If multiple dockable toolbars are provided, access to the availabletoolbars should be provided through the View->Toolbars... menu as wellas through a toolbar button in the standard toolbar.

Recommended Dockable toolbars should remain open while a user is using them. Theuser should be able to dismiss these toolbars when they are no longerbeing used.

Optional If toolbar buttons act on selected objects, it may benefit the users to beable to drag and drop managed objects from the content or scope paneand to drop them on the toolbar button to activate the commandassociated with the toolbar button on the dragged objects.

Tool Buttons in the Toolbar

Required If there is an HP OpenView- or operating system-provided graphic forthe functionality that a toolbar button is providing, use the existinggraphic in the toolbar button.

Recommended If there is no appropriate HP OpenView- or operating system-providedgraphic, develop a graphic that clearly represents the action beingprovided by the toolbar button.

It is recommended to run user tests on any graphics to be used in thetoolbars. These tests should evaluate both a user’s ability to associate thegraphic with the functionality it represents as well as his ability torecognize the icon once the association has been learned.

Recommended Make buttons and pixmaps in the toolbar the same width and height:

• 24x24 pixels for UNIX, JAVA, and HTML applications.

• 16x16 or 32x32 pixels for applications native to the Windows NToperating system.

Chapter 5 137


Recommended The graphics used in toolbar buttons should be chosen so that they arenot specific to any given culture.

Recommended The graphics used in toolbar buttons should be provided in files that canbe replaced when localizing an application for a specific country.

Required If a toolbar button will cascade to a second level of items, provide agraphic with a downward pointing arrow that will display the secondlevel of toolbar items once the tool button is clicked. See Figure 5-5.

Required For toolbar buttons that are presented through NNM applicationregistration files, provide a grayed-out version of graphics for any buttonwhich will be grayed whenever its functionality becomes unavailable.

Toolbar Structure and Customization

Recommended If dockable toolbars are provided, break the toolbar buttons into sets ofsimilar types of functionality that users will want to use together. Thereshould be a separate dockable toolbar for each set of tools.

Recommended If an application permits a user to choose from multiple variations of thesame type functionality (for example, presentation formats for data orvariations of sorting of objects in the data), provide these functionalityvariations in a cascading toolbar menu.

Figure 5-5 A Cascading Toolbar Button

Recommended Limit toolbars to two levels of depth: a main level of tools, with thepossibility of lower-level tools in a cascading tool button. See Figure 5-5for an example.

Recommended Allow users to customize the contents of the toolbars.

138 Chapter 5


Context Control Within the ToolbarRather than opening new windows whenever the user wants to access adifferent type of functionality or to obtain information on a different setof objects, HP OpenView suggest the use of a context control that isprovided in the toolbar of the application window.

Recommended If an application allows users to switch between different managementcontexts (for example, different hierarchies of managed objects, differenttypes of management capabilities such as accounting versus systemsmanagement, or different sets of managed objects), provide the ability toswitch contexts through the context control in the toolbar. See “ContextControls” in this chapter.

Recommended The context list should control information presented in the scope pane,results pane, and menu items in the menu bar.

Context and Toolbar Items

Recommended Buttons in the toolbar must be consistently maintained regardless ofselections within a view. New toolbar buttons should not appear as aresult of selecting different objects in a view, nor should existing toolbarbuttons be removed.

Optional Toolbar buttons may vary from view to view within a context ornavigation hierarchy.

Recommended Toolbar items that are specific to a given window should only beavailable in the context of that specific window.

Follow these guidelines when specifying toolbar placement rules fortoolbar items.

Application Registration FilesApplications that integrate with HP OpenView Network Node Managerdefine their toolbar buttons via the application registration files. Theseregistration files provide placement rules that will help determine theviews where toolbar buttons are placed. Placement rules are Booleanexpressions that will result in a value of TRUE when evaluated with theview context identifiers for the views in which toolbar button will appear.

Chapter 5 139


Required When specifying toolbar items in the registration files, provideplacement rules that will help determine the views where toolbar itemswill appear.

Required Do not specify a placement rule of AllContexts for a toolbar buttonsunless that button is applicable to all managed object hierarchies and alllevels within the hierarchies, and users will want to have immediateaccess to this functionality at all times. Close Window is an example ofone of the few operations that satisfy this criteria.

140 Chapter 5

Window ComponentsDescription Bar Guidelines

Description Bar GuidelinesThe description bar is message area that goes across the top of the scopeand results panes. It provides information to a user on what is currentlybeing presented in the scope and results panes. In Figure 5-6,Management Hierarchy appears in the portion of the description barabove the scope pane, while trees.new.tc.com appears above theresults pane.

Figure 5-6 Description Bar over the Scope and Results Panes in a Window

Recommended Description bars are specifically recommended for applications windowsthat:

• Have a scope pane with context tabs. In this case, the description barhelps users see the current setting of the context tab presented in thedescription bar.

• Have a scope pane with no context list. In this case, the descriptionbar can serve as a “label” for the scope pane.

An application whose scope pane does provide a context list can usethe list (instead of a description bar) as the label for the pane. Thecontext list helps to identify the type of items to be found in the scopepane. For applications with a context list, the description bar providesredundant information.

• Do not have a scope pane, but which do allow users to navigate withinthe results pane.

If there is no scope pane, the description bar provides a label for theinformation presented in the results pane.

Recommended If a description bar is provided, controls should be provided to allowusers to turn the description bar on or off.

Recommended The following guidelines should be used to determine the text to put inthe description bar above the scope pane:

• If the scope pane contains context tabs, the description bar shouldindicate which context tab is active (such as Object Hierarchy or TaskHierarchy).

Chapter 5 141

Window ComponentsDescription Bar Guidelines

• If the scope pane does not have context tabs or a context list, thedescription bar should indicate the contents of the scope pane. Thiswould be equivalent to the name that would be in the context list ifmultiple contexts were available in the window.

Recommended The portion of the description bar above the results pane should displaythe name of the open object whose contents are presented in the resultspane.

142 Chapter 5

Window ComponentsContext Controls

Context ControlsRather than opening new windows whenever the user wants to access adifferent set of objects or a different type of functionality, HP OpenViewsuggests the use of context controls. These controls allow users to changebetween different management contexts within the application window.

Two different types of context controls can be found in HP OpenViewapplications: a context list and context tabs.

The context list is presented as a combo box on the left side of the toolbarin the window. This list presents the contexts that are available for theuser to choose.

Figure 5-7 Context List in a Close and Open State

Context tabs are tabs presented at the bottom of the scope pane. Inmultiple-purpose presentation manager windows, the tabs can allowusers to change between objects, tools, tasks, management areas,favorites, and help.

Figure 5-8 Context Tabs

Required If an application allows users to switch between different contexts (forexample, different hierarchies of managed objects, different types ofmanagement capabilities such as accounting versus systemsmanagement, or different sets of managed objects), the ability to switchcontexts is provided through the context list in the toolbar.

Chapter 5 143

Window ComponentsContext Controls

NOTE Typically, context lists will be found in scope pane windows. Single panewindows are less likely to have context lists.

Recommended The context list determines the information presented in the scope pane,results pane, any functionality provided through the menus and toolbarbuttons.

Recommended All contexts in the context list should be meaningfully associated withone another from the user’s point of view.

Required The name for a context in the context list should clearly indicate the typeof hierarchy or filter categories that will be presented in the scope pane.

Recommended For task presentation managers, it is recommended that the names ofcontexts in the context list be drawn from the predefined task categoriesfor the Task tab of the HP OpenView Launcher. See Appendix A, “HPOpenView Launcher Categories,” for a listing and definition of thepredefined task categories.

Recommended If different management hierarchies are presented via the context list, auser-specified hierarchy that is based on user groupings of managedobjects should be provided.

Recommended Context tabs should only used in multiple-purpose presentationmanagers. See “Multiple Purpose Presentation Managers” in Chapter 3for more information.

144 Chapter 5

Window ComponentsScope Pane

Scope PaneThe scope pane is a vertical pane on the left side of the window’s resultspane. Items presented in the scope pane provide users with the means ofnavigating in the information space and controlling the information thatis presented in the results pane. Figure 5-9 and Figure 5-12 showexamples of scope panes.

General Guidelines

Recommended A scope pane should be provided in the application window if user taskperformance will benefit from any of the following:

• Having a hierarchical listing of all objects in the managementenvironment.

• Having a quick-access mechanism for navigating to and displayingdetailed information on specific locations within the managementhierarchy.

• Having quick access to common filters, which specify the subset ofinformation to be displayed in the results pane.

• Having a listing of tools in the scope pane, which allows quick accessof information or functionality.

Required The scope pane must be resizable.

The scope pane takes up space that would otherwise be used by theresults pane. A resizeable scope pane allows redistribution of windowspace to better suit user task needs once the user has navigated to thedesired location.

Required If a user changes context with either the context list or context tabs, thecontents of the scope pane should change to match the new contextsetting.

Recommended While in the scope pane, pressing:

• The Tab key should move keyboard focus to the results pane in thewindow.

Chapter 5 145


• The Shift Tab keys should move keyboard focus to the context tabs (or, ifthere are no context tabs, to the context list).

The Tab key should allow a user to navigate between the variouspanes and controls in the window. The sequence of movement basedon the Tab key should be as follows:

1. Scope pane tabs

2. Scope pane

3. Results pane

4. Navigation tabs

5. Control pane

6. Context list

7. Scope pane tabs

If the window is split, Tab should move through the top half of the split,followed by the bottom half, before moving to the context list.

For other guidelines on keyboard navigation in the scope pane, see“Keyboard Navigation in Tree List Controls” in Chapter 9.

Scope Panes With Hierarchies of ItemsThe scope pane in the window typically provides a hierarchy of objects,tasks, or information. The appearance of the hierarchy will be dependenton the depth of the hierarchy.

146 Chapter 5


Figure 5-9 Two Examples of Scope Panes Showing Hierarchies

See also the guidelines in “Interactions between the Scope Pane andResults Pane” later in this chapter.

Recommended If multiple, unrelated sets of items (see the left figure in Figure 5-9) aresimultaneously presented in the same scope pane, all of the followingguidelines should be followed:

• Each set should have a category heading (for example, SystemInformation).

• Items within a set should be indented and listed under the headings(for example, Disks, Printers, and Tape Drives).

• Any selectable category headings should, when selected, cause theresults pane to display icons representing each item in the category.

As an alternative, category headings can be nonselectable.

Recommended If a hierarchy of items (for example, tools, tasks, or objects) is presentedin the scope pane, this hierarchy should be presented as a tree list. (Seethe right figure in Figure 5-9 for an example.)

For guidelines on navigation within a tree list and the behavior of thecontrols within a tree list see “Tree List Controls” in Chapter 9.

Chapter 5 147


Recommended The scope pane should present all container items in the hierarchy,including a top-level item that is a container for all lower-level items.

Having a top-level item in the scope pane provides organization for theuser and allows him to access information on that item’s properties.

For example, in a hierarchy that shows the topology for the IP Internet,the first item in the hierarchy should be IP Internet.

Optional Both container and leaf-level items may be presented in the scope paneunless the hierarchy will be large enough to cause performanceproblems:

• Examples of container items are task categories (such asConfiguration Tasks), information categories (such as SystemInformation), and compound objects (such as a network segment or acomputer system).

• Examples of leaf-level items are individual tasks (such as ModifySNMP Parameters), individual tools (such as CPU Utilization), andlower-level objects (such as an IP Network Card).

Required If leaf-level items (items that have no child items) are presented in thescope pane for any portion of the hierarchy within a given context, theymust be presented for all portions of the hierarchy within that context.

Required When the window is first opened the first container in the scope paneshould be expanded to show the user the items in that container.

It is confusing for users go into a window where the scope pane containsa single entry that has not been expanded. Expanding the first containerin the hierarchy will provide greater visibility of available functionality.It also provides sufficient visual cues to indicate that additional itemscan be made available by expanding and contracting containers in thescope pane.

Interactions between the Scope Pane and ResultsPaneFor further guidance, see “Selection Guidelines” in Chapter 7.

Required When a scope pane window is first opened, the item in the scope panethat corresponds to the information in the results pane should beindicated as “open”.

148 Chapter 5


An open item is visually indicated by a location cursor or a locationcursor plus a selection highlight surrounding it. See also “Results Pane”below.

Required When a container item is selected in the scope pane, the results paneshould display information that is relevant to the selected container.Typically, the information presented is a view of the child items directlyunder the container item.

For example, in a task presentation manager, the selection of thecontainer Service Tasks results in the presentation of a table with tablerows corresponding to the task folders and individual tasks containedwithin Service Tasks .

In an object presentation manager, the selection of a container objectsuch as a network segment (for example, 10.5.106) results in thepresentation of the nodes within that segment (for example, thecomputers, printers, bridges, and other network nodes).

Recommended Use the following guidelines in determining what to present in theresults pane when a leaf-level item is selected. If the leaf-level item is:

• An object, its properties are presented in the results pane. Theproperties can be presented in a form view that shows a propertiesbox, or they can be presented in a tabular view.

• A task, a wizard, or tabbed dialog box for the task should bepresented in the results pane.

• A report or label for a set of data, the associated information shouldbe presented in the results pane.

Required Clicking on an expansion control in the scope pane must not change theplacement of the selection cursor nor the view presented in the resultspane.

Figure 5-10 Expansion Controls

Required Users should be able to scroll the contents of the scope pane withoutaffecting the information displayed in the results pane.

Chapter 5 149


This allows users to easily move within the display space and to use dragand drop between different views of objects.

Recommended Double-clicking on a item in the scope pane should cause informationrelated to that item to be presented in the results pane; this actionshould also cause the item to be expanded if it had a [+] next to it orcollapsed if it had a [-] next to it.

Required Single-clicking in the results pane on an object, task, information, or toolicon must both cause the item to be selected as well as remove theselection cursor appearance from the scope pane. A location cursor (forexample, black box or gray highlight) appears around the open item inthe scope pane.

Required Double-clicking in the results pane on an icon for a container objectshould cause the child view associated with that object to be presented.The double-click action also causes a synchronized change in the scopepane so that the object that was double-clicked on in the results pane isshown in the scope pane as the open object, but not as a selected object.

To present the opened object in the scope pane may require scrolling ofthe tree list so the open item is visible. The open item in the scope paneshould not be selected; instead, the location cursor should be on the itemto indicate that it is open. User testing has shown that users do notexpect the opening of an object to affect their selections.

Required A CTRL-click on an item in the scope pane should cause the item to beselected without affecting the selection state of other items. TheCTRL-click should not change the view presented in the results pane. See“Selection Guidelines” in Chapter 7 for more information on multipleselection.

Required Double-clicking on the icon for a leaf-level object (that is one that doesnot have a child view) in the results pane causes the default actionassociated with that object to be executed or an error message to be givento the user.

Typically the default action associated with an object is the presentationof the properties of the object.

150 Chapter 5


Menus in a Scope PaneThere are typically pop-up menus associated with items in the scopepane. See “Pop-Up Menus” in this chapter for guidelines related to thesepop-up menu items.

Visual Cues in a Scope PaneScope panes with hierarchical presentations of objects and tasks containa lot of visual cues that help guide the user in their interactions with theapplication. Examples of the visual cues discussed in this section can beseen in Figure 5-11.

Figure 5-11 Visual Cues in the Scope Pane

Recommended If the items in the scope pane are presented in a tree list, these itemsshould be represented by both a graphic and a label. The type of graphicused should adhere to the following guidelines:

• If the status of the represented object is normal, a 16x16 graphic thatdepicts the object should be used.

For information on the design of graphical images see “Symbol DesignGuidelines” in Chapter 6.

Chapter 5 151


• If the status of the represented object is abnormal, the object shouldbe represented by a symbol class shape that is colored to depict theabnormal status and the image for the object. The symbol class shapeshould fit within a 20x20 square.

Abnormal status states in HP OpenView are critical, major, minor,and warning. For more information on presentation of statusinformation see “Use of Status Colors” in Chapter 8.

Required Any currently-selected items in the scope pane should be marked by aselection highlight (see figure on the left in Figure 5-11) or by a selectioncheck box (see figure on the right in Figure 5-11).

• In a applications native to the UNIX or Windows NT operatingsystem, the selection highlight is one defined by the operating system.

• In a JAVA application or applet, the selection indicator should bedefined by the system color variables indicated below:

• The text for the selected item should be set to “activeCaptionText”.

• The highlight surrounding the selected item should be set to:“activeCaption”.

• In an HTML application, the selection indicator should be a block ofcolor (lightblue #ADDE86) surrounding the item’s label.


• A radio button, if all items in the scope pane are mutuallyexclusive.

• A check box, if multiple selection of items is allowed.

Recommended The position of the location cursor in the scope pane should be marked bya location cursor or open indicator:

• In applications native to the UNIX or Windows NT operating system,the location cursor or open indicator should be the one by theoperating system.

• In a JAVA applet or HTML application, the location cursor or openindicator should be a black box that surrounds the name of the itemon which the location cursor is resting.

152 Chapter 5


Recommended The item in the scope pane that is currently open (the item whosecontents are displayed in the results pane) should adhere to all of thefollowing:

• It should be shown in the object_or_task_or_tool field of the title bar.

• It should be shown by a label in a white navigation tab if navigationtabs are provided in the interface.

• It should be indicated by either:

• A selection cursor, unless there has been a selection in the resultspane.

• A location cursor, if there has been a selection in the selectionpane and the user has not navigated in the tree list with thekeyboard or keyboard- equivalent device.

Variations in the appearance of the icons to indicate the open object isalso allowed as a means of showing the open item. However, this type ofvisual cue is not applicable to all types of icons (for example, servers,services, computers, printers); therefore, it cannot be the only cue that isprovided for “open”.

Recommended Items that have a symbol alert associated with them have an "!"(exclamation point) to the left of the icons representing the object.

Chapter 5 153


Scope Panes with Filters

Figure 5-12 A Scope Pane with Filters

Recommended If filters are presented in the scope pane, they should be presented as aflat list or as sets of filters with category headings.

Recommended If the scope pane presents filters, the material presented in the resultspane should be that information which matches the selected filters.

Recommended If a more complex filter mechanism is provided in a separate dialog box,it should adhere to all of the following guidelines:

• The information presented in the results pane should reflect the filtercategories in the dialog box.

• The filter categories in the dialog box should include the filtercategories presented in the scope pane.

• Changes made to the filter categories in the dialog box should bereflected in the associated categories in the scope pane of the window.

• If dialog box has set filters that are not displayed in the scope pane,the status bar of the window should indicate that additional filtershave been set.

154 Chapter 5


Recommended A single-click on the check box for a filter should cause the selection ofthe filter to be turned on or off depending on its previous state. It shouldalso cause the items which match that filter to be displayed in the resultspane.

Control of the information display by selection of categories should takeeffect immediately without the need for the user to use a push button toapply the filters. Compliance with this guideline may depend onapplication performance.

Recommended If the user must take a step to apply filters, there should be a [Display]button associated with the scope pane that is continuously visible.

Chapter 5 155

Window ComponentsResults Pane

Results PaneThe results pane (or client area) is the area that is used for presentingthe primary information about managed objects and other applicationfunctionality. Depending on the primary purpose of the applicationwindow, the results pane will present different types of information.

Figure 5-13 The Results Pane in an Application Window

Required A results pane is required for all HP OpenView application windows.

Recommended In object presentation managers, the results pane should providemeaningful views related to the object shown in the scope pane as open.

Recommended In task presentation managers, the results pane should provide a wizardor tabbed dialog for the task shown in the scope pane as open.

Recommended In information presentation managers, the results pane should providethe information associated with the open item in the scope pane.

156 Chapter 5


Recommended When a user first enters an application’s window, the results pane shouldnot be empty. The results pane should show either:

• Information relevant to the menu item, launcher entry, or selectionfrom which the user accessed the window (see Example 1 below).

• Information that was visible when the user last exited the application(see Example 2 below).

• A default set of information. If the window is a scope pane window,the default information should be associated with the first item in thescope pane.

Example 1: If the user opened the window by double-clicking on analarm in an alarm browser, the window should present informationthat is relevant to the alarm (for example, a view containing theobject that was the source of the alarm).

Example 2: If the user had previously had the window open andshowing the 12.1.5 subnet within the IP network hierarchy, thewindow should open to that subnet.

Keyboard interaction in the results pane will need to vary depending onthe type of presentation format that is presented in the results pane. Seeguidelines for keyboard navigation in see “Presentation Formats for theResults Pane."

Presentation Formats for the Results PaneWhen managing the network and system environment different types oftasks can benefit from different presentation formats. The types ofpresentation formats recommended for HP OpenView applicationsinclude:

• Graphical (that is iconic with various layouts or pictorial).

• Chart (for example, a line chart, bar chart, pie chart).

• Tabular (that is rows and columns of information).

• Form (for example, a wizard or tabbed control with fields for viewingor entering values).

Refer to Figure 5-14, Figure 5-16, and Figure 5-17 for examples of thesekinds of presentation formats.

Chapter 5 157


Recommended When managed objects are initially presented, they should be presentedin the presentation format that will most likely benefit the user’s tasksthe type of object that is selected and the current context.

For example:

• If the context is concerned with the connectivity and status ofmanaged objects, a graphical format can accurately depict how theobjects are connected together in the management environment aswell as provide status by means of status colors.

• If the context is concerned with configuration and changemanagement and a router is selected, a properties format can showsthe current configuration of the router and allow users make changes.

• If the context is concerned with performance and the selected object isa network, a chart format which shows a Pareto of the “Top 10Talkers” contributing to network traffic can provide a summary ofimportant information.

• If the object is a container that has no attributes of its own and userswould benefit from a summary of information on all objects within thecontainer, a tabular format can present objects as rows in the tableand information on the objects as columns (for example, hostname, IPaddress, MAC address, and packets in).

Recommended If it will benefit users, an application should provide differentpresentation formats for the objects presented in a view.

Recommended If different presentation formats are provided, users must be able tochange between different presentation formats using menu items listedunder the View menu (for example, Details, Icons, Large Icon, and SmallIcon) and toolbar buttons that represent the available presentationformats.

Recommended If multiple presentation formats are available, capabilities should beprovided to allow users to set their preference for:

• A default format to be used for views of different types of objects.

• A presentation format for a view which is either a default format orone based on the last format set by the user.

158 Chapter 5


Graphical Presentation FormatsThere are different types of graphical presentation formats. The mostcommon types are iconic and pictorial.

Iconic presentation formats provide views in which objects arerepresented by icons and relationships between the objects arerepresented by lines. Iconic views may show topology (as in a networksubmap) or logical relationships (as in an organization chart). Iconicviews can simply show containment (as in a row/column layout in a NodeSubmap). See an example of an iconic presentation format in Figure5-14.

Figure 5-14 A View Showing an Iconic Presentation Format

Recommended When an iconic presentation format is used, users should be able tonavigate to lower levels in the hierarchy by double-clicking on the icons.

Chapter 5 159


Recommended Users should be able to use the arrow keys to navigate among the objectspresented in an iconic presentation format:

• Pressing the up arrow should move to the nearest icon above thecurrent location.

• Pressing the down arrow should move to the nearest icon below thecurrent location.

• Pressing the left arrow should move to the nearest icon to the left ofthe current location.

• Pressing the right arrow should move to the nearest icon to the rightof the current location.

Recommended For other guidelines on iconic presentation formats, refer to Chapter 6,“Objects and Symbols.”

Pictorial presentation formats provide an image of the object beingmanaged. This format frequently lets users manipulate the managedobject through the direct manipulation of image components. Forexample, dragging a object and dropping it on a port shown in a pictorialformat may reconfigure the port on the device to provide a connection tothe object.

160 Chapter 5


Figure 5-15 Pictorial Presentation Format

Recommended When users can do direct manipulation actions on portions of a picture,the user should be provided with visual cues to indicate what portions ofthe picture can be manipulated.

For example:

• The appearance of the pointer can change when the pointer is over ahotspot in the picture that can be manipulated.

• An area of the picture can become highlighted when the pointer isover a hotspot that can be manipulated.

• Tool tips can be presented when the pointer is over a hotspot that canbe manipulated.

Chapter 5 161


Tabular Presentation FormatA tabular presentation format provides a means for providing detailedinformation on all of the objects within a view. Tables allow the display ofmultiple pieces of information on multiple objects without cluttering thedisplay. Types of information that can be presented in a tabular formatare properties of the objects, important statistics, and multiple pieces ofstatic data.

When providing a tabular presentation format, refer to the guidelines inthis section and those on “Tables and Grids” in Chapter 9.

Figure 5-16 A View Showing a Tabular Presentation Format

Required Tabular presentation formats for views of multiple objects must presentthe objects as rows and the information on these objects as columns inthe table.

This is the typical way in which information on objects is presented andconsistency will aid the user in locating desired information.

162 Chapter 5


Recommended When providing a tabular presentation format for object, adhere to all ofthe following guidelines:

• Provide important information that will benefit a user in his task.

When deciding what information to present, consider the context inwhich the object is being presented and use this as a basis fordetermining what information should be presented. In a networkcontext, properties like IP address, subnet mask, and the number andstate of network cards or ports will typically be important to users. Ina system context, important properties could include the operatingsystem version, CPU usage, amount of RAM, available RAM, disksmounted, and disk space.

• Do not simply repeat the information that is provided in a existingchart or graphical format.

While it is beneficial to repeat some information available in an iconicview (for example, status and label), users do not go to a tabular viewto get a repetition of the information they had in another format.Information like the symbol type and class should not be given in atabular view.

• Present only a subset of the properties associated with an object.

If the table presents all of the properties associated with the objectsin a view, the table will become cluttered and will require too muchhorizontal navigation by the user.

Recommendation If the view associated with a tabular format includes heterogeneoustypes of objects, adhere to all of the following guidelines:

• Try to choose properties for display that are common across thevarious types of objects in the view.

• If the properties displayed are not common to all objects, cells whichare not applicable to a given object should contain a “-”(a dash).

• If some of the objects in the view are of lesser importance to the user,do not include them in the table.

For example, in some network views frequently the connection objectsare not very important as the connections are not actively managed.Status of the connections are derived from the status of the interfaceswithin the connected objects (for example, computers, bridges,routers, and switches). Tabular presentation formats in these types ofnetwork views should not contain the connections.

Chapter 5 163


Recommended The default sorting for a table in the tabular presentation format shouldbe alphabetical by object name or label.

Recommended Allow users to set preferences for the information to be displayed in thetabular view. Potential preferences that should be considered for usermanipulation include:

• The properties to be presented.

• The types of objects to be presented in the table.

• The size of the columns in the table.

• Which columns in the table are used to sort the information.

(Many table controls allow users to sort by clicking on the columnheading. This can aid users in finding information.)

Recommended See “Keyboard Navigation in Tables and Grids” in Chapter 9 forinformation on keyboard navigation within a tabular presentationformat.

Chart Presentation FormatsA chart presentation format provides a means of summarizinginformation for a user. Because the chart is visual, the user can acquireimportant information at a glance. Charts provide a good means fordisplaying the health of managed objects, performance, and for showingproblems. They are not intended for presenting detailed information on alarge number of objects.

164 Chapter 5


Figure 5-17 A View Showing a Chart Presentation Format

Recommended When providing a chart presentation of a large number of managedobjects, do not attempt to present data on all of the objects in the chart.Information presented in charts should only represent important objectsor objects with extreme conditions that users would want to know about.

For example, in a network view users will want to know about theperformance of routers or objects that have the most network traffic. In asystem view, users may want information on the systems that have thelowest amount of RAM or disk space or that have the highest load ontheir processing capacity.

Recommended Allow users to set preferences for the type of information to be displayedin a chart and for how many objects will be presented in the chart at agiven time (for example, “top 5 objects”, “top 10 objects).

Chapter 5 165


Form Presentation FormatA form presentation format, which is displayed in the results pane of theprimary window, overlaps in its functionality with property boxes,property inspectors and wizards. Property boxes, property inspectors,and wizards typically present object properties in a secondary dialog box.See Chapter 9, “Dialog Boxes and Controls.” Form views are applicable toboth object and task presentation managers. Use the followingguidelines to determine when to use a property box, property inspector,or wizard as compared to a form format in the results pane of apresentation manager.

Figure 5-18 A View Showing a Form Presentation Format

Required Form presentation formats are only applicable in windows that have ascope pane.

166 Chapter 5


Recommended If a user has the results pane set to a presentation format other than theform format and he requests the properties of an object via a menu ortoolbar button, these object properties should be presented in aproperties box instead of as a form in the main window area.

Recommended Use a form presentation format in the results pane to present objectattributes if:

• A user has selected an object in the scope pane, and the object’sproperties are the relevant information associated with the selectedobject.

(For example, a leaf-level object has no child view associated with it;the only relevant view is the object’s properties.)

• The user’s primary task involves viewing or editing of objectproperties.

• The user may need to quickly go back and forth between theproperties for different objects.

• The user’s task would benefit from being able to drag objects from thescope pane into the properties in the results pane.

Recommended Use a properties box to present object attributes if:

• A user will be viewing or editing objects properties infrequently.

• The user does not need to quickly go back and forth between theproperties for different objects.

• The tasks that an application is presenting do not allow drag anddrop onto the properties box.

• The number of attributes or amount of information associated withthe object is large; the presentation of this information in a separatewindow would reduce clutter and make it clearer to the user.

Recommended Use a property inspector for presenting object attributes if:

• The objects (for which the properties are to be provided) are notpresented in the scope pane.

• The user’s primary task involves viewing or editing of objectproperties.

• Users may need to quickly go back and forth between the propertiesfor different objects.

Chapter 5 167


Recommended The guidelines for keyboard navigation within a form presentationformat should be identical to those for keyboard navigation within adialog box, see Chapter 9, “Dialog Boxes and Controls.”

168 Chapter 5

Window ComponentsNavigation Tabs

Navigation TabsNavigation tabs are tabs that are presented at the bottom of the resultspane. Navigation tabs allow users the ability to quickly move back to apreviously accessed view in the results pane.

Figure 5-19 Navigation Tabs with Images of Stick Pins on Them

Navigation tabs can have three possible states: “reusable”, “keepaccessible”, and “stay on top”. Each state is indicated on the tab label inthe following manner:

• In the “reusable” state, the tab label should be blank on the right side,see “Reusable Tab” in Figure 5-20 below.

• In the “keep accessible” state, the tab has a picture of a pin lying onits side, see “Keep Accessible Tab” in Figure 5-20 below.

• In the “stay on top” state, the tab has a picture of the pin stuckdirectly into the label, see “Stay on Top Tab” in Figure 5-20.

Chapter 5 169


Figure 5-20 Tab States and Appearance

Required If navigation tabs are provided, the tab that is currently on top or activeshould appear in white, while any nonactive tabs appear in the samecolor as the background for dialog boxes and scroll bars.

Recommended When the user clicks on a navigation tab with the menu button on thepointing device, a pop-up menu containing the following menu itemsshould be presented.

Reuse Tab This menu item causes the stick pin in the tab to beremoved. If the tab is for the top view, the view and thetab will remain until the user navigates to a new view.If the tab is for one of the lower-level views, the tab willdisappear, but there will be no change in the currentview.

Keep Accessible This menu item causes the stick pin in the tab to be inthe pinned state (sideways pin). When the pin is in thisstate, the tab for the view is maintained when the usernavigates to a new view. A new tab is created forpresenting the new view.

Keep Tab on Top This menu item is optional. When available, it causesthe pin on the tab to have a stuck in appearance. Untilthe state of the tab is changed, it always remains ontop. This prevents the results pane from changingwhen the user navigates in the scope pane.

Display in NewWindow This menu item causes the view associated with the

tab to be presented in a new window. If thepresentation manager supports child windows, the tabis removed and a child window containing only theidentified view is presented. If the presentationmanager supports copied windows, a new duplicatewindow is presented with view associated with the tabset as the active view.

170 Chapter 5


Close Tab This menu item causes the tab to be removed; and, ifthe tab is associated with the active view, the view willchange to the view associated with the tab previouslyviewed prior to this tab.

Optional When possible, have any menu items associated with the navigation tabsavailable from the background pop-up menu for the view.

Recommended Some of the menu items associated with the navigation tabs should bepresented as toolbar buttons in the toolbar:

Keep Accessible A toolbar button should be presented for changing thepin state of the active tab between the Keep Accessibleand Reuse Tab states. This button should be a togglebutton.

Display in NewWindow This should be a regular toolbar button that uses the

graphic for display in new window.

Close This should be a regular toolbar button that uses thegraphic for closing a view or a window.

Optional If an application supports the three tab states of keep accessible, reusetab and stay on top, the toolbar button for Keep Accessible shouldtoggle between the three states and change images when necessary forthe “keep accessible” (a pin on its side) and the “stay on top” (a stuck-inpin) states. Specifically, this button should show:

• A pushed-out appearance with the image of a pin on its side when thestate of the tab is “reusable.”

• A pushed-in appearance with an image of a pin on its side when thestate of the tab is “keep accessible.”

• A pushed-in appearance with an image of a stuck-in pin when thestate of the tab is “stay on top.”

Each click on the button should toggle between the three states in thissequence: “reusable”, “keep accessible”, “keep on top”, and then back to“reusable”.

Recommended If a tab is in the “keep on top” state, the selection of an item in the scopepane should result in a nonactive tab (that is a tab that is overlaid by thetab that is stuck) which contains the view associated with the selecteditem.

Chapter 5 171


Recommended If a tab is in the “stay on top” state, the selection of another navigationtab should override this state, and the view associated with thenewly-selected tab would be presented. The state of the tab previouslymarked as “stay on top” would become “keep accessible”.

Users will not want to change the tab state before they are allowed tonavigate to other views marked as “keep accessible”.

Recommended When a user moves the contents of a navigation tab into a child window,the view associated with navigation tab that he most recently visitedshould be presented as the active view in the parent window. Also, if thetab is the last remaining navigation tab, the application should do one ofthe following:

• Present the user with a new tab and its associated view (for example,last view visited, view located hierarchically above the current view).

• Gray the menu item and toolbar button for “Display in New Window”so that the user will not attempt to take this action.

Recommended When a user takes an action to return a child window to the parentwindow, the contents of the child window should be presented as theactive view in the current window, and its tab state (empty, pinned, orstuck) should be the same as it was when the user took the action topresent the tab in a child window.

This behavior should be true regardless of the state of other tabs in theparent window. If there was an existing tab in the parent window thatwas marked as “stay on top”, the state of this tab would be changed to“keep accessible”.

Recommended When a user takes an action to close a navigation tab:

• The view that was most recently visited by the user should bepresented as the active view in the parent window.

• If the tab is the last remaining navigation tab, the application shoulddo one of the following:

• Allow the user to close the tab and then present him with a newtab and its associated view (for example, last view visited, viewhierarchically above the current view).

• Gray the menu items and toolbar buttons for Close so that theuser will not be able to take this action.

172 Chapter 5


• Present the user with a confirmation dialog to confirm whetherthe user wants to exit the application.

Optional Applications can predefine navigation tabs as “keep accessible” for theviews which they believe users will want to access quickly. Any of thefollowing methods can be used:

• The tab for a view can set to the “keep accessible” state when thepresentation manager is first accessed. This will cause the tab to bepresented and available when the presentation manager is firstbrought up.

• The tab for the view can have a default state of “keep accessible”.While the tab for the view will not be presented when thepresentation manager is first brought up, the view will be marked as“keep accessible” once it has been accessed by the user.

• The application can designate the state of a tab as “keep accessible”when navigation away from that location would cause data to be lostor access to information to be lost.

Required If an application does predefine pinned tabs for specific views, usersmust be able to modify these settings so that the tab is “reusable” andthe view can be closed.

Recommended In a task presentation manager, tabs should be set to “keep accessible”by the application when either:

• The user has made changes in the task dialog without completing thetask.

• There are system activities that are still in progress which will affectthe successful completion of the task, even though all user actions arecomplete.

Recommended If the tab for the active view is not marked as “keep accessible”:

• The tab should be overlaid when the user navigates to a new view byselecting an item in the scope pane.

• The tab should be released and should disappear when the usernavigates to a new view by selecting one of the “keep accessible”navigation tabs.

Chapter 5 173


Recommended When there has been a change in status of the task or process that isgoing on in a view associated with a keep accessible navigation tab thatis not currently active, a visual cue should be presented on the left side ofthe navigation tab. Recommended visual cues include:

• A check mark to indicate that the user should check the viewcontained on the tab (See Figure 5-21)

• An exclamation mark to indicate that there has been an error. Thecolor of the exclamation mark should correspond to the level ofserverity of the error (see “Use of Status Colors” in Chapter 8 formore information).

Figure 5-21 Navigation Tabs Showing a Change in Task Status

Recommended The name presented in navigation tabs should be the name for the viewassociated with the navigation tab.

For example, if the view associated with the tab is Segment 2, then thetab should also contain the label Segment 2. Generic names should notbe used on tabs. See Figure 5-19 for an example.

Recommended If the name for an associated view is long and needs to be abbreviated inthe tab, tool tips should be provided to give the full name of the viewwhen the pointer is over the navigation tab.

Recommended Since the number of available tabs may be greater than the availabledisplay space, a mechanism for scrolling navigation tabs should beprovided.

Required All navigation tabs that have been marked as “keep accessible” must bemaintained regardless of context.

If there are multiple contexts in a presentation manager, users will wantto have quick access to views in different contexts. Users will not want tochange contexts to access the desired navigation tab. All navigation tabsthat have been marked as “keep accessible” should be added to the set ofavailable navigation tabs.

174 Chapter 5


Required In an object presentation manager, navigation by navigation tabs mustnot affect the selection list.

This is different from navigating by selecting items in the scope pane. Ifthe user navigates using the scope pane, the items that are selected inthe scope pane will clear any selections in the results pane and becomethe new selection.

Required Using navigation tabs to change views should cause the contents of thescope pane to change to match the view associated with the navigationtab.

When the user selects a navigation tab the object associated with view inthe navigation tab should be shown as the open object in the scope pane.A location cursor, not the selection highlight, should be used to indicatewhich object is open.

Required In a task presentation manager, navigating via navigation tabs must notstart a new task nor affect the status of other tasks that are currently inprogress.

Chapter 5 175

Window ComponentsStatus Bar

Status BarThe status bar is an optional area that should appear at the bottom of awindow. This bar provides users with state information about theapplication when such information will help them perform their tasks.

Figure 5-22 A Status Bar

Recommended If multiple sets of status information are to be presented, the sets ofinformation should be presented in visually-separated areas in thestatus bar. (See Figure 5-22.)

Recommended The status information in the status bar should be applicable to theactive window and view.

Recommended If context sensitive active help is provided on menu items, the help textshould be displayed in the status bar.

176 Chapter 5

Window ComponentsStatus Bar

177

6 Objects and Symbols

178 Chapter 6

Objects and Symbols

This chapter presents information on objects and the symbols that areused to represent them. It also includes information on the symbols usedto represent actions in the toolbars and in executable symbols. Thechapter includes guidelines for the following areas:

• When to represent objects with symbols in iconic views.

• Hierarchies of objects presented in the scope pane.

• Hierarchies of objects presented in the results pane.

• Assigning symbols to represent objects, connections and actions.

• Designing symbol classes for new types of objects and connections.

• Designing symbol subclass graphics for new objects, connections andactions.

Chapter 6 179

Objects and SymbolsIconic Views

Iconic ViewsAn iconic view is a collection of symbols that are displayed in a singleresults pane. An HP OpenView Network Node Manager (NNM) submapis an example of an iconic view. Each view displays a perspective of theobjects and information being represented about the objects (forexample, internet, WAN, bus, service view). Sets of views are typicallyorganized in a hierarchical fashion.

When to Represent Objects with SymbolsHP OpenView does not require that all of the objects be represented bysymbols. However, it is likely that most objects will be represented byone or more symbols in iconic views. The following guidelines should befollowed in assigning symbols to represent objects in iconic views.

Recommended Symbols should be used to represent managed objects in iconic views ifone or more of the following are true:

• A user wants to monitor the status of the objects. Graphical symbolscan serve as visual cues about the condition of managed objects (forexample, the wear status of backup media can be indicated by redcoloring on the symbol, or a network connection being down can beindicated by the red status color line connecting two objects, a serverbeing down can be indicated by the status color of the symbol classshape surrounding the graphic of the server).

• A user wants to act on an object (for example, configure or obtain dataabout it), using functionality presented in the window’s menus.

• A user wants to act on objects using drag-and-drop (for example, backup a file by dragging and dropping it onto a tape device).

• A user wants to see the relationships between managed objects. Theuse of connection symbols and different layout algorithms in iconicviews allows him to see these relationships.

180 Chapter 6


Levels of Symbol Creation

Recommended If the objects to be represented are part of an existing managementhierarchy that provides status information, create the symbols at thelowest possible level in the management hierarchy. This minimizesapplication conflicts in status setting of higher-level symbols andprovides the greatest level of flexibility and control for users.

Representation of Container ObjectsContainer objects are objects that contain other objects. The containmentrelationship can be either logical or physical. Examples of containerobjects include networks, computers, processes, domains, services,correlations, and media groups.

Required In a hierarchy in the scope pane of a window, container objects that canbe expanded to show their contents in the scope pane must berepresented by both a graphic and an expansion control that indicatesthe symbol can be expanded.

Required In a hierarchy in the scope pane of a window, container objects that onlyshow their contents in the results pane and cannot be expanded in thescope pane must either:

• Be represented by a graphic without an expansion control.

• If performance will be impacted by the processing required todetermine which container objects can be expanded in the scope pane,the graphic can initially be presented with an expansion control butthe expansion control must be removed as soon as the application candetermine that the object cannot be expanded in the scope pane.

Figure 6-1 Expansion Controls in a Hierarchy of Objects

Recommended In a results pane with an iconic presentation format, container objectsshould be represented by compound (explodable) symbols.

Chapter 6 181


Computer systems are fundamental container objects in manymanagement hierarchies. Resources manipulated during network,systems, and service management are contained within or connected to acomputer. As a result, many applications provide managementhierarchies that include a computer view, or they integrate into anexisting management hierarchy by adding symbols to views directlyunder computer symbols. Because of the large number of applicationsintegrating at this level, it is beneficial for the user if applications areconsistent in how they present objects in computer views.

Recommended Symbols in computer views (sometimes referred to as “node” views)should represent classes of objects (for example, networking, storagedevices, users, and file systems).

Recommended The symbols for object classes in computer or “node” views should becompound symbols that lead to lower-level views of the individualinstances of the objects of that class (for example, floppy device, harddrive, CD device), or to finer-grained classifications of objects in thatclass.

Recommended If some views in a given management hierarchy are not meaningful forthat hierarchy, or if the view only contains one symbol that is simply acontainer for other symbols, then consideration should be given toremoving the view from the hierarchy and moving up the lower levelitems.

Recommended A user should have some way of configuring the number of levelspresented in a given management hierarchy.

Example:

Users are provided with a dialog box to choose the levels to be presentedin the hierarchy. The dialog box allows the user to choose the levels to becombined and those to be eliminated.

Recommended Applications should ensure that all object views that they create can beaccessed through the higher level views in the scope pane or through achange in the setting of the context tab.

Although an application may not be interested in objects at all levels inthe hierarchy, it should create sufficient higher-level symbols to provideusers with appropriate contextual cues and navigation aids. In general,

182 Chapter 6


it is not a good idea to present managed objects in views that do not havea parent object or which do not allow navigation back to the root level forthe hierarchy.

Representation of Leaf-Level ObjectsLeaf-level objects are objects that do not naturally contain other objects.They may be associated with other objects and can have attributes.Examples of leaf-level objects include individual network cards, files, andindividual event correlation elements.

Recommended If the hierarchy is small enough so that there will not be a negativeimpact on performance, it is recommended that leaf-level objects bepresented in the hierarchy in the scope pane of the window.

Required If a leaf-level object is presented in the scope pane hierarchy, a graphicwithout an expansion control must be used.

Recommended If the leaf-level object is selected in the scope pane, it should result in thepresentation of a form or table view that displays the attributes orproperties of that object. Menu and toolbar items associated withaccessing a iconic view should be grayed.

Iconic views that contain explodable symbols imply the ability tonavigate to a lower-level item. Users should not be presented with thesetypes of iconic views when they open an object that is a leaf-level object.

Recommended In a results pane with iconic presentation format, leaf-level objectsshould be represented by symbols similar to those for container objects.Double-clicking on these symbols should lead to a form or table view thatdisplays the attributes or properties of the leaf-level object.

Representing Objects in an Existing Hierarchy

Recommended If there is an existing management hierarchy into which an applicationcan integrate, and user tasks will benefit from having the new objectspresented in the context of existing objects, the application should createits symbols at the appropriate locations within the existing hierarchy.

Example:

An application for managing the configuration and maintenance ofNetworked File Systems (NFS) is being developed. There is an existingsystems management hierarchy defined by another application that

Chapter 6 183


supports application integration. For systems that have NFS configured,two symbols are added in the computer view of the managementhierarchy. One symbol is for imported file systems and the other is forexported file systems. When the user opens up the symbol for importedfile systems, they see individual icons representing each of the filesystems that have been imported.

Representing All Objects in the HierarchyStand-alone applications or applications that are unique to amanagement area may need to create representations for all objects inthe hierarchy that they are interested in presenting to users.

Example:

In the HP OpenView Event Correlation System (ECS) application, thehierarchy of objects is based on the correlation that a user is creating todo event correlation. The levels in the hierarchy are based on thecompound correlation elements that are developed as part of thecorrelation. The contents at any level are based on the correlationelements that the user has added in building the correlation.

Recommended If the objects to be represented do not fit into an existing hierarchy, or ifuser tasks will benefit from having objects in a separate hierarchy, theapplication should create a new management hierarchy.

The creation of a complete management hierarchy in a presentationmanager requires that a context be created for the hierarchy. Thishierarchy should provide the user with cues as to the types of objectsbeing represented and the means to navigate within the hierarchy.

When integrating into NNM, placing a symbol in the root submapautomatically creates an entry in the context list. The symbol in the rootsubmap should represent the top level of the hierarchy.

Example:

In an application for managing processes, it does not make sense topresent processes inside an existing network hierarchy. As a result, theapplication will need to develop a complete hierarchy for processes,which would include the following: groupings of processes, individualprocesses within the groupings, steps within each process, and actionswithin steps.

184 Chapter 6


Representing Objects Using a Combined Approach

Recommended If there is an existing object hierarchy that meets a portion of theapplication’s needs, or if user tasks will benefit from having objects in aseparate hierarchy as well as in an existing hierarchy, the applicationshould use a combination of these approaches.

Example:

An application that provides object discovery and status information foran X.25 network could both integrate into an existing IP networkhierarchy of NNM and also provide users with a separate hierarchy thatonly shows X.25 networking.

Chapter 6 185


Figure 6-2 X.25 Application Using a Combined Approach

X.25Node A

Node BNode 3

X.25

X.25 Net

IP Internet

IP Internet

IP Internet

Segment

Node 1 Node 3Node 2

X.25

X.25

LAN

Root Submap

IP Internet

IP Internet

Segment

Node 3

X.25 Network

186 Chapter 6


Container Objects: Networks. At the highest level in thehierarchy is the root submap, where the parent object for IP submapswould likely be IP Internet. Users generally do not expect to navigate toan X.25 network via IP networks and segments. Therefore, the X.25application would want to provide a different route for accessing thesubmap that contained the X.25 nodes. The X.25 application must createa new X.25 network symbol to place in the root submap.

Note that submaps are tied to parent objects. Although only one submapcan be attached to an object, different symbols can explode into the samesubmap, since different symbols can represent the same object.

Container Objects: Computers. At the intermediate level in thishierarchy are container objects, as described by the examples that follow.

• Computers with X.25 only (Node B object in the “X.25 Network”submap).

At the intermediate level are computers that have only X.25 cardsinstalled and therefore would not be discovered or created by the IPmap application. They would need to be created by the X.25application, as is the case of the Node B object in Figure 6-1. Thecomputer is a container object that both provides contextualinformation for the user and contains the interface to the X.25network.

Even though the X.25 application creates the computer, thisapplication should not attempt to exclusively control computerobjects. The child submaps of the computer objects should be createdas shared submaps to allow for the addition of computer componentsby other map applications.

• Computers with X.25 and IP (Node C object in the “X.25 Network”submap; Node 3 object in the “Segment” submap).

Also at this level are computers that probably already exist in thedatabase due to their creation by the IP application. If a shared childsubmap exists for the computers, the X.25 application should add itscomponents to it, as it has done in the “Node 3” submap. If there is nochild submap, the X.25 application may create a shared submap andthen add its component objects, as is the case in the “Node B”submap.

Chapter 6 187


Since the Node C object, which supports X.25, already exists on themap, the X.25 application uses that existing object. It adds anothersymbol representing the object to its own X.25 network submap.Thus, the Node 3 symbol and the Node C symbol both represent thesame object and explode into the same submap (“Node 3” submap).

Leaf Level Object: X.25 Interface Cards. At the lowest level inthis hierarchy are the X.25 interface cards. The interface cards should beviewed as the base-level primary objects for the application. Since theseobjects do not readily break down into lower-level components, theapplication can assume control over the object and symbols, such as insetting status. To create these objects, the X.25 application needs tocreate the container objects (if they do not already exist) that contain theinterface cards.

Special Types of Objects and Views

Representing Multiple Location (Linked) ObjectsSome managed objects are homed in a single location but, for ease of use,need to be presented at multiple locations within a managementhierarchy.

Example:

User accounts defined by NIS are actually set up on the master NISserver system. To simplify the management of individual systems, theremay need to be symbols for NIS users and UNIX users under eachsystem. The user login information for NIS is actually homed on the NISserver, not on the individual client systems.

Users can do some management tasks when working with symbols forobjects outside of the objects’ home context. For other management tasks,it will be better for users to quickly access the home location for theseobjects.

Recommended Objects that are presented out of their home context should be presentedwith a symbol that indicates they are references or links to the actualobject. This symbol also indicates that the user can select the object andview it within its home location. See Figure 6-3, later in this chapter.

188 Chapter 6


Recommended To allow access to the home location for multiple location objects, a Goto Home menu item should be provided under the pull-down menus andin the pop-up menu for the symbol.

When the user accesses this menu item with a multiple location or linkedobject, the scope pane should change to have a location cursor on thehome location for the linked object and the results pane should show thelinked object as selected. This can be done within the current scope andresults pane for the window or the window can be split as in Figure 6-3,later in this chapter.

Representing Related Objects and Attributes

Recommended Objects that are not part of a given hierarchy, but which are related to agiven component in the hierarchy, should not be shown as part of thehierarchy. Doing so can create recursion in the navigation. This recursioncan cause the user to get lost when trying to navigate to accomplish histasks.

Example:

The following hierarchy has recursion:

domain->system->system components->users->tom->groupmemberships->lab->members of lab-> tom

The recursion is based on the fact that tom is actually a leaf-level objectand his group membership is an attribute or property of tom, not anobject contained within tom . It would be best for the user if the objecttom were treated as a leaf- level object.

Recommended Related objects should be presented in a selectable format that indicatesthat they are homed in a different location, that is they should berepresented by both a label and a symbol with a link indicator.

Recommended Access to the hierarchy associated with related objects should beprovided within the context of their home location in the managementhierarchy using the Go to Home menu item or a push button.

Recommended The Go to Home menu item should work with related objects withinproperties boxes that are presented in the results pane of the window. AGo to Home push button for accessing the home hierarchy of related

Chapter 6 189


objects should be provided in properties boxes presented outside of theresults pane. For more information see “Representing Multiple Location(Linked) Objects” above.

Figure 6-3 Item in a Property Box with a Link Symbol

190 Chapter 6


Figure 6-4 Split Window Showing Objects at Linked Location

Independent Iconic ViewsIndependent views (that is orphan views) are those which do not have aparent symbol or entry in the context list. As a result, these views cannotbe accessed by traversing the hierarchy of objects presented in the scopepane.

Recommended Use independent views only for special-purpose capabilities that are notintended to represent managed objects and their relationships.

Recommended If independent views are provided, users should be given easymechanisms for accessing these views (for example, a menu item toaccess the view).

Layout Algorithms for Iconic ViewsA variety of layout algorithms can be used for iconic views of objects. Thelayout algorithm that is chosen for a given view, should take thefollowing guidelines into account.

Chapter 6 191


Recommended Choose a layout for the view which will match the user’s task needs giventhe context and type of view.

Recommended If the layout of the objects in the real world affects a user’s managementtasks, choose a layout algorithm and a sequencing of object symbols thatmatches the real world.

Example:

When creating a view which will display systems on a token ring, use thering layout. Sequence the systems in accordance with their sequence inthe token ring. If network elements are connected with a bus, the viewshould have a bus layout.

Recommended If a user’s task involves developing a flow of information throughdifferent steps or elements, use a point-to-point layout.

Example:

A point-to-point layout would be used in displaying the flow of eventsthrough different event correlation elements or in defining the flow ofsteps in a process.

Recommended If a user’s task involves working with objects that are ordered in ahierarchy or for which there is some type of inheritance from otherobjects, use a tree layout.

Recommended When using a tree layout for inheritance, objects with more generalinformation that is carried over to other objects should be presented atthe top of the tree. Objects which are more specific or which mayoverwrite inherited data should be presented lower down in the tree.

Recommended If a user’s task involves a logical ordering of objects and their real worldposition is not important, choose a layout algorithm that will match theway in which the user thinks about the objects.

• A ring layout should be used when the connectivity between objects tobe represented is circular.

• A star layout should be used only when a central object is in arelationship with multiple peripheral objects.

192 Chapter 6


Recommended The row/column layout should only be used when the structuralrelationship between the objects represented in the view is not importantto a user’s task and sequencing of the items will benefit taskperformance. This layout may also be used if there are multiple differentrelationships between the elements to be represented in the view.

Recommended When using a row/column layout, sequence the objects to allow a user toquickly locate specific objects when doing his tasks. One or more of thefollowing types of sequences should be considered

• Sequence objects according to meaningful variables (for example,name, time of creation/change, performance).

• Place similar things together in a row and arrange the columns basedon a meaningful variable (for example, name, time of creation/change,performance).

Example:

Systems running the Windows NT operating system are placed in row 1,Windows 95 systems in row 2, HP-UX systems in row 3, and Solarissystems in row 4. Within each row systems are alphabetically orderedbased on their hostnames.

Recommended When a row/column layout is used, consider allowing the user the abilityto resequence the objects based on a variety of meaningful variables (forexample, name, address, time of creation/change, performance).

Chapter 6 193

Objects and SymbolsGuidelines for Assigning Symbols to Objects

Guidelines for Assigning Symbols toObjects

Symbols and Symbol TypesWhen a symbol is a graphical representation of a managed object, it is apresentation element that has characteristics such as a label, status, andsymbol type.

The symbol type is the classification scheme that helps users identify theobject being represented by a symbol. The symbol type should reflect thetype or nature of the underlying object that the symbol represents.Symbol type has two components: symbol class and symbol subclass.

• The symbol class specifies the general category of the object, such asnetwork, computer, or T1 carrier. For object symbols, class isrepresented by the outside shape of the symbol. For connectionsymbols, class is designated by the overlay graphic for the connection(one exception are connection symbols in the generic class which donot have overlay graphics).

• The symbol subclass further specifies the symbol, such as thecomputer subclass PC or the T carrier connection subclass T1. Iconsymbol subclasses are graphically depicted inside the outer shape.Connection symbol subclasses can be specified by the line style or thethickness of the connection symbol, or by a combination of these twoattributes.

Examples of symbols and symbol types are shown below:

Figure 6-5 Symbol Class and Subclass for an Object

194 Chapter 6


Figure 6-6 Symbol Class and Subclass for a Connection

Assigning Symbols to ObjectsHP OpenView provides a large variety of symbol classes and subclasseswhich an application can use to present managed objects.

Use the following guidelines when assigning symbols to objects andactions.

Required Choose symbol classes for objects that represent the type of object and itsrole in the application view. SeeTable 6-2 in the next section of thischapter.

Required Choose the symbol class and subclass that best depict the role that anobject is playing given the context in which the symbol will be displayed.

Example:

In a network hierarchy, a computer should be presented by a gatewaysymbol if the computer is a gateway in the network that is beingdisplayed. But in a system management hierarchy, this same computerwould be better represented by the appropriate computer class symbol.

Recommended Chose the symbol class and subclass for an object that will provide theuser with the most specific information available about the object.

Example:

If the object is a computer and the application knows it is a PC with aWindows NT operating system, use the symbol for the Windows NTsubclass, not the generic PC symbol.

Required Do not use existing HP OpenView graphics to represent objects otherthan those that are implied in the name of the symbol as it appears inthe Display Legend or Add Object dialog box.

Chapter 6 195


Example:

Do not use the symbol for the TestMeasure: Analyzer to represent amessage-browsing capability that is presented via an executable symbol.

Required Some symbol types are in the process of being phased out in HPOpenView in order to provide more specific symbol classes andsubclasses. Such types should not be used by an application. See thefollowing table:

Table 6-1 Obsolete Symbol Types and Their Replacements

Assigning Symbols to Connections andRelationshipsWhen assigning symbols to connections, the chosen symbol should berepresentative of the type of connection or relationship and informationabout the connection or relationship that is intended to be communicatedto the user.

Required If an application does not differentiate between different types ofconnections for management purposes, represent all connections by thedefault connection symbol type (that is, a single, pixel-wide, solid line).

Required If an application uses multiple, generic symbol subclasses to representdifferent types of connections or relationships, assign the mostdistinguishable connection symbols to those connections or relationshipswhich are the most different.

Do not use this SymbolType Use this Symbol Type

NetDevice:Analyzer TestMeasure:Analyzer

NetDevice:Modem Transceiver:Modem

NetDevice:PBX Connector:PBX

NetDevice:X25 Connector:X25

Software: Mail Application: Mail

Software: Database Application: Database

196 Chapter 6


Recommended When assigning connection symbols to connections or relationships:

• The overlay symbol on the line should be related to the class orcategory of connection or relationship that is being represented.

• The line style should be semantically associated with the specificcharacteristics of the connection or relationship.

• Line thickness should be semantically associated with the capacity orbandwidth of a connection or with the strength of a relationship.

Examples:

• If connection symbols are used to represent reporting relationships, adotted line is used to represent a loose reporting relationship and asolid line for a more definitive reporting relationship.

• Higher bandwidth connections would be represented by wideconnection symbols and lower bandwidth connections would berepresented by narrow connection symbols.

Recommended If an application will provide users with information on the amount ofthe available capacity that is used within a given connection, theguidelines for “Partially Filled Connection Symbols” in Chapter 8 shouldbe followed.

Assigning Symbols to ActionsAction symbols are symbols that represent actions a user can take.Action symbols are used in toolbar buttons and in executable symbolsthat appear in the results pane.

Recommended If action symbols are to be used for accessing functionality via executablesymbols in the results pane, these action symbols should be representedas members of the Software Utilities class or appear as transparentsymbols.

Recommended If an action provides functionality for which a subclass graphic hasalready been defined, the existing graphic should be used forrepresenting the action.

Most symbols for actions are found in the Software Utilities class. Othersymbols for actions are found in the toolbar of HP OpenViewapplications.

Chapter 6 197


Required Existing HP OpenView graphics for actions should be used only torepresent the functionality for which the graphic was defined. See Table6-4 for a list of different graphical cues and how they are to be used.

198 Chapter 6

Objects and SymbolsSymbol Design Guidelines

Symbol Design GuidelinesWhen presenting a new object in an HP OpenView application, firstdetermine if there is an existing symbol type (class and subclass) that isappropriate for representing the object. Consider both the visual aspectand the semantic aspect when making this determination. Only designnew symbol classes and graphics if none of the existing classes andgraphics match the characteristics of the object, action, or connectionthat is to be represented.

If new symbols are created for an HP OpenView application, theguidelines in this section should be followed.

Symbol ClassesIf new symbol classes need to be developed, they should not overlap withthe existing HP OpenView symbol classes. All symbol classes should bemutually exclusive. The following section provides information onexisting symbol classes as well as guidelines for creating new symbolclasses.

Using Existing Symbol ClassesA variety of symbol classes have been developed for HP OpenView andare shown in Table 6-2. If possible, choose from among these classes andbackground class shapes when developing your application. Note thatTable 6-2 shows just the outside class shapes, even though the table’sdescriptions also discuss the internal graphics that are appropriate foreach shape.

Recommended If there is an existing symbol class that is appropriate for an object, usethat symbol class. New symbol classes should be created only as needed.

See guidelines above in “Assigning Symbols to Objects."

NOTE If the application is integrating into NNM, additional capabilities can beadded in the symbol registration file for the symbol that will be used torepresent the object.

Chapter 6 199


Table 6-2 Existing Symbol Class Shapes

Symbol ClassName

ClassGraphic

Symbol Class/Subclass Description

Application A software object which is used by a system userto accomplish different tasks. The internalgraphic in this class identifies a general type ofapplication or the specific application itself (forexample, word processing, business accounting,Lotus 123, Microsoft Word).

Cards A card or interface that may be contained within acomputer or network element. The internalgraphic identifies the specific type of card orinterface (for example, an IP network card or agraphics accelerator).

Client A managed object that is receiving a service fromanother managed object. The internal graphicidentifies the type of service that the client isreceiving (for example, a backup client or an NFSclient).

Computer Computer systems that are not playing a specialrole in the management context. Typically, theinternal graphic indicates the type of computervendor and/or the type of operating system on thecomputer (for example, HP-UX, SUN, WindowsNT).

Connector Network elements that act to connect or routeinformation from one area to another in thenetwork. Typically, the internal graphic indicatesthe type of connector (for example, a frame relayswitch, gateway, or bridge).

Device Input, output, and storage devices found in anetwork and system environment. The internalgraphic indicates the specific type of I/O orstorage device (for example, a fax, printer, plotter,audio, monitor, mouse, keyboard, or disk drive).

200 Chapter 6


Domain Sets of objects that have a logical connectionbetween the objects (for example, communicationprotocol, management software, managementresponsibilities). The internal graphic indicatesthe basis for combining the objects into thedomain or the type of domain (for example, acollection station, a Windows NT domain, or amanaged node group).

Location Locations or sites in which managed objectsphysically reside. This class of symbols provides ahigher-level classification for grouping objectsbased on their geographical or physical location.The internal graphic indicates notable aspectsabout the location in the physical world (forexample Australia, state, city, site, or room).

Logo Executable functionality, when the desire is torepresent the vendor associated with theexecutable symbol.The internal graphic indicatesthe specific vendor (for example, HP OpenView,IBM).

Media Media that may be found in the network andsystem environment. The internal graphicindicates the specific type of media (for example,cd, tape, floppy, or disk).

Network Networks or higher-level network components.The internal graphic provides information on thetype of protocol and/or layout associated with thenetwork (for example, IP, IPX, bus layout, or starlayout).

Symbol ClassName

ClassGraphic


Chapter 6 201


Network Device Miscellaneous devices in the network. Thiscategory should only be used for network devicesthat do not meaningfully fit into another objectclass. The internal graphic indicates the specifictype of device (for example, an Add DropMultiplexor).

Server Managed object that is providing a service to oneor more managed objects. The internal graphicidentifies the type of service that the server isproviding (for example, a backup client or an NFSclient).

Service Service that is being provided to users or to othermanaged objects. The internal graphic identifiesthe type of service (for example, backups, printerspooling, and domain name service).

Software Software object that is a configurable parameterof an application or operating system, or which isprovided through the operating system. Theinternal graphic identifies the type of object orparameter (for example, a user group, messagegroup, file system, file, driver, or process).

Symbol ClassName

ClassGraphic


202 Chapter 6


Graphical Cues for Symbol ClassesThe following cues have been defined for object classes in HP OpenViewapplications and should be used as part of the graphics for the indicatedobject classes:

Software Utilities Executable functionality, when the desire is torepresent the type of functionality that will beprovided to the user when the symbol is activated.The internal graphic indicates the type offunctionality or the type of results that will beprovided (for example, an event browser, findroute, or a graph).

Test and Measurement Intended for representation of objects that areused for test and measurement. The internalgraphic indicates the specific type of test andmeasurement object (for example, a LANanalyzer).

Transceiver Intended for representation of objects that receiveand/or transmit information. The internal graphicindicates the specific type of object (for example, aphone, modem, satellite, or microwave station).

Symbol ClassName

ClassGraphic


Chapter 6 203


Table 6-3 Internal Graphics Cues

Images Cues to add to Graphics forthe Object and Connection Classes Listed

Class = Cards classCue = Small card in the upper left portion of the pixmap

Class = Client classCue = Single gray arrow pointing downward from the topright corner of the icon

Class = Server classCue = Three lines pointing upward to the top right corner ofthe icon

Class = Service classCue = Multiple objects representing the specific type ofservice

Class = Fiber Connection classCue = Circle with two 45 degree arrows

Class = TCarrier Connection classCue = Two triangles touching at their apex

204 Chapter 6


Creating New Class Shapes for Objects

Required New classes of icon symbols must have a unique outside shape that isdifferent from the outside shapes used in existing classes. A distinctiveoutside shape is required for all new symbol classes. Refer back to Figure6-2 for a list of outside shapes being used by existing symbol classes.

The outside shape provides both a visual cue to a user of the class ofobject that he is working with and a means of displaying statusinformation to him.

Recommended If a new symbol class that is closely related to an exiting class needs to becreated, the new class should both:

• Contain a discernible cue that helps users to relate its members tothe existing class.

• Contain cues that allow the user to distinguish the new class from theexisting class.

Because icon symbols are sometimes used without their backgroundshapes, it is a good idea to provide visual cues in the graphic thatindicate the class of the object. See “Graphical Cues for Symbol Classes”for more information.

Example:

The client class is closely related to the server class. The two classes havesimilar outside shapes. Members of the client class have a single inwardpointing arrow in the right corner while members of the server classhave three outward pointing arrows in the right corner.

New Connection Symbol ClassesSupport for different connection symbol classes is provided forapplications integrating into HP OpenView Network Node Manager onHP-UX, Solaris, and Windows NT.

Recommended Follow the connection symbol guidelines in “Assigning Symbols toConnections and Relationships."

Required New connection symbol classes should be created only by applications inwhich the management of the connection or relationship is important.Applications that are primarily concerned about the management of

Chapter 6 205


network or system elements which happen to be connected or relatedshould use the generic symbol class “connection” to represent theirrelationships and connections.

Required Do not define a symbol class with a visual appearance that would includeexisting members of other classes. Before a new connection symbol classis defined, information should be obtained on existing, registeredconnection symbol classes and subclasses; doing so will ensure that thenew symbol class being defined does not conflict with anyalready-defined symbol classes and subclasses.

The overlay graphic is the visual cue to be used for identifying differentconnection symbol classes. An example of an overlay graphic on top of aconnection symbol is shown below:

Recommended Overlay graphics should be consistent with existing standards (ANSI,ISO).

Recommended Overlay graphics must not have the potential for offending users.

Recommended Overlay graphics should be abstract (a diamond, a triangle) so they canbe readily discriminated from icon symbols. They should not requirechange when they are localized for use in other countries.

Recommended The size of an overlay graphic should be minimized to reduce clutter. Thesizes for the overlay graphic must be 11, 13, 17, 21, 25, or 29 pixels.

Recommended When an overlay graphic is defined via a color graphic, the colors used inthe graphic must minimize the use of color associated with overlaygraphics. Overlay graphics should consist of no more than two colors. Itis recommended that most overlay graphics be black and white.

Recommended If a new connection symbol class is created that is an extension of anexisting, closely-related class, the new class should have visualcharacteristics that not only help users to relate the two classes to oneanother, but also to distinguish the new class from the existing class.

206 Chapter 6


Example:

Two connection lines have the same line style, but the overlay graphic isdifferent and this visual cue indicates to the user that they representdifferent types of connection symbols.

Symbol Subclasses (Graphics)Generally the graphics used in HP OpenView are drawn from thefollowing metaphors or domains:

• Information technology (networks, systems, devices, services, media).

• Office environment (file cabinets, files, folders, data, graphs).

• Abstract symbols (arrows, boxes, circles).

If new symbol subclasses or graphics need to be developed, they shouldbe consistent with the existing HP OpenView symbol graphics. Thefollowing section provides information on existing symbol subclasses orgraphics as well as guidelines for creating new graphics.

Using Existing Symbol Subclasses (Graphics)A variety of symbol subclasses or graphics have been developed for HPOpenView. Many of these graphics make use of identifiable visual cuesthat are intended to convey specific concepts to users. These visual cuesprovide a visual language for the user. Consistent use of these visualcues in accord with the visual language will make it easier for users torecognize the meaning of graphic symbols and to translate new symbols.See Table 6-4 for information on defined visual cues.

Recommended If there is an existing symbol class but no subclass that matches thecharacteristics needed to represent an object, define a new symbolsubclass for the object but use the existing symbol class. For moreinformation see “Guidelines for Assigning Symbols to Objects” and“Using Existing Symbol Classes."

Required If an toolbar button or executable symbol provides functionality forwhich a graphic has already been defined, the existing graphic should beused instead of creating a new graphic.

Required Existing HP OpenView graphics should be used only to represent theconcepts for which the graphic was designed.

Chapter 6 207


Table 6-4 Visual Cues Used in Existing Graphics

Predefined Visual Cues Description

Adding items to a log file: for symbolsthat represent the logging of differenttypes of information

Arrow pointing upward: for symbolsthat include the concept accessing theparent object

Arrow side ways and up: for symbolsthat include the concept moving up alevel in the hierarchy

Book: for symbols that include theconcept of a browser.

Binoculars: for symbols that relate tothe search for the location of objects.

Clipboard: for symbols that representan inventory of objects.

208 Chapter 6


Closing lid: for closing a window orview within a window.

Cloud: for symbols that include theconcept of a Wide Area Network.

Cog: for symbols that include theconcept of hidden software that allowapplications or hardware to run, forexample, daemons, services, agents.

Configuration switches: for symbolsthat represent the configuration ofpart of the HP OpenViewenvironment.

Curved arrow: for symbols thatrepresent the action of taking anobject and moving or copying it into adifferent form or location.

Envelope: for symbols that include theconcept of mail.

File cabinet: for symbols that includethe concept of a file system.


Chapter 6 209


Folder: for symbols that include theconcept of a folder or other type ofcontainer. A graphic for type of objectin the container can be super imposedon the folder graphic.

Glasses: for symbols that involve thepreviewing of either information orthe results of an action that will besimulated before it is actually carriedout.

Globe: for symbols that include theconcept of the World Wide Web.

Hierarchy with top: for symbols thatinclude the concept of going to the topof a hierarchy.

House: for symbols that include theconcept of a home location.

Line Graph: for symbols thatrepresent on-going data collection orpresentation for one or morevariables.

Listing sheet: for symbols thatrepresent listings of information.


210 Chapter 6


Magnifying glass: for action symbolsthat provide a closer look at one ormore objects, or which are used formonitoring objects or processes.

Mixture of tools/application: forsymbols that represent an applicationwhich provides a variety offunctionality.

Monitor and desktop computer: forsymbols that include the concept of apc type of computer. The operatingsystem or vendor for the pc should bepresented by changing the content ofthe display for the PC.

Monitor and keyboard: for symbolsthat include the concept of aworkstation type of computer. Theoperating system or vendor for theworkstation should be presented bychanging the content of the display forthe workstation.

Multitabbed folder: for symbols thatinclude the concept of a properties.

Multiple instances of the same type ofobject: for symbols that represent agroup of that type of object.


Chapter 6 211


Network Triangle: for symbols thatinclude the concept of a local areanetwork (LAN) of an indeterminatetype.

Options box: for symbols thatrepresent the configuration of anobject in a context that is notdedicated to configuration.

Person: for symbols that include theconcept of a user.

Printer: for symbols that include theconcept of a printer.

Pyramid of Disks: for symbols thatinclude the concept of a database.

Question Mark: for symbols thatinclude the concept of help.

Sheets of paper: for symbols thatinclude the concept of a file.


212 Chapter 6


New Symbol Subclasses (Graphics) for Objects

Required Applications that present objects in iconic views must provide at leasttwo sizes for each icon: 16x16 and 32x32.

Sparkle: for symbols that include theconcept of a creating something new.

Status colors: for symbols thatrepresent the functionality ofproviding status information on one ormore objects.

Switch: for symbols that include theconcept of some type of switch.

Table: for symbols that represent thepresentation of static data on one ormore variables.

Trash can: for symbols that representthe deletion or removal of something.

Yellow Triangle: for symbols thatinclude the concept of an alarm, event,message.


Chapter 6 213


Recommended It is recommended that applications which simultaneously present alarge number of objects in the results pane should provide their iconsymbols in multiple sizes so that the images can be scaled withoutdistortion of the image. The recommended sizes include 16x16, 20x20,26x26, 32x32, 38x38, 44x44 and 50x50.

Recommended Graphics used in toolbars should be 24x24.

Action graphics are harder to present than objects. The 24x24 size makesit easier for users to recognize what is being presented in the toolbarbutton.

Some HP OpenView applications use size 16x16 toolbar buttons. As aresult, it is a good idea to provide toolbar buttons in two sizes: 16x16, and24x24.

Action graphics used in the results pane should be the same size as newsymbol subclasses for objects, above.

Required New symbol subclasses must use the same outside shape as defined forother symbols in that class. Do not create new symbols that belong in anexisting class of symbols and place them in a new symbol class.

Recommended If action symbols are to be used for accessing functionality via executablesymbols, these action symbols should come from the Software Utilitiesclass (or appear as transparent symbols).

Required New symbol subclasses must contain any class-specific graphics thathave been defined for the class.

Recommended If a new graphic has concepts similar to other graphic that are alreadydefined for HP OpenView, the new graphic should use the same visualcues as the existing symbols.

Recommended Graphics that represent the symbol subclasses should be easilyrecognized by users as being associated with the objects they represent.

Recommended The graphics that are used for action symbols must provide arepresentation of one or more of the following:

• The type of functionality being provided by the control that thesymbol is associated with (such as using a curved arrow to representcopying or installing).

214 Chapter 6


• The type of result that will be obtained as a result of the action (suchas installed software).

• The type of object being acted upon (such as software).

Example:

The symbol for a fax card contains the graphic for a fax device and theclass-specific graphic for a card.

Recommended Graphics should not have the potential of offending users.

Example:

A devil may be an easily recognizable symbol for a UNIX daemon, but itshould not be used as it has the potential to offend users. Graphics whichcontain body parts (such as a hand) also may be viewed as offensive insome cultures.

Recommended If possible, the graphics used in subclasses should not require changeswhen they are localized for use in other countries. Graphics based onpuns or images for words that sound the same but which have a differentmeaning should not be used, as they cannot be localized. To avoid theneed to localize graphical images, do not use the following items in asubclass’s graphical image:

• Hand and arm gestures.

• Body parts and positions.

• Facial expressions.

• Stars or crosses (may be interpreted as religious symbols).

• Words or alphabetic characters.

• Punctuation or commercial symbols.

• Animals.

• Puns and humor.

• Images for words that sound the same, but which have a differentmeaning.

Chapter 6 215


Recommended All graphics used for defining new symbol subclasses should come fromthe network and system management domain or office domain; or theyshould be logical or symbolic representations of the objects theyrepresent.

Recommended A new subclass that is a variation of an existing icon symbol (such as, aspecific vendor’s PC), should either:

• Provide a clearly recognizable version of the object that it represents.

• Use a modification of an existing graphic that contains a cueassociated with the particular variation (for example, using a PCsymbol with the vendor’s initials in the display).

Recommended When the symbol subclass is defined via a color pixmap, the colors usedin the bitmap or icon should:

• Come from the color palette provided by HP OpenView, see ChapterC, “Color Mapping and Palettes.”

• Use subtle. muted coloring in the pixmap image so that the imagedoes not interfere with the visibility of the status colors. This isparticularly important when users are interacting with a submapcrowded with numerous small images.

• Provide the illusion of a concrete, three-dimensional object ratherthan the effect of a lot of color in the image.

New Connection Symbol SubclassesNew connection symbol subclasses should be created by applications onlywhen either:

• The application has created a new connection symbol class and needsto populate that class with subclasses.

• Existing connection symbol subclasses are not sufficient to meet theneeds of the specific types of connections or relationships that need tobe represented.

Recommended A symbol subclass must not be defined with a visual appearance thatcould be interpreted as belonging to a class other than the one thesymbol actually belongs to, or which is identical to another instance of asubclass that is in the same class. A new connection symbol subclassshould be defined only after examining the registered connection symbolclasses and subclasses for those applications with which an application

216 Chapter 6


will coexist; this will ensure that the new symbol subclass will not bedefined in a way that it would conflict with existing symbol classes andsubclasses.

Recommended Subclasses of a specific connection class must have the same overlaygraphic that will be used consistently across all members of the class. Itis generally recommended that two visual cues (such as line style andoverlay graphics) be maintained as common across all subclasses withina class.

The use of line style and thickness in new connection symbol subclassesmust be consistent with the semantic meanings suggested for thesevisual cues in the sections below and in “Assigning Symbols toConnections and Relationships."

Connection Symbol Line StyleVery similar line styles are difficult for users to differentiate. If line styleis used as the primary visual cue for differentiation between connectionsymbol subclasses, care should be taken to make sure that all of the linestyles within a class are sufficiently different in their visual appearance.

Connection Symbol ThicknessWhen using thickness as an attribute of a connection symbol class orsubclass, the largest width allowed can be no greater than the iconsymbols being connected (that is the largest icon symbol allowed is 50x50pixels wide). Also remember that, as the icon symbols shrink based onthe scaling of the submap, the connection symbols will also shrink. Thischange in size may make it very difficult for users to discriminatebetween different connections based on thickness alone. Users will bejudging the thickness of the connections relative to the size of the iconthat they are connecting.

Required If thickness is used as the only visual cue for differentiating betweenconnection subclasses, only a few widths should be used (no more than5.) The differences between the line widths should gradually increase asthe line widths increase. Due to proportional changes in line width withany shrinkage in the icon symbols, the following line widths aresuggested: 1, 5, 15, 30, or 50 pixels.

Chapter 6 217


If only two line widths are used, the thinnest line should be one pixelwide and the thicker line should 5 pixels or more. If the difference in linewidth is not at least 4 pixels, users will not be able discriminatedifferences in width when the icons and connection symbols have beenscaled to their smallest size.

To aid users in discriminating between different subclasses, otherredundant visual cues should be provided in addition to thickness.Possible redundant cues can be line style or variations in the overlaygraphic.

218 Chapter 6

Objects and SymbolsUser Modification of Views

User Modification of Views

Changing Symbol TypesApplications should try to be as specific as possible when discoveringobjects and representing them in their management hierarchies. Nomatter how good the application is, there will likely be some types ofobjects that the application cannot adequately differentiate. In theseinstances, the symbol choice specified by the application will not be asgood as the symbol specification that can be provided by the user.

Optional By default, users should be given the choice of changing a symbol typeonly within the symbol class to which the object was originally assignedrather than changing type to all possible classes.

Recommended If there are multiple symbol classes that would be applicable for theobject within the active view, users should be able to chose between thesymbol classes in the Change Symbol Type dialog box.

See Figure 6-7 below for an example of a Change Symbol Type dialogbox.

Chapter 6 219

Objects and SymbolsUser Modification of Views

Figure 6-7 Change Symbol Type Dialog Box

User Addition of SymbolsIt is unlikely that applications will be able to discover all of the objects ina given management area. As a result, applications should allow users toadd objects to their views.

Recommended By default, users should be given the choice of adding symbols within thesymbol classes that are most appropriate for the active view. Symbolsthat are not appropriate for the view should be excluded.

Recommended When applicable, users should be able to add multiple objects byspecifying a file that defines the parameters required for adding the setof objects.

220 Chapter 6

Objects and SymbolsCreating NNM Submaps

Creating NNM SubmapsWhen creating views that will be submaps within NNM, a number offactors have to be considered:

• Will a submap be shared or exclusive?

• Will a submap be persistent or transient?

The concept of submap context and submap hierarchies also needs to beaddressed. All of these topics are discussed in this section.

Shared vs. Exclusive SubmapsNew submaps can be created as a shared submap or as an exclusivesubmap. Shared submaps are those in which multiple applications usethe same application plane. Exclusive submaps are those that can beused only by the creating application and by end users. Otherapplications are prohibited from adding objects to exclusive submaps.

Recommended It is recommended that applications create and use shared submaps.Using these will allow other map applications to add objects to theapplication plane, thus building upon and adding value to theapplication. Using shared submaps will also enable other applications toadd menus to the menu bar in a submap (if the menu placement rulematches the context identifiers specified for this submap). Becauseshared submaps allow applications to work together to create a totalpicture, their use provides users with the ability to develop a map thatmore closely approximates the composition and layout of their networkand systems environment. It also helps users locate and identify objectsfor manipulation since the resulting maps are organized in a formsimilar to a real world network.

Recommended An exclusive submap should be created only if there are explicit reasonsfor one application to keep other applications from modifying its submap(such as an application which is able to provide absolutely all the detailand information that a user would need in order every feature in thatapplication).

Recommended An application should not attach exclusive submaps to an object in ashared submap unless that application created the parent object.

Chapter 6 221


Using an Existing Shared SubmapRather than create its own submap, an application can add objects to anexisting shared submap that was created by another application. Thisallows for the generation of a mapping that is closer to the compositionand layout of the user’s network and systems environment.

To use existing submaps, an application must be aware of other existingand compatible applications. The first application must query HPOpenView Windows to determine if the submap-creating application isinstalled and running. If the submap-creating application is not installedand running, the object-creating application must provide a backupmechanism for creating its own submaps, or it must require the runningof the submap-creating application as a prerequisite for its invocation.

When menu items are added to an existing shared submap which arespecific to the objects being added to the submap, context identifiersshould be used to enable the association of these menu items with thesubmap. Without these context identifiers, menu items for acting onthese new types of objects will not appear in the menu bar for thesubmap.

Any application should anticipate the possibility that its submaps will beused by other applications and determine how to interact with theseother applications.

Persistent and Transient SubmapsHP OpenView Windows provides transient submaps, which are createdand deleted on user demand. Transient submaps provide better overallperformance for users by allowing the management of a larger number ofobjects. When the on-demand feature is enabled, only the host submap,home submaps, and submaps that have been made persistent are loadedinto memory (RAM) when HP OpenView is first started. Other submapsare loaded into RAM when the user opens them, and they are removedfrom RAM when the last user closes them.

Persistent submaps are provided for backward compatibility and to allowfor compound presentation status. Filters can be used to make specificsubmaps persistent if an application requires such persistence tofunction appropriately. However, having a large number of persistentsubmaps takes away the end-user advantages associated with transient

222 Chapter 6


submaps. It is generally recommended that an application be designed touse transient submaps. Any use of persistent submaps should beminimized.

To move an application from being dependent on persistent submaps tobeing designed to take advantage of the on-demand functionality, followthese guidelines:

Required Remove any application dependencies on the presence of symbols andsubmaps.

Symbols and/or submaps created or used by an application will notalways be present in RAM. Since API calls to the “map” can act only onwhat is currently in RAM, the results to an application’s API calls maybe different than anticipated. If an application depends on thecontinuous presence of all symbols and submaps, the informationreceived may not be timely or complete.

Example:

• If an application depends upon the notification of when new objectsare discovered and added to the NNM map, the application shouldhandle this notification when the submap containing the new object isopened, as opposed to when NNM is first started.

• If symbols are added to the child submaps, they should be addedgradually as submaps are opened, instead of when NNM is firstinvoked. Note that a listing of submaps or objects in the map willgenerally be incomplete, as the list will vary depending on whichsubmaps a user currently has open.

Recommended If compound presentation status is being used, minimize the number oflevels of submaps required to provide this status. Limit the persistentsubmaps to one level below the symbol that uses compound presentationstatus.

Submap ContextThe concept of submap context was developed to allow applicationdevelopers to tailor the menu items and toolbar buttons in each of theirapplication’s submaps. Submap context better matches the menu itemsand toolbar buttons in an application with the types of objects presented,the type of management provided, and the user tasks performed.

Chapter 6 223


The advantages of submap context include:

• Eliminating continuously grayed-out menu items in a particularsubmap.

• Restricting menu contents based on the user’s tasks. Submap contextgives users quicker access to the menu items they need, based on thetypes of objects in the submap and the type of work being done.

• Giving developers of map applications more control over the types ofmenu items presented in the submaps that they create. They specifythe context of submaps so that only those menu items relevant to thesubmap’s contents and type of management will be presented in thesubmap menus.

Using Submap Context

Required For each submap created, a submap context must be specified. If nocontext identifiers are provided for a submap, it will contain only genericmenu items or undefined menu items that have no menu placement rulesidentified. Information on how to specify context for menu items in HPOpenView Windows submaps is in “Context and Menu Items” in Chapter5.

Context can be added by end users or by other developers, but they canbe removed only by the application that created them. Since a menu itemneeds to match only one submap context identifier, the more submapcontext identifiers that are defined, the wider the variety of menu itemsthat can be included in a submap. Conversely, the use of fewer submapcontext identifiers allows for finer placement of menu items.

The following guidelines suggest the types of submap context identifiersto be defined when creating a submap:

Required Include context identifiers for the type of management that will be doneby the users of the submap (such as printer management, disk spacemanagement, or IP network management).

Recommended Include context identifiers for the types of network protocols anticipatedin the submap (such as IP, SNMP, or CMIP).

Optional Include context identifiers for the type of objects anticipated to occur inthe submap (such as routers, networks, bridges, gateways, genericconnector or PC, mini, workstation, or mainframe).

224 Chapter 6


Required Block generic menu items and toolbar buttons only if the submap is ahighly- specialized submap, where the inclusion of these items wouldlead to user confusion and errors. Generic menu items and toolbarbuttons are blocked by specifying a submap context identifier ofNoGeneric . Examples of generic menu items are Print , Add Object .

Recommended Block undefined menu items from submaps unless these submaps andsymbols are general ones that other applications are planning to buildupon. Pull-down menu items in applications that have not beendeveloped under the context-dependent paradigm will automaticallyappear in submaps unless they are blocked. Contextually-undefinedpull-down menu items are blocked by specifying a submap contextidentifier of NoUndefined .

Required Provide consistent context identifiers for all submaps within a hierarchyof submaps that relate to a given type of functionality (NFS, printermanagement) or topology (IP or SNA). Testing has shown that usersbecome confused when there are arbitrary changes in the menus fromone submap level to the next. In a given hierarchy of submaps, makevariations within the context identifiers only if there are real differencesin the functionality associated with the submap or the objects to bepresented in the submap.

Recommended When adding to the submap context of a submap created by anotherapplication, define only those context identifiers that relate explicitly tothe particular symbols being added to the submap or the types ofmanagement capabilities being added to the menus or toolbar.

Submap Window GeometryThis feature is supported for applications integrating into NNM when itis running natively on HP-UX, Solaris, and Windows NT operatingsystem.

NNM provides applications with the ability to set the geometry (size andlocation) for the submaps that they create. An end user can save hischanges to submap window geometry on a per-submap basis, which willoverride the geometry settings of applications.

Chapter 6 225


Given the integration of multiple applications that all have the ability toset submap geometry, there is the potential for applications to createusability problems for end users by creating submaps that totallyoverlap those presented by other applications. To minimize the need forwindow manipulation by the user, adhere to the following guidelines.

Required Restrict an application’s use of geometry for submaps by:

• Setting submap geometry primarily for special-purpose windows ifthe user’s use model is clearly understood.

• Not specifying submap geometry for regular submap windows thatare used to display the topology of a set of managed objects.

Required If an application is going to set submap geometry, it should be done priorto the first time the submap is displayed.

Required After submap creation, applications should modify the initial submapgeometry (that is the geometry set at creation) only when requested bythe user. User requests are typically given through the choice of a menuitem or the activation of a toolbar button.

Example:

An application could provide a menu item that would result in the tilingof all submap windows open in the display if their geometry had not beset by the end user.

Recommended When specifying submap geometry, take into account all of the windowsthat a user will simultaneously be using in his environment.

Before specifying submap geometry for any submap, develop anunderstanding of what applications are likely to be in the user’senvironment and which ones he will use simultaneously. The geometryfor one application’s submaps should not interfere with the use of otherapplications.

Recommended When specifying submap size, take into account both:

• Consistency in the size of windows within a given hierarchy. If usersturn submap overlay off for a large number of submaps, it can bedisconcerting to have related submaps presented in different sizeswhen the user has not modified the size.

226 Chapter 6


• Whether or not overlay is set for the submap window. If the submapwindow is overlaid, parent submap and child submaps of the currentsubmap in the hierarchy must have the same size.

• The number of windows to be presented on the screen at one time. Ifan application sets a large size for its submap window, there will beless space for other submap windows. The default size of anapplication’s submap must allow for the simultaneous viewing ofmultiple submaps.

Recommended When specifying submap location, take into account:

• The flow of the user’s actions. In countries with European-basedlanguages, user task flow should proceed from the upper left portionof the display to the lower right portion of the display. It is desirablethat the placement of windows be consistent with the languagevariable specified by the user.

• The other windows in the display. Window overlap should beminimized.

Submap Window OverlayThis feature is supported for applications integrated into NNM when itis running natively on HP-UX, Solaris, and Windows NT operatingsystem.

To minimize the number of extraneous windows that are presentedduring user navigation within the map, HP OpenView reuses displayspace when displaying submaps. By default, submap windows areoverlaid as the user directly navigates from one submap to the next (thatis, he opens a symbol or uses a menu item to directly access a submap).End users have the ability to override the default overlay state on aper-submap basis.

Application developers have the ability to change the default state of theoverlay from “on” to “off” by using the OVw APIs. Map applicationsshould adhere to the following guidelines related to changing the settingof the submap overlay toggle:

Recommended The state of the overlay toggle should be left with the default of “on” if:

Chapter 6 227


• The submap is a regular submap window that is used to display thetopology of a set of managed objects. It is often difficult forapplications to identify at what level their customers will be trying todo management. It is better to allow users to identify “important”submaps that they do not want to overlay.

• Users will want to go back and forth between different levels in agiven submap hierarchy, and there is no known reason to have thedifferent levels of the hierarchy open at the same time.

Recommended The state of the overlay toggle should be changed to “off” immediatelyafter submap creation if:

• The submap is a special-purpose submap that users will want to haveavailable at all times (for example, Quick Navigator), and overlayingthe submap will detract from its intended functionality.

• It is known in advance that users will need to keep the current andnext level of the submap open in order to use the full functionality ofthe two levels of submaps.

If an application developer specifies NoGeneric for his application, theoverlay menu item will not be available in his submap, and users will notbe able to change the overlay state. The developer must therefore modifythe application registration file to add back the overlay menu item.

228 Chapter 6


229

7 Object Selections, Grouping,and Drag and Drop

230 Chapter 7

Object Selections, Grouping, and Drag and Drop

This chapter provides guidelines on the following topics:

• Selection of objects.

• Grouping of objects.

• Drag and drop.

Chapter 7 231

Object Selections, Grouping, and Drag and DropSelection Guidelines

Selection GuidelinesMany HP OpenView applications use an object-action syntax in theiruser interfaces. Users select symbols to indicate the objects that theywant to manipulate, then select menu items to initiate the desiredaction. The selected objects make up the selection list.

Selection is a key aspect of user interaction with an application or set ofapplications. Consistency in the way selections are made, how they aredisplayed and how they are treated by the application is very importantfor ease of learning of individual applications and transfer of trainingacross applications. Users do not want to learn special selection rules forinteracting with specific applications.

Basic Selection ModelThe HP OpenView Environment frequently has multiple applicationsrunning together. Individual applications within the environment maybe developed as multiple pane windows or presentation managers thathave access to different views within a single window. However,functionality that requires a global selection list including all selectionswithin a set of applications or selection that extends across multipleviews in a window is less common than functionality that focuses on theselections that are contained within a single view. For most tasks usersmake their selections within a single view in the results pane of thewindow.

The basic selection model for HP OpenView applications is based on themost common type of selections done by users. It also is consistent withthe most common type of selection in the Windows NT operating systemand the Common Desktop Environment on UNIX. This selection modellimits the list of selections to all items selected within the currentwindow.

A global selection list that can include selections across all windows inthe HP OpenView Environment is planned for the future. The plannedglobal selection list will not be the default selection list, this list will beused only when the user takes an explicit action to request its use.

232 Chapter 7


The HP OpenView Windows provides a global selection list that isapplicable to all HP OpenView applications (that is, NNM, ITO) in theWindows NT or UNIX environment. This selection list is beingmaintained for backward compatibility reasons but will be replaced inthe future.

The following guidelines provide details on the basic selection model forHP OpenView applications.

Required The active selection list, for application not based on HP OpenViewwindows, must be restricted to items selected within the current window.

In the future, users will be able to request the use of a global selectionlist.

Required If the user makes an single selection in the scope pane or in the resultspane of a window, all other selections within the window must be cleared.

Required When the user makes a single selection in the results pane, the selectedappearance of the open item in the scope pane must be removed andreplaced by a location cursor or an open indicator for the item in thescope pane. See Figure 7-1 for an example.

Recommended Users should be able to do a range select using Shift +Click or by rubberbanding objects within a view.

Required If the user does a Ctrl +Select, the selection state of the item should toggleto on if it was not previously selected or toggle to off if it was previouslyselected and the selection state of other items within the window areunchanged.

Required Child windows and copies of application windows should have their ownselection lists that do not affect selections in the parent window.

NOTE Child windows are windows which present a single view that wasoriginally presented in the presentation manager used for accessingmultiple views. Copies of the window refers to duplicate windows thatinclude all views within the parent window, not just a single view.

Recommended When the user makes a copy of a window or moves a view into a childwindow, the selections in the current and new window should beunaffected.

Chapter 7 233


Recommended Users should be able to select items with the keyboard by pressing theSpace Bar or Enter key when the item has keyboard focus.

Recommended When an item is selected, it should be shown as selected in both theresults pane and in the scope pane if it appears in both.

Required Any currently-selected item(s) visible should be marked by a selectionindicator or by a selection toggle:

• In a native UNIX or Windows NT operating system application, theselection indicator is one defined by the operating system.

• In a JAVA application or applet, the selection indicator should bedefined by the system color variables indicated below:

• The text for the selected item should be set to “activeCaptionText”.

• The highlight surrounding the selected item should be set to:“activeCaption”.

See Chapter 2, “Web Applications,” for more information on the use ofcolors in Web applications.

• In an HTML application, the selection indicator should be a block ofcolor (0x c0c0ff) surrounding the item’s label (see Chapter 2, “WebApplications,” for more information on the use of colors in Webapplications).


• A radio button, if all items in the scope pane are mutuallyexclusive.

• A check box, if multiple selection of items is allowed.

Affects of Navigation on SelectionNavigation within the application has the potential for affecting theusers selections. The following guidelines must be adhered to by all HPOpenView Applications.

See also guidelines for “Multiple Selection Across Views in a Window” forguidelines related to navigation.

Required Expanding and contacting items in the scope pane should have no affecton the selection list.

234 Chapter 7


Required Users should be able to change the visible view without affecting theselection list by:

• Use of a navigation tab to access views marked as “Keep Accessible”

• Use of a find or locate mechanism to open a new view in the window.

Required Single clicking on an item in the scope pane to navigate, should clear allexisting selections, select the item the was clicked on and cause theresults pane to show a view associated with the item.

Required Double clicking on an container object in the results pane should causethe view associated with the container object to be displayed in theresults pane. The scope pane should change so that the object that wasdouble clicked is visible and has a location cursor or open indicatorassociated with it. Double clicking should have no affect on the selectionlist.

Items that were selected before the double click should remain selected.

Multiple Selection Across Views in a WindowUse of the scope pane to navigate has an affect on selections. Typicallyselection in a scope pane clears all selections in the results pane. Extraimplementation and user effort is required to allow users to be able to domultiple selection across views within a window.

To select multiple objects on separate views of the same window, the userhas various alternatives depending on what functionality has beenimplemented into the presentation manager:

• If the application has provided capabilities for multiple selection inthe scope pane, the user can expand the hierarchy and useCtrl +Select to select the desired objects in the scope pane. See“Multiple Selection in the Scope Pane” for guidelines related to thisapproach.

• If the application has provided a multiple-view selection list, userscan use Ctrl +Select to select multiple items in the results pane andCtrl +Select to navigate in the scope pane without changingselections in the results pane. See “Multiple Selection Across ResultsPanes” for guidelines related to this approach.

Chapter 7 235


Multiple Selection in the Scope PaneThe following guidelines are only applicable if an application with ascope pane window provides multiple selection across views and allowsusers to make multiple selections in the scope pane.

Required When the user does a single selection of an item in the scope pane tonavigate to a new view, this selection should clear the selections in theresults pane unless the user does a Ctrl +Select .

Required Users must be able to use Ctrl +Select in the scope pane as well as theresults pane to toggle the selection state of the item under the pointer.

Required Expanding and contacting items in the scope pane should have no affecton the selection list.

Recommended When an object or item (that is, message) is selected it by a Ctrl +Selectin the results pane, it is shown as selected in the scope pane and as wellas in the results pane if it is visible in both.

User testing has shown that users want to be able to see a list of theirselections when they are making multiple selections across differentviews. If multiple selections are allowed in the scope pane, users want tosee all of their selections in the scope pane.

Required When the user does multiple selection with Ctrl +Select, the selection listmust consist of all selected objects or items in the window, regardless ofwhether they are visible or not.

236 Chapter 7


Figure 7-1 Selection List for Scope Pane that Allows Multiple Selection

Required Selections in child windows that are reattached to the parent windowshould be maintained and the selections should be added to the selectionlist in the parent window.

For example, a user places view “B” in a child window. The user thenproceeds to select 3 objects in view “A” in the parent window and 2objects in view “B” in the child window. While the windows areseparated, the parent windows selection list consists of three items andthe child windows selection list consists of 2 items. If the user reattachesthe child window to the parent window, the selection list in the parentwindow will consist of 5 items (3 in view “A” and 2 in view “B”).

Multiple Selection Across Results PanesThe following guidelines are applicable if an application with a scopepane window provides multiple selection across views and users can onlymake a single selection in the scope pane.

Chapter 7 237


This approach is applicable to HP OpenView applications that plan tointegrate into Microsoft’s Management Console (MMC), however, theMMC does not provide support for multiple selection across views shownin the results pane.

Required When the user does a single selection of an item in the scope pane tonavigate to a new view, this selection clears the selections in the resultspane unless the user does a Ctrl + Select.

Required When an object or item (that is, message) is selected it by a Ctrl +Selectin the scope pane all selections in the scope pane are removed, theselections in the results panes are maintained. The scope pane will showthe selected object with a location cursor or an open indicator but not aselection highlight. The results pane will show a view associated withthe item in the scope pane.

NOTE Ctrl +Select in the scope pane should not select the object that is onlybeing used for navigation. To have this object selected would requireusers to take extra steps in order to obtain the selection list that theywould want to use. That is to remove the scope pane object from theselection list, users would need to use Ctrl +Select to deselect the object.

Required All of the selected objects in the window are listed in a user accessibleselection list. The selection list may be in a separate dialog box.

User testing has shown that users want to be able to see a list of theirselections when they are making multiple selections across differentviews. Without this capability it becomes difficult for users to accuratelymake their selections. .

When the user does multiple selection with Ctrl +Select, the selection listmust consist of all selected objects or items in the window, regardless ofwhether they are visible or not.

Required Selections in child windows that are reattached to the parent windowshould be maintained and the selections should be added to the selectionlist in the parent window.

For example, a user places view “B” in a child window. The user thenproceeds to select 3 objects in view “A” in the parent window and 2objects in view “B” in the child window. While the windows areseparated, the parent windows selection list consists of three items and

238 Chapter 7


the child windows selection list consists of 2 items. If the user reattachesthe child window to the parent window, the selection list in the parentwindow will consist of 5 items (3 in view “A” and 2 in view “B”).

Recursive or Group SelectionUser performance in management tasks can be enhanced by allowingrecursive selection in which all of the items within a container object areselected at the time the container object is selected. This allows users toselect multiple items with a single action and then take desired actionson the selected set of objects.

OpenView Style supports two types of recursive selection:

• Recursive selection in a tree list with check boxes.

• Group selection for container symbols.

Recursive Selection In a Tree List with Check BoxesTree Lists with check boxes allow users to select objects at differentlevels in the hierarchy. This type of selection allows the selection to beinherited by objects lower in the hierarchy. Users should be able to makeselections at each level in the hierarchy.

The following guidelines are applicable only to applications that providerecursive selection in a tree list with check boxes.

Required If the user selects an item at a higher level in the hierarchy, all itemscontained within the higher level item should be marked as selected (forexample, black check mark in the associated check boxes).

Required When the user has selected a subset of items beneath a higher level item,the check mark in the check box of the higher level item should be lightgray instead of black to indicate that the item is partially selected.

The selection of a subset of items can be accomplished by directlyselecting some of the lower level items or by deselecting a subset of lowerlevel items that under a previously selected higher level item.

In Figure 7-2 below, the left most graphic shows what the tree would looklike with no selections. If the user directly selected “HP-UX”, the higherlevel item “Nodes” would be shown as partially selected, see the graphicin the middle. As is shown in the right most graphic, if the user directly

Chapter 7 239


selected “Denver” the lower level items under “Denver” wouldautomatically be selected and higher level items in the hierarchy wouldbe shown as partially selected.

Figure 7-2 Visual Cues for Recursive Selection

Recommended If it is important to distinguish items where selection is inherited ascompared to items that are directly selected, this should be indicated byvisual cues.

Required Clicking on the check box or on the icon to make the item part of amultiple selection should not affect the position of the selection cursor orlocation cursor if the tree list is presented in the scope pane.

Group Selection for Container SymbolsIn the OpenView management environment there are many containersymbols that are of interest to the user as an object and which containother objects. For example, a network is a container for computers,connectors, and network devices but it also can be viewed as a object forwhich the user wants to obtain and monitor data. A computer is acontainer for software, interface cards, etc., and it is also a specific devicethat users want to manipulate.

To allow flexibility to accommodate user needs, containers should allowusers to easily:

• Select the container object without selecting the objects containedwithin.

• Select all of the objects contained within the container.

240 Chapter 7


Required A single click on the container symbol should select of the containerobject without selecting the objects contained within it.

Keyboard equivalents for selection by a single click should also beprovided.

Recommended A pop-up menu item should be provided for selecting of all of the objectscontained within the container symbol. The menu item should be labeled“Select Grouped Items”

Recommended When objects are selected by selecting the container, the selection listshould either list all lower level items that have been selected or providea visual cue associated with container item so that it can bedistinguished from items that were not selected via a group selection.

Recommended When objects are selected with a group selection, menu items executedon the group should act on the subset of items in the group to which theyare applicable. Menu item graying should be disabled when a groupselection is in effect.

Selection Lists in Applications Integratinginto Presentation ManagersMany applications integrating into presentation managers integratetheir functionality as menu items or toolbar buttons that result in thepresentation of a separate window. These separate windows are referredto as “tools.” A single application may integrate multiple tools into apresentation manager.

Recommended If a tool requires selections and is accessed from a menu or toolbar in anobject presentation manager, the tool should use selection list from theobject presentation manager and allow the user to set or change theselections within the tool.

Recommended If a tool that is launched from a presentation manager and takes itsselections from the presentation manager, it should provide a means forthe user to determine what selections the tool is using (that is, a controlthat displays the current selections, or the name of the selection in thetitle bar).

Recommended If a tool can act on only a single selection, the selection should bedisplayed ion one of the following ways.

Chapter 7 241


• Selection in Text Field (if users can change the selection)

Use of a single line text field that displays the current selectionminimized the use of display space while allowing users to modify theselection.

• Selection in Title Bar

If users cannot change the selection from within the application,provide the name of the selected object in the title bar for the window.See “Title Bar” in Chapter 9 for guidelines.

Recommended If an application can act on multiple objects, allow users to access andview the list of selections.

If applicable, users should be able to view all possible selections and beable to differentiate active selections from inactive selections.

Providing Access to HP OpenView WindowsSelection List

Recommended If the application or tool is implemented using the OVw API and it usesthe HP OpenView Windows selection list, provide users with amechanism for accessing the HP OpenView Windows selection list onceyour application is started.

• The application involves the manipulation of different sets of objectsused in different capacities.

For example, in a software distribution tool that requires the user toidentify a list of nodes that will receive software and the server thatwill be used for the update, the user could use the HP OpenViewWindows selection list to specify the target nodes before theapplication is launched. Once the tool is running, the user could usethe HP OpenView Windows selection list to select the server node.

• Successful completion of the user’s task requires re-running theapplication with a different set of selected objects.

For example, a diagnostic tool indicates that there is a configurationdiscrepancy between a selected node and one or more nodes that werenot previously in the tool’s selection list. To isolate and fix theproblem the new nodes must be in the selection list.

• After running the application with one set of objects, the user wantsto re-run the application with a new set of objects.

242 Chapter 7


For example, the user may use a tool to monitor a variable on asystem, and then decide to monitor that variable on a differentsystem.

Modifying the HP OpenView WindowsSelection ListApplications can modify the HP OpenView Windows selection listthrough the OVw API. Applications have the ability to select anddeselect objects. The selection and deselection of objects needs to be donewith care as users expect to have control over the selection list andchanges to the selection list need to be consistent across applications.Modifying the selection list in a manner that is not anticipated by theusers could lead to user confusion and errors.

Required Applications other than NNM should only modify the Open ViewWindows selection list based on an explicit user request through a menuitem or a push button.

Required If an application integrated into NNM is going to modify the selectionlist, it should add or remove items from the selection list only under thefollowing three conditions:

• Items are added or dropped from the selection list in conjunction withuser actions that the user will associate with selection.

For example, the user selects a grouping symbol and all objectscontained within the grouping are added to the selection list, and thegrouping symbol is removed from the list.

• Items are dropped from the selection list in response to a user’s choicein a confirmation message.

For example, the user selects a number of objects and tries to executean action on them. Because the user has permission to take thespecified action only on a subset of the objects, the user is presentedwith a confirmation message. In the confirmation message, the user isgiven the choice of deselecting objects for which he does not havepermission and then proceeding with the action, or cancelling therequested action.

• Items are added to or dropped from the selection list and a message ispresented to the user, notifying him of the change.

Chapter 7 243


For example, the user selects a number of systems and tries toexecute an action on them. Some of the systems cannot be contactedto make the user-requested change. The change is made on thosesystems that were contacted. The user is then notified to indicate thatsystems for which the change was made were removed from theselection list. The current selection lists contains only those systemswhich could not be contacted. This will allow the user to take anynecessary actions on the remaining systems without the need tolocate and select them.

244 Chapter 7

Object Selections, Grouping, and Drag and DropGroups

GroupsGroups are sets of objects and/or other groups. Groups can be defined byapplications or by end users. Groups can occur in any context. They havea variety of uses including:

• Setting up security.

• Allowing a user defined hierarchy of objects and relationships.

• Allowing attributes or associations of the group to be applied to newgroup members when they are initially added to the group.

• Grouping objects for viewing.

• Grouping objects for selection:

• Allowing users to act on all members of the group by selecting thegroup.

• Allowing users to act on an applicable subset of the group byselecting the group.

Guidelines for GroupsThere are three different types of groups that can exist in OpenView:

• Rule-based groups

Rule based groups are groups in which group membership can bedefined through the specification of a rule. Rule specification forgrouping is similar to specifying a query on the objects in the database. All of the objects identified as a result of the rule are membersof the group.

The rule-based groups are dynamic. The advantage to the user is thatthey can be defined once and members are automatically added anddeleted from the groups based on the rules of membership. Theapplication of the rules for changing group membership can be doneimmediately as a result of any change in the environment,periodically on schedule, or based on a user request to update groupmembership.

• Identification-based groups

Chapter 7 245


Identification-based groups are defined by the direct identification ofgroup members. As a result these groups are static. Membership onlychanges based on a direct action of the user to add members or deletemembers.

• Mixed Groups

Groups that are defined to have both a rule and to have a list ofidentified members are partially dynamic and partially static.

Recommended Membership in a rule based group should be dynamic and membershipshould change as new objects are added and removed from as thenetwork and system environment.

Recommended If membership in rule based groups cannot be made dynamic, usersshould be able to specify a schedule for periodically updating the groupsand users should be able to update group membership on demand with asingle action, (for example, menu item “Refresh Group Membership”.

Recommended When rule based grouping is supported, users should be able to access apull down menu item to create the group and specify the rule that will beused for identifying group members.

Recommended When identification based grouping is supported, users should be able tocreate identification based groups by selecting a number of objects andthen accessing a pull-down menu item to create a group or by draggingand dropping objects into the group.

Required Membership in identification based groups should not change unless theuser specifically adds or deletes members.

Recommended Users should be able to set properties for the group and have theseproperties propagated to all members of the group. When applicable,users should be able to overwrite properties inherited from groupmembership and to specific more specific properties for lower levelgroups and objects.

Recommended The property boxes associated with groups should include:

• Name

• Description

• Rule (rule based or mixed groups)

246 Chapter 7


• List of Group Members (optional)

• Associations related to the group. For example:

• Actions periodically applied to all group members.

• Properties inherited by group members.

Recommended To help users differentiate group symbols from other container symbolswhich do not provide inherited properties and solicitations, it isrecommended that container objects that are primarily intended forpropagating properties and actions on groups of objects should be containthe word “Group” in their label.

Required When presented in the scope pane, groups that contains other groupsmust have a expansion control associated with them. The presentation ofa “+” or “-” in the expansion control is dependent on whether thehierarchical listing of the group is expanded or collapsed. If the userselects a group from the scope pane to open it, the contents of the groupare presented in the results pane of the window.

Recommended A single click on the group symbol in the scope pane should cause theresults pane to present a view associated with the group. The mosttypical view associated with a group would be a view showing themembers of the group.

Recommended If the members of the group are not presented in the default viewassociated with a group, users should have a simple mechanism forrequesting a listing of group members.

Recommended The group symbol should allow propagation of status from the objectscontained within the group.

Recommended In a tabular presentation format, groups should be represented byhaving the name of the group in the first column of the table. Otherinformation will be dependent on the context in which the group iscontained. Opening up a group that is in a tabular format should resultin the presentation of the members of the group in a tabular format.

Recommended In a form presentation format, the properties of the group shouldpresented when the group is selected in the scope pane.

Chapter 7 247


Groups and SelectionFor guidelines on selecting groups and group members, see “GroupSelection for Container Symbols”.

248 Chapter 7

Object Selections, Grouping, and Drag and DropDrag and Drop

Drag and DropHP OpenView’s drag and drop supports the user guided approach tomanagement and uses an object-action paradigm. Users can dragsymbols or table entries that represent objects and drop them on droptargets within and across applications. An object action paradigm allowsusers to drop objects onto other objects or to drop objects onto actions.Dropping of actions on to objects is not valid in the object-actionparadigm.

HP OpenView applications can provide default drag and drop forgraphical views, tabular views, executable symbols and explodablesymbols or containers. Generally if the user does a drag operationwithout a modifier key, the action is interpreted as a move. If the userdoes a drag operation while pressing the Control key the action isinterpreted as a Copy operation. If the user does a drag operation whilepressing the Shift key, the action is interpreted as a Copy.

• Copy operations affect the dragged object or the drop target, but notthe view in which the dragged object was originally located. Generallythe copy operation places a copy of the dragged symbol or table entryat the drop target without removing the symbol/table entry from itsoriginal location.

• A move operation must place a copy of the dragged symbol or tableentry at the drop target and then remove the symbol or table entryfrom its original location.

Visual Cues for Drag and DropUsers should be provided with visual cues during drag and dropoperations so that they know whether the operation will result in a copyor a move. They also need visual cues to indicate when a drop operationis not allowed.

Recommended The visual cue for a copy operation is a + sign associated with the pointerwhen the object is being dragged over a drop target that would result in acopy.

Recommended The visual cue for a move operation is the pointer when the object isbeing dragged over a drop target that would result in a move.

Chapter 7 249


Recommended When an object is being dragged over a drop target that will not allow adrop, it is recommended that the user be presented with a “not sign” inassociation with the pointer.

Recommended Applications should be implemented to “do the right thing” regardless ofhow the user initiated a drag operation.

Applications that change from the typical drag and drop behavior shoulddefine their drop target behavior to be consistent with the most likelyand or desirable operation from the user’s perspective. For example:

• If a user drags a symbol or table entry to a location that causes someconfiguration change to the dragged item, the original symbol or tableentry should not be removed unless removal is consistent with theconfiguration change.

• If a user drags a symbol or table entry to a location that causes anaction to be initiated that is not a configuration change (that is, graphcollected data), the symbol or table entry for the object should remainat its original location after the action is completed.

• If a user drags an symbol for an activity from one process outline toanother, the activity should remain at its original location after theaction is completed.

For guidance on user appropriate drop target behavior, see “Guidelinesfor Specific Types of Drop Targets”. Note: These guidelines are intendedto aid the user as some users may not know the key sequence to initiate acopy instead of a move operation and users may not understand inadvance the particular drag and drop operation that is required forspecific drop targets.

Guidelines for Specific Types of Drop Targets

Views as Drop TargetsViews are presented to users in the results pane of presentation managerwindows. A view consists of the data to be presented to the user and thepresentation format for that data.

When drag and drop is supported, users can drag objects from otherviews or the scope pane and drop them into a tabular or graphical view.

Recommended The application should create any new symbols or table entries requiredat the drop target as a result of the drag and drop operation.

250 Chapter 7


Recommended When an object is dropped into a view, it should automatically change tothe presentation format that matches the format into which it wasdropped.

Recommended If the drop target is a graphical view and automatic layout is off, thedropped symbol should remain at the location where the user dropped it.

Recommended If the drop target is a graphical view and automatic layout is on, thedropped symbol should remain at dropped location for 3-5 seconds andthen be moved to a position that is consistent with the layout algorithmand which is as close as possible to the location where the user droppedthe symbol.

The automatic layout algorithm should never cause the symbol to bemoved to a location that is not visible in the current viewing area of thewindow. If the automatic layout algorithm would cause the symbol tomove to a location that would be out of the visible display space, thewindow should be automatically scrolled so the dropped object is visible.

Recommended If the drop target is a tabular view, the dropped entry should remain atthe location where the user dropped it. The entry should beautomatically selected to aid the user in identifying it.

Recommended If the user takes an action to sorting the information in the table, thedropped entry should be placed in a sequence based the sortingalgorithm specified by the user. The entry was selected, it should remainselected to aid the user in identifying it.

Recommended If the dragged object is a table entry and the drop target has differenttable entries than the view that was the source of the drag operation, thetable entry for the dropped object should automatically be modified to fitthe table in which the object was dropped or the drop target should rejectthe dropped entry. If the name field is the only field that is applicable forthe dropped object, all other columns in the table should be blank or havea dash in them.

Recommended If the user drops an executable symbol into a view, the executable symbolshould be placed in the view if it has the characteristics that are requiredfor that view. The action associated with the executable symbol shouldnot be executed.

Recommended If the dropped symbol or table entry does not have the characteristicsthat are required for the view:

Chapter 7 251


• The drop operation should result in a presentation edit where thedropped object(s) is presented in the user plane for the view.

or

• The drop operation should be rejected and the symbol or table entryshould be restored to its original location.

Container Symbols as Drop TargetsContainer symbols (also known as explodable symbols) are presented inthe scope pane of windows and in graphical views of data presented inthe results pane. The following guidelines apply to container symbols asdrop targets:

Recommended When a dragged item is dropped on to a container symbol, the itemshould by default be propagated to the child view of that symbol.

This behavior can be modified by specifying how far down the hierarchythe symbol will appear. In some cases, symbols which are dropped on acontainer symbol may appear in views at various levels below the droptarget symbol. For example, when a symbol representing a user isdropped on a symbol representing a computer system, the new usersymbol might actually show up in a user view that is two levels below thecomputer system’s view.

Recommended If the user drops an executable symbol on a container symbol, the actionassociated with the executable symbol should not be executed. Insteadthe container symbol should be treated it as if it were an object (forexample, dropped into the child view) or the drop operation should berejected.

Recommended If the user drops a group symbol on to a container symbol, the groupshould be treated as if it were a single object and the symbol for thegroup should be passed on to a child view.

Recommended The rules for propagating dropped symbols/table entries to lower levelviews must be consistent across drop targets of the same type and makesense given the type of item being dragged and the logical hierarchy ofviews.

Recommended Dragging a symbol or table entry to a container symbol in the scope panehas the same results as if the symbol were dropped the container symbolin the results pane.

252 Chapter 7


Recommended If the dropped symbol or table entry does not match the characteristicsthat are required for the any of the views under the compound symbol:

• The drop operation should result in a presentation edit where thedropped object(s) is presented in the user plane for the child viewunder the symbol.

or

• The drop operation should be rejected and the symbol or table entryshould be bounced back to its original location.

Leaf Level Symbols as Drop TargetsLeaf level symbols are typically presented in the presented in views inthe results pane. Leaf level symbols may also be presented in the scopepane.

When a dragged item is dropped on to a leaf symbol, the dropped objectcannot appear in a child view. By definition, leaf level symbols are onesthat do not contain other objects. However leaf level symbols do haveattributes or properties with which the dropped object can be integrated.

Recommended If the user drops a object symbol, group symbol or table entry on to a leaflevel symbol, the drag operation should result in a change in theattributes associated with the leaf level symbol or the drop operationshould be rejected.

Recommended If a executable symbol is dropped on a leaf level symbol, the dropoperation should be rejected.

Executable Symbols as Drop TargetsExecutable symbols are symbols that represent an action.

Recommended Dragged items which are dropped on an executable symbol should betreated as the selection list for the actions initiated by that executablesymbol.

If the dropped symbol(s) or table entries do not match the capabilitiesrequired for the executable, the operation should be rejected for all itemsthat are dropped on the symbol. The symbol(s) or table entries should bebounced back to their original locations.

Chapter 7 253


Recommended If the user uses the pop-up menu to select all items in a container andthen drags and drops the container symbol on an executable symbol, theobjects contained within the group should be used as the selection list forthe actions initiated by that executable.

Recommended If an executable symbol is dropped on an executable symbol, the dropoperation should be rejected.

Drop Targets that Cause a Change in theInstrumentation SpaceIn some instances, the result of a drag and drop operation may be asignificant change to real underlying data for the dragged object or thedrop target. This might happen, for example, when dropping the itemresults in editing of a configuration file or a change in topologicalinformation for the objects involved.

Recommended When a drag operation will result in a change in the underlyingmanaged objects, the application should help which explicitly describesthe instances when an instrumentation change will occur through use ofdrag and drop.

Recommended If the data change is not obvious given the type of dragged item, or thedrop target behavior is severe or unrecoverable, the application mustprovide a warning dialog (after the drop) which permits the user tocancel the action.

Use of HP OpenView Window’s Drag and DropHP OpenView Windows provides support for drag and drop on the UNIXoperating system. When HP OpenView Windows’s drag and drop is usedeach application defines what semantic actions will occur at a givendrop-target. These actions can be strictly specified depending on the typeof item dragged.

Applications can specify drop-target behavior on an instance basis byusing the OVw API.

If the OVw API’s is used to specify drop target actions, developers mustensure that all objects with the same symbol types within a particularview maintain the same drop target behavior.

254 Chapter 7


Recommended Applications that provide drop-targets should document theirregistration files and application callbacks related to drag and drop. Thiswill allow other applications to enable their symbols to be dropped on thefirst applications drop-targets.

Drop Target HelpFor HP OpenView Windows drag and drop, drop target help is providedto users upon pressing F1 when the pointer with the dragged item is overa registered drop target location or on some platforms as a result of theuser resting the dragged object over the drop target for a minimum of 2seconds.

Recommended Drop target help should be provided for all application registered droptargets that have behavior that is different than the default.

Recommended At a minimum, drop target help should include a summary of any specialactions which would occur as a result of dropping items at this location(that is, data changes).

Keep in mind that the overall purpose of drop target help is to providethe user with enough information to decide whether they want tocontinue with the drop they’ve initiated or to identify what they can do ifthe items they are dragging are not permitted to be dropped at thatlocation.

Executable Symbols with Explodable AppearanceHP OpenView Windows allows applications to create executable symbolsthat have the appearance of explodable symbols.

Recommended In cases where the symbol appearance of an executable has beenchanged to indicate a compound (explodable) symbol, you must treat thedropped items in the same manner as that described for container(explodable) symbols.

255

8 Visual Presentation

256 Chapter 8

Visual Presentation

This chapter presents design and style guidelines for the use of visualpresentation capabilities, including:

• Status and events

• Highlighting symbols

• Symbol alerts

• Text annotation

• Flashing symbols

• Transparent symbols

• Executable symbol appearance

• Partially filled connection symbols

Chapter 8 257

Visual PresentationGeneral Guidelines

General GuidelinesOveruse of visual cues in applications will result in visual clutter andwill interfere with the effectiveness of these visual cues.

Recommended To enhance the effectiveness of visual cues, it is recommended that:

• Cues be used sparingly so that they do not create visual clutter.

• Cues not be used arbitrarily to add excitement to the user interface(for example, decorative use, aesthetic additions).

• Cues be used only for important conditions or states that requireoperator notification.

• The use of visual cues be consistent throughout a given context. Agiven visual cue should not be used for different purposes within acontext.

258 Chapter 8

Visual PresentationNotification of Object Conditions

Notification of Object ConditionsMany applications provide condition information on the managedobjects, network, systems or services. In HP OpenView, applications cannotify users of the condition information through the following methods:

• Status coloring of the class shapes associated with objects.

• Providing text annotation on symbols.

• Presenting symbol alerts in association with the object symbols.

• Generating alarms or messages indicating the condition of managedobjects with messages.

• Logging the conditions to a file.

Visual Cues versus Alarm MessagesIf an application detects many different conditions for an object, theapplication should not attempt to present all of these conditions in theform of a visual cue in an iconic view of objects. For example, applicationsthat support SNMP traps or CMIP events have the choice of informingthe user about the condition of an object through either an alarm sent toa message browser or by providing visual cues on the symbolsrepresenting the objects.

Recommended Only the most important object conditions should be presented throughvisual cues in iconic views.

Recommended If an application provides alarms or visual cues for communicating thestate of the network, systems or services, the application should allowusers to configure the use of visual cues and alarms.

Examples of variables to be configured are:

• Conditions that result in presentation of symbol alerts.

• Conditions that result in text annotation of symbols.

• Conditions that determine status color changes.

• Conditions that generate alarms or messages.

• Conditions that are merely logged.

Chapter 8 259


Use of Status ColorsStatus color is the color presented in association with objects to provideinformation on the operational or administrative status of the objects.The most common use of status colors is in iconic view of objects. In theseviews, the status color is displayed in background of class shapes ofobject symbols and is used for drawing connection symbols. HPOpenView has defined two different sets of status colors, operationalstatus colors and administrative status colors, see Table 8-1.

Recommended Status color should be used as the primary visual cue for summarizingthe operational or administrative status of a managed object presentedin an iconic view.

Recommended The summarized state of an object should be based solely on importantconditions about which the user would want to be notified immediately.

Required Status color must not be used to notify users of a specific condition (forexample, system rebooting) or to indicate what type of action a usershould take with regard to the state of an object. This detailedinformation should be provided through other mechanisms (events,symbol alerts, text annotation, and others).

Required Users should be able to configure the colors used for status color.Approximately 7% of the users are likely to be color blind. The ability toconfigure the colors used for status will allow color impaired users tochoose colors that they can differentiate in terms of brightness whenthey are unable to differentiate the hues.

Required The default status colors used by applications must match the defaultstatus colors defined for HP OpenView.

260 Chapter 8


Table 8-1 Default Status Colors Defined for HP OpenView

Source of Status InformationStatus coloring of symbols can be based on the a single attribute of amanaged object, multiple attributes of a managed object, or on attributesof multiple managed objects. The choice of what contributes to the statusinformation will determine how useful the status information is to theuser.

Recommended The status coloring of objects that contain other objects should be basedon the status of all contained objects that are relevant to the currentcontext.

Example

In a context for file server management, the status of the server shouldbe based the server’s file systems, network card, processes related toserving the file systems and connecting to the network. The status of theprinters on this system and processes related to these printers shouldnot contribute to the file server’s status coloring.

StatusName Color RGB Value Status Type

Critical Red 255, 000, 000 Operational

Major Orange 155, 128, 000 Operational

Minor Yellow 255, 255, 000 Operational

Warning Cyan 000, 255, 255 Operational

Normal Green 000, 255, 000 Operational

Unknown Blue 000, 128, 255 Operational

Unmanaged Off White 255, 255, 204 Administrative

Disabled Brown 100, 000, 000 Administrative

Testing Tan 255, 191, 102 Administrative

Restricted Light Pink 255, 128, 255 Administrative

Chapter 8 261


Recommended The status coloring of leaf-level objects that do not contain other objectsshould be based on the status of object attributes that are relevant to thecurrent context.

Example

In a context for file server management, the status of the network cardshould be based on whether the network card is functional andconnecting the server to the network.

Status Source in NNMHP OpenView Network Node Manager (NNM) provides a choice statussources for the setting status of status colors by applications. The statussource choices are by object, by symbol, or by compound status. Thefollowing guidelines should be used by applications integrating intoNNM.

A single real world object can be acted on and monitored by multiplestatus setting applications. Users may need and want to have statusinformation from all of the different applications.

It is undesirable to have more than one application setting status on asingle symbol since it can result in applications changing the status colorback and forth as their polling alternates.

To avoid this conflict, follow these guidelines.

Recommended Only the owner of a symbol should set its status source. The owner of asymbol is determined as follows:

• An application that creates a symbol is its owner.

• For a user-added symbol, the first application that accepts the symbolinto the application plane is its owner. The application that createdthe submap to which the symbol is added is given preference overother applications if it accepts the symbol into the application planeat the time the symbol is added.

• The application designated as the owner of a symbol appears first inthe list of interested applications found in the symbol informationstructure for that symbol.

262 Chapter 8


Recommended Use object status source for the symbols representing low-level,non-compound objects that your application is responsible for and thatno other application should be setting status on (for example, an IPinterface card).

Recommended Object status source should only be used by the application that createdthe object in the HP OpenView Windows database (ovwdb).

Recommended Compound status is appropriate only for compound objects that havepersistent child submaps. The number of submap levels that anapplication requires to be persistent should be limited. Compound statusshould be dependent on the persistence of only the child submap underthe symbol.

Recommended If an application wants to provide status information on objects thatwere created by other applications in the HP OpenView Windowsdatabase, the application should create a new symbol for the object andset status by symbol. Status should be set by symbol only if theapplication created the symbol.

Further information about status and events can be found inHP OpenView Integration Series: OpenView Windows Developer’s Guide.

Chapter 8 263

Visual PresentationSymbol Alerts

Symbol AlertsSupport for symbol alerts is only provided for applications integratinginto NNM on HP-UX and Solaris. All applications may use symbol altersbut may need to implement them on their own.

Symbol alerts are dynamically displayed graphics that are linked tosymbols used to represent objects or connections. They are used to notifyusers of alarms, critical events, or of changes in status where a singlesymbol may have multiple attributes for which status is set. Symbolalerts may be presented in the scope pane of a window or the in theresults pane. Symbol alerts in the results pane are not scaled and cannotbe occluded by object symbols, therefore, they provide a very powerfulvisual cue to the user.

Figure 8-1 Symbol Alert in the Results Pane of a Window

Figure 8-2 Symbol Alert in the Scope Pane of a Window

264 Chapter 8


When to Use Symbol Alerts

Required If symbol alerts are used, their primary purpose should be to notify theuser of an important event or condition that requires user attention andto allow the user to take quick action on the condition that led to it.

Required Symbol alerts must not be used arbitrarily to add excitement value(decorative, aesthetic additions) to the display.

Required Use symbol alerts to notify users of alarms or conditions with a severityof minor, major or critical only. Alarms with lower levels of severity mustnot have symbol alerts associated with them unless they have beenspecifically configured by the HP OpenView administrator.

Guidelines for Symbol AlertsConsistent use of symbol alerts will make them more meaningful tousers and will enable symbol alerts to better support user-taskperformance.

Required If symbol alerts are used, they should by default be presented at thehighest visible level in the object hierarchy:

• In the results pane symbol alerts should be presented on:

• Symbols for leaf level objects whose status caused the symbolalert.

• Symbols for objects that contain other objects whose statuscaused the symbol alert.

• In the scope pane, the symbol alert should be presented next to thehighest unexpanded level in the hierarchy that contains an objectwhose status caused the symbol alert.

Presenting symbol alerts at higher levels (for example, site or subnet)allows the user to minimize the number of symbols they are monitoringand to still obtain specific information about problems with objects atlower levels in the management hierarchy (for example, individualsystems or components within systems).

Recommended To allow symbol alerts to better meet user needs, the application shouldallow HP OpenView administrators to choose the level within thehierarchy at which the symbol alerts will be presented.

Chapter 8 265


Recommended The HP OpenView symbol alert graphics should be used for symbolalerts. The type chosen should have the status color that corresponds tothe severity of the event or condition.

Recommended Create new symbol alert graphics for notification only if the event orcondition is of a very special type and requires the user to recognize it asdifferent from the other notifications that they will encounter. See theThe Integration Series: HP OpenView Windows Developer’s Guide forinformation on creating new symbol alert types.

Recommended If there are multiple different alarms associated with a single object thatwould result in a symbol alert, adhere to all of the following guidelines:

• Display only a single symbol alert in conjunction with the symbol forthe object. The multiple alarms should all be associated with this onesymbol alert.

• Display the symbol alert with a severity that corresponds to the mostsevere alarm condition.

Example:

If there are two alarms associated with a given symbol alert, one withminor severity and one which is critical, the symbol alert should bered to show the critical severity.

• Use the pop-up menu associated with the symbol alert to provide theusers with a means of viewing all of the alarm conditions that led tothe symbol alert.

Recommended While the symbol alert is visible and has not been deleted, users can benotified about duplicate alarms by presenting a number to indicate thenumber of messages of the same type.

Required Once the condition associated with the symbol alert has been resolved,the symbol alert must be removed, whether or not the user hasresponded to the alert.

Required To enable quick user action on alarms associated with symbol alerts,double clicking on the symbol alert must do one of the following:

• Provide further information on the nature of the alert, and whatactions can be taken.

266 Chapter 8


• Execute an action that will allow the user to immediately respond tothe source of the alert.

• Result in the presentation of a view of the object whose conditionresulted in the symbol alert. This view should allow the user to takedirect action to fix the problem.

Example:

A symbol alert on a location icon opens a submap for the card draweron a switch. At this level users can identify the card with the problemand use the menu items to take action.

Recommended If a symbol alert has multiple alarms or multiple actions associated withit, it should provide a pop-up menu, see Figure 8-3.

Recommended The pop-up menu associated with symbol alerts should adhere to all ofthe following guidelines:

• The default action that would be executed by double clicking on thesymbol alert should be the first item in the pop-up menu.

• The pop-up menu should provide access to a textual messagedescribing the condition that led to the alert.

• The menu should provide access to actions that the user can take tofix the condition that led to the alert.

• The menu should provide access to views of the object whosecondition led to the symbol alert.

• If there are multiple alarms associated with the symbol alert, themenu should provide access to information on what the variousalarms are and should allow the user to chose the sequence of tryingto handle these problems.

• The menu should allow acknowledgment of the symbol alert.Acknowledgment of the symbol alert should cause the symbol alert tobe deleted and should prevent the display of additional symbol alertsresulting from the same or duplicate alarm conditions, whether or notthe problem was fixed by the user.

Chapter 8 267


Figure 8-3 Pop-up Menu Associated with Symbol Alerts

268 Chapter 8

Visual PresentationText Annotation for Symbols

Text Annotation for SymbolsThis feature is supported for applications on HP-UX and Solaris only.

Text annotations can be superimposed over object symbols, connectionsymbols and symbol alerts. When using text annotation strings, adhereto the following guidelines:

Required To minimize display clutter, text annotation on icon or connectionsymbols must be provided only through configurable parameters or as aresult of a user action.

• Users should be able to configure text annotation to be displayed onan ongoing basis as interesting events occur. For example, a systemsmanagement application could allow users to configure which eventsare automatically announced to the user through text annotation (forexample, system reboot, user added, file system down, IP addresschange).

• Users should be able to use menu items to request the display of textannotation on a single instance basis. For example, an applicationcould provide a menu item that allows users to display textannotation showing the bandwidth of a connection and the amount ofthe capacity that is available for use.

Required If your application provides text annotation through configurableparameters or as a result of user actions, it must provide a means forusers to turn off the text annotation.

• Users should be able to configure the application so that textannotation is not displayed on an ongoing basis.

• Users should be able to use menu items to clear text annotation on asingle symbol and on all symbols within the submap.

Recommended It is recommended that text annotation be provided in symbol alertspresented in the results pane.

The text annotation should give a brief indication of the nature of thealarm that has produced the symbol alert. This use of text annotation insymbol alerts does not require that you allow the user to control thepresentation of the annotation, but it should follow the guidelines forsymbol alerts.

Chapter 8 269

Visual PresentationHighlighting Symbols

Highlighting SymbolsOne of the visual cues defined for HP OpenView is the highlighting ofsymbols. Highlighting of an object symbol results in the inverse videoappearance of the symbol label. Symbol labels generally include blacktext on a white background. The label of a highlighted object symbolappears as white text on a black background. Highlighting of aconnection symbol is presented as the overlaying of the symbol with adistinctive color.

It is recommended that highlighting be used for the following purposes:

Recommended To help users visually locate objects identified in a locate operation(automatically handled by HP OpenView windows for applicationsintegrating into NNM).

Recommended To help users visually locate objects identified as a result of anapplication operation. For example, identify the client systems that willbe affected when the user disables a print server.

Recommended To help users visually locate connections or relationships that areidentified as a result of an application operation. For example, theidentification of a network path resulting from the Find Route menuitem.

Optional To guide users to objects in computer based training for an application.

Required Highlighting must not be used for conveying information about thestatus conditions for an object or for notifying users of alerts.

Recommended Each new access of a highlight command should replace the currentlyhighlighted items with a new set of highlighted items.

Required If you allow users to append new highlights to the list of highlighteditems, you must label the command “Add to Highlighted.”

270 Chapter 8

Visual PresentationFlashing Symbols

Flashing SymbolsDevelopers to cause symbols to flash, and to turn off this flashing. Ifflashing symbols are used in the application adhere to the followingguidelines:

Required Flashing should be used only for high severity conditions where usersmust handle the condition immediately; generally this is when thesymbol has a status of major or critical.

While useful for attracting the user’s attention, flashing can be annoyingand stress producing. If over used, this visual cue can interfere with userperformance.

Required If flashing symbols are used in the application, users must have a meansof configuring the application so that flashing is turned off.

Required Flashing must never be the only visual cue used to notify a user of a highseverity condition.

If flashing is turned off, your application must have another mechanismfor notifying users of the high severity condition; for example, statuscolor, symbol alerts, or text annotation.

Recommended If an application uses flashing symbols, it should provide menu itemsthat allow the user to acknowledge the condition and thereby turnflashing off for that particular symbol.

The pop-up menu associated with the symbol and the View menu in themenu bar are the recommended locations for this functionality.

Chapter 8 271

Visual PresentationTransparent Symbols

Transparent SymbolsWhen assigning symbols to objects, you can choose to present thesymbols with a class background shape or as transparent symbols thatdo not have a class background shape. Transparent symbols do notdisplay their background shape and status color as long as the objectassociated with the symbol has normal status. While in normal status,only the inside graphic is visible in transparent symbols.

For applications integrated into NNM, end users can override adeveloper’s setting for symbol transparency.

Use the following guidelines in determining if objects should bepresented with transparent symbols or regular symbols.

Recommended Transparent symbols should be used:

• In the tree list in the scope pane of presentation managers.

• In the results pane of windows where symbols are not resized belowminimum graphic size of 16x16 pixels.

In NNM, symbols are resized to sizes smaller than 16x16. When thesymbol goes below the minimum graphic size, the bitmap is replacedby an empty class shape. As a result, transparent symbols are notrecommended for use in the content area of applications based onNNM’s scaling algorithm.

Required Do not use transparent symbols in the following situations:

• As a specific visual cue associated with a condition or state in anobject other than normal.

The presence or absence of a background class shape is a very subtlecue and it is unlikely that users will attend to this cue.

In addition in NNM, users have the ability to override transparentsymbol appearance. If this visual cue is disabled, the application maynot function as intended.

• If the symbols being used will be presented on the same view(s) assymbols from other applications that use symbols with class shapes.

272 Chapter 8

Visual PresentationTransparent Symbols

The mixture of different types of symbols in the same view will beconfusing to users.

• If the view containing the object symbol will be resized to a pointwhere the graphic will no longer be visible.

The change from a graphic without a background shape to one with abackground shape with no graphic will be confusing to users.

• If users will need to differentiate between the different classes ofobjects to accomplish their management tasks.

The class of the object is visually represented by the backgroundshape. When transparent symbols are used the visual cue for theobject class is not available.

• If users will want to use drag and drop and the transparent symbolsare presented through HP OpenView Windows.

In HP OpenView Windows, the hot spot for the symbol is defined toinclude the space that would be occupied by the class shape. Symbolsfor objects can partially overlap. When the symbols are transparent,it is impossible for users to determine which symbol is on top. Thislack of visible symbol boundaries may cause users to make errorswhen dragging and dropping.

Chapter 8 273

Visual PresentationExecutable Symbol Appearance

Executable Symbol AppearanceBy default executable symbols in HP OpenView applications aresurrounded by a box that makes them appear as push buttons that theuser would use to execute an action.

For applications integrating with NNM, developers have the ability tospecify whether the visual cue for an executable symbol is present or not.End users have the ability to override the developer’s setting.

Recommended While executable symbols are allowed, it is recommended thatapplication provided functionality be provided through configurabletoolbar buttons, instead of through executable symbols.

Required If executable symbols are used, the symbols should be presented with thedefault executable symbol appearance (that is, box around symbol) if anyof the following are true:

• The executable symbol is being used to provide quick access toapplication functionality (such as the presentation of an applicationtool, graphed data, etc.).

• The intent is for users to execute actions on objects by dragging anddropping other symbols on to the executable symbol.

Recommended If executable symbols are used, the executable symbol appearanceshould be removed (that is, make the symbol appear explodable) if any ofthe following are true:

• The action of the symbol is to open an application created view.

• The symbol is intended to act as a container for lower level objectsthat are displayed when the user double-clicks on the symbol (forexample, double-clicking on the symbol leads to a list of the softwarethat is currently loaded on the system, the list provides a view with atabular format).

Required If the executable symbol looks executable it must act executable.

• Users should recognize the result of double-clicking on the symbol asthe execution of an action or command.

274 Chapter 8

Visual PresentationExecutable Symbol Appearance

• Objects dropped on to the symbol during a drag and drop operationmust be acted on as if they were the selection list for the executableaction.

Required If the executable symbol looks an explodable symbol (a symbol thatopens to show the view of the objects contained within it), it must actexplodable.

• Users should recognize the result of double clicking on the symbol asthe opening of a view or a submap into a container object.

• Objects dropped on to the symbol during a drag and drop operationshould be added to a lower level view and should be visible to the userwhen the symbol is opened.

Chapter 8 275

Visual PresentationPartially Filled Connection Symbols

Partially Filled Connection SymbolsFor all connection symbols with a width of greater than three pixels, youcan control the appearance of the connection symbol so that it appearsempty, partially filled, or completely filled.

By default the connection symbols presented through HP OpenViewWindows will appear completely filled (that is, percent fill equal to100%). Developers can dynamically change connection symbol fill to avalue between 0% and 100%.

Using HP OpenView Windows for creating partially filled connectionsymbols, developers can dynamically control:

• The percent of connection symbol fill from 0% to 100%.

• The primary status. Primary status is used to control the color usedto present the borders of the symbol and the amount of the connectionthat is filled; by default this is black (normal status).

• The secondary status. Secondary status is used to present the unfilledportion of the connection symbol; by default this is transparent. Thetransparent appearance is the “normal” status color for the secondarystatus. In setting the color for the secondary status, developers canonly specify the state associated with the secondary status. This stateis then translated into the appropriate color based on the status.

If the connection symbol has 0% fill, it will appear as having a border inthe primary color and it will be transparent and show the underlyingbackground between the two borders. If a connection symbol has 100%fill it will appear as single line or patterned line presented in the primarycolor. If a connection symbol has a percentage fill between these values(that is, uses partially filled connection symbols) and it is of sufficientwidth to display the differences, the connection symbol will appear tohave two different horizontally aligned areas, one for each of the statuscolors.

If partially filled connection symbols are used, adhere to the followingguidelines. These guidelines are intended to assure consistency in theway partially filled connection symbols are used and to help usersdevelop a meaningful conceptual model.

Required Partially filled connection symbols must only be used to provide userswith information on the status, use and available capacity of connections.

276 Chapter 8

Visual PresentationPartially Filled Connection Symbols

When defining percentage fill for the connection symbol:

Required The percentage fill should represent the percentage of the capacity inconnection that is currently being used.

Required The area displayed in the secondary status color should represent theamount of the capacity that is available for use.

Recommended When the line is down, the percent fill should be 100% to indicate thatnone of the capacity is available for use. The status color for theconnection should be consistent with the state (for example, critical).

Recommended The primary status color for a connection symbol should indicate thequality of the connection (for example, how much noise is on the line,how much data is being lost, if the connection is down).

Optional It is generally recommended that no status be applied to the emptyportion of the connection. However, if an application chooses to present astatus color in the “empty” portion of the connection, the statusinformation should be aimed at giving warnings about capacity.Generally this color should be transparent. As the connection startsrunning out of capacity, a limited set of status colors (for example,orange-major and red-critical) can be used to warn the user.

Users have difficulty in discriminating different widths of lines.Therefore, applications should not expect users to be able to identifydifferent fill percentages and act on them.

Recommended The number of different fill percentages used should be minimized; forexample, 0, 25, 50, 75, and 100 are recommended.

Recommended The manner in which connection symbol fill is used should be consistentacross all connection symbol subclasses within a class.

Recommended Consider providing a menu item that will display a numeric value for theused and/or available capacity for a connection. The results of this itemcould be presented in a dialog box or as text annotation on theconnections themselves.

277

9 Dialog Boxes and Controls

278 Chapter 9

Dialog Boxes and Controls

This chapter presents guidelines and recommendations for:

• Dialog box design

• Size of dialog boxes

• Fonts

• Help for dialog boxes

• Error handling and input validation

• Default values and default actions

• User interface controls

• Push buttons (command buttons in Windows NT)

• Options buttons (UNIX platforms only)

• Radio buttons (option buttons in Windows NT)

• Check boxes (check buttons in UNIX)

• Text fields

• Combination boxes

• Spin boxes

• Sliders and gauges

• List boxes

• Tree list controls

• Tables and grids

• Tab controls

• Scroll bars

Chapter 9 279

Dialog Boxes and ControlsDialog Box Design

Dialog Box DesignDialog boxes are used for requests for information from the user or tosupport user tasks that require detailed interaction from the user and donot lend themselves well to direct manipulation in your main applicationwindow. This section presents general guidelines for you to follow whendesigning dialog boxes for your application.

Title BarThe content of the title for dialog boxes will vary depending on thepurpose of the dialog box.

Recommended The title of dialog boxes should adhere to the conventions in Table 9-1.As in the title bar for windows, the application name in the title barshould be presented in abbreviated form. Include the <objectname> onlyif there is only one object. Include the <toolname> only if there aremultiple tools associated with an application. The <actionname> shouldbe associated with the menu item that led to the dialog box.

Table 9-1 Recommended Dialog Box Title Formats

FocusThe initial focus of a dialog box should be based on what actions arerequired of the user. Provide visual cues to guide users in their tasks; forexample, use the location cursor or the text cursor.

Usage Format

Message <objectname> - <appname>:<toolname>

Progress <objectname> - <appname>:<toolname> or<actionname>

Action (Command) <objectname> - <appname>:<actionname>

Object Properties <object> Properties

Application Options <appname>:<toolname>-<type> Properties

280 Chapter 9


Upon initial invocation of a dialog box, the following guidelines areeither required or recommended:

Required The location cursor should be in the first field the user is likely to modify.

Required If the location cursor is in a text field, the text cursor should be placed atthe most likely point of modification; the beginning of an empty field andthe end of a field already containing text.

Recommended Text cursors should not appear in every modifiable text field. Only onetext cursor should be visible at a time.

Recommended Use cursors to indicate the field that has keyboard focus, and providevisual cues to guide users in their tasks.If the choices available in a givenfield are dependent on the value assigned to a prerequisite field, then doone of the following:

• Place the prerequisite field above dependent fields to encourage usersto input data in the prerequisite fields first.

• Display only the prerequisite field and wait until the user assigns avalue to it before displaying the fields or options that are dependenton that value.

Menu Bars

Recommended Do not use menu bars in dialog boxes.

Fonts for Dialog Boxes and WindowsTo achieve maximum readability and consistency across applications,follow these guidelines for fonts in your dialog boxes and windows.

Size of Fonts

Recommended Whenever possible, use the font size chosen by users in their system levelfont specifications (that is, VUE, Windows NT operating system).

Chapter 9 281


Recommended When using a different font size than that set by the user’s environment,consider the effect of display size and resolution on the readability of thefonts. As display resolution increases (for example, 800 x 600 to 1280 x1024) the size of the characters presented in the display appear to shrinkin size.

• Test the readability of your smallest fonts on the smallest monitorwith the highest resolution that is anticipated to be used by yourcustomers (for example, 19 inch 1280 x 1024 monitor).

• Provide users with a means of changing the font size to a size thatwill better fit their needs.

Default Size for Dialog Boxes and WindowsApplications need to carefully consider the default size of the dialogboxes and windows that they present to the user. Because of theinteraction between display sizes, display resolution and the size ofdialog boxes and windows, it is possible to create windows that are toolarge to be presented in the user’s display or that are hard to use becausethe controls are too small. Consider the following guidelines whenchoosing the default size for your dialog boxes and windows.

As display resolution decreases (1280 x 1024 to 800 x 600) the size of adialog box or window appears to increase, and there is a correspondingdecrease in the amount of available display space.

As display size decreases at a given resolution (for example, 19 inch to 13inch monitor with resolution of 800 x 600), the amount of availabledisplay space decreases.

To assure an appropriate default size for your windows, dialog boxes andtheir controls, follow these guidelines.

Required Test the default size of the largest application windows on the smallestmonitor with the lowest resolution that is anticipated to be used bycustomers (for example, 13 inch 800 x 600 monitor). Make sure that thewhole window and all of its controls fit easily into the display. Make sureto test the application using a font size that will also be readable on thehighest resolution monitor used by customers (for example, 1280 x 1024monitor).

282 Chapter 9


Required Test the default size of the smallest application controls on the smallestmonitor with the highest resolution that is anticipated to be used bycustomers (for example, 13 inch 1280 x 1024 monitor). Make sure thatthere is adequate distance between controls and that all controls can beeasily activated without error.

Resizing Dialog Boxes and WindowsUsers generally resize dialog boxes and windows with specific goals inmind. They become frustrated when the results of the resize operationdoes not meet their goals.

Recommended The following user goals should guide the resize behavior for the dialogboxes and windows that are resizable by users.

• View more information by enlarging the window.

• View information in a larger size (that is, for scaled views of objects).

• Create more room on the desktop by shrinking the window.

When operating in accord with this goal, users will want to see themost important information in the window or dialog box, otherwisethey would iconify the window.

Panes in Resized WindowsWhen a user enlarges or shrinks a window or dialog box that hasmultiple visible panes, they typically do not want to resize only one pane.They would like the resize operation to affect all panes. Users also wantto make choices between which pane will get the most space.

Recommended Panes should be implemented so that resizing of the window or dialogbox affects all panes in the window that would benefit from the resizeoperation.

Benefit is defined as allowing the user to show more data in an enlargeoperation or preventing the loss of user controls in a shrink operation.

Recommended Controls for resizing window panes should be provided when users willbenefit from differential sizing of the panes.

Chapter 9 283


User Help

Recommended Provide help text for every dialog box. Help can be accessible from a[Help] button in the right corner of the button box at the bottom of thedialog box, from the F1 key for context sensitive help, or from a questionmark in the title bar of the dialog box for what’s this help.

NOTE When an application runs on a Windows Platform, help information canalso be accessible from the ‘?’ in the title bar.

General Guidelines for Controls in DialogBoxes

Sequencing of Controls within the Dialog BoxTo match the user’s concept of the task and to minimize user actions,order the dialog box fields with all of the following concepts in mind:

• If defaults for other fields can be derived based on values for specificfields, put the fields used as prerequisites for the default values abovethe fields for which defaults are derived.

• Place mandatory fields that must be completed by the user at the topof the dialog box, with optional fields or fields with default valueslower in the dialog box.

• Group fields associated with a single concept together.

For example, in a dialog box for printer configuration, all fieldsassociated with hardware switch settings should be presentedtogether.

• When other constraints have been met, sequence fields to minimizethe number of changes between input devices. Whenever possible,follow text fields with other text fields so that users do not need to goback and forth between the mouse and the keyboard.

Alignment of FieldsIn dialog boxes containing multiple fields, provide the viewer with anobvious and efficient scanning and handling sequence. Eye and mousepointer movements should be minimized, direction of movement shouldbe obvious, and a consistent and predictable pattern must be followed.This is best achieved when labels and fields are aligned in columns.

284 Chapter 9


Recommended Align fields in vertical columns (typically one to three per row).

In some cases, dialog box constraints may dictate a horizontalorientation of controls.

Control LabelsThe labels used for controls have a direct impact on how easy or difficultit is for the user to do their tasks. The labels provide implicit userguidance which instructs the user on what options are available andwhat input is valid.

Recommended Labels for controls in dialog boxes should be meaningful to users.

Recommended If labels for controls are related to database fields, both labels should bemeaningfully stated in terms and relationships that the user is likely tounderstand.

Recommended The capitalization of labels for controls should be based on the type ofcontrol, unless the words in the label have a conventional usage thatdictates their capitalization:

• Push buttons and tabs should have the first letter of each wordcapitalized unless the word is an article or preposition.

• Labels for radio buttons, check boxes, text boxes, combo boxes, spinboxes, sliders, gauges, tables, grids, and group boxes should usesentence-style capitalization with only the first letter of the first wordcapitalized.

Recommended Place a colon (:) after the label for:

• A group of check buttons.

• A group of radio buttons.

• A text field.

• An option button field name.

• A list with a single column.

Recommended For option buttons (UNIX only), place a colon (:) after the label if itprecedes the option button.

Chapter 9 285


Visual Cues in LabelsProvide visual cues to indicate the state and type of action of controls.

Required Gray buttons that are not available.

Required Place an ellipsis (...) after the label on buttons that lead to a dialog box towhich the user must respond before an action can take place.

NOTE Ellipses should not be used in labels simply because the commandresults in the presentation of a new window. If the new window providesthe requested functionality, for example, view of data, no ellipsis isrequired. If the new window is used to obtain desired options before theaction is carried out. For example, print options dialog, then an ellipsisshould be used on the control.

Required Do not place any symbols after the label on buttons that lead to animmediate action (sometimes known as command buttons).

Recommended Provide a clear indication of which fields in the dialog box require userinput (mandatory fields) and the fields for which user input is optional(optional fields). Either:

• Place parentheses around the label for controls in optional fields;

For example: The label for the text fields in which users may entercomments should be “(Comments:)”.

• Label the fields with “mandatory” and “optional”.

Required Place two arrows ( >> ) after the label on the button that leads to theexpansion of a window to display a previously invisible pane. The arrowsshould indicate the direction of the expansion of the window.

To aid the user in understanding the functionality of the button, it isgood to provide a textual label, such as More>> .

General GuidelinesComplexity in dialog boxes should be appropriate for the task

286 Chapter 9


Recommended If a dialog box supports basic functionality, as well as advanced,auxiliary or less frequently used functionality, it should use one of thefollowing methods to reduce the complexity. The methods are listed inorder of preference:

• Additional dialog boxes with advanced, auxiliary, or less frequentlyused functionality, accessible via controls within the higher leveldialog boxs.

• A multiple page dialog box, with advanced, auxiliary or lessfrequently used functions on later pages.

• An expandable dialog box to present the advanced, auxiliary or lessfrequently used functionality.

Recommended Dialog box expansions and additional dialog boxes should be restricted tofunctions that are used by only a subset of the users and are not neededfor typical execution of a task.

Recommended If beneficial to task performance and if the form structure is complex, anoverview of the form structure or a visual presentation of the structureshould be provided to users.

Recommended Unless it is necessary for command completion or if it is important toprevent further interaction until a condition is satisfied, modeless ratherthan modal dialog boxs should be used.

Default ValuesDefault values are the values that are set by the application so that theyappear as the initial settings for controls when users access them for thefirst time. Default values reduce task time by minimizing the number offields the user needs to complete, and by providing examples of validentries that users can modify. Providing good default values willminimize the need for users to do extensive customizing prior to use ofthe application. Users should not be required to provide any informationthat the application can supply for itself.

Recommended Provide default values for each control in the dialog box unless a defaultwould lead to destructive consequences or to user errors.

Chapter 9 287


Recommended Default values should be chosen to support the user’s task, all of thefollowing guidelines should be adhered to when choosing the defaultvalues:

• System default values should not be destructive (that is, lead to theloss of data) nor should they lead to undesirable time consumingactivities.

• In a single selection list box, the initial default selection should beeither the item most likely to be selected or the first item in the list

• In a multiple selection list box, the default selections should includethe set of items most likely to be selected by the user.

• In a group of radio buttons, the default choice should be the buttonmost likely to be selected.

• In a group of check boxes, each check box should be set to the value(that is, on or off) that would most likely to be selected.

• The default value in a text box should be the value most likely beentered by the user.

• The initially displayed choice in a stepper button should be the mostlogical default choice (that is, the most likely to be selected).

For example, if the user opens a report in a directory and the user hasnot previously accessed the save dialog box, that directory in whichthe report was opened should be the default directory for saving thereport.

Recommended If default values are likely to vary across customers but remainrelatively consistent across the tasks of a specific customer, methodsshould be provided to allow customization of default values.

Recommended If it is likely that retaining values set by an individual user willminimize user steps or the need for changes in field values, user settingsshould be presented as the default values the next time the dialog box orform is accessed.

NOTE In network, systems and service management, customized defaults aretypically set on an organizational basis rather than on an individual userbasis.

288 Chapter 9


Recommended If it is not likely that users will want to retain their previously setvalues, application specified defaults or customized defaults should bepresented as the default values the next time the dialog box or form isaccessed.

Recommended If an application allows customization of default values, some meansshould be provided to allow users to return the settings to the applicationdefined default values.

NOTE The default values that are used for fields in the dialog box or form canbe a combination of previous user values, user configured values andsystem default values. For example, in a print dialog box, the defaultprinter could be set to the last printer selected by the user, however, theformat of the printout could be that defined by the application for thereport that is being printed.

Recommended If there is a default for a control or field in a dialog box, the default valueshould be visible when the field is first presented or as soon as sufficientinformation is available for the application to set the default value.

Recommended Default values for text boxes and combination boxes should be editableby the user using conventional editing commands.

Input Validation and Error HandlingInput validation and error handling can have a major affect on userperformance.

Recommended If possible, perform input validation and error handling on afield-by-field basis while the dialog box that initiated the action is stillup.

For example, if an application prompts for a file name and the file needsto be present before continuing, then keep the dialog box visible untileither a valid file name is entered or the user selects the [Cancel]button. Requiring users to reinitiate an action (for example, from themenu bar) causes extra user steps and time loss.

Chapter 9 289


Default ActionsDefault actions result from the user pressing the Return or Enter key, or bydouble-clicking on an item, symbol, or control. Following are generalguidelines for the use of default actions, additional guidelines specific toindividual controls are found later in this chapter.

Recommended Use default actions in the following situations:

• To perform the action that the user would expect if he pressed theReturn or Enter key when the location cursor is in a specific field. Forexample, if the location cursor is in a text field for string search, themost likely action may be to find the next instance of the typed string.A [Find Next] push button would need to be placed next to the textfield. Pressing the Return or Enter key activates this button.

• To guide user task steps. If users are required to perform a specificsequence of steps, default actions can be used to guide these steps.

• To perform a nondestructive action. A destructive command, such asdelete, should not be used for a default action.

• To minimize user time. Default actions should not lead totime-consuming events that users may or may not have wanted tooccur. If there is a doubt about what the user would want to do,default actions should not lead to a time-consuming activity.

Simple dialog boxes are those that have no input fields, or only one inputfield. In simple dialog boxes, the primary user interaction is provided byspecific push buttons, such as [OK] , [Cancel], or [Close] . Dialogboxes with multiple input fields are more complex, and user interactionis carried out by the use of various controls in the dialog box. The role ofthe [OK] and [Cancel] push buttons is to signal a close to the user’sinteraction. Because of the different interaction styles in these two typesof dialog boxes, there are different guidelines for default actions.

Recommended In simple dialog boxes with no input fields or only one input field, both ofthe following guidelines should be followed:

• One of the push buttons, [OK] , [Cancel] , or [Close] , should bedefined as the default action when the user first enters the dialog box.

• The the choice of default action should be based on which actionwould be the safest for the user.

Recommended In dialog boxes with multiple input fields:

290 Chapter 9


• Actions that close the dialog box (for example, [Ok] or [Cancel] )should be the default action only when one of the following is true:

• The dialog box is first entered and no input has been given, and nonavigation has taken place.

• The location cursor on one of the push buttons that close thedialog box.

• All fields in the dialog box are read-only.

• Otherwise all of the following should be followed:

• The default action should change as the user navigates within thedialog box.

• The default action should be based on the most likely user actionat a given location.

• If the location cursor is on the last field in the dialog box before theexiting push buttons, and the user will not need to review thevalues in the dialog box, the default action should be to activate apush button to close the dialog box.

Chapter 9 291

Dialog Boxes and ControlsGuidelines for Controls

Guidelines for ControlsApply the following HP OpenView-specific recommendations, as well asany guidelines associated with the platform that your applicationsupports, for these types of controls:

• Push buttons (command buttons in Windows NT)

• Options buttons (UNIX platforms only)

• Radio buttons (option buttons in Windows NT)

• Check boxes (check buttons in UNIX)

• Text fields

• Combination boxes

• Spin boxes

• Sliders and gauges

• List boxes

• Tree list controls

• Tables and grids

• Tab controls

• Scroll bars

Note that if your application will be localized, you may have to modifythe guidelines for size, placement, and fonts accordingly.

Push Buttons

Recommended A push button is recommended when most or all of the followingconditions are met:

• The desired result is the execution of an action or the setting of astate.

• There is a need for quick access.

• There is a need for high visibility.

292 Chapter 9


Figure 9-1 Push Buttons

Required Limit the use of push buttons in presentation managers and the primaryapplication window. Provide access to commands or operations throughthe toolbar, through pull down or pop-up menus, or by executablesymbols.

PlacementFollow the general guidelines for the placement of controls presented inthis chapter under “General Guidelines for Controls in Dialog Boxes.”Also follow the specific guidelines for push buttons presented in thissection.

NOTE The recommendation for the placement of the push buttons need to bemodified for localization for different countries.

Push buttons may be placed at the bottom of the dialog box or in themain portion of the dialog box.

Required If a push button is applicable to a dialog box as a whole, place it at thebottom of the dialog box.

Recommended To improve the visual appearance of the dialog provide some type ofseparator between the push buttons at the bottom of the dialog and theother fields in the dialog box. See Figure 9-1 above.

When placing within dialog box and windows, follow these guidelines.

Required Place push buttons applicable to a single pane or component of a dialogbox or window in the pane where they are applicable. This is particularlytrue for complex screens where it may be difficult for users to determinethe effect of the button.

Required Place push buttons applicable to a list to the right of the list to whichthey apply. Vertically align the left side of each push button.

Recommended Sequence push buttons that select and act on items in a list at the top ofthe set of buttons, for example [Open] . Place buttons that modify and/ordelete items in a selection list at the bottom of the set of buttons.

Chapter 9 293


Recommended Push buttons placed at the bottom of the dialog box should be alignedstarting at the right side of the window.

Recommended The distance from the window or dialog box border to the edge of thebutton should be a minimum of 7 dialog base units, or 7 to 11 pixels wide.

Recommended The minimum distance between buttons should be 4 dialog base units, or5 pixels.

Size of Buttons

Recommended All push buttons in a set should be equal in size.

Recommended If there must be a discrepancy in the size of push buttons in order toaccommodate the required number of push buttons when there are largedifferences in the size of the labels; for example, in the words “OK”versus “Cancel,” make the buttons as close in size as possible withoutcompromising the appearance of the longest label.

Labels and DefinitionsFollow the general guidelines for the labeling of controls presented inthis chapter under “General Guidelines for Controls in Dialog Boxes.”Also follow the specific guidelines for push buttons presented in thissection.

Required Table 9-2 outlines the labels and definitions that are required for pushbuttons in HP OpenView applications.

NOTE Do not label buttons at the bottom of the dialog box or window with theword [Exit] . [Exit] should be reserved for exiting the HP OpenViewapplication or HP OpenView environment as a whole. Cognitively, usersview the completion of a dialog box as simply closing the window inwhich the dialog box is presented.

294 Chapter 9


Table 9-2 Labels and Definitions for Push Buttons

Key Action

[Yes] Applies an affirmative response to the question in the dialog box andcloses the dialog box.

[No] Applies a negative response to the question in the dialog box and closesthe dialog box.

[OK] Validates the user-specified action in the dialog box, and closes the dialogbox. If appropriate, saves changes in the dialog box.

[Apply] Applies operation of the dialog box with the current settings. Thisincludes any changes in the dialog box. The [Apply] button should begrayed when the dialog box is first accessed. It should be made availableas soon as the user makes any change in the dialog box.

[Reset] Cancels any user changes that have not been applied. Also resets thestatus of the dialog box to its initial state. Users can undo changes bydoing a [Reset] . [Reset] does not close the dialog box. The [Reset]button should be grayed when the dialog box is first accessed.

[Cancel] Cancels the changes in the dialog box without performing any actionsthat has not been previously applied. [Cancel] closes the dialog box. The[Cancel] button should be available when the user first accesses thedialog box.

[Close] Closes the dialog box without performing any actions in the box. If thedialog box does not allow for user input and changes, it should contain a[Close] button instead of [Ok] and [Cancel] buttons.

[Help] Provides help for the dialog box. This button should always be available.

[Select] Places the highlighted items on the selection list.

[Add] Adds a new item to the list of items. This button should be grayed whenits text input field or list of selections is empty.

[Delete] Deletes the items from the list. In some cases this will result in a deletionfrom the application. This button should be grayed when its list ofselections is empty.

Chapter 9 295


Visual Cues

Required Provide visual cues for the availability of push buttons. If a button is notcurrently available for use, gray the label for the button. If a button isnever available for use, it should not be presented in the dialog box.Examples of when specific push buttons should be grayed are presentedin Table 9-3.

Table 9-3 Guidelines for Showing Buttons as Unavailable

Default ActionFollow these guidelines and the guidelines in “Default Actions” on page289 when assigning default actions to push buttons.

[Describe]or[Describe/Modify]

Presents a dialog box that allows the user to see a description.

[Modify...] Presents a dialog box for modifying an item chosen in a list box. May becombined with Describe as in [Describe/Modify] .

[Properties] Presents a dialog box that indicates the properties of an object orapplication and allows the user to change modifiable fields.

Key Action

Button Button Grayed When...

[Reset] No changes have been made in the dialog box since the last use of[Apply] .

[Next] There is no information to follow.

[Previous] There is no information before.

[Apply] No changes have been made in the dialog box since the last use of[Apply] .

[Cancel] No changes have been made since the last use of [Apply] . [Cancel]should not be grayed when the user first accesses the dialog box.

296 Chapter 9


Required If the location cursor is on a push button, the default action should be toactivate the push button under the location cursor.

Required If the location cursor is in a single line text field and there is a pushbutton associated with the text field, the default action should be toactivate the push button, and the location cursor should remain in thetext field.

Required If a push button is associated with the default action, it must have avisual cue to indicate that it is the default push button.

Figure 9-2 Push Button with Location Cursor and Default Action Indicator

Recommended If the dialog box includes a [Close] button, it should be selected whenthe user presses ALT - F4. If the dialog box includes a [Cancel] button, itshould be selected when the user presses ESC. On some systems, thismay be handled automatically.

Option ButtonsAn option button produces an option menu from which the user canchoose a single item. Option buttons are available only in UNIX. Forapplications on Windows NT, use combination boxes.

Figure 9-3 Option Button in Closed and Open State

Recommended The use of a option button is recommended when most or all of thefollowing conditions are met:

Chapter 9 297


• The desired result is the making of a selection or the setting of astate.

• Choices are mutually exclusive.

• The application will primarily be used on UNIX or a different controlwill be substituted when the application is presented on otheroperating systems.

• There is limited display space.

• Users need to see only the item that is currently selected, exceptwhen changing the selection.

• There are more than 2 items or the number of items may change overtime.

• All applicable items can be identified by the application.

NOTE If some, but not all, valid options are known, use a combination box inplace of an option button.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for option buttonspresented in this section.

NOTE The recommendation for the placement of the option button and itslabels may need to be modified for localization for different countries.

Recommended If the content of the option menu is not appropriate given the currentstate in the window or dialog box, the labels both inside the button andnext to the button should be grayed.

Recommended Place the label that defines the use of the button to the left of the buttonto which it applies, as shown in Figure 9-3. The label for the value set forthe control should be shown on the button itself.

Default Actions and Values

Recommended If the location cursor is on a menu item within the option button, thedefault action should be to accept the menu item as the value for thecontrol and move the location cursor to the next control.

298 Chapter 9


Recommended The default value for an option button should be the choice most likely tobe selected by users.

Radio ButtonsRadio buttons can be used in dialog boxes, panes of windows, or inmenus. Radio buttons occur as a set and allow for the selection of a singlealternative within the set. Radio buttons are sometimes referred to asoption or toggle buttons.

Figure 9-4 Radio Buttons

Recommended The use of a radio button is recommended when most or all of thefollowing conditions are met:

• The desired result is the making of a choice or the setting of a state.

• There are two or more mutually exclusive choices.

• There is sufficient space for all of the buttons and labels.

• The list of choices is greater than two but not large (for example, 5 orfewer).

• Users need to quickly see which option is currently selected.

• Users will benefit from simultaneously seeing all of the alternatives.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for radio buttonspresented in this section.

NOTE The recommendation for the placement of radio buttons, their headersand labels may need to be modified for localization for differentcountries.

Chapter 9 299


Required Label the header for a set of radio buttons to indicate the variable that isbeing modified by the buttons.

Recommended Place the header for the set of radio buttons above the radio buttons.

Required Label each button to indicate the value or state that will be active whenthe given button is set to “On”.

Recommended Place the state indicator button to the left of the button label.

Recommended If space is available, all radio buttons within a set should be verticallyaligned:

• The state indicator buttons should be vertically aligned.

• The labels for the indicator buttons should be left aligned relative toone another.

• If radio buttons are on the left side of a window, left align all stateindicator buttons no less than 1/3 inch and no more than 1/2 inch, or14 base dialog units, from the inside edge of the window border.

Vertically aligned radio buttons are easier for users to scan thanhorizontally aligned buttons.

Optional If space is limited, radio buttons can be horizontally aligned.

If there are more than two radio buttons in a set, they should be evenlyspaced across the width of the window or pane.

Default Actions and Default Values

Required If the location cursor is on a radio button, the default action should be tochange the selection state of the radio button, and move to the next fieldafter the set of radio buttons.

Recommended The default value for a set of radio buttons should be the choice mostlikely to be selected by users.

300 Chapter 9


Check BoxA check box is a toggle control in which the user makes the logical choicebetween “A” and “Not A”. In groups of check boxes, each check boxrepresents an independent choice. However, check boxes are mostobvious in their meaning when they occur in groups of two or more.

Recommended The use of a check box is recommended when most or all of the followingconditions are met:


• Each setting is a single choice between two states.

• Choices can be meaningfully portrayed as an on-off state.

• Users need to quickly see the current state of the choices.

• Users will clearly understand the meaning of the choice when it isselected or not selected.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for check boxespresented in this section.

NOTE The recommendation for the placement of the check box and its labelmay need to be modified for localization for different countries.

Recommended If a set of check boxes are grouped together under a header, the headerlabel for the group should indicate the category of variables that arebeing defined by the buttons.

Recommended Place the header for a set of check boxes above the group of check boxes.

Required Label each check box to indicate the particular variable that is beingtoggled on or off.

Recommended Place the state indicator buttons to the left of the label.

Recommended If space is available and it will not distort the meaning of the controls, allcheck boxes within a window should be grouped together and verticallyaligned:

Chapter 9 301


• When check boxes are vertically aligned, the indicators should bealigned and the labels should be left aligned relative to one another.

• If check boxes are on the left side of a window, left align all stateindicator buttons no less than 1/3 inch and no more than 1/2 inch, or14 base dialog units, from the inside edge of the window border.

Vertically aligned check boxes are easier for users to scan thanhorizontally aligned buttons.

Optional If space is limited, check boxes can be horizontally aligned.

If there are more than two check buttons in a group, they should beevenly spaced across the width of the window or pane.


Required If the location cursor is on a check box, the default action should be tochange the selection state of the check box and move to the next checkbox in the group, or to the next field if there are no more check boxes inthe group.

Recommended On initial presentation, each check box should be set to the value thatwould most likely be selected by the user.

Text BoxesText boxes are controls that present textual data, or fields into which theuser can type characters from the keyboard. Text boxes can be combinedwith menus, lists, and other selection mechanisms, such as the radiobuttons, to allow users increased flexibility with ease of use. Examples ofvariables that can best be presented in text boxes are names, comments,and locations.

302 Chapter 9


Figure 9-5 Single and Multi-line Text Boxes

Recommended The use of a text box is recommended when most or all of the followingconditions are met:

• The desired result is the providing unspecified information, making ofa choice, the setting of a state or the giving of a command.

• The set of possible valid entries is large.

• Entries cannot all be predefined in advance.

• Users will know what entries are valid.

• The control is to be used as part of a keyboard intensive task.

• Any input is acceptable (for example, a comment field).

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for text boxes presentedin this section.

NOTE The recommendation for the placement of text box and its label mayneed to be modified for localization for different countries.

Recommended Label text boxes to clearly indicate the purpose and meaning of thecontrol. Include valid ranges in labels where appropriate; for example,Page Width (60-120).

Recommended Place labels above or to the left of the text box.

Chapter 9 303


Required If there is a wide variation in the length of labels, place labels above thetext box.

Labels above text box allow for easier localization.

Required If labels are placed above text boxes, align the left edge of the firstcharacter in the label with the left edge of the text box beneath it.

Required If labels are placed to the left of text boxes, right-align labels with the leftedge of the text field.

Required If there are multiple rows of text boxes, vertically align the boxes of thesefields.

General Guidelines

Required Users should be able to discriminate between read-write text boxes andread-only text boxes, see Figure 9-5 for an example.

• Read-only text boxes should have the same background color as thebackground of the dialog box.

• Read-write text boxes should have a different background color thanthe background of the dialog box.

Recommended Users should be able to use the operating system-provided copy/cut andpaste methods to cut and paste text strings into text boxes.

Recommended The location of the text cursor when a text box is first given keyboardfocus should support the user’s task:

• If the task flow indicates that a portion of the text in the box is mostlikely to be modified, then the text cursor should be placed at the endof that portion.

Example: A server and its fully distinguished name are displayed ina text box. The text cursor is placed at the end of the hostname, beforethe domain name, as this is the portion of the name most likely to bechanged.

• If the task flow indicates that no specific portion of the text is mostlikely to be modified, the text cursor should be placed at the end of thetext in the box.

304 Chapter 9


NOTE If the entire text is selected for replacement it is possible that the textcursor will not be shown.

Recommended If the user’s task will typically require the replacement of all rather thana portion of the text in a text box, the entire text should be selected forreplacement when the user first enters that text box.

• If the user enters information into the text box, the previouslyselected text should be replaced with the new text.

• If the user leaves the text box without entering new information, thetext that was initially in the box should remain.

Size of Text Boxes and Scrolling

Required Use single-line text boxes only if users are limited to entering charactersequal to one line or less.

Users should not be able to press the Return key and get a new line withina single line text field.

Required If users can enter multiple lines of text into a single text box, make thedefault size of the text box show multiple lines (that is, two lines ormore).

Recommended Text boxes should be large enough to accommodate the majority ofanticipated entries without scrolling.

Recommended If the variable associated with a text box has a specified number ofcharacters that the user can enter, make the length of the text box equalto the maximum number of characters that the user can enter.

The visual cues of the length of the text box will aid the user in correctlyspecifying the information to be entered into the text box.

Recommended A mono-spaced font should be used for the data in the text box so thatthe text box will appear to be filled when the maximum number ofcharacters has been entered into the box.

It is confusing for users to receive an error indication when trying to typeinto a text box where the visual cues indicate that more characters canbe entered.

Chapter 9 305


Optional Single-line text boxes can scroll if there is more information in the boxthan can be viewed within the visible area of the text box.

Recommended Provide vertical scroll bars for multiple line text boxes, only after theuser has entered more lines of text than can be viewed within the visiblearea of the text box.

Default Action and Default Values

Recommended If the location cursor is in a single line text box and there is a pushbutton associated with the text box, the default action should be toactivate the push button. The location cursor should remain in the textbox.

Recommended If the location cursor is in a single line text box and the text box does nothave an associated push button, the default action should be to move tothe next input field, if one exists.

Recommended If the location cursor is in a multi-line text box, the text cursor shouldmove to the next line in the text box when the user presses Enter. Thelocation cursor should remain on the text box.

Recommended Whenever possible, provide a default value for text boxes. The defaultvalue should be the value most likely to be entered by users.

Even if the value needs to be changed by the many users, it will provide aindication of the format required for the entry.

Recommended If there is no meaningful default value can be provided for a text box, thebox should be empty.

Combo BoxesCombo boxes are controls that combine text boxes and lists of items.There are two types of combo boxes, regular and drop-down combo boxes.In regular combo boxes the list is continually presented below the textfield in which users can enter data. Drop-down combo boxes present onlythe text field until the user takes an action to present the list.

306 Chapter 9


Figure 9-6 Drop-down Combo Box in Closed and Open State

Recommended The use of a combo box is recommended when most or all of the followingconditions are met:



• There is limited display space.

• Users need to see only the item that is currently selected, exceptwhen changing the selection.

• There are 5 or more items to choose from or the number of items maychange over time.

• Users may be able to type the entry more quickly than they can selectit.

• The control is used as part of a keyboard intensive task.

• Users may have to type values that cannot be supplied by theapplication.

Recommended Use drop-down combo boxes to replace option buttons from Motif whenrunning on the Windows NT operating system.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” For specific guidelines on the labeling and placement ofcombo boxes see “Text Boxes.”

Chapter 9 307


General Guidelines

Recommended If combo box list does not present an exhaustive list of all validalternatives, allow the user to type values that are not currently in thelist. Valid typed values should be added to the list whenever possible.

Recommended If combo boxes are used and space is not an issue, use regular comboboxes where the list is always available.

Recommended Combo boxes should provide automatic searching of the list entries basedon the characters that the user types into the text box. This aids users insearching for items in long lists and allows for consistency across allcombo boxes. Searches should take into account all characters typed bythe user, not only the first character.

Required When combo boxes are used they should provide the same visual cuesthat are recommended for text controls and for list boxes (see “TextBoxes” and “List Boxes”).


Recommended If the location cursor is on the text box portion of the combo box, thedefault action should be to check the entry in the text box, and if it isvalid, move to the next field. If the entry is not valid, an error messageshould be given and the location cursor should remain in the combo box.

Recommended The default value in a combo box should be the value most likely to bechosen by users.

Spin BoxesA spin box is a control with a text box and up and down arrows that theuser clicks to move through a fixed set of values. Users can also typevalid inputs into the text box associated with the control.

Recommended The use of a spin box is recommended when most or all of the followingconditions are met:

• The desired result is the making of a choice or setting of a state.


• There is limited space.

308 Chapter 9


• There is a familiar sequential order to the items.

• Users may want to go either direction within the sequence.

• Users do not need to preview the options before making a selection.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for spin boxespresented in this section.

NOTE The recommendation for the placement of the spin box and its label mayneed to be modified for localization for different countries.

Required Unless the values inside the spin box make the purpose of the spin boxintuitively obvious, each spin box should have a label to indicateparticular variable that is being incremented or decremented by the spinbox. See Figure 9-7 and Figure 9-8.

Figure 9-7 Spin Box with Labels Required

Figure 9-8 Spin Box with Labels Optional

Recommended The label for the spin box should be to the left of the spin box or abovethe spin box.

Optional If it will benefit the user, place labels identifying units for variablesinside the spin box or to the right of the spin box.

Recommended The mapping between the labels on the buttons and the direction ofchange in values should be consistent with user population conventions.

Chapter 9 309


Example 1: Data are consistently sequenced so that using an up arrowincreases the value for the data while using a down arrow decreases thevalue for the data, up to the point where the data wrap.

Example 2: Days of the week are presented in a spin box and the leftarrow moves to an earlier day and the right arrow moves to a later day inthe week.


Required If the location cursor is on a spin box, the default action should be toaccept the current entry in the text box and move to the next input field.

Recommended The default value in a spin box should be the value most likely to bechosen by users.

Sliders and GaugesSliders and gauges are analog controls. An analog control is one thatallows for setting or presentation of variables as relative values ratherthan absolute. Analog controls provide less precise value setting thandigital controls such as a spin box. However they are very useful inincreasing or decreasing values or in displaying values along acontinuum.

Figure 9-9 Slider with a Default Setting and Current Value Shown

Figure 9-10 Gauges for Setting a Value and Displaying a Value

310 Chapter 9


Recommended The use of analog control is recommended when most or all of thefollowing conditions are met:

• The desired result is the making of a choice or the setting of a state orthe display of a value along a continuum.

• There is a need to show the current value relative to possible rangesof values.

• There is a need for large imprecise changes with minimal effort.


• Display space is sufficient.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for sliders and gaugespresented in this section.

NOTE The recommendation for the placement of an analog control and its labelmay need to be modified for localization for different countries.

Required Both ends of the scale associated with a slider or gauge must be labeledso that users can determine the direction of the continuum for increasingand decreasing values. See Figure 9-9.

Recommended If users will need to know the absolute value for the variable set by theslider or gauge, provide a label that displays the value. See Figure 9-9and Figure 9-10.

Recommended The direction of change (increasing and decreasing) in values in theslider or gauge should be consistent with user population conventionsand with the labels for the control.

Example 1: Lower values set in a slider are associated with the left sideof the scale and the higher values are associated with the right side ofthe scale.

Example 2: Desired values presented in a gauge are associated with themiddle of the gauge. Values that are below normal are presented on theleft side of the gauge while values that are above normal are presentedon the right side of the gauge.

Chapter 9 311


Recommended Place the label identifying the type of variable to left or above the slideror gauge.

Recommended If it will benefit the user, display a default setting for the slider as a moreelongated marking on the scale, see Figure 9-9.

Recommended If it will benefit the user, display threshold settings for the gauge as aline or a change in coloring inside the main portion of the gauge, seeFigure 9-10.


Required If the location cursor is on a slider or gauge, the default action should beto accept the current value and move to the next input field.

Recommended If a slider or gauge is used for setting values as well as displaying thevalue, the value most likely to be chosen by the user should be set as thedefault.

List BoxesLists can have a single dimension or multiple dimensions. Lists thathave a single dimension are typically presented in a list box with eachitem in the list appearing as a row in the list box. Different dimensions ofa multiple dimension list are typically presented as different columnswithin a row that represents the item. Guidelines on presenting singlecolumn lists in list boxes are presented in this section of the style guide.Guidelines for multiple dimension lists are presented in section on“Tables and Grids” later in this chapter.

List boxes can allow users to select a single item or multiple items fromwithin the list. Lists can have both horizontal and vertical scroll bars forscrolling the visible portion of the list of items.

When to Use

Recommended The use of a single selection list box is recommended when most or all ofthe following conditions are met:

• The desired result is the making of a single choice or the setting of astate.


312 Chapter 9


• There are more than 5 items in the list or the number of items maychange over time.

• Users may need to change settings frequently.

• There is value in having a large number of the choices simultaneouslyvisible.

• There is adequate space to display 3 or more items simultaneouslywithout scrolling.

NOTE If a vertical scroll bar will be used with the list box, it is important thatthe list box be large enough to show at least 3 items.

Recommended The use of a multiple selection list is recommended when most or all ofthe following conditions are met. The desired result is the making ofmultiple choices or the setting of one or more states.

• Choices are not mutually exclusive.

• There are more than 5 items or the number of items may change overtime.

• Users may need to change settings frequently.

• There is value in having a large number of the choices simultaneouslyvisible.


NOTE When users need to make multiple selections it is especially importantto make the box as large as space will allow.

Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for list boxes presentedin this section.

NOTE The recommendation for the placement of list boxes and their labels mayneed to be modified for localization for different countries.

Required Label lists to clearly indicate the purpose and content of the list. Labelthe items contained in lists to clearly identify them to the user.

Chapter 9 313


Recommended Place labels for lists as follows:

• Place labels so that they remain visible when the list is scrolled.

• Place the column label above the list and vertically align it with theleft side of the list.

General Guidelines

Recommended In lists that contain a large number of items:

• Sequence the items according to an easy to recognize logical sequenceto allow the users to easily scan the list items and locate those thatthey want to select.

For example, items in the list can be presented in alphabetical order.If time is a key attribute, items can be sequenced according to time.

• Provide a search or find capability to allow the users to locate theitems in the list without having to find them by manual scrolling.

Required Visual cues should be provided that allow users to differentiate betweensingle selection and multiple selection list boxes.

Multiple selection list boxes can include a check box next to each item toindicate to the user that they can select multiple items, see Figure 9-11.

Figure 9-11 Visual Cues for a Multiple Selection List Box

Recommended Minimize the need for horizontal scroll bars in the list.

314 Chapter 9


NOTE It is difficult to read information if it must be scrolled horizontally.


Recommended In a single selection list box, the default action should be to perform theaction most frequently associated with the list item, that is, select, open,modify. After the default action, location cursor should either remain atits current location or move to the next input field.

• The location cursor should remain at its current location if the defaultaction was to bring up a dialog box.

• The location cursor should move to the next field if the default actionwas the selection of the list item.

Recommended In a multiple selection list box, the default action should be select the listitem and move to the next list item that is available for selection ordeselection.

Recommended In a single selection list box, the initial default selection should be eitherthe item most likely to be selected or the first item in the list.

Recommended In a multiple selection list box, the default selection should include theset of items most likely to be selected by the user.

Tree List ControlsTree list controls provide a hierarchical listing of objects withindependent mechanisms for expanding and contracting and selectingitems in the list.

Chapter 9 315


Figure 9-12 Single Selection Tree List and Multiple Selection Tree List

Follow the guidelines in this section when using tree list controls.

When to Use

Recommended The tree list control is recommended when most or all of the followingconditions are met:


• There is value in showing the hierarchical relationships between theitems in the hierarchy or items can be meaningfully grouped in ahierarchy.

• Users need to select all of the subordinates of one or more levels inthe hierarchy.

• There are a large number of items and users can get lost in theinformation if some of the items are not hidden from initial view.

• The number of items may change over time.


Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for tree lists presentedin this section.

316 Chapter 9


NOTE The recommendation for the placement of tree lists and their labels mayneed to be modified for localization for different countries.

Recommended Label tree list items meaningfully to indicate the specific objects in thelist.

Recommended If icons are used in the list, place the icons to the right of the [+] and [-]expansion controls and place the labels to the right of the icons. If iconsare not used in the list, place the labels to the right of the [+] and [-]expansion controls

General Guidelines

Recommended If the list is expandable, expansion controls should be placed to the left ofitems that can be expanded. Each item that can be expanded to showlower-level contents should have a [+] on its left side. Each item that canbe contracted to remove the lower-level contents should have a [-] on itsleft side. Items that cannot be expanded nor contracted have no [+] or [-] .

Recommended Indent each level in the hierarchy to indicate lower-level items that aresubordinate to a higher-level item.

Recommended The sequencing of the items in a list should represent on the nature ofthe objects represented in the list. Adhere to the following guidelineswhen sequencing hierarchical items in a tree list:

• List items that are naturally structured into hierarchies in sequencethat reflects their order in the real world hierarchy.

• Sequence items at the same level in the hierarchy according to theirrelationships, temporal or logical parameters.

• Relational Sequence

If there is a meaningful relationship between objects at the samelevel in a hierarchy sequence the items based on this relationship.Examples of meaningful relationships include physicalconnectivity, physical distance, shared attributes.

• Temporal Sequence

Chapter 9 317


If time is a key attribute associated with items in the hierarchy,sequence the items according to time. If users need to access themost recent items quickly, place the most recent items at the top ofthe list and the least recent items at the bottom of the list.

• Logical Sequence

Sequence items that have no firm relationship to one anotheraccording to a logical rule, such as alphabetical or numericalordering.

Selection in Tree List Controls

Recommended In single selection tree lists and tree lists used in the scope pane, thecurrently selected items should be marked by a selection highlight (bluebackground with white text) see the left portion of Figure 9-12.

Recommended If multiple selection is the most typical type of selection done in a treelist, a check box should be placed between the expansion control and theicon associated with the item see the right portion of Figure 9-12.

NOTE If single selection is the most typical type of selection done in a tree listcontrol, check boxes are not recommended.

Optional If there are a significant number of levels in the hierarchy and space forthe check boxes is an issue, multiple selection can be done by:

• Substituting check boxes for icons.

• Substituting check boxes for expansion controls.

NOTE Check boxes that replace the expansion control are not allowed formultiple selection in a tree list control in a scope pane. Having expansiononly accessible through double-clicking on icons that contain expansioncontrols restricts user flexibility. It takes away the ability of the user toexpand and contract the navigation hierarchy without changing theinformation in the content pane of the window.

Tree lists with check boxes allow users to select objects at different levelsin the hierarchy. This type of selection allows the selection to beinherited by objects lower in the hierarchy. Users should be able tocontrol selection at each level in the hierarchy.

318 Chapter 9


Required If the user selects an item at a higher level in the hierarchy, all itemscontained within the higher level item should be marked as selected(that is, black check mark in their check boxes).

Required When the user selects a subset of items beneath a higher level item orturns off some of the selections that were done by means of selecting ahigher level item, the check mark in the check box of the higher levelitem should be light gray instead of black to indicate that the item ispartially selected.

Recommended If it is important to distinguish items where selection is inherited ascompared to items that are directly selected, this should be indicated byvisual cues.

In Figure 9-13 below, the left most graphic shows what the tree wouldlook like with no selections. If the user directly selected “HP-UX”, thehigher level item “Nodes” would be shown as partially selected, see thegraphic in the middle. As is shown in the right most graphic, if the userdirectly selected “Denver” the lower level items under “Denver” wouldautomatically be selected and higher level items in the hierarchy wouldbe shown as partially selected.

Figure 9-13 Visual Cues for Recursive Selection

Required Clicking on the check box or on the icon to make the item part of amultiple selection should not affect the position of the selection cursor orlocation cursor if the tree list is presented in the scope pane.

Chapter 9 319


Keyboard Navigation in Tree List Controls

Recommended Pressing the down arrow key acts to move the selection cursor down andto execute any action associated with selection. When at the bottom ofthe hierarchy, pressing the down arrow key does nothing.

Recommended Pressing the up arrow key acts to move the selection cursor up and toexecute any action associated with selection. When at the top of thehierarchy, pressing the up arrow key does nothing.

Recommended Pressing the right arrow key when the focus is on:

• An item that contains a [+] acts to expand the list associated withthat item.

• An item that contains a [-] moves the selection cursor to the first itemin the expanded list under the item and executes any actionassociated with selection.

• An item that does not have an expansion control does nothing.

Recommended Pressing the left arrow key when the focus on:

• An item that contains a [-] acts to contract the list associated withthat item.

• An item that contains a [+] or no expansion control moves theselection cursor to the parent item in the navigation hierarchy andexecutes any action associated with selection.

• Highest level in the hierarchy pressing the left arrow key doesnothing.

Pointer Navigation in Tree List Controls

Required A single click on the [+] or [-] causes the item to expand or contractdepending on its previous state.

Required A single selection button click on the icon or the item label, selects theitem and executes any action associated with the selection.

Recommended Double-clicking on the icon or the item label that has a [+] or [-] causesthe item to expand or contract depending on its previous state, selectsthe item and executes the default action associated with the item.

320 Chapter 9


Recommended A menu button click on the item results in a pop-up menu with menuitems that are specific to the item under the pointer.

Recommended If the names of the item in the tree list are truncated, resting the pointerover the name of the item should result in the presentation of a tooltipwith the full name of the item.

Default Actions and Default ValuesThe default action associated with items in a tree list control will varydepending on how the control is being used. Typical default actions are toopen the item, expand and open the item, or open a properties dialogassociated with the item.

Recommended If appropriate to the use of the tree list control, items in the list arerecommended to have default actions associated with them.

Recommended In a single selection tree list, the initial default selection should be eitherthe item most likely to be selected or the first item in the list.

Recommended In a multiple selection tree list, the default selection should include theset of items most likely to be selected by the user.

Tables and GridsTabular controls typically provide vertically aligned rows of items withmultiple columns across each row. The columns are used to provide aspecific type of information about the item presented in the first columnof each row. For example, a table can provide information on the users ona system. The first column in the table could be the user’s login name,the second column could provide the user’s home directory, the thirdcolumn could provide the start up shell.

There are two basic types of tabular controls: tables which presentinformation that must be indirectly edited outside of the table and gridswhich are directly editable. Tables restrict user actions to the selection ofthe rows, columns or cells of the table. After selecting entries in the table,users can act on the selected items via push buttons or menu items. Ifthe contents of a table are to be edited, this is done indirectly in aseparate dialog box. Grids are similar to spread sheets in that they allowusers to directly modify the cells within the grid.

Chapter 9 321


Figure 9-14 Table

Figure 9-15 Grid

When to Use Table and GridsUse table controls when you need to display or allow user editing ofmultiple pieces of information associated with a multiple items or objects(for example, an array of data or a structure).

322 Chapter 9


Recommended The table is recommended when most or all of the following conditionsare met:

• The desired result is the making of a choice or the presentation ofinformation.

• It benefits the user to show attributes or additional data associatedwith the items being displayed.

• The need to modify the attributes shown is infrequent or themodification of the attributes is most easily done with specificcontrols.

• There are multiple items or the number of items may change overtime.


Recommended The table is recommended when most or all of the following conditionsare met:

• The desired result is the making of a choice, the presentation ofinformation, or the modification of individual attributes.

• It benefits the user to show attributes or additional data associatedwith the items being displayed.

• The need to modify the attributes shown is frequent and can easily bedone by entering data into text fields.

• There are multiple items or the number of items may change overtime.


Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for tables and gridspresented in this section.

NOTE The recommendation for the placement of an tables and grids and theirlabels may need to be modified for localization for different countries.

Chapter 9 323


Recommended In tables and grids, vertically align the label for the first column with theleft side of the list box. For the labels for the remaining columns, followthese guidelines:

• If the contents of a line in the column is long relative to the label (forexample, if the line in the column contains 50 characters and spacesand the label contains 10), center the label above the column unlessthis would cause the label to be off the visible area of the displaywhen a portion of the column is displayed.

• If the contents of the column is approximately the same width as, orshorter than, the label, the label should be left aligned.

Recommended In tables and grids, provide adequate spacing between column entries(two or more spaces minimum), so users can clearly discriminate thecolumns.

Recommended Tables should have a column label above each column in the table. Ifusers can horizontally scroll the data, they should be able to scroll thecolumn labels.

Input Focus and Editing for Tables and GridsWhile tables are fairly common, grids are relatively new to users. Userswill need to be able to differentiate these types of multi column controls.They will also need to have strong visual cues to indicate the types ofactions they can take in a grid.

Recommended Tables should have the appearance of a multiple column list and thereshould not be any lines between the rows and columns in the table.

Recommended Grids should have the appearance of a spreadsheet and there should belines between the rows and columns in the grid.

Recommended If the content of the table or grid is greater than can fit on a single screenof information, allow users to resize the columns of information to meettheir individual needs. Also consider giving the user control over thesequencing of the columns of information.

Recommended Push buttons that act on selections within the table should be placed tothe right of the table.

324 Chapter 9


If users will need to edit or modify the entries in the table, provide apush button labeled Modify... or Properties... that will present aseparate dialog box for editing a given row in the table. Each editable cellin the table should be represented by a separate field in the dialog box.

Recommended When a table first receives input focus, the row that the user is mostlikely to select or modify should be selected.

Recommended When a grid first receives input focus, the cell that the user is most likelyto edit should have input focus.

If the most likely user action is to add entries to the grid, the cell withinput focus should be the left most cell within the first empty row of thegrid.

Recommended If the grid is the only control in a dialog box or window, input focusshould on the grid and one of the cells in the grid should have input focuswhen the window is first opened.

Required The cell in the grid that has input focus should be indicated by a clearvisual cue. A dark border around the cell is the suggested visual cue. SeeFigure 9-15.

Recommended Grids in which users can add entries should have two empty rows of cellsat the bottom. See Figure 9-15.

Having two empty rows in the grid provides a visual cue that users canadd new entries to the table. After the user has filled in information inthe first empty row and then moves to the second empty row a newempty row of cells should be added to the grid. This assures that there isalways an empty row of cells at the bottom of the grid, even when theuser is doing data entry in the last column of the empty row.

Recommended When the user is adding a new item to an grid, default values should beprovided in cells where it is possible to have default values.

Recommended Users should be able to delete items from grids by highlighting theinformation in the cells and pressing the [Backspace Erase] key onthe keyboard.

Required If some of the cells in the grid are read only this should be indicated by agrayed background appearance to the cells. See Figure 9-15.

Chapter 9 325


Recommended If controls other than text boxes are placed in the cells of grids, thecontrols should not be visible until input focus is in the cell.

If input focus is not in one of the cells in the grid, the cells should onlyreflect the current value of that cell. When input focus is placed withinthe cell the type of control associated with that cell should be shown.

Filtering and Sequencing of ItemsThe best sequencing of the items in a table or grid depends on the natureof the objects represented in the table.

Recommended When it will benefit the user’s task, users should be able to filter theinformation in the table or grid.

Typically filtering capabilities can be accessed by a pop-up menuassociated with the column labels for the table or grid.

Recommended When users can add entries to tables or grids, the entries should besequenced in the order in which they were added.

Recommended If users cannot add entries to a table or grid, the rows should besequenced in a logical order based on the first column in the table. Thelogical order can be alphabetical, based on the physical layout of theobjects in the managed environment.

Recommended When it will benefit the user’s task, users should be able to control thesequence of items in the table:

• Sort the tabular information by the information in the variouscolumns by clicking on the column labels.

• Resequence the columns in the table by dragging the column headingto a new location.

• Resequence rows in the table by selecting the row and dragging it to anew location or by push buttons for manipulating item sequence (forexample, [Move Up] and [Move Down] .

Recommended If a table or grid has more columns than can be displayed in the dialogbox or window in which it is contained, a horizontal scroll bar should beprovided to allow users to see all of the columns.

326 Chapter 9


Recommended If a table or grid has more rows than can be displayed in the dialog box orwindow in which it is contained, a vertical scroll bar should be providedto allow users to see all of the rows.

Selection in Tables and Grids

Recommended When applicable to the task, users should be able to do multiple selectionin table controls by doing a range selection or control select of individualrows or cells.

Recommended Unless users are able to select individual cells in the table, the selectionhighlight should be placed around the full row in the table when the userselects it.

Recommended A single-click on a cell in the of a grid should place input focus in thatcell.

Keyboard Navigation in Tables and Grids

Recommended In a table:

• Pressing the down arrow key should move the selection cursor downone row. When at the last row in the table, pressing the down arrowkey does nothing.

• Pressing the up arrow key should move the selection cursor up onerow. When at the first row in the table, pressing the up arrow keydoes nothing.

• If users can select individual cells in the table, pressing the rightarrow key should move to the selection cursor to the next selectablecell. If users can only select full rows in the table, pressing the rightarrow key should move the selection cursor down one row. When atthe last row or cell in the table, pressing the right arrow key doesnothing.

• If users can select individual cells in the table, pressing the left arrowkey should move to the selection cursor to the previous selectable cell.If users can only select full rows in the table, pressing the left arrowkey should move the selection cursor up one row. When at the firstrow or cell in the table, pressing the left arrow key does nothing.

Recommended In a grid:

Chapter 9 327


• Pressing the Down Arrow key should move input focus down one row.When at the last row in the table, pressing the Down Arrow key doesnothing.

• Pressing the Up Arrow key should move input focus up one row.When at the first row in the table, pressing the Up Arrow key doesnothing.

• Pressing the Right Arrow key should move input focus to the nexteditable cell in the table. When at the last editable cell in the table,pressing the Right Arrow key does nothing.

• Pressing the Left Arrow key should move input focus to the previouseditable cell. When at the first editable cell in the table, pressing theLeft Arrow key does nothing.


Recommended When one or more rows are selected in a table, the default action shouldbe to perform the most typical action associated with the item associatedwith the table row (for example, open, modify).

In Figure 9-14 the default action would be to enable the selected object.

Recommended When in the cell of a grid, the default action should be to perform themost typical action associated with the cell.

Frequently the most meaningful action will be to accept the valueentered in the cell and to move to the next cell in which the user needs tomake an entry.

Recommended If users will need to take action on items in a table, the item that userswill most likely need to act on should be selected. If there is no means fordetermining what item users will need to act on, the first item in thetable should be selected.

Tab ControlsTab controls provide a means of presenting a large amount ofinformation in a limited amount of space. These controls presentmultiple pages of information or controls using a metaphor of a set ofindex cards with attached tabs.

328 Chapter 9


Figure 9-16 Tab Control

Follow the guidelines in this section when using tab controls.

When to Use

Recommended The tab control is recommended when most or all of the followingconditions are met:

• The desired result is the presentation properties of an object or thepresentation of multiple sets of information or controls in a limiteddisplay space.

• There is more information to be collected or presented than can beshown in a single dialog without scrolling.

• The information or controls can be grouped into meaningfulnonoverlapping categories.

• Users do not need to see all settings simultaneously or may benefitfrom having the data presented separately (for example, users mayonly need to view or input data within a single tab).

• There is no sequential dependency between controls that would beplaced on separate tabs.

Chapter 9 329


Placement and LabelingFollow the general guidelines for the placement and labeling of controlspresented in this chapter under “General Guidelines for Controls inDialog Boxes.” Also follow the specific guidelines for tab controlspresented in this section.

NOTE The recommendation for the placement of tab controls and their labelsmay need to be modified for localization for different countries.

Recommended Label the tabs meaningfully to indicate the types of data to be input orpresented on the tab.

Recommended The sequence of tabs within a tabbed control should match the logicalorder required by the user’s task:

• The most frequently used tabs should be placed to the left in thesequence and less frequently used tabs should be placed to the right.

• Data that users would expect to provide first are placed in the firsttab in the sequence (for example, the name of the item or object).

Required The ordering of tabs should be preserved as users access different tabs inthe set.

Recommended The placement of tab controls at the top or bottom of a window shouldfollow these guidelines:

• Tab controls at the bottom of the scope pane should only be used ascontext tabs, see “Context Controls” in Chapter 5 for moreinformation on context tabs.

• Tab controls at the bottom of the results pane should only be used asnavigation tabs, see “Navigation Tabs” in Chapter 5 for moreinformation on navigation tabs.

• Tab controls at the top of the scope pane should be avoided.

• Tab controls at the top of the results pane should be used for groupingproperties, task steps, or information sets.

Recommended If vertically aligned tabs are used, the labels should be rotated as awhole rather than closing characters vertically aligned.

330 Chapter 9


Figure 9-17 Vertical Tabs

NOTE Vertically aligned tabs are not recommended.

General Guidelines

Recommended In general it is recommended horizontally aligned tabs be used instead ofvertically tabs.

Recommended Only a single row of tabs should be presented in a tabbed control.

Multiple rows of tabs are confusing to users when they are navigatingbetween the different rows of tabs. If the rows stay in their absolutepositions, they top row does not appear to be attached to the tab. If therows change position depending on whether they are active or not, theirposition changes and this results in user error.

Recommended If there are more categories than there is space for tabs in a single rowthe following methods should be used to eliminate the need for multiplerows of tabs:

• Using the shortest possible meaningful tab label and shrinking thetabs to fit the labels.

• Restructuring the categories so there are fewer categories.

Chapter 9 331


• Increasing the width of the tabbed dialog box so that there is morespace for tabs.

• Scrolling the tabs if user performance will not suffer from seeing asubset of the categories.

Recommended If tabs are scrolled:

• Visual cues should be provided on the tabs to indicate that not alltabs are visible and the tabs can be scrolled see Figure 9-18,“Scrollable Tabs.”

• Tabs should automatically scroll to the right when the user selectsthe right most tab in the visible tab set.

• Tabs should automatically scroll to the left when the user selects theleft most tab in the visible tab set.

Figure 9-18 Scrollable Tabs

Recommended If beneficial to task performance, visual cues should be provided toindicate:

• The tab contains mandatory fields that must be completed before thedialog box can be exited.

For example, an asterisk could appear on each tab that containsmandatory fields.

• The user has previously accessed a tab during the current session.

For example, all tabs that have been accessed in the current sessioncould have the tab labels presented in italic font.

• The user has changed information in the set of tabs but the changesnot been saved.

For example, the status bar of the window or dialog box containingthe tab control could present the message “Unsaved changes.”

332 Chapter 9


Required Tabs in a tab control that may be unavailable for long periods of time ormay never be available (that is, tabs only available when specificsoftware has been installed or if the operator is granted specificpermissions) should be removed from the tab control. These tabs shouldonly be included in the tab when the prerequisites for their availabilityhave been met.

Required Push buttons that act on a single tab with the set of tabs should beplaced within the tab on which they act.

Required Push buttons that act on all of the tabs within a tab set should be placedoutside of the tabs.

NOTE Push buttons placed outside of the tab set should be placed beneath theset of tabs or optionally to the side of the tabs. Placement beneath the setof tabs is preferred.

Grouping ControlsIn addition to providing aesthetic appeal, grouping of information canaid user recall, and result in faster screen search. Grouping methodsinclude separator lines, group boxes, and panes.

Separator lines are simply a horizontal or vertical line that is used toseparate information on the screen. Separator lines are commonly usedin menus to separate different types of menu items. They can also beused in windows and dialog boxes to separate different types of controls.Separator lines take up less space than group boxes as they consist of asingle line rather than a set of four lines.

Chapter 9 333


Figure 9-19 Dialog Box with a Separator Line

NOTE Separator lines can be created in n Windows NT applications by bitmapimages of a line, in HTML applications using horizontal rules (<HR>), inJava applications using a GIF image of a line and in UNIX applicationsby using panes without sashes.

Group boxes provide a box or line surrounding the set of controls thatthey group. Group boxes can be used to organize the screen or dialog boxinto functional or semantic groups. Although technically consideredcontrols, group boxes do not process any mouse or keyboard input. Theydo however affect keyboard navigation as the user of the interface mustuse the tab key to move into the controls within the group box.

334 Chapter 9


Figure 9-20 Dialog Box with a Group Box

Panes provide a more definite boundary between the set of controls thatthey group. Panes divide the window into individual segments and allowthe user to apportion the window display space based on their individualneeds when using the different window segments. The informationpresented in a pane can be independently scrolled. Like group boxes,panes affect the keyboard navigation within a window, as the user of theinterface must use the Tab key to move between the different panes in thewindow. See Figure 9-21.

Chapter 9 335


Figure 9-21 Window with Two Panes

When to Use

Recommended The use of a line as a grouping mechanism is recommended when most orall of the following conditions are met:

• The desired result is a visual indication that there are differences inthe type of functionality or type of information being provided indifferent sections of the dialog box.

• The information or controls can be arranged into meaningfulnonoverlapping groups.

• Users have the possibility of misunderstanding the information if itis not grouped.

336 Chapter 9


• There is limited space in the dialog box for presenting the groupingmechanism.

• It is more aesthetically appealing to have the separator in the dialogbox.

Recommended The use of a group box as a grouping mechanism is recommended whenmost or all of the following conditions are met:

• The desired result is a visual indication that there are differences inthe type of functionality or type of information being provided in thegroups.


• Users have the possibility of misunderstanding the information if it isnot grouped.

• There is sufficient space in the dialog box for presenting the groupingmechanisms.

• Having a label or title for the group increases the usersunderstanding of the controls that are presented in the group.

Recommended The use of a pane as a grouping mechanism is recommended when mostor all of the following conditions are met:

• The desired result is a visual indication that there are differences inthe type of functionality or the type of information being provided indifferent sections of the window.


• Having separate panes aids the user in interacting with theinformation being presented.

• Users need to be able to independently scroll the information inthe different panes.

• Users will need to see simultaneously see portions of theinformation in the two different panes.

• Having different panes enables users to more easily navigatewithin the information space (for example, scope pane, and resultspane).

Chapter 9 337


Guidelines for Group BoxesIf used appropriately group boxes can be beneficial to the userperformance, however, if used inappropriately they simply take up spaceand can create visual clutter in the dialog box.

When using group boxes adhere to the following guidelines:

Recommended All controls and fields inside the group box should be meaningfullyrelated.

Required Group boxes should not be placed inside of other group boxes.

Recommended Labeling of group boxes should adhere to the following guidelines:

• Label group boxes with a meaningful name the indicates the overallpurpose of the controls inside the group box.

Make sure that the label is related to all controls inside the groupbox.

• Place the label in the top border of the group box.

• The group box label exceeds the length of the controls and labelsinside the group box, extend the width of the group box by 7 dialogbase units beyond the label.

Recommended The spacing and alignment of group boxes should adhere to the followingguidelines:

• Maintain a consist spacing (4-7 dialog base units) above, below, to theleft, and the right of the controls and labels inside the group box.

• Leave a minimum 7 base dialog units between the group box and theedge of the window or dialog box in which it is contained.

• Align the items within the group box (for example, left align checkboxes or radio buttons).

Recommended In windows with multiple group boxes and multi columns, create abalanced appearance by maintaining equal group box widths and groupbox heights as much as practical.

Recommended If more than one group box is incorporated within a column on a dialogbox, then:

338 Chapter 9


• Align the controls within the group boxes following the guidelinespresented earlier.

• Align the left and right borders of all group boxes.

Panes

Recommended Use panes with size controls to enable the user to adjust the relative sizeof each pane to suit the current task.

Recommended The default size of a pane should be sufficient for the user to easily accessand use all controls contained within the pane.

Optional In a multi-pane window provide a clear indication as to which panecurrently has input focus.

If users are navigating via the keyboard, it will be important to easilydetect the pane that is receiving input from the keyboard. Examples of avisual cues for input focus are a black box around the pane with inputfocus or the presence of the blue selection cursor.

Expanding panes are panes which are not continuously visible but whichbecome visible when the user presses a push button or sets a togglebutton.

Recommended Adhere to the following guidelines when expanding panes are used:

• Only use expanding panes to minimize the size of dialog boxes andwindows, or to minimize screen clutter by hiding unnecessaryinformation until it is requested by the user.

• Do not put material in expanding panes if it will be needed every timethe user accesses the window.

339

10 Miscellaneous Guidelines

340 Chapter 10

Miscellaneous Guidelines

This chapter presents general guidelines for the localization andinternationalization of user interfaces.

In general, you should follow guidelines for the platform upon whichyour application is built. There are several HP OpenView-specificguidelines presented in this chapter. The HP OpenView guidelines canbe implemented following the steps in the HP OpenView IntegrationSeries: OVW Developer’s Guide.

Other references that you may want to consult are listed below:

• X Windows on the World, by Thomas C. McFarland (Prentice HallPTR, 1996)

• Programming for the World, Sandra Martin O’Donnell (Prentice HallPTR, 1994)

Chapter 10 341

Miscellaneous GuidelinesInternationalization and Localization of the User Interface

Internationalization and Localizationof the User InterfaceInternationalized user interfaces are interfaces that can be tailored for aspecific country, culture or language without modifications to applicationcode and without recompiling or relinking code. They may or may notinclude translation of texts (within the user interface) into a languageother than English.

Internationalized user interfaces are interfaces that have all of thefollowing characteristics:

• Can be localized (texts can be translated into other languages).

• Can display monetary, date, time, and numeric data in a localespecific manner.

• Can display data sorted and collated in a locale-specific manner canaccept multibyte data input from end users on various types of data,except hostnames and login names.

• Can store data in a manner so that it can be displayed to users asmultibyte. In addition, they should maintain data integrity as thedata are manipulated in the code.

• Can install in a non-locale specific manner so that a singleinstallation can be used by various users under various locales (notnecessarily simultaneously).

• Can switch locale based on the user’s preference. For example, onUNIX systems, use XPG4 locale category environment variables, suchas LANG or LC_ALL.

• Allow externally visible data to be shared across multiple locales.

• Use locale-specific fonts (may or may not be the fonts specified by theend user of the subsystem). On UNIX systems, use font sets. OnWindows NT systems, use the localized version of Developer Studio toedit and create localized resource files. This ensures that correct fontsare selectable for the user’s language.

In most cases, a subsystem that follows the ANSI locale model will beinternationalized. Follow the style guide for the operating system onwhich you are delivering your product when preparing your applicationfor international markets.

342 Chapter 10


Localization of the User Interface

Recommended When attempting to make your product localizable, you need to ensurethat all areas of the user interface can display localized text as an outputto the end user. Throughout your various user interface subsystems, thetexts that appear in the following user interface components areexpected to have the ability to display multibyte texts based on the localespecified by the end user:

• Labels, including button labels, text labels, and symbol labels.

• Pull-down and pop-up menu names.

• Dialog box titles; for example, the string that is displayed by thewindow manager in the frame of a window.

• Text, including text all dialog boxes and messages boxes, text thatappears in message and status areas, and text indicating mappermissions.

• Names, including file, directory, end user, application, map, submap,symbol class, symbol type, and API action names.

When implementing the user interface, applications should allow forlocalization for as much of their user interface as possible. However,some things are not localizable. For example, product names are usuallynot translated because there is a copyright associated with thetranslated string.

Helpful Hints for InternationalizingHP OpenView Applications

Recommended To support internationalized data in the user interface componentsmentioned above, it is important to design the interface forHP OpenView applications using the following guidelines:

• Use the guidelines for the platform upon which your application isbuilt.

• Assume left-to-right and top-to-bottom ordering of information(acceptable for HP OpenView-related user interface).

• Assume that arabic numbers (1, 2, 3, etc.) are acceptable inHP OpenView-related software. Expect that the user will use the USformat of floating point numbers.

Chapter 10 343


• Assume that the hostnames and UNIX login names contain strictly7-bit characters (networking software does not allow multibytecharacters in those areas).

• Do not assume that one column = one character. Most Asiancharacters require two columns per character.

• Do not use bold face and italic fonts to differentiate from non-bold andnon-italic fonts, or be sure that the fonts can be localized. Not allmultibyte fonts can be bold faced or italicized.

• Do not assume that words are separated by a space. Some languagesdo not separate words with a space character.

• Do not assume that special characters (such as ?, !, “) exist within alanguage.

• Do not assume the existence of a period (.) to end a sentence. Somelanguages do not end their sentences with a period.

• Do not build English grammar into the user interface. For example, amenu command that spells out the English sentence using a cascademenu Display->data->using->graphs will be very difficult (if notimpossible) to localize. Another example of a non-localizable interfaceis one that requires an end user to fill in the blanks, as in searchfor ______ in the _____ file .

• Do not use X or check marks to imply OK or not OK; show legends forsymbols if necessary.

• Do not use abbreviated English characters. For example, using D nextto map names to indicate the Default map is not intuitive tonon-English speaking users. Also, the letter D cannot be translatedeasily.

• Do not assume that short (or long) English words are short (or long)words in other languages. Allow the user interface component (forexample, the text widget or the push-button widget) to shrink orexpand based on varying sizes of words.

• Do not assume that the characters can be displayed using fontssmaller than 14 pixels wide. For example, most Asian characters arecompletely unreadable when displayed using fonts that are smallerthan 14 pixels wide.

344 Chapter 10


• Do not assume that American/Western color coding conventions (forexample, green = go or OK, blue ribbon = first place) will apply toyour customers. Allow users to customize the colors used in yourapplication.

• Do not use graphics for symbols or icons that have the potential foroffending user, or that have different meanings in different cultures.For example, graphics that contain body parts, such as a hand, maybe viewed as offensive in some cultures. As another example, in theUS, a black cat is a symbol of bad luck, while in the UK it is a symbolof good luck.

345

11 Guidelines for ProductDocumentation

346 Chapter 11

Guidelines for Product Documentation

This chapter presents recommendations for designing the manuals thataccompany your HP OpenView application. These recommendations areimportant because they:

• Maintain a consistent organizational approach to userdocumentation. Users will be able to move from one application toanother and find the same information flow throughout the productmanuals.

• Help users learn the application more quickly because they can findinformation more easily.

• Provide consistency in design, content, and organization. Thisenhances the integration of the many HP OpenView applications.

Chapter 11 347

Guidelines for Product DocumentationStructure of the Documentation Set

Structure of the Documentation SetHewlett-Packard has adopted a set of editorial guidelines for productdocumentation that help documentation developers create manuals thatare not only highly usable, but also have a consistent, uniform structureand appearance across HP OpenView products.

HP OpenView recommends that Hewlett-Packard developers ofapplications for HP OpenView follow the latest version of the HPguidelines, paying particular attention to the items outlined in thischapter.

Third-party developers are urged to follow, at minimum, the guidelinesthat are presented here.

Types of DocumentationHP identifies six basic types of manuals, which define a basic structurefor meeting the needs of users, based on their knowledge level andlearning needs.

• Quick Start Guide—a one-glance overview of the product and a fewtask instructions to help the user get comfortable.

• Task Reference—a complete set of task instructions andproblem-solving guidelines, with a few basic concepts. This is oftenthe basis for a Users’ Guide.

• Reference Guide—descriptions of the product in a dictionary orencyclopedia format.

• Concept Guide—topics that explain concepts and apply them toadvanced tasks.

• Installation Guide—instructions for installing and configuring theproduct.

• Quick Reference—tables, syntax lists, menu trees, and briefinstructions that help the user remember details.

348 Chapter 11


A Modular ApproachStart by identifying the information that is most important for the typeof manual. This information may be task or tutorial instructions,problem-solving instructions, descriptions of product features, orconceptual topics.

Such information is organized in modules. One task, one problem, onefeature description, or one topic forms a single module. All modules ofthe same type have the same structure, with the same kind of heading.See Figure 11-1.

Chapter 11 349


Figure 11-1 Organizing Information into Modules

Developers of applications for HP OpenView Windows are urged to thinkof their documentation in terms of modules, as this concept is very usefulin organizing documentation.

Grouping the ModulesOnce you have conceptually organized the information you want toinclude into modules, you group the modules together to form themanual. One of the decisions you need to make is how many manuals

Task Module 1

Task Module 3

Task Module 2

Topic Module 1

Topic Module 2

Topic Module 3

Problem Module 1

Problem Module 2

Problem Module 3

Concept Module 1

Concept Module 2

Concept Module 3

350 Chapter 11


you will use to document your product. The six different types ofmanuals do not necessarily represent six different books for eachproduct.

Several types of manuals can be combined. For example, you cancombine concept modules and task modules into one user’s guide.You cangroup tasks by types of tasks, or can group them by type of audience,such as operators or administrators. You may decide that you need twoor three books to meet the needs of distinct audiences for the product.

The most common grouping of modules results in an installation guide(which may contain system administration information), a users’ guide,and a reference guide. Some products also need a developer’s guide.

Ask yourself the following questions to help you determine the number ofmanuals that will document your product:

• Who is the user for your product, and thus the audience for yourbook? Are there multiple users with different needs? For example,will your product be installed, configured, and administered by oneperson and used by another?

• Are there different kinds of end users for your product? Will one bookaddress the knowledge level of all users, or would it be better to have,for example, a users’ guide for beginning users and a reference guidefor more advanced users?

• How complex is your product? Is the information better presented inseparate books?

Recommendations for the Documentation SetFollowing is a list of recommendations for the structure of yourdocumentation set.

• Individual products should each have individual manuals. Forexample, do not combine reference information for multiple productsinto one reference guide.

• Do not combine different types of manuals into a single book, unlessthere is compelling reason to do so. For example, keep installationinformation separate from reference information.

Examples of when it is acceptable to combine different types ofmanuals into one book include:

Chapter 11 351


• Yours is a simple product, easy to install and use, and the personinstalling the product is the same person using or administeringthe product. In that case, it is acceptable to combine installationinformation with information on using the product or withadministration information in one manual.

• Economic reasons prevent multiple manuals. In this case, youshould clearly separate the various types of modules (task,concept, tutorial, reference) from each other.

• If you provide your documentation online only, you should provide aprinted Getting Started guide that lets the user know how to start theproduct and where to find the online documentation.

In addition, you should consider a desktop publishing system that meetsthe future needs of your documentation set. If you are going to besharing your documentation set with another company, choose apublishing system that can be translated or exported into a format thatcan be shared.

352 Chapter 11

Guidelines for Product DocumentationStructure of Individual Manuals

Structure of Individual ManualsOnce you have decided on the overall structure of your documentationset, you need to design each individual manual. In addition to groupingthe modules in a logical, organized manner, you need to add supportingelements. These include:

• Section and chapter introductions.

• Table of Contents, Table of Figures, Table of Tables.

• Index.

• Glossary.

• Graphics.

• Learning products map.

Recommendations for Information AccessThe goal of any documentation is to help users learn how to use yourproduct. Key to that process is helping users find information quickly. Ifusers can find the information that they need, they will becomeproductive more quickly.

These recommendations will help the user find the information needed tolearn how to use your product:

• Include the chapter heading plus two levels of subheadings in theTable of Contents.

• Include List of Tables and List of Figures.

• Include a documentation map that lets the user know what othermanuals are available for your product, and what types ofinformation can be found in each book.

• Include a book introduction that helps the reader understand whatinformation the book contains. You may include a quick overview ofthe product’s capabilities from the user point of view.

• Provide an index with multiple listings and cross references. Use bothnoun-oriented and verb-oriented entries.

Chapter 11 353


• Use headers and/or footers. These should contain chapter numberand/or title and section headings. Include page numbers in either theheader or the footer.

• Provide a glossary if you are introducing new terms and/or are usingany terms that are industry-specific or could be easily misunderstood.

• Choose a binding method for your book such that it can be laid flatwhile the user is using it.

• When you combine multiple manuals into one book, separate thesections with tabs, preferably hard tabs with labels, to help the userfind information.

Recommendations for InformationUnderstandingRegardless of whether you are presenting task information, conceptinformation, procedural information, or reference information, the wayin which you present that information is key to user understanding.

The following recommendations will help your user more easilyunderstand the information you are presenting.

• Use introductions to describe what each section or chapter covers, orwhat the procedures will cover. Describe the tasks or procedures fromthe user’s point of view.

• Use bulleted lists wherever possible, rather than long sentences orparagraphs.

• Use numbered lists to describe steps or procedures.

• Keep procedures free from conditional steps. If necessary,reorganize the information to accomplish this.

• Explain what should result when the user completes the stepcorrectly.

• Provide troubleshooting information immediately before or after theprocedure whenever possible. If not feasible, then direct the userwhere to look for troubleshooting information.

• Include a section or chapter on errors and troubleshooting. Explainwhat caused the error to occur and how to correct it.

354 Chapter 11


• Include figures and graphics to help illustrate concepts andcomplicated procedures. Figures and graphics should be kept simple,and may contain callouts when appropriate to further describe whatyou are illustrating. Number and caption all figures and graphics,and reference them in the related text.

• Use tables to present complex information in tabular format. Numberand caption all tables, and reference them in the related text.

• Use different typefaces to present different elements, such as filenames, command names, user input, computer output, etc. Provide atable in the introduction of your book that explains the typefaces, anduse them consistently throughout the book.

• Use heading formats consistently. The hierarchy of heads should beeasily distinguishable to the reader.

• Keep 10% to 20% white space throughout your book.

• Use consistent verbs to describe how the user interacts with thecomputer or the software. For example:

• Click on the [OK] button or click [OK] .

• Select an item in a list.

• Press a key on the keyboard.

Recommendations for LocalizationIf you are planning on having your documentation translated fromEnglish into other languages, you should follow these guidelines.

• Keep a minimum of 20% white space around text. Many languagesexpand when translated from English.

• Avoid using idioms, acronyms, slang, and jargon.

• Use clear and consistent English text. Keep sentences short; usesimple words.

• Avoid using words that have multiple meanings.

• Do not use words or graphics that could have special culturalmeaning.

355

A HP OpenView LauncherCategories

356 Appendix A

HP OpenView Launcher CategoriesObject Tab Categories

Object Tab CategoriesThe following categories have been defined as the top level items for theObjects tab in the HP OpenView Web Launcher. These categories willonly be visible in the launcher when there are one or more entriesbeneath the category.

• Object Views

This is the top level or root item for this tab. All other categories andaccess points to applications that provide views are listed under thiscategory.

• Customers

Views that show managed objects from the perspective of thecustomer: views of customers; views of managed objects or serviceswithin the customer organization.

• Devices

Views that show managed objects grouped in terms of the type ofdevice, or views of devices in their context of use. Devices includerouters, switches, hubs, printers, tape drives, hard disks, andothers.

• IT Resources and Applications

Views of the organizational structure of the IT group and/or thehardware and software used by the IT group for providingmanagement services: OpenView users, management systems,management applications.

• Networks

Views that show managed objects based on a network topology: IP;IPX; SNA; and others.

• SLA’s and Services

Views of service level agreements or views of objects that aregrouped together because they are involved in providing a specificservice.

• Software

Appendix A 357

HP OpenView Launcher CategoriesObject Tab Categories

Views that show software objects that are being managed:applications; licences; data.

• Systems and Servers

Views of managed objects from the point of view of the systemsadministration or server administration with hierarchies based onthe resources contained within the systems and servers.

• Telecom Resources

Views of the organizational structure of Telecom managementgroup and the resources that are used by the group for providingmanagement of the infrastructure used in providing telecomservices: OpenView users; individuals in the NOC; managementapplications, and others.

• Other Objects

Views of objects that do not readily fit into the other categories ofobject views.

358 Appendix A

HP OpenView Launcher CategoriesTask Tab Categories

Task Tab CategoriesThe following categories have been defined as the top level items for theTasks tab of the HP OpenView Web Launcher. These categories will onlybe visible in the launcher when there are one or more entries beneath thecategory.

• Tasks

This is the top level or root item for this tab. All other categories andaccess points to applications that provide tasks in the form of taskpresentation mangers, wizards, or tabbed dialogs are listed underthis category.

• Accounting and Asset Management

Tasks related to asset management: record keeping for objectsbeing managed; tracking of systems, devices, and applications;review of available assets; and setup and customization ofmanagement capabilities for accounting and asset management.

• Change Management

Tasks related to change management: configuration of managedobjects (for example, systems, servers, routers, networks, andsoftware); tracking of configuration changes; and setup andcustomization of management capabilities for configuration andchange management.

• Fault Management and Diagnostics

Tasks related to the trouble shooting and resolution of problems inthe network and system management environment: connectivitydiagnosis; performance diagnosis; handling of events or alarms;setup and customization of management capabilities for faultmanagement.

• Information and Reporting

Tasks related to the access of information and reports on themanaged environment: generation of reports; data collection; andsetup and customization of capabilities for data collection andreporting.

Appendix A 359

HP OpenView Launcher CategoriesTask Tab Categories

• Resource and Performance Management

Tasks related to monitoring and regulation of the performance inthe network and systems management environment: performancemonitoring, modifications in the infrastructure to improveperformance; setup and customization of management capabilitiesfor performance management.

• Security Management

Tasks associated with the management of the security of thenetwork and systems environment: setting up mechanisms tocontrol access to network and system resources; auditing of access;modification of access privileges; setup and customization ofmanagement capabilities for security management.

• SLA’s and Service Management

Tasks related to creating and maintaining Service LevelAgreements (SLA’s) and service management: creating andmaintaining Service Level Agreements (SLA’s); managing servicesbased on SLA’s; and setup and customization of managementcapabilities for service management.

• Software and Data Distribution

Tasks related to software and data distribution: installation andupdating of software (e.g., operating systems, applications);distribution of data within the network and systems environment;setup and customization of management capabilities for softwareand data distribution.

• Storage, Back Up, and Recovery

Tasks related to the setup and maintenance of backup andrecovery and storage management: storage management;maintenance of storage devices; tracking of storage space; mediamanagement; interactive and automated backups; recovery offiles, directories or other data sources; setup and customization ofmanagement capabilities for storage management and backupand recovery.

360 Appendix A

HP OpenView Launcher CategoriesInformation and Reporting Tab Categories

Information and Reporting TabCategoriesThe following categories have been defined as the top level items for theInformation and Reporting tab of the HP OpenView Web Launcher.These categories will only be visible in the launcher when there are oneor more entries beneath the category.

• Information and Reporting

This is the top level or root item for this tab. All other categories andaccess points to applications that provide tasks in the form of taskpresentation mangers, wizards, or tabbed dialogs are listed underthis category.

• Accounting and Assets

Information and reports related to asset management: reports onthe systems, devices, applications and data in the organization.

• Configuration Information

Information and reports related to the current configuration orconfiguration changes to managed objects (for example, systems,servers, routers, networks, and software)

• Faults and Alarms

Information and reports related to faults that have occurred in themanaged environment and resolution of problems.

• Resource and Performance Management

Information and reports related to usage and availability ofresources and the performance of these resources (for example,networks, systems, and software).

• Security

Information and reports associated with the security of thenetwork and systems environment: logins, access to systems,attempts to breach security, and others.

• SLA’s and Service Management

Appendix A 361

HP OpenView Launcher CategoriesInformation and Reporting Tab Categories

Information and reports related to Service Level Agreements(SLA’s), the services being provided, management tasks, andservice performance relative to the criteria specified in the servicelevel agreements.

• Software and Data Distribution

Information and reports related to software and data distribution,including what software and data has been distributed.

• Storage, Back Up, and Recovery

Information and reports related backup and recovery and datastorage including reports on frequency and success of backup andrecovery, location and movement of data for storage purposes.

362 Appendix A

HP OpenView Launcher CategoriesTool Tab Categories

Tool Tab CategoriesThe tool tab in the HP OpenView Web Launcher allows applicationdevelopers more freedom in identifying categories for portions of theirapplications. The tool tab should contain the name or initials of theapplication as a category entry with portions of the application that areexecutable as separate user interfaces being listed under the application.If an application has a lot of functionality that can be grouped underdifferent category headings, it may be desirable to have category items asentries under the application.

Potential Tool Tab Entries for NNM and ITO are presented below asexamples:

• Network Node Manager (NNM)

• Network Views

• NNM Reports

• Data Presenter

• Data Collector

• Application Builder

• IT/Operations (ITO)

• Message Browser

• ITO Configuration Views

• ITO Operational Views

• ITO Tasks

363

B Mnemonics and Accelerators

364 Appendix B

Mnemonics and Accelerators

Table B-1 Common Accelerator Key Assignments in HP OpenView

Table B-2 Common Mnemonic Access Key Assignments in HP OpenView

Keyboard Sequence Meaning

Ctrl + C Copy

Ctrl + O Open

Ctrl + P Print

Ctrl + S Save or Apply

Ctrl + V Paste

F1 Help

Esc Cancel

Alt + Enter Display property sheet forcurrent selection

Shift + F10 Display pop-up menu

Key Assignment Menu Item or Push ButtonLabel

a About

a Action

a Apply

a Save As

a Select All

b Back

c Close

c Copy

d Delete

e Edit

Appendix B 365


e Explore

f File

f Find

f Finish

h Help

h Hide

m Move

n New

n Next

o Open

p Paste

p Print

q Quick Navigator

r Properties

r Refresh

s Save

s Show

t Cut

t Help Topics

v View

w Window

x Exit

Key Assignment Menu Item or Push ButtonLabel

366 Appendix B


367

C Color Mapping and Palettes

368 Appendix C

Color Mapping and PalettesUsing Color in Web Page Design

Using Color in Web Page DesignThis chapter explains the guidelines for specifying the color values forvarious features on your Web site pages. These color values are providedwithin two color palettes, each one having a specific set of color values forspecific types of Web graphics.

Color Palettes Used in HP OpenViewIn an HP OpenView environment, there are two types of color palettesyou can use when creating Web elements such as illustrations,navigational aids, and other types of graphics.

• A “limited” color palette, for use in small graphics (such as thoseappearing on buttons in a toolbar).

• An “expanded” color palette, for use with large images and graphicspresented in a web browser.

NOTE The limited palette is a subset of the expanded palette. This means thatthe color values in the limited palette are also included in the expandedpalette.

Palette ContentsIn the next two sections, the color values for each palette are listed in atable. For each color value, you will see a column for its hexadecimalvalue and a column for its decimal value. Browsers typically requirecolor values to be stated in hexadecimal. Conversely, many graphicsediting programs use digital (decimal) values for their RGB values.

Appendix C 369

Color Mapping and PalettesUsing the Limited Color Palette

Using the Limited Color PaletteThe colors in this palette type are intended for use in creating veryspecific graphic types: icons and status colors. On Web pages and in HPOpenView applications, you will find icons being used in such features astoolbar buttons and object icons. HP OpenView applications also usestatus colors to indicate the current state of objects (an example would bea Network Node Manager submap on which several nodes and serversare shown to be disabled).

For these graphic types and status, you should use only those colorvalues provided in the limited color palette.

The limited color palette is available in the file hppal.gif .

You can display this color palette by doing the following steps:

1. Open your web browser.

2. Open the file, hppal.gif , in the browser.

NOTE Be careful when using gray colors. Gray colors do not displayconsistently when formatted as nondithered colors across the threebrowsers tested with the limited palette.

Color Values in the Limited Color PaletteIn the chart below, each color value is listed by a name, a Hexadecimalvalue, and a Decimal (RGB) value. The name used in color table would bethe color name that you would use in specifying a background color orother color in html. The final column indicates the HPOpenView-standardized usage for a particular color value whenever thatvalue is not being used within icons. For example, you should use the“Dark Brown” color value to indicate an object’s disabled status.

370 Appendix C


Table C-1 Color Values in the Limited Color Palette

ColorName

HexValue

DecimalValue

HP OpenView usage(other than icons)

Blue 00 00 FF 0 0 255

Green 00 FF 0 0 255 0 Normal status

Red FF 0 0 255 0 0 Critical status

Yellow FF FF 00 255 255 0 Minor status

Orange FF 80 00 255 128 0 Major status

Dark Blue 00 00 80 0 0 128 Selection indication

Dark Green 00 80 00 0 128 0

Dark Red 80 00 00 128 0 0

Gold 80 80 00 128 128 0

Dark Brown 64 00 00 100 0 0 Disabled status

Light Blue 00 80 FF 0 128 255 Unknown status

Cyan 00 FF FF 0 255 255 Warning status

Magenta FF 00 FF 255 0 255

Light Pink FF 80 FF 255 128 255 Restricted status

Tan FF BF 66 255 191 102 Testing status

Teal 00 80 90 0 128 128

Purple 80 00 80 128 0 128

Off-white FF FF CC 255 255 204 Unmanaged status

White FF FF FF 255 255 255 Background for labels

Appendix C 371


a. Dithered on Internet Explorer.b. Dithered on UNIX Netscape.

Gray (0) a C0 C0 C0 192 192 192 Map background/Transparent color

Gray (1) b CB CB CB 203 203 203

Gray (2) b 98 98 98 152 152 152 S

Gray (3) b 66 66 81 102 102 129

Gray (4) 33 33 4F 51 51 79

Black 00 00 00 0 0 0 Text

ColorName

HexValue

DecimalValue

HP OpenView usage(other than icons)

372 Appendix C

Color Mapping and PalettesUsing the Expanded Color Palette

Using the Expanded Color PaletteThe colors in this palette type have been tested with Microsoft’s InternetExplorer on Windows NT and with Netscape on Windows NT and UNIX.All colors (with the exception of the grays) have been found to displayapproximately the same hue without dithering. Therefore, the colors inthis palette should be safe to use for larger graphics or blocks of color.

The expanded color palette is in the file largepal.gif .

You can display this color palette by doing the following steps:

1. Open your web browser.

2. Open the file, largepal.gif , in the browser.

NOTE Be careful when using gray colors. Gray colors do not displayconsistently when formatted as non-dithered colors across the threebrowsers tested with the limited palette.

Color Values in the Expanded Color PaletteIn the chart below, each color value is listed by both its hexadecimalvalue and its Decimal (RGB) value. A check mark (3) appearing before acolor in the “LP” column means this color is also included in the limitedcolor palette as well as the expanded palette. And you can use the lastcolumn, “Cell Location in .gif File” to view onscreen the exact colorswatch for a particular color value in the largepal.gif file.

Table C-2 Color Values in the Expanded Color Palette

LP Hex Value DecimalValue

Cell Location in .gifFile

3 00 00 00 0 0 0 Row 1 , Column 1

0 0 33 0 0 51 Row 1 , Column 2

0 0 66 0 0 102 Row 1 , Column 3

3 00 00 80 0 0 128 Row 1 , Column 4

0 0 99 0 0 153 Row 1 , Column 5

0 0 CC 0 0 204 Row 1 , Column 6

0 0 ED 0 0 237 Row 1 , Column 7

Appendix C 373


3 00 00 FF 0 0 255 Row 1 , Column 8

0 40 0 0 64 0 Row 1 , Column 9

0 40 33 0 64 51 Row 1 , Column 10

0 40 66 0 64 102 Row 2 , Column 1

0 40 99 0 64 153 Row 2 , Column 2

0 40 CC 0 64 204 Row 2 , Column 3

0 40 FF 0 64 255 Row 2 , Column 4

3 0 80 0 0 128 0 Row 2 , Column 5

0 80 33 0 128 51 Row 2 , Column 6

0 80 66 0 128 102 Row 2 , Column 7

3 0 80 80 0 128 128 Row 2 , Column 8

0 80 99 0 128 153 Row 2 , Column 9

0 80 CC 0 128 204 Row 2 , Column 10

3 0 80 FF 0 128 255 Row 3 , Column 1

3 00 FF 00 0 255 0 Row 3 , Column 2

0 FF 33 0 255 51 Row 3 , Column 3

0 FF 66 0 255 102 Row 3 , Column 4

0 FF 99 0 255 153 Row 3 , Column 5

0 FF CC 0 255 204 Row 3 , Column 6

3 00 FF FF 0 255 255 Row 3 , Column 7

3 33 33 4F 51 51 79 Row 3 , Column 8

40 0 0 64 0 0 Row 3 , Column 9

40 0 33 64 0 51 Row 3 , Column 10

40 0 66 64 0 102 Row 4 , Column 1

40 0 99 64 0 153 Row 4 , Column 2

40 0 CC 64 0 204 Row 4 , Column 3

40 0 FF 64 0 255 Row 4 , Column 4

40 40 0 64 64 0 Row 4 , Column 5

40 40 33 64 64 51 Row 4 , Column 6



374 Appendix C


40 40 66 64 64 102 Row 4 , Column 7

40 40 99 64 64 153 Row 4 , Column 8

40 40 CC 64 64 204 Row 4 , Column 9

40 40 FF 64 64 255 Row 4 , Column 10

40 80 00 64 128 0 Row 5 , Column 1

40 80 33 64 128 51 Row 5 , Column 2

40 80 66 64 128 102 Row 5 , Column 3

40 BF 0 64 191 0 Row 5 , Column 4

40 BF 33 64 191 51 Row 5 , Column 5

40 BF 66 64 191 102 Row 5 , Column 6

40 BF 99 64 191 153 Row 5 , Column 7

40 BF FF 64 191 255 Row 5 , Column 8

40 FF 00 64 255 0 Row 5 , Column 9

40 FF 33 64 255 51 Row 5 , Column 10

40 FF 66 64 255 102 Row 6 , Column 1

40 FF 99 64 255 153 Row 6 , Column 2

40 FF CC 64 255 204 Row 6 , Column 3

40 FF FF 64 255 255 Row 6 , Column 4

55 1A 8A 85 26 138 Row 6 , Column 5

3 64 00 00 100 0 0 Row 6 , Column 6

3 66 66 81 102 102 129 Row 6 , Column 7

3 80 00 00 128 0 0 Row 6 , Column 8

80 00 33 128 0 51 Row 6 , Column 9

80 00 66 128 0 102 Row 6 , Column 10

3 80 0 80 128 0 128 Row 7 , Column 1

80 00 99 128 0 153 Row 7 , Column 2

80 00 CC 128 0 204 Row 7 , Column 3

80 00 FF 128 0 255 Row 7 , Column 4

80 40 00 128 64 0 Row 7 , Column 5



Appendix C 375


80 40 33 128 64 51 Row 7 , Column 6

80 40 66 128 64 102 Row 7 , Column 7

80 40 99 128 64 153 Row 7 , Column 8

80 40 CC 128 64 204 Row 7 , Column 9

80 40 FF 128 64 255 Row 7 , Column 10

3 80 80 00 128 128 0 Row 8 , Column 1

80 80 33 128 128 51 Row 8 , Column 2

80 80 66 128 128 102 Row 8 , Column 3

80 80 99 128 128 153 Row 8 , Column 4

80 80 CC 128 128 204 Row 8 , Column 5

80 80 FF 128 128 255 Row 8 , Column 6

80 FF 0 128 255 0 Row 8 , Column 7

80 FF 33 128 255 51 Row 8 , Column 8

80 FF 66 128 255 102 Row 8 , Column 9

80 FF 99 128 255 153 Row 8, Column 10

80 FF CC 128 255 204 Row 9 , Column 1

80 FF FF 128 255 255 Row 9 , Column 2

3 98 98 98 152 152 152 Row 9 , Column 3

BF 0 0 191 0 0 Row 9 , Column 4

BF 0 33 191 0 51 Row 9 , Column 5

BF 0 66 191 0 102 Row 9 , Column 6

BF 0 99 191 0 153 Row 9 , Column 7

BF 0 CC 191 0 204 Row 9 , Column 8

BF 0 FF 191 0 255 Row 9 , Column 9

BF 40 0 191 64 0 Row 9 , Column 10

BF 40 33 191 64 51 Row 10 , Column 1

BF 40 66 191 64 102 Row 10 , Column 2

BF 40 99 191 64 153 Row 10 , Column 3

BF 40 CC 191 64 204 Row 10 , Column 4



376 Appendix C


BF 40 FF 191 64 255 Row 10 , Column 5

BF 80 0 191 128 0 Row 10 , Column 6

BF 80 33 191 128 51 Row 10 , Column 7

BF 80 66 191 128 102 Row 10 , Column 8

BF 80 99 191 128 153 Row 10 , Column 9

BF 80 CC 191 128 204 Row 10 , Column 10

BF 80 FF 191 128 255 Row 11 , Column 1

BF FF 0 191 255 0 Row 11 , Column 2

BF FF 33 191 255 51 Row 11 , Column 3

BF FF 66 191 255 102 Row 11 , Column 4

BF FF 99 191 255 153 Row 11 , Column 5

BF FF CC 191 255 204 Row 11 , Column 6

BF FF FF 191 255 255 Row 11 , Column 7

3 C0 C0 C0 192 192 192 Row 11 , Column 8

3 CB CB CB 203 203 203 Row 11 , Column 9

FE 00 00 254 0 0 Row 11 , Column 10

FE FE CB 254 254 203 Row 12 , Column 1

3 FF 00 00 255 0 0 Row 12 , Column 2

FF 0 33 255 0 51 Row 12 , Column 3

FF 0 66 255 0 102 Row 12 , Column 4

FF 0 99 255 0 153 Row 12 , Column 5

FF 0 CC 255 0 204 Row 12 , Column 6

3 FF 00 FF 255 0 255 Row 12 , Column 7

FF 40 0 255 64 0 Row 12 , Column 8

FF 40 33 255 64 51 Row 12 , Column 9

FF 40 66 255 64 102 Row 12 , Column 10

FF 40 99 255 64 153 Row 13 , Column 1

FF 40 CC 255 64 204 Row 13 , Column 2

FF 40 FF 255 64 255 Row 13 , Column 3



Appendix C 377


3 FF 80 0 255 128 0 Row 13 , Column 4

FF 80 33 255 128 51 Row 13 , Column 5

FF 80 66 255 128 102 Row 13 , Column 6

FF 80 99 255 128 153 Row 13 , Column 7

FF 80 CC 255 128 204 Row 13 , Column 8

3 FF 80 FF 255 128 255 Row 13 , Column 9

3 FF BF 66 255 191 102 Row 13 , Column 10

3 FF FF 0 255 255 0 Row 14 , Column 1

FF FF 33 255 255 51 Row 14 , Column 2

FF FF 66 255 255 102 Row 14 , Column 3

FF FF 99 255 255 153 Row 14 , Column 4

3 FF FF CC 255 255 204 Row 14 , Column 5

3 FF FF FF 255 255 255 Row 14 , Column 6



378 Appendix C


379

D Bibliography

380 Appendix D

Bibliography

Baddeley, A. Human Memory: Theory and Practice. Needham Heights,MA. Allyn and Bacon.

Baecker, R.M., Grudin, J., Buxton, W.A.S., and Greenberg, S. (Eds.)Human Computer Interaction: Toward the Year 2000. Los Altos, CA:Morgan Kaufmann, 1995.

Beyer, H., and Holtzblatt, K. Contextual Design: DefiningCustomer-Centered Systems. San Francisco, CA: Morgan KaufmannPublishers, Inc., 1998

Bezanson, W. “Designing electronic performance support systems.”Innovations in Education and Training International, 32 (1), 56-64,1995.

Carroll, J.M. (Ed.) Designing Interaction: Psychology at theHuman-Computer Interface. Cambridge, MA: Cambridge UniversityPress, 1991

Constantine, L. “Usage-Centered Software Engineering: New Models,Methods, and Metrics.” In Proceedings of the 1996 InternationalConference on Software Engineering: Education and Practice, Duendin,New Zealand: New Zealand Computer Society, 1996.

Carlshamre, P. and Karlsson, J. “A Usability-Oriented Approach toRequirements Engineering.” In Proceeedings of the Second InternationalConference on Requirements Engineering.” April 15-18, ColoradoSprings, CO. p. 52. Los Alamitos, CA: IEEE Computer Society Press,1996.

Dumas, J. S. and Redish, J.C. A Practical Guide to Usability Testing.Norwood, N.J.: Ablex Pub. Corp., 1993.

Greenbaum, J., and Kyng, M (Eds). Design at Work: Cooperative Designof Computer Systems. Mahwah, NJ: Lawrence Erlbaum Associates, 1991.

Hefley, W., et al. “Integrating Human Factors with Software EngineeringPractices.” In Proceedings of the Human Factors and Ergonomics Society,39th Annual Meeting, October 24-28, Nashville, TN, pp. 315-319, SantaMonica, CA Human Factors and Ergonomics Society, 1994.

Hix, D. and Hartson, H.R. Developing User Interfaces: EnsuringUsability Through Product and Process. New York, NY: Wiley, 1993.

Holtzblatt, K., and Beyer, H. (Eds) “Requirements Gathereing: TheHuman Factor.” Communications of the ACM/Special Issue, 38(5), May,1995.

Appendix D 381

Bibliography

Microsoft. The Windows Interface Guidelines for Software Design.Redmond, WA: Microsoft Press, 1995

Nielson, J. Hypertext and Hypermedia. Boston, MA: Academic Press,Inc., 1990.

Nielson, J. Usability Engineering. Boston, Mass.: Academic Press, 1993.

Norman, D.A. The Design of Everyday Things. New York, NY: Doubleday,1990.

Norman, D.A. Things That Make Us Smart. Reading, MA:Addison-Wesley.

Rubin, J. Handbook of Usability Testing: How to Plan, Design, andConduct Effective Tests. New York, N.Y.: Wiley, 1994.

Whiteside, J., Bennett, J., and Holtzblatt, K. “Usability Engineering: OurExperience and Evolution.” In Handbook of Human-ComputerInteraction, Martin Helander (Ed.). Amsterdam: Elseiver Science Pub.Co., 1988.

Wiklund, Michael, E. Ed. Usability in Practice: How Companies DevelopUser-Friendly Products. Boston, MA.: AP Professional, 1994.

Winogratd, T. and Flores, F. Understanding Computers and Cognition.Norwood, NJ. Ablex, 1986.

Winograd, T., (Ed) Bringing Design to Software. Reading, MA:Addison-Wesley, 1996.

382 Appendix D

Bibliography

Index

Index 383

Aaccelerators, 132actions

representing with symbols,196

alignmentin dialog boxes, 283

analog conrolsguidelines, 311

analog controlguidelines, 310, 311

analog controlsguidelines, 309placement, 310when to use, 310

application registration files,126, 138

applicationsaccessing from keyboard, 37quick access to, 38usability principles, 35

audiousing to provide cues, 37

Cchart presentation format, 163check box

default action, 301default value, 301guidelines, 300–301label, 300placement, 300, 302when to use, 300

child windowselection, 232, 236

colorcoding, 37Java System Color Variables,

64link color, 61

colorsin web applications, 61

using in symbols, 215combo box

default action, 307default value, 307guidelines, 305–307labels, 306list entries, 307visual cues, 307when to use, 306

combo boxeslabels, 306

complexityin dialog boxes, 285

compound presentation status,262

computer views, 181connection symbols

classes, 204connections

assigning symbols, 195container object, 186container objects

representation of, 180containment relationships, 38context, 224

concepts, 31effect on menus, 125effect on toolbars, 138generic, 224identifiers, 223session information, 54submap, 222

context areain web application, 74

context controls, 142context list, 142context tabs, 142

in multipurpose presentationmanagers, 97

contolsoption button, 296using symbols with, 285

control frame, 80

controls, 277analog controls, 309check box, 300default values, 286ellipsis in, 285gauge, 309graying, 285grouping, 332input validation, 288labeling, 284punctuation in label, 284push button, 291radio buttons, 298See also specific type, 291slider, 309spin box, 307text box, 303visual cues for, 285

conventionstypographical, 19universal pathnames, 19

cuesfilling connection symbols, 275flashing symbols, 270for drag and drop, 248for recursive selection, 239groups, 246highlighting, 269in graphics, 207in menus, 130in navigation tabs, 170in the scope pane, 150status colors, 259symbol alerts, 263transparent symbols, 271

customizationdescription bar, 140toolbars, 137

Ddefault action

check box, 301

384 Index

Index

combo box, 307gauge, 311grid, 327lists, 314multiple selection list, 314of option buttons, 297push button, 295radio buttons, 299single selection list, 314slider, 311spin box, 309table, 327text box, 305tree list, 320

default actionsuse of, 289

default valuecheck box, 301combo box, 307gauge, 311option button, 297radio buttons, 299slider, 311spin box, 309text box, 305

default valuescontrols, 286list box, 314table, 327tree list, 320

description bar, 140customization, 140

dialog boxes, 277alignment, 283complexity, 285controls, 291–338design, 279field sequencing, 283focus, 279help, 283menus, 280modal and modeless, 286push button placement, 292

resizing, 282size, 281title bar, 279

documentationaccessing information in, 352designing for audience, 349guidelines for structure, 347localizing, 354organizing, 348recommended contents, 352specific guidelines, 350types of manuals, 347

double clickingaffect on selection, 234

drag and drop, 248changes in instrumentation

space, 253containers as drop targets, 251drop target help (OVW), 254executable symbols (OVW),

254executable symbols as drop

targets, 252in OpenView Windows, 253leaf level symbols as drop

targets, 252views as drop targets, 249visual cues, 248

Eellipses, on button labels, 285environment variables, 19

for pathnames, 19events

using vs. visual cues, 258exception driven approach, 27executable symbols

appearance, 273

Ffield

defaults, 286

fieldsalignment, 283input validation, 288labeling, 284text box, 303

filtergrid, 325table, 325

filtersin the scope pane, 153

focusin dialog boxes, 279

font sizein dialog boxes, 280windows, 280

fontsin web applications, 66

form presentation format, 165for properties, 166

formsin web applications, 72

framesin web applications, 69, 71

Ggauge

default action, 311default value, 311guidelines, 309, 311labels, 310placement, 310

gaugeswhen to use, 310

geometry, 224graphical presentation format,

158graphics, 178, 206

creating, 212cues for classes, 202for actions, 213in HP OpenView Launcher, 51in toolbar buttons, 136

Index

Index 385

in web applications, 67localization, 214overlay, 216see also symbols, 178size, 212using existing, 206visual cues, 207

griddefault action, 327editing cells, 323filter, 325guidelines, 320–327input focus, 323keyboard navigation, 326labels, 323placement, 322selection, 326sequencing, 325when to use, 322

group boxes, 337group selection, 238

using containers, 239grouping

controls, 332guidelines, 332–338use of group box, 336use of line separator, 335use of panes, 336

groups, 244concepts, 34membership guidelines, 245properties, 245selection of, 247types of, 244views, 246

guageguidelines, 310

Hhelp, 133

on dialog boxes, 283highlighting symbols, 269

reporting status with, 269HP OpenView Web Launcher

see web launcher, 45HTML

using for web applications, 71

Iiconic presentation format, 158iconic presentation formats, 179

layout algorithms, 190icons

see symbols, 178images

in web applications, 67independent views, 190information coding principles,

36information presentation

managers, 93results pane, 95scope pane, 95when to use, 94

information updatein web applications, 69

input validation, 288

JJava applets, 55

in Java Frame, 55in web browser, 56

Java applications and applets,73

Kkeyboard access

in menus, 131, 132keyboard navigation

in a grid, 326in a table, 326in a tree list, 319in iconic presentation format,

158

in the scope pane, 144keyboard, to access application

actions, 37

Llabels

capitalization, 284check box, 300combo box, 306combo boxes, 306controls, 284for application actions, 38gauge, 310grid, 323in navigation tabs, 173list box, 312menus, 130option button, 297push button, 293radio buttons, 298single selection list box, 312slider, 310spin box, 308tab controls, 329table, 323text box, 302tree list, 316visual cues, 285

leaf level objects, 187representation of, 182

list boxdefault action, 314default values, 314find capability, 313guidelines, 311, 312, 313, 314,

315labeling, 312labels, 312placement, 312sequence of items, 313use of multiple selection, 312use of single selection, 311

386 Index

Index

listsgeneral guidelines, 313guidelines, 314logical sequence, 317selection, 231temporal sequence, 316

localization of documentation,354

Mmenu

design, 117menu bar, 117

File/container menu, 118general purpose menus, 118sequence, 123

menus, 117accelerators, 132Action, 121, 125affect of context, 125application registration files,

126depth/levels of menus, 129Edit, 118for managed objects, 120for navigation tabs, 169general purpose menus, 118Help, 118help for, 133in dialog boxes, 280in split windows, 107labels, 130mnemonics, 131number of items, 128pop-up/context, 124separators, 131sequence in menu bar, 123structure, defining, 127Tools, 125View, 118visual cues, 130

mnemonics, 131

multiple pane windows, 104when to use, 104

multiple purpose presentationmanagers, 96

context tabs, 97results pane, 97scope pane, 97when to use, 96

multiple selection, 232across results panes, 236across views, 234in the scope pane, 235

multiple selection listdefault action, 314

multiple selection list boxplacement, 312when to usf, 312

Nnavigation

in web applications, 68interaction with selection, 233

navigation tabs, 168in task presentation managers,

88, 90labels, 173menus, 169new windows, 171states of, 168visual cues, 170

new windowwith navigation tabs, 171

Oobject

hierarchies of, 180object presentation managers,

83results pane, 83scope pane, 83when to use, 83

objects

assigning symbols, 194container, 186creating a hierarchy of, 183leaf level, 187linked, 187placement in an existing

hierarchy, 182representing attributes, 188representing related objects,

188when to represent with

symbols, 179option button

default action, 297default value, 297guidelines, 296–298in Windows NT see radio

button, 296label, 297use of, 296

overlay graphics, 216overlay, submap window, 226

Ppanes, 338pathnames

environment variables, 19pathnames, universal. See

universal pathnamespersistent submaps, 221pictorial presentation formats,

159placement

analog controls, 310checkbox, 302checkboxes, 300gauge, 310grid, 322list box, 312multiple selection list box, 312of push buttons, 292radio buttons, 299

Index

Index 387

single selection list box, 312slider, 310spin box, 308tab controls, 329table, 322tree list, 315

pointer navigationin a tree list, 319

pop-up menus, 124in scope pane, 150

presentation formatsin the results pane, 156

presentation managers, 82concepts, 30information presentation

managers, 93multiple purpose presentation

managers, 96object presentation managers,

83task presentation managers,

85presentation manages

use of informationpresentation managers, 94

use of multiple purposepresentation managers, 96

use of object presentationmanagers, 83

use of task presentationmanagers, 86

principlesfor accessing actions, 37for general usability, 35for information coding, 36for representing relationships,

38progress indicator

in web applications, 57properties

presentation of, 166using a form presentation

format, 166

punctuation, in control label,284

push buttonat bottom of window, 292availability, 295default action, 295for whole dialog box, 292guidelines, 291–296label, 293placement, 292sequence, 292size, 293visual cues for, 295when to use, 291

Qquick access

using navigation tabs, 168

Rradio button

guidelines, 299radio buttons

default action, 299default value, 299guidelines, 298–??label, 298placement, 299when to use, 298

recursive selecton, 238relationships

containment, 38representing, 38see connections, 195

results pane, 78, 155chart presentation formats,

163form presentation formats, 165graphical presentation

formats, 158in a task presentation

manager, 86

in an information presentationmanager, 95

in an multiple purposepresentation manager, 97

in an object presentationmanager, 83

interaction with scope pane,147

keyboard navigation, 158presentation formats, 156tabular presentation formats,

161with icons, 158

Sscope pane, 144

general guidelines, 144hierarchy, 145in a multiple purpose

presentation manager, 97in a task presentation

manager, 86in an information presentation

manager, 95in an object presentation

manager, 83interaction with results pane,

147keyboard navigation, 144leaf level items, 147pop-up menus, 150visual cues, 150with filters, 153

scope pane windows, 101splitting, 106when to use, 103

scoping panein web applications, 77

scrollingin web applications, 68

securitybasic measures for the web, 59

388 Index

Index

HP OpenView Launcher, 52user roles, 59

security, in web applications, 59selecction

in tables and grids, 326selection, 231

basic model, 231double clicking, 234group, 247in a child window, 232, 236in a tree list, 317in presentation managers, 240in tree list with checkboxes,

238indicator, 233interaction with navigation,

233lists, 240modifying OVw list, 242mulltiple, 234, 235, 236multiple, 232of groups, 238, 239single, 232

selection listproviding access to, 241

sequencein dialog boxes, 283of push buttons, 292

sequencinggrid, 325in tree list, 316table, 325

shared submaps, 220single pane windows, 104

when to use, 104single selection, 232single selection list

default action, 314single selection list box

labels, 312placement, 312when to use, 311

size

of text boxes, 304slider

default, 311default action, 311guidelines, 309, 310, 311labels, 310placement, 310

sliderswhen to use, 310

spin boxdefault action, 309default value, 309guidelines, 307, 309labels, 308placement, 308when to use

, 307split windows, 106

menus, 107scope pane, 106specifying content, 106, 107toolbars, 107

statuscompound presentation, 222,

262conflicts between applications,

261in task presentation managers,

89reporting by object, 262reporting by symbol, 262

status area, 80status bar, 175status colors, 259status source, 261, 262

setting, 261submap window

geometry, 224overlay, 226

submapsin NNM, 220independent, 190persistent, 221

shared, 221shared vs. exclusive, 220transient, 221

symbol alerts, 263guidelines, 264removing, 265severity levels, 264text annotation, 268types, 265user interaction, 265when to ue, 264

symbol designcreating new connection

classes, 204creating new object classes,

204graphical cues for classes, 202guidelines, 198using existing classes, 198

symbols, 178, 215, 269, 273, 285annotating, 268assigning to connections, 195assigning to objects, 193, 194changing type, 218classes, 198connection, 216, 275connection line style, 216connection subclasses, 215connection thickness, 216creating new subclasses, 212flashing, 270for representing objects, 179highlighting, 269new subclasses, 213see also graphics, 178software utilities, 196subclasses, 206symbol types, 193to represent actions, 196transparent, 271user addition of, 219user modification, 218using existing graphics, 206

Index

Index 389

Ttab categories

for web launcher, 46tab controls

bottom placement, 329guidelines, 327–332horizontal alignment, 329labels, 329multiple rows of tabs, 330top placement, 329vertical alignment, 329visual cues, 331when to use, 87, 328

tabledefault action, 327default values, 327editing entries, 323filter, 325guidelines, 320–327input focus, 323keyboard navigation, 326labels, 323placement, 322selection, 326sequencing, 325when to use, 322

tablesin web applications, 71

tabular presentation format, 161for objects, 161

task based approach, 28task presentation managers, 85

related tasks, 90results pane, 86scope pane, 86status, 89use of navigation tabs, 88, 90use of push buttons, 88when to use, 86

task support, 90text annotation, 268

user interaction, 268with symbol alerts, 268

text boxdata entry, 303default action, 305default value, 305editing, 303guidelines, 301–305labels, 302read only, 303scrolling, 304size of, 304visual cues, 303when to use, 302

title bar, 114contents, 114dialog boxes, 279inweb applications, 73

tool bar, 134toolbar

affect of context, 138application registration files,

138buttons, 136customization, 137graphics, 136in web applications, 74structure, 137

toolbarscontent, 134in split windows, 107user control, 135when to use, 134

transient submaps, 221transparent symbols

when to use, 271tree list

default action, 320default values, 320guidelines, 314–320keyboard navigation, 319labels, 316placement, 315pointer navigation, 319selection, 317

sequencing, 316when to use, 315

Uuniversal pathnames, 19user approaches, 27user guided approach, 28user roles

guidelines for setting, 53in HP OpenView Launcher, 52

Vvariables, environment. See

environment variablesVision

for HP OpenView applications,26

visual cuescontrols, 285filling connection symbols, 275flashing symbols, 270for drag and drop, 248for recursive selection, 239general, 257groups, 246highlighting, 269in graphics, 207in menus, 130in navigation tabs, 170in split windows, 107in tab controls, 331in the scope pane, 150push button, 295status colors, 259symbol alerts, 263transparent symbols, 271using to report object

conditions, 258using vs. event, 258

Wweb applications, 43

390 Index

Index

colors, 61context area, 74control frame, 80fonts, 66forms, 72frames, 69, 71general guidelines, 60graphics, 67HTML, 71images, 67in web browser, 55launching, 45link color, 61navigation, 55, 68progress indicator, 57results pane, 78scoping pane, 77scrolling, 68security, 59status frame, 80tables, 71title bar, 73toolbar, 74type of browser window, 57updating information, 69use of browser controls, 58use of named windows, 60use of patterns, 66window components, 73

web browser, 55type of window, 57

web launcherconcepts, 30description, 45object tab, 49registration guidelines, 47security, 52session information, 54tab categories, 46task tab, 49tools tab, 50user roles, 52

web launchrs

graphics, 51window components, 112

identifying, 113windows, 100

creating new, 109multiple pane, 104resizing, 282reuse of, 109scope pane, 101single pane, 104size, 281splitting, 106types of, 101

wizardswhen to use, 86

HP OpenView Application Style Guidestudent.ing-steen.se/unix/hp-ux/J1261-90001.pdf · 2 Legal...

Documents

Transcript of HP OpenView Application Style Guidestudent.ing-steen.se/unix/hp-ux/J1261-90001.pdf · 2 Legal...