j1261 90006

HP OpenView Application Style Guide
Windows NT Operating System, HP-UX, and Solaris
Manufacturing Part Number: J1261-90006

January 2000
Copyright 2000 Hewlett-Packard Company
Legal Notices
Hewlett-Packard makes no warranty of any kind with regard to this
manual, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be held liable for errors contained herein or direct, indirect,
special, incidental or consequential damages in connection with the
furnishing, performance, or use of this material.
Warranty. A copy of the specific warranty terms applicable to your
Hewlett- Packard product and replacement parts can be obtained from
your local Sales and Service Office.
Restricted Rights Legend. All rights are reserved. No part of this
document may be photocopied, reproduced, or translated to another
language without the prior written consent of Hewlett-Packard
Company. The information contained in this document is subject to
change without notice.
Use, duplication or disclosure by the U.S. Government is subject to
restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013
for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the
Commercial Computer Software Restricted Rights clause at FAR
52.227-19 for other agencies.
HEWLETT-PACKARD COMPANY
3404 E. Harmony Road
Fort 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 copies
of the programs may be made for security and back-up purposes only.
Resale of the programs in their present form or with alterations, is
expressly prohibited.
Copyright Notices. Copyright 1983-2000 Hewlett-Packard Company,
all rights reserved.
Reproduction, adaptation, or translation of this document without prior
written permission is prohibited, except as allowed under the copyright
laws.
Contains software from AirMedia, Inc.
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 of
Microsoft Corporation.
Netscape and Netscape Navigator are U.S. trademarks of Netscape
Communications Corporation.
Oracle is a registered U.S. trademark of Oracle Corporation, Redwood
City, California.
Oracle7 is a trademark of Oracle Corporation, Redwood City,
California.
OSF/Motif and Open Software Foundation are trademarks of Open
Software 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
1. Introduction and General Principles for HP OpenView Style

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
HP OpenView Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
User Approaches to Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Exception Driven Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Task Based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
User Guided Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Important Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Web Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
HP OpenView Launcher and Session Context . . . . . . . . . . . . . . . . .36
Context Controls and Management Context . . . . . . . . . . . . . . . . . . .36
Open Object and Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
View/Submap Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Menu Placement Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Selected Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Application Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Principles for General Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Principles for Information Presentation . . . . . . . . . . . . . . . . . . . . . . . .40
Principles for Access to Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Keyboard Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Use of Special Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Quick Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Labeling Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Principles for Representing Relationships . . . . . . . . . . . . . . . . . . . . . .42
Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Contents
Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Temporal Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2. Web Applications
Introduction to Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Launching Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HP OpenView Web Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Launcher Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Graphics Used in Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Launcher and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Launcher and Session Information . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
49
51
55
55
57
Use of Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Java Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Type of Browser Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Web Applications and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Basic Security Measures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
User Roles and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
General Guidelines for Web Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .
Named Web Browser Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Color and Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Graphics and Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Navigating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Updating Application Information. . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
64
65
70
70
71
72
73
Web Applications Based on HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
75
75
75
Contents
Using Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

Components of Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Title Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Context Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Scope Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Results Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Control/Status Frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
3. HP OpenView Presentation Managers
Object Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Task Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Information Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Multiple Purpose Presentation Managers . . . . . . . . . . . . . . . . . . . . . . . .99
4. Using Windows
Windows in the HP OpenView Environment. . . . . . . . . . . . . . . . . . . . .103
Scope Pane Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
Single Pane Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Multiple Pane Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
Split Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
Creating New Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
5. Window Components
Identification of Window Components . . . . . . . . . . . . . . . . . . . . . . . . . .115
Title Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116
Menu Bar and Pop-Up Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Contents
Menu Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Container Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General-Purpose Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menus for Managed-Object Functionality . . . . . . . . . . . . . . . . . . .
Sequence of Menu Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pop-Up Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Context and Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Registration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Number of Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Depth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cues for Types of Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Separators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Mnemonics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help on Menu Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
119
120
122
125
126
127
128
129
130
131
132
133
134
134
135
136
Toolbar Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to use Toolbars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Content of Toolbars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Control and Support for Toolbar Use . . . . . . . . . . . . . . . . . . . .
Tool Buttons in the Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Toolbar Structure and Customization . . . . . . . . . . . . . . . . . . . . . . . .
Context Control Within the Toolbar. . . . . . . . . . . . . . . . . . . . . . . . . .
Context and Toolbar Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Registration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
137
137
137
138
139
140
141
141
141
Description Bar Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Context Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Scope Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Contents
Scope Panes With Hierarchies of Items . . . . . . . . . . . . . . . . . . . . . . .148

Interactions between the Scope Pane and Results Pane. . . . . . . . .150
Menus in a Scope Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Visual Cues in a Scope Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153
Scope Panes with Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
Results Pane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
Presentation Formats for the Results Pane . . . . . . . . . . . . . . . . . . . .159
Graphical Presentation Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
Tabular Presentation Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
Chart Presentation Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .166
Form Presentation Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
Navigation Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177
6. Objects and Symbols
Iconic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
When to Represent Objects with Symbols . . . . . . . . . . . . . . . . . . . . .181
Levels of Symbol Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Representation of Container Objects . . . . . . . . . . . . . . . . . . . . . . . .182
Representation of Leaf-Level Objects . . . . . . . . . . . . . . . . . . . . . . .183
Representing Objects in an Existing Hierarchy . . . . . . . . . . . . . . .184
Representing All Objects in the Hierarchy . . . . . . . . . . . . . . . . . . .185
Representing Objects Using a Combined Approach . . . . . . . . . . . .185
Special Types of Objects and Views. . . . . . . . . . . . . . . . . . . . . . . . . . .189
Representing Multiple Location (Linked) Objects. . . . . . . . . . . . . .189
Representing Related Objects and Attributes . . . . . . . . . . . . . . . . .190
Independent Iconic Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Layout Algorithms for Iconic Views . . . . . . . . . . . . . . . . . . . . . . . . . .192
Guidelines for Assigning Symbols to Objects. . . . . . . . . . . . . . . . . . . . .195
Symbols and Symbol Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Contents
Assigning Symbols to Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Assigning Symbols to Connections and Relationships . . . . . . . . . . . 197
Assigning Symbols to Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Symbol Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbol Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Existing Symbol Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Graphical Cues for Symbol Classes . . . . . . . . . . . . . . . . . . . . . . . .
Creating New Class Shapes for Objects . . . . . . . . . . . . . . . . . . . . .
New Connection Symbol Classes . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbol Subclasses (Graphics) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Existing Symbol Subclasses (Graphics). . . . . . . . . . . . . . . .
New Symbol Subclasses (Graphics) for Objects . . . . . . . . . . . . . . .
New Connection Symbol Subclasses. . . . . . . . . . . . . . . . . . . . . . . .
Connection Symbol Line Style . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connection Symbol Thickness. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
200
200
200
204
205
206
207
207
214
217
217
217
User Modification of Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Changing Symbol Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
User Addition of Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Creating NNM Submaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shared vs. Exclusive Submaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using an Existing Shared Submap . . . . . . . . . . . . . . . . . . . . . . . . . .
Persistent and Transient Submaps . . . . . . . . . . . . . . . . . . . . . . . . . .
Submap Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Submap Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Submap Window Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Submap Window Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
221
221
222
222
223
224
225
227
7. Object Selections, Grouping, and Drag and Drop

Selection Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Basic Selection Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
10
Contents
Affects of Navigation on Selection . . . . . . . . . . . . . . . . . . . . . . . . . .233

Multiple Selection Across Views in a Window . . . . . . . . . . . . . . . . . .234
Multiple Selection in the Scope Pane. . . . . . . . . . . . . . . . . . . . . . . .235
Multiple Selection Across Results Panes . . . . . . . . . . . . . . . . . . . . .236
Recursive or Group Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
Recursive Selection In a Tree List with Check Boxes. . . . . . . . . . .238
Group Selection for Container Symbols . . . . . . . . . . . . . . . . . . . . . .239
Selection Lists in Applications Integrating into Presentation
Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .240
Providing Access to HP OpenView Windows Selection List . . . . . . .241
Modifying the HP OpenView Windows Selection List . . . . . . . . . . . .242
Drag and Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Visual Cues for Drag and Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
Guidelines for Specific Types of Drop Targets . . . . . . . . . . . . . . . . . .245
Views as Drop Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
Container Symbols as Drop Targets. . . . . . . . . . . . . . . . . . . . . . . . .247
Leaf Level Symbols as Drop Targets . . . . . . . . . . . . . . . . . . . . . . . .248
Executable Symbols as Drop Targets. . . . . . . . . . . . . . . . . . . . . . . .248
Drop Targets that Cause a Change in the Instrumentation Space 249
Use of HP OpenView Windows Drag and Drop . . . . . . . . . . . . . . . . .249
Drop Target Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
Executable Symbols with Explodable Appearance . . . . . . . . . . . . .250
8. Visual Presentation
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .253
Notification of Object Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .254
Visual Cues versus Alarm Messages. . . . . . . . . . . . . . . . . . . . . . . . . .254
Use of Status Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
Source of Status Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .256
Status Source in NNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .257
11
Contents
Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

When to Use Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Guidelines for Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Text Annotation for Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Highlighting Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Flashing Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Transparent Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Executable Symbol Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Partially Filled Connection Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
9. Dialog Boxes and Controls
Dialog Box Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Title Bar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Menu Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonts for Dialog Boxes and Windows. . . . . . . . . . . . . . . . . . . . . . . . .
Size of Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Size for Dialog Boxes and Windows . . . . . . . . . . . . . . . . . . .
Resizing Dialog Boxes and Windows . . . . . . . . . . . . . . . . . . . . . . . . .
Panes in Resized Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Guidelines for Controls in Dialog Boxes . . . . . . . . . . . . . . .
Sequencing of Controls within the Dialog Box. . . . . . . . . . . . . . . .
Alignment of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Visual Cues in Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Validation and Error Handling . . . . . . . . . . . . . . . . . . . . . . . .
12
275
275
275
276
276
276
277
278
278
278
279
279
279
280
280
281
282
284
Contents
Default Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284

Guidelines for Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Push Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .287
Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .288
Size of Buttons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Labels and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
Visual Cues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Default Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .291
Option Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
Placement and Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .293
Default Actions and Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Radio Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Default Actions and Default Values . . . . . . . . . . . . . . . . . . . . . . . . .295
Check Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .296
Default Actions and Default Values . . . . . . . . . . . . . . . . . . . . . . . . .297
Text Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .299
Size of Text Boxes and Scrolling. . . . . . . . . . . . . . . . . . . . . . . . . . . .300
Default Action and Default Values. . . . . . . . . . . . . . . . . . . . . . . . . .301
Combo Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Spin Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .303
Sliders and Gauges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305
13
Contents
Default Action and Default Values . . . . . . . . . . . . . . . . . . . . . . . . .

List Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Placement and Labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Default Action and Default Values . . . . . . . . . . . . . . . . . . . . . . . . .
Tree List Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selection in Tree List Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keyboard Navigation in Tree List Controls . . . . . . . . . . . . . . . . . .
Pointer Navigation in Tree List Controls . . . . . . . . . . . . . . . . . . . .
Default Actions and Default Values . . . . . . . . . . . . . . . . . . . . . . . .
Tables and Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to Use Table and Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Focus and Editing for Tables and Grids . . . . . . . . . . . . . . . .
Filtering and Sequencing of Items . . . . . . . . . . . . . . . . . . . . . . . . .
Selection in Tables and Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keyboard Navigation in Tables and Grids . . . . . . . . . . . . . . . . . . .
Default Actions and Default Values . . . . . . . . . . . . . . . . . . . . . . . .
Tab Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grouping Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Guidelines for Group Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
307
307
307
309
309
310
311
311
312
312
313
315
316
316
317
318
319
320
321
322
322
323
324
325
325
327
329
331
333
334
Contents
10. Miscellaneous Guidelines

Internationalization and Localization of the User Interface. . . . . . . . .337
Localization of the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . .338
Helpful Hints for Internationalizing HP OpenView Applications. . .338
11. Guidelines for Product Documentation
Structure of the Documentation Set. . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Types of Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
A Modular Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
Grouping the Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
Recommendations for the Documentation Set . . . . . . . . . . . . . . . . . .345
Structure of Individual Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
Recommendations for Information Access . . . . . . . . . . . . . . . . . . . . .347
Recommendations for Information Understanding . . . . . . . . . . . . . .348
Recommendations for Localization . . . . . . . . . . . . . . . . . . . . . . . . . . .349
A. HP OpenView Launcher Categories
Object Tab Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352
Task Tab Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354
Information and Reporting Tab Categories . . . . . . . . . . . . . . . . . . . . . .356
Tool Tab Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .358
B. Mnemonics and Accelerators
C. Color Mapping and Palettes
Using Color in Web Page Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364
Color Palettes Used in HP OpenView . . . . . . . . . . . . . . . . . . . . . . . . .364
Palette Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .364
Using the Limited Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .365
15
Contents
Color Values in the Limited Color Palette . . . . . . . . . . . . . . . . . . . . . 365

Using the Expanded Color Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Color Values in the Expanded Color Palette . . . . . . . . . . . . . . . . . . . 368
D. Bibliography
16
Figure 2-1 . Launcher Window with the Task Tab Selected . . . . . . . . . .40
Figure 2-2 . Icons for Categories and for Leaf Level Items . . . . . . . . . . .45
Figure 2-3 . Web Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Figure 3-1 . Object Presentation Manager . . . . . . . . . . . . . . . . . . . . . . . .78
Figure 3-2 . Task Presentation Manager with a Task Presented in a
Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Figure 3-3 . Task Presentation Manager with Task Presented in a Tab
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Figure 3-4 . Visual Cues and Task Completion Feedback in a Task
Presentation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Figure 3-5 . Related Task Tab in a Task Presentation Manager with a
Tab Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Figure 3-6 . Example of an Information Presentation Manager. . . . . . .87
Figure 3-7 . Multipurpose Presentation Manager . . . . . . . . . . . . . . . . . .89
Figure 4-1 . Scope Pane Window with Network Hierarchy . . . . . . . . . . .94
Figure 4-2 . Scope Pane Window with Categories to be Matched . . . . . .95
Figure 4-3 . A Multiple Pane Window . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Figure 4-4 . A Split Scope Pane Window . . . . . . . . . . . . . . . . . . . . . . . .100
Figure 5-1 . Window with Its Components Identified . . . . . . . . . . . . . .105
Figure 5-2 . Sequence for Items in Menu Bars Using OSI Menus . . . .115
Figure 5-3 . Sequence for Items in Menu Bars Using an Action Menu 115
Figure 5-4 . A Menu Bar Using Object-Based Menus . . . . . . . . . . . . . .115
Figure 5-5 . A Cascading Toolbar Button . . . . . . . . . . . . . . . . . . . . . . . .130
Figure 5-6 . Description Bar over the Scope and Results Panes in a
Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
Figure 5-7 . Context List in a Close and Open State . . . . . . . . . . . . . . .135
Figure 5-8 . Context Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
Figure 5-9 . Two Examples of Scope Panes Showing Hierarchies . . . .139
Figure 5-10 . Expansion Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
17
Figure 5-11 . Visual Cues in the Scope Pane . . . . . . . . . . . . . . . . . . . . 143

Figure 5-12 . A Scope Pane with Filters . . . . . . . . . . . . . . . . . . . . . . . . 146
Figure 5-13 . The Results Pane in an Application Window . . . . . . . . . 148
Figure 5-14 . A View Showing an Iconic Presentation Format . . . . . . 151
Figure 5-15 . Pictorial Presentation Format . . . . . . . . . . . . . . . . . . . . . 153
Figure 5-16 . A View Showing a Tabular Presentation Format. . . . . . 154
Figure 5-17 . A View Showing a Chart Presentation Format . . . . . . . 157
Figure 5-18 . A View Showing a Form Presentation Format . . . . . . . . 158
Figure 5-19 . Navigation Tabs with Images of Stick Pins on Them . . 160
Figure 5-20 . Tab States and Appearance . . . . . . . . . . . . . . . . . . . . . . . 161
Figure 5-21 . Navigation Tabs Showing a Change in Task Status . . . 165
Figure 5-22 . A Status Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 6-1 . Expansion Controls in a Hierarchy of Objects . . . . . . . . . 172
Figure 6-2 . X.25 Application Using a Combined Approach . . . . . . . . 177
Figure 6-3 . Item in a Property Box with a Link Symbol. . . . . . . . . . . 181
Figure 6-4 . Split Window Showing Objects at Linked Location . . . . . 181
Figure 6-5 . Symbol Class and Subclass for an Object . . . . . . . . . . . . . 185
Figure 6-6 . Symbol Class and Subclass for a Connection . . . . . . . . . . 186
Figure 6-7 . Change Symbol Type Dialog Box . . . . . . . . . . . . . . . . . . . 210
Figure 7-1 . Selection List for Scope Pane that Allows Multiple
Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Figure 7-2 . Visual Cues for Recursive Selection . . . . . . . . . . . . . . . . . 229
Figure 8-1 . Symbol Alert in the Results Pane of a Window . . . . . . . . 249
Figure 8-2 . Symbol Alert in the Scope Pane of a Window. . . . . . . . . . 249
Figure 8-3 . Pop-up Menu Associated with Symbol Alerts. . . . . . . . . . 253
Figure 9-1 . Push Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Figure 9-2 . Push Button with Location Cursor and Default Action
Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
18
Figure 9-3 . Option Button in Closed and Open State. . . . . . . . . . . . . .282

Figure 9-4 . Radio Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284
Figure 9-5 . Single and Multi-line Text Boxes . . . . . . . . . . . . . . . . . . . .288
Figure 9-6 . Drop-down Combo Box in Closed and Open State. . . . . . .292
Figure 9-7 . Spin Box with Labels Required . . . . . . . . . . . . . . . . . . . . .294
Figure 9-8 . Spin Box with Labels Optional . . . . . . . . . . . . . . . . . . . . . .294
Figure 9-9 . Slider with a Default Setting and Current Value Shown .295
Figure 9-10 . Gauges for Setting a Value and Displaying a Value . . . .295
Figure 9-11 . Visual Cues for a Multiple Selection List Box . . . . . . . . .300
Figure 9-12 . Single Selection Tree List and Multiple Selection
Tree List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .301
Figure 9-13 . Visual Cues for Recursive Selection . . . . . . . . . . . . . . . .305
Figure 9-14 . Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307
Figure 9-15 . Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .308
Figure 9-16 . Tab Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Figure 9-17 . Vertical Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .316
Figure 9-18 . Scrollable Tabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .318
Figure 9-19 . Dialog Box with a Separator Line . . . . . . . . . . . . . . . . . .319
Figure 9-20 . Dialog Box with a Group Box . . . . . . . . . . . . . . . . . . . . . .320
Figure 9-21 . Window with Two Panes . . . . . . . . . . . . . . . . . . . . . . . . . .321
Figure 11-1 . Organizing Information into Modules . . . . . . . . . . . . . . .334
19
20
Tables
Table 2-1. Defined Color Usage for HTML Based Applications . . . . . . .56
Table 2-2. Defined Java System Color Variable Usage . . . . . . . . . . . . . .57
Table 5-1. Required Visual Cues for Menu Items . . . . . . . . . . . . . . . . .123
Table 6-1. Obsolete Symbol Types and Their Replacements. . . . . . . . .187
Table 6-2. Existing Symbol Class Shapes. . . . . . . . . . . . . . . . . . . . . . . .191
Table 6-3. Internal Graphics Cues . . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
Table 6-4. Visual Cues Used in Existing Graphics . . . . . . . . . . . . . . . .198
Table 8-1. Default Status Colors Defined for HP OpenView . . . . . . . . .245
Table 9-1. Recommended Dialog Box Title Formats . . . . . . . . . . . . . . .265
Table 9-2. Labels and Definitions for Push Buttons . . . . . . . . . . . . . . .280
Table 9-3. Guidelines for Showing Buttons as Unavailable . . . . . . . . .281
Table B-1. Common Accelerator Key Assignments in HP OpenView. .350
Table B-2. Common Mnemonic Access Key Assignments in
HP OpenView. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
Table C-1. Color Values in the Limited Color Palette . . . . . . . . . . . . . .356
Table C-2. Color Values in the Expanded Color Palette . . . . . . . . . . . .358
21
Tables
22
Conventions
The following typographical conventions are used in this manual.
Font
What the Font Represents
Example
For book or manual titles, and for manpage

names.
Refer to the OVW Developers Guide.
To provide emphasis.
You must follow these steps.
To specify a variable that you must supply

when entering a command.
At the prompt type: rlogin

your_name where you supply your login
name.
Bold
For glossary terms.
The distinguishing attribute of this

class...
Computer
Text and items on the computer screen.
The Root map window ...
Italic
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...
Computer
Bold
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.
Menu
Items
A menu name followed by a colon (:)

means that you select the menu, then the
item. When the item is followed by an
arrow (->), a cascading menu follows.
Select Edit:Find->Objects by
Comment
23
24
Contact Information
Technical Support Technical support information can be found on the HP OpenView World
Wide Web site at:
http://www.hp.com/openview/support.html
________________________________
Documentation
Feedback
Your comments on and suggestions for the documentation help us

understand your needs and better meet them.
You can provide feedback about documentation via the HP
documentation 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: ovdoc@fc.hp.com
If you encounter serious errors in the documentation that impair your
ability to use NNM, please contact the HP Response Center or your
support representative so that your feedback can be entered into STARS
(HPs Software Tracking and Reporting System).
________________________________
Training
Information
For information on current HP OpenView training available, see the HP

OpenView World Wide Web site at:
http://openview.hp.com/support
Follow the links for Training to obtain information about scheduled
classes, training at customer sites, and class registration.
25
26
Introduction and General

Principles for HP OpenView
Style
27
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 doing
network, system and service management.
General design principles for all applications.
Since numerous and varied applications are integrated into HP
OpenView, the application developers need to keep these points in mind
while developing an application. This will help ensure cooperation and
interoperability between applications, providing the user with an
integrated, cohesive interface from which to access these applications.
28
Chapter 1

Overview
Overview
HP OpenView is a family of tools and services for managing the IT
infrastructure associated with a company. The tools and services in the
HP OpenView family cover management for desktop computers,
distributed systems, data, applications, local and wide area multivendor
networks, etc. HP OpenView provides tools for creating multivendor
system, network, software, and service management applications.
Applications are perceived by the user as being part of the HP OpenView
family, to the extent that they provide a common appearance and
behavior. This style guide provides a summary of the recommended
appearance and behavior for applications in the HP OpenView family.
Except where specifically indicated, the style recommendations are
applicable regardless of the technology on which the application is built
or the operating systems on which it is presented.
The style for HP OpenView products is in accordance with the general
principles in the The Windows Interface Guidelines for Software Design.
This guide is designed to:
Present a subset of the guidelines from The Windows Interface
Guidelines for Software Design that need emphasis or special
interpretation for products in the HP OpenView Family.
Introduce style guidelines that are unique to HP OpenView products.
Chapter 1
29

HP OpenView Vision
HP OpenView Vision
The platforms and applications that are part of the HP OpenView family
should 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.
30
Chapter 1

User Approaches to Management

When doing network, systems, and service management, a user will
typically take one of three approaches to his work. The choice of
approach will depend on the users job and the way work is structured
within his organization. The user may also move back and forth between
these approaches, depending on the requirements of the work he is
trying to accomplish. HP OpenView applications should be designed to
allow for one or more of these approaches to management.
Exception Driven Approach

In the exception driven management approach, the user might have a
trouble ticket system, message browser, or graphical presentation that
notifies him of problems in his management domain. He receives a
notification, 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 operations
centers.
User interfaces present an exception driven approach by presenting a
user with exceptions, along with the necessary resources, to enable him
to handle these exceptions. Exceptions are not always problems that
occur in the current service, network, and system environment; they can
be a request for new services or for equipment to be placed in the
environment. Some exceptions can be handled by predefined automatic
actions (task based interactions that use the exception as the context for
defining the parameters of the task) or by user guided steps.
The exception based approach requires the tracking of performance
relative to goals for preventing and/or handling exceptions.
HP OpenView applications facilitate the exception driven approach to
management through the presentation of alarms or messages and
graphical views of objects which show status and symbol alerts. See
Chapter 8 , Visual Presentation for information on visual cues that can
be used to support the exception based approach.
Task Based Approach

A task is the performance of a piece of work that results in a self
Chapter 1
31

contained desired outcome. Tasks can be defined at multiple levels (that
is, complex tasks which consist of multiple subtasks or simple tasks that
involve a single step). Tasks can involve the manipulation of single
objects or of multiple objects.
Network, systems, and service management often involves well defined
tasks that need to be accomplished either on a periodic basis or on an
event driven basis. In a task based approach, a user goes through a set of
defined steps to complete that task. For tasks which will be repeated a
number of times by different users or by the same user, it is possible to
define an optimum sequencing of a tasks steps to achieve the best user
performance.
The task based approach is frequently used in setting up new equipment,
in making changes to configurations, and in resolving routine problems
or doing routine jobs.
User interfaces present a task based approach by guiding a user through
the steps required to accomplish a task or allowing users to configure
policies that will automatically handle the tasks. In some complex tasks,
a task based approach may be provided for a portion of the task, but the
user may need to utilize a user guided approach to accomplish the rest of
the task.
HP OpenView applications facilitate the task based approach to
management through the presentation of tasks in task presentation
managers, wizards and in the configuration of policies. Task presentation
managers allow users to start tasks from a list of available tasks and to
complete task steps with the aid of a wizard. (See Chapter 3 , HP
OpenView Presentation Managers.)
User Guided Approach

Because the problems being dealt with in network, systems, and service
management are complex, and because IT and telecommunications
groups vary in the equipment they are managing and the processes they
are using for management, there is a need for unconstrained access to
information and functionality. The user guided approach in user
interfaces allows maximum freedom for a user by enabling him to access
multiple tools and capabilities with limited constraints.
32
Chapter 1

The user guided, information seeking approach is frequently used in
planning for modifications to a network and system infrastructure, in
looking at the health of a specific object or set of objects, and in resolving
complex problems that have not previously been encountered or
predicted.
User interfaces present a user guided approach by offering clearly visible
functionality that a user is allowed to access to accomplish his goals.
Frequently, user guided interfaces use an object action paradigm in
which a user first selects the object on which he wants to act, followed by
the action he wants to take. This selection constrains the functionality to
those actions which are appropriate for the object (for example, menu
graying); the user then chooses from the constrained subset of available
functionality.
HP OpenView applications facilitate the user guided approach to
management through the object action paradigm in object presentation
managers. In these presentation managers, a user can select objects and
then access functionality for acting on these objects from menus and
toolbars. To prevent cognitive overloading of the user, the functionality is
context specific; available functionality is constrained to the context in
which the objects are presented.
Chapter 1
33

Important Concepts
Important Concepts
HP OpenView has a number of important concepts on which the user
interface style is based. These concepts are briefly explained in the
following sections.
Presentation Managers
Presentation managers are windows which present users with views of
managed objects, access to functionality for manipulating objects,
guidance in accomplishing tasks and/or a means of presenting
information on managed objects. Presentation managers are
distinguished from other windows in that they are designed to suit the
users needs and to minimize the number of windows that the user needs
to navigate through in order to accomplish their goals. Typically
presentation managers will allow the integration of other related
applications so that users can access necessary information for a given
management area or task from within a single window. Microsofts
Management Console (MMC) and Network Node Manager both provide
frameworks on which presentation mangers can be built.
HP OpenView provides a set of presentation managers into which
applications can integrate. These presentation managers provide
capabilities that can be used by integrating applications (for example,
NNM Network Presenter, Manage X). Integration into a presentation
manager can minimize the development effort required of the
integrating applications. For example, applications can use the discovery
and multiple selection capabilities of NNM and Manage X.
Developers can also choose to create their own independent presentation
managers.
See Chapter 3 , HP OpenView Presentation Managers for guidelines
regarding presentation managers.
Web Launcher
HP OpenView provides a web launcher into which applications can
integrate. The web launcher provides a single access point on the web;
from which the user can:
Start all HP OpenView web applications.
34
Chapter 1

Important Concepts
Access object presentation managers, which provide both views of
managed 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 user
can log in just once and have his authorization for functionality access
based on this single login. This ensures that the information and
capabilities provided by HP OpenView are available only to authorized
individuals. Having a centralized point for security minimizes the need
for a user to do separate logins to different applications. See Chapter 2 ,
Web Applications, for guidelines regarding the launcher.
Context
Context is an abstract concept which can be applied to the user interface
to filter the information that is presented and to provide a view of
information from different perspectives. Contextual information such as
who the user is, the user role, recent user actions, or events and alarms
can be used to filter the functionality and objects presented in the user
interface. This allows the user to focus on information that is relevant to
the current task. This same type of information can be used by
applications to vary the way information is presented. This enables the
information presentation to match the preferences and needs of the user
as he interacts with the management system. Sharing of contextual
information, allows independently developed applications to appear to
the user as highly integrated applications that work closely together.
Context can also be used to maximize user productivity. Contextual
information such as the currently visible view or recent user actions can
be used to set defaults that minimize the need for user input. This same
information can be used to filter irrelevant information or steps so that
users can more quickly reach their goals. By passing contextual
information between components within an application and between one
application and others, the need for the user to duplicate his actions is
minimized.
HP OpenView currently provides a number of components which support
the use of context to aid the user. These components are described in the
next six sections.
Chapter 1
35

Important Concepts
HP OpenView Launcher and Session Context
The HP OpenView Launcher for web applications provides contextual
information at the session level. This information can be shared across
applications. Examples of session level context information available
from the launcher includes:
Identification of the user who is accessing the application (user login).
The user roles assigned to the person who has accessed the
application.
The language locale specified for this session.
The functionality presented in the HP OpenView Launcher is filtered
to restrict the functionality to match the roles associated with the
user who started the session. Applications can obtain the session
information on user login and user roles. They can then create an
implementation that uses this information to filter the functionality
and objects that they present.
Context Controls and Management Context
The context controls provided in presentation managers provide users
with an explicit mechanism for filtering information and changing the
perspective from which information is presented. In presentation
managers, context changes are typically associated with a change in the
management hierarchy, and/or type of management functionality. For
example, in an object presentation manager, users could change between
management hierarchies for the IP Internet and File Sharing using the
context list box in the toolbar. In a task presentation manager, users
could change between tasks for Asset Management to tasks for Fault
Management and Diagnosis. A change in the management context will
likely result in a change in the functionality that is available in the
menus and toolbars, in the objects, tasks, or tools available in the scope
pane, and in the views that can be presented in the results pane.
See Chapter 5 , Window Components, for more information on context
controls.
Open Object and Context
The object that is open within the scope pane will define context, by
determining the view that is presented to a user in the results pane. A
view consists of two components: the data to be presented to the user and
the presentation formats for that data. A view typically will have both a
36
Chapter 1

Important Concepts
default presentation format (for example, an icon view) as well as other
presentation formats that the user can access for changing the way the
information is presented (for example, a tabular view).
Each view determines which menu and toolbar items are available to the
user for acting on the objects in that view. See View/Submap Context
below.
View/Submap Context
View context, also referred to as submap context, filters the menu items
so that only menu items relevant to the current view are presented.
Using view/submap context, application developers can determine which
menu items and toolbar items to associate with a particular view or
submap. View context allows:
Smaller menus and toolbars, because menu items are defined to occur
only in the specific contexts they are applicable to.
The elimination of continuously grayed-out menu items that would
occur if menu items were not specific to a given context defined by a
set of views.
For each view that is created, a view context must be specified.
If no context identifiers are provided for a view/submap, that
view/submap will only contain generic menu items or undefined menu
items 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 used
for other purposes than menu item specification (that is, determining
whether a given object would appear in a view or accessing related views
containing a specified object).
Menu Placement Rules

Menu placement rules are specifications that work in conjunction with
view context identifiers to determine if a menu item will be presented
with a given view. See Chapter 5 , Window Components, for
information and recommendations about specifying menu placement
rules.
Chapter 1
37

Important Concepts
Selected Objects
Any currently selected objects and their capabilities help to set the
context for which menu items will be available or grayed-out and
unavailable. If the capabilities of the selected objects do not match those
required by a menu item or a toolbar button, the menu item or button
will be grayed-out.
Groups
Groups contain arbitrary sets of objects and/or other groups. Groups can
be defined by applications or by end users. They have a variety of uses
such 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 all
the 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 Chapter
7 , Object Selections, Grouping, and Drag and Drop.
38
Chapter 1

Application Design Principles

When designing an application, keep in mind the underlying concept of
HP OpenView Windows, which is to provide an environment in which
there is cooperation and interoperability between a variety of
applications.
Principles for General Usability

To enhance user interaction and productivity in this kind of
environment, each new HP OpenView application should be designed to
be integrated, intelligent, and consistent. These goals can be achieved by
keeping the following principles in mind when designing the application:
Make functionality visible to users.
Allow users to customize the functionality to suit their individual
work environments.
Make the application extensible by allowing users to add
functionality that they have developed in their own organizations.
Minimize the users work load by automating any tasks that can be
automated (discovery and data access, for example).
Use terminology that is common throughout the HP OpenView
environment and which is consistent with terminology used by end
users.
Minimize the users cognitive load by providing information that an
application can obtain for itself.
Eliminate the need for users to hold information in their short term
memory. Use menus, lists, check boxes, and other user interface
controls (which are based on recognition instead of on recall).
Eliminate the need for users to make decisions, by providing defaults
or 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 not
increase its difficulty.
Chapter 1
39

Provide connections between all dialog that are required to
complete a task. Do not require users to go back to the menu bar
in order to locate the next dialog required for their task.
Support user productivity.
Provide and use accelerators wherever possible to support power
users access of functionality in fewer steps.
Allow users to repeat actions in dialog boxes (for example, provide
an [Apply] button) if they will want to make multiple sets of
changes 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 or
task 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 the
consequences of these errors for the user and his tasks.
Principles for Information Presentation

Use the following principles to ensure consistency in the presentation of
information across applications.
Do not require users to translate data to use it; present all
information 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 more
meaningful.
If color coding is used, provide other redundant cues so that color
blind users will be able to differentiate different color codes from one
40
Chapter 1

another. Allow users to configure colors so that they can be
differentiated.
If auditory cues are used, take into account changes in hearing due to:
A users age (higher tones become more difficult to detect).
The environment in which a user works (in a open office occupied
by multiple users, for example, auditory cues should be
minimized).
If shapes are used, select shapes that are different enough from each
other to be easily distinguishable.
If multiple sizes of shapes are used, be sure that the shapes are
distinguishable at their smallest size.
Principles for Access to Actions

Use the following principles to ensure that user access to actions is
consistent across applications.
Keyboard Access
Keyboard equivalents are the mechanism by which a specialized
software vendor or application developer can provide support for end
users with different types of disabilities. This enables users with
disabilities to access all the capabilities of an application. This same
mechanism can also be used as an accelerator or quick access mechanism
by users without disabilities.
Use of Special Keys
If the keyboard contains hard labeled keys for various actions provided
in an applications user interface, make sure that the applications
software does allow those keys to be used to access the indicated actions.
For example, if an applications interface allows users to delete items in a
list, make sure they can actually use the Delete Line or Delete keys on the
keyboard to accomplish this action.
Quick Access
Frequently used actions should be available to users through a quick
access method, such as a toolbar button, a menu accelerator, or a pop-up
menu.
Chapter 1
41

But, be sure to provide other access methods for the functionality in
addition to these quick access methods. Quick access methods are simply
a faster way of doing an action that can be done using another slower,
but more obvious, method.
Labeling Actions
Similar actions must use similar terminology in their labels. For
example, use the term Delete consistently in action labels which cause
a deletion result (that is, use Delete User and Delete Printer instead
of Remove User and Delete Printer).
Labels chosen for user actions should be based on user terminology. For
example, use the term Save rather than Write.
Principles for Representing Relationships

Relationships can be represented either graphically or textually. Use the
following principles to represent relationships between elements of an
application.
Containment
Containment relationships can be represented:
Graphically by an exploding symbol that leads to a view with the
contained items presented in the child view.
Graphically using a tree list where parent items can be expanded into
the lower level items contained within.
Textually using a hierarchical list with indentation. The container
would be at a higher level in the list, and the contained items would
be indented under the container.
Classification
This type of relationship is one in which objects are related to one
another because they can be placed in the same category or class based
on 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 view
with the member of the class presented in the graphical view.
42
Chapter 1

Graphically via a tree layout with the category label on top and
contained objects being presented beneath under the category label.
Textually within a table. One column can contain the object names
and another column can contain the category to which the object
belongs. Alternatively, each column can represent a separate
category, and the cells under the category headings can indicate the
members of each category.
Textually within a list with a category name as a label for the list. A
hierarchical list can be used for multiple categories.
Lower level objects in a classification relationship should not be
portrayed as being connected to one another. Instead, it is recommended
that they be presented in a row/column layout.
Connection
Connection relationships can be represented graphically using the
various layout algorithms to represent different types of connections of
the objects. See section, Layout Algorithms for Graphical Views. for
detailed guidance on the use of the layout algorithms.
Recommended
It is difficult to meaningfully represent connection relationships in a

textual format. Therefore, a graphical format is recommended.
Recommended
If design constraints force the use of a textual format, connection

relationships can be represented in a table with one of the table columns
listing objects connected to the object in question.
Peer
Peer relationships can be represented:
Graphically by a ring layout with all objects either arranged in a
circle or connected to one another.
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 the
hierarchy would be peers.
Textually within a table, with peers presented as rows within a
column of the table.
Chapter 1
43

Temporal Relationships
Sometimes events or actions need to presented in terms of when they
have occurred or when they will occur in time.
Temporal relationships can be represented:
Graphically by the sequence in which the symbols representing
events are presented. (In western countries, this sequence should be
displayed either top to bottom or left to right with the earliest events
or actions at the top or left side of the display and the most recent
events 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 early
to later.
Textually in a list or a table with the event or action in one column
and the time associated with that event or action presented in
another column.
Recommended
If the temporal relationships are complex with multiple dependencies

and/or simultaneously occurring events and actions, it is better to
portray these relationships graphically.
44
Chapter 1
Web Applications
45
Web Applications
This chapter discusses:

The HP OpenView Launcher which is a new integration point for web
applications.
The trade-offs to be considered in deciding whether to present the
application in a Java frame or a Web browser window.
Guidelines for when to remove the controls from a browser window
used 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 browser
window.
46
Chapter 2
Web Applications
Introduction to Web Applications

Since numerous and varied applications are integrated into HP
OpenView, the application developers need to keep these points in mind
while developing an application. This will help ensure cooperation and
inter-operability between applications, providing the user with an
integrated, cohesive interface from which to access these applications.
Designing an application for the web is not significantly different than
designing an application for any other technology. Certain principles of
user interface design remain valid, regardless of the underlying
technology, because they relate to the way humans receive and interact
with 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 and
widgets that a developer has available to him. Different technologies
allow for the use of different sets of controls and widgets. Differences in
the availability of controls require trade-off decisions on what to use in
place of a control that does not exist, and when to use a new control that
is enabled by the technology. Unless the technology is changing the
fundamental way a control or widget works, the design principles for
good usability associated with a given control are consistent across
technologies. The web provides many of the same controls that are
available in traditional development environments tied to the desktop or
windowing system of a given computer.
Sometimes a given technology changes the response time, visual
appearance, and/or behavior of a control to such an extent that it no
longer represents the previous class of controls. Instead, it becomes a
different type of control. When this happens, the design principles
associated with the control must be redefined in order to achieve high
usability. This chapter is primarily intended to address user interface
components and controls that are modified as a function of being in the
web environment.
With these considerations in mind, the style for HP OpenView products
is based on the concept that all HP OpenView products should have a
consistent look and feel regardless of the underlying technology. Web
applications are expected to follow the general style for HP OpenView
Chapter 2
47
Web Applications
products as described in other chapters of this style guide. This chapter
discusses those areas that need special attention, given that an
application will be based on web technologies (such as HTML or Java).
48
Chapter 2
Web Applications
Launching Web Applications

If users are accessing a large number of web applications in the process
of doing their management tasks, it becomes cumbersome when they are
required to set bookmarks for each of the applications. Use of web
applications becomes much easier for users when all of their web
applications are available from a single access point. This is the intended
use of the HP OpenView Web Launcher.
HP OpenView Web Launcher

The HP OpenView Launcher is a new integration point for web
applications. The launcher provides login security for web-based HP
OpenView applications and provides a central location from which the
user can launch all of the applications that have integrated into the HP
OpenView web environment.
The launcher is a small window that is divided into two parts.
Chapter 2
49
Web Applications
Figure 2-1
Launcher Window with the Task Tab Selected
The top part of the window presents management functionality in a

hierarchical tree list. The management functionality area contains a set
of tabs indicating categories for types of management operations. Each
category is indicated by a small icon that is presented on the tab. Users
click on the tabs to access functionality in the different categories. The
initial list of tabs provided by the launcher is:
Objects
Tasks
Information and Reports
Tools
Management Area <Administrator Configurable>
Help
An active help area is presented beneath the functionality area. This
50
Chapter 2
Web Applications
area displays a short help message explaining the operation of the item
over which the pointer has been placed.
There are top level categories defined for each of the predefined tabs in
the launcher. These categories are presented in Appendix A , HP
OpenView Launcher Categories.
Launcher Registration
The HP OpenView Launcher allows for the integration of web
applications by means of a registration file. The entries in the
registration file determine the placement of the application entries
within the launcher.
Recommended
The following types of web applications should be registered to be

launched from the launcher:
Applications that take the role of a presentation manager in the HP
OpenView environment. See Chapter 3 , HP OpenView Presentation
Managers, for more information.
Stand-alone applications that are not dependent on a presentation
manager in order to provide their functionality to the user.
These applications may be available from one or more presentation
managers but they provide independent mechanisms for the user to
specify necessary parameters (for example, selections) so that access
from a presentation manager is not required.
Applications that integrate into the context list of an existing
presentation manager.
See Chapter 3 , HP OpenView Presentation Managers, and
Context Controls in Chapter 5 for more information.
Recommended
In addition to being registered to be launched from the launcher, it is

recommended that:
Web application be accessible from presentation managers in
locations where the functionality that they provide is appropriate to
the context.
Stand-alone web applications that do not have a native code version
have registration files that allow them to be presented via the native
code HP OpenView products (for example, Manage X, NNM NT or
NNM UNIX).
Chapter 2
51
Web Applications
This will allow users that have a native-code product running locally
on the system to access all of the functionality that is available via
the web.
Required
New launcher registration entries must not add tabs beyond the
specified set.
The tabs are intended to group functionality in ways that make it easier
for users to access the functionality when they are using the different
approaches to management (Exception Driven, User Guided, and Task
Based), that are presented in User Approaches to Management in
Chapter 1 .
Recommended
New launcher entries should be defined so they fit within the predefined
launcher categories presented in Appendix A , HP OpenView Launcher
Categories.
Using the predefined categories will keep the launcher consistent and
will make it easier for users to find and access related functionality.
Recommended
If categorization of the application is ambiguous and different users may

look for it under different tabs, multiple entries in the launcher should
be provided for the application.
For example a reporting capability for an application should be
registered to be accessed under the Information and Report tab and the
Tools tab of the Launcher. If the user is thinking of the report he wants to
see as information, he will look under the Information and Report tab. If
the user is thinking of the name of the application that provides the
report, he will look under the Tools tab.
Recommended
In the Object tab, launcher entries should be provided down to the level
of the context entries for presentation managers. Entries should NOT
be provided for views contained within the context.
For example, a network application should register a launcher entry for
the IP internet under the Network Views category but should not
register 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 to

the items listed in the context control of the object presentation manager.
For more information on context controls see Context Controls in
52
Chapter 2
Web Applications
Chapter 5 . For information on object presentation managers see Object
Presentation Managers in Chapter 3 .
Recommended
In the Task tab, entries should be provided for categories of tasks and the
tasks that users would want to do. Entries should NOT be provided for
subtasks within a task.
For example, an application that provides service management should
provide task entries for creating and modifying service level agreements
but should not include entries for modifying the service availability
parameters 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 or
View OV Users under Security Management.
NOTE
It is a good idea to have the top level task categories on the task tab of
the launcher, correspond to items in the context button of a task
presentation manager. The applications entries into task tab of the
launcher should correspond to the tasks listed in the scope pane of the
task presentation manager. For more information on context controls see
Context Controls in Chapter 5 , for information on task presentation
managers see Task Presentation Managers in Chapter 3 .
Recommended
In the Tools tab, entries should be provided for applications and for the
tools provided by the application. Entries should NOT be provided for
each piece of functionality provided by the tool.
For example, the HP OpenView Network Node Manager should provide a
top level entry for the Network Node Manager application and lower
level entries for the Network Presenter, SNMP Data Presenter, and
Alarm Browser. Entries should not be provided for individual types of
information presented through the SNMP Data Presenter.
Chapter 2
53
Web Applications
NOTE
It is a good idea to have the entries in the tools tab of the launcher
correspond to the separate graphical user interfaces provided by the
product.
Required
Applications must NOT provide entries for the Management Area tab.
This tab is intended to be configured by the HP OpenView administrator
to match the type of management that is anticipated to be done and to
provide quick access to frequently used capabilities.
Applications can provide commented out entries for the Management
Area tab to aid the HP OpenView administrator in setting up a tab that
would be focused on a given type of management. For example a service
management application could provide commented out registration files
to place views, tasks, and tools related to service management within a
single tab.
Required
When launched from a launcher entry, the application must present

functionality that directly corresponds to the label of the launcher entry.
For example, an application that provides views of objects has registered
launcher entries for routers, printers, and web servers. When the user
selects the router entry, the application comes up with the router view
displayed. When the user selects the printer entry, the application comes
up with the printer view displayed.
Recommended
When an application is currently open and the user selects a launcher

entry that accesses that same application, the newly requested
information should be presented within the existing instance of the
application rather than starting a new instance of the application.
Users do not want to have large number of windows open on their
desktop. 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 that
explains the operation of the launcher entry and the type of functionality
that is accessed by the entry.
Required
Applications registered in the launcher must set the locale for the
application based on the session locale set by the user. See HP OpenView
54
Chapter 2
Web Applications
Integration Series: OpenView Windows Developers Guide for more
information.
Graphics Used in Launcher

The HP OpenView Launcher provides a set of default icons that can be
used by applications registered with the launcher. Applications also have
the 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 representation
of the type of object contained in the category presented on top of the
folder. See Figure 2-2, Icons for Categories and for Leaf Level Items.
Required
Leaf level items that provide application access from the launcher should
be include icons that represent the type of application functionality that
is being launched. See Figure 2-2, Icons for Categories and for Leaf
Level Items.
Figure 2-2
Icons for Categories and for Leaf Level Items
Recommended
Icons used in the launcher should follow the guidelines for symbols
presented in Chapter 6 , Objects and Symbols.
Launcher and Security

The HP OpenView Launcher provides login security and basic user roles
for HP OpenView applications. The user roles determine the entries that
are presented in the launcher after the user logs in. These user roles can
also be used by the application for filtering the information and
functionality that can be accessed.
By default the HP OpenView Launcher is shipped with the following
user roles:
Chapter 2
55
Web Applications
Network Administrator
This role is intended for individuals who have a higher level of
knowledge of the network, how it functions and how to trouble shoot
problems with the network. Applications that provide capabilities for
configuration of the network and major connecting devices should
specify this as their associated user role.
Network Operator
This role is intended for individuals who do routine trouble shooting
and maintenance tasks associated with the network. Applications
that provide capabilities for monitoring the network and routine
modifications to the network and network devices should specify this
as their associated user role.
NT Systems Administrator
knowledge of NT systems, how NT systems function, and how to
trouble shoot problems with the systems. Applications that provide
capabilities for configuration of the NT operating system should
NT Systems Operator
and maintenance tasks associated with computer running the NT
operating system. Applications that provide capabilities for
monitoring NT systems and routine modifications to the systems
should specify this as their associated user role.
UNIX Systems Administrator
knowledge of UNIX systems, how UNIX systems function, and how to
trouble shoot problems with the systems. Applications that provide
capabilities for configuration of the UNIX operating system should
UNIX Systems Operator
and maintenance tasks associated with computer running the UNIX
operating system. Applications that provide capabilities for
monitoring UNIX systems and routine modifications to the systems
should specify this as their associated user role.
56
Chapter 2
Web Applications
HP OpenView Administrator
This role is intended for individuals who do configuration of HP
OpenView environment and management applications. Components
of management applications that are associated with configuration
and customizing of the management application should specify this
as their associated user role.
The file in which the user roles are specified is the htgroup file.By default
each of the preconfigured user roles is available to all users. This allows
the functionality to be accessed by all users until the HP OpenView
Administrator modifies the htgroup file to restrict access to specific
users.
Recommended
In the launcher registration file, applications should specify the user role
that would typically be associated with the users of the application.
The specification of the user role will allow the HP OpenView
Administrator to restrict access to the application if this is appropriate to
their application.
Recommended
The predefined user roles should be used whenever possible. Do not add
new user roles unless predefined user roles are inapplicable to the
application.
Recommended
If a new user role is defined in the htgroup file, the default specification
for the user role should contain the all wildcard (+) so that all user
logins can access the functionality. Only the HP OpenView
Administrator in the customers site should restrict the functionality
associated with applications.
Launcher and Session Information

The HP OpenView Launcher provides session level context information
including locale, user login and user roles. The functionality presented in
the HP OpenView Launcher is filtered to restrict the functionality to
match the roles associated with the user who started the session.
Applications can obtain the session information from the launcher. They
can then create an implementation that uses this session information to
filter the functionality and objects that they present.
Chapter 2
57
Web Applications
Required
Applications must use the locale set by the user for the session.
See the The Integration Series: HP OpenView Windows Developers Guide
for information on how to access session information available from the
launcher.
58
Chapter 2
Web Applications
Use of Web Browsers
Use of Web Browsers

When developing an application using web technology, the role of the
web browser within the application must be established.
An application that is presented in a web browser can be so presented
with full browser controls or with restricted controls. The advantage of
an application with full browser controls is that it can offer quick access
to other web-based information needed by a user. Conversely, the use of
full browser controls can be detrimental to an application by creating
navigation problems, difficulty in accessing controls or information due
to screen clutter, and restrictions on interaction style. In particular,
navigation problems can occur when a user tries to use the navigation
controls associated with the web browser and the results do not match
his expectations. For example, the user has been navigating in a
hierarchy of managed objects and accesses online help text associated
with a given area; when he uses the [Back] button to return through the
network of managed objects, he may at some point re-access the help text
that he had forgotten he had accessed, an action which will likely confuse
him.
Java Applets
A Java applet can be presented either in a browser window or outside a
browser in a Java frame. Which method an applet uses is dependent on
the characteristics of that applet. The interaction style of an applet
presented within a web browser window is to some extent determined by
the web browser and the user settings within the browser. Presentation
of an applet in a Java frame provides more flexibility. However,
presentation of a Java applet in a Java frame can result in the
presentation of extraneous browser windows that must be kept around
in order for the Java applet to continue running.
Recommended
As more of the following criteria are met, the more appropriate it is for
the Java applet to be presented in a Java frame instead of inside a
browser window:
Users want to resize the window (for example, the application is
running over a long period of time, and information is presented in a
tree list that may expand).
Chapter 2
59
Web Applications
Use of Web Browsers
When Java applets are presented in a browser window, they stay a
constant size and do not change size when the user resizes the
browser window unless specific coding is done to enable the applet to
change size.
The applet has a large amount of functionality and will need to
present the user with a menu bar.
Java does not currently allow menu bars for applications presented
inside browser windows.
The set of applets that make up the application can be implemented
such that there is only a need for a single browser window to be
running in the users environment (not one browser window per
applet).
The applet presents all the necessary navigational controls inside it,
and there is no need for the navigational controls provided by the
browser.
There are numerous java applets running, and users may benefit
from having an application-specific title bar when a window is
minimized.
When running in a web browser window, the title bar always starts
with the name of the web browser and the name of the object being
acted on (but the name of the application may not be visible when the
window is minimized).
The applet is running in an environment where the majority of the
Java applets are running outside of a web browser window, and it will
be more consistent for the user to have all Java applets running in
their own windows.
Recommended
the Java applet to be presented in a browser window instead of inside a
Java frame:
Users will have no need to resize the applet (for example, the user
interface is up for only a short period of time, and all information can
be presented in a small amount of space).
The applet has a limited amount of functionality that can be handled
via a toolbar or controls within the applet.
The applet will be running under conditions that will require a
browser window to be associated with each applet.
60
Chapter 2
Web Applications
Use of Web Browsers
Presenting the applet in the browser window will save a user from
having two windows on his desktop when only one is required.
The applet needs to use the navigational controls provided by the
browser.
There are few applications running in browser windows, and a user
will be able to easily identify each application window even when
they are iconified.
The applet is running in an environment where the majority of the
application functionality is provided inside a web browser windows,
and it will be more consistent for a user to have all Java applets
running in web browser windows.
Recommended
Provide a window with a progress indicator that is presented when the

Java applet is first accessed.
When a Java applet is first started, it may take a significant amount of
time for the applet to be downloaded onto the client system. A user might
become confused if there is no ongoing indication that the system is
working on his request. The progress window will provide the user with
feedback that the system is working and the applet is being loaded.
Optional
Provide a picture above the progress indicator to make the window more
visually appealing to the user.
Recommended
Automatically dismiss the in progress window when the Java applet is

up and running.
Users do not want to be forced to dismiss the in progress window if it
serves no other purpose after the main application window is presented.
Type of Browser Window

When an application is presented in a web browser with full controls, the
application controls must compete for display space and user attention
with the menus, toolbar, and other controls provided by the web browser.
Consequently, the full set of browser controls should only be maintained
when they would benefit the user. On the other hand, presenting an
application in a web browser with the browser controls removed may
require that the application duplicate some of the functionality that the
browser controls were providing (for example, back).
Chapter 2
61
Web Applications
Use of Web Browsers
Recommended
the application to be presented in a browser window with full browser
controls:
A users primary job involves interacting with a variety of web
locations and unrelated applications that are accessed over the web.
The interface is used on a periodic basis to access information, but is
not considered a primary tool for accomplishing the users tasks.
The application is initially accessed from a web browser window with
full controls and the user would have no need to maintain the current
results of the web browser window when the new application is
presented, that is, the new application can overlay the contents of the
browser without interfering with the users tasks.
Recommended
the application to be presented in a browser window with the browser
controls removed:
The application presents all the necessary navigational controls
inside the frames it uses, or the application has limited functionality
(for example, a single page of content) and no need for navigational
controls.
The application would take up less display space if it were presented
in a web browser window with the controls removed.
A users job primarily involves interacting with applications that do
not require the use of the web browsers location control for access (for
example, any necessary applications are accessed from a presentation
manager or from the HP OpenView Launcher instead).
The environment in which a user is working is one in which browsers
controls are extraneous, and their removal will benefit user task
performance.
The application is initially accessed from a web browser window
without controls and the user would have no need to maintain the
current content of the web browser window when the new application
is presented, that is, the new application can overlay the contents of
the browser window without interfering with the users tasks.
62
Chapter 2
Web Applications
Web Applications and Security
Web Applications and Security

Customers do not want all Internet users to be able to access their
management applications and to manipulate the systems and networks
that are being managed. Because of the openness of the web, some form
of security beyond the basic user login to the system is required for all
web applications.
Basic Security Measures

Recommended
To protect both the user data and the network and system elements
being managed, web-based management applications should provide
security 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 HP
OpenView Launcher.
A user should not be required to give a login name and password for
every new URL or application that he accesses on the web. Since the HP
OpenView Launcher provides a login for the user and then passes this
user information on to applications, this should be the primary
mechanism for controlling access to web applications. See Launching
Web Applications earlier in this chapter for more information on the HP
OpenView Launcher.
User Roles and Security

Different customer environments have different requirements for
security. Within the same customer environment, different users may be
permitted to have access to only a subset of the functionality that is
provided in a given application.
Recommended
If an application provides the ability to configure different access rights

for users, it should be developed so that users are not presented with
links to which they do not have access. It is both confusing and
frustrating for a user to click on a link and then be told that he cannot
access that link.
Chapter 2
63
Web Applications
General Guidelines for Web Interfaces

Web pages that present application functionality have the specific
purpose of enabling users to do their tasks. These types of web pages are
different from web pages intended for other purposes, such as
information searches, advertisements, entertainment. The difference in
purpose requires specific guidelines for the application-focused web
pages.
Named Web Browser Windows

Using named browser windows can organize the users functionality into
groups and can allow for the simultaneous presentation of functionality
in different windows when this is appropriate to the users task. Java
script can be used to call named windows and this will allow the reuse of
browser windows for related functionality. This same use of Java script
can allow for the presentation of functionality in a new browser window
when this is appropriate.
Recommended
All web applications presented in a browser should be presented in

named windows.
Recommended
The names of the browser windows should be published so that other

applications can use the appropriate named windows when calling the
functionality.
The launcher registration file allows for the use of named windows and
these registration files can serve as a source for information about the
named windows being used by other applications.
Recommended
If the application provides a means of opening a new window containing

the same functionality as the current window, the new window will not
be named.
Leaving the new window unnamed will keep the copied window from
being overwritten unless the user takes an action directly within the
window. The original named window will be overwritten when related
functionality is accessed in a separate window.
Recommended
All of the following guidelines should be used in defining names for

named browser windows:
64
Chapter 2
Web Applications
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 presentation
manager that will be presented in the window.
Examples of named windows include:
OvWwwSnmpData
Name for the window that presents

the SNMP Data Presenter.
OvWwwHelpWindow
Name for the full browser window

that presents HTML help.
Using Color and Patterns

Color is a very powerful visual cue that can be used by an application to
convey important information (for example, the status of managed
objects). But, if color is overused, it is no longer effective as a visual cue
and can interfere with information reception. In addition, the overuse of
colors can cause problems for users whose system displays might have
limited color maps.
Recommended
Use color only to present important information to a user or as part of

the symbols that represent objects. For additional recommendations
about symbol design and the use of color, see Chapter 6 , Objects and
Symbols, and Chapter 8 , Visual Presentation.
Recommended
Verify that the colors used in an application will display as expected on

all systems and browsers that the application supports.
Different browsers and browsers on different operating systems support
different color ramps. The colors that an application can provide for its
graphics 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 their
previous use of hyperlinks. If an application changes the colors it uses for
its links, users may have difficulty in recognizing and using these links.
Chapter 2
65
Web Applications
Recommended
Do not change the color of text that is presented in the main area of the
application. Users will have trouble reading the text if there is
insufficient contrast between the background color and the color of the
text.
Required
Any use of color should be consistent with the HP OpenView-defined

status colors for objects. For additional information about status colors,
see Table 2-1.
Table 2-1
Defined Color Usage for HTML Based Applications
Color
Name
Hexadecimal
Value for Color
Defined Color Use
white
#ffffff
1) Background in scope pane

2) Background inside tables that allow selection
3) Text on title bar in application window
4) Background for reports
black
#000000
1) General text presented in application

2) Labels for controls
navy
#000080
1) Title bar for application
lightsteelblue
#c0c0ff a
1) Highlight to surround selected items in the scope pane

2) Highlight to surround selected items in a table
lightgrey
#c0c0c0
1) Background for controls

2) Background in tabbed controls or wizards
3) General background in result area
4) Background for toolbar area
lightyellow
#ffffe0
1) Background for help text

2) 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
66
Chapter 2
Web Applications
Table 2-1
Defined Color Usage for HTML Based Applications
Color
Name
Hexadecimal
Value for Color
Defined Color Use
yellow
#ffff00
1) Minor status
orange
#ff8000 a
1) Major status
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
a. Hexadecimal values are different than the named colors for browsers.
Recommended
Java applets and applications should use the Java System Color
Variables for setting the color of interface components. See Table 2-2 for
specific recommendations.
Use of the System Color Variables will enable an applets to appear as an
application running natively on the client system.
Table 2-2
Defined Java System Color Variable Usage
System Color
Variable Name
Defined Use In HP OpenView
background
None
activeCaption
1) Highlight around label of selected items (icon views,

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)
Chapter 2
67
Web Applications
Table 2-2
System Color
Variable Name
activeCaptionText
1) Text in label of selected items (icon views, scope pane,

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 without focus

(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, and

pull-down menus
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
68
Chapter 2
Web Applications
Table 2-2
System Color
Variable Name
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 (for example
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 icon presentation

formats
controlDkShadow
None
scrollbar
1) Scrollbar
info
None
infoText
None
Recommended
Do not present background patterns on an applications web pages if the

pages contain information that a user needs to read.
Chapter 2
69
Web Applications
Displaying patterns adds clutter to the display and distracts the user
from his intended task. Many background patterns also detract from the
legibility of any text presented in the display.
Using Fonts
If an application manipulates the fonts on its web pages, keep in mind
that not all systems have the same fonts.
Recommended
Do not specify specific fonts (for example, <FONT FACE="Futura">) to be

presented unless it can be verified that these same fonts will be available
on the users systems.
Ensuring that specific fonts are available on a users system may require
the application to download the font for the user.
Recommended
Do not change the font size for most text presented in the display. This is
especially true for extensive text that users will need to read.
Users may have their font sizes set to meet their individual preferences
or abilities. For example, users who have vision difficulties may
intentionally set an applications fonts to larger sizes so they can more
accurately see the information that they are trying to read.
Recommended
If the font size for text presented in the browser is changed, it should be
done relative to the default font size rather than by setting an absolute
font size. Setting font size relative to the default allows users to maintain
control over the font size they are viewing (for example, <FONT
SIZE="-2">).
Optional
The font size of controls or buttons used in the screen can be set to allow
them to adequately fit in the display.
Using Graphics and Images

Recommended
Use images on a web page only if the presentation of the image will
improve user performance over the presentation of simple text alone.
Images can lengthen the time to load a web page. In addition, too many
non- specific images can add clutter to the display and make it difficult
for a user to understand how to accomplish his tasks in the application.
70
Chapter 2
Web Applications
Extraneous images with words like NEW and Hot have no place on
application web pages.
Recommended
Keep the size of displayed images small both in overall display size and
in file size.
Larger images take longer to load than smaller images. They also take
up display space. When running an application in a web browser, display
space is at a premium as the web browser already takes up a large
amount of the usable display space.
Recommended
Provide an alternative textual means of presenting important

information for users who may have configured their browsers to not
present graphical information.
Recommended
Provide users with clear visual cues to indicate which images or portions
of an image have a link associated with them. Visual cues that users will
associate with links include the following:
Presenting the images as three-dimensional controls that are similar
in appearance to push buttons in regular application windows.
Making any portions of images with links appear to be raised above
the 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 in
accord with the guidelines for flashing discussed in Chapter 8 , Visual
Presentation.
Scrolling
Recommended
Minimize the need for users to scroll information in the screen.

Long web pages can cause some information to be hidden while other
information is visible. User testing suggests that users would prefer to
access all needed information at a glance without the need to scroll
through it.
A users willingness to accept scrolling is partially dependent on the type
of information that is being presented as well as on how he is trying to
use the information. If users are managing a large number of objects or
dealing with large amounts of information, it is difficult and not
Chapter 2
71
Web Applications
necessarily meaningful to eliminate scrolling of the information. In such
cases where scrolling cannot be completely eliminated, the recommended
approach is to view the screen from the point of view of the user and the
type of task that he is doing.
Recommended
Make the most important information highly visible, and provide visual
cues for accessing information that is currently not visible. Minimize the
number of steps that a user must take to make the hidden information
visible.
Even if content must be scrolled, a user should not need to scroll
backward 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 constantly
available.
If frames cannot be used, provide access to controls at both the top
and bottom of the results pane.
Navigating
The way users expect to navigate within an application is not the same
as when they are browsing for information on the web. User experience
with applications has led them to expect tightly controlled navigation
based on their tasks. User experience with browsing for information on
the web has led them to expect navigation based on links and the
sequence in which they have accessed these links.
In a web-based application, users can benefit from having both the
tightly-controlled application navigation presented in the application
space and sequential navigation presented through web browser
controls. To make this strategy work well, adhere to the following
guidelines.
Recommended
Make sure that navigation via the browsers [Back] button leads to the
locations that would be anticipated by a user. Information that is not
part of the main interaction with the application should be presented in
a separate window.
A user will likely become frustrated when the [Back] button takes him
to help text or an error message when he was anticipating the previous
page in the application.
72
Chapter 2
Web Applications
Recommended
If an application consists of more than a single web page, provide

controls on all web pages that will allow users to navigate quickly to
important application locations, using the following mechanisms.
A [Help] button that will allow a user to access help information in a
separate web browser.
A link or control that takes the user directly to the main application
page.
A link or control to allow the user to move upward in the application
space if the application consists of hierarchically arranged pages.
A frame that acts as a scope pane which allows the user to access
various 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 of

bookmarks takes a user to the information that was visible when the
bookmark was set, and not to the location that was initially defined in
the frameset.
Updating Application Information

Information on managed objects will not be useful to a user if it is
inaccurate or out of date. Design the application so that it keeps any
information it presents adequately updated.
Recommended
Provide a visible timestamp in association with information that will

change dynamically. The timestamp should indicate the time at which
the information was loaded into the browser.
NOTE
When the information is updated, for example, the user reloads the web
page or the application automatically reloads information, the
timestamp should be updated.
Recommended
Important information that changes dynamically and which needs to be

accurate should be automatically updated by the application, rather
than being dependent on the user to refresh the displayed information.
Chapter 2
73
Web Applications
It is recommended that this information be maintained via server push
mechanisms, which allow for faster presentation of a pages subset.
Recommended
Less dynamically changing information (or information that is less

crucial to be accurate) can be handled either through:
A [Refresh] button provided in the toolbar.
Various client pull mechanisms that change the information
automatically.
74
Chapter 2
Web Applications
Web Applications Based on HTML

Using HTML
Different web browsers support different HTML commands, and
sometimes present the same HTML in different ways. To be sure that an
application is working as anticipated, test the interface on all of the
system/browser combinations that the application will support. Be
particularly careful when using advanced HTML capabilities.
Using Frames
Frames make use of the features of web browsers to structure an
applications functionality to better match the structure applications
which are presented outside of web browsers. The frames can be used to
provide a separation between the application and the web browser, to
keep user controls constantly visible, and to provide a quick-access
mechanism for navigating to different capabilities provided by the
application.
Recommended
The use of frames is recommended for most applications, unless the

application is intended for users who will typically not have access to a
web browser with frame capabilities.
Recommended
The use of frames is recommended for:

Applications where users have functionality presented at two or more
levels 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 off
the screen if the information is presented without frames.
Using Tables
Recommended
Minimize the number of borders presented in tables, as these borders

can cause visual clutter.
Recommended
If tables are being used to provide an even layout of information rather

than an actual table, specify the table to be without borders.
Chapter 2
75
Web Applications
Recommended
If the background of a table cell is to be used for indicating a selected or

open object, set the background to lightblue.
The color light blue allows text to be readable and allows the hyperlink
associated with the text to be visible. See Table 2-1, Defined Color Usage
for HTML Based Applications, for information on the specific RGB
values for colors.
Using Forms
Forms are the typical method for collecting user input in an HTML based
application. The guidelines for the design of forms in HTML are the
same as those for the design of dialog boxes when using Java or C++. See
recommendations in Chapter 9 , Dialog Boxes and Controls, for
guidelines 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 the
form.
76
Chapter 2
Web Applications
Components of Web Applications

Guidelines for windows and window components for Java applications
and applets presented in Java frames as well as native applications
presented in windows are presented in Chapter 4 , Using Windows, and
Chapter 5 , Window Components. This section covers the window
components that should be provided by applications that are presented
inside a web browser.
Just as windows have different components associated with them, so do
web pages for applications have different components associated with
them. Maintaining a certain level of consistency across these key
components can aid a user both in learning to use various HP OpenView
applications and in locating information within each application. Key
components to be used in applications presented inside a web browser
include
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 a

web browser. If an application uses frames, the title bar should be
presented in a separate frame.
The title bar provides contextual information that informs the user of his
location within the application when a new web page is presented. The
title bar also provides the user with a visual cue that separates the
application window from the web browser and its controls.
Recommended
The title bar should use the colors specified in Table 2-1, Defined Color
Usage for HTML Based Applications, or Table 2-2, Defined Java
System Color Variable Usage.
Chapter 2
77
Web Applications
Recommended
The size of the title bar area should be approximately 30-40 pixels in
height, and it should extend across the entire page.
Recommended
Graphics can be presented in the title bar if they will help identify the
application. 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 being
presented in the web browser, how the page was accessed, and whether
the contents of the window are associated with a single object or multiple
objects. Follow the recommendations in Chapter 5 , Window
Components, for the format and content of the title bar.
Context Area
Required
If an application allows users to switch between different management

contexts (different hierarchies of managed objects or different types of
management 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 side
of the toolbar directly beneath the title bar, or as a control within the
toolbar.
Recommended
The context control should determine what information or controls are

presented in the web page. A change in the context control may result in
a change in all frames presented on the web page. See Context Controls
in Chapter 5 for more information on context controls.
Toolbar
Since there is currently no way to present a pull-down menu in an
application presented in a web browser, most functionality associated
with the web application should be presented in a toolbar frame or in tool
buttons in the results pane. The toolbar in the web browser, unlike the
toolbar in an application window, is not simply a quick-access
mechanism. It may be the only method for accessing functionality.
78
Chapter 2
Web Applications
NOTE
When functionality becomes available for true menus, web applications

should provide a menu pane for presenting the bulk of their
functionality.
Recommended
An application should provide a toolbar if the application presents

objects 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 (for
example, graphic versus tabular view of objects).
Recommended
If an application provides so much functionality that the toolbar will

need to scroll, the application should be created so that it runs in a Java
frame 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 different
location.
Recommended
Only display toolbar buttons in the toolbar frame which are applicable to
the current context.
Following this guideline will minimize the number of controls presented
in the toolbar at any one time.
Recommended
Provide visual cues for the toolbar buttons to make it clear to users that
they can be clicked on for accessing functionality.
Visual cues that can be used to inform users that the toolbar images
access functionality include:
Providing tool tips that indicate the functionality that can be accessed
by the button.
Making the images change on mouse over so that it is clear that they
can be activated, this is similar to the visual cues provide in the
Netscape and Internet Explorer Browsers.
Giving the images in the toolbar a three-dimensional appearance so
that they appear to users as if they can be pressed.
Providing a label for the image that is underlined. Since hyperlinks
Chapter 2
79
Web Applications
are typically underlined, the underlining of the label will indicate to
the user that the image and label are a link to some other
functionality.
Recommended
If there is an HP OpenView-provided toolbar buttons for the

functionality that is provided in the application, use a GIF image of the
existing toolbar button to provide access to that functionality. See
Chapter 6 , Objects and Symbols, for more information.
Recommended
If there are no HP OpenView-provided toolbar buttons that match the

functionality of the application, develop a GIF image that looks like a
button and contains an image which clearly represents the action to be
associated with the button.
It is always a good idea to run user tests on the icons to be used in the
toolbar. Tests should evaluate both a users ability to associate the icon
with the functionality it represents and the users ability to recognize the
icon 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 functionality
that will be accessed by clicking on the button.
Provide pop-up messages that appear when the pointer moves over
each toolbar button.
These pop-up messages can be provided by specifying alternative text
associated with each of the images.
Provide active help in the status area of the same window that
contains the toolbar. The active help should change as the pointer
moves 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 the
results pane.
Appear grayed-out when the user selects an object in the results pane
for which the toolbar button functionality is not available.
80
Chapter 2
Web Applications
Scope Pane
The scope pane is on the left side of the page under the context control
and toolbar. Items presented in the scope pane should provide users with
links to different sets of information that can be presented in the results
pane.
Recommended
Provide a scope pane in an application window if the application consists

of 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 the
results pane.
Required
The scope pane must be resizeable by the user.

The scope pane takes up space that would otherwise be used to present
the content of the web page. Therefore, when a user has finished with the
scope pane, he may want to redistribute the window space to better suit
his task needs.
Recommended
If a user changes the current context by means of the context control, the
scope panes contents should also change to match this new context
setting.
Required
Any currently selected items in the scope pane should be marked by a

selection indicator or by a selection toggle.
If a selection indicator is used, it should be a block of color
surrounding the items label. See Table 2-1, Defined Color Usage for
HTML Based Applications, and Table 2-2, Defined Java System
Color Variable Usage, for information 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 mutually
exclusive).
A check box (if multiple selection of items is allowed).
Recommended
To minimize user actions, radio buttons or check boxes should

automatically be submitted when the user clicks on them. Users should
not be required to click on a submit button after making a selection via a
radio button or check box.
Chapter 2
81
Web Applications
Recommended
The location cursor in the scope pane should be indicated by one of the
following:
A black rectangle outlining the item that the location cursor is on.
An arrow pointing at the items icon or label and which is placed to
the left of the label.
Results Pane
The results pane is the area used for presenting both any managed
objects and the main functionality of the application.
Recommended
When a user first enters the application window, the results pane should
not be empty. If there is a scope pane in the window, the results pane
should present the information associated with the first link in the scope
pane or the last link that the user accessed within this application
context.
Recommended
If an application requires the selection of both an object in the results

pane and an action in the toolbar, a user should be able to select the
objects without taking a step to submit his selection. For example, the
user should not have to press a submit button after a selection before
they can access actions in the toolbar.
Recommended
If an application provides functionality that is applicable to some, but

not all, objects in the results pane, any toolbar buttons that are
inapplicable to the currently selected objects should be grayed. If these
inapplicable toolbar buttons cannot be grayed, consider presenting the
objects in a table. Provide functionality that is applicable to only a subset
of objects in a column labeled Operations, as shown if Figure 2-3. This
functionality should be presented in the row for an object only if it is
applicable to that object.
82
Chapter 2
Web Applications
Figure 2-3
Web Application
Chapter 2
83
Web Applications
Control/Status Frame
The use of a control/status frame is optional for HP OpenView web
applications.
Recommended
If a control/status frame is provided, it should be presented beneath the

results pane in a separate frame.
Recommended
The control/status area should be used to provide state information

relevant to the objects or information presented in the results pane, or to
provide users with controls that need to be constantly visible but which
are too complicated or inter-related to be presented in the toolbar.
84
Chapter 2
HP OpenView Presentation
Managers
85
HP OpenView Presentation Managers
Presentation managers are windows which present users with views of

managed objects, access to functionality for manipulating objects,
guidance in accomplishing tasks and/or a means of presenting
information on managed objects. Presentation managers are
distinguished from other windows in that they are designed to suit the
users needs and to minimize the number of windows that the user needs
to navigate through in order to accomplish their goals. Typically
presentation managers will allow the integration of other related
applications so that users can access necessary information for a given
management area or task from within a single window.
This chapter discusses the various types of presentation managers that
are recommended for the HP OpenView environment and some of the
guidelines associated with their implementation. The presentation
managers described include:
Object Presentation Managers
Task Presentation Managers
Information Presentation Managers
Multiple Purpose Presentation Managers
86
Chapter 3


Object presentation managers present views of managed objects and
provide access to functionality for managing those objects. For an
example of an object presentation see Figure 3-1. Typically these
presentation managers present object folders, object groups, container
objects, 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 object
presentation managers or are integrated into object presentation
managers (for example, Network Presenter or Manage X). General
guidance on the style for object presentation managers is too detailed to
be presented in this chapter and can be found in chapters 4 through 8 of
this style guide.
Recommended
Object presentation managers are recommended for applications that

deal with managed objects and want to provide views showing
relationships between objects and information on the attributes of the
objects (for example, status, properties).
Required
The scope pane of an object presentation manager should only contain

object folders, object groups, container objects (for example, subnet), or
individual objects.
For more information on guidelines for the scope pane see Scope Pane
in Chapter 5 . For more information on object groups, see Groups in
Chapter 1 .
Required
The information in the results pane of an object presentation manager

must be directly related to the selected object in the scope pane. This can
include any of the following.
Graphical views related to the selected object or object groups (for
example, topological views of object relationships, pictures of the
objects back-plane or controls).
Charts and graphs showing data relevant to the selected object or if
the selected object is an object group or container, data on a subset of
the contained objects may be shown.
Chapter 3
87

Table of data relevant to the selected object or if the selected object is
an object group or container, data on the contained objects may be
shown.
Tab control with the properties of the selected object group, container
object or individual object.
A wizard or tab control for a frequent task related to the selected
object, container object, or individual object.
Recommended
If a wizard or tab control is presented in the results pane of an object

presentation manager, follow the guidelines on the use of wizards, use of
tab control and the labeling of push buttons under Task Presentation
Managers below.
Recommended
Object presentation managers should provide menu access to other

presentation managers related to the objects that they present.
Figure 3-1
Object Presentation Manager
88
Chapter 3


Task presentation managers provide user access to wizards and tab
controls that guide the user through task steps and allow the user to
quickly access related tasks. Typically these presentation managers
present tasks folders and individual tasks in the scope pane. In the
results pane, they present lists of tasks, wizards or tab control for
accomplishing the task.
In addition to recommendations and requirements presented in this
section of the style guide, other guidance on the style for task
presentation managers can be found in Chapter 2 , Web Applications,
Chapter 4 , Using Windows, Chapter 5 , Window Components, and
Chapter 9 , Dialog Boxes and Controls.
Figure 3-2
Task Presentation Manager with a Task Presented in a Wizard
Chapter 3
89

Recommended
Task presentation managers are recommended for applications want to

take a task oriented approach for presenting their functionality and
which have no need to allow users to access the functionality in terms of
the object being acted on.
Required
The scope pane of an task presentation manager should only contain

task folders or individual tasks.
in Chapter 5 .
Required
The information in the results pane of an task presentation manager

must be directly related to the selected item in the scope pane. This can
Graphical views of tasks if the selected item is a task folder (for
example, large or small icon views of tasks).
Table of information on contained tasks if the selected item is a task
folder (for example, task name and task description).
Tab control or wizard for accomplishing the task if an individual task
is selected.
Recommended
The task presentation manager should present the task as a wizard that
guides the user through the task using next and previous buttons when
one or more of the following are true:
The task involves a set of steps or subtasks that the user must do in a
proscribed sequence to successfully complete the task.
The task involves a set of steps or subtasks and users must complete
each step or subtask to successfully complete the task.
Users do the task infrequently and will need guidance to complete the
task.
Creation and initial configuration are examples of tasks that are best
presented in a wizard. See Figure 3-2 for an example of a task presented
in a wizard inside a task presentation manager.
Recommended
The task presentation manager should present the task in a tab control
where the user can choose what tabs they want to access and modify
when:
90
Chapter 3

The task allows users to complete actions or subtasks in any
sequence.
The task does not require user interaction for all subtasks or steps
and 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 task
steps in an unconstrained manner.
Modification of settings and new configurations based on a template are
examples of tasks that are best presented in a tab control. See Figure 3-3
for an example of a presentation manager with a tab control.
Figure 3-3
Task Presentation Manager with Task Presented in a Tab

Control
Recommended
The labeling of buttons used at the bottom of tab controls presented in a

task presentation manager should correspond to the behavior that will
would be expected based on the label:
[OK] should only be used if the wizard or tab control for
accomplishing the task will be removed when the button is pressed.
Chapter 3
91

The task presentation manager should not be closed when the user
clicks on an [OK] button.
[Apply] or [Save] should be used in place of [OK] if the tab control
or wizard will not be removed when the button is pressed.
[Cancel] should only be used if the wizard or tab control for
accomplishing the task will be removed when the button is pressed.
[Reset] should be used in place of [Cancel] if the wizard or tab
control for accomplishing the task will not be removed when the
button is pressed.
Typically[OK] and [Cancel] are only appropriate for multiple purpose
presentation managers in which the wizard or tab control will be
replaced by a view of managed objects related to the task that was
completed or canceled.
Recommended
Task presentation managers should allow users to bring in selections

when they are launched from object presentation managers. They should
also allow users to access object presentation managers when users need
to make a large number of selections.
Recommended
When a user has started a task in the task presentation manager but has
not completed it before starting a new task in the same presentation
manager:
The users should be given a means of reaccessing the partially
completed task at a later time without the loss of entered data.
or
Before the initial task is overlaid, the user should be presented with a
confirmation dialog box indicating that the data will be lost if the user
chooses to proceed with the new task.
Examples of mechanisms for reaccessing the partially completed task
would include the use of navigation tabs (see Navigation Tabs in
Chapter 5 ) that allow access to the task (see Figure 3-4) or providing a
back button that would take users back to the screen with the partially
completed data.
92
Chapter 3

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

Presentation Manager
Recommendation
When there has been a change of state in an ongoing task, that is not
currently visible in the task presentation manager, there should be a
visible indication to the user of the change in state. When navigation
tabs are provided:
A check mark on the left side of the navigation tab is recommended as
a visual indicator that the task was successful or there is a change in
state 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 indicator
that there is a change in task status that includes an error.
Providing a visual indication of a change in state, notifies the user that
they should return to the task to determine what has happened. In the
example in Figure 3-4, the check mark in the navigation tab is indicating
that the installation of the software have been completed.
Chapter 3
93

Required
When the user takes an action that successfully completes a task within
the task presentation manager and the wizard or proprieties box is not
removed, a message must be given that indicates that the task has been
successfully completed.
Required
When the user takes an action to complete a task within a task

presentation manager and there is an error that prevents successful
completion of the task, an error message must be presented that
indicates what problems prevented the task from successfully being
completed.
Users expect to have feedback on the completion of a task. Tasks
presented in a stand-alone wizard, have the wizard disappear when the
user presses the [Finish] button. Similar completion feedback is needed
in a task presentation manager. The presentation manager should not be
dismissed when the user completes a task as the user may want 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, the feedback
needs to be in the form of a message. See Figure 3-4 for an example.
Recommended
If a task presented in a tab control has related tasks that the user may
want to do after finishing the initial task, all guidelines below should be
followed:
The last tab in the tab control should present users with information
on the related tasks and a means of accessing the functionality to do
the related tasks.
In the Related Tasks tab, visual cues should be provided that allow
differentiation between related tasks that are optional and related
tasks 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 tasks
that are optional should be indicated by the word (Optional) in
parentheses in following the task name.
If there are related tasks that are required for the user to achieve the
most likely goals of the initial task, the related task tab should
automatically be presented to the user at task completion, instead of
a completion message.
Immediately taking users to the related task tab instead of giving a
completion message when related tasks are required helps prevent user
errors. When users are new to an application or when they do tasks
94
Chapter 3

infrequently, they may not recognize the full sequence of tasks that are
needed to accomplish a larger goal. Users are not required to do the
related task from this tab. They can choose to put off related tasks that
are required until a more convenient time. See Figure 3-5 for an example
of a tab for related tasks.
Even when related tasks are optional, having a related task tab provides
benefits to the user. This tab helps inform users about loosely related
tasks and introduces users to other functionality that your application
provides.
NOTE
Related tasks that are required and which cannot be deferred to a later
time should be presented as steps in the tab control or wizard.
Figure 3-5
Related Task Tab in a Task Presentation Manager with a Tab

Control
Chapter 3
95


Like object presentation managers and task presentation managers,
information presentation managers minimize the number of windows
that appear in the display by reusing the results pane. Information
presentation managers may provide an integration point for tools that
act on similar types of objects. Information presentation managers also
help to eliminate menu clutter by allowing multiple tools to be accessed
by means of a category name that represents all of the tools of a given
type. Information presentation managers can also increase user
effectiveness and efficiency by allowing the user to access a variety of
information on the objects included in the selection list without the need
to return to the menus in an object presentation manager window. For an
example of a information presentation manager see Figure 3-6.
In addition to recommendations and requirements presented in this
section of the style guide, other guidance on the style for information
presentation managers can be found in Chapter 2 , Web Applications,
Chapter 4 , Using Windows, Chapter 5 , Window Components,
Chapter 8 , Visual Presentation, and Chapter 9 , Dialog Boxes and
Controls.
96
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 of
management information that they provide (for example, SNMP
Data, Reports).
Tools that require the same capabilities in the objects on which they
can act (that is, the same selection criteria in the registration file).
Chapter 3
97

Required
The scope pane of an information presentation manager should only

contain folders or individual reports or types of information that can be
accessed.
in Chapter 5 .
Required
The contents of the results pane of an information presentation manager

must be directly related to the selected item in the scope pane. This can
Graphical views of information or reports if the selected item is a
folder (for example, large or small icon views of information).
Table of data on contained reports or information if the selected item
is a folder (for example, report name and report description).
Charts, graphs, tables of information and/or relevant descriptive text
if the selected item is an individual report or information item.
Recommended
Information presentation managers should allow users to bring in

selections when they are launched from object presentation managers.
They should also allow users to access object presentation managers for
making selections.
Recommended
If information items or reports in an information presentation manager

require a selection but are not applicable to the current selection, they
should be shown as unavailable (that is, grayed).
Providing an error message after the user has selected the report or
information item results in unnecessary user actions and can frustrate
the user. The unnecessary user actions can be avoided by presenting the
appropriate visual cues.
98
Chapter 3


Multiple purpose presentation managers provide separate scope panes
which present different types of items, that is, tasks, information, or
objects. These presentation managers allow users to switch between the
different types of scope panes using context tabs at the bottom of the
scope pane.
Figure 3-7
Multipurpose Presentation Manager
Recommended
Multiple purpose presentation managers are recommended for:

applications whose functionality is implemented to allow the user to
choose the approach that he will want to take in accessing the
applications functionality (that is, task-oriented, object-oriented and
information oriented).
Chapter 3
99

Required
The multiple purpose presentation manager must provide context tabs to

allow users to change between the types of items that it provides (i.e.,
objects, information and / or tasks). A single scope pane should not
provide a mixture of tasks, objects and information.
For more information on context tabs, see Context Controls in Chapter
5.
Required
The behavior of multiple purpose presentation manager must conform to

the following guidelines:
When the context tab is set to objects, the presentation manager
behaves like an object presentation manager.
When the context tab is set to tasks, the presentation manager
behaves like a task presentation manager.
When the context tab is set to information, the presentation manager
behaves like an information presentation manager.
100
Chapter 3
Using Windows
This chapter covers the following topics:
Types of windows that can be used in HP OpenView applications and
guidelines on when to use each type.
101
Using Windows
Guidelines for splitting application windows.

Guidelines on when to create new windows as compared to using
existing windows.
102
Chapter 4
Using Windows
Windows in the HP OpenView Environment

The basic means by which an application presents managed objects and
allows access to application functions is through primary windows and
dialog boxes. Dialog boxes are discussed in Chapter 9 , Dialog Boxes and
Controls. This chapter and Chapter 5 , Window Components,covers
guidelines 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
Microsofts Management Console (MMC) and Manage X both use MDI

windows. It is also possible that other future HP OpenView management
platforms may use MDI windows. As a result, it is not recommended that
integrating applications use MDI windows. This could potentially cause
a MDI window inside a MDI window.
Scope Pane Windows

Scope pane windows are ones that have a scope pane and a results pane.
Scope pane windows minimize the number of windows that appear in the
display by reusing the results pane to present different sets of
information (for example, managed objects, tasks, or information and
reports). Scope pane windows allow users to select the objects, tasks or
data to be presented in the results pane by making a selection in the
scope pane. The selection can be from a hierarchical listing of objects or
from sets of categories that are matched to determine the objects that are
presented. These windows allow users to quickly move between different
types of data.
The management hierarchy that is presented in the scope pane provides
navigational cues to users so they are less likely to get lost in complex
hierarchies. Returning to previously viewed information requires fewer
Chapter 4
103
Using Windows
user steps, as multiple locations at different levels in the hierarchy are
simultaneously visible and accessible. See Figure 4-1.
Scope pane windows that present categories of information allow the
user to select multiple categories and to see data from the combination of
these categories in the content pane. The categories act somewhat like a
filter and allow users to quickly see different amounts of information.
See Figure 4-2.
Figure 4-1
Scope Pane Window with Network Hierarchy
104
Chapter 4
Using Windows
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 a
hierarchy of levels within a correlation definition).
Sets or groupings of loosely or tightly related objects or components
that 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 are
specific well-known categorizations or filters that users would want to
apply, based on the characteristics of the objects or data (for example,
reports on objects that can be filtered).
Chapter 4
105
Using Windows
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 of
related topics.
Sets or groupings of tasks that can be categorized and presented to
the user.
Sets of functionality that can be categorized and presented to the user
in a meaningful hierarchy.
Single Pane Windows

Single pane windows provide the user with a view of a single set of
objects that is separated from other information which may or may not
be relevant to the users task.
Optional
Single pane windows can be used for:

Displaying objects or information when navigation, filtering, or access
to other objects are not necessary for the users task.
Displaying tasks that can be completed in a single window of
information without any need to access other objects, information or
tasks.
Recommended
When possible, single pane windows should be integrated with other

applications in a scope pane window.
Multiple Pane Windows

Developers can chose to have multiple window panes which used for
purposes other that navigation as in the scope pane or presenting a
single set of results as in the results pane of a scope pane window.
Recommended
Multiple pane windows should be used only for complex activities where
the user needs to carry out multiple types of activities simultaneously
and the panes are needed to separate different types of information (for
example, navigation, controls, or summary information).
106
Chapter 4
Using Windows
Figure 4-3
A Multiple Pane Window
Chapter 4
107
Using Windows
Split Windows
Split Windows
Split windows are windows in which the number of panes being
displayed 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 results
pane can be associated with different items in the scope pane, implement
all 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 two
scope panes.
If there are navigation tabs, they would be presented in each of the
two results panes.
Navigation and context tabs have visual cues that make them appear
to be attached to the window contents. This may confuse users if the
tabs are not contained within the pane in which they will change the
information. See Figure 4-4 for an example.
Recommended
If a scope pane window can be split but the contents of the split results
pane can only be associated with a single item in the scope pane, only the
results pane should be split.
Splitting only the results pane maximizes the amount of display space
used for viewing the object, tool outputs, data set, or task.
Recommended
If the mechanism for splitting of window allows a user to specify what is

to be presented in the new pane:
The top or left-half of the split should contain the requested
information.
The bottom or right-half of the split should show the view that was
active at the time the split was requested.
A pop-up menu that provides an item labeled Show in New Pane is an
example of a mechanism that allows users to choose what information is
presented at the time they request the split.
Recommended
If the mechanism for requesting the splitting of the window does not
108
Chapter 4
Using Windows
Split Windows
allow a user to specify what goes in the new pane, the split should result
in 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 are
examples of mechanisms that do not allow users to choose what
information is to be presented at the time they split the window.
Recommended
If functionality is provided for splitting a window, a means of changing

the information in the different split panes needs to be provided.
Mechanisms for changing the information in split windows include:
Scroll bars in both halves of a split window provide a means of
viewing different locations within the same object, tool output, data
set, or task.
Scope panes in both halves of a split window allow users to choose
different objects to be presented in the split results pane.
Navigation tabs in both halves of a split scope pane window allow
users to navigate to different views.
A context list tied to the active pane in a split window allows users to
present different information in each of the split panes.
Recommended
In a split window, the contents of the menu items, toolbar items, and
context list should be determined by the pane that is active (has the
focus).
Having the menu and toolbar items tied to the context of the active pane
is intuitive for users. Different panes within the window are made active
by clicking in the pane. When a user selects an object within a pane, it
should make the pane active and set the menu context to the view in that
pane. This will result in a set of menus that is tailored to the objects
within the active view.
In Figure 4-4, the top scope and content pane are currently active. The
menu bar and toolbar are specific to this pane. Users can use the context
control to change the navigation hierarchy for one of these panes and
leave the context for the other pane unchanged.
Recommended
The active pane of a split pane window should provide visual cues to the
user to indicate that it is the active pane.
Examples of visual cues to indicate that a pane is active include a black
box surrounding the active pane or a more brightly colored selection
cursor.
Chapter 4
109
Using Windows
Split Windows
Figure 4-4
A Split Scope Pane Window
110
Chapter 4
Using Windows
Creating New Windows

It is very typical in web applications to access a link and have that new
information or functionality overlay the current results pane. Similar
behavior occurs with scope pane windows. While it is generally a good
idea not to clutter the users display with numerous new windows, there
are occasions when the presentation of a new window will benefit the
user.
Adhere to the following guidelines when deciding whether or not to
present a new window.
Recommended
If a user will want to have simultaneous access to an existing windows

contents as well as to any newly requested material, then present the
requested information in a new window.
Examples of ways that users request new information includes selecting
menu items, pressing push buttons, or selecting links in web
applications.
Recommended
If the information is likely to be used in a sequential manner with no

need for simultaneous viewing, present the information in the current
window.
Recommended
If a user is working with an application and takes an action that will

result in the presentation of help information, and there currently is no
open window that is displaying help, open a new window containing the
requested help information.
Allowing a user to look at the application window at the same time that
he reads the help information will provide the most benefit from the help
that is presented.
Recommended
If a user is working with an application and takes an action that will

result in the presentation of help information, and there currently is a
window that is displaying different help information, use the open help
window and overlay the displayed help information with the requested
help information.
Recommended
If a user requests access to an application that is already running in a

separate window, bring the open window to the top displaying the
requested functionality.
Chapter 4
111
Using Windows
For example, an application presents detailed information on objects in a
separate window. This allows users to simultaneously view the status of
various 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), the
detailed information on Object A is replaced with the information on
Object B.
Recommended
If a user presses a toolbar button to request the presentation of the

current view in a new window, present a new window that provides the
same information that was in the initial window.
112
Chapter 4
Window Components
113
Window Components
The windows used for HP OpenView applications have a number of

different components, as shown in Figure 5-1. Maintaining a certain
level of consistency across these key components can aid users in
learning to use various HP OpenView applications and in locating
information within them. Key HP OpenView window components
discussed 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
114
Chapter 5
Window Components
Identification of Window Components
Identification of Window Components

At a minimum, every HP OpenView application must provide a title bar
and a results pane in their windows; the remaining components shown
below are optional.
Figure 5-1
Window with Its Components Identified
Chapter 5
115
Window Components
Title Bar
Title Bar
The title bar provides the user with a means for distinguishing different
windows that may be presented on the desktop. It also provides
contextual information to inform a user of his location within the
application. When an HP OpenView application window is presented
within a web browser, it provides the user with a visual cue (the title bar)
that separates the application window from the web browser and its
controls.
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, whether
there are multiple instances of the window, how the window was
accessed, and whether the contents of the window are associated with a
single object or multiple objects.
Recommended
The title bar should contain specific fields in a specific sequence, as

shown 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 much

definitive information as possible when he first reads the title, or to
identify the windows contents when it is minimized and the title is
truncated.
icon:
The icon should be a 16x16 graphic that represents the

application or set of applications associated with the
window.
object, tool, task or item: This entry is intended to provide a user with
information that is related to where he is within the
application and what he is currently doing. As the user
navigates within the window and changes the
information presented in the window, this field within
the title bar should change to match the current
location in the window:
If the results pane of the window is related to a
single object, that objects name should appear in
116
Chapter 5
Window Components
Title Bar
this field (for example, as in an object presentation
manager).
If the results pane of the window is displaying a set
of data, the name for the data set should appear in
this field (for example, as in an information
presentation manager).
If the results pane of the window is presenting a
task, the tasks name should appear in this field (for
example, as in a task presentation manager, dialog
box or wizard).
application name: The application name is required in the title bar
because there are typically multiple applications
running in an HP OpenView environment. If a user
encounters a problem or needs to access
documentation, he will need to know which
applications documentation to read. To save space, it is
recommended that the application name be presented
in abbreviated format. Examples of application names
presented in abbreviated format are NNM, ITO, and
ITA.
window id:
The window id is helpful to users for differentiating

between multiple open windows which contain the
same title. The window id would be a number such as
1, 2, or 3. The window id is only used when the user has
opened new window which has the same content as an
existing window open on the display.
An example of a title bar for an object presentation manager focused on a

single object appears below:
An example of a title bar for an object presentation manager for which

the user had accessed a second window with the same content as an
existing window is shown next:
An example of a title bar for an information presentation manger

showing the routing table for one or more objects would look like the
following:
Chapter 5
117
Window Components
Title Bar
An example of a title bar for a task presentation manager where the
current tasks is setting up a new alarm would be this:
118
Chapter 5
Window Components
Menu Bar and Pop-Up Menus

Menu Bar
Menu bars provide a means of making the application functionality
visible to the user while occupying a minimal amount of display space.
They minimize the clutter associated with the presentation of
application functionality. Unlike pop-up menus, the menu bar is
continuously visible, and this provides a cue to the user about the type of
functionality that is potentially available. It is therefore much easier for
users to learn to use functionality provided in a menu bar than in pop-up
menus.
One of the fundamental concepts of HP OpenView is to prevent user
errors whenever possible. By using consistent cues in the menu labels,
an application can give users information on how each item functions
before they select an item. And menus which are used in a consistent
manner will provide continuity between applications.
The menu bars within HP OpenView application windows should follow
the following recommendations.
Optional
Menu bars are optional for HP OpenView application windows. However,

if a large amount of functionality is presented in an applications window,
a menu bar is recommended.
Recommended
Do not specify application-specific menu items to be presented in the

menu bar of an HP OpenView application window; this should be done
only by the developer who is responsible for creating the navigation
context that is presented in an applications window. Instead, menu
items should be placed under the existing menu bar categories.
Recommended
Developers who have created the hierarchy presented in their

applications window should choose appropriate menu items from the
container, general-purpose, or managed-object menu subsets described
below.
Container Menu
This type of menu should contain menu items that are related to the
access and manipulation of the container itself. It also has menu items
Chapter 5
119
Window Components
for 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 menu

should always be the left-most menu item in the menu bar.
Required
All application windows must have a Close menu item in the first menu
in 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 of
managed objects being presented and whether or not the managed
objects are contained in files.
In a context that presents network objects, for example, the name of the
container menu could be Map or Network. Other examples for this menu
might be Processes (for a process management application) or Circuits
(for an application that is used for building event correlation circuits). In
applications that deal with files, it is recommended that the name of the
container menu be File.
Recommended
If there is no meaningful container menu for your application, you

should use File as the container menu.
File is used as the container in a large number of applications. Users will
not be confused by having it as the first menu in your menu bar.
However, they would become confused if there is no container menu at
all in the application.
General-Purpose Menu
Typically, general-purpose menus do not contain specific management
functionality. Instead, these menus provide generic functionality that is
needed by a variety of applications, regardless of the specific type of
management functionality being provided by the application. While some
of these menus will be used by all applications (for example, Help), other
general-purpose menus (such as Edit) will be needed only by a subset of
the applications. When general-purpose menus are used, HP OpenView
users will benefit from having consistent naming in the menu bar and
consistent placement of menu items under these menus so that they can
easily locate this common functionality.
120
Chapter 5
Window Components
When providing the general functionality that is not specific to a type of
management, present the functionality under the appropriate generic
menu bar label as described below.
Edit
Use for menu items that edit the content of the current
location in the managed object hierarchy and the
properties of managed objects. The Edit menu can also
contain menu items that allow the user to locate
symbols, objects, or locations within the application.
Examples of menu items to be presented under this
menu include New, Cut, Copy, and Paste.
View
Use for menu items that affect the way the current
data is presented. The View menu does not contain any
option that alters the data itself. Examples of View
menu items are Toolbar, Pan and Zoom, and
Presentation Formats.
Options
Use for menu items that provide access to global

settings which control the functionality associated with
an application and the way it behaves. Use this menu
for items relating to the configuration and customizing
of an application.
Help
Use for menu items that allow for access to online help
information, application documentation, version
information, and tutorials.
Tools
Use for accessing generic services, utilities, and

peripheral functionality that is less directly tied to the
managed objects presented in the current window.
Items in the Tools menu should include only those
that act on the objects being manipulated by the
application, rather than on the management
application itself.
Window
Use this menu item to provide quick access to

important windows that users need to access
frequently in the process of accomplishing their tasks.
Do not place routinely-managed object locations in this
menu if they can be accessed by other mechanisms
within the current window, (for example, the scope
pane). Important views should be placed under the
Chapter 5
121
Window Components
View menu. When scope pane windows are used, there
is no need for this menu and it is recommended that it
not be used.
Recommended
If menu item only allows the user to add specific managed objects, place
the menu item under the Edit menu and label this item in a way that
will 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 label
for 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 each
available presentation format should be presented under the View menu.
Recommended
If a user can configure various aspects of the presentation format,

provide this configuration in a properties box that is accessed from the
View->Options menu.
Required
All applications in HP OpenView which provide a menu bar must include

a 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 menu
items.
Optional
If it will be beneficial to users tasks, the Help menu should provide

access to reference documents using the menu item, Reference Pages.
Menus for Managed-Object Functionality
These menus provide the primary functionality for an application. They
enable users to access actions which perform such management tasks as
backing up a system, obtaining data on a router, changing a systems
hostname and IP address, or monitoring a services status.
OSI has defined a set of categories for classifying network and system
management functionality: Performance, Configuration, Fault,
Accounting, and Security.
HP OpenView recommends that managed-object functionality be
provided by means of menus named for the OSI categories or by means of
122
Chapter 5
Window Components
an Action menu. Which of these two alternatives is most appropriate for
your applications functionality is dependent on the functionality being
provided, types of objects that are being managed, the homogeneity of
the objects that are presented at any given level within the management
hierarchy, and the variability in the types of functionality being made
available to users.
Recommended
Use OSI category menus if any of the following are true:

The applications functionality is being integrated into an application
area that uses the OSI category menus.
The application presents a hierarchy of managed objects in which
each level in the hierarchy will typically contain a wide variety of
object types. Applications that allow other applications to integrate
with 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 uses
the Action menu.
The application presents a hierarchy of managed objects in which
each level in the hierarchy will typically contain homogenous types of
objects, while different levels in the hierarchy will contain different
types of objects. Systems management applications are frequently
like this in that they contain categories of objects at higher levels in
the hierarchy, while lower levels contain a relatively homogenous set
of objects (for example, users, disks).
The application is designed to provide a task or information
OSI category menus provide a categorization of menu items based on the
type of management capabilities that is being provided. Since there are
five different categories, this allows the application to spread out their
menu items by placing them under categories that are related to a users
tasks.
Performance
Use for menu items which allow users to view

information associated with the performance of the
network or managed objects within the network. Also
use for menu items directed at improving the
performance of the managed objects.
Configuration Use for menu items which allow users to view or

Chapter 5
123
Window Components
modify configuration settings associated with managed
objects.
Fault
Use for menu items which perform troubleshooting and

diagnostics, and which fix network and system
problems that are not associated with the configuration
of managed objects.
Accounting
Use for menu items which allow for the setting up of

accounting, monitoring, and billing services associated
with the usage of the network or managed objects.
Security
Use for menu items which allow for the setting up of

security services, the monitoring of security breaches
and security configuration, and for any ongoing
security maintenance.
The Action menu provides a single location for all functionality which
act on the managed objects in the current window. This menus contents
may vary as a function of the level in the managed object hierarchy and
the currently-selected item. But, because variation in the content of the
menus is limited to specific menus (that is Action and Tools), users
quickly learn about the variable nature of these menus.
Action
Use for menu items which allow users to act on the

managed objects that are selected within the current
view or view hierarchy.
Required
Action menu items which require the multiple selection of different

types of objects should be continuously available in the Action menu.
Conversely, these menu items should be grayed if the current selections
are inappropriate for making them available.
Recommended
If there is both an Action and an Edit menu, the Action menu should
not include items associated with editing, adding, deleting, copying. Put
these items under the Edit menu instead.
Some applications only have a small number of different types of objects
to present within their window or navigation hierarchy. These
applications can use either an Action menu or an object-based menu in
the menu bar.
<objectname> If an application window presents only one or two
specific types of objects, and they have a limited
number of menu items, use object-based menu items in
place of the Edit and Action menus.
124
Chapter 5
Window Components
Examples of object-based menu items can be Printers
and Queues (see Figure 5-4).
Recommended
If an application is using object-based menus, it should not have an Edit

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

object-based menus and an Action menu in the menu bar at the same
time.
Sequence of Menu Bars
To provide consistency and ease of use, the sequence of menu bar items
should not vary across applications.
Recommended
If a menu bar uses OSI category menus for presenting application

functionality, the sequence of items in the menu bar should be the same
as 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 in
Figure 5-3:
Figure 5-3
Sequence for Items in Menu Bars Using an Action Menu
Recommended
If a menu bar uses one or more object menus to replace the Edit menu
and OSI category menus, all object menus except the container should be
presented before the View menu. In Figure 5-4, the object menus
appearing before the View menu are Printers and Queues.
Figure 5-4
A Menu Bar Using Object-Based Menus
Chapter 5
125
Window Components
Pop-Up Menus
Menu items in pop-up menus are presented when a user clicks the menu
button on the pointing device. These menus are sometimes referred to as
context menus.
Required
Pop-up menus are required for HP OpenView applications that present

symbols which represent objects.
Recommended
Menu items in pop-up menus associated with objects should be restricted

to object-specific or symbol-specific functionality.
Recommended
General functionality should be presented in a pop-up menu associated

with the background of the results pane of the window.
Recommended
Whenever possible, items in pop-up menus should also be placed on the

pull-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 to
access them. A user may not know how to access pop-up menus or not
remember that they exist. If functionality is only available in a pop-up
menu, some users may never access it.
Optional
If a menu item acts on the symbol only and does not affect the object
associated 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
an object by means of a Properties menu item; this item should be the
last one in the pop-up menu.
Recommended
Pop-up menus should not contain grayed menu items. If a menu item is
temporarily unavailable, it should be removed from the pop-up menu.
NOTE
This is in contrast to pull-down menus where items should be grayed if

they are temporarily unavailable. Pop-up menu items are intended as a
quick-access mechanism for experienced users. The graying of
126
Chapter 5
Window Components
temporarily unavailable menu items is primarily a learning aid.
Experienced users do not require this learning aid, and it detracts from
the performance benefits of keeping the pop-up menus short.
Context and Menu Items

HP OpenView is a family of products that are frequently integrated with
one another. In this broad environment, it is important that the menu
items match the types of objects and functionality that users would
expect within the current view. Users would overwhelmed if the menu
items for all integrated applications were simply appended together in a
single set of pull-down menus.
To aid users in their tasks, contextual information should be used for
filtering the menu items that will be presented. For pull down menus,
this contextual information should be derived from the hierarchy of
objects that are presented in the scope pane and from the view that is
currently visible in the results pane. Pop-up menus should use this same
contextual information as a starting point and should add contextual
information on the object or symbol that is under the pointer.
Recommended
Items in the menu bar must be consistently maintained across all levels
in an object hierarchy. New menu items should not appear as a result of
navigating to a lower level in the hierarchy, nor should existing menu
items be removed.
Required
With the exception of the Tools and Action menus, menu contents must
be consistently maintained across all levels in a hierarchy. If a menu
item is temporarily unavailable because of the set of items currently
displayed in the results pane or because of the current selection, this
menu item should be grayed rather than being removed from the menu.
Research shows that users become confused when menu items appear
and disappear from the menus. Having a menu item visible, but grayed,
lets users know where they need to go to access this functionality; it also
provides a visual cue to indicate that users must change the state of the
application in order to access the menu item.
NOTE
Restricting the changing menu items to the Action and Tools menu
will minimize learning difficulties for users. Experience across HP
OpenView applications and applications integrated into Microsofts
Chapter 5
127
Window Components
MMC will train users to expect menu items in these menus to be
variable.
Recommended
If menu items in the Action menu require multiple selections of different

types of objects (for example, a router, and a PC), these menu items
should be continuously presented in the Action menu and be grayed
only when they are not applicable.
Required
Pop-up menu items must be consistently maintained across all instances

of an object within a given view. Different pop-up menu items can be
presented in different contexts and views.
Optional
Menu bar items, as well as the contents of menus, may be changed when
a user changes to a different context via the context control in the
toolbar.
Recommended
Menu items that are specific to a special-purpose window should only be

available in the context of that specific window.
An example of a menu item for a special-purpose window is the Add
Selected Symbols menu item in the Quick Navigator of NNM.
Application Registration Files
Applications that integrate with HP OpenView Network Node Manager
define their menu items via the application registration files. These
registration files provide menu placement rules that will help determine
the views where menu items are placed. Menu placement rules are
boolean expressions that will result in a value of TRUE when evaluated
with the view context identifiers for the views in which menu items will
appear.
NOTE
In NNM, a submap is a type of view.
The menu registration files have context identifiers that determine

where menu items should be presented. The context identifiers allow
appropriate functionality to be available for a users tasks, without
having the menu clutter that would exist if all menu items from all
applications were continuously available.
128
Chapter 5
Window Components
In addition to the guidelines on context and menu items presented above,
follow the guidelines below when specifying the menu structure for
pull-down menu items and pop-up menu items in application
registration files.
Recommended
Specify placement rules for Help menu items which match the placement
rules associated with the functionality that the help is describing. This
creates more context-specific help and to have it presented in the
appropriate submaps.
Optional
Recheck the view context for the hierarchy of views where menu items
will be placed. If the views do not have sufficient context identifiers to
handle the specificity of the menu items, add context identifiers.
Required
Do not specify a menu placement rule of AllContexts unless a menu item

is applicable to all managed object hierarchies and all levels within the
hierarchies. Examples of generic menu items that may be applicable for
All Contexts include print functions, generic graphing functions, and
functions that allow actions on the map.
Menu Structure
Changes to the menu structure of an application across releases can be
disruptive to the performance of the operators of the application in that
it will necessitate retraining. Therefore, it is best to define an
applications menu structure to handle its full functionality even though
not all of the functionality is provided in a given release.
Recommended
Minimize changes to the menu structure across releases by positioning

menu items based on the anticipated functionality of the application.
In initial releases with less functionality, display only the menu items
that are available in that release. Be sure to position these items under
the same menus in which they will be located when the full functionality
is provided.
Chapter 5
129
Window Components
For example, the initial release of an application may include the items
noted as Release 1 below, while the items noted as Release 2 are planned
for, but not included in the initial release:
Defined Menu Structure
Release #
Systems:
Change Password
Add
Delete
Set Network Access
2
1
1
2
Therefore, the Release 1 menu would look like the following:

Systems:
Add
Delete
Number of Items
The number of menu items within a menu panel can either enhance
user-task performance or it can interfere with performance. Using a
menu is a search task where the user is searching to find the item that
will provide the functionality that they need to access. Search
performance is aided by minimizing menu depth and by providing visual
and cognitive cues to aid the user.
Recommended
Menus at a given level should contain between two and fifteen menu
items (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, consider
moving the menu items to a higher level in the menu structure (but not
into the menu bar).
If possible in an application, use an approach similar to that provided in
the Network Node Manager menu bar where menu cascades with a
single menu item are pulled up to the menu level above.
130
Chapter 5
Window Components
For example:
Configuration: Backup ->
Schedule
becomes
Configuration: Backup: Schedule
Menu Depth
Recommended
Research indicates that the complexity of tasks increases sharply as soon

as the depth of a menu structure exceeds three levels. Therefore you
should 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 (for
example, Backup)
Level three: items that cascade from the pull-down menus (for
example, Schedule)
Thus,
Configuration: Backup ->
Schedule
Utilities
is the recommended full extent of pull-down menus.
NOTE
If necessary to avoid menu clutter, pull-down menus can have a 4th level
of 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 (for
example, Delete).
Level two: items that cascade from pop-up menu (for example,
Symbol).
Thus,
Delete ->
Symbol
Chapter 5
131
Window Components
Object
is the recommended full extent of pop-up menus.

Pop-up menus are intended for quick access. Having multiple cascades
off of these kinds of menus detracts from their ability to provide quick
access.
Menu Labels
Recommended
Choose a label for each menu item that clearly indicates the type of
functionality the menu item leads to and the extent of the items actions.
Where ambiguity could arise, use a label to indicate if the function acts
on all objects or a subset of objects, a single symbol, or the actual
resource being managed. For example:
Delete -> From This Submap
From Multiple Submaps
NOTE
Users need to be able to distinguish between operations that will affect

the actual resource being managed (such as files on a disk, data in a
database, or network devices) and operations that will affect only the
presentation of information in the management application. In some
cases, this distinction can be made explicit in the menu item name; in
other cases this may be difficult to do. Be aware of the potential for user
confusion.
Recommended
If a menu item does not provide clarification of the scope of its action, the
scope should be set to just the current object/symbol in the current
context. It should not affect all instances of the object in all contexts.
132
Chapter 5
Window Components
Cues for Types of Menu Items

Required
Provide cues on each menu label about the type of menu item. The cues
presented in Table 5-1 should be standard across all menu items in the
HP OpenView environment.
Table 5-1
Required Visual Cues for Menu Items
Type of Menu Item
Cue
Explanation
Unavailable
gray label
Menu items that are temporarily unavailable should have their

menu labels grayed.
Dialog box
...
An ellipsis following the label indicates that the item leads to a

dialog box that will require further user input before the requested
action can be carried out.
Chapter 5
133
Window Components
Table 5-1
Required Visual Cues for Menu Items
Type of Menu Item

- Commanda
Cue
none
A label followed by no symbol or by an accelerator is used for

access to a command or application.
->
An arrow following the menu item indicates that it leads to a new

menu.
- Applicationb
Cascading
Explanation
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 Separators
Menu separators are lines drawn across the menu that act to separate
menu items from one another. When overused, menu separators can add
visual noise to the menus and can have a negative affect on user
performance.
Recommended
Minimize the use of menu separators. Menu separators should only be

used when menu items are highly different from one another. If you have
a number of individual and very different menu items, do not present
them with separators between each item; instead, treat them as a group
of different items with a single separator between them and other menu
items.
Menu Mnemonics
Menu mnemonics are designators that allow a user to move the selection
cursor to a menu item through a keyboard mechanism. A mnemonic is a
single character which is contained in the label for the menu item and
which supports ease of learning and use.
When the location cursor is within a menu or a menu bar, pressing the
mnemonic key for a menu item within the menu moves the location
cursor to that item and activates it.
The following are guidelines for the use of mnemonics in menus.
134
Chapter 5
Window Components
Required
Mnemonics should be supplied for every pull-down and pop-up menu

item.
Required
Mnemonics for menu items that are added into an existing menu
structure should be chosen so they do not conflict with the mnemonics for
any existing menu items.
Recommended
Mnemonic characters should be chosen for ease-of-location within the

text of a label. Whenever possible, use the first character of the label. If
that is not possible, try to use the last character of the label or, if there is
more 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 HP
OpenView Mnemonics.
Menu Accelerators
If an application uses keyboard accelerators, follow the guidelines for the
platform on which the application will be delivered.
Recommended
Limit keyboard accelerators to frequently used functions. Pull-down

menu items which are infrequently used or which lead to destructive
actions should not have accelerators.
Recommended
If an application provides accelerators, each accelerators key

combination should be displayed to the right of the label of the menu
item.
Recommended
If an application is being integrated into another HP OpenView

application, do not redefine any of the standard accelerators provided by
the platform application or the operating system on which an application
will be delivered.
Recommended
Do not redefine accelerators that are typically found in applications that

will coexist with the application being developed.
NOTE
Should two or more applications use the same accelerators when

integrating into NNM, the menu for the application that is first
Chapter 5
135
Window Components
encountered by NNM will use the defined accelerators. These
accelerators will be invalid in the other applications that use them.
Recommended
Choose accelerators that are meaningful across applications. For

example, CTRL - v is the standard accelerator for the menu item Paste.
See Appendix B , Mnemonics and Accelerators, for information on the
standard mnemonics used in HP OpenView.
Help on Menu Items

Recommended
Users should be able to access help on all of an applications menu items.
Recommended
Provide access to context-sensitive help via F1 when the pointer is over a

menu item that the user wants to have explained.
Recommended
In the help text for menu items, indicate what functionality is supplied
by the menu item, the types of objects on which the menu item acts, the
conditions under which the item is unavailable, and any other relevant
information.
136
Chapter 5
Window Components
Toolbar Guidelines
Toolbar Guidelines
The toolbar is a set of graphic controls. It provides quick access to
functionality that is already available to the user by other methods. It
may give the user access to frequently used menu items and tools, may
provide navigation shortcuts, or may enable the user to change the
presentation format of data. Toolbar access can simplify the number of
steps needed to perform common operations.
Toolbars can be statically attached to the window in a single location, or
they can be designed like dockable tool palettes (where they can be
detached from the window border, float within the window, and be
dismissed when they are no longer needed).
When to use Toolbars

Toolbars are optional for HP OpenView applications. However, decisions
about whether to add tools to the standard toolbar or to provide a
separate dockable toolbar should be based on the following guidelines.
Recommended
Applications should add tools to the standard toolbar if these tools will
improve usability by enhancing user access to common operations. For
example, an application which provides a new presentation format for a
view of managed objects should add this presentation format to the
standard toolbar.
Recommended
Provide dockable toolbars for times when a user will benefit by having
quick access to a set of capabilities to use over a period of time and then
dismiss when he goes on to other activities. Applications which provide
several large menus can improve their usability by providing quick
access to frequently used menu items via a dockable toolbar.
Content of Toolbars
Toolbars are intended only for frequently accessed functionality, not for
all of the functionality in an application. Dockable toolbars can be more
extensive since a user can choose different sets of tools and dismiss them
when he has finished using them.
Recommended
Keep the number of toolbar buttons to a minimum by placing only
Chapter 5
137
Window Components
Toolbar Guidelines
frequently used functions in the toolbar. Make toolbar buttons
unavailable or remove them when they are no longer applicable to a
given view or selection.
Recommended
Make sure the functionality in the toolbar is also available through the
pull-down menus. When the standard toolbar is turned off or the
dockable toolbars are dismissed, the user will need another mechanism
for accessing the functionality provided in the toolbar.
Recommended
If an application allows multiple different presentation formats for

objects presented in the scope pane, provide access to those presentation
formats through buttons in the toolbar.
Recommended
If a history is kept of the views that are presented in the results pane of a
window, provide users with a [Back] button in the standard toolbar so
they can quickly access the last ten views that they visited.
Recommended
If an application uses dockable toolbars, provide tool buttons for all of the
major 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 menu
bar. It is desirable to allow users to move toolbars and to dock them at
any border within the window to which they are attached.
When toolbars contain only graphic representations of objects, it can
sometimes be difficult for users to associate the graphics with the
functionality that they represent. Also, when items are presented only
graphically, they cannot be made accessible to the visually impaired via
accessibility software.
Recommended
To aid users in recognizing and accessing the tools in the toolbars, use
one of the following mechanisms:
Provide pop-up messages or tool tips that pop up when the mouse
pointer rests on the tool button.
In the windows status bar present context sensitive active help for
the toolbar button currently under the pointer.
Include labels under every graphic to indicate what they represent.
Caution should be used in providing labels under icons. If the label is
138
Chapter 5
Window Components
Toolbar Guidelines
part of the graphic, the graphic will need to be redrawn in order to be
localized.
Recommended
Enable users to hide the toolbar. While the toolbar is beneficial to some
users, it takes up display space that other users may want to use for
another purpose.
Required
If multiple dockable toolbars are provided, access to the available

toolbars should be provided through the View->Toolbars... menu as well
as through a toolbar button in the standard toolbar.
Recommended
Dockable toolbars should remain open while a user is using them. The
user should be able to dismiss these toolbars when they are no longer
being used.
Optional
If toolbar buttons act on selected objects, it may benefit the users to be

able to drag and drop managed objects from the content or scope pane
and to drop them on the toolbar button to activate the command
associated 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 for

the functionality that a toolbar button is providing, use the existing
graphic in the toolbar button.
Recommended
If there is no appropriate HP OpenView- or operating system-provided

graphic, develop a graphic that clearly represents the action being
provided by the toolbar button.
It is recommended to run user tests on any graphics to be used in the
toolbars. These tests should evaluate both a users ability to associate the
graphic with the functionality it represents as well as his ability to
recognize 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 NT
operating system.
Chapter 5
139
Window Components
Toolbar Guidelines
Recommended
The graphics used in toolbar buttons should be chosen so that they are
not specific to any given culture.
Recommended
The graphics used in toolbar buttons should be provided in files that can
be replaced when localizing an application for a specific country.
Required
If a toolbar button will cascade to a second level of items, provide a

graphic with a downward pointing arrow that will display the second
level of toolbar items once the tool button is clicked. See Figure 5-5.
Required
For toolbar buttons that are presented through NNM application

registration files, provide a grayed-out version of graphics for any button
which will be grayed whenever its functionality becomes unavailable.
Toolbar Structure and Customization

Recommended
If dockable toolbars are provided, break the toolbar buttons into sets of
similar types of functionality that users will want to use together. There
should be a separate dockable toolbar for each set of tools.
Recommended
If an application permits a user to choose from multiple variations of the

same type functionality (for example, presentation formats for data or
variations of sorting of objects in the data), provide these functionality
variations 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 the
possibility of lower-level tools in a cascading tool button. See Figure 5-5
for an example.
Recommended
Allow users to customize the contents of the toolbars.
140
Chapter 5
Window Components
Toolbar Guidelines
Context Control Within the Toolbar

Rather than opening new windows whenever the user wants to access a
different type of functionality or to obtain information on a different set
of objects, HP OpenView suggest the use of a context control that is
provided in the toolbar of the application window.
Recommended
If an application allows users to switch between different management

contexts (for example, different hierarchies of managed objects, different
types of management capabilities such as accounting versus systems
management, or different sets of managed objects), provide the ability to
switch contexts through the context control in the toolbar. See Context
Controls 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 of

selections within a view. New toolbar buttons should not appear as a
result of selecting different objects in a view, nor should existing toolbar
buttons be removed.
Optional
Toolbar buttons may vary from view to view within a context or

navigation hierarchy.
Recommended
Toolbar items that are specific to a given window should only be

available in the context of that specific window.
Follow these guidelines when specifying toolbar placement rules for
toolbar items.
Application Registration Files
Applications that integrate with HP OpenView Network Node Manager
define their toolbar buttons via the application registration files. These
registration files provide placement rules that will help determine the
views where toolbar buttons are placed. Placement rules are Boolean
expressions that will result in a value of TRUE when evaluated with the
view context identifiers for the views in which toolbar button will appear.
Required
When specifying toolbar items in the registration files, provide

Chapter 5
141
Window Components
Toolbar Guidelines
placement rules that will help determine the views where toolbar items
will appear.
Required
Do not specify a placement rule of AllContexts for a toolbar buttons

unless that button is applicable to all managed object hierarchies and all
levels within the hierarchies, and users will want to have immediate
access to this functionality at all times. Close Window is an example of
one of the few operations that satisfy this criteria.
142
Chapter 5
Window Components
Description Bar Guidelines

The description bar is message area that goes across the top of the scope
and results panes. It provides information to a user on what is currently
being presented in the scope and results panes. In Figure 5-6,
Management Hierarchy appears in the portion of the description bar
above the scope pane, while trees.new.tc.com appears above the
results pane.
Figure 5-6
Description Bar over the Scope and Results Panes in a Window
Recommended
Description bars are specifically recommended for applications windows

that:
Have a scope pane with context tabs. In this case, the description bar
helps users see the current setting of the context tab presented in the
description bar.
Have a scope pane with no context list. In this case, the description
bar can serve as a label for the scope pane.
An application whose scope pane does provide a context list can use
the list (instead of a description bar) as the label for the pane. The
context list helps to identify the type of items to be found in the scope
pane. For applications with a context list, the description bar provides
redundant information.
Do not have a scope pane, but which do allow users to navigate within
the results pane.
If there is no scope pane, the description bar provides a label for the
information presented in the results pane.
Recommended
If a description bar is provided, controls should be provided to allow

users to turn the description bar on or off.
Recommended
The following guidelines should be used to determine the text to put in

the description bar above the scope pane:
Chapter 5
143
Window Components
If the scope pane contains context tabs, the description bar should
indicate which context tab is active (such as Object Hierarchy or Task
Hierarchy).
If the scope pane does not have context tabs or a context list, the
description bar should indicate the contents of the scope pane. This
would be equivalent to the name that would be in the context list if
multiple contexts were available in the window.
Recommended
The portion of the description bar above the results pane should display
the name of the open object whose contents are presented in the results
pane.
144
Chapter 5
Window Components
Context Controls
Context Controls
Rather than opening new windows whenever the user wants to access a
different set of objects or a different type of functionality, HP OpenView
suggests the use of context controls. These controls allow users to change
between different management contexts within the application window.
Two different types of context controls can be found in HP OpenView
applications: a context list and context tabs.
The context list is presented as a combo box on the left side of the toolbar
in the window. This list presents the contexts that are available for the
user 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. In
multiple-purpose presentation manager windows, the tabs can allow
users 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 (for

example, different hierarchies of managed objects, different types of
management capabilities such as accounting versus systems
management, or different sets of managed objects), the ability to switch
contexts is provided through the context list in the toolbar.
Chapter 5
145
Window Components
Context Controls
NOTE
Typically, context lists will be found in scope pane windows. Single pane
windows 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 toolbar
buttons.
Recommended
All contexts in the context list should be meaningfully associated with

one another from the users point of view.
Required
The name for a context in the context list should clearly indicate the type
of hierarchy or filter categories that will be presented in the scope pane.
Recommended
For task presentation managers, it is recommended that the names of

contexts in the context list be drawn from the predefined task categories
for the Task tab of the HP OpenView Launcher. See Appendix A , HP
OpenView Launcher Categories, for a listing and definition of the
predefined task categories.
Recommended
If different management hierarchies are presented via the context list, a

user-specified hierarchy that is based on user groupings of managed
objects should be provided.
Recommended
Context tabs should only used in multiple-purpose presentation

managers. See Multiple Purpose Presentation Managers in Chapter 3
for more information.
146
Chapter 5
Window Components
Scope Pane
Scope Pane
The scope pane is a vertical pane on the left side of the windows results
pane. Items presented in the scope pane provide users with the means of
navigating in the information space and controlling the information that
is presented in the results pane. Figure 5-9 and Figure 5-12 show
examples of scope panes.
General Guidelines
Recommended
A scope pane should be provided in the application window if user task

performance will benefit from any of the following:
Having a hierarchical listing of all objects in the management
environment.
Having a quick-access mechanism for navigating to and displaying
detailed information on specific locations within the management
hierarchy.
Having quick access to common filters, which specify the subset of
information to be displayed in the results pane.
Having a listing of tools in the scope pane, which allows quick access
of information or functionality.
Required
The scope pane must be resizable.

The scope pane takes up space that would otherwise be used by the
results pane. A resizeable scope pane allows redistribution of window
space to better suit user task needs once the user has navigated to the
desired location.
Required
If a user changes context with either the context list or context tabs, the
contents of the scope pane should change to match the new context
setting.
Recommended
While in the scope pane, pressing:

The Tab key should move keyboard focus to the results pane in the
window.
Chapter 5
147
Window Components
Scope Pane
The Shift Tab keys should move keyboard focus to the context tabs (or,
if there are no context tabs, to the context list).
The Tab key should allow a user to navigate between the various
panes and controls in the window. The sequence of movement based
on 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 Items

The scope pane in the window typically provides a hierarchy of objects,
tasks, or information. The appearance of the hierarchy will be dependent
on the depth of the hierarchy.
148
Chapter 5
Window Components
Scope Pane
Figure 5-9
Two Examples of Scope Panes Showing Hierarchies
See also the guidelines in Interactions between the Scope Pane and
Results Pane later in this chapter.
Recommended
If multiple, unrelated sets of items (see the left figure in Figure 5-9) are
simultaneously presented in the same scope pane, all of the following
guidelines should be followed:
Each set should have a category heading (for example, System
Information).
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 the
results 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 presented

in the scope pane, this hierarchy should be presented as a tree list. (See
the right figure in Figure 5-9 for an example.)
Chapter 5
149
Window Components
Scope Pane
For guidelines on navigation within a tree list and the behavior of the
controls within a tree list see Tree List Controls in Chapter 9 .
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 the
user and allows him to access information on that items 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 pane
unless the hierarchy will be large enough to cause performance
problems:
Examples of container items are task categories (such as
Configuration Tasks), information categories (such as System
Information), and compound objects (such as a network segment or a
computer system).
Examples of leaf-level items are individual tasks (such as Modify
SNMP Parameters), individual tools (such as CPU Utilization), and
lower-level objects (such as an IP Network Card).
Required
If leaf-level items (items that have no child items) are presented in the
scope pane for any portion of the hierarchy within a given context, they
must be presented for all portions of the hierarchy within that context.
Required
When the window is first opened the first container in the scope pane
should be expanded to show the user the items in that container.
It is confusing for users go into a window where the scope pane contains
a single entry that has not been expanded. Expanding the first container
in the hierarchy will provide greater visibility of available functionality.
It also provides sufficient visual cues to indicate that additional items
can be made available by expanding and contracting containers in the
scope pane.
Interactions between the Scope Pane and Results Pane
For further guidance, see Selection Guidelines in Chapter 7 .
150
Chapter 5
Window Components
Scope Pane
Required
When a scope pane window is first opened, the item in the scope pane
that corresponds to the information in the results pane should be
indicated as open.
An open item is visually indicated by a location cursor or a location
cursor plus a selection highlight surrounding it. See also Results Pane
below.
Required
When a container item is selected in the scope pane, the results pane
should display information that is relevant to the selected container.
Typically, the information presented is a view of the child items directly
under the container item.
For example, in a task presentation manager, the selection of the
container Service Tasks results in the presentation of a table with table
rows corresponding to the task folders and individual tasks contained
within Service Tasks.
In an object presentation manager, the selection of a container object
such as a network segment (for example, 10.5.106) results in the
presentation of the nodes within that segment (for example, the
computers, printers, bridges, and other network nodes).
Recommended
Use the following guidelines in determining what to present in the

results pane when a leaf-level item is selected. If the leaf-level item is:
An object, its properties are presented in the results pane. The
properties can be presented in a form view that shows a properties
box, or they can be presented in a tabular view.
A task, a wizard, or tabbed dialog box for the task should be
presented in the results pane.
A report or label for a set of data, the associated information should
be presented in the results pane.
Required
Clicking on an expansion control in the scope pane must not change the
placement of the selection cursor nor the view presented in the results
pane.
Figure 5-10
Expansion Controls
Chapter 5
151
Window Components
Scope Pane
Required
Users should be able to scroll the contents of the scope pane without
affecting the information displayed in the results pane.
This allows users to easily move within the display space and to use drag
and drop between different views of objects.
Recommended
Double-clicking on a item in the scope pane should cause information

related to that item to be presented in the results pane; this action
should also cause the item to be expanded if it had a [+] next to it or
collapsed if it had a [-] next to it.
Required
Single-clicking in the results pane on an object, task, information, or tool

icon must both cause the item to be selected as well as remove the
selection cursor appearance from the scope pane. A location cursor (for
example, black box or gray highlight) appears around the open item in
the scope pane.
Required
Double-clicking in the results pane on an icon for a container object

should cause the child view associated with that object to be presented.
The double-click action also causes a synchronized change in the scope
pane so that the object that was double-clicked on in the results pane is
shown 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 of
the tree list so the open item is visible. The open item in the scope pane
should not be selected; instead, the location cursor should be on the item
to indicate that it is open. User testing has shown that users do not
expect 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 be

selected without affecting the selection state of other items. The
CTRL-click should not change the view presented in the results pane. See
Selection Guidelines in Chapter 7 for more information on multiple
selection.
Required
Double-clicking on the icon for a leaf-level object (that is one that does
not have a child view) in the results pane causes the default action
associated with that object to be executed or an error message to be given
to the user.
Typically the default action associated with an object is the presentation
of the properties of the object.
152
Chapter 5
Window Components
Scope Pane
Menus in a Scope Pane
There are typically pop-up menus associated with items in the scope
pane. See Pop-Up Menus in this chapter for guidelines related to these
pop-up menu items.
Visual Cues in a Scope Pane
Scope panes with hierarchical presentations of objects and tasks contain
a lot of visual cues that help guide the user in their interactions with the
application. Examples of the visual cues discussed in this section can be
seen 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 items
should be represented by both a graphic and a label. The type of graphic
used should adhere to the following guidelines:
If the status of the represented object is normal, a 16x16 graphic that
depicts the object should be used.
For information on the design of graphical images see Symbol Design
Guidelines in Chapter 6 .
If the status of the represented object is abnormal, the object should
be represented by a symbol class shape that is colored to depict the
Chapter 5
153
Window Components
Scope Pane
abnormal status and the image for the object. The symbol class shape
should fit within a 20x20 square.
Abnormal status states in HP OpenView are critical, major, minor,
and warning. For more information on presentation of status
information see Use of Status Colors in Chapter 8 .
Required
Any currently-selected items in the scope pane should be marked by a

selection highlight (see figure on the left in Figure 5-11) or by a selection
check box (see figure on the right in Figure 5-11).
In a applications native to the UNIX or Windows NT operating
system, the selection highlight is one defined by the operating system.
In a JAVA application or applet, the selection indicator should be
defined 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 of
color (lightblue #ADDE86) surrounding the items label.
A radio button, if all items in the scope pane are mutually
exclusive.
A check box, if multiple selection of items is allowed.
Recommended
The position of the location cursor in the scope pane should be marked by
a 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 the
operating system.
In a JAVA applet or HTML application, the location cursor or open
indicator should be a black box that surrounds the name of the item
on which the location cursor is resting.
Recommended
The item in the scope pane that is currently open (the item whose
contents are displayed in the results pane) should adhere to all of the
following:
154
Chapter 5
Window Components
Scope Pane
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 navigation
tabs are provided in the interface.
It should be indicated by either:
A selection cursor, unless there has been a selection in the results
pane.
A location cursor, if there has been a selection in the selection
pane and the user has not navigated in the tree list with the
keyboard or keyboard- equivalent device.
Variations in the appearance of the icons to indicate the open object is
also allowed as a means of showing the open item. However, this type of
visual cue is not applicable to all types of icons (for example, servers,
services, computers, printers); therefore, it cannot be the only cue that is
provided 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
155
Window Components
Scope Pane
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 a

flat list or as sets of filters with category headings.
Recommended
If the scope pane presents filters, the material presented in the results
pane 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 filter
categories in the dialog box.
The filter categories in the dialog box should include the filter
categories presented in the scope pane.
Changes made to the filter categories in the dialog box should be
reflected 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 filters
have been set.
156
Chapter 5
Window Components
Scope Pane
Recommended
A single-click on the check box for a filter should cause the selection of
the filter to be turned on or off depending on its previous state. It should
also cause the items which match that filter to be displayed in the results
pane.
Control of the information display by selection of categories should take
effect immediately without the need for the user to use a push button to
apply the filters. Compliance with this guideline may depend on
application 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
157
Window Components
Results Pane
Results Pane
The results pane (or client area) is the area that is used for presenting
the primary information about managed objects and other application
functionality. Depending on the primary purpose of the application
window, 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 provide

meaningful views related to the object shown in the scope pane as open.
Recommended
In task presentation managers, the results pane should provide a wizard

or tabbed dialog for the task shown in the scope pane as open.
Recommended
In information presentation managers, the results pane should provide

the information associated with the open item in the scope pane.
158
Chapter 5
Window Components
Results Pane
Recommended
When a user first enters an applications window, the results pane should
not be empty. The results pane should show either:
Information relevant to the menu item, launcher entry, or selection
from 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 the
scope pane.
Example 1: If the user opened the window by double-clicking on an
alarm in an alarm browser, the window should present information
that is relevant to the alarm (for example, a view containing the
object that was the source of the alarm).
Example 2: If the user had previously had the window open and
showing the 12.1.5 subnet within the IP network hierarchy, the
window should open to that subnet.
Keyboard interaction in the results pane will need to vary depending on
the type of presentation format that is presented in the results pane. See
guidelines for keyboard navigation in see Presentation Formats for the
Results Pane."
Presentation Formats for the Results Pane

When managing the network and system environment different types of
tasks can benefit from different presentation formats. The types of
presentation formats recommended for HP OpenView applications
include:
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 viewing
or entering values).
Refer to Figure 5-14, Figure 5-16, and Figure 5-17 for examples of these
kinds of presentation formats.
Chapter 5
159
Window Components
Results Pane
Recommended
When managed objects are initially presented, they should be presented

in the presentation format that will most likely benefit the users tasks
the type of object that is selected and the current context.
For example:
If the context is concerned with the connectivity and status of
managed objects, a graphical format can accurately depict how the
objects are connected together in the management environment as
well as provide status by means of status colors.
If the context is concerned with configuration and change
management and a router is selected, a properties format can shows
the current configuration of the router and allow users make changes.
If the context is concerned with performance and the selected object is
a network, a chart format which shows a Pareto of the Top 10
Talkers contributing to network traffic can provide a summary of
important information.
If the object is a container that has no attributes of its own and users
would benefit from a summary of information on all objects within the
container, a tabular format can present objects as rows in the table
and information on the objects as columns (for example, hostname, IP
address, MAC address, and packets in).
Recommended
If it will benefit users, an application should provide different

presentation formats for the objects presented in a view.
Recommended
If different presentation formats are provided, users must be able to

change between different presentation formats using menu items listed
under the View menu (for example, Details, Icons, Large Icon, and Small
Icon) and toolbar buttons that represent the available presentation
formats.
Recommended
If multiple presentation formats are available, capabilities should be

provided 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 or
one based on the last format set by the user.
160
Chapter 5
Window Components
Results Pane
Graphical Presentation Formats

There are different types of graphical presentation formats. The most
common types are iconic and pictorial.
Iconic presentation formats provide views in which objects are
represented by icons and relationships between the objects are
represented by lines. Iconic views may show topology (as in a network
submap) or logical relationships (as in an organization chart). Iconic
views can simply show containment (as in a row/column layout in a Node
Submap). See an example of an iconic presentation format in Figure
5-14.
Figure 5-14
A View Showing an Iconic Presentation Format
Recommended
When an iconic presentation format is used, users should be able to

navigate to lower levels in the hierarchy by double-clicking on the icons.
Chapter 5
161
Window Components
Results Pane
Recommended
Users should be able to use the arrow keys to navigate among the objects
presented in an iconic presentation format:
Pressing the up arrow should move to the nearest icon above the
current location.
Pressing the down arrow should move to the nearest icon below the
current location.
Pressing the left arrow should move to the nearest icon to the left of
the current location.
Pressing the right arrow should move to the nearest icon to the right
of 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 being
managed. This format frequently lets users manipulate the managed
object through the direct manipulation of image components. For
example, dragging a object and dropping it on a port shown in a pictorial
format may reconfigure the port on the device to provide a connection to
the object.
162
Chapter 5
Window Components
Results Pane
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 of
the picture can be manipulated.
For example:
The appearance of the pointer can change when the pointer is over a
hotspot in the picture that can be manipulated.
An area of the picture can become highlighted when the pointer is
over a hotspot that can be manipulated.
Tool tips can be presented when the pointer is over a hotspot that can
be manipulated.
Tabular Presentation Format

A tabular presentation format provides a means for providing detailed
Chapter 5
163
Window Components
Results Pane
information on all of the objects within a view. Tables allow the display of
multiple pieces of information on multiple objects without cluttering the
display. Types of information that can be presented in a tabular format
are properties of the objects, important statistics, and multiple pieces of
static data.
When providing a tabular presentation format, refer to the guidelines in
this 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 present

the objects as rows and the information on these objects as columns in
the table.
This is the typical way in which information on objects is presented and
consistency will aid the user in locating desired information.
Recommended
When providing a tabular presentation format for object, adhere to all of

Provide important information that will benefit a user in his task.
When deciding what information to present, consider the context in
164
Chapter 5
Window Components
Results Pane
which the object is being presented and use this as a basis for
determining what information should be presented. In a network
context, properties like IP address, subnet mask, and the number and
state of network cards or ports will typically be important to users. In
a system context, important properties could include the operating
system version, CPU usage, amount of RAM, available RAM, disks
mounted, and disk space.
Do not simply repeat the information that is provided in a existing
chart or graphical format.
While it is beneficial to repeat some information available in an iconic
view (for example, status and label), users do not go to a tabular view
to get a repetition of the information they had in another format.
Information like the symbol type and class should not be given in a
tabular view.
Present only a subset of the properties associated with an object.
If the table presents all of the properties associated with the objects
in a view, the table will become cluttered and will require too much
horizontal navigation by the user.
Recommendation
If the view associated with a tabular format includes heterogeneous

types of objects, adhere to all of the following guidelines:
Try to choose properties for display that are common across the
various types of objects in the view.
If the properties displayed are not common to all objects, cells which
are 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 objects
are not very important as the connections are not actively managed.
Status of the connections are derived from the status of the interfaces
within the connected objects (for example, computers, bridges,
routers, and switches). Tabular presentation formats in these types of
network views should not contain the connections.
Recommended
The default sorting for a table in the tabular presentation format should
be alphabetical by object name or label.
Recommended
Allow users to set preferences for the information to be displayed in the
Chapter 5
165
Window Components
Results Pane
tabular view. Potential preferences that should be considered for user
manipulation 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 column
heading. This can aid users in finding information.)
Recommended
See Keyboard Navigation in Tables and Grids in Chapter 9 for

information on keyboard navigation within a tabular presentation
format.
Chart Presentation Formats

A chart presentation format provides a means of summarizing
information for a user. Because the chart is visual, the user can acquire
important information at a glance. Charts provide a good means for
displaying the health of managed objects, performance, and for showing
problems. They are not intended for presenting detailed information on a
large number of objects.
166
Chapter 5
Window Components
Results Pane
Figure 5-17
A View Showing a Chart Presentation Format
Recommended
When providing a chart presentation of a large number of managed

objects, do not attempt to present data on all of the objects in the chart.
Information presented in charts should only represent important objects
or objects with extreme conditions that users would want to know about.
For example, in a network view users will want to know about the
performance of routers or objects that have the most network traffic. In a
system view, users may want information on the systems that have the
lowest amount of RAM or disk space or that have the highest load on
their processing capacity.
Recommended
Allow users to set preferences for the type of information to be displayed

in a chart and for how many objects will be presented in the chart at a
given time (for example, top 5 objects, top 10 objects).
Form Presentation Format

A form presentation format, which is displayed in the results pane of the
primary window, overlaps in its functionality with property boxes,
Chapter 5
167
Window Components
Results Pane
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
to both object and task presentation managers. Use the following
guidelines to determine when to use a property box, property inspector,
or wizard as compared to a form format in the results pane of a
Figure 5-18
A View Showing a Form Presentation Format
Required
Form presentation formats are only applicable in windows that have a

scope pane.
Recommended
If a user has the results pane set to a presentation format other than the
form format and he requests the properties of an object via a menu or
toolbar button, these object properties should be presented in a
properties box instead of as a form in the main window area.
168
Chapter 5
Window Components
Results Pane
Recommended
Use a form presentation format in the results pane to present object

attributes if:
A user has selected an object in the scope pane, and the objects
properties are the relevant information associated with the selected
object.
(For example, a leaf-level object has no child view associated with it;
the only relevant view is the objects properties.)
The users primary task involves viewing or editing of object
properties.
The user may need to quickly go back and forth between the
properties for different objects.
The users task would benefit from being able to drag objects from the
scope 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 the
properties for different objects.
The tasks that an application is presenting do not allow drag and
drop onto the properties box.
The number of attributes or amount of information associated with
the object is large; the presentation of this information in a separate
window 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 not
presented in the scope pane.
The users primary task involves viewing or editing of object
properties.
Users may need to quickly go back and forth between the properties
for different objects.
Recommended
The guidelines for keyboard navigation within a form presentation

format should be identical to those for keyboard navigation within a
dialog box, see Chapter 9 , Dialog Boxes and Controls.
Chapter 5
169
Window Components
Navigation Tabs
Navigation Tabs
Navigation tabs are tabs that are presented at the bottom of the results
pane. Navigation tabs allow users the ability to quickly move back to a
previously 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, keep

accessible, and stay on top. Each state is indicated on the tab label in
the 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 on
its side, see Keep Accessible Tab in Figure 5-20 below.
170
Chapter 5
Window Components
Navigation Tabs
In the stay on top state, the tab has a picture of the pin stuck
directly into the label, see Stay on Top Tab in Figure 5-20.
Figure 5-20
Tab States and Appearance
Required
If navigation tabs are provided, the tab that is currently on top or active
should appear in white, while any nonactive tabs appear in the same
color as the background for dialog boxes and scroll bars.
Recommended
When the user clicks on a navigation tab with the menu button on the
pointing device, a pop-up menu containing the following menu items
should be presented.
Reuse Tab
This menu item causes the stick pin in the tab to be

removed. If the tab is for the top view, the view and the
tab will remain until the user navigates to a new view.
If the tab is for one of the lower-level views, the tab will
disappear, but there will be no change in the current
view.
Keep Accessible This menu item causes the stick pin in the tab to be in
the pinned state (sideways pin). When the pin is in this
state, the tab for the view is maintained when the user
navigates to a new view. A new tab is created for
presenting the new view.
Keep Tab on Top This menu item is optional. When available, it causes
the pin on the tab to have a stuck in appearance. Until
the state of the tab is changed, it always remains on
top. This prevents the results pane from changing
when the user navigates in the scope pane.
Display in New Window This menu item causes the view associated
with the tab to be presented in a new window. If the
presentation manager supports child windows, the tab
is removed and a child window containing only the
identified view is presented. If the presentation
manager supports copied windows, a new duplicate
window is presented with view associated with the tab
set as the active view.
Chapter 5
171
Window Components
Navigation Tabs
Close Tab
This menu item causes the tab to be removed; and, if

the tab is associated with the active view, the view will
change to the view associated with the tab previously
viewed prior to this tab.
Optional
When possible, have any menu items associated with the navigation tabs
available from the background pop-up menu for the view.
Recommended
Some of the menu items associated with the navigation tabs should be
presented as toolbar buttons in the toolbar:
Keep Accessible A toolbar button should be presented for changing the
pin state of the active tab between the Keep Accessible
and Reuse Tab states. This button should be a toggle
button.
Display in New Window This should be a regular toolbar button that
uses the graphic for display in new window.
Close
Optional
This should be a regular toolbar button that uses the

graphic for closing a view or a window.
If an application supports the three tab states of keep accessible, reuse

tab and stay on top, the toolbar button for Keep Accessible should
toggle between the three states and change images when necessary for
the keep accessible (a pin on its side) and the stay on top (a stuck-in
pin) states. Specifically, this button should show:
A pushed-out appearance with the image of a pin on its side when the
state of the tab is reusable.
A pushed-in appearance with an image of a pin on its side when the
state of the tab is keep accessible.
A pushed-in appearance with an image of a stuck-in pin when the
state of the tab is stay on top.
Each click on the button should toggle between the three states in this
sequence: 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 scope
pane should result in a nonactive tab (that is a tab that is overlaid by the
tab that is stuck) which contains the view associated with the selected
item.
172
Chapter 5
Window Components
Navigation Tabs
Recommended
If a tab is in the stay on top state, the selection of another navigation

tab should override this state, and the view associated with the
newly-selected tab would be presented. The state of the tab previously
marked as stay on top would become keep accessible.
Users will not want to change the tab state before they are allowed to
navigate 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 visited
should be presented as the active view in the parent window. Also, if the
tab is the last remaining navigation tab, the application should do one of
the 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 parent

window, the contents of the child window should be presented as the
active view in the current window, and its tab state (empty, pinned, or
stuck) should be the same as it was when the user took the action to
present the tab in a child window.
This behavior should be true regardless of the state of other tabs in the
parent window. If there was an existing tab in the parent window that
was 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 be
presented as the active view in the parent window.
If the tab is the last remaining navigation tab, the application should
do one of the following:
Allow the user to close the tab and then present him with a new
tab and its associated view (for example, last view visited, view
hierarchically above the current view).
Gray the menu items and toolbar buttons for Close so that the
user will not be able to take this action.
Chapter 5
173
Window Components
Navigation Tabs
Present the user with a confirmation dialog to confirm whether
the user wants to exit the application.
Optional
Applications can predefine navigation tabs as keep accessible for the

views which they believe users will want to access quickly. Any of the
following methods can be used:
The tab for a view can set to the keep accessible state when the
presentation manager is first accessed. This will cause the tab to be
presented and available when the presentation manager is first
brought 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 the
presentation 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 lost
or access to information to be lost.
Required
If an application does predefine pinned tabs for specific views, users

must be able to modify these settings so that the tab is reusable and
the 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 the
task.
There are system activities that are still in progress which will affect
the successful completion of the task, even though all user actions are
complete.
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 by
selecting an item in the scope pane.
The tab should be released and should disappear when the user
navigates to a new view by selecting one of the keep accessible
navigation tabs.
Recommended
When there has been a change in status of the task or process that is
174
Chapter 5
Window Components
Navigation Tabs
going on in a view associated with a keep accessible navigation tab that
is not currently active, a visual cue should be presented on the left side of
the navigation tab. Recommended visual cues include:
A check mark to indicate that the user should check the view
contained on the tab (See Figure 5-21)
An exclamation mark to indicate that there has been an error. The

color of the exclamation mark should correspond to the level of
serverity of the error (see Use of Status Colors in Chapter 8 for
more 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 view
associated with the navigation tab.
For example, if the view associated with the tab is Segment 2, then the
tab should also contain the label Segment 2. Generic names should not
be 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 in

the tab, tool tips should be provided to give the full name of the view
when the pointer is over the navigation tab.
Recommended
Since the number of available tabs may be greater than the available
display space, a mechanism for scrolling navigation tabs should be
provided.
Required
All navigation tabs that have been marked as keep accessible must be
maintained regardless of context.
If there are multiple contexts in a presentation manager, users will want
to have quick access to views in different contexts. Users will not want to
change contexts to access the desired navigation tab. All navigation tabs
that have been marked as keep accessible should be added to the set of
available navigation tabs.
Required
In an object presentation manager, navigation by navigation tabs must

not affect the selection list.
Chapter 5
175
Window Components
Navigation Tabs
This is different from navigating by selecting items in the scope pane. If
the user navigates using the scope pane, the items that are selected in
the scope pane will clear any selections in the results pane and become
the new selection.
Required
Using navigation tabs to change views should cause the contents of the
scope pane to change to match the view associated with the navigation
tab.
When the user selects a navigation tab the object associated with view in
the navigation tab should be shown as the open object in the scope pane.
A location cursor, not the selection highlight, should be used to indicate
which object is open.
Required
In a task presentation manager, navigating via navigation tabs must not

start a new task nor affect the status of other tasks that are currently in
progress.
176
Chapter 5
Window Components
Status Bar
Status Bar
The status bar is an optional area that should appear at the bottom of a
window. This bar provides users with state information about the
application 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 of

information should be presented in visually-separated areas in the
status bar. (See Figure 5-22.)
Recommended
The status information in the status bar should be applicable to the

active window and view.
Recommended
If context sensitive active help is provided on menu items, the help text
should be displayed in the status bar.
Chapter 5
177
Window Components
Status Bar
178
Chapter 5
Objects and Symbols
179
Objects and Symbols
This chapter presents information on objects and the symbols that are
used to represent them. It also includes information on the symbols used
to represent actions in the toolbars and in executable symbols. The
chapter 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 and
actions.
180
Chapter 6
Objects and Symbols

Iconic Views
Iconic Views
An iconic view is a collection of symbols that are displayed in a single
results pane. An HP OpenView Network Node Manager (NNM) submap
is an example of an iconic view. Each view displays a perspective of the
objects and information being represented about the objects (for
example, internet, WAN, bus, service view). Sets of views are typically
organized in a hierarchical fashion.
When to Represent Objects with Symbols

HP OpenView does not require that all of the objects be represented by
symbols. However, it is likely that most objects will be represented by
one or more symbols in iconic views. The following guidelines should be
followed in assigning symbols to represent objects in iconic views.
Recommended
Symbols should be used to represent managed objects in iconic views if

one or more of the following are true:
A user wants to monitor the status of the objects. Graphical symbols
can serve as visual cues about the condition of managed objects (for
example, the wear status of backup media can be indicated by red
coloring on the symbol, or a network connection being down can be
indicated by the red status color line connecting two objects, a server
being down can be indicated by the status color of the symbol class
shape surrounding the graphic of the server).
A user wants to act on an object (for example, configure or obtain data
about it), using functionality presented in the windows menus.
A user wants to act on objects using drag-and-drop (for example, back
up a file by dragging and dropping it onto a tape device).
A user wants to see the relationships between managed objects. The
use of connection symbols and different layout algorithms in iconic
views allows him to see these relationships.
Levels of Symbol Creation

Recommended
If the objects to be represented are part of an existing management

hierarchy that provides status information, create the symbols at the
Chapter 6
181
Objects and Symbols

Iconic Views
lowest possible level in the management hierarchy. This minimizes
application conflicts in status setting of higher-level symbols and
provides the greatest level of flexibility and control for users.
Representation of Container Objects
Container objects are objects that contain other objects. The containment
relationship can be either logical or physical. Examples of container
objects include networks, computers, processes, domains, services,
correlations, and media groups.
Required
In a hierarchy in the scope pane of a window, container objects that can

be expanded to show their contents in the scope pane must be
represented by both a graphic and an expansion control that indicates
the symbol can be expanded.
Required
In a hierarchy in the scope pane of a window, container objects that only

show their contents in the results pane and cannot be expanded in the
scope pane must either:
Be represented by a graphic without an expansion control.
If performance will be impacted by the processing required to
determine which container objects can be expanded in the scope pane,
the graphic can initially be presented with an expansion control but
the expansion control must be removed as soon as the application can
determine 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 objects

should be represented by compound (explodable) symbols.
Computer systems are fundamental container objects in many
management hierarchies. Resources manipulated during network,
systems, and service management are contained within or connected to a
computer. As a result, many applications provide management
hierarchies that include a computer view, or they integrate into an
existing management hierarchy by adding symbols to views directly
182
Chapter 6
Objects and Symbols

Iconic Views
under computer symbols. Because of the large number of applications
integrating at this level, it is beneficial for the user if applications are
consistent 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, storage
devices, users, and file systems).
Recommended
The symbols for object classes in computer or node views should be

compound symbols that lead to lower-level views of the individual
instances of the objects of that class (for example, floppy device, hard
drive, CD device), or to finer-grained classifications of objects in that
class.
Recommended
If some views in a given management hierarchy are not meaningful for

that hierarchy, or if the view only contains one symbol that is simply a
container for other symbols, then consideration should be given to
removing the view from the hierarchy and moving up the lower level
items.
Recommended
A user should have some way of configuring the number of levels

presented in a given management hierarchy.
Example 6-1
Example:
Users are provided with a dialog box to choose the levels to be presented
in the hierarchy. The dialog box allows the user to choose the levels to be
combined and those to be eliminated.
Recommended
Applications should ensure that all object views that they create can be
accessed through the higher level views in the scope pane or through a
change in the setting of the context tab.
Although an application may not be interested in objects at all levels in
the hierarchy, it should create sufficient higher-level symbols to provide
users with appropriate contextual cues and navigation aids. In general,
it is not a good idea to present managed objects in views that do not have
a parent object or which do not allow navigation back to the root level for
the hierarchy.
Representation of Leaf-Level Objects
Leaf-level objects are objects that do not naturally contain other objects.
They may be associated with other objects and can have attributes.
Chapter 6
183
Objects and Symbols

Iconic Views
Examples of leaf-level objects include individual network cards, files, and
individual event correlation elements.
Recommended
If the hierarchy is small enough so that there will not be a negative

impact on performance, it is recommended that leaf-level objects be
presented in the hierarchy in the scope pane of the window.
Required
If a leaf-level object is presented in the scope pane hierarchy, a graphic

without an expansion control must be used.
Recommended
If the leaf-level object is selected in the scope pane, it should result in the
presentation of a form or table view that displays the attributes or
properties of that object. Menu and toolbar items associated with
accessing a iconic view should be grayed.
Iconic views that contain explodable symbols imply the ability to
navigate to a lower-level item. Users should not be presented with these
types 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 objects

should be represented by symbols similar to those for container objects.
Double-clicking on these symbols should lead to a form or table view that
displays 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 application

can integrate, and user tasks will benefit from having the new objects
presented in the context of existing objects, the application should create
its symbols at the appropriate locations within the existing hierarchy.
Example 6-2
Example:
An application for managing the configuration and maintenance of
Networked File Systems (NFS) is being developed. There is an existing
systems management hierarchy defined by another application that
supports application integration. For systems that have NFS configured,
two symbols are added in the computer view of the management
hierarchy. One symbol is for imported file systems and the other is for
exported file systems. When the user opens up the symbol for imported
file systems, they see individual icons representing each of the file
systems that have been imported.
184
Chapter 6
Objects and Symbols

Iconic Views
Representing All Objects in the Hierarchy
Stand-alone applications or applications that are unique to a
management area may need to create representations for all objects in
the hierarchy that they are interested in presenting to users.
Example 6-3
Example:
In the HP OpenView Event Correlation System (ECS) application, the
hierarchy of objects is based on the correlation that a user is creating to
do event correlation. The levels in the hierarchy are based on the
compound correlation elements that are developed as part of the
correlation. The contents at any level are based on the correlation
elements that the user has added in building the correlation.
Recommended
If the objects to be represented do not fit into an existing hierarchy, or if

user tasks will benefit from having objects in a separate hierarchy, the
application should create a new management hierarchy.
The creation of a complete management hierarchy in a presentation
manager requires that a context be created for the hierarchy. This
hierarchy should provide the user with cues as to the types of objects
being represented and the means to navigate within the hierarchy.
When integrating into NNM, placing a symbol in the root submap
automatically creates an entry in the context list. The symbol in the root
submap should represent the top level of the hierarchy.
Example 6-4
Example:
In an application for managing processes, it does not make sense to
present processes inside an existing network hierarchy. As a result, the
application will need to develop a complete hierarchy for processes,
which would include the following: groupings of processes, individual
processes within the groupings, steps within each process, and actions
within steps.
Representing Objects Using a Combined Approach
Recommended
If there is an existing object hierarchy that meets a portion of the

applications needs, or if user tasks will benefit from having objects in a
separate hierarchy as well as in an existing hierarchy, the application
should use a combination of these approaches.
Chapter 6
185
Objects and Symbols

Iconic Views
Example 6-5
Example:
An application that provides object discovery and status information for
an X.25 network could both integrate into an existing IP network
hierarchy of NNM and also provide users with a separate hierarchy that
only shows X.25 networking.
186
Chapter 6
Objects and Symbols

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

Root Submap
X.25
X.25 Net
IP Internet
X.25 Network
IP Internet
X.25
Node A
IP Internet
Node 3
IP Internet
Node B
IP Internet
Segment
Node 3
LAN
X.25
Segment
X.25
Node 1
Chapter 6
Node 2
Node 3
187
Objects and Symbols

Iconic Views
Container Objects: Networks At the highest level in the hierarchy is
the root submap, where the parent object for IP submaps would likely be
IP Internet. Users generally do not expect to navigate to an X.25 network
via IP networks and segments. Therefore, the X.25 application would
want to provide a different route for accessing the submap that
contained the X.25 nodes. The X.25 application must create a new X.25
network symbol to place in the root submap.
Note that submaps are tied to parent objects. Although only one submap
can be attached to an object, different symbols can explode into the same
submap, since different symbols can represent the same object.
Container Objects: Computers At the intermediate level in this
hierarchy 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 cards
installed and therefore would not be discovered or created by the IP
map application. They would need to be created by the X.25
application, as is the case of the Node B object in Figure 6-1. The
computer is a container object that both provides contextual
information for the user and contains the interface to the X.25
network.
Even though the X.25 application creates the computer, this
application should not attempt to exclusively control computer
objects. The child submaps of the computer objects should be created
as shared submaps to allow for the addition of computer components
by 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 the
database due to their creation by the IP application. If a shared child
submap exists for the computers, the X.25 application should add its
components to it, as it has done in the Node 3 submap. If there is no
child submap, the X.25 application may create a shared submap and
then add its component objects, as is the case in the Node B
submap.
Since the Node C object, which supports X.25, already exists on the
map, the X.25 application uses that existing object. It adds another
symbol representing the object to its own X.25 network submap.
188
Chapter 6
Objects and Symbols

Iconic Views
Thus, the Node 3 symbol and the Node C symbol both represent the
same object and explode into the same submap (Node 3 submap).
Leaf Level Object: X.25 Interface Cards At the lowest level in this
hierarchy are the X.25 interface cards. The interface cards should be
viewed as the base-level primary objects for the application. Since these
objects do not readily break down into lower-level components, the
application can assume control over the object and symbols, such as in
setting status. To create these objects, the X.25 application needs to
create the container objects (if they do not already exist) that contain the
interface cards.
Special Types of Objects and Views

Representing Multiple Location (Linked) Objects
Some managed objects are homed in a single location but, for ease of use,
need to be presented at multiple locations within a management
hierarchy.
Example 6-6
Example:
User accounts defined by NIS are actually set up on the master NIS
server system. To simplify the management of individual systems, there
may need to be symbols for NIS users and UNIX users under each
system. The user login information for NIS is actually homed on the NIS
server, not on the individual client systems.
Users can do some management tasks when working with symbols for
objects outside of the objects home context. For other management tasks,
it will be better for users to quickly access the home location for these
objects.
Recommended
Objects that are presented out of their home context should be presented
with a symbol that indicates they are references or links to the actual
object. This symbol also indicates that the user can select the object and
view it within its home location. See Figure 6-3, later in this chapter.
Recommended
To allow access to the home location for multiple location objects, a Go to

Home menu item should be provided under the pull-down menus and in
the pop-up menu for the symbol.
When the user accesses this menu item with a multiple location or linked
object, the scope pane should change to have a location cursor on the
Chapter 6
189
Objects and Symbols

Iconic Views
home location for the linked object and the results pane should show the
linked object as selected. This can be done within the current scope and
results 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 a
given component in the hierarchy, should not be shown as part of the
hierarchy. Doing so can create recursion in the navigation. This recursion
can cause the user to get lost when trying to navigate to accomplish his
tasks.
Example 6-7
Example:
The following hierarchy has recursion:
domain->system->system components->users->tom->group
memberships->lab->members of lab-> tom
The recursion is based on the fact that tom is actually a leaf-level object
and his group membership is an attribute or property of tom, not an
object contained within tom. It would be best for the user if the object tom
were treated as a leaf- level object.
Recommended
Related objects should be presented in a selectable format that indicates

that they are homed in a different location, that is they should be
represented by both a label and a symbol with a link indicator.
Recommended
Access to the hierarchy associated with related objects should be

provided within the context of their home location in the management
hierarchy using the Go to Home menu item or a push button.
Recommended
The Go to Home menu item should work with related objects within
properties boxes that are presented in the results pane of the window. A
Go to Home push button for accessing the home hierarchy of related
objects should be provided in properties boxes presented outside of the
results pane. For more information see Representing Multiple Location
(Linked) Objects above.
190
Chapter 6
Objects and Symbols

Iconic Views
Figure 6-3
Item in a Property Box with a Link Symbol
Figure 6-4
Split Window Showing Objects at Linked Location
Chapter 6
191
Objects and Symbols

Iconic Views
Independent Iconic Views
Independent views (that is orphan views) are those which do not have a
parent symbol or entry in the context list. As a result, these views cannot
be accessed by traversing the hierarchy of objects presented in the scope
pane.
Recommended
Use independent views only for special-purpose capabilities that are not
intended to represent managed objects and their relationships.
Recommended
If independent views are provided, users should be given easy

mechanisms for accessing these views (for example, a menu item to
access the view).
Layout Algorithms for Iconic Views

A variety of layout algorithms can be used for iconic views of objects. The
layout algorithm that is chosen for a given view, should take the
following guidelines into account.
Recommended
Choose a layout for the view which will match the users task needs given
the context and type of view.
Recommended
If the layout of the objects in the real world affects a users management
tasks, choose a layout algorithm and a sequencing of object symbols that
matches the real world.
Example 6-8
Example:
When creating a view which will display systems on a token ring, use the
ring layout. Sequence the systems in accordance with their sequence in
the token ring. If network elements are connected with a bus, the view
should have a bus layout.
Recommended
If a users task involves developing a flow of information through

different steps or elements, use a point-to-point layout.
Example 6-9
Example:
A point-to-point layout would be used in displaying the flow of events
through different event correlation elements or in defining the flow of
steps in a process.
192
Chapter 6
Objects and Symbols

Iconic Views
Recommended
If a users task involves working with objects that are ordered in a

hierarchy or for which there is some type of inheritance from other
objects, use a tree layout.
Recommended
When using a tree layout for inheritance, objects with more general
information that is carried over to other objects should be presented at
the top of the tree. Objects which are more specific or which may
overwrite inherited data should be presented lower down in the tree.
Recommended
If a users task involves a logical ordering of objects and their real world
position is not important, choose a layout algorithm that will match the
way in which the user thinks about the objects.
A ring layout should be used when the connectivity between objects to
be represented is circular.
A star layout should be used only when a central object is in a
relationship with multiple peripheral objects.
Recommended
The row/column layout should only be used when the structural

relationship between the objects represented in the view is not important
to a users task and sequencing of the items will benefit task
performance. This layout may also be used if there are multiple different
relationships between the elements to be represented in the view.
Recommended
When using a row/column layout, sequence the objects to allow a user to

quickly locate specific objects when doing his tasks. One or more of the
following 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 based
on a meaningful variable (for example, name, time of creation/change,
performance).
Example 6-10
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 Solaris
systems in row 4. Within each row systems are alphabetically ordered
based on their hostnames.
Recommended
When a row/column layout is used, consider allowing the user the ability
Chapter 6
193
Objects and Symbols

Iconic Views
to resequence the objects based on a variety of meaningful variables (for
example, name, address, time of creation/change, performance).
194
Chapter 6
Objects and Symbols

Guidelines for Assigning Symbols to Objects

Symbols and Symbol Types
When a symbol is a graphical representation of a managed object, it is a
presentation element that has characteristics such as a label, status, and
symbol type.
The symbol type is the classification scheme that helps users identify the
object being represented by a symbol. The symbol type should reflect the
type 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 as
network, computer, or T1 carrier. For object symbols, class is
represented by the outside shape of the symbol. For connection
symbols, class is designated by the overlay graphic for the connection
(one exception are connection symbols in the generic class which do
not have overlay graphics).
The symbol subclass further specifies the symbol, such as the
computer subclass PC or the T carrier connection subclass T1. Icon
symbol subclasses are graphically depicted inside the outer shape.
Connection symbol subclasses can be specified by the line style or the
thickness of the connection symbol, or by a combination of these two
attributes.
Examples of symbols and symbol types are shown below:
Figure 6-5
Symbol Class and Subclass for an Object
Chapter 6
195
Objects and Symbols

Figure 6-6
Symbol Class and Subclass for a Connection
Assigning Symbols to Objects

HP OpenView provides a large variety of symbol classes and subclasses
which an application can use to present managed objects.
Use the following guidelines when assigning symbols to objects and
actions.
Required
Choose symbol classes for objects that represent the type of object and its
role in the application view. See Table 6-2, Existing Symbol Class
Shapes, in the next section of this chapter.
Required
Choose the symbol class and subclass that best depict the role that an
object is playing given the context in which the symbol will be displayed.
Example 6-11
Example:
In a network hierarchy, a computer should be presented by a gateway
symbol if the computer is a gateway in the network that is being
displayed. But in a system management hierarchy, this same computer
would be better represented by the appropriate computer class symbol.
Recommended
Chose the symbol class and subclass for an object that will provide the
user with the most specific information available about the object.
Example 6-12
Example:
If the object is a computer and the application knows it is a PC with a
Windows NT operating system, use the symbol for the Windows NT
subclass, not the generic PC symbol.
Required
Do not use existing HP OpenView graphics to represent objects other

than those that are implied in the name of the symbol as it appears in
the Display Legend or Add Object dialog box.
196
Chapter 6
Objects and Symbols

Example 6-13
Example:
Do not use the symbol for the TestMeasure: Analyzer to represent a
message-browsing capability that is presented via an executable symbol.
Required
Some symbol types are in the process of being phased out in HP

OpenView in order to provide more specific symbol classes and
subclasses. Such types should not be used by an application. See the
following table:
Table 6-1
Obsolete Symbol Types and Their Replacements

Do not use this Symbol Type
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
Assigning Symbols to Connections and Relationships

When assigning symbols to connections, the chosen symbol should be
representative of the type of connection or relationship and information
about the connection or relationship that is intended to be communicated
to the user.
Required
If an application does not differentiate between different types of

connections for management purposes, represent all connections by the
default connection symbol type (that is, a single, pixel-wide, solid line).
Required
If an application uses multiple, generic symbol subclasses to represent

different types of connections or relationships, assign the most
distinguishable connection symbols to those connections or relationships
which are the most different.
Chapter 6
197
Objects and Symbols

Recommended
When assigning connection symbols to connections or relationships:

The overlay symbol on the line should be related to the class or
category of connection or relationship that is being represented.
The line style should be semantically associated with the specific
characteristics of the connection or relationship.
Line thickness should be semantically associated with the capacity or
bandwidth of a connection or with the strength of a relationship.
Example 6-14
Examples:
If connection symbols are used to represent reporting relationships, a
dotted line is used to represent a loose reporting relationship and a
solid line for a more definitive reporting relationship.
Higher bandwidth connections would be represented by wide
connection symbols and lower bandwidth connections would be
represented by narrow connection symbols.
Recommended
If an application will provide users with information on the amount of

the available capacity that is used within a given connection, the
guidelines for Partially Filled Connection Symbols in Chapter 8 should
be followed.
Assigning Symbols to Actions

Action symbols are symbols that represent actions a user can take.
Action symbols are used in toolbar buttons and in executable symbols
that appear in the results pane.
Recommended
If action symbols are to be used for accessing functionality via executable

symbols in the results pane, these action symbols should be represented
as members of the Software Utilities class or appear as transparent
symbols.
Recommended
If an action provides functionality for which a subclass graphic has

already been defined, the existing graphic should be used for
representing the action.
Most symbols for actions are found in the Software Utilities class. Other
symbols for actions are found in the toolbar of HP OpenView
applications.
198
Chapter 6
Objects and Symbols

Required
Existing HP OpenView graphics for actions should be used only to

represent the functionality for which the graphic was defined. See Table
6-4, Visual Cues Used in Existing Graphics, for a list of different
graphical cues and how they are to be used.
Chapter 6
199
Objects and Symbols

Symbol Design Guidelines

When presenting a new object in an HP OpenView application, first
determine if there is an existing symbol type (class and subclass) that is
appropriate for representing the object. Consider both the visual aspect
and the semantic aspect when making this determination. Only design
new symbol classes and graphics if none of the existing classes and
graphics match the characteristics of the object, action, or connection
that is to be represented.
If new symbols are created for an HP OpenView application, the
guidelines in this section should be followed.
Symbol Classes
If new symbol classes need to be developed, they should not overlap with
the existing HP OpenView symbol classes. All symbol classes should be
mutually exclusive. The following section provides information on
existing symbol classes as well as guidelines for creating new symbol
classes.
Using Existing Symbol Classes
A variety of symbol classes have been developed for HP OpenView and
are shown in Table 6-2. If possible, choose from among these classes and
background class shapes when developing your application. Note that
Table 6-2 shows just the outside class shapes, even though the tables
descriptions also discuss the internal graphics that are appropriate for
each shape.
Recommended
If there is an existing symbol class that is appropriate for an object, use

that symbol class. New symbol classes should be created only as needed.
See guidelines above in Assigning Symbols to Objects."
200
Chapter 6
Objects and Symbols

NOTE
If the application is integrating into NNM, additional capabilities can be

added in the symbol registration file for the symbol that will be used to
represent the object.
Table 6-2
Existing Symbol Class Shapes
Symbol Class
Name
Class
Graphic
Symbol Class/
Subclass Description
Application
A software object which is used by a system user to

accomplish different tasks. The internal graphic in this
class identifies a general type of application or the
specific application itself (for example, word processing,
business accounting, Lotus 123, Microsoft Word).
Cards
A card or interface that may be contained within a

computer or network element. The internal graphic
identifies the specific type of card or interface (for
example, an IP network card or a graphics accelerator).
Client
A managed object that is receiving a service from another

managed object. The internal graphic identifies the type
of service that the client is receiving (for example, a
backup client or an NFS client).
Computer
Computer systems that are not playing a special role in

the management context. Typically, the internal graphic
indicates the type of computer vendor and/or the type of
operating system on the computer (for example, HP-UX,
SUN, Windows NT).
Connector
Network elements that act to connect or route information

from one area to another in the network. Typically, the
internal graphic indicates the type of connector (for
example, a frame relay switch, gateway, or bridge).
Chapter 6
201
Objects and Symbols

Table 6-2
Symbol Class
Name
Class
Graphic
Symbol Class/
Device
Input, output, and storage devices found in a network and

system environment. The internal graphic indicates the
specific type of I/O or storage device (for example, a fax,
printer, plotter, audio, monitor, mouse, keyboard, or disk
drive).
Domain
Sets of objects that have a logical connection between the

objects (for example, communication protocol,
management software, management responsibilities). The
internal graphic indicates the basis for combining the
objects into the domain or the type of domain (for
example, a collection station, a Windows NT domain, or a
managed node group).
Location
Locations or sites in which managed objects physically

reside. This class of symbols provides a higher-level
classification for grouping objects based on their
geographical or physical location. The internal graphic
indicates notable aspects about the location in the
physical world (for example Australia, state, city, site, or
room).
Logo
Executable functionality, when the desire is to represent

the vendor associated with the executable symbol.The
internal graphic indicates the specific vendor (for
example, HP OpenView, IBM).
Media
Media that may be found in the network and system

environment. The internal graphic indicates 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 the type of
protocol and/or layout associated with the network (for
example, IP, IPX, bus layout, or star layout).
202
Chapter 6
Objects and Symbols

Table 6-2
Symbol Class
Name
Class
Graphic
Symbol Class/
Network Device
Miscellaneous devices in the network. This category

should only be used for network devices that do not
meaningfully fit into another object class. The internal
graphic indicates the specific type of device (for example,
an Add Drop Multiplexor).
Server
Managed object that is providing a service to one or more

managed objects. The internal graphic identifies the type
of service that the server is providing (for example, a
backup client or an NFS client).
Service
Service that is being provided to users or to other

managed objects. The internal graphic identifies the type
of service (for example, backups, printer spooling, and
domain name service).
Software
Software object that is a configurable parameter of an

application or operating system, or which is provided
through the operating system. The internal graphic
identifies the type of object or parameter (for example, a
user group, message group, file system, file, driver, or
process).
Software Utilities
Executable functionality, when the desire is to represent

the type of functionality that will be provided to the user
when the symbol is activated. The internal graphic
indicates the type of functionality or the type of results
that will be provided (for example, an event browser, find
route, or a graph).
Test and Measurement
Intended for representation of objects that are used for

test and measurement. The internal graphic indicates the
specific type of test and measurement object (for
example, a LAN analyzer).
Chapter 6
203
Objects and Symbols

Table 6-2
Symbol Class
Name
Class
Graphic
Transceiver
Symbol Class/
Intended for representation of objects that receive and/or
transmit information. The internal graphic indicates the
specific type of object (for example, a phone, modem,
satellite, or microwave station).
Graphical Cues for Symbol Classes

The following cues have been defined for object classes in HP OpenView
applications and should be used as part of the graphics for the indicated
object classes:
Table 6-3
Images
Internal Graphics Cues

Cues to add to Graphics for
the Object and Connection Classes Listed
Class = Cards class
Cue = Small card in the upper left portion of the pixmap
Class = Client class

Cue = Single gray arrow pointing downward from the top right corner
of the icon
Class = Server class
Cue = Three lines pointing upward to the top right corner of the icon
Class = Service class

Cue = Multiple objects representing the specific type of service
204
Chapter 6
Objects and Symbols

Table 6-3
Images
Internal Graphics Cues

Cues to add to Graphics for
the Object and Connection Classes Listed
Class = Fiber Connection class
Cue = Circle with two 45 degree arrows
Class = TCarrier Connection class

Cue = Two triangles touching at their apex
Creating New Class Shapes for Objects

Required
New classes of icon symbols must have a unique outside shape that is
different from the outside shapes used in existing classes. A distinctive
outside shape is required for all new symbol classes. Refer back to Figure
6-2, X.25 Application Using a Combined Approach, 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 of
object that he is working with and a means of displaying status
information to him.
Recommended
If a new symbol class that is closely related to an exiting class needs to be

created, the new class should both:
Contain a discernible cue that helps users to relate its members to
the existing class.
Contain cues that allow the user to distinguish the new class from the
existing class.
Because icon symbols are sometimes used without their background
shapes, it is a good idea to provide visual cues in the graphic that
indicate the class of the object. See Graphical Cues for Symbol Classes
for more information.
Example 6-15
Example:
The client class is closely related to the server class. The two classes have
similar outside shapes. Members of the client class have a single inward
Chapter 6
205
Objects and Symbols

pointing arrow in the right corner while members of the server class
have three outward pointing arrows in the right corner.
New Connection Symbol Classes
Support for different connection symbol classes is provided for
applications integrating into HP OpenView Network Node Manager on
HP-UX, Solaris, and Windows NT.
Recommended
Follow the connection symbol guidelines in Assigning Symbols to

Connections and Relationships."
Required
New connection symbol classes should be created only by applications in

which the management of the connection or relationship is important.
Applications that are primarily concerned about the management of
network or system elements which happen to be connected or related
should use the generic symbol class connection to represent their
relationships and connections.
Required
Do not define a symbol class with a visual appearance that would include
existing members of other classes. Before a new connection symbol class
is defined, information should be obtained on existing, registered
connection symbol classes and subclasses; doing so will ensure that the
new symbol class being defined does not conflict with any
already-defined symbol classes and subclasses.
The overlay graphic is the visual cue to be used for identifying different
connection symbol classes. An example of an overlay graphic on top of a
connection 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 can

be readily discriminated from icon symbols. They should not require
change when they are localized for use in other countries.
Recommended
The size of an overlay graphic should be minimized to reduce clutter. The

sizes for the overlay graphic must be 11, 13, 17, 21, 25, or 29 pixels.
206
Chapter 6
Objects and Symbols

Recommended
When an overlay graphic is defined via a color graphic, the colors used in
the graphic must minimize the use of color associated with overlay
graphics. Overlay graphics should consist of no more than two colors. It
is recommended that most overlay graphics be black and white.
Recommended
If a new connection symbol class is created that is an extension of an

existing, closely-related class, the new class should have visual
characteristics that not only help users to relate the two classes to one
another, but also to distinguish the new class from the existing class.
Example 6-16
Example:
Two connection lines have the same line style, but the overlay graphic is
different and this visual cue indicates to the user that they represent
different types of connection symbols.
Symbol Subclasses (Graphics)

Generally the graphics used in HP OpenView are drawn from the
following 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 should
be consistent with the existing HP OpenView symbol graphics. The
following section provides information on existing symbol subclasses or
graphics as well as guidelines for creating new graphics.
Using Existing Symbol Subclasses (Graphics)
A variety of symbol subclasses or graphics have been developed for HP
OpenView. Many of these graphics make use of identifiable visual cues
that are intended to convey specific concepts to users. These visual cues
provide a visual language for the user. Consistent use of these visual
cues in accord with the visual language will make it easier for users to
recognize 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 the

characteristics needed to represent an object, define a new symbol
subclass for the object but use the existing symbol class. For more
Chapter 6
207
Objects and Symbols

information see Guidelines for Assigning Symbols to Objects and
Using Existing Symbol Classes."
Required
If an toolbar button or executable symbol provides functionality for

which a graphic has already been defined, the existing graphic should be
used instead of creating a new graphic.
Required
Existing HP OpenView graphics should be used only to represent the

concepts for which the graphic was designed.
Table 6-4
Visual Cues Used in Existing Graphics

Predefined Visual Cues
Description
Adding items to a log file: for symbols that
represent the logging of different types of
information
Arrow pointing upward: for symbols that

include the concept accessing the parent
object
Arrow side ways and up: for symbols that

include the concept moving up a level in the
hierarchy
Book: for symbols that include the concept

of a browser.
Binoculars: for symbols that relate to the

search for the location of objects.
208
Chapter 6
Objects and Symbols

Table 6-4

Description
Clipboard: for symbols that represent an
inventory of objects.
Closing lid: for closing a window or view

within a window.
Cloud: for symbols that include the concept

of a Wide Area Network.
Cog: for symbols that include the concept of

hidden software that allow applications or
hardware to run, for example, daemons,
services, agents.
Configuration switches: for symbols that

represent the configuration of part of the HP
OpenView environment.
Curved arrow: for symbols that represent

the action of taking an object and moving or
copying it into a different form or location.
Chapter 6
209
Objects and Symbols

Table 6-4

Description
Envelope: for symbols that include the
concept of mail.
File cabinet: for symbols that include the

concept of a file system.
Folder: for symbols that include the concept

of a folder or other type of container. A
graphic for type of object in the container
can be super imposed on the folder graphic.
Glasses: for symbols that involve the

previewing of either information or the
results of an action that will be simulated
before it is actually carried out.
Globe: for symbols that include the concept

of the World Wide Web.
Hierarchy with top: for symbols that include

the concept of going to the top of a
hierarchy.
House: for symbols that include the concept
of a home location.
210
Chapter 6
Objects and Symbols

Table 6-4

Description
Line Graph: for symbols that represent
on-going data collection or presentation for
one or more variables.
Listing sheet: for symbols that represent

listings of information.
Magnifying glass: for action symbols that

provide a closer look at one or more objects,
or which are used for monitoring objects or
processes.
Mixture of tools/application: for symbols
that represent an application which provides
a variety of functionality.
Monitor and desktop computer: for symbols

that include the concept of a pc type of
computer. The operating system or vendor
for the pc should be presented by changing
the content of the display for the PC.
Monitor and keyboard: for symbols that
include the concept of a workstation type of
computer. The operating system or vendor
for the workstation should be presented by
changing the content of the display for the
workstation.
Chapter 6
211
Objects and Symbols

Table 6-4

Description
Multitabbed folder: for symbols that include
the concept of a properties.
Multiple instances of the same type of

object: for symbols that represent a group of
that type of object.
Network Triangle: for symbols that include

the concept of a local area network (LAN)
of an indeterminate type.
Options box: for symbols that represent the

configuration of an object in a context that is
not dedicated to configuration.
Person: for symbols that include the concept

of a user.
Printer: for symbols that include the concept

of a printer.
Pyramid of Disks: for symbols that include

the concept of a database.
212
Chapter 6
Objects and Symbols

Table 6-4

Description
Question Mark: for symbols that include the
concept of help.
Sheets of paper: for symbols that include the

concept of a file.
Sparkle: for symbols that include the

concept of a creating something new.
Status colors: for symbols that represent the

functionality of providing status
information on one or more objects.
Switch: for symbols that include the concept

of some type of switch.
Table: for symbols that represent the

presentation of static data on one or more
variables.
Chapter 6
213
Objects and Symbols

Table 6-4

Description
Trash can: for symbols that represent the
deletion or removal of something.
Yellow Triangle: for symbols that include

the concept of an alarm, event, message.
New Symbol Subclasses (Graphics) for Objects

Required
Applications that present objects in iconic views must provide at least

two sizes for each icon: 16x16 and 32x32.
Recommended
It is recommended that applications which simultaneously present a

large number of objects in the results pane should provide their icon
symbols in multiple sizes so that the images can be scaled without
distortion 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 makes
it easier for users to recognize what is being presented in the toolbar
button.
Some HP OpenView applications use size 16x16 toolbar buttons. As a
result, it is a good idea to provide toolbar buttons in two sizes: 16x16, and
24x24.
Action graphics used in the results pane should be the same size as new
symbol subclasses for objects, above.
Required
New symbol subclasses must use the same outside shape as defined for
other symbols in that class. Do not create new symbols that belong in an
existing class of symbols and place them in a new symbol class.
214
Chapter 6
Objects and Symbols

Recommended
If action symbols are to be used for accessing functionality via executable

symbols, these action symbols should come from the Software Utilities
class (or appear as transparent symbols).
Required
New symbol subclasses must contain any class-specific graphics that

have been defined for the class.
Recommended
If a new graphic has concepts similar to other graphic that are already
defined for HP OpenView, the new graphic should use the same visual
cues as the existing symbols.
Recommended
Graphics that represent the symbol subclasses should be easily

recognized by users as being associated with the objects they represent.
Recommended
The graphics that are used for action symbols must provide a
representation of one or more of the following:
The type of functionality being provided by the control that the
symbol is associated with (such as using a curved arrow to represent
copying or installing).
The type of result that will be obtained as a result of the action (such
as installed software).
The type of object being acted upon (such as software).
Example 6-17
Example:
The symbol for a fax card contains the graphic for a fax device and the
class-specific graphic for a card.
Recommended
Graphics should not have the potential of offending users.
Example 6-18
Example:
A devil may be an easily recognizable symbol for a UNIX daemon, but it
should not be used as it has the potential to offend users. Graphics which
contain body parts (such as a hand) also may be viewed as offensive in
some cultures.
Recommended
If possible, the graphics used in subclasses should not require changes

when they are localized for use in other countries. Graphics based on
puns or images for words that sound the same but which have a different
meaning should not be used, as they cannot be localized. To avoid the
Chapter 6
215
Objects and Symbols

need to localize graphical images, do not use the following items in a
subclasss 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 different
meaning.
Recommended
All graphics used for defining new symbol subclasses should come from
the network and system management domain or office domain; or they
should be logical or symbolic representations of the objects they
represent.
Recommended
A new subclass that is a variation of an existing icon symbol (such as, a

specific vendors PC), should either:
Provide a clearly recognizable version of the object that it represents.
Use a modification of an existing graphic that contains a cue
associated with the particular variation (for example, using a PC
symbol with the vendors initials in the display).
Recommended
When the symbol subclass is defined via a color pixmap, the colors used
in the bitmap or icon should:
Come from the color palette provided by HP OpenView, see Chapter
C , Color Mapping and Palettes.
Use subtle. muted coloring in the pixmap image so that the image
does not interfere with the visibility of the status colors. This is
particularly important when users are interacting with a submap
crowded with numerous small images.
Provide the illusion of a concrete, three-dimensional object rather
than the effect of a lot of color in the image.
216
Chapter 6
Objects and Symbols

New Connection Symbol Subclasses
New connection symbol subclasses should be created by applications only
when either:
The application has created a new connection symbol class and needs
to populate that class with subclasses.
Existing connection symbol subclasses are not sufficient to meet the
needs of the specific types of connections or relationships that need to
be represented.
Recommended
A symbol subclass must not be defined with a visual appearance that

could be interpreted as belonging to a class other than the one the
symbol actually belongs to, or which is identical to another instance of a
subclass that is in the same class. A new connection symbol subclass
should be defined only after examining the registered connection symbol
classes and subclasses for those applications with which an application
will coexist; this will ensure that the new symbol subclass will not be
defined in a way that it would conflict with existing symbol classes and
subclasses.
Recommended
Subclasses of a specific connection class must have the same overlay

graphic that will be used consistently across all members of the class. It
is generally recommended that two visual cues (such as line style and
overlay graphics) be maintained as common across all subclasses within
a class.
The use of line style and thickness in new connection symbol subclasses
must be consistent with the semantic meanings suggested for these
visual cues in the sections below and in Assigning Symbols to
Connections and Relationships."
Connection Symbol Line Style
Very similar line styles are difficult for users to differentiate. If line style
is used as the primary visual cue for differentiation between connection
symbol subclasses, care should be taken to make sure that all of the line
styles within a class are sufficiently different in their visual appearance.
Connection Symbol Thickness
When using thickness as an attribute of a connection symbol class or
subclass, the largest width allowed can be no greater than the icon
symbols being connected (that is the largest icon symbol allowed is 50x50
Chapter 6
217
Objects and Symbols

pixels wide). Also remember that, as the icon symbols shrink based on
the scaling of the submap, the connection symbols will also shrink. This
change in size may make it very difficult for users to discriminate
between different connections based on thickness alone. Users will be
judging the thickness of the connections relative to the size of the icon
that they are connecting.
Required
If thickness is used as the only visual cue for differentiating between

connection subclasses, only a few widths should be used (no more than
5.) The differences between the line widths should gradually increase as
the line widths increase. Due to proportional changes in line width with
any shrinkage in the icon symbols, the following line widths are
suggested: 1, 5, 15, 30, or 50 pixels.
If only two line widths are used, the thinnest line should be one pixel
wide and the thicker line should 5 pixels or more. If the difference in line
width is not at least 4 pixels, users will not be able discriminate
differences in width when the icons and connection symbols have been
scaled to their smallest size.
To aid users in discriminating between different subclasses, other
redundant visual cues should be provided in addition to thickness.
Possible redundant cues can be line style or variations in the overlay
graphic.
218
Chapter 6
Objects and Symbols

User Modification of Views

Changing Symbol Types
Applications should try to be as specific as possible when discovering
objects and representing them in their management hierarchies. No
matter how good the application is, there will likely be some types of
objects that the application cannot adequately differentiate. In these
instances, the symbol choice specified by the application will not be as
good as the symbol specification that can be provided by the user.
Optional
By default, users should be given the choice of changing a symbol type

only within the symbol class to which the object was originally assigned
rather than changing type to all possible classes.
Recommended
If there are multiple symbol classes that would be applicable for the
object within the active view, users should be able to chose between the
symbol classes in the Change Symbol Type dialog box.
See Figure 6-7 below for an example of a Change Symbol Type dialog
box.
Chapter 6
219
Objects and Symbols

Figure 6-7
Change Symbol Type Dialog Box
User Addition of Symbols

It is unlikely that applications will be able to discover all of the objects in
a given management area. As a result, applications should allow users to
add objects to their views.
Recommended
By default, users should be given the choice of adding symbols within the
symbol classes that are most appropriate for the active view. Symbols
that are not appropriate for the view should be excluded.
Recommended
When applicable, users should be able to add multiple objects by

specifying a file that defines the parameters required for adding the set
of objects.
220
Chapter 6
Objects and Symbols

Creating NNM Submaps

When creating views that will be submaps within NNM, a number of
factors 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 be
addressed. All of these topics are discussed in this section.
Shared vs. Exclusive Submaps

New submaps can be created as a shared submap or as an exclusive
submap. Shared submaps are those in which multiple applications use
the same application plane. Exclusive submaps are those that can be
used only by the creating application and by end users. Other
applications 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 the
application plane, thus building upon and adding value to the
application. Using shared submaps will also enable other applications to
add menus to the menu bar in a submap (if the menu placement rule
matches the context identifiers specified for this submap). Because
shared submaps allow applications to work together to create a total
picture, their use provides users with the ability to develop a map that
more closely approximates the composition and layout of their network
and systems environment. It also helps users locate and identify objects
for manipulation since the resulting maps are organized in a form
similar to a real world network.
Recommended
An exclusive submap should be created only if there are explicit reasons

for one application to keep other applications from modifying its submap
(such as an application which is able to provide absolutely all the detail
and information that a user would need in order every feature in that
application).
Recommended
An application should not attach exclusive submaps to an object in a

shared submap unless that application created the parent object.
Chapter 6
221
Objects and Symbols

Using an Existing Shared Submap

Rather than create its own submap, an application can add objects to an
existing shared submap that was created by another application. This
allows for the generation of a mapping that is closer to the composition
and layout of the users network and systems environment.
To use existing submaps, an application must be aware of other existing
and compatible applications. The first application must query HP
OpenView Windows to determine if the submap-creating application is
installed and running. If the submap-creating application is not installed
and running, the object-creating application must provide a backup
mechanism for creating its own submaps, or it must require the running
of the submap-creating application as a prerequisite for its invocation.
When menu items are added to an existing shared submap which are
specific to the objects being added to the submap, context identifiers
should be used to enable the association of these menu items with the
submap. Without these context identifiers, menu items for acting on
these new types of objects will not appear in the menu bar for the
submap.
Any application should anticipate the possibility that its submaps will be
used by other applications and determine how to interact with these
other applications.
Persistent and Transient Submaps

HP OpenView Windows provides transient submaps, which are created
and deleted on user demand. Transient submaps provide better overall
performance for users by allowing the management of a larger number of
objects. When the on-demand feature is enabled, only the host submap,
home submaps, and submaps that have been made persistent are loaded
into memory (RAM) when HP OpenView is first started. Other submaps
are loaded into RAM when the user opens them, and they are removed
from RAM when the last user closes them.
Persistent submaps are provided for backward compatibility and to allow
for compound presentation status. Filters can be used to make specific
submaps persistent if an application requires such persistence to
function appropriately. However, having a large number of persistent
submaps takes away the end-user advantages associated with transient
222
Chapter 6
Objects and Symbols

submaps. It is generally recommended that an application be designed to
use transient submaps. Any use of persistent submaps should be
minimized.
To move an application from being dependent on persistent submaps to
being designed to take advantage of the on-demand functionality, follow
these guidelines:
Required
Remove any application dependencies on the presence of symbols and

submaps.
Symbols and/or submaps created or used by an application will not
always be present in RAM. Since API calls to the map can act only on
what is currently in RAM, the results to an applications API calls may
be different than anticipated. If an application depends on the
continuous presence of all symbols and submaps, the information
received may not be timely or complete.
Example 6-19
Example:
If an application depends upon the notification of when new objects
are discovered and added to the NNM map, the application should
handle this notification when the submap containing the new object is
opened, as opposed to when NNM is first started.
If symbols are added to the child submaps, they should be added
gradually as submaps are opened, instead of when NNM is first
invoked. Note that a listing of submaps or objects in the map will
generally be incomplete, as the list will vary depending on which
submaps a user currently has open.
Recommended
If compound presentation status is being used, minimize the number of

levels of submaps required to provide this status. Limit the persistent
submaps to one level below the symbol that uses compound presentation
status.
Submap Context
The concept of submap context was developed to allow application
developers to tailor the menu items and toolbar buttons in each of their
applications submaps. Submap context better matches the menu items
and toolbar buttons in an application with the types of objects presented,
the type of management provided, and the user tasks performed.
Chapter 6
223
Objects and Symbols

The advantages of submap context include:
Eliminating continuously grayed-out menu items in a particular
submap.
Restricting menu contents based on the users tasks. Submap context
gives users quicker access to the menu items they need, based on the
types of objects in the submap and the type of work being done.
Giving developers of map applications more control over the types of
menu items presented in the submaps that they create. They specify
the context of submaps so that only those menu items relevant to the
submaps contents and type of management will be presented in the
submap menus.
Using Submap Context
Required
For each submap created, a submap context must be specified. If no

context identifiers are provided for a submap, it will contain only generic
menu items or undefined menu items that have no menu placement rules
identified. Information on how to specify context for menu items in HP
OpenView Windows submaps is in Context and Menu Items in Chapter
5.
Context can be added by end users or by other developers, but they can
be removed only by the application that created them. Since a menu item
needs to match only one submap context identifier, the more submap
context identifiers that are defined, the wider the variety of menu items
that can be included in a submap. Conversely, the use of fewer submap
context identifiers allows for finer placement of menu items.
The following guidelines suggest the types of submap context identifiers
to be defined when creating a submap:
Required
Include context identifiers for the type of management that will be done
by the users of the submap (such as printer management, disk space
management, or IP network management).
Recommended
Include context identifiers for the types of network protocols anticipated

in the submap (such as IP, SNMP, or CMIP).
Optional
Include context identifiers for the type of objects anticipated to occur in

the submap (such as routers, networks, bridges, gateways, generic
connector or PC, mini, workstation, or mainframe).
224
Chapter 6
Objects and Symbols

Required
Block generic menu items and toolbar buttons only if the submap is a
highly- specialized submap, where the inclusion of these items would
lead to user confusion and errors. Generic menu items and toolbar
buttons are blocked by specifying a submap context identifier of
NoGeneric. Examples of generic menu items are Print, Add Object.
Recommended
Block undefined menu items from submaps unless these submaps and
symbols are general ones that other applications are planning to build
upon. Pull-down menu items in applications that have not been
developed under the context-dependent paradigm will automatically
appear in submaps unless they are blocked. Contextually-undefined
pull-down menu items are blocked by specifying a submap context
identifier of NoUndefined.
Required
Provide consistent context identifiers for all submaps within a hierarchy

of submaps that relate to a given type of functionality (NFS, printer
management) or topology (IP or SNA). Testing has shown that users
become confused when there are arbitrary changes in the menus from
one submap level to the next. In a given hierarchy of submaps, make
variations within the context identifiers only if there are real differences
in the functionality associated with the submap or the objects to be
presented in the submap.
Recommended
When adding to the submap context of a submap created by another

application, define only those context identifiers that relate explicitly to
the particular symbols being added to the submap or the types of
management capabilities being added to the menus or toolbar.
Submap Window Geometry

This feature is supported for applications integrating into NNM when it
is running natively on HP-UX, Solaris, and Windows NT operating
system.
NNM provides applications with the ability to set the geometry (size and
location) for the submaps that they create. An end user can save his
changes to submap window geometry on a per-submap basis, which will
override the geometry settings of applications.
Given the integration of multiple applications that all have the ability to
set submap geometry, there is the potential for applications to create
usability problems for end users by creating submaps that totally
Chapter 6
225
Objects and Symbols

overlap those presented by other applications. To minimize the need for
window manipulation by the user, adhere to the following guidelines.
Required
Restrict an applications use of geometry for submaps by:

Setting submap geometry primarily for special-purpose windows if
the users use model is clearly understood.
Not specifying submap geometry for regular submap windows that
are 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 prior

to the first time the submap is displayed.
Required
After submap creation, applications should modify the initial submap

geometry (that is the geometry set at creation) only when requested by
the user. User requests are typically given through the choice of a menu
item or the activation of a toolbar button.
Example 6-20
Example:
An application could provide a menu item that would result in the tiling
of all submap windows open in the display if their geometry had not be
set by the end user.
Recommended
When specifying submap geometry, take into account all of the windows
that a user will simultaneously be using in his environment.
Before specifying submap geometry for any submap, develop an
understanding of what applications are likely to be in the users
environment and which ones he will use simultaneously. The geometry
for one applications submaps should not interfere with the use of other
applications.
Recommended
When specifying submap size, take into account both:

Consistency in the size of windows within a given hierarchy. If users
turn submap overlay off for a large number of submaps, it can be
disconcerting to have related submaps presented in different sizes
when the user has not modified the size.
Whether or not overlay is set for the submap window. If the submap
window is overlaid, parent submap and child submaps of the current
submap in the hierarchy must have the same size.
226
Chapter 6
Objects and Symbols

The number of windows to be presented on the screen at one time. If
an application sets a large size for its submap window, there will be
less space for other submap windows. The default size of an
applications submap must allow for the simultaneous viewing of
multiple submaps.
Recommended
When specifying submap location, take into account:

The flow of the users actions. In countries with European-based
languages, user task flow should proceed from the upper left portion
of the display to the lower right portion of the display. It is desirable
that the placement of windows be consistent with the language
variable specified by the user.
The other windows in the display. Window overlap should be
minimized.
Submap Window Overlay

This feature is supported for applications integrated into NNM when it
is running natively on HP-UX, Solaris, and Windows NT operating
system.
To minimize the number of extraneous windows that are presented
during user navigation within the map, HP OpenView reuses display
space when displaying submaps. By default, submap windows are
overlaid as the user directly navigates from one submap to the next (that
is, 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 a
per-submap basis.
Application developers have the ability to change the default state of the
overlay from on to off by using the OVw APIs. Map applications
should adhere to the following guidelines related to changing the setting
of the submap overlay toggle:
Recommended
The state of the overlay toggle should be left with the default of on if:
The submap is a regular submap window that is used to display the
topology of a set of managed objects. It is often difficult for
applications to identify at what level their customers will be trying to
do 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 a
Chapter 6
227
Objects and Symbols

given submap hierarchy, and there is no known reason to have the
different levels of the hierarchy open at the same time.
Recommended
The state of the overlay toggle should be changed to off immediately

after submap creation if:
The submap is a special-purpose submap that users will want to have
available at all times (for example, Quick Navigator), and overlaying
the submap will detract from its intended functionality.
It is known in advance that users will need to keep the current and
next level of the submap open in order to use the full functionality of
the two levels of submaps.
If an application developer specifies NoGeneric for his application, the
overlay menu item will not be available in his submap, and users will not
be able to change the overlay state. The developer must therefore modify
the application registration file to add back the overlay menu item.
228
Chapter 6
Object Selections, Grouping,

and Drag and Drop
229
Object Selections, Grouping, and Drag and Drop
This chapter provides guidelines on the following topics:

Selection of objects.
Grouping of objects.
Drag and drop.
230
Chapter 7

Selection Guidelines
Many HP OpenView applications use an object-action syntax in their
user interfaces. Users select symbols to indicate the objects that they
want to manipulate, then select menu items to initiate the desired
action. The selected objects make up the selection list.
Selection is a key aspect of user interaction with an application or set of
applications. Consistency in the way selections are made, how they are
displayed and how they are treated by the application is very important
for ease of learning of individual applications and transfer of training
across applications. Users do not want to learn special selection rules for
interacting with specific applications.
Basic Selection Model

The HP OpenView Environment frequently has multiple applications
running together. Individual applications within the environment may
be developed as multiple pane windows or presentation managers that
have access to different views within a single window. However,
functionality that requires a global selection list including all selections
within a set of applications or selection that extends across multiple
views in a window is less common than functionality that focuses on the
selections that are contained within a single view. For most tasks users
make their selections within a single view in the results pane of the
window.
The basic selection model for HP OpenView applications is based on the
most common type of selections done by users. It also is consistent with
the most common type of selection in the Windows NT operating system
and the Common Desktop Environment on UNIX. This selection model
limits the list of selections to all items selected within the current
window.
A global selection list that can include selections across all windows in
the HP OpenView Environment is planned for the future. The planned
global selection list will not be the default selection list, this list will be
used only when the user takes an explicit action to request its use.
The HP OpenView Windows provides a global selection list that is
applicable to all HP OpenView applications (that is, NNM, ITO) in the
Windows NT or UNIX environment. This selection list is being
Chapter 7
231

maintained for backward compatibility reasons but will be replaced in
the future.
The following guidelines provide details on the basic selection model for
HP OpenView applications.
Required
The active selection list, for application not based on HP OpenView

windows, must be restricted to items selected within the current window.
In the future, users will be able to request the use of a global selection
list.
Required
If the user makes an single selection in the scope pane or in the results
pane 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 selected
appearance of the open item in the scope pane must be removed and
replaced by a location cursor or an open indicator for the item in the
scope pane. See Figure 7-1 for an example.
Recommended
Users should be able to do a range select using Shift+Click or by rubber

banding objects within a view.
Required
If the user does a Ctrl+Select, the selection state of the item should toggle
to on if it was not previously selected or toggle to off if it was previously
selected and the selection state of other items within the window are
unchanged.
Required
Child windows and copies of application windows should have their own
selection lists that do not affect selections in the parent window.
NOTE
Child windows are windows which present a single view that was
originally presented in the presentation manager used for accessing
multiple views. Copies of the window refers to duplicate windows that
include 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 child
window, the selections in the current and new window should be
unaffected.
232
Chapter 7

Recommended
Users should be able to select items with the keyboard by pressing the
Space Bar or Enter key when the item has keyboard focus.
Recommended
When an item is selected, it should be shown as selected in both the

results pane and in the scope pane if it appears in both.
Required
Any currently-selected item(s) visible should be marked by a selection

indicator or by a selection toggle:
In a native UNIX or Windows NT operating system application, the
selection indicator is one defined by the operating system.
In a JAVA application or applet, the selection indicator should be
defined 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
of colors in Web applications.
In an HTML application, the selection indicator should be a block of
color (0x c0c0ff) surrounding the items label (see Chapter 2 , Web
Applications, for more information on the use of colors in Web
applications).
A radio button, if all items in the scope pane are mutually
exclusive.
A check box, if multiple selection of items is allowed.
Affects of Navigation on Selection
Navigation within the application has the potential for affecting the
users selections. The following guidelines must be adhered to by all HP
OpenView Applications.
See also guidelines for Multiple Selection Across Views in a Window for
guidelines related to navigation.
Required
Expanding and contacting items in the scope pane should have no affect
on the selection list.
Chapter 7
233

Required
Users should be able to change the visible view without affecting the
selection 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 all
existing selections, select the item the was clicked on and cause the
results pane to show a view associated with the item.
Required
Double clicking on an container object in the results pane should cause

the view associated with the container object to be displayed in the
results pane. The scope pane should change so that the object that was
double clicked is visible and has a location cursor or open indicator
associated with it. Double clicking should have no affect on the selection
list.
Items that were selected before the double click should remain selected.
Multiple Selection Across Views in a Window

Use of the scope pane to navigate has an affect on selections. Typically
selection in a scope pane clears all selections in the results pane. Extra
implementation and user effort is required to allow users to be able to do
multiple selection across views within a window.
To select multiple objects on separate views of the same window, the user
has various alternatives depending on what functionality has been
implemented into the presentation manager:
If the application has provided capabilities for multiple selection in
the scope pane, the user can expand the hierarchy and use
Ctrl+Select to select the desired objects in the scope pane. See
Multiple Selection in the Scope Pane for guidelines related to this
approach.
If the application has provided a multiple-view selection list, users
can use Ctrl+Select to select multiple items in the results pane and
Ctrl+Select to navigate in the scope pane without changing selections
in the results pane. See Multiple Selection Across Results Panes for
guidelines related to this approach.
234
Chapter 7

Multiple Selection in the Scope Pane
The following guidelines are only applicable if an application with a
scope pane window provides multiple selection across views and allows
users to make multiple selections in the scope pane.
Required
When the user does a single selection of an item in the scope pane to
navigate to a new view, this selection should clear the selections in the
results pane unless the user does a Ctrl+Select.
Required
Users must be able to use Ctrl+Select in the scope pane as well as the
results pane to toggle the selection state of the item under the pointer.
Required
Expanding and contacting items in the scope pane should have no affect
on the selection list.
Recommended
When an object or item (that is, message) is selected it by a Ctrl+Select

in the results pane, it is shown as selected in the scope pane and as well
as 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 their
selections when they are making multiple selections across different
views. If multiple selections are allowed in the scope pane, users want to
see all of their selections in the scope pane.
Required
When the user does multiple selection with Ctrl+Select, the selection list
must consist of all selected objects or items in the window, regardless of
whether they are visible or not.
Chapter 7
235

Figure 7-1
Selection List for Scope Pane that Allows Multiple Selection
Required
Selections in child windows that are reattached to the parent window

should be maintained and the selections should be added to the selection
list in the parent window.
For example, a user places view B in a child window. The user then
proceeds to select 3 objects in view A in the parent window and 2
objects in view B in the child window. While the windows are
separated, the parent windows selection list consists of three items and
the child windows selection list consists of 2 items. If the user reattaches
the child window to the parent window, the selection list in the parent
window will consist of 5 items (3 in view A and 2 in view B).
Multiple Selection Across Results Panes
The following guidelines are applicable if an application with a scope
pane window provides multiple selection across views and users can only
make a single selection in the scope pane.
This approach is applicable to HP OpenView applications that plan to
236
Chapter 7

integrate into Microsofts Management Console (MMC), however, the
MMC does not provide support for multiple selection across views shown
in the results pane.
Required
When the user does a single selection of an item in the scope pane to
navigate to a new view, this selection clears the selections in the results
pane unless the user does a Ctrl+ Select.
Required
When an object or item (that is, message) is selected it by a Ctrl+Select

in the scope pane all selections in the scope pane are removed, the
selections in the results panes are maintained. The scope pane will show
the selected object with a location cursor or an open indicator but not a
selection highlight. The results pane will show a view associated with
the item in the scope pane.
NOTE
Ctrl+Select in the scope pane should not select the object that is only
being used for navigation. To have this object selected would require
users to take extra steps in order to obtain the selection list that they
would want to use. That is to remove the scope pane object from the
selection 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 accessible
selection 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 their
selections when they are making multiple selections across different
views. Without this capability it becomes difficult for users to accurately
make their selections. .
When the user does multiple selection with Ctrl+Select, the selection list
must consist of all selected objects or items in the window, regardless of
whether they are visible or not.
Required
Selections in child windows that are reattached to the parent window

should be maintained and the selections should be added to the selection
list in the parent window.
For example, a user places view B in a child window. The user then
proceeds to select 3 objects in view A in the parent window and 2
objects in view B in the child window. While the windows are
separated, the parent windows selection list consists of three items and
Chapter 7
237

the child windows selection list consists of 2 items. If the user reattaches
the child window to the parent window, the selection list in the parent
window will consist of 5 items (3 in view A and 2 in view B).
Recursive or Group Selection

User performance in management tasks can be enhanced by allowing
recursive selection in which all of the items within a container object are
selected at the time the container object is selected. This allows users to
select multiple items with a single action and then take desired actions
on 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 Boxes
Tree Lists with check boxes allow users to select objects at different
levels in the hierarchy. This type of selection allows the selection to be
inherited by objects lower in the hierarchy. Users should be able to make
selections at each level in the hierarchy.
The following guidelines are applicable only to applications that provide
recursive selection in a tree list with check boxes.
Required
If the user selects an item at a higher level in the hierarchy, all items
contained within the higher level item should be marked as selected (for
example, 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 light
gray instead of black to indicate that the item is partially selected.
The selection of a subset of items can be accomplished by directly
selecting some of the lower level items or by deselecting a subset of lower
level items that under a previously selected higher level item.
In Figure 7-2 below, the left most graphic shows what the tree would look
like with no selections. If the user directly selected HP-UX, the higher
level item Nodes would be shown as partially selected, see the graphic
in the middle. As is shown in the right most graphic, if the user directly
selected Denver the lower level items under Denver would
238
Chapter 7

automatically be selected and higher level items in the hierarchy would
be shown as partially selected.
Figure 7-2
Visual Cues for Recursive Selection
Recommended
If it is important to distinguish items where selection is inherited as

compared to items that are directly selected, this should be indicated by
visual cues.
Required
Clicking on the check box or on the icon to make the item part of a
multiple selection should not affect the position of the selection cursor or
location cursor if the tree list is presented in the scope pane.
Group Selection for Container Symbols
In the OpenView management environment there are many container
symbols that are of interest to the user as an object and which contain
other objects. For example, a network is a container for computers,
connectors, and network devices but it also can be viewed as a object for
which the user wants to obtain and monitor data. A computer is a
container for software, interface cards, etc., and it is also a specific device
that users want to manipulate.
To allow flexibility to accommodate user needs, containers should allow
users to easily:
Select the container object without selecting the objects contained
within.
Select all of the objects contained within the container.
Chapter 7
239

Required
A single click on the container symbol should select of the container

object without selecting the objects contained within it.
Keyboard equivalents for selection by a single click should also be
provided.
Recommended
A pop-up menu item should be provided for selecting of all of the objects
contained within the container symbol. The menu item should be labeled
Select Grouped Items
Recommended
When objects are selected by selecting the container, the selection list
should either list all lower level items that have been selected or provide
a visual cue associated with container item so that it can be
distinguished from items that were not selected via a group selection.
Recommended
When objects are selected with a group selection, menu items executed
on the group should act on the subset of items in the group to which they
are applicable. Menu item graying should be disabled when a group
selection is in effect.
Selection Lists in Applications Integrating into

Presentation Managers
Many applications integrating into presentation managers integrate
their functionality as menu items or toolbar buttons that result in the
presentation of a separate window. These separate windows are referred
to as tools. A single application may integrate multiple tools into a
Recommended
If a tool requires selections and is accessed from a menu or toolbar in an

object presentation manager, the tool should use selection list from the
object presentation manager and allow the user to set or change the
selections within the tool.
Recommended
If a tool that is launched from a presentation manager and takes its

selections from the presentation manager, it should provide a means for
the user to determine what selections the tool is using (that is, a control
that displays the current selections, or the name of the selection in the
title bar).
Recommended
If a tool can act on only a single selection, the selection should be

displayed ion one of the following ways.
240
Chapter 7

Selection in Text Field (if users can change the selection)
Use of a single line text field that displays the current selection
minimized the use of display space while allowing users to modify the
selection.
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 and

view the list of selections.
If applicable, users should be able to view all possible selections and be
able to differentiate active selections from inactive selections.
Providing Access to HP OpenView Windows Selection

List
Recommended
If the application or tool is implemented using the OVw API and it uses
the HP OpenView Windows selection list, provide users with a
mechanism for accessing the HP OpenView Windows selection list once
your application is started.
The application involves the manipulation of different sets of objects
used in different capacities.
For example, in a software distribution tool that requires the user to
identify a list of nodes that will receive software and the server that
will be used for the update, the user could use the HP OpenView
Windows selection list to specify the target nodes before the
application is launched. Once the tool is running, the user could use
the HP OpenView Windows selection list to select the server node.
Successful completion of the users task requires re-running the
application with a different set of selected objects.
For example, a diagnostic tool indicates that there is a configuration
discrepancy between a selected node and one or more nodes that were
not previously in the tools selection list. To isolate and fix the
problem the new nodes must be in the selection list.
After running the application with one set of objects, the user wants
to re-run the application with a new set of objects.
Chapter 7
241

For example, the user may use a tool to monitor a variable on a
system, and then decide to monitor that variable on a different
system.
Modifying the HP OpenView Windows Selection List

Applications can modify the HP OpenView Windows selection list
through the OVw API. Applications have the ability to select and
deselect objects. The selection and deselection of objects needs to be done
with care as users expect to have control over the selection list and
changes to the selection list need to be consistent across applications.
Modifying the selection list in a manner that is not anticipated by the
users could lead to user confusion and errors.
Required
Applications other than NNM should only modify the Open View
Windows selection list based on an explicit user request through a menu
item or a push button.
Required
If an application integrated into NNM is going to modify the selection

list, it should add or remove items from the selection list only under the
following three conditions:
Items are added or dropped from the selection list in conjunction with
user actions that the user will associate with selection.
For example, the user selects a grouping symbol and all objects
contained within the grouping are added to the selection list, and the
grouping symbol is removed from the list.
Items are dropped from the selection list in response to a users choice
in a confirmation message.
For example, the user selects a number of objects and tries to execute
an action on them. Because the user has permission to take the
specified action only on a subset of the objects, the user is presented
with a confirmation message. In the confirmation message, the user is
given the choice of deselecting objects for which he does not have
permission and then proceeding with the action, or cancelling the
requested action.
Items are added to or dropped from the selection list and a message is
presented to the user, notifying him of the change.
For example, the user selects a number of systems and tries to
execute an action on them. Some of the systems cannot be contacted
242
Chapter 7

to make the user-requested change. The change is made on those
systems that were contacted. The user is then notified to indicate that
systems for which the change was made were removed from the
selection list. The current selection lists contains only those systems
which could not be contacted. This will allow the user to take any
necessary actions on the remaining systems without the need to
locate and select them.
Chapter 7
243

Drag and Drop
Drag and Drop

HP OpenViews drag and drop supports the user guided approach to
management and uses an object-action paradigm. Users can drag
symbols or table entries that represent objects and drop them on drop
targets within and across applications. An object action paradigm allows
users to drop objects onto other objects or to drop objects onto actions.
Dropping of actions on to objects is not valid in the object-action
paradigm.
HP OpenView applications can provide default drag and drop for
graphical views, tabular views, executable symbols and explodable
symbols or containers. Generally if the user does a drag operation
without a modifier key, the action is interpreted as a move. If the user
does a drag operation while pressing the Control key the action is
interpreted as a Copy operation. If the user does a drag operation while
pressing the Shift key, the action is interpreted as a Copy.
Copy operations affect the dragged object or the drop target, but not
the view in which the dragged object was originally located. Generally
the copy operation places a copy of the dragged symbol or table entry
at the drop target without removing the symbol/table entry from its
original location.
A move operation must place a copy of the dragged symbol or table
entry at the drop target and then remove the symbol or table entry
from its original location.
Visual Cues for Drag and Drop

Users should be provided with visual cues during drag and drop
operations so that they know whether the operation will result in a copy
or a move. They also need visual cues to indicate when a drop operation
is not allowed.
Recommended
The visual cue for a copy operation is a + sign associated with the pointer
when the object is being dragged over a drop target that would result in a
copy.
Recommended
The visual cue for a move operation is the pointer when the object is
being dragged over a drop target that would result in a move.
244
Chapter 7

Drag and Drop
Recommended
When an object is being dragged over a drop target that will not allow a
drop, it is recommended that the user be presented with a not sign in
association with the pointer.
Recommended
Applications should be implemented to do the right thing regardless of

how the user initiated a drag operation.
Applications that change from the typical drag and drop behavior should
define their drop target behavior to be consistent with the most likely
and or desirable operation from the users perspective. For example:
If a user drags a symbol or table entry to a location that causes some
configuration change to the dragged item, the original symbol or table
entry should not be removed unless removal is consistent with the
configuration change.
If a user drags a symbol or table entry to a location that causes an
action to be initiated that is not a configuration change (that is, graph
collected data), the symbol or table entry for the object should remain
at its original location after the action is completed.
If a user drags an symbol for an activity from one process outline to
another, the activity should remain at its original location after the
action is completed.
For guidance on user appropriate drop target behavior, see Guidelines
for Specific Types of Drop Targets. Note: These guidelines are intended
to aid the user as some users may not know the key sequence to initiate a
copy instead of a move operation and users may not understand in
advance the particular drag and drop operation that is required for
specific drop targets.
Guidelines for Specific Types of Drop Targets

Views as Drop Targets
Views are presented to users in the results pane of presentation manager
windows. A view consists of the data to be presented to the user and the
presentation format for that data.
When drag and drop is supported, users can drag objects from other
views or the scope pane and drop them into a tabular or graphical view.
Recommended
The application should create any new symbols or table entries required
at the drop target as a result of the drag and drop operation.
Chapter 7
245

Drag and Drop
Recommended
When an object is dropped into a view, it should automatically change to

the presentation format that matches the format into which it was
dropped.
Recommended
If the drop target is a graphical view and automatic layout is off, the
dropped 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, the
dropped symbol should remain at dropped location for 3-5 seconds and
then be moved to a position that is consistent with the layout algorithm
and which is as close as possible to the location where the user dropped
the symbol.
The automatic layout algorithm should never cause the symbol to be
moved to a location that is not visible in the current viewing area of the
window. If the automatic layout algorithm would cause the symbol to
move to a location that would be out of the visible display space, the
window should be automatically scrolled so the dropped object is visible.
Recommended
If the drop target is a tabular view, the dropped entry should remain at
the location where the user dropped it. The entry should be
automatically selected to aid the user in identifying it.
Recommended
If the user takes an action to sorting the information in the table, the
dropped entry should be placed in a sequence based the sorting
algorithm specified by the user. The entry was selected, it should remain
selected to aid the user in identifying it.
Recommended
If the dragged object is a table entry and the drop target has different
table entries than the view that was the source of the drag operation, the
table entry for the dropped object should automatically be modified to fit
the table in which the object was dropped or the drop target should reject
the dropped entry. If the name field is the only field that is applicable for
the dropped object, all other columns in the table should be blank or have
a dash in them.
Recommended
If the user drops an executable symbol into a view, the executable symbol
should be placed in the view if it has the characteristics that are required
for that view. The action associated with the executable symbol should
not be executed.
Recommended
If the dropped symbol or table entry does not have the characteristics
that are required for the view:
246
Chapter 7

Drag and Drop
The drop operation should result in a presentation edit where the
dropped object(s) is presented in the user plane for the view.
or
The drop operation should be rejected and the symbol or table entry
should be restored to its original location.
Container Symbols as Drop Targets
Container symbols (also known as explodable symbols) are presented in
the scope pane of windows and in graphical views of data presented in
the results pane. The following guidelines apply to container symbols as
drop targets:
Recommended
When a dragged item is dropped on to a container symbol, the item

should by default be propagated to the child view of that symbol.
This behavior can be modified by specifying how far down the hierarchy
the symbol will appear. In some cases, symbols which are dropped on a
container symbol may appear in views at various levels below the drop
target symbol. For example, when a symbol representing a user is
dropped on a symbol representing a computer system, the new user
symbol might actually show up in a user view that is two levels below the
computer systems view.
Recommended
If the user drops an executable symbol on a container symbol, the action

associated with the executable symbol should not be executed. Instead
the container symbol should be treated it as if it were an object (for
example, dropped into the child view) or the drop operation should be
rejected.
Recommended
If the user drops a group symbol on to a container symbol, the group

should be treated as if it were a single object and the symbol for the
group should be passed on to a child view.
Recommended
The rules for propagating dropped symbols/table entries to lower level

views must be consistent across drop targets of the same type and make
sense given the type of item being dragged and the logical hierarchy of
views.
Recommended
Dragging a symbol or table entry to a container symbol in the scope pane

has the same results as if the symbol were dropped the container symbol
in the results pane.
Chapter 7
247

Drag and Drop
Recommended
If the dropped symbol or table entry does not match the characteristics
that are required for the any of the views under the compound symbol:
The drop operation should result in a presentation edit where the
dropped object(s) is presented in the user plane for the child view
under the symbol.
or
The drop operation should be rejected and the symbol or table entry
should be bounced back to its original location.
Leaf Level Symbols as Drop Targets
Leaf level symbols are typically presented in the presented in views in
the results pane. Leaf level symbols may also be presented in the scope
pane.
When a dragged item is dropped on to a leaf symbol, the dropped object
cannot appear in a child view. By definition, leaf level symbols are ones
that do not contain other objects. However leaf level symbols do have
attributes 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 leaf
level symbol, the drag operation should result in a change in the
attributes associated with the leaf level symbol or the drop operation
should be rejected.
Recommended
If a executable symbol is dropped on a leaf level symbol, the drop

operation should be rejected.
Executable Symbols as Drop Targets
Executable symbols are symbols that represent an action.
Recommended
Dragged items which are dropped on an executable symbol should be

treated as the selection list for the actions initiated by that executable
symbol.
If the dropped symbol(s) or table entries do not match the capabilities
required for the executable, the operation should be rejected for all items
that are dropped on the symbol. The symbol(s) or table entries should be
bounced back to their original locations.
Recommended
If the user uses the pop-up menu to select all items in a container and
248
Chapter 7

Drag and Drop
then drags and drops the container symbol on an executable symbol, the
objects contained within the group should be used as the selection list for
the actions initiated by that executable.
Recommended
If an executable symbol is dropped on an executable symbol, the drop

operation should be rejected.
Drop Targets that Cause a Change in the Instrumentation Space
In some instances, the result of a drag and drop operation may be a
significant change to real underlying data for the dragged object or the
drop target. This might happen, for example, when dropping the item
results in editing of a configuration file or a change in topological
information for the objects involved.
Recommended
When a drag operation will result in a change in the underlying

managed objects, the application should help which explicitly describes
the instances when an instrumentation change will occur through use of
drag and drop.
Recommended
If the data change is not obvious given the type of dragged item, or the
drop target behavior is severe or unrecoverable, the application must
provide a warning dialog (after the drop) which permits the user to
cancel the action.
Use of HP OpenView Windows Drag and Drop

HP OpenView Windows provides support for drag and drop on the UNIX
operating system. When HP OpenView Windowss drag and drop is used
each application defines what semantic actions will occur at a given
drop-target. These actions can be strictly specified depending on the type
of item dragged.
Applications can specify drop-target behavior on an instance basis by
using the OVw API.
If the OVw APIs is used to specify drop target actions, developers must
ensure that all objects with the same symbol types within a particular
view maintain the same drop target behavior.
Recommended
Applications that provide drop-targets should document their

registration files and application callbacks related to drag and drop. This
Chapter 7
249

Drag and Drop
will allow other applications to enable their symbols to be dropped on the
first applications drop-targets.
Drop Target Help
For HP OpenView Windows drag and drop, drop target help is provided
to users upon pressing F1 when the pointer with the dragged item is over
a registered drop target location or on some platforms as a result of the
user resting the dragged object over the drop target for a minimum of 2
seconds.
Recommended
Drop target help should be provided for all application registered drop
targets that have behavior that is different than the default.
Recommended
At a minimum, drop target help should include a summary of any special

actions 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 provide
the user with enough information to decide whether they want to
continue with the drop theyve initiated or to identify what they can do if
the items they are dragging are not permitted to be dropped at that
location.
Executable Symbols with Explodable Appearance
HP OpenView Windows allows applications to create executable symbols
that have the appearance of explodable symbols.
Recommended
In cases where the symbol appearance of an executable has been

changed to indicate a compound (explodable) symbol, you must treat the
dropped items in the same manner as that described for container
(explodable) symbols.
250
Chapter 7
Visual Presentation
251
Visual Presentation
This chapter presents design and style guidelines for the use of visual
presentation capabilities, including:
Status and events
Highlighting symbols
Symbol alerts
Text annotation
Flashing symbols
Transparent symbols
Executable symbol appearance
Partially filled connection symbols
252
Chapter 8
Visual Presentation
General Guidelines
General Guidelines
Overuse of visual cues in applications will result in visual clutter and
will 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 require
operator notification.
The use of visual cues be consistent throughout a given context. A
given visual cue should not be used for different purposes within a
context.
Chapter 8
253
Visual Presentation
Notification of Object Conditions

Many applications provide condition information on the managed
objects, network, systems or services. In HP OpenView, applications can
notify 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 managed
objects with messages.
Logging the conditions to a file.
Visual Cues versus Alarm Messages

If an application detects many different conditions for an object, the
application should not attempt to present all of these conditions in the
form of a visual cue in an iconic view of objects. For example, applications
that support SNMP traps or CMIP events have the choice of informing
the user about the condition of an object through either an alarm sent to
a message browser or by providing visual cues on the symbols
representing the objects.
Recommended
Only the most important object conditions should be presented through

visual cues in iconic views.
Recommended
If an application provides alarms or visual cues for communicating the

state of the network, systems or services, the application should allow
users 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.
254
Chapter 8
Visual Presentation
Use of Status Colors

Status color is the color presented in association with objects to provide
information on the operational or administrative status of the objects.
The most common use of status colors is in iconic view of objects. In these
views, the status color is displayed in background of class shapes of
object symbols and is used for drawing connection symbols. HP
OpenView has defined two different sets of status colors, operational
status colors and administrative status colors, see Table 8-1, Default
Status Colors Defined for HP OpenView.
Recommended
Status color should be used as the primary visual cue for summarizing
the operational or administrative status of a managed object presented
in an iconic view.
Recommended
The summarized state of an object should be based solely on important

conditions about which the user would want to be notified immediately.
Required
Status color must not be used to notify users of a specific condition (for
example, system rebooting) or to indicate what type of action a user
should take with regard to the state of an object. This detailed
information 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 to
configure the colors used for status will allow color impaired users to
choose colors that they can differentiate in terms of brightness when
they are unable to differentiate the hues.
Required
The default status colors used by applications must match the default
status colors defined for HP OpenView.
Table 8-1
Default Status Colors Defined for HP OpenView

Status Name
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
Chapter 8
255
Visual Presentation
Table 8-1
Default Status Colors Defined for HP OpenView

Status Name
Color
RGB Value
Status Type
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
Source of Status Information

Status coloring of symbols can be based on the a single attribute of a
managed object, multiple attributes of a managed object, or on attributes
of multiple managed objects. The choice of what contributes to the status
information will determine how useful the status information is to the
user.
Recommended
The status coloring of objects that contain other objects should be based
on the status of all contained objects that are relevant to the current
context.
Example 8-1
Example
In a context for file server management, the status of the server should
be based the servers file systems, network card, processes related to
serving the file systems and connecting to the network. The status of the
printers on this system and processes related to these printers should
not contribute to the file servers status coloring.
Recommended
The status coloring of leaf-level objects that do not contain other objects
should be based on the status of object attributes that are relevant to the
current context.
256
Chapter 8
Visual Presentation
Example 8-2
Example
In a context for file server management, the status of the network card
should be based on whether the network card is functional and
connecting the server to the network.
Status Source in NNM
HP OpenView Network Node Manager (NNM) provides a choice status
sources for the setting status of status colors by applications. The status
source choices are by object, by symbol, or by compound status. The
following guidelines should be used by applications integrating into
NNM.
A single real world object can be acted on and monitored by multiple
status setting applications. Users may need and want to have status
information from all of the different applications.
It is undesirable to have more than one application setting status on a
single symbol since it can result in applications changing the status color
back 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 a
symbol is determined as follows:
An application that creates a symbol is its owner.
For a user-added symbol, the first application that accepts the symbol
into the application plane is its owner. The application that created
the submap to which the symbol is added is given preference over
other applications if it accepts the symbol into the application plane
at the time the symbol is added.
The application designated as the owner of a symbol appears first in
the list of interested applications found in the symbol information
structure for that symbol.
Recommended
Use object status source for the symbols representing low-level,

non-compound objects that your application is responsible for and that
no other application should be setting status on (for example, an IP
interface card).
Recommended
Object status source should only be used by the application that created
the object in the HP OpenView Windows database (ovwdb).
Chapter 8
257
Visual Presentation
Recommended
Compound status is appropriate only for compound objects that have

persistent child submaps. The number of submap levels that an
application requires to be persistent should be limited. Compound status
should be dependent on the persistence of only the child submap under
the symbol.
Recommended
If an application wants to provide status information on objects that

were created by other applications in the HP OpenView Windows
database, the application should create a new symbol for the object and
set status by symbol. Status should be set by symbol only if the
application created the symbol.
Further information about status and events can be found in
HP OpenView Integration Series: OpenView Windows Developers Guide.
258
Chapter 8
Visual Presentation
Symbol Alerts
Symbol Alerts
Support for symbol alerts is only provided for applications integrating
into NNM on HP-UX and Solaris. All applications may use symbol alters
but may need to implement them on their own.
Symbol alerts are dynamically displayed graphics that are linked to
symbols used to represent objects or connections. They are used to notify
users of alarms, critical events, or of changes in status where a single
symbol may have multiple attributes for which status is set. Symbol
alerts may be presented in the scope pane of a window or the in the
results pane. Symbol alerts in the results pane are not scaled and cannot
be occluded by object symbols, therefore, they provide a very powerful
visual 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
Chapter 8
259
Visual Presentation
Symbol Alerts
When to Use Symbol Alerts

Required
If symbol alerts are used, their primary purpose should be to notify the
user of an important event or condition that requires user attention and
to 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 severity

of minor, major or critical only. Alarms with lower levels of severity must
not have symbol alerts associated with them unless they have been
specifically configured by the HP OpenView administrator.
Guidelines for Symbol Alerts

Consistent use of symbol alerts will make them more meaningful to
users and will enable symbol alerts to better support user-task
performance.
Required
If symbol alerts are used, they should by default be presented at the

highest 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 symbol
alert.
Symbols for objects that contain other objects whose status
caused the symbol alert.
In the scope pane, the symbol alert should be presented next to the
highest unexpanded level in the hierarchy that contains an object
whose 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 monitoring
and to still obtain specific information about problems with objects at
lower levels in the management hierarchy (for example, individual
systems or components within systems).
Recommended
To allow symbol alerts to better meet user needs, the application should
allow HP OpenView administrators to choose the level within the
hierarchy at which the symbol alerts will be presented.
260
Chapter 8
Visual Presentation
Symbol Alerts
Recommended
The HP OpenView symbol alert graphics should be used for symbol

alerts. The type chosen should have the status color that corresponds to
the severity of the event or condition.
Recommended
Create new symbol alert graphics for notification only if the event or
condition is of a very special type and requires the user to recognize it as
different from the other notifications that they will encounter. See the
The Integration Series: HP OpenView Windows Developers Guide for
information on creating new symbol alert types.
Recommended
If there are multiple different alarms associated with a single object that
would result in a symbol alert, adhere to all of the following guidelines:
Display only a single symbol alert in conjunction with the symbol for
the object. The multiple alarms should all be associated with this one
symbol alert.
Display the symbol alert with a severity that corresponds to the most
severe alarm condition.
Example 8-3
Example:
If there are two alarms associated with a given symbol alert, one with
minor severity and one which is critical, the symbol alert should be
red to show the critical severity.
Use the pop-up menu associated with the symbol alert to provide the
users with a means of viewing all of the alarm conditions that led to
the symbol alert.
Recommended
While the symbol alert is visible and has not been deleted, users can be
notified about duplicate alarms by presenting a number to indicate the
number 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 has
responded 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 what
actions can be taken.
Chapter 8
261
Visual Presentation
Symbol Alerts
Execute an action that will allow the user to immediately respond to
the source of the alert.
Result in the presentation of a view of the object whose condition
resulted in the symbol alert. This view should allow the user to take
direct action to fix the problem.
Example 8-4
Example:
A symbol alert on a location icon opens a submap for the card drawer
on a switch. At this level users can identify the card with the problem
and use the menu items to take action.
Recommended
If a symbol alert has multiple alarms or multiple actions associated with

it, it should provide a pop-up menu, see Figure 8-3.
Recommended
The pop-up menu associated with symbol alerts should adhere to all of
The default action that would be executed by double clicking on the
symbol alert should be the first item in the pop-up menu.
The pop-up menu should provide access to a textual message
describing the condition that led to the alert.
The menu should provide access to actions that the user can take to
fix the condition that led to the alert.
The menu should provide access to views of the object whose
condition led to the symbol alert.
If there are multiple alarms associated with the symbol alert, the
menu should provide access to information on what the various
alarms are and should allow the user to chose the sequence of trying
to handle these problems.
The menu should allow acknowledgment of the symbol alert.
Acknowledgment of the symbol alert should cause the symbol alert to
be deleted and should prevent the display of additional symbol alerts
resulting from the same or duplicate alarm conditions, whether or not
the problem was fixed by the user.
262
Chapter 8
Visual Presentation
Symbol Alerts
Figure 8-3
Pop-up Menu Associated with Symbol Alerts
Chapter 8
263
Visual Presentation
Text Annotation for Symbols
Text Annotation for Symbols

This feature is supported for applications on HP-UX and Solaris only.
Text annotations can be superimposed over object symbols, connection
symbols and symbol alerts. When using text annotation strings, adhere
to the following guidelines:
Required
To minimize display clutter, text annotation on icon or connection

symbols must be provided only through configurable parameters or as a
result of a user action.
Users should be able to configure text annotation to be displayed on
an ongoing basis as interesting events occur. For example, a systems
management application could allow users to configure which events
are automatically announced to the user through text annotation (for
example, system reboot, user added, file system down, IP address
change).
Users should be able to use menu items to request the display of text
annotation on a single instance basis. For example, an application
could provide a menu item that allows users to display text
annotation showing the bandwidth of a connection and the amount of
the capacity that is available for use.
Required
If your application provides text annotation through configurable

parameters or as a result of user actions, it must provide a means for
users to turn off the text annotation.
Users should be able to configure the application so that text
annotation is not displayed on an ongoing basis.
Users should be able to use menu items to clear text annotation on a
single symbol and on all symbols within the submap.
Recommended
It is recommended that text annotation be provided in symbol alerts

presented in the results pane.
The text annotation should give a brief indication of the nature of the
alarm that has produced the symbol alert. This use of text annotation in
symbol alerts does not require that you allow the user to control the
presentation of the annotation, but it should follow the guidelines for
symbol alerts.
264
Chapter 8
Visual Presentation
Highlighting Symbols
Highlighting Symbols
One of the visual cues defined for HP OpenView is the highlighting of
symbols. Highlighting of an object symbol results in the inverse video
appearance of the symbol label. Symbol labels generally include black
text on a white background. The label of a highlighted object symbol
appears as white text on a black background. Highlighting of a
connection symbol is presented as the overlaying of the symbol with a
distinctive 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 applications
integrating into NNM).
Recommended
To help users visually locate objects identified as a result of an

application operation. For example, identify the client systems that will
be affected when the user disables a print server.
Recommended
To help users visually locate connections or relationships that are

identified as a result of an application operation. For example, the
identification of a network path resulting from the Find Route menu
item.
Optional
To guide users to objects in computer based training for an application.
Required
Highlighting must not be used for conveying information about the

status conditions for an object or for notifying users of alerts.
Recommended
Each new access of a highlight command should replace the currently

highlighted items with a new set of highlighted items.
Required
If you allow users to append new highlights to the list of highlighted

items, you must label the command Add to Highlighted.
Chapter 8
265
Visual Presentation
Flashing Symbols
Flashing Symbols
Developers to cause symbols to flash, and to turn off this flashing. If
flashing symbols are used in the application adhere to the following
guidelines:
Required
Flashing should be used only for high severity conditions where users
must handle the condition immediately; generally this is when the
symbol has a status of major or critical.
While useful for attracting the users attention, flashing can be annoying
and stress producing. If over used, this visual cue can interfere with user
performance.
Required
If flashing symbols are used in the application, users must have a means
of 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 high
severity condition.
If flashing is turned off, your application must have another mechanism
for notifying users of the high severity condition; for example, status
color, symbol alerts, or text annotation.
Recommended
If an application uses flashing symbols, it should provide menu items

that allow the user to acknowledge the condition and thereby turn
flashing off for that particular symbol.
The pop-up menu associated with the symbol and the View menu in the
menu bar are the recommended locations for this functionality.
266
Chapter 8
Visual Presentation
Transparent Symbols
Transparent Symbols
When assigning symbols to objects, you can choose to present the
symbols with a class background shape or as transparent symbols that
do not have a class background shape. Transparent symbols do not
display their background shape and status color as long as the object
associated 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 a
developers setting for symbol transparency.
Use the following guidelines in determining if objects should be
presented 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 below
minimum graphic size of 16x16 pixels.
In NNM, symbols are resized to sizes smaller than 16x16. When the
symbol goes below the minimum graphic size, the bitmap is replaced
by an empty class shape. As a result, transparent symbols are not
recommended for use in the content area of applications based on
NNMs scaling algorithm.
Required
Do not use transparent symbols in the following situations:

As a specific visual cue associated with a condition or state in an
object other than normal.
The presence or absence of a background class shape is a very subtle
cue and it is unlikely that users will attend to this cue.
In addition in NNM, users have the ability to override transparent
symbol appearance. If this visual cue is disabled, the application may
not function as intended.
If the symbols being used will be presented on the same view(s) as
symbols from other applications that use symbols with class shapes.
Chapter 8
267
Visual Presentation
Transparent Symbols
The mixture of different types of symbols in the same view will be
confusing to users.
If the view containing the object symbol will be resized to a point
where the graphic will no longer be visible.
The change from a graphic without a background shape to one with a
background shape with no graphic will be confusing to users.
If users will need to differentiate between the different classes of
objects to accomplish their management tasks.
The class of the object is visually represented by the background
shape. When transparent symbols are used the visual cue for the
object class is not available.
If users will want to use drag and drop and the transparent symbols
are presented through HP OpenView Windows.
In HP OpenView Windows, the hot spot for the symbol is defined to
include the space that would be occupied by the class shape. Symbols
for objects can partially overlap. When the symbols are transparent,
it is impossible for users to determine which symbol is on top. This
lack of visible symbol boundaries may cause users to make errors
when dragging and dropping.
268
Chapter 8
Visual Presentation
Executable Symbol Appearance

By default executable symbols in HP OpenView applications are
surrounded by a box that makes them appear as push buttons that the
user would use to execute an action.
For applications integrating with NNM, developers have the ability to
specify whether the visual cue for an executable symbol is present or not.
End users have the ability to override the developers setting.
Recommended
While executable symbols are allowed, it is recommended that

application provided functionality be provided through configurable
toolbar buttons, instead of through executable symbols.
Required
If executable symbols are used, the symbols should be presented with the
default executable symbol appearance (that is, box around symbol) if any
of the following are true:
The executable symbol is being used to provide quick access to
application functionality (such as the presentation of an application
tool, graphed data, etc.).
The intent is for users to execute actions on objects by dragging and
dropping other symbols on to the executable symbol.
Recommended
If executable symbols are used, the executable symbol appearance

should be removed (that is, make the symbol appear explodable) if any of
the 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 objects
that are displayed when the user double-clicks on the symbol (for
example, double-clicking on the symbol leads to a list of the software
that is currently loaded on the system, the list provides a view with a
tabular format).
Required
If the executable symbol looks executable it must act executable.

Users should recognize the result of double-clicking on the symbol as
the execution of an action or command.
Chapter 8
269
Visual Presentation
Objects dropped on to the symbol during a drag and drop operation
must be acted on as if they were the selection list for the executable
action.
Required
If the executable symbol looks an explodable symbol (a symbol that

opens to show the view of the objects contained within it), it must act
explodable.
Users should recognize the result of double clicking on the symbol as
the opening of a view or a submap into a container object.
Objects dropped on to the symbol during a drag and drop operation
should be added to a lower level view and should be visible to the user
when the symbol is opened.
270
Chapter 8
Visual Presentation
Partially Filled Connection Symbols

For all connection symbols with a width of greater than three pixels, you
can control the appearance of the connection symbol so that it appears
empty, partially filled, or completely filled.
By default the connection symbols presented through HP OpenView
Windows will appear completely filled (that is, percent fill equal to
100%). Developers can dynamically change connection symbol fill to a
value between 0% and 100%.
Using HP OpenView Windows for creating partially filled connection
symbols, 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 used
to present the borders of the symbol and the amount of the connection
that is filled; by default this is black (normal status).
The secondary status. Secondary status is used to present the unfilled
portion of the connection symbol; by default this is transparent. The
transparent appearance is the normal status color for the secondary
status. In setting the color for the secondary status, developers can
only specify the state associated with the secondary status. This state
is then translated into the appropriate color based on the status.
If the connection symbol has 0% fill, it will appear as having a border in
the primary color and it will be transparent and show the underlying
background between the two borders. If a connection symbol has 100%
fill it will appear as single line or patterned line presented in the primary
color. If a connection symbol has a percentage fill between these values
(that is, uses partially filled connection symbols) and it is of sufficient
width to display the differences, the connection symbol will appear to
have two different horizontally aligned areas, one for each of the status
colors.
If partially filled connection symbols are used, adhere to the following
guidelines. These guidelines are intended to assure consistency in the
way partially filled connection symbols are used and to help users
develop a meaningful conceptual model.
Required
Partially filled connection symbols must only be used to provide users

with information on the status, use and available capacity of connections.
Chapter 8
271
Visual Presentation
When defining percentage fill for the connection symbol:
Required
The percentage fill should represent the percentage of the capacity in

connection that is currently being used.
Required
The area displayed in the secondary status color should represent the
amount of the capacity that is available for use.
Recommended
When the line is down, the percent fill should be 100% to indicate that
none of the capacity is available for use. The status color for the
connection should be consistent with the state (for example, critical).
Recommended
The primary status color for a connection symbol should indicate the
quality 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 empty

portion of the connection. However, if an application chooses to present a
status color in the empty portion of the connection, the status
information should be aimed at giving warnings about capacity.
Generally this color should be transparent. As the connection starts
running 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 identify
different fill percentages and act on them.
Recommended
The number of different fill percentages used should be minimized; for

example, 0, 25, 50, 75, and 100 are recommended.
Recommended
The manner in which connection symbol fill is used should be consistent

across all connection symbol subclasses within a class.
Recommended
Consider providing a menu item that will display a numeric value for the
used and/or available capacity for a connection. The results of this item
could be presented in a dialog box or as text annotation on the
connections themselves.
272
Chapter 8
Dialog Boxes and Controls
273
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
274
Chapter 9

Dialog Box Design
Dialog Box Design

Dialog boxes are used for requests for information from the user or to
support user tasks that require detailed interaction from the user and do
not lend themselves well to direct manipulation in your main application
window. This section presents general guidelines for you to follow when
designing dialog boxes for your application.
Title Bar
The content of the title for dialog boxes will vary depending on the
purpose 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 bar
should be presented in abbreviated form. Include the <objectname> only
if there is only one object. Include the <toolname> only if there are
multiple tools associated with an application. The <actionname> should
be associated with the menu item that led to the dialog box.
Table 9-1
Recommended Dialog Box Title Formats
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
Focus
The initial focus of a dialog box should be based on what actions are
required of the user. Provide visual cues to guide users in their tasks; for
example, use the location cursor or the text cursor.
Chapter 9
275

Dialog Box Design
Upon initial invocation of a dialog box, the following guidelines are
either 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 at
the most likely point of modification; the beginning of an empty field and
the end of a field already containing text.
Recommended
Text cursors should not appear in every modifiable text field. Only one
text cursor should be visible at a time.
Recommended
Use cursors to indicate the field that has keyboard focus, and provide
visual cues to guide users in their tasks.If the choices available in a given
field are dependent on the value assigned to a prerequisite field, then do
one of the following:
Place the prerequisite field above dependent fields to encourage users
to input data in the prerequisite fields first.
Display only the prerequisite field and wait until the user assigns a
value to it before displaying the fields or options that are dependent
on that value.
Menu Bars
Recommended
Do not use menu bars in dialog boxes.
Fonts for Dialog Boxes and Windows

To 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 level
font specifications (that is, VUE, Windows NT operating system).
Recommended
When using a different font size than that set by the users environment,
consider the effect of display size and resolution on the readability of the
fonts. As display resolution increases (for example, 800 x 600 to 1280 x
276
Chapter 9

Dialog Box Design
1024) the size of the characters presented in the display appear to shrink
in size.
Test the readability of your smallest fonts on the smallest monitor
with the highest resolution that is anticipated to be used by your
customers (for example, 19 inch 1280 x 1024 monitor).
Provide users with a means of changing the font size to a size that
will better fit their needs.
Default Size for Dialog Boxes and Windows

Applications need to carefully consider the default size of the dialog
boxes and windows that they present to the user. Because of the
interaction between display sizes, display resolution and the size of
dialog boxes and windows, it is possible to create windows that are too
large to be presented in the users display or that are hard to use because
the controls are too small. Consider the following guidelines when
choosing the default size for your dialog boxes and windows.
As display resolution decreases (1280 x 1024 to 800 x 600) the size of a
dialog box or window appears to increase, and there is a corresponding
decrease in the amount of available display space.
As display size decreases at a given resolution (for example, 19 inch to 13
inch monitor with resolution of 800 x 600), the amount of available
display space decreases.
To assure an appropriate default size for your windows, dialog boxes and
their controls, follow these guidelines.
Required
Test the default size of the largest application windows on the smallest
monitor with the lowest resolution that is anticipated to be used by
customers (for example, 13 inch 800 x 600 monitor). Make sure that the
whole window and all of its controls fit easily into the display. Make sure
to test the application using a font size that will also be readable on the
highest resolution monitor used by customers (for example, 1280 x 1024
monitor).
Required
Test the default size of the smallest application controls on the smallest
monitor with the highest resolution that is anticipated to be used by
customers (for example, 13 inch 1280 x 1024 monitor). Make sure that
there is adequate distance between controls and that all controls can be
easily activated without error.
Chapter 9
277

Dialog Box Design
Resizing Dialog Boxes and Windows

Users generally resize dialog boxes and windows with specific goals in
mind. They become frustrated when the results of the resize operation
does not meet their goals.
Recommended
The following user goals should guide the resize behavior for the dialog
boxes 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 the
most important information in the window or dialog box, otherwise
they would iconify the window.
Panes in Resized Windows
When a user enlarges or shrinks a window or dialog box that has
multiple visible panes, they typically do not want to resize only one pane.
They would like the resize operation to affect all panes. Users also want
to make choices between which pane will get the most space.
Recommended
Panes should be implemented so that resizing of the window or dialog

box affects all panes in the window that would benefit from the resize
operation.
Benefit is defined as allowing the user to show more data in an enlarge
operation or preventing the loss of user controls in a shrink operation.
Recommended
Controls for resizing window panes should be provided when users will
benefit from differential sizing of the panes.
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 the
dialog box, from the F1 key for context sensitive help, or from a question
mark in the title bar of the dialog box for whats this help.
278
Chapter 9

Dialog Box Design
NOTE
When an application runs on a Windows Platform, help information can

also be accessible from the ? in the title bar.
General Guidelines for Controls in Dialog Boxes

Sequencing of Controls within the Dialog Box
To match the users 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 specific
fields, put the fields used as prerequisites for the default values above
the fields for which defaults are derived.
Place mandatory fields that must be completed by the user at the top
of the dialog box, with optional fields or fields with default values
lower in the dialog box.
Group fields associated with a single concept together.
For example, in a dialog box for printer configuration, all fields
associated with hardware switch settings should be presented
together.
When other constraints have been met, sequence fields to minimize
the number of changes between input devices. Whenever possible,
follow text fields with other text fields so that users do not need to go
back and forth between the mouse and the keyboard.
Alignment of Fields
In dialog boxes containing multiple fields, provide the viewer with an
obvious and efficient scanning and handling sequence. Eye and mouse
pointer movements should be minimized, direction of movement should
be obvious, and a consistent and predictable pattern must be followed.
This is best achieved when labels and fields are aligned in columns.
Recommended
Align fields in vertical columns (typically one to three per row).

In some cases, dialog box constraints may dictate a horizontal
orientation of controls.
Chapter 9
279

Dialog Box Design
Control Labels
The labels used for controls have a direct impact on how easy or difficult
it is for the user to do their tasks. The labels provide implicit user
guidance which instructs the user on what options are available and
what 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 be
meaningfully stated in terms and relationships that the user is likely to
understand.
Recommended
The capitalization of labels for controls should be based on the type of

control, unless the words in the label have a conventional usage that
dictates their capitalization:
Push buttons and tabs should have the first letter of each word
capitalized unless the word is an article or preposition.
Labels for radio buttons, check boxes, text boxes, combo boxes, spin
boxes, sliders, gauges, tables, grids, and group boxes should use
sentence-style capitalization with only the first letter of the first word
capitalized.
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 it
precedes the option button.
Visual Cues in Labels
Provide visual cues to indicate the state and type of action of controls.
Required
Gray buttons that are not available.
280
Chapter 9

Dialog Box Design
Required
Place an ellipsis (...) after the label on buttons that lead to a dialog box to
which the user must respond before an action can take place.
NOTE
Ellipses should not be used in labels simply because the command

results in the presentation of a new window. If the new window provides
the requested functionality, for example, view of data, no ellipsis is
required. If the new window is used to obtain desired options before the
action is carried out. For example, print options dialog, then an ellipsis
should be used on the control.
Required
Do not place any symbols after the label on buttons that lead to an
immediate action (sometimes known as command buttons).
Recommended
Provide a clear indication of which fields in the dialog box require user
input (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 enter
comments should be (Comments:).
Label the fields with mandatory and optional.
Required
Place two arrows ( >> ) after the label on the button that leads to the
expansion of a window to display a previously invisible pane. The arrows
should indicate the direction of the expansion of the window.
To aid the user in understanding the functionality of the button, it is
good to provide a textual label, such as More>>.
General Guidelines
Complexity in dialog boxes should be appropriate for the task
Recommended
If a dialog box supports basic functionality, as well as advanced,

auxiliary or less frequently used functionality, it should use one of the
following methods to reduce the complexity. The methods are listed in
order of preference:
Chapter 9
281

Dialog Box Design
Additional dialog boxes with advanced, auxiliary, or less frequently
used functionality, accessible via controls within the higher level
dialog boxs.
A multiple page dialog box, with advanced, auxiliary or less
frequently used functions on later pages.
An expandable dialog box to present the advanced, auxiliary or less
frequently used functionality.
Recommended
Dialog box expansions and additional dialog boxes should be restricted to

functions that are used by only a subset of the users and are not needed
for typical execution of a task.
Recommended
If beneficial to task performance and if the form structure is complex, an

overview of the form structure or a visual presentation of the structure
should be provided to users.
Recommended
Unless it is necessary for command completion or if it is important to

prevent further interaction until a condition is satisfied, modeless rather
than modal dialog boxs should be used.
Default Values
Default values are the values that are set by the application so that they
appear as the initial settings for controls when users access them for the
first time. Default values reduce task time by minimizing the number of
fields the user needs to complete, and by providing examples of valid
entries that users can modify. Providing good default values will
minimize the need for users to do extensive customizing prior to use of
the application. Users should not be required to provide any information
that the application can supply for itself.
Recommended
Provide default values for each control in the dialog box unless a default
would lead to destructive consequences or to user errors.
Recommended
Default values should be chosen to support the users task, all of the
following guidelines should be adhered to when choosing the default
values:
282
Chapter 9

Dialog Box Design
System default values should not be destructive (that is, lead to the
loss of data) nor should they lead to undesirable time consuming
activities.
In a single selection list box, the initial default selection should be
either the item most likely to be selected or the first item in the list
In a multiple selection list box, the default selections should include
the set of items most likely to be selected by the user.
In a group of radio buttons, the default choice should be the button
most 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 be
entered by the user.
The initially displayed choice in a stepper button should be the most
logical default choice (that is, the most likely to be selected).
For example, if the user opens a report in a directory and the user has
not previously accessed the save dialog box, that directory in which
the report was opened should be the default directory for saving the
report.
Recommended
If default values are likely to vary across customers but remain

relatively consistent across the tasks of a specific customer, methods
should be provided to allow customization of default values.
Recommended
If it is likely that retaining values set by an individual user will

minimize user steps or the need for changes in field values, user settings
should be presented as the default values the next time the dialog box or
form is accessed.
NOTE
In network, systems and service management, customized defaults are

typically set on an organizational basis rather than on an individual user
basis.
Recommended
If it is not likely that users will want to retain their previously set
values, application specified defaults or customized defaults should be
Chapter 9
283

Dialog Box Design
presented as the default values the next time the dialog box or form is
accessed.
Recommended
If an application allows customization of default values, some means

should be provided to allow users to return the settings to the application
defined default values.
NOTE
The default values that are used for fields in the dialog box or form can
be a combination of previous user values, user configured values and
system default values. For example, in a print dialog box, the default
printer could be set to the last printer selected by the user, however, the
format of the printout could be that defined by the application for the
report that is being printed.
Recommended
If there is a default for a control or field in a dialog box, the default value
should be visible when the field is first presented or as soon as sufficient
information is available for the application to set the default value.
Recommended
Default values for text boxes and combination boxes should be editable
by the user using conventional editing commands.
Input Validation and Error Handling

Input validation and error handling can have a major affect on user
performance.
Recommended
If possible, perform input validation and error handling on a

field-by-field basis while the dialog box that initiated the action is still
up.
For example, if an application prompts for a file name and the file needs
to be present before continuing, then keep the dialog box visible until
either a valid file name is entered or the user selects the [Cancel]
button. Requiring users to reinitiate an action (for example, from the
menu bar) causes extra user steps and time loss.
Default Actions
Default actions result from the user pressing the Return or Enter key, or
by double-clicking on an item, symbol, or control. Following are general
284
Chapter 9

Dialog Box Design
guidelines for the use of default actions, additional guidelines specific to
individual 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 the
Return or Enter key when the location cursor is in a specific field. For
example, if the location cursor is in a text field for string search, the
most 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 text
field. Pressing the Return or Enter key activates this button.
To guide user task steps. If users are required to perform a specific
sequence of steps, default actions can be used to guide these steps.
To perform a nondestructive action. A destructive command, such as
delete, should not be used for a default action.
To minimize user time. Default actions should not lead to
time-consuming events that users may or may not have wanted to
occur. 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 input
field. In simple dialog boxes, the primary user interaction is provided by
specific push buttons, such as [OK], [Cancel], or [Close]. Dialog
boxes with multiple input fields are more complex, and user interaction
is carried out by the use of various controls in the dialog box. The role of
the [OK] and [Cancel] push buttons is to signal a close to the users
interaction. Because of the different interaction styles in these two types
of dialog boxes, there are different guidelines for default actions.
Recommended
In simple dialog boxes with no input fields or only one input field, both of
the following guidelines should be followed:
One of the push buttons, [OK], [Cancel], or [Close], should be
defined as the default action when the user first enters the dialog box.
The the choice of default action should be based on which action
would be the safest for the user.
Recommended
In dialog boxes with multiple input fields:

Actions that close the dialog box (for example, [Ok] or [Cancel])
should be the default action only when one of the following is true:
Chapter 9
285

Dialog Box Design
The dialog box is first entered and no input has been given, and no
navigation has taken place.
The location cursor on one of the push buttons that close the
dialog 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 the
dialog box.
The default action should be based on the most likely user action
at a given location.
If the location cursor is on the last field in the dialog box before the
exiting push buttons, and the user will not need to review the
values in the dialog box, the default action should be to activate a
push button to close the dialog box.
286
Chapter 9

Guidelines for Controls

Apply the following HP OpenView-specific recommendations, as well as
any guidelines associated with the platform that your application
supports, 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 modify
the guidelines for size, placement, and fonts accordingly.
Push Buttons
Recommended
A push button is recommended when most or all of the following

conditions are met:
The desired result is the execution of an action or the setting of a
state.
There is a need for quick access.
There is a need for high visibility.
Chapter 9
287

Figure 9-1
Push Buttons
Required
Limit the use of push buttons in presentation managers and the primary
application window. Provide access to commands or operations through
the toolbar, through pull down or pop-up menus, or by executable
symbols.
Placement
Follow the general guidelines for the placement of controls presented in
this chapter under General Guidelines for Controls in Dialog Boxes.
Also follow the specific guidelines for push buttons presented in this
section.
NOTE
The recommendation for the placement of the push buttons need to be

modified for localization for different countries.
Push buttons may be placed at the bottom of the dialog box or in the
main portion of the dialog box.
Required
If a push button is applicable to a dialog box as a whole, place it at the

bottom of the dialog box.
Recommended
To improve the visual appearance of the dialog provide some type of

separator between the push buttons at the bottom of the dialog and the
other 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 dialog

box or window in the pane where they are applicable. This is particularly
true for complex screens where it may be difficult for users to determine
the effect of the button.
Required
Place push buttons applicable to a list to the right of the list to which
they apply. Vertically align the left side of each push button.
288
Chapter 9

Recommended
Sequence push buttons that select and act on items in a list at the top of
the set of buttons, for example [Open]. Place buttons that modify and/or
delete items in a selection list at the bottom of the set of buttons.
Recommended
Push buttons placed at the bottom of the dialog box should be aligned
starting at the right side of the window.
Recommended
The distance from the window or dialog box border to the edge of the
button 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, or

5 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 to

accommodate the required number of push buttons when there are large
differences in the size of the labels; for example, in the words OK
versus Cancel, make the buttons as close in size as possible without
compromising the appearance of the longest label.
Labels and Definitions
Follow the general guidelines for the labeling of controls presented in
this chapter under General Guidelines for Controls in Dialog Boxes.
Also follow the specific guidelines for push buttons presented in this
section.
Required
Table 9-2 outlines the labels and definitions that are required for push
buttons in HP OpenView applications.
Chapter 9
289

NOTE
Do not label buttons at the bottom of the dialog box or window with the
word [Exit]. [Exit] should be reserved for exiting the HP OpenView
application or HP OpenView environment as a whole. Cognitively, users
view the completion of a dialog box as simply closing the window in
which the dialog box is presented.
Table 9-2
Labels and Definitions for Push Buttons
Key
Action
[Yes]
Applies an affirmative response to the question in the dialog box and closes the
dialog box.
[No]
Applies a negative response to the question in the dialog box and closes the dialog
box.
[OK]
Validates the user-specified action in the dialog box, and closes the dialog box. If
appropriate, saves changes in the dialog box.
[Apply]
Applies operation of the dialog box with the current settings. This includes any
changes in the dialog box. The [Apply] button should be grayed when the dialog
box is first accessed. It should be made available as soon as the user makes any
change in the dialog box.
[Reset]
Cancels any user changes that have not been applied. Also resets the status of the
dialog box to its initial state. Users can undo changes by doing 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 actions that has not
been previously applied. [Cancel] closes the dialog box. The [Cancel] button
should be available when the user first accesses the dialog box.
[Close]
Closes the dialog box without performing any actions in the box. If the dialog 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 when its text input
field or list of selections is empty.
290
Chapter 9

Table 9-2
Labels and Definitions for Push Buttons
Key
Action
[Delete]
Deletes the items from the list. In some cases this will result in a deletion from the
application. This button should be grayed when its list of selections is empty.
[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 be combined
with Describe as in [Describe/Modify].
[Properties]
Presents a dialog box that indicates the properties of an object or application and
allows the user to change modifiable fields.
Visual Cues
Required
Provide visual cues for the availability of push buttons. If a button is not
currently available for use, gray the label for the button. If a button is
never available for use, it should not be presented in the dialog box.
Examples of when specific push buttons should be grayed are presented
in Table 9-3.
Table 9-3
Guidelines for Showing Buttons as Unavailable
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.
Default Action
Follow these guidelines and the guidelines in Default Actions on page
284 when assigning default actions to push buttons.
Chapter 9
291

Required
If the location cursor is on a push button, the default action should be to

activate the push button under the location cursor.
Required
If the location cursor is in a single line text field and there is a push
button associated with the text field, the default action should be to
activate the push button, and the location cursor should remain in the
text field.
Required
If a push button is associated with the default action, it must have a

visual 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 when

the user presses ALT - F4. If the dialog box includes a [Cancel] button, it
should be selected when the user presses ESC. On some systems, this
may be handled automatically.
Option Buttons
An option button produces an option menu from which the user can
choose a single item. Option buttons are available only in UNIX. For
applications 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 the

following conditions are met:
292
Chapter 9

The desired result is the making of a selection or the setting of a
state.
Choices are mutually exclusive.
The application will primarily be used on UNIX or a different control
will be substituted when the application is presented on other
operating systems.
There is limited display space.
Users need to see only the item that is currently selected, except
when changing the selection.
There are more than 2 items or the number of items may change over
time.
All applicable items can be identified by the application.
NOTE
If some, but not all, valid options are known, use a combination box in
place of an option button.
Placement and Labeling

Follow the general guidelines for the placement and labeling of controls
presented in this chapter under General Guidelines for Controls in
Dialog Boxes. Also follow the specific guidelines for option buttons
presented in this section.
NOTE
The recommendation for the placement of the option button and its
labels may need to be modified for localization for different countries.
Recommended
If the content of the option menu is not appropriate given the current
state in the window or dialog box, the labels both inside the button and
next to the button should be grayed.
Recommended
Place the label that defines the use of the button to the left of the button
to which it applies, as shown in Figure 9-3. The label for the value set for
the control should be shown on the button itself.
Chapter 9
293

Default Actions and Values
Recommended
If the location cursor is on a menu item within the option button, the
default action should be to accept the menu item as the value for the
control and move the location cursor to the next control.
Recommended
The default value for an option button should be the choice most likely to
be selected by users.
Radio Buttons
Radio buttons can be used in dialog boxes, panes of windows, or in
menus. Radio buttons occur as a set and allow for the selection of a single
alternative within the set. Radio buttons are sometimes referred to as
option or toggle buttons.
Figure 9-4
Radio Buttons
Recommended
The use of a radio button is recommended when most or all of the

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 or
fewer).
Users need to quickly see which option is currently selected.
Users will benefit from simultaneously seeing all of the alternatives.
294
Chapter 9

Dialog Boxes. Also follow the specific guidelines for radio buttons
NOTE
The recommendation for the placement of radio buttons, their headers

and labels may need to be modified for localization for different
countries.
Required
Label the header for a set of radio buttons to indicate the variable that is
being 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 when
the 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 vertically

aligned:
The state indicator buttons should be vertically aligned.
The labels for the indicator buttons should be left aligned relative to
one another.
If radio buttons are on the left side of a window, left align all state
indicator buttons no less than 1/3 inch and no more than 1/2 inch, or
14 base dialog units, from the inside edge of the window border.
Vertically aligned radio buttons are easier for users to scan than
horizontally 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 evenly
spaced 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 to

change the selection state of the radio button, and move to the next field
after the set of radio buttons.
Chapter 9
295

Recommended
The default value for a set of radio buttons should be the choice most
likely to be selected by users.
Check Box
A check box is a toggle control in which the user makes the logical choice
between A and Not A. In groups of check boxes, each check box
represents an independent choice. However, check boxes are most
obvious 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 following
conditions 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 is
selected or not selected.
Dialog Boxes. Also follow the specific guidelines for check boxes
NOTE
The recommendation for the placement of the check box and its label
may need to be modified for localization for different countries.
Recommended
If a set of check boxes are grouped together under a header, the header
label for the group should indicate the category of variables that are
being 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 being
toggled on or off.
296
Chapter 9

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, all
check boxes within a window should be grouped together and vertically
aligned:
When check boxes are vertically aligned, the indicators should be
aligned 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 state
indicator buttons no less than 1/3 inch and no more than 1/2 inch, or
14 base dialog units, from the inside edge of the window border.
Vertically aligned check boxes are easier for users to scan than
horizontally 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 be
evenly spaced across the width of the window or pane.
Required
If the location cursor is on a check box, the default action should be to

change the selection state of the check box and move to the next check
box in the group, or to the next field if there are no more check boxes in
the group.
Recommended
On initial presentation, each check box should be set to the value that
would most likely be selected by the user.
Text Boxes
Text boxes are controls that present textual data, or fields into which the
user can type characters from the keyboard. Text boxes can be combined
with menus, lists, and other selection mechanisms, such as the radio
buttons, to allow users increased flexibility with ease of use. Examples of
variables that can best be presented in text boxes are names, comments,
and locations.
Chapter 9
297

Figure 9-5
Single and Multi-line Text Boxes
Recommended
The use of a text box is recommended when most or all of the following
conditions are met:
The desired result is the providing unspecified information, making of
a 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).
Dialog Boxes. Also follow the specific guidelines for text boxes presented
in this section.
NOTE
The recommendation for the placement of text box and its label may
need to be modified for localization for different countries.
Recommended
Label text boxes to clearly indicate the purpose and meaning of the
control. Include valid ranges in labels where appropriate; for example,
Page Width (60-120).
298
Chapter 9

Recommended
Place labels above or to the left of the text box.
Required
If there is a wide variation in the length of labels, place labels above the
text box.
Labels above text box allow for easier localization.
Required
If labels are placed above text boxes, align the left edge of the first
character 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 left
edge of the text field.
Required
If there are multiple rows of text boxes, vertically align the boxes of these
fields.
General Guidelines
Required
Users should be able to discriminate between read-write text boxes and

read-only text boxes, see Figure 9-5 for an example.
Read-only text boxes should have the same background color as the
background of the dialog box.
Read-write text boxes should have a different background color than
the background of the dialog box.
Recommended
Users should be able to use the operating system-provided copy/cut and

paste methods to cut and paste text strings into text boxes.
Recommended
The location of the text cursor when a text box is first given keyboard
focus should support the users task:
If the task flow indicates that a portion of the text in the box is most
likely to be modified, then the text cursor should be placed at the end
of that portion.
Example: A server and its fully distinguished name are displayed in
a text box. The text cursor is placed at the end of the hostname, before
the domain name, as this is the portion of the name most likely to be
changed.
If the task flow indicates that no specific portion of the text is most
likely to be modified, the text cursor should be placed at the end of the
text in the box.
Chapter 9
299

NOTE
If the entire text is selected for replacement it is possible that the text
cursor will not be shown.
Recommended
If the users task will typically require the replacement of all rather than
a portion of the text in a text box, the entire text should be selected for
replacement when the user first enters that text box.
If the user enters information into the text box, the previously
selected text should be replaced with the new text.
If the user leaves the text box without entering new information, the
text 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 characters
equal to one line or less.
Users should not be able to press the Return key and get a new line
within a single line text field.
Required
If users can enter multiple lines of text into a single text box, make the
default size of the text box show multiple lines (that is, two lines or
more).
Recommended
Text boxes should be large enough to accommodate the majority of

anticipated entries without scrolling.
Recommended
If the variable associated with a text box has a specified number of

characters that the user can enter, make the length of the text box equal
to 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 correctly
specifying 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 that
the text box will appear to be filled when the maximum number of
characters has been entered into the box.
300
Chapter 9

It is confusing for users to receive an error indication when trying to type
into a text box where the visual cues indicate that more characters can
be entered.
Optional
Single-line text boxes can scroll if there is more information in the box
than can be viewed within the visible area of the text box.
Recommended
Provide vertical scroll bars for multiple line text boxes, only after the
user has entered more lines of text than can be viewed within the visible
area 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 push
button associated with the text box, the default action should be to
activate the push button. The location cursor should remain in the text
box.
Recommended
If the location cursor is in a single line text box and the text box does not
have an associated push button, the default action should be to move to
the next input field, if one exists.
Recommended
If the location cursor is in a multi-line text box, the text cursor should
move to the next line in the text box when the user presses Enter. The
location cursor should remain on the text box.
Recommended
Whenever possible, provide a default value for text boxes. The default
value 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 a
indication of the format required for the entry.
Recommended
If there is no meaningful default value can be provided for a text box, the
box should be empty.
Combo Boxes
Combo 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 text
field in which users can enter data. Drop-down combo boxes present only
the text field until the user takes an action to present the list.
Chapter 9
301

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 following
conditions are met:
There is limited display space.
Users need to see only the item that is currently selected, except
when changing the selection.
There are 5 or more items to choose from or the number of items may
change over time.
Users may be able to type the entry more quickly than they can select
it.
The control is used as part of a keyboard intensive task.
Users may have to type values that cannot be supplied by the
application.
Recommended
Use drop-down combo boxes to replace option buttons from Motif when
running on the Windows NT operating system.
Dialog Boxes. For specific guidelines on the labeling and placement of
combo boxes see Text Boxes.
302
Chapter 9

General Guidelines
Recommended
If combo box list does not present an exhaustive list of all valid
alternatives, allow the user to type values that are not currently in the
list. 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 combo
boxes where the list is always available.
Recommended
Combo boxes should provide automatic searching of the list entries based
on the characters that the user types into the text box. This aids users in
searching for items in long lists and allows for consistency across all
combo boxes. Searches should take into account all characters typed by
the user, not only the first character.
Required
When combo boxes are used they should provide the same visual cues
that are recommended for text controls and for list boxes (see Text
Boxes and List Boxes).
Recommended
If the location cursor is on the text box portion of the combo box, the
default action should be to check the entry in the text box, and if it is
valid, move to the next field. If the entry is not valid, an error message
should 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 be
chosen by users.
Spin Boxes
A spin box is a control with a text box and up and down arrows that the
user clicks to move through a fixed set of values. Users can also type
valid inputs into the text box associated with the control.
Recommended
The use of a spin box is recommended when most or all of the following
conditions are met:
The desired result is the making of a choice or setting of a state.
There is limited space.
Chapter 9
303

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.
Dialog Boxes. Also follow the specific guidelines for spin boxes
NOTE
The recommendation for the placement of the spin box and its label may
Required
Unless the values inside the spin box make the purpose of the spin box
intuitively obvious, each spin box should have a label to indicate
particular variable that is being incremented or decremented by the spin
box. 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 above
the spin box.
Optional
If it will benefit the user, place labels identifying units for variables
inside the spin box or to the right of the spin box.
Recommended
The mapping between the labels on the buttons and the direction of
change in values should be consistent with user population conventions.
304
Chapter 9

Example 1: Data are consistently sequenced so that using an up arrow
increases the value for the data while using a down arrow decreases the
value 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 left
arrow moves to an earlier day and the right arrow moves to a later day in
the week.
Required
If the location cursor is on a spin box, the default action should be to

accept 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 be
chosen by users.
Sliders and Gauges

Sliders and gauges are analog controls. An analog control is one that
allows for setting or presentation of variables as relative values rather
than absolute. Analog controls provide less precise value setting than
digital controls such as a spin box. However they are very useful in
increasing or decreasing values or in displaying values along a
continuum.
Figure 9-9
Slider with a Default Setting and Current Value Shown
Figure 9-10
Gauges for Setting a Value and Displaying a Value
Chapter 9
305

Recommended
The use of analog control is recommended when most or all of the

The desired result is the making of a choice or the setting of a state or
the display of a value along a continuum.
There is a need to show the current value relative to possible ranges
of values.
There is a need for large imprecise changes with minimal effort.
Display space is sufficient.
Dialog Boxes. Also follow the specific guidelines for sliders and gauges
NOTE
The recommendation for the placement of an analog control and its label
Required
Both ends of the scale associated with a slider or gauge must be labeled
so that users can determine the direction of the continuum for increasing
and decreasing values. See Figure 9-9.
Recommended
If users will need to know the absolute value for the variable set by the
slider or gauge, provide a label that displays the value. See Figure 9-9
and Figure 9-10.
Recommended
The direction of change (increasing and decreasing) in values in the

slider or gauge should be consistent with user population conventions
and with the labels for the control.
Example 1: Lower values set in a slider are associated with the left side
of the scale and the higher values are associated with the right side of
the scale.
Example 2: Desired values presented in a gauge are associated with the
middle of the gauge. Values that are below normal are presented on the
306
Chapter 9

left side of the gauge while values that are above normal are presented
on the right side of the gauge.
Recommended
Place the label identifying the type of variable to left or above the slider
or gauge.
Recommended
If it will benefit the user, display a default setting for the slider as a more
elongated marking on the scale, see Figure 9-9.
Recommended
If it will benefit the user, display threshold settings for the gauge as a
line or a change in coloring inside the main portion of the gauge, see
Figure 9-10.
Required
If the location cursor is on a slider or gauge, the default action should be

to 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 the

value, the value most likely to be chosen by the user should be set as the
default.
List Boxes
Lists can have a single dimension or multiple dimensions. Lists that
have a single dimension are typically presented in a list box with each
item in the list appearing as a row in the list box. Different dimensions of
a multiple dimension list are typically presented as different columns
within a row that represents the item. Guidelines on presenting single
column 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 from
within the list. Lists can have both horizontal and vertical scroll bars for
scrolling 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 of
the following conditions are met:
Chapter 9
307

The desired result is the making of a single choice or the setting of a
state.
There are more than 5 items in the list or the number of items may
change over time.
Users may need to change settings frequently.
There is value in having a large number of the choices simultaneously
visible.
There is adequate space to display 3 or more items simultaneously
without scrolling.
NOTE
If a vertical scroll bar will be used with the list box, it is important that
the 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 of

the following conditions are met.
The desired result is the making of multiple 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 over
time.
Users may need to change settings frequently.
There is value in having a large number of the choices simultaneously
visible.
without scrolling.
NOTE
When users need to make multiple selections it is especially important

to make the box as large as space will allow.
308
Chapter 9

Dialog Boxes. Also follow the specific guidelines for list boxes presented
in this section.
NOTE
The recommendation for the placement of list boxes and their labels may
Required
Label lists to clearly indicate the purpose and content of the list. Label
the items contained in lists to clearly identify them to the user.
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 the
left 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 sequence
to allow the users to easily scan the list items and locate those that
they 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 the
items in the list without having to find them by manual scrolling.
Required
Visual cues should be provided that allow users to differentiate between

single selection and multiple selection list boxes.
Multiple selection list boxes can include a check box next to each item to
indicate to the user that they can select multiple items, see Figure 9-11.
Chapter 9
309

Figure 9-11
Visual Cues for a Multiple Selection List Box
Recommended
Minimize the need for horizontal scroll bars in the list.
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 the
action most frequently associated with the list item, that is, select, open,
modify. After the default action, location cursor should either remain at
its current location or move to the next input field.
The location cursor should remain at its current location if the default
action was to bring up a dialog box.
The location cursor should move to the next field if the default action
was the selection of the list item.
Recommended
In a multiple selection list box, the default action should be select the list
item and move to the next list item that is available for selection or
deselection.
Recommended
In a single selection list box, the initial default selection should be either
the item most likely to be selected or the first item in the list.
310
Chapter 9

Recommended
In a multiple selection list box, the default selection should include the
set of items most likely to be selected by the user.
Tree List Controls

Tree list controls provide a hierarchical listing of objects with
independent mechanisms for expanding and contracting and selecting
items in the list.
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 following
conditions are met:
There is value in showing the hierarchical relationships between the
items in the hierarchy or items can be meaningfully grouped in a
hierarchy.
Users need to select all of the subordinates of one or more levels in
the hierarchy.
There are a large number of items and users can get lost in the
information if some of the items are not hidden from initial view.
The number of items may change over time.
Chapter 9
311

without scrolling.
Dialog Boxes. Also follow the specific guidelines for tree lists presented
in this section.
NOTE
The recommendation for the placement of tree lists and their labels may
Recommended
Label tree list items meaningfully to indicate the specific objects in the
list.
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 icons
are 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 of

items that can be expanded. Each item that can be expanded to show
lower-level contents should have a [+] on its left side. Each item that can
be contracted to remove the lower-level contents should have a [-] on its
left side. Items that cannot be expanded nor contracted have no [+] or [-] .
Recommended
Indent each level in the hierarchy to indicate lower-level items that are
subordinate to a higher-level item.
Recommended
The sequencing of the items in a list should represent on the nature of

the objects represented in the list. Adhere to the following guidelines
when sequencing hierarchical items in a tree list:
List items that are naturally structured into hierarchies in sequence
that reflects their order in the real world hierarchy.
Sequence items at the same level in the hierarchy according to their
relationships, temporal or logical parameters.
312
Chapter 9

Relational Sequence
If there is a meaningful relationship between objects at the same
level in a hierarchy sequence the items based on this relationship.
Examples of meaningful relationships include physical
connectivity, physical distance, shared attributes.
Temporal Sequence
If time is a key attribute associated with items in the hierarchy,
sequence the items according to time. If users need to access the
most recent items quickly, place the most recent items at the top of
the list and the least recent items at the bottom of the list.
Logical Sequence
Sequence items that have no firm relationship to one another
according to a logical rule, such as alphabetical or numerical
ordering.
Selection in Tree List Controls
Recommended
In single selection tree lists and tree lists used in the scope pane, the
currently selected items should be marked by a selection highlight (blue
background 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 tree

list, a check box should be placed between the expansion control and the
icon 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 list
control, check boxes are not recommended.
Optional
If there are a significant number of levels in the hierarchy and space for
the 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 for
multiple selection in a tree list control in a scope pane. Having expansion
Chapter 9
313

only accessible through double-clicking on icons that contain expansion
controls restricts user flexibility. It takes away the ability of the user to
expand and contract the navigation hierarchy without changing the
information in the content pane of the window.
Tree lists with check boxes allow users to select objects at different levels
in the hierarchy. This type of selection allows the selection to be
inherited by objects lower in the hierarchy. Users should be able to
control selection at each level in the hierarchy.
Required
If the user selects an item at a higher level in the hierarchy, all items
contained 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 or
turns off some of the selections that were done by means of selecting a
higher level item, the check mark in the check box of the higher level
item should be light gray instead of black to indicate that the item is
partially selected.
Recommended
If it is important to distinguish items where selection is inherited as

compared to items that are directly selected, this should be indicated by
visual cues.
In Figure 9-13 below, the left most graphic shows what the tree would
look like with no selections. If the user directly selected HP-UX, the
higher level item Nodes would be shown as partially selected, see the
graphic in the middle. As is shown in the right most graphic, if the user
directly selected Denver the lower level items under Denver would
automatically be selected and higher level items in the hierarchy would
be shown as partially selected.
314
Chapter 9

Figure 9-13
Visual Cues for Recursive Selection
Required
Clicking on the check box or on the icon to make the item part of a
multiple selection should not affect the position of the selection cursor or
location cursor if the tree list is presented in the scope pane.
Keyboard Navigation in Tree List Controls
Recommended
Pressing the down arrow key acts to move the selection cursor down and
to execute any action associated with selection. When at the bottom of
the hierarchy, pressing the down arrow key does nothing.
Recommended
Pressing the up arrow key acts to move the selection cursor up and to
execute any action associated with selection. When at the top of the
hierarchy, 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 with
that item.
An item that contains a [-] moves the selection cursor to the first item
in the expanded list under the item and executes any action
associated 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 with
that item.
An item that contains a [+] or no expansion control moves the
Chapter 9
315

selection cursor to the parent item in the navigation hierarchy and
executes any action associated with selection.
Highest level in the hierarchy pressing the left arrow key does
nothing.
Pointer Navigation in Tree List Controls
Required
A single click on the [+] or [-] causes the item to expand or contract
depending on its previous state.
Required
A single selection button click on the icon or the item label, selects the
item and executes any action associated with the selection.
Recommended
Double-clicking on the icon or the item label that has a [+] or [-] causes
the item to expand or contract depending on its previous state, selects
the item and executes the default action associated with the item.
Recommended
A menu button click on the item results in a pop-up menu with menu
items that are specific to the item under the pointer.
Recommended
If the names of the item in the tree list are truncated, resting the pointer
over the name of the item should result in the presentation of a tooltip
with the full name of the item.
The default action associated with items in a tree list control will vary
depending on how the control is being used. Typical default actions are to
open the item, expand and open the item, or open a properties dialog
associated with the item.
Recommended
If appropriate to the use of the tree list control, items in the list are
recommended to have default actions associated with them.
Recommended
In a single selection tree list, the initial default selection should be either
the 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 the
set of items most likely to be selected by the user.
316
Chapter 9

Tables and Grids

Tabular controls typically provide vertically aligned rows of items with
multiple columns across each row. The columns are used to provide a
specific type of information about the item presented in the first column
of each row. For example, a table can provide information on the users on
a system. The first column in the table could be the users login name,
the second column could provide the users home directory, the third
column could provide the start up shell.
There are two basic types of tabular controls: tables which present
information that must be indirectly edited outside of the table and grids
which are directly editable. Tables restrict user actions to the selection of
the 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. If
the contents of a table are to be edited, this is done indirectly in a
separate dialog box. Grids are similar to spread sheets in that they allow
users to directly modify the cells within the grid.
Figure 9-14
Table
Chapter 9
317

Figure 9-15
Grid
When to Use Table and Grids

Use table controls when you need to display or allow user editing of
multiple pieces of information associated with a multiple items or objects
(for example, an array of data or a structure).
Recommended
The table is recommended when most or all of the following conditions

are met:
The desired result is the making of a choice or the presentation of
information.
It benefits the user to show attributes or additional data associated
with the items being displayed.
The need to modify the attributes shown is infrequent or the
modification of the attributes is most easily done with specific
controls.
There are multiple items or the number of items may change over
time.
without scrolling.
Recommended
The table is recommended when most or all of the following conditions

are met:
The desired result is the making of a choice, the presentation of
information, or the modification of individual attributes.
318
Chapter 9

It benefits the user to show attributes or additional data associated
with the items being displayed.
The need to modify the attributes shown is frequent and can easily be
done by entering data into text fields.
There are multiple items or the number of items may change over
time.
without scrolling.
Dialog Boxes. Also follow the specific guidelines for tables and grids
NOTE
The recommendation for the placement of an tables and grids and their
labels may need to be modified for localization for different countries.
Recommended
In tables and grids, vertically align the label for the first column with the
left side of the list box. For the labels for the remaining columns, follow
these guidelines:
If the contents of a line in the column is long relative to the label (for
example, if the line in the column contains 50 characters and spaces
and the label contains 10), center the label above the column unless
this would cause the label to be off the visible area of the display
when a portion of the column is displayed.
If the contents of the column is approximately the same width as, or
shorter 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 the
columns.
Recommended
Tables should have a column label above each column in the table. If
users can horizontally scroll the data, they should be able to scroll the
column labels.
Chapter 9
319

Input Focus and Editing for Tables and Grids
While tables are fairly common, grids are relatively new to users. Users
will 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 of
actions they can take in a grid.
Recommended
Tables should have the appearance of a multiple column list and there
should not be any lines between the rows and columns in the table.
Recommended
Grids should have the appearance of a spreadsheet and there should be

lines 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 screen
of information, allow users to resize the columns of information to meet
their individual needs. Also consider giving the user control over the
sequencing of the columns of information.
Recommended
Push buttons that act on selections within the table should be placed to
the right of the table.
If users will need to edit or modify the entries in the table, provide a
push button labeled Modify... or Properties... that will present a
separate dialog box for editing a given row in the table. Each editable cell
in 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 most
likely to select or modify should be selected.
Recommended
When a grid first receives input focus, the cell that the user is most likely
to edit should have input focus.
If the most likely user action is to add entries to the grid, the cell with
input focus should be the left most cell within the first empty row of the
grid.
Recommended
If the grid is the only control in a dialog box or window, input focus
should on the grid and one of the cells in the grid should have input focus
when the window is first opened.
Required
The cell in the grid that has input focus should be indicated by a clear
visual cue. A dark border around the cell is the suggested visual cue. See
Figure 9-15.
320
Chapter 9

Recommended
Grids in which users can add entries should have two empty rows of cells
at the bottom. See Figure 9-15.
Having two empty rows in the grid provides a visual cue that users can
add new entries to the table. After the user has filled in information in
the first empty row and then moves to the second empty row a new
empty row of cells should be added to the grid. This assures that there is
always an empty row of cells at the bottom of the grid, even when the
user 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 be
provided in cells where it is possible to have default values.
Recommended
Users should be able to delete items from grids by highlighting the

information in the cells and pressing the [Backspace Erase] key on the
keyboard.
Required
If some of the cells in the grid are read only this should be indicated by a
grayed background appearance to the cells. See Figure 9-15.
Recommended
If controls other than text boxes are placed in the cells of grids, the
controls 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 only
reflect the current value of that cell. When input focus is placed within
the cell the type of control associated with that cell should be shown.
Filtering and Sequencing of Items
The best sequencing of the items in a table or grid depends on the nature
of the objects represented in the table.
Recommended
When it will benefit the users task, users should be able to filter the
information in the table or grid.
Typically filtering capabilities can be accessed by a pop-up menu
associated with the column labels for the table or grid.
Recommended
When users can add entries to tables or grids, the entries should be
sequenced in the order in which they were added.
Recommended
If users cannot add entries to a table or grid, the rows should be

sequenced in a logical order based on the first column in the table. The
Chapter 9
321

logical order can be alphabetical, based on the physical layout of the
objects in the managed environment.
Recommended
When it will benefit the users task, users should be able to control the
sequence of items in the table:
Sort the tabular information by the information in the various
columns by clicking on the column labels.
Resequence the columns in the table by dragging the column heading
to a new location.
Resequence rows in the table by selecting the row and dragging it to a
new location or by push buttons for manipulating item sequence (for
example, [Move Up] and [Move Down].
Recommended
If a table or grid has more columns than can be displayed in the dialog
box or window in which it is contained, a horizontal scroll bar should be
provided to allow users to see all of the columns.
Recommended
If a table or grid has more rows than can be displayed in the dialog box or
window in which it is contained, a vertical scroll bar should be provided
to 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 selection

in table controls by doing a range selection or control select of individual
rows or cells.
Recommended
Unless users are able to select individual cells in the table, the selection
highlight should be placed around the full row in the table when the user
selects it.
Recommended
A single-click on a cell in the of a grid should place input focus in that

cell.
Keyboard Navigation in Tables and Grids
Recommended
In a table:
Pressing the down arrow key should move the selection cursor down
one row. When at the last row in the table, pressing the down arrow
key does nothing.
322
Chapter 9

Pressing the up arrow key should move the selection cursor up one
row. When at the first row in the table, pressing the up arrow key
does nothing.
If users can select individual cells in the table, pressing the right
arrow key should move to the selection cursor to the next selectable
cell. If users can only select full rows in the table, pressing the right
arrow key should move the selection cursor down one row. When at
the last row or cell in the table, pressing the right arrow key does
nothing.
If users can select individual cells in the table, pressing the left arrow
key should move to the selection cursor to the previous selectable cell.
If users can only select full rows in the table, pressing the left arrow
key should move the selection cursor up one row. When at the first
row or cell in the table, pressing the left arrow key does nothing.
Recommended
In a grid:
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 does
nothing.
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 does
nothing.
Pressing the Right Arrow key should move input focus to the next
editable 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 previous
editable cell. When at the first editable cell in the table, pressing the
Left Arrow key does nothing.
Recommended
When one or more rows are selected in a table, the default action should
be to perform the most typical action associated with the item associated
with 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 the
most typical action associated with the cell.
Chapter 9
323

Frequently the most meaningful action will be to accept the value
entered in the cell and to move to the next cell in which the user needs to
make an entry.
Recommended
If users will need to take action on items in a table, the item that users
will most likely need to act on should be selected. If there is no means for
determining what item users will need to act on, the first item in the
table should be selected.
Tab Controls
Tab controls provide a means of presenting a large amount of
information in a limited amount of space. These controls present
multiple pages of information or controls using a metaphor of a set of
index cards with attached tabs.
Figure 9-16
Tab Control
Follow the guidelines in this section when using tab controls.
324
Chapter 9

When to Use
Recommended
The tab control is recommended when most or all of the following

conditions are met:
The desired result is the presentation properties of an object or the
presentation of multiple sets of information or controls in a limited
display space.
There is more information to be collected or presented than can be
shown in a single dialog without scrolling.
The information or controls can be grouped into meaningful
nonoverlapping categories.
Users do not need to see all settings simultaneously or may benefit
from having the data presented separately (for example, users may
only need to view or input data within a single tab).
There is no sequential dependency between controls that would be
placed on separate tabs.
Dialog Boxes. Also follow the specific guidelines for tab controls
NOTE
The recommendation for the placement of tab controls and their labels
Recommended
Label the tabs meaningfully to indicate the types of data to be input or

presented on the tab.
Recommended
The sequence of tabs within a tabbed control should match the logical
order required by the users task:
The most frequently used tabs should be placed to the left in the
sequence and less frequently used tabs should be placed to the right.
Data that users would expect to provide first are placed in the first
tab in the sequence (for example, the name of the item or object).
Chapter 9
325

Required
The ordering of tabs should be preserved as users access different tabs in

the set.
Recommended
The placement of tab controls at the top or bottom of a window should

follow these guidelines:
Tab controls at the bottom of the scope pane should only be used as
context tabs, see Context Controls in Chapter 5 for more
information on context tabs.
Tab controls at the bottom of the results pane should only be used as
navigation tabs, see Navigation Tabs in Chapter 5 for more
information 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 grouping
properties, task steps, or information sets.
Recommended
If vertically aligned tabs are used, the labels should be rotated as a

whole rather than closing characters vertically aligned.
Figure 9-17
Vertical Tabs
326
Chapter 9

NOTE
Vertically aligned tabs are not recommended.
General Guidelines
Recommended
In general it is recommended horizontally aligned tabs be used instead of

vertically 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 navigating
between the different rows of tabs. If the rows stay in their absolute
positions, they top row does not appear to be attached to the tab. If the
rows change position depending on whether they are active or not, their
position changes and this results in user error.
Recommended
If there are more categories than there is space for tabs in a single row
the following methods should be used to eliminate the need for multiple
rows of tabs:
Using the shortest possible meaningful tab label and shrinking the
tabs to fit the labels.
Restructuring the categories so there are fewer categories.
Increasing the width of the tabbed dialog box so that there is more
space for tabs.
Scrolling the tabs if user performance will not suffer from seeing a
subset of the categories.
Recommended
If tabs are scrolled:

Visual cues should be provided on the tabs to indicate that not all
tabs are visible and the tabs can be scrolled see Figure 9-18,
Scrollable Tabs.
Tabs should automatically scroll to the right when the user selects
the right most tab in the visible tab set.
Tabs should automatically scroll to the left when the user selects the
left most tab in the visible tab set.
Chapter 9
327

Figure 9-18
Scrollable Tabs
Recommended
If beneficial to task performance, visual cues should be provided to

indicate:
The tab contains mandatory fields that must be completed before the
dialog box can be exited.
For example, an asterisk could appear on each tab that contains
mandatory fields.
The user has previously accessed a tab during the current session.
For example, all tabs that have been accessed in the current session
could have the tab labels presented in italic font.
The user has changed information in the set of tabs but the changes
not been saved.
For example, the status bar of the window or dialog box containing
the tab control could present the message Unsaved changes.
Required
Tabs in a tab control that may be unavailable for long periods of time or
may never be available (that is, tabs only available when specific
software has been installed or if the operator is granted specific
permissions) should be removed from the tab control. These tabs should
only be included in the tab when the prerequisites for their availability
have been met.
Required
Push buttons that act on a single tab with the set of tabs should be
placed within the tab on which they act.
Required
Push buttons that act on all of the tabs within a tab set should be placed
outside of the tabs.
NOTE
Push buttons placed outside of the tab set should be placed beneath the
set of tabs or optionally to the side of the tabs. Placement beneath the set
of tabs is preferred.
328
Chapter 9

Grouping Controls
In addition to providing aesthetic appeal, grouping of information can
aid user recall, and result in faster screen search. Grouping methods
include separator lines, group boxes, and panes.
Separator lines are simply a horizontal or vertical line that is used to
separate information on the screen. Separator lines are commonly used
in menus to separate different types of menu items. They can also be
used in windows and dialog boxes to separate different types of controls.
Separator lines take up less space than group boxes as they consist of a
single line rather than a set of four lines.
Figure 9-19
Dialog Box with a Separator Line
NOTE
Separator lines can be created in n Windows NT applications by bitmap

images of a line, in HTML applications using horizontal rules (<HR>), in
Java applications using a GIF image of a line and in UNIX applications
by using panes without sashes.
Group boxes provide a box or line surrounding the set of controls that
they group. Group boxes can be used to organize the screen or dialog box
into functional or semantic groups. Although technically considered
controls, group boxes do not process any mouse or keyboard input. They
Chapter 9
329

do however affect keyboard navigation as the user of the interface must
use the tab key to move into the controls within the group box.
Figure 9-20
Dialog Box with a Group Box
Panes provide a more definite boundary between the set of controls that
they group. Panes divide the window into individual segments and allow
the user to apportion the window display space based on their individual
needs when using the different window segments. The information
presented in a pane can be independently scrolled. Like group boxes,
panes affect the keyboard navigation within a window, as the user of the
interface must use the Tab key to move between the different panes in
the window. See Figure 9-21.
330
Chapter 9

Figure 9-21
Window with Two Panes
When to Use
Recommended
The use of a line as a grouping mechanism is recommended when most or

all of the following conditions are met:
The desired result is a visual indication that there are differences in
the type of functionality or type of information being provided in
different sections of the dialog box.
The information or controls can be arranged into meaningful
nonoverlapping groups.
Users have the possibility of misunderstanding the information if it

is not grouped.
Chapter 9
331

There is limited space in the dialog box for presenting the grouping
mechanism.
It is more aesthetically appealing to have the separator in the dialog
box.
Recommended
The use of a group box as a grouping mechanism is recommended when

most or all of the following conditions are met:
the type of functionality or type of information being provided in the
groups.
Users have the possibility of misunderstanding the information if it is
not grouped.
There is sufficient space in the dialog box for presenting the grouping
mechanisms.
Having a label or title for the group increases the users
understanding of the controls that are presented in the group.
Recommended
The use of a pane as a grouping mechanism is recommended when most

or all of the following conditions are met:
the type of functionality or the type of information being provided in
different sections of the window.
Having separate panes aids the user in interacting with the
information being presented.
Users need to be able to independently scroll the information in
the different panes.
Users will need to see simultaneously see portions of the
information in the two different panes.
Having different panes enables users to more easily navigate
within the information space (for example, scope pane, and results
pane).
332
Chapter 9

Guidelines for Group Boxes
If used appropriately group boxes can be beneficial to the user
performance, however, if used inappropriately they simply take up space
and 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 meaningfully
related.
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 overall
purpose of the controls inside the group box.
Make sure that the label is related to all controls inside the group
box.
Place the label in the top border of the group box.
The group box label exceeds the length of the controls and labels
inside the group box, extend the width of the group box by 7 dialog
base units beyond the label.
Recommended
The spacing and alignment of group boxes should adhere to the following
guidelines:
Maintain a consist spacing (4-7 dialog base units) above, below, to the
left, and the right of the controls and labels inside the group box.
Leave a minimum 7 base dialog units between the group box and the
edge of the window or dialog box in which it is contained.
Align the items within the group box (for example, left align check
boxes or radio buttons).
Recommended
In windows with multiple group boxes and multi columns, create a

balanced appearance by maintaining equal group box widths and group
box heights as much as practical.
Recommended
If more than one group box is incorporated within a column on a dialog

box, then:
Chapter 9
333

Align the controls within the group boxes following the guidelines
presented 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 size
of each pane to suit the current task.
Recommended
The default size of a pane should be sufficient for the user to easily access
and use all controls contained within the pane.
Optional
In a multi-pane window provide a clear indication as to which pane

currently has input focus.
If users are navigating via the keyboard, it will be important to easily
detect the pane that is receiving input from the keyboard. Examples of a
visual cues for input focus are a black box around the pane with input
focus or the presence of the blue selection cursor.
Expanding panes are panes which are not continuously visible but which
become visible when the user presses a push button or sets a toggle
button.
Recommended
Adhere to the following guidelines when expanding panes are used:

Only use expanding panes to minimize the size of dialog boxes and
windows, or to minimize screen clutter by hiding unnecessary
information until it is requested by the user.
Do not put material in expanding panes if it will be needed every time
the user accesses the window.
334
Chapter 9
10
Miscellaneous Guidelines
335
This chapter presents general guidelines for the localization and

internationalization of user interfaces.
In general, you should follow guidelines for the platform upon which
your application is built. There are several HP OpenView-specific
guidelines presented in this chapter. The HP OpenView guidelines can
be implemented following the steps in the HP OpenView Integration
Series: OVW Developers Guide.
Other references that you may want to consult are listed below:
X Windows on the World, by Thomas C. McFarland (Prentice Hall
PTR, 1996)
Programming for the World, Sandra Martin ODonnell (Prentice Hall
PTR, 1994)
336
Chapter 10
Internationalization and Localization of the User Interface
Internationalization and Localization of the

User Interface
Internationalized user interfaces are interfaces that can be tailored for a
specific country, culture or language without modifications to application
code and without recompiling or relinking code. They may or may not
include translation of texts (within the user interface) into a language
other than English.
Internationalized user interfaces are interfaces that have all of the
following characteristics:
Can be localized (texts can be translated into other languages).
Can display monetary, date, time, and numeric data in a locale
specific manner.
Can display data sorted and collated in a locale-specific manner can
accept 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 as
multibyte. In addition, they should maintain data integrity as the
data are manipulated in the code.
Can install in a non-locale specific manner so that a single
installation can be used by various users under various locales (not
necessarily simultaneously).
Can switch locale based on the users preference. For example, on
UNIX systems, use XPG4 locale category environment variables, such
as 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 the
end user of the subsystem). On UNIX systems, use font sets. On
Windows NT systems, use the localized version of Developer Studio to
edit and create localized resource files. This ensures that correct fonts
are selectable for the users language.
In most cases, a subsystem that follows the ANSI locale model will be
internationalized. Follow the style guide for the operating system on
which you are delivering your product when preparing your application
for international markets.
Chapter 10
337
Localization of the User Interface

Recommended
When attempting to make your product localizable, you need to ensure

that all areas of the user interface can display localized text as an output
to the end user. Throughout your various user interface subsystems, the
texts that appear in the following user interface components are
expected to have the ability to display multibyte texts based on the locale
specified 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 the
window manager in the frame of a window.
Text, including text all dialog boxes and messages boxes, text that
appears in message and status areas, and text indicating map
permissions.
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 for
localization for as much of their user interface as possible. However,
some things are not localizable. For example, product names are usually
not translated because there is a copyright associated with the
translated string.
Helpful Hints for Internationalizing HP OpenView

Applications
Recommended
To support internationalized data in the user interface components

mentioned above, it is important to design the interface for
HP OpenView applications using the following guidelines:
Use the guidelines for the platform upon which your application is
built.
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 in
HP OpenView-related software. Expect that the user will use the US
format of floating point numbers.
338
Chapter 10
Assume that the hostnames and UNIX login names contain strictly
7-bit characters (networking software does not allow multibyte
characters in those areas).
Do not assume that one column = one character. Most Asian
characters require two columns per character.
Do not use bold face and italic fonts to differentiate from non-bold and
non-italic fonts, or be sure that the fonts can be localized. Not all
multibyte fonts can be bold faced or italicized.
Do not assume that words are separated by a space. Some languages
do not separate words with a space character.
Do not assume that special characters (such as ?, !, ) exist within a
language.
Do not assume the existence of a period (.) to end a sentence. Some
languages do not end their sentences with a period.
Do not build English grammar into the user interface. For example, a
menu command that spells out the English sentence using a cascade
menu Display->data->using->graphs will be very difficult (if not
impossible) to localize. Another example of a non-localizable interface
is one that requires an end user to fill in the blanks, as in search for
______ in the _____ file.
Do not use X or check marks to imply OK or not OK; show legends for
symbols if necessary.
Do not use abbreviated English characters. For example, using D next
to map names to indicate the Default map is not intuitive to
non-English speaking users. Also, the letter D cannot be translated
easily.
Do not assume that short (or long) English words are short (or long)
words in other languages. Allow the user interface component (for
example, the text widget or the push-button widget) to shrink or
expand based on varying sizes of words.
Do not assume that the characters can be displayed using fonts
smaller than 14 pixels wide. For example, most Asian characters are
completely unreadable when displayed using fonts that are smaller
than 14 pixels wide.
Do not assume that American/Western color coding conventions (for
example, green = go or OK, blue ribbon = first place) will apply to
Chapter 10
339
your customers. Allow users to customize the colors used in your
application.
Do not use graphics for symbols or icons that have the potential for
offending user, or that have different meanings in different cultures.
For example, graphics that contain body parts, such as a hand, may
be viewed as offensive in some cultures. As another example, in the
US, a black cat is a symbol of bad luck, while in the UK it is a symbol
of good luck.
340
Chapter 10
11
Guidelines for Product

Documentation
341
Guidelines for Product Documentation
This chapter presents recommendations for designing the manuals that

accompany your HP OpenView application. These recommendations are
important because they:
Maintain a consistent organizational approach to user
documentation. Users will be able to move from one application to
another and find the same information flow throughout the product
manuals.
Help users learn the application more quickly because they can find
information more easily.
Provide consistency in design, content, and organization. This
enhances the integration of the many HP OpenView applications.
342
Chapter 11

Structure of the Documentation Set

Hewlett-Packard has adopted a set of editorial guidelines for product
documentation that help documentation developers create manuals that
are not only highly usable, but also have a consistent, uniform structure
and appearance across HP OpenView products.
HP OpenView recommends that Hewlett-Packard developers of
applications for HP OpenView follow the latest version of the HP
guidelines, paying particular attention to the items outlined in this
chapter.
Third-party developers are urged to follow, at minimum, the guidelines
that are presented here.
Types of Documentation
HP identifies six basic types of manuals, which define a basic structure
for meeting the needs of users, based on their knowledge level and
learning needs.
Quick Start Guidea one-glance overview of the product and a few
task instructions to help the user get comfortable.
Task Referencea complete set of task instructions and
problem-solving guidelines, with a few basic concepts. This is often
the basis for a Users Guide.
Reference Guidedescriptions of the product in a dictionary or
encyclopedia format.
Concept Guidetopics that explain concepts and apply them to
advanced tasks.
Installation Guideinstructions for installing and configuring the
product.
Quick Referencetables, syntax lists, menu trees, and brief
instructions that help the user remember details.
A Modular Approach
Start by identifying the information that is most important for the type
of manual. This information may be task or tutorial instructions,
Chapter 11
343

problem-solving instructions, descriptions of product features, or
conceptual topics.
Such information is organized in modules. One task, one problem, one
feature description, or one topic forms a single module. All modules of
the same type have the same structure, with the same kind of heading.
See Figure 11-1.
Figure 11-1
Organizing Information into Modules
Task Module 3
Task Module 2
Task Module 1
Problem Module 3
Problem Module 2
Problem Module 1
Topic Module 3
Topic Module 2
Topic Module 1
Concept Module 3
Concept Module 2
Concept Module 1
Developers of applications for HP OpenView Windows are urged to think

of their documentation in terms of modules, as this concept is very useful
in organizing documentation.
344
Chapter 11

Grouping the Modules

Once you have conceptually organized the information you want to
include into modules, you group the modules together to form the
manual. One of the decisions you need to make is how many manuals
you will use to document your product. The six different types of
manuals do not necessarily represent six different books for each
product.
Several types of manuals can be combined. For example, you can
combine concept modules and task modules into one users guide.You can
group tasks by types of tasks, or can group them by type of audience,
such as operators or administrators. You may decide that you need two
or 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 developers guide.
Ask yourself the following questions to help you determine the number of
manuals that will document your product:
Who is the user for your product, and thus the audience for your
book? Are there multiple users with different needs? For example,
will your product be installed, configured, and administered by one
person and used by another?
Are there different kinds of end users for your product? Will one book
address the knowledge level of all users, or would it be better to have,
for example, a users guide for beginning users and a reference guide
for more advanced users?
How complex is your product? Is the information better presented in
separate books?
Recommendations for the Documentation Set

Following is a list of recommendations for the structure of your
documentation set.
Individual products should each have individual manuals. For
example, do not combine reference information for multiple products
into one reference guide.
Chapter 11
345

Do not combine different types of manuals into a single book, unless
there is compelling reason to do so. For example, keep installation
information separate from reference information.
Examples of when it is acceptable to combine different types of
manuals into one book include:
Yours is a simple product, easy to install and use, and the person
installing the product is the same person using or administering
the product. In that case, it is acceptable to combine installation
information with information on using the product or with
administration information in one manual.
Economic reasons prevent multiple manuals. In this case, you
should clearly separate the various types of modules (task,
concept, tutorial, reference) from each other.
If you provide your documentation online only, you should provide a
printed Getting Started guide that lets the user know how to start the
product and where to find the online documentation.
In addition, you should consider a desktop publishing system that meets
the future needs of your documentation set. If you are going to be
sharing your documentation set with another company, choose a
publishing system that can be translated or exported into a format that
can be shared.
346
Chapter 11

Structure of Individual Manuals

Once you have decided on the overall structure of your documentation
set, you need to design each individual manual. In addition to grouping
the modules in a logical, organized manner, you need to add supporting
elements. These include:
Section and chapter introductions.
Table of Contents, Table of Figures, Table of Tables.
Index.
Glossary.
Graphics.
Learning products map.
Recommendations for Information Access

The goal of any documentation is to help users learn how to use your
product. Key to that process is helping users find information quickly. If
users can find the information that they need, they will become
productive more quickly.
These recommendations will help the user find the information needed to
learn how to use your product:
Include the chapter heading plus two levels of subheadings in the
Table of Contents.
Include List of Tables and List of Figures.
Include a documentation map that lets the user know what other
manuals are available for your product, and what types of
information can be found in each book.
Include a book introduction that helps the reader understand what
information the book contains. You may include a quick overview of
the products capabilities from the user point of view.
Provide an index with multiple listings and cross references. Use both
noun-oriented and verb-oriented entries.
Use headers and/or footers. These should contain chapter number
Chapter 11
347

and/or title and section headings. Include page numbers in either the
header or the footer.
Provide a glossary if you are introducing new terms and/or are using
any terms that are industry-specific or could be easily misunderstood.
Choose a binding method for your book such that it can be laid flat
while the user is using it.
When you combine multiple manuals into one book, separate the
sections with tabs, preferably hard tabs with labels, to help the user
find information.
Recommendations for Information Understanding

Regardless of whether you are presenting task information, concept
information, procedural information, or reference information, the way
in which you present that information is key to user understanding.
The following recommendations will help your user more easily
understand the information you are presenting.
Use introductions to describe what each section or chapter covers, or
what the procedures will cover. Describe the tasks or procedures from
the users point of view.
Use bulleted lists wherever possible, rather than long sentences or
paragraphs.
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 step
correctly.
Provide troubleshooting information immediately before or after the
procedure whenever possible. If not feasible, then direct the user
where to look for troubleshooting information.
Include a section or chapter on errors and troubleshooting. Explain
what caused the error to occur and how to correct it.
Include figures and graphics to help illustrate concepts and
complicated procedures. Figures and graphics should be kept simple,
and may contain callouts when appropriate to further describe what
348
Chapter 11

you 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. Number
and caption all tables, and reference them in the related text.
Use different typefaces to present different elements, such as file
names, command names, user input, computer output, etc. Provide a
table in the introduction of your book that explains the typefaces, and
use them consistently throughout the book.
Use heading formats consistently. The hierarchy of heads should be
easily distinguishable to the reader.
Keep 10% to 20% white space throughout your book.
Use consistent verbs to describe how the user interacts with the
computer 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 Localization

If you are planning on having your documentation translated from
English into other languages, you should follow these guidelines.
Keep a minimum of 20% white space around text. Many languages
expand when translated from English.
Avoid using idioms, acronyms, slang, and jargon.
Use clear and consistent English text. Keep sentences short; use
simple words.
Avoid using words that have multiple meanings.
Do not use words or graphics that could have special cultural
meaning.
Chapter 11
349

350
Chapter 11
HP OpenView Launcher
Categories
351
HP OpenView Launcher Categories

Object Tab Categories

The following categories have been defined as the top level items for the
Objects tab in the HP OpenView Web Launcher. These categories will
only be visible in the launcher when there are one or more entries
beneath the category.
Object Views
This is the top level or root item for this tab. All other categories and
access points to applications that provide views are listed under this
category.
Customers
Views that show managed objects from the perspective of the
customer: views of customers; views of managed objects or services
within the customer organization.
Devices
Views that show managed objects grouped in terms of the type of
device, or views of devices in their context of use. Devices include
routers, switches, hubs, printers, tape drives, hard disks, and
others.
IT Resources and Applications
Views of the organizational structure of the IT group and/or the
hardware and software used by the IT group for providing
management services: OpenView users, management systems,
management applications.
Networks
Views that show managed objects based on a network topology: IP;
IPX; SNA; and others.
SLAs and Services
Views of service level agreements or views of objects that are
grouped together because they are involved in providing a specific
service.
352
Appendix A

Software
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 systems
administration or server administration with hierarchies based on
the resources contained within the systems and servers.
Telecom Resources
Views of the organizational structure of Telecom management
group and the resources that are used by the group for providing
management of the infrastructure used in providing telecom
services: OpenView users; individuals in the NOC; management
applications, and others.
Other Objects
Views of objects that do not readily fit into the other categories of
object views.
Appendix A
353

Task Tab Categories
Task Tab Categories

Tasks tab of the HP OpenView Web Launcher. These categories will only
be visible in the launcher when there are one or more entries beneath the
category.
Tasks
access points to applications that provide tasks in the form of task
presentation mangers, wizards, or tabbed dialogs are listed under
this category.
Accounting and Asset Management
Tasks related to asset management: record keeping for objects
being managed; tracking of systems, devices, and applications;
review of available assets; and setup and customization of
management capabilities for accounting and asset management.
Change Management
Tasks related to change management: configuration of managed
objects (for example, systems, servers, routers, networks, and
software); tracking of configuration changes; and setup and
customization of management capabilities for configuration and
change management.
Fault Management and Diagnostics
Tasks related to the trouble shooting and resolution of problems in
the network and system management environment: connectivity
diagnosis; performance diagnosis; handling of events or alarms;
setup and customization of management capabilities for fault
management.
Information and Reporting
Tasks related to the access of information and reports on the
managed environment: generation of reports; data collection; and
setup and customization of capabilities for data collection and
reporting.
354
Appendix A

Task Tab Categories
Resource and Performance Management
Tasks related to monitoring and regulation of the performance in
the network and systems management environment: performance
monitoring, modifications in the infrastructure to improve
performance; setup and customization of management capabilities
for performance management.
Security Management
Tasks associated with the management of the security of the
network and systems environment: setting up mechanisms to
control access to network and system resources; auditing of access;
modification of access privileges; setup and customization of
management capabilities for security management.
SLAs and Service Management
Tasks related to creating and maintaining Service Level
Agreements (SLAs) and service management: creating and
maintaining Service Level Agreements (SLAs); managing services
based on SLAs; and setup and customization of management
capabilities for service management.
Software and Data Distribution
Tasks related to software and data distribution: installation and
updating of software (e.g., operating systems, applications);
distribution of data within the network and systems environment;
setup and customization of management capabilities for software
and data distribution.
Storage, Back Up, and Recovery
Tasks related to the setup and maintenance of backup and
recovery and storage management: storage management;
maintenance of storage devices; tracking of storage space; media
management; interactive and automated backups; recovery of
files, directories or other data sources; setup and customization of
management capabilities for storage management and backup
and recovery.
Appendix A
355

Information and Reporting Tab Categories

Information and Reporting tab of the HP OpenView Web Launcher.
These categories will only be visible in the launcher when there are one
or more entries beneath the category.
Information and Reporting
access points to applications that provide tasks in the form of task
presentation mangers, wizards, or tabbed dialogs are listed under
this category.
Accounting and Assets
Information and reports related to asset management: reports on
the systems, devices, applications and data in the organization.
Configuration Information
Information and reports related to the current configuration or
configuration 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 the
managed environment and resolution of problems.
Resource and Performance Management
Information and reports related to usage and availability of
resources and the performance of these resources (for example,
networks, systems, and software).
Security
Information and reports associated with the security of the
network and systems environment: logins, access to systems,
attempts to breach security, and others.
SLAs and Service Management
Information and reports related to Service Level Agreements
(SLAs), the services being provided, management tasks, and
356
Appendix A

service performance relative to the criteria specified in the service
level 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 data
storage including reports on frequency and success of backup and
recovery, location and movement of data for storage purposes.
Appendix A
357

Tool Tab Categories
Tool Tab Categories

The tool tab in the HP OpenView Web Launcher allows application
developers more freedom in identifying categories for portions of their
applications. The tool tab should contain the name or initials of the
application as a category entry with portions of the application that are
executable as separate user interfaces being listed under the application.
If an application has a lot of functionality that can be grouped under
different category headings, it may be desirable to have category items as
entries under the application.
Potential Tool Tab Entries for NNM and ITO are presented below as
examples:
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
358
Appendix A
Mnemonics and Accelerators
359
Table B-1
Table B-2
Common Accelerator 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 for current

selection
Shift + F10
Display pop-up menu
Common Mnemonic Access Key Assignments in HP OpenView

Key Assignment
Menu Item or Push Button Label
About
Action
Apply
Save As
Select All
Back
Close
Copy
Delete
Edit
Explore
360
Appendix B
Table B-2
Common Mnemonic Access Key Assignments in HP OpenView

Key Assignment
Menu Item or Push Button Label
File
Find
Finish
Help
Hide
Move
New
Next
Open
Paste
Print
Quick Navigator
Properties
Refresh
Save
Show
Cut
Help Topics
View
Window
Exit
Appendix B
361
362
Appendix B
Color Mapping and Palettes
363

Using Color in Web Page Design
Using Color in Web Page Design

This chapter explains the guidelines for specifying the color values for
various features on your Web site pages. These color values are provided
within two color palettes, each one having a specific set of color values for
specific types of Web graphics.
Color Palettes Used in HP OpenView

In an HP OpenView environment, there are two types of color palettes
you 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 those
appearing on buttons in a toolbar).
An expanded color palette, for use with large images and graphics
presented in a web browser.
NOTE
The limited palette is a subset of the expanded palette. This means that
the color values in the limited palette are also included in the expanded
palette.
Palette Contents
In the next two sections, the color values for each palette are listed in a
table. For each color value, you will see a column for its hexadecimal
value and a column for its decimal value. Browsers typically require
color values to be stated in hexadecimal. Conversely, many graphics
editing programs use digital (decimal) values for their RGB values.
364
Appendix C

Using the Limited Color Palette

The colors in this palette type are intended for use in creating very
specific graphic types: icons and status colors. On Web pages and in HP
OpenView applications, you will find icons being used in such features as
toolbar buttons and object icons. HP OpenView applications also use
status colors to indicate the current state of objects (an example would be
a Network Node Manager submap on which several nodes and servers
are shown to be disabled).
For these graphic types and status, you should use only those color
values 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 display

consistently when formatted as nondithered colors across the three
browsers tested with the limited palette.
Color Values in the Limited Color Palette

In the chart below, each color value is listed by a name, a Hexadecimal
value, and a Decimal (RGB) value. The name used in color table would be
the color name that you would use in specifying a background color or
other color in html. The final column indicates the HP
OpenView-standardized usage for a particular color value whenever that
value is not being used within icons. For example, you should use the
Dark Brown color value to indicate an objects disabled status.
Appendix C
365

Table C-1
Color
Name
Hex
Value
Decimal
Value
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
366
HP OpenView usage
(other than icons)
Appendix C

Table C-1
Color
Name
Hex
Value
Decimal
Value
HP OpenView usage
(other than icons)
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
Gray (3) b
66 66 81
102 102 129
Gray (4)
33 33 4F
51 51 79
Black
00 00 00
000
Text
a. Dithered on Internet Explorer.

b. Dithered on UNIX Netscape.
Appendix C
367

Using the Expanded Color Palette

The colors in this palette type have been tested with Microsofts Internet
Explorer on Windows NT and with Netscape on Windows NT and UNIX.
All colors (with the exception of the grays) have been found to display
approximately the same hue without dithering. Therefore, the colors in
this 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 display

consistently when formatted as non-dithered colors across the three
browsers tested with the limited palette.
Color Values in the Expanded Color Palette

In the chart below, each color value is listed by both its hexadecimal
value and its Decimal (RGB) value. A check mark (3) appearing before a
color in the LP column means this color is also included in the limited
color palette as well as the expanded palette. And you can use the last
column, Cell Location in .gif File to view onscreen the exact color
swatch for a particular color value in the largepal.gif file.
Table C-2

LP
Hex Value
Decimal Value
Cell Location in .gif File
00 00 00
000
Row 1 , Column 1
0 0 33
0 0 51
Row 1 , Column 2
0 0 66
0 0 102
Row 1 , Column 3
00 00 80
0 0 128
Row 1 , Column 4
368
Appendix C

Table C-2

LP
Hex Value
Decimal Value
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
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
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
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
0 80 FF
0 128 255
Row 3 , Column 1
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
00 FF FF
0 255 255
Row 3 , Column 7
Appendix C
369

Table C-2

LP
Hex Value
Decimal Value
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
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
370
Appendix C

Table C-2

LP
Hex Value
Decimal Value
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
64 00 00
100 0 0
Row 6 , Column 6
66 66 81
102 102 129
Row 6 , Column 7
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
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
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
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
Appendix C
371

Table C-2

LP
372
Hex Value
Decimal Value
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
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
BF 40 FF
191 64 255
Row 10 , Column 5
BF 80 0
191 128 0
Row 10 , Column 6
Appendix C

Table C-2

LP
Hex Value
Decimal Value
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
C0 C0 C0
192 192 192
Row 11 , Column 8
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
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
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
Appendix C
373

Table C-2

LP
Hex Value
Decimal Value
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
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
FF 80 FF
255 128 255
Row 13 , Column 9
FF BF 66
255 191 102
Row 13 , Column 10
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
FF FF CC
255 255 204
Row 14 , Column 5
FF FF FF
255 255 255
Row 14 , Column 6
374
Appendix C
Bibliography
375
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: Defining
Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann
Publishers, 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 the
Human-Computer Interface. Cambridge, MA: Cambridge University
Press, 1991
Constantine, L. Usage-Centered Software Engineering: New Models,
Methods, and Metrics. In Proceedings of the 1996 International
Conference on Software Engineering: Education and Practice, Duendin,
New Zealand: New Zealand Computer Society, 1996.
Carlshamre, P. and Karlsson, J. A Usability-Oriented Approach to
Requirements Engineering. In Proceeedings of the Second International
Conference on Requirements Engineering. April 15-18, Colorado
Springs, 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 Design
of Computer Systems. Mahwah, NJ: Lawrence Erlbaum Associates, 1991.
Hefley, W., et al. Integrating Human Factors with Software Engineering
Practices. In Proceedings of the Human Factors and Ergonomics Society,
39th Annual Meeting, October 24-28, Nashville, TN, pp. 315-319, Santa
Monica, CA Human Factors and Ergonomics Society, 1994.
Hix, D. and Hartson, H.R. Developing User Interfaces: Ensuring
Usability Through Product and Process. New York, NY: Wiley, 1993.
Holtzblatt, K., and Beyer, H. (Eds) Requirements Gathereing: The
Human Factor. Communications of the ACM/Special Issue, 38(5), May,
1995.
376
Appendix D
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, and
Conduct Effective Tests. New York, N.Y.: Wiley, 1994.
Whiteside, J., Bennett, J., and Holtzblatt, K. Usability Engineering: Our
Experience and Evolution. In Handbook of Human-Computer
Interaction, Martin Helander (Ed.). Amsterdam: Elseiver Science Pub.
Co., 1988.
Wiklund, Michael, E. Ed. Usability in Practice: How Companies Develop
User-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.
Appendix D
377
Bibliography
378
Appendix D
Index
A
accelerators, 125
actions
representing with symbols,
188
alignment
in dialog boxes, 269
analog conrols
guidelines, 297
analog control
guidelines, 296, 297
analog controls
guidelines, 295
placement, 296
when to use, 296
application registration files,
118, 131
applications
accessing from keyboard, 31
quick access to, 31
usability principles, 29
audio
using to provide cues, 31
C
chart presentation format, 156
check box
default action, 287
default value, 287
guidelines, 286287
label, 286
placement, 286, 288
when to use, 286
child window
selection, 222, 226
color
coding, 31
Java System Color Variables,
57
link color, 55
colors
in web applications, 55
Index
using in symbols, 206

combo box
default action, 293
default value, 293
guidelines, 291293
labels, 292
list entries, 293
visual cues, 293
when to use, 292
combo boxes
labels, 292
complexity
compound presentation status,
248
computer views, 173
connection symbols
classes, 196
connections
assigning symbols, 187
container object, 178
container objects
representation of, 172
containment relationships, 32
context, 215
concepts, 25
effect on menus, 117
effect on toolbars, 131
generic, 215
identifiers, 214
session information, 47
submap, 213
context area
in web application, 68
context controls, 135
context list, 135
context tabs, 135
in multipurpose presentation
managers, 90
contols
option button, 282
using symbols with, 271
control frame, 74
controls, 263
analog controls, 295
check box, 286
default values, 272
ellipsis in, 271
gauge, 295
graying, 271
grouping, 319
input validation, 274
labeling, 270
punctuation in label, 270
push button, 277
radio buttons, 284
See also specific type, 277
slider, 295
spin box
, 293
text box, 289
visual cues for, 270
conventions
typographical, 13
cues
filling connection symbols, 261
flashing symbols, 256
for drag and drop, 234
for recursive selection, 229
highlighting, 255
in graphics, 198
in menus, 123
in navigation tabs, 162
in the scope pane, 143
status colors, 245
symbol alerts, 249
transparent symbols, 257
customization
description bar, 133
toolbars, 130
D
default action
check box, 287
combo box, 293
379
Index
gauge, 297
grid, 313
lists, 300
multiple selection list, 300
of option buttons, 284
push button, 281
radio buttons, 285
single selection list, 300
slider, 297
spin box, 295
table, 313
text box, 291
tree list, 306
default actions
use of, 275
default value
check box, 287
combo box, 293
gauge, 297
option button, 284
radio buttons, 285
slider, 297
spin box, 295
text box, 291
default values
controls, 272
list box, 300
table, 314
tree list, 306
description bar, 133
customization, 133
dialog boxes, 263
alignment, 269
complexity, 271
controls, 277324
design, 265
field sequencing, 269
focus, 265
help, 268
menus, 266
modal and modeless, 272
push button placement, 278
380
resizing
, 268
size, 267
title bar, 265
documentation
accessing information in, 337
designing for audience, 335
guidelines for structure, 333
localizing, 339
organizing, 333
recommended contents, 337
specific guidelines, 335
types of manuals, 333
double clicking
affect on selection, 224
drag and drop, 234
changes in instrumentation
space, 239
containers as drop targets, 237
drop target help (OVW), 240
executable symbols (OVW),
240
executable symbols as drop
targets, 238
in OpenView Windows, 239
leaf level symbols as drop
targets, 238
views as drop targets, 235
visual cues, 234
E
ellipses, on button labels, 271
events
using vs. visual cues, 244
exception driven approach, 21
executable symbols
appearance, 259
F
field
defaults, 272
fields
alignment, 269
labeling, 270
text box, 289
filter
grid, 311
table, 311
filters
focus
font size
windows, 266
fonts
form presentation format, 157
for properties, 159
forms
frames
in web applications, 63, 65
G
gauge
default action, 297
default value, 297
labels, 296
placement, 296
gauges
when to use, 296
geometry, 215
graphical presentation format,
151
graphics, 171, 197
creating, 204
cues for classes, 193
for actions, 205
in HP OpenView Launcher, 45
in toolbar buttons, 129
Index
Index
localization, 205
overlay, 207
see also symbols, 171
size, 204
using existing, 197
visual cues, 198
grid
default action, 313
editing cells, 310
filter, 311
guidelines, 307314
input focus, 310
keyboard navigation, 313
labels, 309
placement, 309
selection, 312
sequencing, 311
when to use, 308
group boxes, 323
group selection, 228
using containers, 229
grouping
controls, 319
guidelines, 319324
use of group box, 322
use of line separator, 321
use of panes, 322
groups
concepts, 28
guage
guidelines, 296
H
help, 126
on dialog boxes, 268
highlighting symbols, 255
reporting status with, 255
HP OpenView Web Launcher
see web launcher, 39
HTML
using for web applications, 65
Index
I
iconic presentation format, 151
iconic presentation formats, 171
layout algorithms, 182
icons
see symbols, 171
images
independent views, 182
information coding principles,
30
information presentation
managers, 86
results pane, 88
scope pane, 88
when to use, 87
information update
J
Java applets, 49
in Java Frame, 49
in web browser, 50
Java applications and applets,
67
K
keyboard access
in menus, 124, 125
keyboard navigation
in a grid, 313
in a table, 312
in a tree list, 305
in iconic presentation format,
151
keyboard, to access application
actions, 31
L
labels
capitalization, 270
check box, 286
combo box, 292
combo boxes, 292
controls, 270
for application actions, 32
gauge, 296
grid, 309
list box, 299
menus, 122
option button, 283
push button, 279
radio buttons, 284
single selection list box, 299
slider, 296
spin box, 294
tab controls, 315
table, 309
text box, 288
tree list, 302
visual cues, 270
leaf level objects, 179
representation of, 173
list box
default action, 300
default values, 300
find capability, 299
guidelines, 297, 298, 299, 300,
301
labeling, 299
labels, 299
placement, 299
sequence of items, 299
use of multiple selection, 298
use of single selection, 297
lists
general guidelines, 299
guidelines, 301
logical sequence, 303
selection, 221
381
Index
temporal sequence, 303

localization of documentation,
339
M
menu
design, 109
menu bar, 109
File/container menu
menus
File/container
menu,
109
general purpose menus, 110
sequence, 115
menus, 109
accelerators, 125
Action, 113, 117
affect of context, 117
118
depth/levels of menus, 121
Edit, 110
for managed objects, 112
for navigation tabs, 161
general purpose menus, 110
Help, 110
help for, 126
in split windows, 99
labels, 122
mnemonics, 124
number of items, 120
pop-up/context, 116
separators, 124
sequence in menu bar, 115
structure, defining, 119
Tools, 117
View, 110
visual cues, 123
mnemonics, 124
382
multiple pane windows, 96

when to use, 96
multiple purpose presentation
managers, 89
context tabs, 90
results pane, 90
scope pane, 90
when to use, 89
multiple selection, 222
across results panes, 226
across views, 224
multiple selection list
default action, 300
multiple selection list box
placement, 299
when to usf, 298
N
navigation
interaction with selection, 223
navigation tabs, 160
in task presentation managers,
82, 84
labels, 165
menus, 161
new windows, 163
states of, 160
visual cues, 162
new window
with navigation tabs, 163
O
object
hierarchies of, 171
object presentation managers,
77
results pane, 77
scope pane, 77
when to use, 77
objects
assigning symbols, 186

container, 178
creating a hierarchy of, 175
leaf level, 179
linked, 179
placement in an existing
hierarchy, 174
representing attributes, 180
representing related objects,
180
when to represent with
symbols, 171
option button
default action, 284
default value, 284
guidelines, 282284
in Windows NT see radio
button, 282
label, 283
use of, 282
overlay graphics, 207
overlay, submap window, 217
P
panes, 324
persistent submaps, 212
pictorial presentation formats,
152
placement
analog controls, 296
checkbox, 288
checkboxes, 286
gauge, 296
grid, 309
list box, 299
multiple selection list box, 299
of push buttons, 278
radio buttons, 285
single selection list box, 299
slider, 296
spin box, 294
tab controls, 315
Index
Index
table, 309
tree list, 302
pointer navigation
in a tree list, 306
pop-up menus, 116
in scope pane, 143
presentation formats
in the results pane, 149
presentation managers
concepts, 24
information presentation
managers, 86
multiple purpose presentation
managers, 89
object presentation managers,
77
task presentation managers,
79
presentation manages
use of information
presentation managers, 87
use of multiple purpose
presentation managers, 89
use of object presentation
managers, 77
use of task presentation
managers, 80
principles
for accessing actions, 31
for general usability, 29
for information coding, 30
for representing relationships,
32
progress indicator
properties
presentation of, 159
using a form presentation
format, 159
punctuation, in control label,
270
push button
at bottom of window, 278
Index
availability, 281
default action, 281
for whole dialog box, 278
guidelines, 277282
label, 279
placement, 278
sequence, 279
size, 279
visual cues for, 281
when to use, 277
Q
quick access
using navigation tabs, 160
R
radio button
guidelines, 286
radio buttons
default action, 285
default value, 285
guidelines, 284??
label, 284
placement, 285
when to use, 284
recursive selecton, 228
relationships
containment, 32
representing, 32
see connections, 187
results pane, 72, 148
chart presentation formats,
156
form presentation formats, 157
graphical presentation
formats, 151
in a task presentation
manager, 80
in an information presentation
manager, 88
in an multiple purpose
presentation manager, 90
in an object presentation
manager, 77
interaction with scope pane,
140
presentation formats, 149
tabular presentation formats,
153
with icons, 151
S
scope pane, 137
hierarchy, 138
in a multiple purpose
presentation manager, 90
in a task presentation
manager, 80
in an information presentation
manager, 88
in an object presentation
manager, 77
interaction with results pane,
140
leaf level items, 140
pop-up menus, 143
visual cues, 143
with filters, 146
scope pane windows, 93
splitting, 98
when to use, 95
scoping pane
scrolling
security
basic measures for the web, 53
HP OpenView Launcher, 45
user roles, 53
security, in web applications, 53
selecction
383
Index
in tables and grids, 312

selection, 221
basic model, 221
double clicking, 224
in a child window, 222, 226
in a tree list, 303
in presentation managers, 230
in tree list with checkboxes,
228
indicator, 223
interaction with navigation,
223
lists, 230
modifying OVw list, 232
mulltiple, 224, 225, 226
multiple, 222
of groups, 228, 229
single, 222
selection list
providing access to, 231
sequence
of push buttons, 279
sequencing
grid, 311
in tree list, 302
table, 311
shared submaps, 211
single pane windows, 96
when to use, 96
single selection, 222
single selection list
default action, 300
single selection list box
labels, 299
placement, 299
when to use, 297
size
of text boxes, 290
slider
default, 297
default action, 297
guidelines, 295, 296, 297
384
labels, 296
placement, 296
sliders
when to use, 296
spin box
default action, 295
default value, 295
labels, 294
placement, 294
when to use
, 293
split windows, 98
menus, 99
scope pane, 98
specifying content, 98, 99
toolbars, 99
status
compound presentation, 213,
248
conflicts between applications,
247
in task presentation managers,
83
reporting by object, 247
reporting by symbol, 248
status area, 74
status bar, 167
status colors, 245
status source, 247, 248
setting, 247
submap window
geometry, 215
overlay, 217
submaps
in NNM, 211
independent, 182
persistent, 212
shared, 212
shared vs. exclusive, 211
transient, 212
symbol alerts, 249
guidelines, 250
removing, 251
severity levels, 250
text annotation, 254
types, 251
user interaction, 251
when to ue, 250
symbol design
creating new connection
classes, 196
creating new object classes,
195
graphical cues for classes, 194
guidelines, 190
using existing classes, 190
symbols, 171, 206, 255, 259, 271
annotating, 254
assigning to connections, 187
assigning to objects, 185, 186
changing type, 209
classes, 190
connection, 207, 261
connection line style, 207
connection subclasses, 207
connection thickness, 208
creating new subclasses, 204
flashing, 256
for representing objects, 171
highlighting, 255
new subclasses, 204
see also graphics, 171
software utilities, 188
subclasses, 197
symbol types, 185
to represent actions, 188
transparent, 257
user addition of, 210
user modification, 209
using existing graphics, 197
T
tab categories
for web launcher, 40
Index
Index
tab controls
bottom placement, 316
guidelines, 314318
horizontal alignment, 316
labels, 315
multiple rows of tabs, 317
top placement, 316
vertical alignment, 316
visual cues, 318
when to use, 80, 315
table
default action, 313
default values, 314
editing entries, 310
filter, 311
guidelines, 307314
input focus, 310
labels, 309
placement, 309
selection, 312
sequencing, 311
when to use, 308
tables
tabular presentation format, 153
for objects, 154
task based approach, 21
task presentation managers, 79
related tasks, 84
results pane, 80
scope pane, 80
status, 83
use of navigation tabs, 82, 84
use of push buttons, 81
when to use, 80
task support, 84
text annotation, 254
user interaction, 254
with symbol alerts, 254
text box
data entry, 289
default action, 291
Index
default value, 291

editing, 289
guidelines, 287291
labels, 288
read only, 289
scrolling, 290
size of, 290
visual cues, 289
when to use, 288
title bar, 106
contents, 106
dialog boxes, 265
inweb applications, 67
tool bar, 127
toolbar
affect of context, 131
131
buttons, 129
customization, 130
graphics, 129
structure, 130
toolbars
content, 127
user control, 128
when to use, 127
transient submaps, 212
transparent symbols
when to use, 257
tree list
default action, 306
default values, 306
guidelines, 301306
labels, 302
placement, 302
pointer navigation, 306
selection, 303
sequencing, 302
when to use, 301
U
user approaches, 21
user guided approach, 22
user roles
guidelines for setting, 47
in HP OpenView Launcher, 46
V
Vision
for HP OpenView applications,
20
visual cues
controls, 270
filling connection symbols, 261
flashing symbols, 256
for drag and drop, 234
for recursive selection, 229
general, 243
highlighting, 255
in graphics, 198
in menus, 123
in tab controls, 318
push button, 281
status colors, 245
symbol alerts, 249
transparent symbols, 257
using to report object
conditions, 244
using vs. event, 244
W
web applications, 37
colors, 55
context area, 68
control frame, 74
fonts, 60
forms, 66
frames, 63, 65
385
Index
graphics, 60
HTML, 65
images, 60
in web browser, 49
launching, 39
link color, 55
navigation, 49, 62
progress indicator, 51
results pane, 72
scoping pane, 71
scrolling, 61
security, 53
status frame, 74
tables, 65
title bar, 67
toolbar, 68
type of browser window, 51
updating information, 63
use of browser controls, 52
use of named windows, 54
use of patterns, 59
window components, 67
web browser, 49
type of window, 51
web launcher
concepts, 24
description, 39
object tab, 42
registration guidelines, 41
security, 45
session information, 47
tab categories, 40
task tab, 43
tools tab, 43
user roles, 46
web launchrs
graphics, 45
window components
identifying, 105
windows, 92
creating new, 101
multiple pane, 96
resizing, 268
386
reuse of, 101

scope pane, 93
single pane, 96
size, 267
splitting, 98
types of, 93
wizards
when to use, 80
Index

j1261 90006

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

j1261 90006

Uploaded by

Copyright:

Available Formats

HP OpenView Application Style Guide

Windows NT Operating System, HP-UX, and Solaris

Manufacturing Part Number: J1261-90006

Copyright 1996 AirMedia, Inc.

1. Introduction and General Principles for HP OpenView Style

Use of Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Web Applications Based on HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Using Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

Description Bar Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Scope Panes With Hierarchies of Items . . . . . . . . . . . . . . . . . . . . . . .148

Assigning Symbols to Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

User Modification of Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

7. Object Selections, Grouping, and Drag and Drop

Affects of Navigation on Selection . . . . . . . . . . . . . . . . . . . . . . . . . .233

Symbol Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Default Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .284

Default Action and Default Values . . . . . . . . . . . . . . . . . . . . . . . . .

10. Miscellaneous Guidelines

Color Values in the Limited Color Palette . . . . . . . . . . . . . . . . . . . . . 365

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

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

What the Font Represents

For book or manual titles, and for manpage

Refer to the OVW Developers Guide.

You must follow these steps.

To specify a variable that you must supply

At the prompt type: rlogin

For glossary terms.

The distinguishing attribute of this

Text and items on the computer screen.

The Root map window ...

The system replies: Press Enter

Use the grep command ...

File and directory names.

Check to see if pmd is running.

Window/dialog box names

In the IP Internet map window...

Text that you must enter.

At the prompt, type: ovstatus.

Buttons on the user interface.

Click [NET]. Click on the [Apply]

A menu name followed by a colon (:)

Your comments on and suggestions for the documentation help us

For information on current HP OpenView training available, see the HP

Introduction and General

Introduction and General Principles for HP OpenView Style

This chapter discusses:

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style

User Approaches to Management

Exception Driven Approach

Task Based Approach

Introduction and General Principles for HP OpenView Style

User Guided Approach

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style

Menu Placement Rules

Introduction and General Principles for HP OpenView Style

Introduction and General Principles for HP OpenView Style