THE INTERFACE OF MAN AND MACHINE

Mar 1, 2000 12:00 PM, Steven Placek

Have you taken the time lately to look at the information screens of workstation monitors for new security systems? The interfaces are becoming increasingly complex: a typical screen is a combination of tabs, windows, toolbars, colors, queues, pictures, jargon and data. Comparing the screens from one supplier to those of another reveals striking differences.

The Smithsonian Institution's problem Computer-user interface issues were a concern recently at the Smithsonian Institute in Washington, D.C. In planning to replace an old proprietary security system at the Smithsonian, the Office of Protection Services expected to confront complex electronic, hardware and software challenges. A new electronic security monitoring scheme required developing, installing, and operating systems for more than 13 museums and facilities in the Washington area. The new system had to support nine control rooms, each operating 24-hours-a-day in a networked environment. The density of displayed exhibits and artifacts in each facility would create intense information demands on the system. Additionally, the Smithsonian's security staff sought to employ as much off-the-shelf technology as possible. Staff planners prepared, therefore, to analyze available industry standards and system configurations.

However, planning for the new system interface had an unexpected impact on security operations. The old system had to go, and discarded along with it was a virtual culture of terminology, technical administration, procedures, and electronic security philosophy. More than 75 control room operators and technical staff had to reengineer processes for alarm definition and programming, alarm response procedures, maintenance and training. Surprisingly, many of the decisions about the system interface would affect these processes dramatically. The new computer screens would have to convey coherent and useful information for thousands of alarm, CCTV and access control points, and they would become the direct and indirect context for a wide range of new security activities for hundreds of employees.

The role of the interface The interface is one of the most important aspects of security systems. Agencies such as the Smithsonian rely upon their operators to interpret system information correctly and act appropriately to ensure security responsiveness. Complex interfaces can hinder operators; training to prevent errors can be expensive.

System interface design has gained attention in the information system industry, but in the security industry, customers rarely incorporate interface design into the process for system installation. Nor are detailed interface specifications normally considered a criterion in the competitive process for system selection. After system selection and installation, users often end up adapting to the interface the manufacturer offers.

Evolution of the Windows desktop interface With greater frequency, businesses and government agencies demand that Windows NT operating systems comprise the platform for new security system installations. Almost all security system manufacturers now field first-generation Windows NT systems. Second-generation beta-test NT systems are now emerging, which provide more sophisticated information management and database capability for multiple servers installed in complex facilities.

Generally, manufacturers have adapted features of past UNIX, OS/2, or, more recently, Windows '95 systems, to new Windows desktop workstations. In many cases, new security information features have been added, as a simple point-and-click benefit of the Windows environment. As a result, the desktop interface presented to operators and administrators has transformed security applications.

The inertia of system development in industry, although somewhat unexamined, ensures that the Windows desktop will be the primary interface for security systems in the future. Within the context of a Windows environment some important usability heuristics can apply to improve system interfaces and enhance operator performance at a facility.

Guidelines for security systems interfaces Our research reveals many good sources of information about basic principles of usability engineering for information systems in general. These principles advocate sound standards of clear and concise graphical presentation and design. The guidelines provided here summarize some of those principles as they apply to security systems. Lessons drawn from the Smithsonian application provide some basic interface usability heuristics for companies contemplating the purchase of new security systems.

#1 Include interface considerations into design process. Studies have demonstrated that more than 50 percent of software developed for information systems is dedicated to the code for the user interface. It is unknown what percentage of resources security system manufacturers obligate to interface issues, but it is reasonable for customers to establish criteria to ensure the usability of these interfaces early in the selection or the design process of a new system.

System manufacturers violate principles of good usable interfaces all the time. Some aspects of "vanilla" applications can be quite illogical and humorous, or reflect contorted adaptations to a specific facility or corporate need. Often, a manufacturer's interface connotes its corporate business and client evolution, its transition from old software to new software, and its security philosophy. Beneath a given icon or tab lies a chasm of informational priorities decided upon in advance, before installation for a customer.

#2 Set standards for color, motion, and sound. Basic interface design specifications should address color, motion, and sounds on the screen. Colors should be limited on the interface screen to between five and seven colors. Alarm status information should use red, green and yellow. Flashing colors - instead of additional colors - can be used to indicate various alarm-processing states. For example, an initial alarm announcement may display red on the screen. After the operator acknowledges the alarm, the alarm may flash red until the operator resets the alarm.

Bright, loud, and screaming multi-colored designs may be good for brash young corporate web pages trying to get your attention, but they are poor at communicating helpful sensitive information to operators required to stare at screens for hours each day. Background colors should be muted. Light grays and pastels are best. Ideally, the security system interface should be able to convey the same amount of information in the monochrome state as it does in the color screen mode. It might be helpful to know how many users test for color-blindness in their alarm system operators - a trait residing in approximately seven percent of the population.

Most alarm system manufacturers violate the monochrome principle, since often a change in color differentiates or categorizes alarm states. At least two manufacturers of systems researched cited the colors "magenta" and "cyan" in their user manuals to designate control states of alarm zones. Manuals for these systems were printed in black and white, making interpretation even more problematic. Lime green, in conjunction with and as opposed to regular green, is a color showing up more frequently on security system screens, but designs should avoid "fruit salad" effects.

Careful interface design will de-emphasize color. Additional icons, words or marks (such as an "x" to reflect cancel) on tabs and buttons will be necessary to convey information about alarm system information. Informal usability interviews with control room operators at several agencies demonstrated that most operators pay attention only to green and red anyway. Operators have difficulty correctly stating aspects of system status based upon other color indicators.

The typical Windows desktop generates some well-known pings and pleasant musical crescendos. Our research showed that many agencies rely upon the very brief Windows ping default as alarm notification. Over time, these sounds fail to incite operators to act. Alarms should generate noise that is more vibrant than pleasant, and they should resonate until operators complete initial alarm processing activities.

The system manufacturer should allow font size and color for dialogue and alarm information boxes to be altered. Several systems we researched could not vary upper case and lower case letters and alter colors in messages. The size and the complexity of the facility and items secured will often determine the length of long location messages. But large 64-character messages, such as the one below

"SMITHSONIAN /MUSEUM OF NAT HIST/THIRD FLOOR/DINOSAURS EX/BONE CASE"

can be made more readable by breaking up font size and capital letters such as

"Smithsonian / MUSEUM OF NAT HIST / Third Floor / DINOSAURS / Bone Case"

Judicious use of color, bold, and flashing would further enhance readability.

#3 Organize space sensibly on the screen. Security manufacturers vary more widely in use of screen space than in any other interface issue. Alarm queues represent the most challenging issue for alarm system interfaces.

Some manufacturers display an incoming alarm on one part of a screen and then move the alarm to a different queue after the operator processes the alarm. An additional third queue on the screen may be required for operators to ascertain alarm point information after annunciation but prior to acknowledgment or alarm reset. Other manufacturers simply display a running queue of all alarm events on the screen. Color indicators usually designate whether the alarm has been processed or not. Additional alarm status information is hidden behind the screen, requiring informed point-and-clicks on tabs or buttons on the running queue itself.

Both examples above have advantages and disadvantages. Depending upon the amount of alarm activity, running queues may quickly take up the entire screen and sequence from the bottom to the top of the screen in large facilities. Alarms may actually depart the queue while the operator still needs to see them. On the other hand, running queues tend to display higher numbers of alphanumeric characters on the queue, which may be valuable to an operator trying to determine information quickly.

Multiple queue screens make better use of space to categorize the sequence of alarm activity. But they do so at the expense of providing limited information to the operator on the screen without further point-and-clicks. Since there are multiple queues, there are reduced alphanumeric characters, sometimes so few that an operator will not have complete information from viewing the initial interface screen. Multiple queues can also make the screen look busy.

As a rule, customers must make decisions about the initial and short-term historical information captured on the first system alarm screen. All other information should be accessed behind the screen through tabs or point-and-clicks. Important and immediate information should be displayed in the top left-hand corner. Only unauthorized activity on the system should be displayed, limiting the potential for "run-off" queues.

Windows desktops display multiple layers of screens with gradual reductions of screen space. The immediate system alarm screen should be maximized and contain all the immediate information required for an operator to respond appropriately to an alarm. Multiple minimized number of screens should be limited. Remember that operators will have to move from one screen to another to complete all alarm processing activities.

#4 Simplify screen displays to meet specific user tasks of users. Most large agencies divide users into groups such as operators, system administrators and maintenance technicians. Manufacturers generally install the one-for-all Windows screen at every user desktop. However there is no reason for all groups to see the same interface screens. In particular, operators whose primary purpose is to ensure proper alarm response and convey alarm status information need not have access to tabs, icons and windows for editing alarm definitions, adding or deleting alarms, or changing dialogue box information.

As system administration and maintenance become more software-dependent, it will be more important to limit operator access to sensitive alarm administration activities. This compartmentalization will also make training easier and less expensive.

#5 Limit excess maps and metaphors. The consistency of metaphors is an important part of interface design. Strictly speaking, all interface activity is a metaphor for activity going on in the field. Windows desktops generally convey hierarchical analogies for processing administrative activities. Drop-down menus are deductive (e.g. FILE: New, Open, Close). Alarm manufacturers generally carry this logic over to alarm information screens, but the exigency of alarm response carries potential conflicts with hierarchical understanding.

Most interfaces afford the operator an opportunity to access alarm information directly. Many of the map displays that manufacturers offer allow an operator to point-and-click on a map icon (signifying an alarm point) and then to access information without going back through administrative tabs and menus.

For alarm system operator screens, hierarchical paths should be limited. Hierarchy goes against the basic premise of object-oriented interfaces. Operators should be allowed to access alarm information without concern for zones, local processing status, or an understanding of the difference between concepts such as monitor and control points.

Map displays should be consistent with alarm and zone definition format. If it is necessary for the zone definition to format buildings, floors, rooms and vaults, then there should be some sort of map metaphor for those definitions. Alarm information and dialogue boxes should also be displayed along with map displays. Some system require the operator to click back and forth from the map to the alarm information screen to transmit information to a security officer on the floor.

#6 Evaluate basic security terminology. Terms such as "acknowledge," "process," "silence," "mask," "bypass," and "reset" may designate different security concepts for different systems and users. Most likely, a new system with new terminology will generate some confusion in training and operations for those experienced with the "old system."

Terms such as "account," "zone," "control point," and "monitor point" are not so much defined on the basis of some standard security concept, but on the basis of the evolution of the system interface for past manufacturer clients throughout the years.

Terminology and words used on the interface should be precise and concise. Several current systems repeat the same term in title bars, menus and tabs with different consequences. For example, clicking on "status" in the title menu of one manufacturer indicates local processor state. In a tab, which is displayed simultaneously, however, "status" shows the condition state of an alarm point.

#7 Review errors and error messages on the system. Research showed that the most frequent error by operators on Windows-based interfaces occurred when operators inadvertently clicked on the "close" button of the title bar. For several manufacturer system prototypes, the system had to be rebooted with technician help. Windows-based security system interfaces have many more screens and menus than normal desktop operations. Uninformed point-and-clicks can lead to a variety of system administration difficulties.

Default error messages, usually encouraging the operator to find system administration help, can also be a source of frustration for operators. Error messages, when possible, should not provoke operators to guess what is wrong, and messages should speak the same language as the user. The most common error message noted in research was when an administrator had placed the icon for a map link on an alarm tab, without providing the map. When clicked, the message read, "global map sys error; see system administrator for help," leading one to think of much more tragic consequences than necessary.

In the face of error messages, shortcuts for operators to exit the function should be clearly marked. In the example cited above, the lack of a system map should not hinder the operator from performing the rest of alarm response activities.

#8 Interview operators and conduct focus group tests.

Although in-depth interface studies may not be possible or budgeted, it is remarkable what information about the interface can be learned from operators. Ask them what the colors on the screen mean. Ask them the difference between terms on the tab and the menus. Ask them to identify the problems and frustrations they have with the system. You will be amazed and surprised.

If limited focus group tests on interface prototypes are performed, some simple principles can apply. For example, how easily can an operator perform necessary security operations with no training on the interface? Remember, every day millions of people access automatic bank withdrawal screens, airport flight arrival and departure times, shopping mall touch information screens with no training. Why should alarm system screens be much different? Focus groups should evaluate repetitive designs of screens. Once one group has provided input, another focus group should evaluate the results.

#9 Implement procedures into training. The interface is the primary training device for security systems. If the operator interface screen is developed for the operator only, it will be easier to add and delete training items in the curriculum that will enhance operational effectiveness.

When possible, all operational procedures should be developed and documented prior to system training. Training interfaces should replicate the database, graphics and maps exactly as they will display information at the user workstation. Depending upon class size, all training screens displayed on overheads should match training interfaces for each student in the classroom. Practical event scenarios should stress how an operator should respond to a particular event, rather than negotiating the ins and outs of a complex interface.

Ensure students are thoroughly familiar with the Windows operating system environment. System manufacturers generally overlook this issue.

#10 Consider several documentation help models. It is counterintuitive to wade through a faintly thrice-copied user manual to resolve an obscure computer error message. Security system manufacturers are deficient in providing on-line help screens for their applications. Additionally, software improvements rapidly outpace manufacturer's ability to document them and supply them to the users.

Agencies should consider requesting alternative help and documentation models. For example, laminated flash help cards can be produced to remedy the most frequent errors. CD-ROM training and help tools can emulate the interface. Integrated with operations and procedures, the CD-ROM can be a tremendous help in limiting errors and providing operational continuity. Manuals, if necessary, should be minimal, and like the interface should only convey absolutely essential information for the specific user task.

A typical slogan for computer desktop users is that there is no such thing as "WYSWYG" (What you see is what you get) on the interface screen. But it pays for agencies to be attentive to what they want to see on their security system interfaces, before committing millions of dollars to design and selection of security systems in their facilities.

Want to use this article? Click here for options!
© 2008 Penton Media Inc.

This month in Access Control

• Opening Up About Door Closers
• An Enterprise Approach
• The Framework For Open Systems
• On A Higher Plane
• More from April's issue