WlD'ilVffiWlD(1

OOl5aJlDl5 f

November 1981
THE PPC IS CCMING!
Future Powerful Personal Computers:
:: :::::! 7J. ..... .. ::r::::
CRYPTIC CROSSl.,rORD (U) -------r:::::.... 14
SAY WHAT YOU MEANC' (U). .;. W Gaddv.. i ...... ../ 15
HOW TO CREATE A U.,ER-UNFRIENDLY (U)...... . 17
OPELINT IS ALtVE AND WELL IN B GROUP (3)....... 25
REVUJoJ: '.Jhat do you think? (U)................. . 29
TillS DOClJi\UlNT CONTAINS eOBEWORB MA'fERIAI:J
GL'tSSIFIEEl B USA/CSS., 123-2
REVIS,t ON 10 New 2Gl11
Declassified and Approved for Release by NSA on '10-'1.2-.20'1.2 pursuant to E.O. '135.26.
vl DR Case # 54778
DOCID: 4009838
Published hy P1, Techn iques and Standard s,
for thO!! Personnel of ():>erations
VOL. IX, No. 11
PU9LISHFR
90ARD OF

Production ....... . 1 b369s)
FDITORIAL
The response to our cry for hel p in keeping
our subscription lists up to date has been
hearteninF,. "Thanks. me "active" nalle on our
list has been out of the ?gency for several
years j many others have moved.
Along with the resoonses, we h1'lve been get-
tinl2; questions along the 1ine of "Is CRYPTOLOG
sUIl alive?" (we think so) and "Is it
to be merp;ed with some other puhlication?" (we
have no plans to merge with any other puhlica-
tion, and none has so far expresset"l eny
interest in inp; wi th us). We are a DfY)
(Operations) puhlication, but it is clear from
our subscription 1ist and our author 1ist that
we range outside the physical confines of DOO.
If we don't seem to be publishing any art.i-
cles about your area of interest, it is either"
because the editor is biased against your area
of interest," or because he isn't getting any-
thing al'lout your area of interest that can be
published.
M:>st of the layout and ed iting of CRYPTOLOG
is now being done on a computer - actually on
several canputers. Using the tNrX
with some help from PTNgmER, and the PLAT-
FORM network between various host computers,
the original keystrokes (often the author's)
are retained throughout the process. A lot of
retyping, as well as cutting and pasting that
characterized the earlier issues (all done on
a typewriter) is being avoided. Q1e it'!!!l1.r1
I Ipiece last month on Technic91
port Catalogs, was coordinated him in
final form just before publication via the
network (Ken is now stationed/in Germmy).
to CRYPTQLOG. r
or call1.3369S
To submit articles or letters
via address to
crypto1g at bar1c05
(note: no '0' in 'log')
About half of the i now being worked on
for this and have cane in over
the network. \o(e are still interested in
receiving fran people not on the net-
v.ork. We C\on't mind typing. even though it's
nice to have some items that don't require it.
V
P.L. 86-36
UNCLASSIFIED
mrtJRE POWERFUL PERSONAL COMPUTERS:
An Overview of the Teclmology
byl
P.L. 86-36
I
cientific and analytic computing,
'::!' .. especially at NSA, has evolved from
.. the.batch.envirol'lllent of the 1960's
, to the timeshar ing and mul tiprocess-
ing envirol'll1ents of the 1970's. In
the 1960's, typical progranmers submitted 'a
deck of punched cards to the batch system CIld
later rece1v&a the deck and a listing of the
progran execution. In this envirol'lllent, both
the computing power and the user's access to
this power were remote and non-interactive.
In the timesharing environnent of the late
1970's (and of today), the progranmer has
direct, timely, interactive access to his or
her computing processes through a terminal.
In this envirol'll1ent, the computing power is
still' remote, whether in the next room or far
away across a netW>rk, and is shared. J-bw-
ever, the user's access to this power is
potentially local and definitely interactive;
hopefully, the access terminal is on or near
the user's desk.
What will scfentific and analytic computing
be like in the 1980's? While it can be argued
that very large-scale super cClJlputers like the
Cray 1 will definitely be needed for many com-
plex problems (10J, advances in several areas
of computer tecmology have spurred efforts to
design and. produce extremely powerful,
extremely compact computer systems for scien-
tific and analytic use. &Jch systems will be
small and inexpensive to be
single-user systems located at the user's
desk. In a sense, these systems will enable
users to have their 0'-11 "VAX" or "370" instead
of a terminal. In this envirol'll1ent, both the
computing power and the user's access to it
will be local, personal, and highly interac-
tive.
The purpose of this paper is to discuss
capabilities being proposed for such a comput-
ing system, how it may be realized, and Io'hat
its impact on NSA scientific and analytic com-
puting might be. J-bw should this future
system be described? Some papers on the sub-
ject call it a personal computer (4, 12J.
While it will be personal, this label conjures
up images of the TRS-80 or the Apple II - a
totally inappropriate image. other papers
[13) refer to it as an intelligent terminal.
At NSA, this term fits the Delta Data 7000,
for it is a terminal with its 0'-11 microproces-
sor. The powerful future system is M)T a ter-
minal; it is 'IHE computing system and may be
more powerful than systems to Io'hich we inter-
face intelligent terminals today! For lack of
another nane, this paper will refer to this
system as a Powerful Personal Computer (PPC).
The PPC has the potential to revolutionize
scientific and analytic computing at NSA.
Even with the GTSS and other timesharing sys-
tems of today, analysts use' terminals to gain
access to remote, shared computing power and
data over relatively low-speed connections
(Io'hether netw>rk or communications lines).
The PPC will give the analyst access to signi-
ficant local, individual computing power and
data. Netw>rks and communications lines today
are used to gain access to all computing
power ,all data, and personal comml.l1ications.
In the PPC env irol'll1ent, netw>rks
will be used for access to very large data
bases and shared resources and for electronic
personal comml.l1ications. This will be a dras-
tic change from our present netW>Y'king philo-
sophy.
Nov 81 CRYPI'OLOG Page
UNCLASSIFIED
DOCID: 4009838 UNCLASSIFIED
II. Olaracteristics of a Powerfui PersOnal
Canputer
7 aud io input and output ;
8. ease of interfacing other peripherals
if desired;
9. a v-ery high-speed local netw::>rk con-
nection;
10. a powerful local operating system
W1ich can be personalized;
Given a PPC with the above characteristics,
an office environment built arol.lld several
such PPC's w::>uld have these additional charac-
teristics:
Al timesharing systems have given
access to remote, general-purpose canputing
rather than to local, personalized canputing,
the environment which has been created is a
rich one for timesharing users. This environ-
ment . has pranoted a large set of programning
languages, large file storage capabilities,
sharing of programs and data, a cooperative
user ccmml.ll itY, and other benefi ts The
environment of the PPC should preserve and
enrich the good characteristics of the
timesharing environment, while bringing many
totally new capabilities to its users.
11. powerful,
languages,
niques.
easily-used programming
utilities, and OOMS tech-
A number of efforts are I.Ilderway to specify
and/or produce a PPC and its envirol'lllent' at
institutions like xerox [12J, Carnegie-Mellon
University [6], MIT [15], Convergent Tecmolo-
gies [16], and Three Rivers Computer Corpora-
tion [13]. While these efforts do not
canpletely share canmon technologies, their
broad goals are remarkably similar and these
goals apply for many scientific and analytic
institutions (including NSA). The individual
PPC envirol'lllent of the mid-1980'S should' be
reasonably priced ($10,000 to $20,000), should
exist in a S1Iall and attractive package for
office use, and' should have the following
characteristics:
1. a very powerful processor or proces-
sors (W1ile this will be implemented
on one chip, the term "microprocesSbr"
seems too limited); it should have
32-bit data paths and use 1-bit, 8-
bit, 32-bit, and 64-bit
operands;
2. a S1Ioothly addressable virtual address
space using as ma'ly as 32 bits of
address;
3. a very large multiport primary
memory- 1 Mbyte or more;
4. at least 100 Mbytes of high-speed
local secondary storage;
5. a 1024x1024 raster display, probably
color with several bits per picture
point (pixel);
6. good interactive devices (keyboard,
graphics pointer, lights, function
buttons) ;
12. a local, high-speed netw::>rk connecting
all PPC 'S the office;
13. a gateway to other netw::>rks;
14. an "office" PPC to support expensive
peripherals \tlich are needed occasion-
ally (e.g., quality printers, massive
disks) and to perform support func-
tions (e.g., mass data transfers fran
distant data bases, local office coor-
dination) ;
15. an "office" file system for camnonly
used databases;
16. a global (to the local netw::>rk)
operating system to allow easy Inter-
PPC sharing of programs, data, and
resources.
Items 13, 14, and 15 could be implemented
in a distributed ma'lner on several PPC' s
across the local netw::>rk or in a centralized
manner using one physical PPC as the "office"
machine to support all office resources. This
paper will assume the latter implementation.
The global or netw::>rk operating system w::>uld
be distr ibuted
The personal canputing environment
described above is more powerful in both
hardware and softwpre than almost all
timesharing systems in use today. Should a
canputing envirorment that powerful really be
used by only one person? Can institutions
like NSA afford to allow such a powerful can-
puting engine to stand idle between' the
Nov 81 CRYPTOLOG Page 2
UNCLASSIFIED

DOCID: 4009838
UNCLASSIFIED
keystrokes of its single user? Yes. Econom-
ics today show that the hardware to imp16llent
a PPC will be reasonably priced in the mid-
1980' s. Some estimates for a PPC as described
above are in the range of $10,000 [6]. (Of
course, an imp16llentation today would be much
more Economics today also show
that the people 10410 do scientific and analytic
computing are becoming more and more expen-
sive. If such people become only moderately
more productive lo41en given a PPC, the invest-
ment is w:>rthlo41ile. The cost of any "wasted"
machine cycles is insignificant compared to
the productivity gained.
While the packaging of the characteristics
of the PPC in the form described will be a
major effort, each characteristic by i tsel f is
not completely new. Each already exists in
some form at some price. Thus the developnent
of the PPC is more of a hardware and software
engineering project, rather than a research
project [6]. This does not mean it will be
any easier; it simply means that the areas to
be explored and developed are not un-known.
III. Hardware Tecmology for the Powerful Per-
sonal Computer
The combination of hardware and software
technologies needed to successfully imp16llent
a PPC with the 16 characteristics listed in
section II does not yet fully exist. It is
important to point out here that we must have
both adValced hardware technology and advanced
software technology to successfully 'implenent
the PPC env irorrnent. One without the other
will lead to failure. This section will dis-
cuss in some detail the hardware technology
lo41ich will enable the PPC to be built; section
IV will discuss the software technology which
will enable the PPC to be successfully used.
The hardware issues fall mainly in charac-
teristics (1) through (9) and (12). The tech-
nology exists today to supply the capabilities
listed in these characteristics, but at sub-
stantial cost and in very large packages not
at all sui ted for an office setting. One
could attempt to meet these characteristics
with the following set of today's standard
hardware:
(1)-(4),(8) a DEC VAX 11/780 computer sys-
tem ($160K);
(5)-(6) a Genisco or Ramtek raster graphics
system ($3010;
(7) input-- 64-word vocabUlary system by
Heuristics ($259);
output-- VOTRAX voice synthesizer ($31<) or
Texas Instrunents 'I?-l990/306 179-word
system ($11<);
(9),(12) an ETHERNET or Mitre bus system
($6K) ;
If this hardware configuration were assembled,
it would cost about $2001< and would require
about 200 square feet of floor space and spe-
cial electrical connections and air condition-
ing. It w:>uld not be sui table for a personal
system on one's desk.
As LSI and VLSI circui t design. technology
continues to make advances, the hardware
pieces needed to satisfy these requirements
will continue to get smaller and less expen-
sive. The remainder of this section will
explore cominR tecmologicaladvances lo41ich
will help realize the PPC.
A. Processor and Address Space
If the PPC is to truly give its users the
power of current multi-user machines like the
DEC VAX 11/780 or the IBM 370, its processor
must have a powerful instruction set, must be
fast, must have a large address space, and
must have wide internal data paths. gingle-
chip processors of the late 1970's (tradition-
ally called microprocessors) have not met
these criteria. AI though their instructions
sets may have been reasonable, their execution
speeds have been moderate, internal data paths
have been either 8 or (sometimes) 16 bits
wide, and direct addressing has been limited
to 64K bytes of m6ll0ry. Because the tern!
"microprocessor" has been traditionally asSO-
ciated with these earlier single-chip proces-
sors, it is inappropriate when discussing the
type of processor needed for the PPC of the
mid-1980's.
The newest generation of single-chip pro-
cessors has made several major advances over
the earlier generation as LSI technology has
grown. As technology continues to grow,
further advances are sure to come. Before
discussinR what the mid-1980's may produc.e for
single-chip processors, a look at current
state-of-the-art processors is in order,
Nov 81 * CRYPTOLOG * Page 3
UNCLASSIFIED
DOCID: 4009838 UNCLASSIFIED
since these processors are being used in
current projects to implement PPC' s. See Fig-
ure 3 for a quick canparison of the Intel
8086, the Zilog Z-8000, and the Motorola M-
68000.
All three of these processors have been
built with some concern for the operating sys-
tems and higher-level languages that must run
on them. Thus, they have instruction sets to
support byte-string operations, bit manipula-
tion, re-entrant code, dynanic relocation,
etc. They all have interrupts,
register sets, and other expected hardware
features. Al though a ranking of the three
may not be fair, their applicability, for a PPC
processor could be ranked in decreasing order
of applicability as (1) M-68000, (2) Z-8000,
(3) 8086. At this point in LSI evolution, the
capabilities of the processor chip will depend
heavily on the surrounding support chips and
coprocessors. When the processor chip of the
mid-1980's inclooes ml:l1Y functions \otIich are
now off-chip, this will not be true.
LSI state-of-the-art technology in 1980
puts about 70K devices on a chip to produce a
Motorola MC-68000. VLSI technology (VLSI is
usually accepted to mean 1001< or more devices
per chip) will" greatly impact the developnent
of more powerful single-chip ccxnputers because
cf increased design density, increased chip
size, and improved layout techniques [7].
state-of-the-art in about 1985 will put
1M devices on a single chip. The single-chip
processor of 1985 (dubbed P1985 in [7]) will
be a much more one than that of
today. When the P1985 architecture can be
realized, a single-chip processor will indeed
be equivalent in functionality to many large
canmerc ial CPU's 0 f tod ay ( e.g. , the VAX
11/780). With such a processor, the PPC as
described in this paper will be realizable.
B. Primary t-'emory
Given a good virtual memory operating sys-
tem for the PPC, significantly less physical
memory is required than could be supported by
the address space. I-bwever, the anount of
physical memory to nicely support multitasking
and to provide image memory for the raster
display is still significant. Because memory
chips will be very inexpensivE' in the mid-
1980's, a primary memory on the order of 1
Mbyte will be an economically sound way to
reduce local operating system swapping over-
head. memory for the raster display
could take an additional 0.1-0.5 Mbytes,
depend ing upon the choice of black-and-whi te
or color.
With present,- proven 16K-bit memory chips,
it would take 500 chips to provide 1 Mbyte of
primary memoryj this would occupy several phy-
sical boards ( perhaps 10) and would occupy too
much space for a PPC. With the 64K-bit chips
now caning into production, only 125 chips are
needed and they can be configured in a much
smaller package (perhaps two boards). With
256K-bit chips on the horizon [4,7], this
shrinks to approximately 32 chips. Depending
upon other design considerations, this entire
1 Mbyte memory might be placed on the proces-
sor board, considerably reducing packaging
size. Texas Instrunents predicts that these
components will be available by 1985 at a cost
of less than $2000 for the 1 Mbyte capacity
[4]
C. Secondary Storage
For the PPC environment to be successful, a
high-capacity, fast secondary storage system
is needed at the individual PPC to hold per-
sonal utilities, prograns, data, and text
files. For this storage system to fit neatly
into an office envirorrnent, it needs to be
canpact. In an office wi th several PPC' sand
an "office" PPC networked together, the
"office" PPC may be required to supply addi-
tional bulk secondary storage. That can be
done with more traditional disk systems and
will not be considered here.
Exanining current work in storage technolo-
gies shows advances in charge-coupled devices
(CCD's), magnetic bubble memories (MBM's) ,
video disks, AND record ing [J]. At
first glance, one might be inclined to
discount magnetic recording as a continuing
attraction for mass storage. I-bwever, many of
the same technological cdvances that are
cdvancing CCD's and MBM's are also advancing
the state-of-the-art in magnetic recording.
In the past 25 years, device capacities have
increased over 100-fold and recording densi-
ties have increased over 1000-foldj similar
dranatic cdvances continue to be pred icted
[J]. Especially wi th the introduction of df'V-
ices 1ike the Winchester disk, which can store
in excess of 30 Mbytes of data on an 8-inch
platter for about $2500, it seems that
netic recording will be the appropriate tech-
nology for the PPC.
Nov 81 * CRYPTOLOG * Page 4
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
D. Raster Graphics and Interactive Devices
In the timesharing environment of today, a
raster graphics system is a peripheral that is
often used in conjunction with a more standard
alphantJlleric systems terminal. In the PPC
environment, the graphics display will be the
ONLY visual presentation to the user and it
will be an integral part of the PPC, not a
peripheral [11]. Thus, use of the graphics
display will be an inherent part of any pro-
gram ..tlich interacts with the user. The PPC
raster display should have the following
features:
high resolution -- the display should have
approximately 1024x1024 addressable pic-
ture elements (pixels);
frame buffer -- the memory (bitmap)
should be organized as a frane buffer
which can be accessed on a pixel basis
directly by the PPC processor; the frame
buffer should be seen as main memory by
the PPC processor;
graphics processor -- functions I ike vec-
tors, characters, and other graphics
primitives should be implemented by
either a special graphics processor or
by special microcode for the PPC proces-
sor;
color -- depending upon the amount of PPC
memory to be devoted to the frame
buffer, color could be an option; if
chosen, at least four bits per pixel
should be used with a video look-up
table for greater color definition [11];
40-60 Hz refresh is desirable;
video I/O and processing -- digitized video
input to the frame buffer should be pos-
sible; under control of a video proces-
sor [11], output from the frame buffer
to the screen could be zoomed, scrolled,
pseooocolored, etc.;
keyboard -- a flexible keyboard is needed
which reports to the PPC, processor lJ'tich
specific key is depressed, not a
specific ASCII code; this allows total
redefinition of the keyboard by the pro-
gram;
pointing device -- a pointing device with
dynamic cursor is needed for accurately
indicating positions on the screen by
the user.
All of these features are available in
present canmercial raster graphics systems
lJ'tich are tied to present computer systems as
peripherals. The teclTlological issues lohich
must be resolved to put these features in a
PPC are tw;>: size and integration. The bulk
of current color raster graphics systems is
physically in the image memory, the interface
to the host, and the graphics processor. In
the PPC, graphics will be integrated into the
entire package; tt will not be a peripheral
and no interface is needed. The image memory
will be organized as a part of the PPC's main
memory. A separate graphics processor is not
needed if the PPC I S microcode supports primi-
tive graphics functions. If not, a graphics
processor in this technology w;>uld be
extremely small. Thus, if the integration of
raster graphics into the PPC is done
correctly, size is not an issue. Even with a
separate graphics processor and a sophisti-
cated video processor, the extra hardware
associated with the raster graphics should be
confined to one board at most.
E. Audio Input/Output
The concept of talking to your PPC and hav-
ing it talk back to you may seem far-fetched
and perhaps unnecessary, but aoo io I/O seems
very attractive from a hunan factors point of
view. Advances in heuristic techniques for
speech recognition, advances in LSI, and the
home computer market have been driving forces
in producing the aooio ,I/O devices available
today. SevEjral companies now offer speech
input and output systems for trlder $1,000
each. The popularity of the Texas Instrunents
"Speak and Spell" toy attests to the value of
aooio I/O.
F. Interfacing
Gi ven an office environment with a nunber
of individual PPC's and an "office" PPC to
support a large office database and a high-
quality docunent printer, extra peripherals
for an individual PPC may not seem needed.
However, given the of talents and
Nov 81 CRYPTOLOG Page 5
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
interests lJ'lich may use the env ironment, some
new device will soon be suggested as a peri-
pheral to a PPC. When that time cqnes, the
interface to the PPC should be straightforward
and easy. The hardware interface could be via
a standard communications port or directly to
the internal bus of the PPC; both should be
available.
G. High-speed Local NetloOrk
High-speed local netloOrks exist today.
There are several different configurations of
topology, control structure, and transnission
media which can be chosen, depending upon the
applications and the distances involved [1].
For. an office PPC environment, a ring or bus
topology (see Figure 4) with a contention con-
trol structure seems prqnising [1,15]. F.:xan-
pIes in current technology inclu::le the ETHER-
NET and the Mitre bus.
IV. Software and Environment Technology for
the Power ful Personal Computer
Very strong emphasis must be placed on the
software and the environment for the PPC. If
the hardware technology described above is
successful beyond our wildest dreans, the
result will not be practically useful without
an equally successful software technology. If
hardware technology can be viewed as supplying
the raw power needed, the software and
environment supply the ease of use and contro}o
necessary to harness and direct that power.
The user interface to the PPC is all impor-
tant. The hardware technology discussed above
can provide interactive and cqnmunications
devices with very interesting hUllCl1 factors
implications. A PPC which can listen to you
and talk back, draw colored pictures for you,
and communicate with others in your office for
you could beccrne a very powerful extension of
yourself. However, the software and environ-
ment of the PPC must be carefully constructed
for this potential extension tc becqne real-
ity. The use of au::lio I/O, color displays,
and the local netloOrk must be innately a part
of all software cqnponents . If these capabil-.
ities are thought of as occasionally desired
peripherals, rather than as an integral part
of the system, the resulting env ironment will
be much less htlllan and less powerful than it
could otherwise be.
A. Operating Systems
The local operating system will be the pri-
mary interface between the user and his or her
PPC. It should be friendly, easy to use,
helpful, and as forgiving and tolerant as pos-
sible. It should support a multitasking, vir-
tual memory environment with interprocess can-
munication. Any hardware feature of the PPC
should be as useable as possible fran the
operating level.
In the PPC environment with a high-speed
local netloOrk, resources used by a given task
may be distributed between the personal PPC
and the "office" PPC, or they may not. The
location of resources (files, peripherals,
gateways, etc.) should ideally be transparent
to the user. In order for this to happen, a
global or network operating system must exist
to coordinate this communication and resoUrce
sharing. ing upon it
could reside on the "office" PPC or be distri-
buted throughout the PPC ' s in the office
netloOrk.
B. Progranming Languages
Progranming languages will be the second
interface between the user and the PPC. Pro-
grans will be one of a user's major products.
Prograns must be coded, modified,
merle effic ient, and (finally) executed. A
progranming language and its surrounding
environment should be designed to facilitate
this process and to make it as pleasant and
efficient as possible. Alan Kay and his
g.,ALLTALK work on the Xerox ALTO system [2]
have shown that novice progranmers cCl1 quickly
beccrne proficient if the progranming language
is designed appropriately.
Since the PPC as described herein is
designed for sc ientific and analytic progran-
ming, the proposed users are not totally
novice. However, languages for the PPC should
be designed for people who trerlitionally think
of themselves as non- programners. A ntlllber
of current languages are often proposed for
use as a basis for a PPC programning language:
PASCAL, C, ALGOL, Ada. The environment built
around a language should support a cqnpiler,
linker, powerful symbolic debugger, and exten-
sive runtime library.
Nov 81 If CRYPTOLOG If Page 6
UNCLASSIFIED

DOCID: 4009838
UNCLASSIFIED
C. Utilities
Utilities are normally invoked by operating
system commands. They inclooe things like an
editor, various "Ord processing progrcms
(speller, formatter, etc.), a file system,
language compil ers and interpreters,
an electronic mail system, etc
These utilities MUST be implenented with the
total PPC envirorrnent in mind. The text edi-
tor' should take full advantage of the raster
graphics for font definition, color, and
perhaps illustrations. All utilities that
could use the local net"Ork and any gateways
to other net"Orks should use them as tran-
sparently as possil;lle. As with the operating
system, the utilities should be as friendly,
easy to use, helpful, forgiving, and tolerant
as possible.
D. Servers and Net"Ork Gateways
In a local net"Ork PPC envirorment W1ere
users interact with one another frequently,
the concept of servers has proven important
[12J. In this envirorment, a server is a
machine on the net"Ork W1ich performs some
widely-used service for all users who desire
to use it (e.g., document printing). In some
net"Ork envirorrnen.ts, there are several or
many servers distributed arOl.l1d the net"Ork.
In the PPC envirortllent, one server has been
postulated, the "office" PPC.
The concept of gateways to other netw:>rks
is especially important at NSA. If a PPC
local netw:>rk becomes a replacenent for
current Gfss systems, the interconnections
currently supported over Pl...ATFORM would need
to continue. The local Server or "office" PPC
would handle communications for
overall netw:>rk mail and file transfers.
E. Environment
When the software described above is imple-
mented, the envirortllent created for the indi-
vidual scientific or analytic user will be
very extrenely easy to use I and
tailorable to closely suit the individual's
personality and needs. Even though audio I/O
and color graphics are integral tools at all
levels, it is obvious that some people will
use them and others will not. Some people
will make constant use of the local netw:>rk
and others will generally remain in the shell
of their o\oKl PPC. The overall PPC envirorrnent
should be flex ible enough to gracefully allow
use of all, some, or none of these spec ial
features. It should gently encourage their
use without penalizing a person who insists on
using only the keyboard input and alphanumeric
text output. A Personal Computer
must be just W1at its ncme implies: ,
yet personal.
V. NSA and the Powerful Personal Computer
It will take the research and industrial.
community several years to complete a
commercially-available PPC which meets most of
the specifications of section II. Such a sys-
tem may not be available l.I'ltil 1985, if then.
Before 1985, several versions of a FPC wi 11 be
available in one of t"O forms: (1) a commer-
cial form Iktich uses 1980-1981 technology to
meet many of the section II specifications or
(2) a research form W1ich meets all of the
specifications. The commercial versions will
be realistically available in 1981-1982 with
the necessary software. A more
rpsearch version wi th technolop;y might
be available in 1984-1986.
Given that these predictions come true,
what should NSA be doing' to prepare for the
advent of the PPC? NSA should be planning for
it and experimenting with t.hose versions of
the PPC which will soon be available. several
offices in NSA ( e.g. , R53) are now using
timesharing syst,ems in a very personal way.
Terminals are at the users' desks, various
inter-user communications systems exist, the
computer serves as phone book and personal
text preparation system, and many "Orking
documents are kept on the system. Most impor-
tantly, the users of the system have adapted
their way of 1He around the system in per-
oona1 ways; they have made the system an
integral part of their w:>rk environment. Such
offices are excellent candidates to experiment
with the PPC environment.
Nov 81 CR\'PI'OLOG Page 1
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
Parts of the DOR and DDT organizations are
already closely following the develofJllent of
the PPC externally. R53 is now assembling an
initial prototype system for experimentation
in the use of PPC's. This system will ini-
tially inclu::le tlrtO PPC systems fran Apollo
Computer (buil t aroll'ld the Motorol a M-68000),
one system fran Convergent Tecmologies (built
arotl'ld the Intel 8086), and a high-speed local
netlrtOrk buil t by Sytek, Inc. The present R53
timesharing resources will be integrated into
this system via the local netlrtOrk. This total
PPC environment in R53 will be used in part to
gain experience and to help determine possible
architectural configurations for the T4 User
Interface System project.
Bruce W. Ravenel. "The Intel 8086 Micropro-
cessor: A 16-bit Evolution of the 8080," C(}ol-
PUTER, vol. 11, no. 6, June 1918.
6. Newell, Allen, Scott Fahlman, and Robert
Sproull. "A Proposal for Personal Scientific
Computing," Department of Computer Science,
Carnegie-Mellon University, Draft of 13 July
1919.
7. Patterson, David A. and Carlo H. Sequin.
"Design Considerations for Single-chip Comput-
ers of the Future," IEEE TRANSACTIONS ON CCJ.1-
PUTERS, vol. C-29, no. 2, February 1980.
8. Peuto, Bernard L. "Architecture of a New
Microprocessor," crnPUTER, vol. 12, no. 2"
February 1979.
11. Tarbell, Lawrence C., Jr. "The Potential
Impact of Raster Graphics at NSA," PROCEEDINGS
CF TIiE CISI SPRING CONFERENCE, Iol.ay 1979.
9. Stritter, Edward and Tom Gunter. "A
Microprocessor Architecture for a Changing
World: The Motorola 68000," CCMPUTER, vol. 12,
no. 2, February 1919.
12. Thacker, C. P., E. M. McCreight, B. W.
Lampson, R. F. Sproull, and D. R. Boggs.
"Al to: A Personal Computer," Xerox PARC report
CSL-79-11, 7 August 1979.
13. Three Rivers Computer Corporation. Pt'el-
iminary docllllentation for the Perq Intelligent
Terminal, enclosures to correspondence dated
13 June 1979.
14. Trifari, John. "Backing Up the New Win-
chester Disk Drives," MINI-MICRO SYSTEMS, vol.
12, no. 8, August 1979.
'''Superpower' Comput-
vol. 17, no.4, April
10. &Igarman, Robert.
ers," IEEE SPECTRUM,
1980.
References:
What areas of NSA are likely candidates for
a PPC environment? Problems where massive
anOInts of. canputational power must be applied
will still require systems like the CDC 1600
and its successors [10]. However, algorit!'rn
develofJllent for these problems is an excellent
candidate for a PPC envirorrnent. Environments
which now use the Generalized Terminal &Ibsys-
tem (GTSS) timesharing concept are obvious
candidates for the PPC. Any scientific or
analytic canputing lrtOuld be a candidate for
the PPC. Non-technical functions like IrtOrd
processing may eventually benefit from the PPC
environment, depending upon the final cost of
the PPC and the coupling between technical and
administrative people within an Qffice. In
short, any canputing environment where people
are doing interactive canputing or algorit!'rn
develofJllent is a candidate for the PPC
env ironment. Thus, NSA has a lot to gain in
productiVity from successful develofJllent and
application of a Powerful Personal Computer
env ironment
5. Morse, Stephen P., William B. Pohlman,. and
4. Isaacson, Portia, Robert C. Garrrnill,
Richard S. Heiser, Adam Osborne, Larry Tesler,
and Jim C. Warren, Jr. "Personal Computing,"
CCl"IPUTER, vol. 11, no. 9, September 1978.
2. Kay, Alan C. "Microelectronics and the
Personal Computer," SCIEtrrIFIC AMERICAN, vol.
231, no. 3, September 1917.
3. HoaglCl1d, A. S. "Storage Technology: Capa-
bilities and Limitations," CCMiUTER, vol. 12,
no. 5, May 1919.
16. Wegbreit, Ben. Private caDmll'lication of
23 April 1980.
15. Ward, Steve, Chris Terman, Jon SIeber, and
Rae fo'cLellan. "NO: The LCS Advanced Node,"
MIT Internal Memorandllll, 28 February 1979.
and
Area
66,
1. Cl ark, Dav id D., Kenneth T. Pogran,
David P. Reed. "An Introduction to Local
NetlrtOrks ," PROCEEDINGS CF THE IEEE, vol.
no. 11, November 1918.
Nov 81 * CRYPTOLOG * Page 8
UNCLASSIFIED
--DOCID: 4009838
SECRE'f
FUTURISTIC
REPORTING(u)
bylL....--- _
P.L. 86-36
fJl
eporting describes a wide variety of
different activities. Within NSA,
we serve our customers in many dif..;
ferent ways. We issue informal
reports such as TACREPs, formal
reports and translations in both hard copy and
electrical versions, and we support canmll1ity
data bases through the COINS system. Among
our reports and translations, which form the
bulk of lotJat we generally refer to as report-
ing, we cover many different subjects and
I II could go on Ilstlng
l
the variety of reporting for some time. The
variety of reporting we do requires a lot of
different ways of doing it. We tailor our
product to some extent today and are always
looking for ways to improve it, but we do
almost all our reporting via electrical, nar-
rative reports: few hard copy reports, few
graphics, few briefings.
<6 eeS) With the availability of computer
technology, ma'ly parts of NSA' s missiDn have
been affected. Where we used to copy I-t>rse
code on six-ply paper, and the analysts back
at NSA would scan the raw traffic a month or
two after it was intercepted, today we rou-
tinely forward traffic electricall to NSA for
nearl instant anal sis.
Traffic analysis, signals analysis, cryp-'
tanalyis, .telemetry analysis are all done rou-
tinely on computers.
(U) With the advent of the MESSENGER com-
puter system in NSOC, we even prepare reports
on a computer. &.It wait a minute. Let's con-
sider how that is done. The reporter scans
his incoming traffic, prepares his report,
submits it to a chain of reviewers lotJo eventu-
ally deliver the draft to the typist in the
nex roan. The tei'tis retyped (possibly for
the fourth or fifth time) and then released.
AI though MESSENGER is a computer based report
preparation system, it ohly the typ-
ing and releasing functions and does not serve
the person lotJo actually prepares the report -
the reporter.
(U) Will we solve this problem, this lack
ofslJPport to the reporters of NSA, in the
next decade? I certainly hope so, and I think
it is weI], within our power to do so. The
technology is available today to enhance the
reporters', beyond the wildest dreans
of most reporters. Mlmy people recognize both
the problem to be solved and the means of
solution, and in several areas, they "are
already working to develop systems to
serve reports in the preparation of reports.
EO 1. 4. (c)
P.L. 86-36
(U) This paper will/attempt to aeSCrloe
some of the probletlsWhich are inherent in the
reporting field, both those now felt by
reporters /al'ld those lotJich must be addressed
in of a reporting canputer
system. It will then look at current projects
1.l'lderway which are developing canputer systems
capable of supporting reporters. Some of
these systems are not intended to serve
reporters but could do so with little addi-
tional effort. We will look at the possibili-
ties available for reporting computer systems
given today's technology, and then discuss
some of the ways in lotJich future technology
might further enhance a reporter's life.
Finally, we will discuss some of the possible
changes in the structure of the reporting
field caused both by the computer itself and
by policy changes in the intelligence commll1-
ity.
Nov 81 CRYPTOLOG Page 9
8:BRECf IIJdfficB YfA 88MB" eUidiNBbS 8Nc
DOCID: 4009838
CONFIDBNTIAI.
Problems To Be Addressed (U)
In today's intelligence reporting
world, we have reached the dubious position of
inl.l'ldating our customer s wi th reports. We
have a great need to tailor our reporting more
carefully so that the important pieces of
information \otlich U.S. decision-makers need
are not lost in the sea of information we are
'capable of producing.
(U) We have always had a problen insuring
quality control. No one wants to publish an
erroneous report, but sometimes we don't have,
time to check all the facts. Sometimes the
typist introduces an error into a report that
was already carefully checked. And sometimes
out intelligence sources present us with
erroneous information in the first place. We
have established over the years a canplex
coordination-review process aimed at getting
anyone lJlo has information relevant to the
subject of the report involved in the produc-
tion of the report. Of course, this coord ina-
tion takes time. Sometimes the reviewer makes
changes that are wrong, and doesn't take the
report back to the originator. Sometimes the
report has to be revised heavily and therefore
be retyped fran scratch.
(U) In the research that goes into an NSA
product report, there are a nUTIber of onerous
tasks that must be performed, which must seen
to many reporters as needlessly time-
conslJ1ling: checking the spelling of
cencrnes, finding the coordinates (because the
report goes out electrically and has no maps) ,
getting people's ncrnes spelled right, conform-
ing to the myriad regulation about format,
preparing the coversheet so that the acCOlllt-
ing system will work. All the-se are tasks
which must be done but are not a part of lJlat
the reporter thinks of as his primary function
- presenting relevant facts to a customer so
that the can make informed decisions
on behalf of the country.
(e-ees) Accolllting for \otlat we do is very
important to the proper managenent of limited
resources. We are now trying to connect for-
mal requirements and their satisfaction
through the use of canputers, but reporters
are finding that it takes a lot of extra time
to prepare the canplex coversheet that puts
the needed data into the managenent progran.
And that doesn't include t.he time spent
keypunching all that information. Hooking the
reporter to the canputer could save time and
at the same time eliminate the keypunching.
(U) How fast can we report information?
How fast do we need to? Wi thout trying to
definitively answer those questions, let us
say that there are nlJ1lerous times lJlen our
reporting was not fast enough to suit the
situation. en a limited basis, we have the
capability to speed up reporting but it takes
a heavy toll in resources. How much 'of the
,delay is in the report research and prepara-
tion process itself? Some might not agree
wi th me but I would claim that today most of
the delay is in the report preparation pre-
cess. We have enabled intelligence to be
expeditiously intercepted and decrypted, but
we have made little progress in translating
and reporting quickl y.
(e=ees) Some problems lJlich are introduced
with the canputer are the dependability of the
canputer system, and the, security of the data.
If the canputer goes dOW1. do we have all our
analysts sit on their hands I.I'ltil it canes
back up? And in the sectrity area, we have
potentially horrendous problens. We have
built up over the years an incredibly canplex
of canpartments, codewords, and clear-
ances, to the point that many people don't
know which things they are cleared for. Can
the canputer help us deal with this problen,
or will the potential for inadvertent access
to someone else's data exacerbate the problen
beyond belief?
Current Systems and Projects (U)
(U) There are almost as many coverncrnes in
NSA as people, and a person could be forgiven
if he got confused. &.It let's look at a few
of the names in the field of analytic canputer
systems.
Nov 81 CRYPTOLOG Page 10
CONFIDENTIAl.
IIJtzJJQlsii '".." SII!:tJtJ8b8 St.,..
- .
DOCID: 4009838
CONPIBEN'fIAL
1/
iii/PoLo 86-36
Possibilities With Present Technology (u)
(U) The TRS-80 a'ld similar so-called "per
sonaltI canputers have more than enough power
to satisfy most reporter's needs today. With
canmU'lications interfaces, such canputers pro-
vide the technological basis for a reporting
ccmputer netkOrk capable of revolutionizing
the way we do reporting at NSA.
Nov 81 CRYPTOLOG Page 11
CONFIDBNtIAL
DOCID: 4009838
P.L. 86-36
SECRE'f
anything other than a continuing fast develop-
ment rate in new canputer technology over the
next ten years.
(U) Already there are runors flying, about
canputers that will interpret the spoken "Oro.
can you imagine simply talking to your can-
puter terminal, to give it instructions or to
"write" reports? Undoubtedly, such machined
will be on the market in the next few years.
(S SSS) Developnents in microtechnology and
high speed canputer circui ts pranise to pro-
duce desktop canputers with more power than 25
Cray-1 'so (The Cray-1 is the fastest general
purpose canputer available today, and sells
for about $10 million. We use a Cray-1 to
attack the most sophisticated cipher systems.)
(u) r-bre canpact terminals may result fran
developnents in the pla3lla display field,
using a flat display instead of a cathode ray
tube. This will make the "terminal on every
desk" concept more practical. Combined with
the extra power available, each usl!r might
have a canplete 1Y0cessing system on his desk,
tied to a central system only for data
transfers.
(U) It goes wi thout saying that there are a
nunber of problems that "Ould have to be
solved before this utopian picture can be
developed. The present tubes are rather snall
and can only display a limited anount of
information. The present canputer systems
have nunerous .problems with both turnaround
and dependability. Acouple of developnents
in the canputer field may help in this area:
failsoft technology, in Iotlich pieces of a can-
puter can "Ork independently of one another;
and distributed processing, in Iotlich each user
or snall group of users has an' independent
canputer tied to other canputers only for data
transfer. All the lYoblems are solvable. The
major question is W1.ether our institution will
solve the various problens; whether it, or we ,
are ccmmitted to improv ing the effectiveness
of reporters through the use of canputers.
Can we? Will we?
Future Technology (U)
(U) The TRS-80 has been called the "r-bdel
1'" of the canputer industry. The era of cheap
canputing power is here today. and the pace of
tecl'l'lology developnent has been increilsing for
several years. There is no reason to expect
(U) High quality facsimile transnission at
a reasonable cost is just around the corner.
With consU'llers tied to NSA through a
facsimile/data net"Ork, "electrical" reports
with graphics becane possible. Q.lr l o c a ~ can-
puter might help to generate the maps, requir-
ing no more instructions than a list of the
pI acencrnes to be identified. OIarts and
graphs will also be practical in such a sys-:-
tern.
Possible Reo-Structuring
of the Reporting Function (U)
(euess) Last year, NSA was stooying a sys-
tem that could result in a massive restructur-
ing of the way in W1.ich reporting is done.
This was not generated by technology but
rather represented an attempt to simplify the
"Orld of code"Ords for intelligence consU'llers.
The progrcrn, called APEX, was a matter of some
confusion here at NSA. APEX called for
"decanpartmentation" of intelligence, meaning
generally the sanitization of material so that
it could be distributed without code"Ords.
APEX is now dead, but some of the ideas con-
tained in the project live on. There is still
Nov 81 CRYPTOLOG Page 12
SECRET
__--------L---..L---L--..----L--.---------....-.--..
DOCID: 4009838
CONPIDBNTIAl.
a hugh dsnand for sanitized SIGINT. This
meal') producing some additional reports
t detach lines, or it could involve produc-
ing t'oO versions of a singrereport, one of
them sanitized.
+a- Imagine, if you will, applying such a
system to all SIGINT reporting. I am sure you
will a computer would bean invalu-
able tool in editing and reviewing reports
w,ich must be sanitized for wider distribu-
tion. If we stop and take a look at the pos-
sibilities, we might even be able to redesign
the reporting' system with an eye on the tech-
nology, and take advantage of the technology
instead of using it to play catch-up.
Ways in W1ich we might restructure the
reporting function to take advattage of tech-
nology incltrle putting more information into
data oases, and making more of that data base
information available to users at multiple
access levels through sanitization. We might
tailor our reporting to fit the needs of indi-
vidual users, by having the computer scan the
available intelligence information and select
items by using a dictionary of relevant terms.
Our requirements process might be different in
that conS\Jllers could simply input their key-
'oOrds into their. computer terminals, instantly
updating the requirements dictionary. The NSA
system could automatically compare the consu-
mers' input and access level wi.h the avail-
able NSA information and route the appropriate
information as it becomes available. Manage-
ment reports could be available instantly on
which user requirements were being satisfied
and were not. Analysts at NSA might
refer to the unsatisfied requirsnents data
base to help them rrioritize their workload.
Supervisors might use it to assign work to
analysts. This infornation might even be used
to a1ter our tasking f c c s on
a real-time basis.
EO 1.4. (c)
P.L. 86-36
Conclusion (U)
(U) In conclusion, let us consider the
challenge of the 80's: to integrate technology
that is available, and that is becoming avail-
able, to improve the efficiency and the effec-
tiveness of the reporters at NSA, and to alter
the ways we do our reporting to better serve
our present and future consuners wi thin the
btrlgetary constraints place on us. My conten-
tion is that we can do our present job of
serving intelligence consuners better and more
cheaply by taking advantage of the existing
technology. The decreasing nunber of secre-
taries at NSA is already a problem, and one
that seems unsolvable. Lack of staff people
to coord inate reports and a continuing need to
maintain quality control create rressures to
use computers to assist the reporting staff in
maintainIng the quality for w,ich NSA is
renoW1ed.
(U) How to do this? First, we need a
coherent policy regarding the use of technol-
ogy to serve the reporting function. If my
contention is correct - that technology can
enable us to do our present job better and
more cheaply - then we are wasting valuable
resources by our continuing failure to use the
technology available to us already.
(U) Second, we must have a driving force.
The purpose of this paper is to pull together
ideas from throughout NSA and from the com-
puter world, and to present them to reporters
and managers in NSA as a meahs of helping to
create such a driving force - nanely, ,the
reporters and managers in NSA. If we sit
around waiting for the T organization to
recommend new and better uses for technology
in support of the reporting function, we will
grow old and gray before anything happens.
This is not intended to be an indictment of
the T organization, merely a statement of the
realities of life. The T organization exists
to serve the other organizations of NSA,
incltrling If we want to update
the reporting technology here, we must ask -
demand - that it be done. And we must take an
active role in specifying in great detail how
the job is to be done.
(U) The possibilities are almost endless,
but the challenge is ours. The technology is
there and more is coming. fut we must take an
active role in developing our understanding of
how the technology can help us and in seeing
to it that we make the fullest possible use of
the technology.
Nov 81 CRYPTOLOG Page 13
eONFIDBN'i?IAL
DOCID 4009838
UNCLASSIFIED
CRYPTIC
CROSSWORD
Byl I

Pwu..
AnagJu1m6.

Vouble
I I 4
In60!lma.tion Suence /EcLU:nIL,
hM COtUltJw.ct.ed ex.cellent
c.I!.044WOlLd puzzle. done the
c.l!.lJptic, oIL 4tfjle.
(But 06 that
one' 4 plLettfj aw6u.t. )
P.L. 86-36
1 3
fI+
*5
6 7 8
_
e
_ _
e
_ _
e
9
_
10
_ _
e e
11
_
e e
12
_
3
-
1+
e
i4Ij
15
e e e
16
e e
e
_
e
7
18
e
9.
_ _ _
e e
_
20
ee e
_
e
_
_ _ _
?1
_
?2
23
_
1+
_
5
_
--
6
I_
e
_
7
e
_
28
_9
e e
__
e e
e
e
30
1.
31
ACROSS DOWN
\1. Average second bites are vegetables. (8)
5. Could this be where amputated limbs are thrown? (6)
9. Small overthrows combined in great poems. (8)
10. A child or a place in Mexico. (6)
12. Consumes teas in a sloppy manner, (4)
13. Weasel out of orders to attack. (5)
14. A kick from the teaa's top untried draft choice. (4)
17. I hear the sea left the fiend's farm machine so he
could show us his wares. (12)
20. Otherwise calm mediator possessing emotional
appeal. (12)
23. It's not often the meat isn't overcooked. (4)
24. Less confused about a tradition at Easter. (5)
25. A peachy coat for policemen? (4)
28. Myth of the ankle, perhaps? (6)
29. Religious gentleman takes a note back to provide
work for the secretary. (8)
30. Did the bug clear his throat for the
Spangled (6)
31. Snake has Richard Henry cbnfused about a small
prisoner. (8)
,1. A sentry stationed at the fence? (6)
2. The right side ejects from bed. (6)
3. Somehow the line forms in the river. (4)
4. ewe into paint; need we ask again? (8. 4)
6. Enough space to anchor around. (4)
7. The faction favoring pipes put together the mer-
chandise. (8r
8. I sort art for Arnold's kind. among others. (8)
11. Gather '50 scheme for the European Recovery
Program. (8, 4)
IS. Rushes. we hear. through the book. (5)
16. Draw off five hundred droplets. (5)
18. Destroy the rum label? Nol It'll be useful
next April. (8)
19. Very good! Everyone is not left behind. (3. 5)
21. Roman god adds eyes, we hear, to restore a flat. (6)
22. Blossoms as a sound heard over the meadow? (6)
26. At one time, at the induction center. (4)
27. Scandinavian in a Japanese rickshaw. (4)
Nov 81 * CRYPTOLOG * Page 14
UNCLASSIFIED
CONFIBRN'fIAb
SAY What You MEAN!
by David W. Gaddy
@
ver time, jargon becomes accepted
usage, but in its application there
can be confusion of meaning. "San-
itization" is an example. Part of
"(U) the confusion arises frCITI our
view of the handling sys-
tem, a view which must bemodifiE!d if we are
to cOOlllunicate effectively among oursp-Ives and
Olr colleagues in the Community. "\o1hat follows
is. a renection on "lessons learned" during
the APEX study of the past years and an
attempt to clarify terminology now in wide
(but often differing) use.
(e-eee) To set thf'! stage by stating the
obvious (50 obvious it may be overlooked), the.
body of infonnation under discussion, Cf"MINT,
is classifiPd. It is TOP SECRET, SECRET,
rarely CONFIDENTIAL. (lJnthinkable a fp.w years
back, there also unclassified CrnTIIT of a
historical nature, but we are concerned here
with current DOMINT.) It also has at least
one attribute: it usually" has a
or a restriction that it be handled
only in crnINT channels, the "compart-
ment." This is the infonnation which, from
World War II U.S. Army usage, is frequently
called "special intelligence," or SI.
SI is now limited to CCJo1INT, it has become a
euphemism - !lOme even mistakenly (but with the
same result) think it equates to "signal s
intelligence. "
(e eee) For years most of us have thought
of "compartJnents" as thosf'! small, cloistered
efforts, usually distinguished by a covern<flle,
which are now, for the most part, covered
under the VRK (Very Restricteci !(nowledge) sys-
tem. (See llSSTD 16 for details.) It still
comes as a mild shock to he reminded that the
COUNT handling system is itself a compartment
(or "special access progran," as cCITIP8rtments
are termed in Executive Order 12065) . Here is
the definition of "compartment" as develope<'!
under APEX and approved by the It
represents but a slight morlification of that
contained in the 1978 DCIINFIB "Glossary of
Intelligence Tenns and Definitions":
cQlTlp1'1rtmentation: FonnCil systems of res-
rfct.i>d access established and/or managm
by the Director of Central Intelligence
(DCI) to protect the sensitive aspects of
5Ources, methods, and analyticCll procedures
of intelligence progr1ll1s.
The term in Conrnunity is "sensi-
tive compartmenterl information," SCI. CCJo1INT,
or STGINT hanrlled the COMIVT is
therefore a fonn of foCI. ( Al we are
concerned only with spec1::ll progrcrns in
an context, there are other such
programs, especially those createrl for mili-
tary operatiomll purposes.)
/
EO 1.4. (c)
Nov 81 CRYPTOLOG," l'flge
eONFIBBN'fIAJ:.
IWJBIoB 8SMHff' eItA:mUftoS 6Jft;Y
DOCID: 4009838
CONFIDENTIAL
I
.4. (c)
86-36
Ed Note: It may have been the conductor on
the Orient Express 1<110 said it first, as
the oetachnmt of 'I\Jrkish soldiers got off
the train at Vienna: "I think we shall'
have to sanitize that ccrnpartment."
Nov 91 * Pap,e 16
CONPIDBN'fIAL WA 99M1fR' eltANlfBt.:S 8f4Li
DOCID: 4009838 UNCLASSIFIED
HOWTO CREATE
A USER-OltnFRIENDLY
SYSTEM
byl _
(Clsl Workshop, May 1981)
vrona c08IIand. duaay J
10 away. I'. bUlyl
another lOlic error. atupid'
P.L. 86-36
one of us sets out deliberately
to bring unfriendly hunan/machine
interfaces into the world. Somehow,
even though we trying our hard-
est to design and build good
software, the user interface all too often
turns out to have some serious defects when it
is delivered and people start using it. Some
of the defects can result in increased error,
waste of expensive man-rours, and waste of
machine resources. If the users have any
choice, and things are bad enoup;h, they may
simply refuse to use the system, and find
other ways to get their work done. If they
don't have a choice, their work efficiency may
suffer significantly. The worst aspect of the
situation is that the losses are hidden; the
machine is not down, some amount of \<oOrk is
flowing through the system, and there is no
obvious stoppage or breakdown that can be sin-
gled out to warn us that a lot of time and
effort may be going down the drain unneces-
sarily.
My main purpose here is to raise your cons-
ciousness about the needs of the user, and row
some kinds of desip;n decisions can affect the
convenience and supportiveness of the user
interface in an interactive system. I have a
strong feeling, based on studies I have made
of several Agency systems, that ma1Y of the
unfriendly features are unnecessary. Some, it
is true, are forced on us by prior commitments
to specific formats or procedures, or by file
security and file integrity requirements. The
majority of the features that make problems
for users come about, however, simply because
the designer and programJer were optimizing
other variables, without thinking about the
effects on the user. Their priority lists are
headed by other things, and the. user is way
down in the stack. They are concentrating on
space, getting around weaknesses in the
programming languages and operating systems,
meeting demands of the sponsor for performing
given fUnctions, and beating deadlines.
In the miost of these pressing preoccupa-
tions, it is all too easy to forget that we
are desip;ning a system that will interact with
a user. From his point of-view, the system
will exhibit behavior, just like another per-
son or animal. If its behavior is puzzling,
contraiictory, and frustrating, the user will
have a lot of trouble getting along with it.
If it leaves him hanging, not knowing what to
do next, and he has to dig through a badly-
written manual while his work waits, his time
and the system resources are being needlessly
wasted, when we could have told him what he
needed to know :'n a simpl e message on the.
screen. If system messages mislead the user,
or if datA-entry procedures are confusing and
inconsistent with normal usage, we are design-
ing in a source of constant error. All it
takes, in ma1Y cases, is a slight re-wording
of a message, addition of information to an
incomplete message, or standardization on one
set of field 1abel s or procedures, to solve
these for the user. Very rarely will
the changes toward require
any major sacrifices in efficiency, running
time, or ease of debugging or maintenance. In
fact, the same changes that make a a system
more predictable and convenient for a user are
likely to make it easier to maintain and debug
Nov 91 * CRYPTOLOG * Page 17
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
as well.
I guess what I am trying to sell to you is
the need for a lot more EMPATItY TC7tlARD THE
USER. Interactive programs are basically
ferent frOlT1 the kinds of programs that read in
a batch of data, chew on it a lJ1ile, then spit
out a batch of answers to be read later at a
user's desk, or rlJ'l (;m another computer. At
least half the work in an interactive system
is being done by that user out there, who is
carrying out a continuous exchange of infonna-
tion and instructions with the system.
we design such a system, we cannot afford to
let ourselves forget that we are creating
BEHAVIOR. The interface that the user sees
will have characteristics that significantly
affect his work efficiency. We have to find a
WaY to keep in mind what the user is trying to
do, what exPectations he brings to the taSk,
and how he will perceive what the system is
saying to him. At any given point in an
interactive dialog, the user has certain
expectatIons in terms of infoilllation he needs
and timeliness of response to avoid breaking
his train of thought. You, the system
designer and programmer, have built up that
set of expectations (whether knowingly or not)
in the of dialog steps that preceded
the screen the user now sees. we like
it or not, when we design and implement an
interactive system, we are creating behavior,
and we are creating a conversation. If we are
going to do it right, we must somehow get into
the habit of empathy, imagination, putting
ourselves in the user's place, at all stages
of our work.
WHY IS IT SO HARD TO SEE
TIfE USER'S VIEWPOINT?
Unfortunately, there aren't very many good
tools and techniques yet to help designers
change their point of view from the old
"batch" way of designing programs. Most of us
still tend to approach an interactive system
design task pretty much as if it were a batch
program. f\ task is specified by a sponsor who
has certain requirements j we know what COlT1-
puter system and programming language we will
use; we go ahead and write A PROGRAM which
will do the job wi thin those constraints. lole
treat the interactive user as if he were a
tape drive, a card reader, or any other input
device that we get data and parameters from.
Instead of send ing a seek to the disk, or a
read to the tape drive, we seml a message to
the user. This is a very poor way to look at
an interactive task! People are not like
disks or tape drives, for better or for
Somehow we must develop diagrCl1llling and plan-
ning techniques, modelling and prototyping
skills, and useful practices and guidelines
for this new and special kind of programming
and design involving dynamic give-and-take
between user and system.
\olE NEED A COURSE IN
INTERACTIVE SYSTEM DESIGN
I would very much like to see a COlD"se in
"Design of Interactive Computer Dialogs"
taught at OlD" School. There are a nunber of
courses being taught at Universities and Col-
leges, and in private industry. Videotapes
are available from at one source I know
of, rr. Ben Schneidennan at the University of
Maryland. An excellent course is offered by
Dr. J. D. Foley at GW. There are also a
nunber of research efforts under way in
several places to develop guidelines for
interactive system design, and they have pub-
lishe9 usefUl papers (e.g., those by Ramsay,
pt al. and Smith, et al. in the references). I
bel ievp that such a course should be practical
in its orientation. It should incltx:le at
least one real design project. And it ought
to be required in our Data Systems Profession-
alization program!
TOOLS TO HELP THE DESIGNER
In the near fut ure, there wi 11 be new aid s
for designers of interactive systems. 'ole wi 11
be able to use the power of interactive sys-
tems themselves in the design process, with
rapid prototyping and planning packages simi-
lar to the PSA/PSL system currently in use by
T-Group for program design. I believe that we
could gain useful techniques and tools right
now frOlT1 the Computer Aided Instruction (0,1)
field. Designers of computerized courses have
developed a lot of experience in building one
type of interactive dialog. Astudy of CAT
packages and ::lnd an attempt to
transfer useful ideas to interactive system
design, would cmply repay our effort. Unfor-
tunately, our need is pressing and we don't
have these tools at OlD" fingertips today.
There are still some infonnal methods we can
use to help us visualize and manipulate the
essential structure of an interactive session
from the us-er's point of view. The diagram-
ming method I am suggesting in this workshop
is a simple, pencil-<lnd-paper aid you can use
right away to tryout ideas and see how thl'!Y
wi 11 impact the user, to cOlT1pare different
designs, and to trouble-shoot bad spots in. an
ex isting dialog.
Nov R1 * CRYPTOLOG * Page 18
UNCLASSIFIED
L
DOCID: 4009838
UNCLASSIFIED
..
EXAMPLES CF mOD AND BAD USER DIAWGS
As a way of demonstrating the importance of
empathy toward the interactive system user, I
will present several examples of poor design,
chosen from actual NSA systems in current use.
The examples will be disguised, to avoid need-
less embarrassment to and
progra1lllers associated with them. Features of
several real systP.ms may be lunped together
into one artificial "system" for the sake of a
dramatic illustration. The essentials of each
feature will be retained, with surface details
changed to conceal the source. "Rock-throwing
sessions" are destructive to all concerned,
and my intention is not to criticize any
specific system or Agency elanent. In many
cases, the particular unfriendly feature I
have chosen to describe is only a S'llall part
of a system lokJich is otherwise very helpful
to users. With just a little forethought to
avoid needless problans for the user,
these excellent systems could be performing
far better. I will also present some
cOll'lter-examples to illustrate good, "user-
friendly" designs for contrast. Some of these
are chosen from the same real-life Agency sys-
tems as the "bro" examples. (For reasons of
space, the examples were not Incluned in this
paper, but were presented in my talk at the
workshop only.) First, let's look at the
basic shape of an interactive session - the
structure that makes it essentially different
from batch program run.

TI-lE STRUCTIJRE OF A DIALOG

I.will illustrate these points with a con-
venient method of an interactive
user dialog, which emphasizes the dynamic
structure of the interaction. Fig. 1 shows a
diagram of a simplified typical dialog. The
circles are of the user, and the arrows
are exchanges of information between him and
the system lokJich move the user to a next
state. Each step from one state the next
involves a user input, followed by a systP.m
response. Tn this analysis, we are interested
in the USF.R's states; the system, too, has
states, but we are seeing them entirely
through the user's eyes at present, because it
is the user's viewpoint we are trying to model
and understand in this exercise. The action
starts when the user sits down at the terminal
and LOGS ON. When the system receives his
log-on, it. can either accept him, at state 1,
and display a message, prompt, or menu, or
else it can refuse him and give him (we hope)
a cleDr message telling him what is wrong, at
state 4. If his log-on is accepted, the
system gives the access to what I will
call the TOP of the rtialog. Here he has
a chance to sp.lf'Ct one of a set of
actions he can perform on the system. They
can be commmds he may type in, files he may
call up, nunbered choices from a menu, or
function buttons he may press. he
self'Cts one of these actions, the system will
again respond by either giving him access to
the subsystMl he has requested (file, command,
routine, package, etc.) or displaying a mes-
sage warning him that he is unauthor i zeci to
use it, or has made an error in his input.
The function the user has chosen may offer
him still another set of choices, leading to
another level of subsystems, or there may be a
linear chain of actions and responses between
user and system, involving no further choices
of dialog patl1s, but continuing until t.he
action is done (data entry, record retrieval,
and display of a result, etc.),
for instance, the step from state? to i in
fip,ure 1. After the user has viewed the
display, or the system has completed work
behind the scenes and given the user a mes-
sage, the system may automatically return the
user to a higher level and let him choose a
new action at that level, or else it may ask
him lokJere he wants to go next. Eventually,
the user will decide to quit work, or else the
system will automatically terminate his ses-
sion and he will be returned to the top level,
....nere he wi 11 LOG O!='F. At any point in the
dialog, the user may su1denly see that some-
thing is wrong, or else he to break
off his work unexpectedly, so he will need to
ABORT or CANCf1. the dialog and return to a
higher level before work at the current level
has terminated normally. Tn many existing
systems, the top level special, in that a
user cannot ordinarily bypass it by an inter-
rupt from inside the dialog. His interrupt
will get him !"lack to the top level, where he
must LOG OFF to get out of the system
entirely. This is because logging on and off
Nov 81 * CRYPTOLOG * Page 19
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
are often handled by the operating system.
while lower levels of dialog are handled by a
specific routine or software package under the
operating system. Some systems allow users to
log off directly from one or more states
within a SUbsystem without having to return
first to the top. At each state. the system
gives the user specific displays that must
tell him lJ1at he needs to 'know to select the
next transition. No matter what else may be
going on behind the scenes in the host com-
puter. disk files, m8SS memories, network con-
nections, data links, etc., ALL THE USER'S
DECISIONS MUST BE BASED ON WHAT HE SEES ON ruE
SCREEN RIGHT IN FRONT OF HIM HERE AND NOli. As
the designers and of the user
interface. we have to find a way to tell him
just what he needs to know right now, to make
the best choice of his next action. Why make
him guess at incompletp information. try to
remember lists of commands, or recall data
displayed on earlier screens? You are
unnecessarily adding to his burden and
detracting from his effectiveness in the pri-
mary task he is performing with the system.
The table below is a state-tr8nsition
matrix. It provides a useful way of
.5t111l11arizing information concerning pairs of
states, or data associated with each transi-
tion allowed by the dialog in figure 1. This
particular table shows user inputs (U) and
system responses (S) for each transition. An
X indicates that the transition is not 8llowed
by the dialog. Such a table is a convenient
method of reviewing 811 the Possibilities and
planning or analyzing an interactivf> dialog.
I STA!! "
!t",.r:: I .,!lFTW_t.: 1 I : ..
---------1----------1---------- --------f---------I---------
I x on X : on
: l':top menu I :!:r.fu l
---------iu;i;;-;;r-:----i----- u;;;;t;;r---;-----l---;-----
15:f'dbllGkl S:pro.ptl r
---------1----------1---------- --------1---------1---------
2' X rU:o.rio.1 1: :U:1.t. , X
:S: top ..... u IS:d isphyl
--------- ----------1-------- -------- r-------- 1---------
X fU:qu1t X: . X 1 X
I I!:top ,..enu 1 (
---------I----------l---------- --------r---------:---------
It :U:- I X X : X : X
: I f
---------1----------1---------- --------l---------:---------
Figure 2 shows a diagran of a dia wi th a
user-interrupt transition skipping from State
1 directl y back to the top 1evel, bypassinp; an
intervening State 2, and skipping State q,
wnich ordinarily would have come next.

U
T
e
A
L
For instance, suppose that a user has
on, and at St8te 1 has asked for a file-updatp
packagf>. 2, inside the file-update part
of the dialog, has givf'n him a data-entry for-
mat to fill in on his screen (State 3). While
data, the user suddenly realizes that
he should first have retrieved a record to
check its contents before making the
He enters a comm8nd canceling the data entry
screen, removing the effects of any data
he may h8ve entered already, 8nd returning
him directly to the top level, where he"may
request the retrieval subsystem and make his
query. It is useful for the designer make
a state-tr8nsition tahle including al] the
"cancel" or "user interrupt" t.ransitions he
will allow, and listing the items of dat8 or
vari8bles that must be reset to clean
up the loose ends at each point. This is also
a good method of deciding where we can reason-
ahly permit the user cancel, without creat-
ing too much chaos in the data base or program
variables. Tn general, it is more "user-
friendly" to allow user-interrupts at as many
points in the as can reasonably be
mCln8f(M.
Before he ] ogs on, and after he logs off,
the user is in a speci::!l "neutral state",
where he is not directly affected by anything
the system does. In this state, he is not
enp;aged in any dialog with the system. Q1ce
he logs on. and from then until he logs off,
Nov Rl * CRYPTOL0G '" 20
UNCLASSIFIED
-----OOCID: 4009838- 1
1
UNCLASSIFIED
he is more or less closely coupled with the
system, and his actions are directly affected
by the p;ive-ald-take of the dialog. At (!ach
of his states wi thin the dialog, he expects to
see certain data, wi thin a certain range of
time-frames. He has specific uncertainties
which must be resolved completely by the
display on the screen, if he is to he able to
continue YoOrking effectively. The system
designer must be aware of this mental context
buHt up by the previous steps of the interac-
tion, and provide what the user to know
right where he needs it. The diagram can help
us by factoring out each transition and let-
ting us consider just what path or paths have
led the user to a given state. A state-
transition table can help us organize and
review all the items of information the user
has supplied to the system 8I1d expects to
receive from the system state.
Figure 2 shows another situation, which can
happen in this nIl-too-imperfect IooOrld. Ima-
gine that the user has YoOrked his way to State
3 again. Suppose, for instance, that he has
called up the retrieval subsystem (State 2),
entered a query (State 3), and is waiting for
the system to display the retrieval on his
screen. Suddenly, he finds himself not at the
top level, but all the way back at the neutral
state, out of contact with t:he system. The
dialog has been stopped dead, the screen is
unresponsive, and when he pushes a key, noth-
ing happens. The system has CRASHED in
midstream, perhaps leaving a multitude of
messy loose-ends hanging behind the scenes.
The way this experience feels to the
interactive system user must be lived through
to be truly understood. The best way to
describe it is to say that one minute the user
is closely involved in a lively give-and-take
with a responsive, talkative entity, and sud-
denly everything has died on him. It is a
very pecul iar and frustrating feel ing, a 1it-
tIe like running into a walL Whenever this
happens to a user, he will have some very
strong uncertainties that must be resolved
somehow by messages or pre-Jarrangl"ct pro-
cedures, so that he can put his IooOrk back
together and get going again with a minimum of
lost motion after the system comes back up.
In addition, THERE IS
RESPONSE of frustration and alarm, especially
if the user knows that a lot of his YoOrk will
be lost: not just the last action he per-
formed, but perhaps hours or even days of ear-
lier IooOrk as well. A state-transition table
incltrling "crash" tra,1sitions back to the neu-
tral state can help us review the possibili-
ties and plan \otlat loose ends need to be
clenned up and what recovE'ry features need to
bE' provided to the user.
The diagrams can be a handy aid for "doo-
dling" while you are planning an interaction.
Tf you are a designer, they can l1el p you to
see the structure of a user interface from the
user's viewpoint. They can help to make clear
what are the successive choices a given design
puts before the user, and what data he
at each point to decide Where to go nE'xt. If
you are a user, you might find it an interest-
ing exercise to try diagramming all or a por-
tion of a user dialog for a system you use,
especially a part of it that often gives you
trouble. Fxper iment with various kinds of
matricE's and tables of data associated with
state-pairs, for instance user performance
times, system response times, user inputs and
system messages, etc. The excrnples in these
handouts will some illustrations. The
references at the end of this paper list
several sources where state diagrgns for
interactive dialogs are discussec1. These
references were brought to my attention by
Joan J'o'C[bnald, R8.
sa-1E HIl.NDY RllLFS OF
Below are some guidelines that express the
"moral" of the illustrntions T presented in
the IooOrkshop.
1. Ibn't make the user give you rerlundant
information; get it from him once and use it
efficiently behind the scenes. (E.g., if you
ask him for his name and can look it up, you
shouldn't need to ask for his initials and his
social security number too. If you have a
passYoOrd, you shoLildn' t need else to
identify him.)
2. Ibn't leave the user looking at a blank
screen after he has input a command or data.
Give him a messagE' (''DocLlllent number not
fOl.l'l'i", "retrieval ended", "retrieval failed")
or at feast a prompt to t",ll him what level of
dialog or state he is in so he has an idea
what to do next, especially if the command he
just input has failed.
3. Ibn't build data entry formats or
representations into your rj ialog which are
counter to normal usage. You ar!" laying t.he
fOl.naation for persistent user that
will waste far more time in error checking and
recovery code than the extra trouble to
81 * CRYPTOLOG * Page 21
UNCLASSIFIED
DOCIO:
4
UNCLASSIFIED
t.1
E
lJ
,-
Il.
.A ... __
....
THE.
E:.b IT
SOL.IS
3
--------------------------------.----------------------------
Fir +
CU;:7-;EU:---------------------NEXT-----------------------------------
ft!r.T: TRAL: : 2' : 3 : q : 5 '5 .,
----1-------1-------:-------1-------1-------1------- -------- --------
:U:l.on I : 1 :
TRALI t x : x I X I X "( '(
----l-------:-------l-------t-------l-------l------- -------- --------
1 10:1.01'1'1 IU:re(r)1 :
x :g:wndow: x : x 1
----1-------1-------1-------1-------1-------1------- -------- --------
2 IU:- :U:del I :U:otl-alU:old 1'1
f!:er-ashfS:mess,: r :S:new x r x
----1-------1-------1-------1-------1-------1------- -------- --------
3 IU:-- 1 I : :U:new r: !.Jn1el
: x : x: '( X '5:Slve r
----1-------1-------1-------:-------1-------1------- -------- --------
':U:--: : : 1 11:.11". U:1.1
..asht l X I X : x :S:new r
----1-------1-------:-------:-------:-------:------- -------- --------
5 IU:-- 1 : I IU:dlta 1
IS:cr-ash: x I x : X' x x
----1-------1-------1-------1-------1-------:------- -------- --------
5 :U:-- 1 : : IU:dlta 1
:S:e...sh: r : r : x x {
----1-------1-------1-------1-------1-------:------- -------- --------
1 :U:-- :U:--: : : :
1 x I '1: : '( 1 x x
----1-------1-------1-------1-------1-------:------- -------- --------
CUR-I R!U-
TItAL : 1 : 2 : I" ! I
----1-----1----1------1----1----- --- ----:
:U:1.on I 1: I
TR'LI X I X 1 X : X 't :
1 IT:2I1ln I I: I ___ I : I I r ------ eel
1 :U:l.orrl IU:edlt I I I
:!:Ictal.l X 1!:::Ilplyl X I X X X :
IT:6-1Dsl: :
____ : 1 : :
1
--------1
2 :U:-: : IU:lntel"t 1
hl : X I X :'( :
: : : r ____ : : 1 1 : ._--- --------l
3 :U:-:: :
X 1 x i X X ;
____ : : : : : 1
:U:-:: :U:t8b U:t.b I
IS:arl.hl '( : '( : x S:hol'lt. X :
1 : : , IT:!" or:", I
----r-------:-------I-------:-------:------- ------ --------1
5 IU:-: : U:.nt... :
1C;:crulhl I X IS:fl.1d X S:pr-OMot:
: : : ;
____ : : r : t ------ --------1
6 :U:exlt I :: I
1 X X : J: X X 1
I
I) ------ --------1

.,..J.,.
Id_
aL

, \.::J
3 "f

,..
12.,,"''' 1:.. ,To"
Examples from Other Systems
....
............ to.I
e
u
I
A
L
CRASH: stites 1l,5,6, '(.ystroke rltcovery fl1. '.
stites 1,2,3, user ... not
st8te !: after hit "del-, not possible
Nov 81 * CRYPrOLQG * Page 22
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
r.UR-I IlEU- "'ElM'
RJ::IIT: : 1 I 2 I 3 1'1 I c; I f'i I 7 I fl I" I 10 I
----I-------I-------I-------I-------r-------I-------I--------1--------1--------1--------1--------1
'I<;U-l fU:t.on : I I : 1 I I fU:IO/t onl 1
X 1 X I X : X I X I 1{ I X I 1{ 1( I
----:-------:-------I-------f-------I-------l-------I--------1--------1--------1--------:--------:
1 IIJ:l.ofr: IU:trivi.. I I I I I I I 1
::>:llIe:'l"31 X X I lC I x I x I X I 1( I 1( I lC I
----I-------1-------I-------l-------l-------I-------I--------1--------1--------1--------1--------1
2 :U:- J I I I I
1::;:crAShl X I X 1( I 1( 1( I 1(
----1-------1-------1-------1-------1-------1-------1--------l--------I--------r--------r--------I
1 I'J:--: IU:exit I I I 1 1 I I I I
X X I lC 1 X I X I 1( I X I X : X I

'1 111:- I I I 1 lU:dat.a I I I I 1 I
..shf X f 1( I X : X 1( I X : 1( f 1( I 1( I
----1-------1-------1-------1-------1-------1-------1--------1--------1--------1--------1--------1
'; In: --: W:cf1I1cll I r fU:<fatl'l I. I I I I
1( 1( I X I x X I x l)l I X 1
----1-------1-------1-------1-------1-------1-------1--------1--------1--------1--------1--------:
., 11':- t IU:exlt I I 1 I I I I I I
15:prmpt: X :!( r 1( 1 X I x I x I x I '( I
----1-------1-------1-------1-------1-------1-------1--------1--------1--------1--------1--------1
7 lIJ:--: IU:l!xit I : : I I I I I I
X IS:prmpt: 1{ : X I X I X I X 1 X 1)( I X I
----I-------J-------I-------r-------I-------I-------I--------1--------1--------1--------1--------1
R l'J:- I I I I I I I I I I 1
IS:crllllhl X I 1( I X I X 1 X I X I X I X I X I X I

') 11J:- I I 1 I I I I I I 11l:trlvi"l
X I X J X I X I X 1 X 1 X f 1( I 1f fS:r"rus.. r

1(1 II!: -- 1 I If: I r I I I :
..!I!1P,1 X I x 1 x I X I 1( I X I x I x I x I 1( 1
----f-------:-------:-------:-------l-------,-------I--------I--------f--------:--------:--------:
Nov 81 * CRYPI'OIOO * Page 23
UNCLASSIFIED
DOCID: 4009838
UNCLASSIFIED
provide a natural format in the first place!
If a field is to contain dollars and cents,
permit the user to insert. a decimal point, and
edit it out later if you must. If the data
structure behind the scenes requires an odd-
ball representation of dates, times, etc., let
the user enter them in a natural, easy-to-
rememher form and do the needed conversion in
the software. When you display them to him,
convert them hehind the scenes back to the
form hp is used to.
4. Don't let different parts of the same
system Ilse different formats, procedures, or
representations for things that are the same
to the user. Use the same method of error
warning and correction throughout all the data
entry routines of a system. Use the same con-
vention for "default" or "null" data entries
i3nd command selections. If one subsystem pro-
vides a list of options "1", "2", "3" and
asks the user pick one, don't use a similar
display with numbered items to mean something
else in another subsystem. If some subsystems
tell the user "PROCESSING Cct-1PLETE" at the end
of their actions, as a way of letting him know
he is back at the top level, all subsystems
should do so, rather than some of them leaving
the user looking at a blank screen. If you
display a review aft.er data entry in a form,
always give the user the same way of inrlicat-
ing "correct" or "wrong" ood making correc-
tions, throughout all data-entry routines of a
single system.
7. If t.here are requirements for contents
or formats in data entry fields, check for
them right away <lnd let the use>r correct
errors for each field as he enters it. Don't
give him a review several fields at once,
one of \J1ich may be incorrect, unless you al.so
provide a forms-entry interface with tabbing
from field to field and protected field boun-
daries.
8. Don't use different labels or abbrevia-
tions for field names, commanrls, or other key
wrds in differe>nt parts of the same di810g or
system. If a field is called "AMOUNT" in one
display, call that field the same thing in
every display or message that refers to it
(not AMT one place, MONEY someplace else,
"FUNDS" someplace else). Don't choose labels
or abbreviations that look alike or are
confusing. l"hlle an experienced user may be
used to some of these, you are making it need-
lessly harti for a new user to learn and
remanber them. F.xperienced users have a way
of leaving, and all users have to start out as
new users sometime.
9. If there is information at the top of
the screen the user needs to see, be sure it
doesn't get scrolled off before he gets to Ilse
it. Jf you aren't sure it will still be there
when he needs it, dtsplay it again; don't
count on its being visible now just because
you d i591 ayed i t few steps earlier.
REFERPJCFS
Foley, J.D., Notes and Lectures in a ,course
taURht at G.1-1. University, Fall 1QAO
Giloi, 1,'.K., Interactive Computer Graphics,
Prpntice-Hall Inc., pp. 2n5-?07.
5. When you send an error or warning mes-
sage to the user:-, tell him clearl y what is
wrong, where the error is, anrl what he can or
must do next. Don't just say "invalid code";
give him a list of what the valid codes are,
or provide a "help" or "?" command that will
display them to him without interrupting the
interaction. Don't just say "index out of
range"! Tell him the name of the variable,
and what was in it ("1=0", "X=999QQ99"). If
the indicates that something is wrong
which the user can't. fix, give him a phone
number to call for help, and keep the message
up to date so the> mrnber is right.
Foley, J.D, and Wallace, V.L.,
Natural Graphic Man-Machine
Proceedings of IEF.E, Vol. 62,
1974, pp.
"The &rt of
(',cnversation" ,
No.4, _I\pril
6. If certain data to be input by the user
must function as key elffilents in the data
structure or the procedures on which the task
is based, let him input them at the beginning,
check them thoroughly right away, and give him
a chance to correct them if neP<led. Don't
wait until he has ente>red several of a
form before YOIl tell him "WRONG - FATIl.L
ERROR" and make him re-enter all' the other
data.
Newnan, W.M., "A System for Interactive Graph-
ical Programming", /I!='IP"> of Spring
Joint Computer (',cnference, 196
P
, pp.
Ramsay, H. R., and Atwod, M. F.., "Human Factors
in Computer Systems: A Review of the Litera-
ture", Science Applications Jnc. Technical
Report 21 September 197Q.
Smith, S. L., "Requirements Definition ::lnd
Design Guiriel ines for the Man-Machine Inter-
face in gystem Acquisition", MITRE Techni-
cal Report M80-10, 15 April 1980.
Nov g1 * CRYPTOLOG * Page 24
UNCLASSIFIED
DOCID: 4009838
SECRE'f
OPELINT is Alive
and Well in BGroup
MY INSURANCE COMPANY ,
ENGLAND LIFE, OF
COURSE .. WHY f
f1J......... : ........ L. 86- 3 6
.: '/("
Much has happened in the v.orld of ELINT
.. in meanwhile. Collection systems have
measurement have
i'llproved, And in many areas of DOO, OPELINT
and CCl-I!NT analysts have joined forces against
their This inter-disciplinary min-
gl ing has spawned a new breed of SIGINT
analysts who are equally oomfortable on either
side of the fence, And...no constantly strive
to operate on both sides, to produce the
highest quality, most accurate 3IGINT product
available
he alternate title of this article
could be, "To P,ag Po BLACKBIRD, ann
Other SIGINT Tales," and it might
start with a conversation something
like this:
"Hello, Ralph? You know that SAM site that
isn't there?"
"Yes, Jim, what about it?"
"It just launched tv.o 311."'f's at the SR-71."
"Ch, no!"
by
/
....f.8+ Fi ve years ago, I Iexcellent
article, "Yes, Xln, There Is An FLINT!" (CRYP-
TOLOG, August 1976), ELINT out into
the bright light 9f day for many, His TT::CHEL-
INT oriented piece invited a companion article
from an OPELINT-er in 11., B,ior G Group. No
one has yet responded to challenge, so
this article will hopefully bep;in to fill that
void.
EO 1.4. (c)
P.L. 86-36
P.L. 86-36
.f&r Much of the credit for this welcome
evolutionary stage in the state of the art
known as SIGINT production goes to those
Agency and Community managers with foresight
enough to appreciate the potential of ELINT,
who have pushed to popularize and expand the
ELINT fusion curriculum in the National Cryp-
tologic School, and ...no h;we kept up the suc-
cessful battle to remove the best FLINT col-
lection from the compartment in which it
resided for .so long.
+et-Managers ...no have made the choice to
make F.LINT work in their own SIGINT organiza-
tions have found that activism and. encourage-
ment are the keys to success. Without these
ingredients, the curtain separating the tv.o
major components of SIGINT remains
Nov 81 * CRYPTOLOG * Page 25
SECRE'f

DOCID: 4009838
SECRET
impenetrable, while analysts continue to "go
wi th what they know," rather than trying some-
thing new and strange.
To Pag a "BLACKBIRD" (U)
/
The crux of the dile:nma which roUowed
consolidation was how to keep E1..INTclose to
the entity analysts while still achieving the
economies of scale offered by consolidation,
for OPELINT, worked away frC1Tl the CCMINT it
supports er tuates the se ration of the
tloO
-+er As a resul t,Me /haveia SIGINT. analytic
fUSion effort which/ really has gotten the max-
imlJTl mileage out of both .CO:fIIofT and ELTIofT in
producing a ntlTlbet/ of siM.ificant products and
stud ies wi th far-reaching/ impl ications.
EO 1.4. (c)
P.L. 86-36
Nov Rl CRYPTOLOG Page 26
SECRET
DOCID: 4009838
EO 1.4. (c)
P.L.8636
SECRET SPOKE
Nov ~ 1 If CRYPTOLOG If Page 27
SECRET SPOKE
- __ --0 _ .. _
- ~ ~ - - - ' . ~ - ' . - ._-_._.._ ~ - .
DOCID
E014 (c)
P.L.86-36
SECftE'f SPOKE
I
Try It, You'll Like It! (u)
-+erTn Sllll, we are still on the uphill side
of the learning curve with regard to the best
uses of OPELINT, both on its own and in
fusion. But the more we learn, the more we
find we can do. And, oh yes, who ))f!r forms
these "exotic" analytic routines? Ordinary
Traffic and Special Research fmalysts, just
11ke you and me, with a more than able assist
from -a one 98J ELINT Analyst.
Which Way Did They Go? (U)
+P.+ The reconstruction of a recent SIGHIT
event scenario serves to indicate how valuable
a resource FLINT can be in determining exactly
what occurrE'l'l.
We are all capable of using FLINT to
its full potential, given minimal training and
practice. Let's bring Fl.INT out of the closet
and the spotlight it deserves!
SOWfTON TO NSA-CROSTIC No. 35
"Plain English," by I I
r-1""';";;;';;";;';';""-""';;;""""'11 CRYPTOLOG, May 1977,
reprinted from the fiMl issue of C-
Liners.
"If we want all Agency personnel to speak
and write plai.n English, perhaps we should
first teach Agf'ncy personnel If
want Agency managenent to write con-
cise, active, decisive memos, perhaps we
should first teach Mency. managE!mf'l"lt to be
concise, active, and decisive.
"Let us attack the probl I1l,\.notjust hide
the symptom."
/
EO 1.4. (c)
P.L. 86-36
Nov R1 If CRYPTOLOG If Page 28
SHCREq.J SPOKE
P.L. 86-36
I
!
DOCID: 4009838
UNCLASSIFIED
What doYOU think?
Re,view:
It be Nice if We Could Write
Computer Prograns in Ordinary English -- or
Would It?"
I. D. Hill, The Computer Bulletin,
19'72.
Although this paper was published nearly a
decade ago, it is still right on target in an
area of cooputer technology that is receiving
even more concentrated attention today. There
are many software designers ...no seem to think
that "natural language" (by which they usually
mean "everyday, conversational English") is
the ideal medium for ccmmunication between
humans and cooputers. The arguments for this
idea are obv ious: we all Imow Engl ish, and
nobody has to spend a lot of time and money
teaching it to us. Of course, teaching it to
cooputers WILL require tremendous amounts of
time and money, if it is ever really possible
at all. The "natural language" enthusiasts
are convinced that the vast benefits conferred
by computer English will counterbalance the
'costs. Proponents of "natural language" also
seem to assume that English is an ideal medii.m
for humans to specify exact and detailed
instructions to cooputers and other humans.
Hill has presented some very good arguments
against this assumption, and I believe all of
us who are concerned with human-machine sys-
tems can profit froo a 'careful consideration
of the points he raises. If everyday English
is ineffectual as a means of conveying exact
instructions, it certainly isn't worth spend-
ing all that money and time to design
English-like programming languages.
Hill's paper presents a very clever and
amusing argument against the use of "natural"
English for programming. In fact, in a half-
serious way, it suggests that English isn't
very good for any precise 'description or
instructions intended to guide others'
actions; instead, should learn to use
an algorittrnic formal language, even in speci-
fying procedures for other people, as well as
in working with computers. Hill makes his
points about the deficiencies of English very
convincingly, in spite of the exaggerations
implicit in the humorous view he presents. He
makes some other very interesting points - for
example, that the unreadableness and general
difficulty of legal language, (...tlich attempts
to specify something precisely and
unambiguously), result from the lI1suitability
of natural English for this use. He gives
some amusing examples of people misunderstand-
ing other peoples' descriptions, and some more
serious ones. He uses an ALGOL-like block
notation to show the precise meaning (or
alternative possible meanings) of many exam-
ples quite effectivel y. Cooking rec ipes,
knitting instructions, and musical notation
provide further examples of somewhat better
specialized subsets of English; these are
incooplete, however, and still open to
misunderstandings.
HiH makes the further claim that, even if
a way could be found to enable cooputers truly
to understand natural language inputs, there
remains a much more basic objection. English
just isn't the right language to nJINK in
...nile deciding "EXACTLY what is the right
thing to do". We would sacrifice precision
and power in the way we think about a problem
or task, and also in the way we represent the
task and possible solutions. We would also
lose a main advantage of cooputers:. their
reliable obedience in doing exactly what we
unambiguously instruct them to do, without a
chance of misunderstanding. It wouldn't
really be a help to have computer systems that
responded, like J!leople, "Ol! but I you
meant so-and-so!" (especially if you, the
human user never realized that the system
acting on a totally different, Bl1I' SENSIBLE
interpretation of your instructions until it
was too late for correction!) Hill suggests
that we start by using an algorittrnic form for
specifying legal/financial matters (e.g.
taxes), many of ...nich have to be programmed
into cooputers, anyway.
While this idea of using a "prograJllling"
language in ccxnmll1icating with other people
seemed bizarre to me at first glance, second
thought made it more and more convincing.
English phrases, with BEGIN, END" meaningrul
labels, judicious use of "go-to' s", and care-
ful use of parentheses to define scope, wi th
some other conventi'Ons defining logical impli-
cation, conjunction, and disjll1ction might
prove a highly useful tool. People could
switch to an algorithmic description in this
1anguage whenever they fel t they had not been
understood, or use it whenever they antici-
pated difficulty. It could be taught in ele-
mentary schools, especially when terminals and
interactive teaching networks becooe common-
place. I can 1magine a highly amusing parlor
game involving "charades" or skits, called
"What's my program?" In this game, one team
would compose a set of tricky "programs" for
sets of actions to be performed by the other
team; penalty points would .be scored for
failure to follow the specifications exactly.
What do you thi'J<?
P,L, 86-36
P1-Dec 81-53-11593
Nov 81 CRYPTOLOG Page 29
UNCLASSIFIED
DOCI
-sEeREf
'fillS BOeln\tBN'f ON'fA:INS OBBWORB MhTKRlAb
\
[
[