User Interfaces for Database Systems

Akmal B. Chaudhri
July-September, 1988

Supervisor:

Norman Revell
Senior Tutor, CBSA

Submitted as part of the requirements for the award of the

MSc in Business Systems Analysis & Design,
The City University, London.

Copyright © 1988 A.B. Chaudhri

 Table of Contents

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
CHAPTER 1 - Evolution of the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Evolution of the User Interface .................................................... 9
1.1.1 Microcomputers .......................................................... 9
1.1.2 Mainframes ............................................................... 10
1.2 User-System Interaction ............................................................ 11
1.2.1 Models..................................................................... 11
1.2.2 Classifying Users ........................................................ 14
1.2.3 User Friendly and Ease of Use......................................... 20
CHAPTER 2 - Interaction Styles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2
2.1 Menu Selection....................................................................... 22
2.2 Form Fill-In .......................................................................... 23
2.3 Command Language ................................................................ 24
2.4 Natural Language.................................................................... 27
2.5 Direct Manipulation.................................................................. 31
CHAPTER 3 - Empirical Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3
3.1 Command vs. Form Fill-In......................................................... 33
3.2 Natural Language vs. SQL ......................................................... 34
3.3 QBE vs. SQL vs. Algebraic Language............................................ 35
CHAPTER 4 - Example Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 7
4.1 Menus, Forms & Command Language ........................................... 37
4.1.1 SQL-based Products..................................................... 37
4.1.1.1 Informix-SQL................................................. 38
4.1.1.2 Ingres for PCs ................................................ 38
4.1.1.3 Oracle .......................................................... 38
4.1.1.4 XDB II......................................................... 38
4.1.1.5 dBase IV....................................................... 39
4.1.2 Other Products............................................................ 39
4.1.2.1 Omnis Quartz.................................................. 39
4.1.2.2 dBase Mac..................................................... 40
4.1.2.3 4th Dimension................................................. 41
4.2 Natural Language.................................................................... 42
4.2.1 INTELLECT.............................................................. 42
4.2.2 RENDEZVOUS.......................................................... 43

2
 4.3 Direct Manipulation.................................................................. 45
4.3.1 Query-by-Example....................................................... 45
4.3.2 Spatial Data Management................................................ 47
4.3.3 Dataland ................................................................... 49
CHAPTER 5 - Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 0
5.1 Summary ............................................................................. 50
5.2 Future Developments................................................................ 50
5.3 Conclusions .......................................................................... 52
APPENDIX 1 - Summary of Interaction Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
APPENDIX 2 - Personal Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6

3
 List of Figures

Page No.
Figure 1.1 Syntactic and Semantic Knowledge in Long Term
Memory. 12
Figure 1.2 One Way to Categorise Users is in Terms of Their Relative
Technical and Computer Skills. 14
Figure 1.3 Syntactic and Semantic Knowledge of Different User
Classes. 15
Figure 1.4 Categories of End-Users. 17
Figure 1.5 Types of Online Users. 19
Figure 1.6 Multiple User Interfaces. 20

Figure 2.1 Comparison of High and Low-Level Languages. 26

Figure 2.2 Syntactic and Semantic Knowledge of Different User
Classes. 28
Figure 2.3 Use of Pronouns. 30

Figure 4.1 The Relational Structure for this Database is Created by

Dragging any one Field Name to Another. 41
Figure 4.2 The Four Viewports in RENDEZVOUS. 44
Figure 4.3 QBE Skeleton Table. 46
Figure 4.4 World View and Magnified View of SDMS. 48

4
 Acknowledgements

I would like to thank Norman Revell for supervising me for this project, and for his useful
comments after reading the draft copy of the report.

Thanks also to the Computer Department at the City of London Polytechnic for the use of
its facilities. In particular, my thanks to Kay Taylor.

Special personal thanks to Dina Hamed.

A.C.
The City University, London.

5
 Abstract

With the growth in database systems for a wide range of applications, there is a need for
interfacing with databases in a manner that would be suitable and convenient for all users.
At one level, database systems may offer a query language whilst at another they may offer
forms, menus or icons.

To assist the database designer in providing different user interfaces, a theoretical analysis
will be undertaken. This will hopefully provide some guidelines on identifying potential
users, thus ensuring that adequate interaction facilities are provided. To support this
analysis, there will be a review of the major interaction styles available. Some consideration
will also be given to empirical studies. Finally, a range of database systems will be
reviewed to illustrate how user interfaces have been implemented in practice. Future
developments will also be briefly considered.

6
 Overview

User interface design has become an important consideration for software developers since,
with the growth of personal computing, users are increasingly demanding better quality
software that allows them to interact more naturally with the system. Often, the user
interface is neglected or ignored, but no matter how powerful the software is, ultimately, it
will be the ease of use that will determine its success, (Moody, 1987).

The same would also apply to Database Management Systems (DBMSs). Shneiderman
(1978:417), confirms this view:

“As questions of technical feasibility and performance of database systems

are resolved, increased attention is being paid to human factors. There is
widespread recognition that future systems will be commercially viable only
if the user interface is in harmony with user skills and task requirements.”

The following papers will discuss some of the issues involved in user interface design (as
outlined in the objectives). There are five chapters, arranged as follows.

Chapter 1 will begin with a brief discussion on the evolution of user interfaces on
microcomputers and mainframes. There will also be a theoretical discussion of interface
design. This will include the views of a number of authors, suggesting the need to develop
a model of user knowledge and behaviour. Several methods will also be presented to
enable users to be classified - an important feature, since it may be necessary to provide
different levels of interaction for different users.

Chapter 2 will examine some of the methods that are available for users to interact with
database systems. This will include menu selection, form fill-in, command language,
natural language and direct manipulation. The advantages, disadvantages and suitability of
each technique will also be discussed.

Chapter 3 will present the results of some empirical testing where various styles of user
interaction (as mentioned above) have been compared with one another. The aim being to
determine if one method has proved to be more suitable for particular applications.

Chapter 4 will review some popular database software, and also give examples of database
systems for the various interaction styles as discussed in Chapter 2. In particular, attention
being focused on the screen interface, keeping the user appraised of what is happening,

7
providing help, and letting the user be more in control of the processing steps, (Everest,
1986:162).

Chapter 5 contains a summary and also looks ahead to possible future developments in user
interface design.

8
CHAPTER 1 - Evolution of the User Interface

1.1 Evolution of the User Interface

The aim of this section is to briefly describe the development of software front-ends, from
the early programming environments to the new window and icon systems.

1.1.1 Microcomputers

Everest (1986), suggests the following factors as having a profound impact on the design
and use of DBMS tools in the microcomputer environment.

Firstly, microcomputers are smaller and cheaper. Organisations are not as concerned with
optimising machine efficiency, and there is increasing attention on improving human
productivity.

Secondly, software is cheaper and off-the-shelf. DBMS software for micros is a fraction of
the cost of mainframe DBMSs. Successful microcomputer software must be self-teaching
and developers have paid greater attention to ease of use.

Thirdly, there are more novice and impatient users. Increasing numbers of novice users
will not tolerate low-level interaction with the software. Easier to use and more integrated
packages provide menus, online documentation and help screens.

Fourthly, the user is inherently online. Re-designing mainframe DBMS software to run
online would be expensive. For micros, however, the system must be in constant
communication with the user, responding to requests and advising on the status of actions.

Lastly, the user is both end-user and developer. The person at the terminal is the end-user,
the developer, the operator, the data entry clerk, and the installation manager.

However, even the microcomputer has undergone significant changes in user interface
design. Early systems were aimed at trying to get the software working in the smallest

9
space possible, (Moody, 1987). Perhaps one of the first significant breakthroughs came
with the Visicalc spreadsheet for the Apple II. This enabled users to display the range of
command options (e.g. saving or copying), by pressing the slash key. The next major
development came with Lotus 1-2-3. This permitted users to select options by using either
the cursor keys, or by entering the initial letter of the command. In addition, a subsidiary
menu would be displayed as each main option was highlighted.

The Windows, Icons, Mouse and Pull-down menus (WIMP) approach was originally
developed at Xerox PARC for the Star Information System. The aim of the developers was
to adhere rigorously to a small set of design principles, which would simply the human-
machine interaction, (Smith et al.., 1982). The team at Xerox devoted the equivalent of
thirty-years to develop the Star user interface. Perhaps more importantly, the interface was
designed before the functionality of the system was decided, before the computer hardware
was built and even before any product software was written, (Smith et al., 1982:246).

The Star, however, was not a very successful product due to poor marketing, high cost and
the lack of a high quality output-device. But, Apple Computers used some of the
development team on the Star to produce firstly the Apple Lisa, and then the Apple
Macintosh. Software developers were sufficiently interested to produce packages that used
the WIMP interface extensively.

There are also similar operating environments for the IBM PC, such as GEM and
Windows. Many developers have, however, opted to include a WIMP interface directly in
their software. Framework was an early example of this, where pull-down menus and
windows were integral to the way the product functioned. The latest version of dBase III is
a more recent example. Other examples can be found in a review by Which Computer?
(1987) of easy to use databases, where out of 34 personal databases, 17 were menu driven,
4 command driven, 7 menu and command driven, and 6 used a WIMP interface. Natural
language interfaces are included in the command language category.

1.1.2 Mainframes

Early DBMSs for mainframes were designed to operate with the efficiency of the hardware
in mind, as considerable capital investment was employed. The major facilities offered by
DBMS software were aimed at the application programmer. Users were offline and had to
prepare job requests in advance. These would then be processed by the computer at some
later stage in a batch mode. The majority of DBMSs were used by creating programs,
filling in forms, or preparing a file of commands, (Everest, 1986).

10
Even in the early 1980s, vendors were still supplying systems that by and large offered
very little online interaction. For example, the British Computer Society Query Languages
Group conducted a survey in 1980 of 135 query languages, (British Computer Society,
1981:78-83). The findings showed that 120 were command driven, 6 command driven
with partial dialogue and only 9 offering interactive dialogue (7 of which used forms).

However, a review of some database file handlers for the IBM 43xx and 308x series
hardware (Computer News, 1984), credited four of the systems as providing fifth
generation lexicon driven languages. Most of the nine packages reviewed also offered a
variety of menu and command driven interfaces.

Increasingly, mainframe DBMS vendors are providing better user interfaces for their
systems. Also, personal computers are increasingly being connected to many mainframe
systems (e.g. via SQL drivers), which enable the graphical and WIMP interfaces available
on PCs to improve human-computer interaction. This contrasts with the terminal emulation
approach - the PC merely acting as a window into the mainframe, with little or no control
over the user interface.

A number of DBMS systems for microcomputers and mainframes will be examined in

greater detail in Chapter 4.

1.2 User-System Interaction

This section will describe how models of human behaviour in using computers can be used
by designers to improve human-machine interaction. The views of several authors will also
be presented on various ways to classify users.

1.2.1 Models

Shneiderman (1978), states that since a database system must cater for a wide range of
applications and users, there is a need to establish a framework for the designer, to ensure
that the system isn’t optimised for a subset of the application domain. Functionality, task
analysis and human behaviour are important factors. Shneiderman (1987) suggests that the
syntactic/ semantic model is one method that can be used to provide a useful way to
organise the design process.

A detailed discussion of the model can be found elsewhere (Shneiderman, 1981 & 1987).
Briefly, the model divides human cognitive knowledge into two parts (see also Figure 1.1):

11
 • Semantic Knowledge:
- Hierarchically structured.
- Acquired through meaningful learning.
- Resistant to forgetting.
- Query language independent.
• Syntactic Knowledge:
- Arbitrary.
- Acquired through rote memorisation.
- Easily forgotten (unless frequently rehearsed).
- Query language dependent.

HIGH-LEVEL
PROBLEM DOMAIN
SEQUEL

QUEL

QBE
LOW-LEVEL
PROGRAM DOMAIN

SEMANTIC SYNTACTIC

Figure 1.1 - Syntactic and Semantic Knowledge in Long Term Memory (Shneiderman,
1981).

For databases, semantic knowledge concerns the meaning of entities represented, and the
ways of organising data for retrieval. Syntactic knowledge relates to character strings (or
numbers) stored, and the syntactic forms of the retrieval language.

Functionality and task analysis are also necessary to the design process. Shneiderman
(1978) identified the following points which may be useful:

• Functions:

12
 - The operations that the users wish to perform on the database, such as the
insertion and deletion of items, and the retrieval of information.
• Tasks:
- To perform the above functions requires one or more of the following tasks:
1. Learning the syntax and semantics of the function.
2. Composition of the syntax needed to perform a function, e.g. the user
formulates a query or responds to menu options.
3. Comprehension of function syntax composed by someone else.
4. Debugging of syntax and semantics written by the user or someone else,
to correct errors.
5. Modification of a function, e.g. formulating a new query from an
existing one.

Irby et al. (1977), also note the importance of task analysis. The designers of the Xerox
Star noted that designing the user interface was one of the most troublesome and least
understood aspects of interactive systems. In trying to develop a suitable methodology,
they identified the following areas of concern:

• The provision of languages by which users can express their commands to the
computer.
• The design of display representations that show the state of the system to the
user.
• Other abstract issues that affect the user’s understanding of the systems
behaviour.

Task analysis establishes who the users are, what their goals are in performing the task,
what information they use in performing it, what information they generate, and what
methods they employ, (Irby et al., 1977).

An ESPRIT report (ESPRIT, 1985), states that models of user-system interaction could be
developed at different levels. For human factors, these were - physical ergonomic,
cognitive psychological and situational psychological. The division illustrates how user-
system interaction can be focused very narrowly (e.g. screen display), or more widely
(e.g. the whole situation in which a user is interacting with the system). On the cognitive
aspect, the GOMS model developed at Xerox PARC (Card et al., 1983) is perhaps one of
the best known, and has been successfully applied to a number of well-structured tasks,
such as text-editing.

13
The User Software Engineering (USE) methodology (Wasserman, 1985), was an attempt
to combine ideas about user involvement in the design of interactive information systems
and software engineering. The three-stage methodology consists of firstly identifying user
characteristics (e.g. ability to type, intensity of anticipated usage, etc.). The second stage is
the design of the user interface for the proposed system. The final stage creates an
executable version of the user interface defined at level two. The technique uses transition
diagrams to specify the design, and enables the rapid generation of prototypes to present
the user view of the system.

Shneiderman (1987:79-81) provides additional references to human-computer interface

design.

1.2.2 Classifying Users

The discussion until now has used the term “user” without actually defining who the user
is. Many authors (e.g. Zloof, 1978:32-34; Shneiderman, 1978:422-423; Everest,
1986:168-169), recognise the existence of a variety of users.

Simpson (1986:1-2) suggests a classification of users into four categories, along a

continuum (see Figure 1.2).

Professionals
without Computer
computer professionals
Technical skill

experience

Naive Skilled
users clerks

Computer skill

Figure 1.2 - One Way to Categorise Users is in Terms of Their Relative Technical and
Computer Skills (Simpson, 1986).

14
In designing an appropriate user interface, Simpson states that it is firstly necessary to
define the “audience”, as a system may need to be designed for a combination of user
types. He further suggests the following two guidelines:

• Write for the lowest common denominator:

- The simplest approach, but may not be satisfactory for sophisticated users.
• Provide different features for different audiences:
- More difficult to program, but better for all users.

The syntactic/semantic model previously mentioned, can also be used as a basis for
defining users (see Figure 1.3).

SYNTACTIC KNOWLEDGE

LITTLE A LOT
LITTLE

NAIVE DATA ENTRY/

USER JCL NOVICES
SEMANTIC KNOWLEDGE

INFREQUENT FREQUENT
A LOT

NOVICE PROFESSIONAL
USER USER

Figure 1.3 - Syntactic and Semantic Knowledge of Different User Classes

(Shneiderman, 1981).

Naive (or novice, or casual) users have very little syntactic knowledge. Interaction with the
system may therefore be computer directed (e.g. menus or forms). This is the class of user
defined by Codd (1974) as,

15
 “one whose interactions with the system are irregular in time and not
motivated by his job or social role.”

Codd also describes this class of user as the most rapidly expanding.

Infrequent novice users (or non-programmer professionals) are knowledgeable about the
problem domain, though they will be intermittent users. This class of user may be willing
to learn a certain amount of syntax. Equally, the use of menus and help screens will help
them to perform their tasks. Zloof (1978), states that,

“In this category, one can include secretaries, clerks, engineers, analysts,
etc.”

Frequent users (e.g. application programmers, professional database users) have both
syntactic and semantic knowledge. Shneiderman (1987) defines them as “power” users that
wish to complete their work rapidly. In addition he states that these users will need,

“Strings of commands, shortcuts through menus, abbreviations, and other

accelerators ...”

Martin (1982:103) has suggested a classification of computer end-users into five

categories. This is illustrated in Figure 1.4. Martin also recognises the need to provide
adequate user-driven tools (e.g. database languages, report generators) for Class 4 Users
(non-DP-skilled). He feels that an improvement in software for these end-users is
necessary for the future of the computer industry. Through the use of such tools, this class
of user can automate many activities without requiring any conventional programming
skills. In addition, Martin (1982:106) also notes that it may be necessary to support many
different interaction styles since, as he states,

“A type of dialogue structure that is good for one user is not necessarily
good for another.”

16
 1
INDIRECT
(Users employ
computers via
a third party,
e.g. airline
2
customers)
OFF-LINE
(Users employ
paper listings or
reports)
3
USE BUT DO NOT
Figure 1.4 - Categories of End-Users (Martin, 1982).

DIRECT
CREATE APPLICATIONS
(Conventional terminal
users such as bank tellers,
17

clerks, airline agents)

4
ON-LINE NONPROGRAMMING
(Users employ (Users employ simple
a terminal) application generators)

USE AND
CREATE
APPLICATIONS

5
PROGRAMMING
(Users employ BASIC,
APL, etc.)
The British Computer Society (1981:67-68) also recognises that one form of dialogue may
not be suitable for all applications or all users. It suggests a classification of users into the
following five broad categories:

1. Programmers:
- Use query languages as very high-level languages for generating reports or
performing operations with test data.
2. Scientists, Engineers, Technicians:
- Usually knowledgeable about computers, and could proceed to
sophisticated levels of use with command modes and macros, but may
require query formulation aids.
3. Non-DP Intermediaries:
- Require facilities to create interfaces for users less familiar with systems
than themselves.
4. Non-expert Clerks, Assistant Librarians:
- May start with menus and prompts and progress to forms-driven or limited
command language modes.
5. Casual User:
- Examples could be managers who need to interact with database systems
from time to time for decision support or evaluation purposes. Menus and
prompts would be most suitable, augmented with natural language
interfaces in future.

Everest (1986:168-169), has suggested a classification of DBMS users according to style

of dialogue and mode of use. Figure 1.5 illustrates this, and also shows how users may
migrate from one category to another. For example, novice users may begin with prompts
from the system (as previously mentioned). As they become more experienced, the
command style of dialogue can be used. Eventually, they may develop systems for
themselves and other users.

Everest (1986:179-181) also acknowledges the need for different user interfaces. For the
same DBMS, he suggests that it may be possible to have:

• System-driven interface with menus and prompts for the novice user, and
liberal use of help facilities.
• User-driven interface with an ad hoc command language.
• An extended command language for building command files for deferred
execution.

18
 • Natural language interface for the casual user.

For the microcomputer environment, however, he recognises that there may be only one
type of user (see 1.1.1 Microcomputers - user is both end-user and developer).

MODE OF USE
ad hoc planned/deferred

NOVICE APPLICATION
END USER GENERATOR
System
(Menu)
Driven
STYLE OF DIALOGUE

(Command)
Driven
User

EXPERIENCED SYSTEM
END USER DEVELOPER

Figure 1.5 - Types of Online Users (Everest, 1986).

Furthermore, Everest suggests that architecturally, the various interfaces can be developed
as follows. Since menu and prompting dialogues can virtually capture information
expressed in command form, then a system-driven dialogue can be built on top of a
command-driven interface. Similarly, a natural language interface could be developed on
top of a command-driven one. This is illustrated in Figure 1.6.

Additional discussion of user and task taxonomies can be found by Schneider (1982).

19
 USER USER USER

SYSTEM-DRIVEN USER-DRIVEN
Menus & Prompts Natural Language
INTERFACE INTERFACE

USER-DRIVEN
Formal Command
Language
INTERFACE

INTERNAL
Command
Language

COMMAND
COMMAND
MANAGER
FILES
and
and
EXECUTOR
COMMAND
CODE

DBMS FUNCTIONS

Figure 1.6 - Multiple User Interfaces (Everest, 1986).

1.2.3 User Friendly and Ease of Use

Zloof (1978) states that words such as “ease of use” and “user friendly” are very difficult to
define and quantify. The terms being very subjective and depending on a number of factors
such as user taste, background, environment and training. However, Zloof quotes a
number of sources (e.g. Shneiderman, 1978) where researchers have attempted to

20
determine these factors using a number of criteria such as average time required to
formulate a query, percentage of correct queries, confidence ratings and classification of
errors.

Many authors agree (e.g. Martin, 1981; Greenblatt & Waxman, 1978) that Query-by-
Example (QBE) is an “easy to use” database language. Shneiderman (1983) puts Query-by-
Example into the category of the “direct manipulation” interaction style. Another example of
a system which falls into this category, and in particular seems to suit novice users, is the
Spatial Data Management System (SDMS). There will be further discussion of QBE and
SDMS in Chapter 4. However, direct manipulation is just one of a number of interaction
styles. Shneiderman (1987:57-60) suggests that designers can choose from five primary
methods:

1. Menu Selection.
2. Form Fill-In.
3. Command Language.
4. Natural Language.
5. Direct Manipulation.

Each mode of interaction will be discussed in greater detail in Chapter 2. The advantages
and disadvantages of each method have also been summarised in Appendix 1 for
convenience.

21
CHAPTER 2 - Interaction Styles

2.1 Menu Selection

Using Figure 1.5, it can be seen that menu driven systems are suitable for inexperienced
users, though Shneiderman (1987:59), suggests that they can also be,

“appealing to frequent users if the display and selection mechanisms are

very rapid.”

The system initiates the dialogue, using menus and screens. The user responds to the
messages and prompts - the sequence being determined by preceding dialogue between the
system and the user.

For database systems, Everest (1987:168-169) suggests that, using this mode of
interaction, the user can step through:

• The definition of a data file and the characteristics of data items.

• The entry of data to create or update records.
• The examination of (whole) records (or data from multiple records) on the
screen one record at a time.
• The definition of an output report to display data from several records at once in
a columnar fashion.

One of the major benefits offered by menu selection, is that all the possible choices
available will be displayed to the user. Consequently, there is no language syntax to learn,
and it should not be possible to make a wrong choice. However, careful analysis on the
part of the designer is necessary, to ensure that all functions are supported.

Hauptmann & Green (1983) suggest that one main drawback of menu selection is that the
user may have to leaf through many pages of menus. This may become very tedious,
particularly for experienced users.

22
A more detailed discussion of menu systems can be found by Shneiderman (1987).

2.2 Form Fill-In

Some tasks may be unsuitable for menu selection. For example, when data entry is
extensively needed. In such circumstances, a form fill-in approach could be used.

In this mode of interaction, the system prompts with a number of requests at the same time.
Most often this takes the form of a template, which is presented on the screen. The user is
required to fill in blanks. A useful facility, often provided by intelligent display devices, is
to allow the user to move between the various prompts to correct or amend data already
entered.

Martin (1981) uses the MARK IV DBMS as an example of a forms driven system. MARK
IV offers comprehensive forms facilities for the definition and manipulation of data. Martin
(1981:82-83), gives an example of an application that could be implemented using this
approach.

Ingres is a Relational DBMS (RDBMS) that offers a forms-driven user interface for end-
users. The manufacturers suggest the following benefits of forms design to customising the
user interface (Relational Technology Incorporated, 1987):

• Interactive form design:

- The screen is used as an interactive canvas.
- The form can be tested whilst it is being designed.
- No source code or compilation of instructions is required.
• Eliminating maintenance:
- Forms can be created from scratch or using previously designed ones as
models.
- Errors are detected during the design stage, so no maintenance is
subsequently necessary.
• Windows to your database:
- Screen questionnaires are used to define text and data fields.
- The cursor is used to indicate the position that data will be displayed.
- The screen size is not a restriction, since scrolling is possible horizontally or
vertically.
• Validation checks for data entry:
- Forms can be used to capture data, update the database and control the flow
of applications.

23
 - A wide range of validation checks is possible.
• Promoting fast and accurate data entry:
- The sequence of data entry can be controlled, so that, for example, the
cursor skips protected fields, saving time.
• Visual features:
- Modern terminals can handle a range of features such as colours, reverse
video, blinking, etc. These can be used to enhance the display.
• Self-instructional applications:
- User’s can be provided with context-specific help on screen, reducing the
need for documentation and training.
• Developing a standard user interface:
- Forms can be produced from existing ones. Therefore, screen layout,
terminology and operational sequence can be easily maintained throughout
an organisation.

Ogden & Boyle (1982) compared three human-computer interface designs for a report
modification task. One design was a form fill-in style. The results of their findings will be
discussed in Chapter 3.

2.3 Command Language

Dialogue at the command level becomes user driven. In this form of interface, the system
will wait for the user to enter the next command. Commands may be executed immediately,
or entered into a file for deferred execution. In the latter case, communication between the
user and the system becomes one-way.

When an exclusively command-driven system is first started, the user will be prompted by
the system for the next command. For example, dBase II will display a dot in the first
column, whereas a “?” is displayed by SYSTEM 2000.

Since the system waits for the user to specify what action should be performed next, the
implication is that the user is aware of the available commands. Therefore, this level of
interface would not be suitable for novice users.

Frequent users (or “power” users, as defined by Shneiderman, 1987), would be best suited
to this form of dialogue. However, as mentioned earlier (see 1.2.2 Classifying Users), it is
possible that novice users may become more experienced. They can then use this form of
dialogue to bypass menu hierarchies and create macros and command files for queries or
report definitions, (Everest, 1986).

24
A DBMS command language, according to Everest (1986), should be a high-level data
language. It should provide single commands that can operate on a file (or multiple files) at
the same time. Everest suggests that the following operations should be supported:

• Select records from a file which satisfy a Boolean expression.

• Project named fields from those records.
• Derive additional values for each of those retrieved records.
• Sort the selected records for output.
• Calculate statistics (e.g. count, sum, etc.) on certain fields for the whole file or
at “control breaks”.
• Present the output with appropriate titles and headings.

In a low-level data language (e.g. COBOL), Everest states that a single statement is
semantically simple, but to express a processing task, many statements are needed.
Consequently, a low-level language is more difficult to learn and to use, as users must be
aware of the interdependencies and sequence constraints of statements.

For a high-level data language, Everest states that in contrast, each statement implies more
underlying processing steps. As a result, the user view of the data structure is simpler, and
the processing specification is easier to formulate, understand, and modify.

The benefits of high-level data languages (Everest, 1986:175) are:

• Allow the user to more closely and directly relate to the problem.
• Can insulate users from physical data storage considerations and machine-level
constraints.
• Can reduce application development time by making it easier to define a data
structure (or a user view) and to specify processing against that structure.
• Are more readily understood by a user and, therefore, require less training than
low-level languages.

Everest, however, concludes that these reasons were precisely the same for the initial
development of high-level programming languages (e.g. COBOL, FORTRAN), for the
specification of processes.

An example application, comparing high and low-level data languages is given in Figure
2.1. Martin (1981:80-81 & 84-86), also gives an example using IBMs GIS (Generalized
Information System), which he describes as,

25
 “a high-level programming language restricted to operations on a data base
structure using the DL/I data description language.”

Database Schema: (system)

ALL-ORGS-SET

ORGANIZATION

ORGNO ORGNAME ...

ORG-EMP-SET

EMPLOYEE

EMPNO EMPNAME ...

EMP-SSKILL-SET

SECONDARY
SKILLS
SSKILL ...

High-Level Language:
FROM PERSONNEL-ORGANIZATIONAL DATABASE
PRINT ORGNAME, EMPNAME, COUNT SSKILL PER EMPLOYEE
WHERE ORGNO BETWEEN 2110 AND 2119 AND
EMPLOYEE HAS COUNT SSKILL GT 1.

Low-Level Language:
The equivalent low-level program is too large to display here -
the user must navigate through the data structure, initializing,
incrementing a counter, finding the "next" record, and testing for
the end of a set of records in order to take an alternative path in
the processing logic.

Figure 2.1 - Comparison of High and Low-Level Languages (Everest, 1986).

Martin states that the 14 lines of GIS code used to produce an example report would require
the equivalent of 250 lines of COBOL code! He recognises, however, that GIS is not
aimed at the casual end-user, but a programmer or trained specialist. He suggests that non-

26
procedural languages, such as Structured Query Language/SEQUEL (SQL) or Query-by-
Example (QBE) would be more suitable for end-users without programming skills.

Some SQL-based products and Query-by-Example will be discussed in Chapter 4.

2.4 Natural Language

Natural Language interfaces eliminate the need for syntax learning, (Shneiderman, 1978).
Since most users are competent in Natural Language (NL), it would seem to be an ideal
method for database interaction.

NL systems, however, may not be suitable for all types of users. Shneiderman (1981) uses
the syntactic/semantic model to determine which class of user would benefit from using an
NL interface for database applications (see also Figure 2.2):

• Naive User:
- Will be stymied by NL systems because these users don’t even know where
to begin asking questions and might not be reasonable partners in a
clarification dialogue.
• Data Entry/JCL Novices:
- Would also lack the semantic structure to actively pursue a dialogue.
• Frequent Professional Users:
- Would probably prefer the precise concise query facility.
• Infrequent Novice Users:
- The most likely group to benefit. These users have semantic knowledge of a
problem domain, yet are not knowledgeable in the query language syntax.
- Applications which may be suitable include library card catalogues, airline
schedules, or banking transactions.

Shneiderman feels, however, that even the group that would benefit most may be better
served by menu selection facilities instead - a view shared by Everest (1986:179).
Shneiderman suggests that the following problems need to be overcome.

Firstly, unrealistic expectations to the computer’s power. Users may pose questions
requiring value judgements, such as, “How can I improve profits?” or “Is the defendant
guilty?”.

27
 SYNTACTIC KNOWLEDGE

LITTLE A LOT

LITTLE
NAIVE DATA ENTRY/
USER JCL NOVICES
SEMANTIC KNOWLEDGE

INFREQUENT FREQUENT
A LOT

NOVICE PROFESSIONAL
USER USER

Figure 2.2 - Syntactic and Semantic Knowledge of Different User Classes

(Shneiderman, 1981).

Secondly, attempts to request information not contained in the database. NL users may not
be aware of the contents or semantics of the database, and may pose unanswerable
questions. Codd (1978:21) describes this problem as “semantic overshoot”.

Thirdly, developers may need to design long and tedious clarification dialogues, to
overcome the ambiguities of English syntax. Sophisticated users who are careful in their
choice of words may find the clarification dialogue particularly annoying. Existential and
universal quantification (e.g. SOME, ALL or NOT in logic) may also cause problems.

Fourthly, although users may know English syntax, they may not be aware of the
semantics of question asking using a database system. A concise and precise query
language will teach users the semantics of question asking, and help users in formulating
complex queries.

28
Fifthly, novel screen manipulation techniques may be more appealing than lengthy and
tedious NL dialogue. Positional notation schemes such as QBE or Spatial Data
Management (discussed later), may be more attractive.

Lastly, the overhead of creating and maintaining an NL interface will be high in comparison
to other techniques. Query language or menu selection are possible alternatives to NL
systems. Hauptmann & Green (1983) also agree that NL interfaces will require software of
extreme size and complexity.

Problems of ambiguity are also discussed by Hill (1983). Harris (1983) suggests that there
are three possibilities, for users to access information held in a database - human
intermediary, formal computer language or natural language. He agrees with the view that
within a restricted semantic environment, a discourse is possible with a database using an
NL interface. Using examples of user experience with the INTELLECT system, Harris
(1983:78) states that,

“natural language database query technology does provide significant

advantages over both the intermediary approach and the formal language
approach.”

Other research (e.g. Small & Weldon, 1983) showed no such advantages. These issues
will be discussed in more detail in Chapter 3.

Wallace (1984) in examining the state of current commercially available NL systems, states
that most of them attempt to construct a formal query of the input, rather than trying to
determine its meaning. The consequence is that the system is often “caught out”, since the
intended meaning is beyond the scope of its formal query language.

Wallace suggests that one of the most essential components of an NL system is referring
back to previous queries. Most current systems, he adds, being able to cope with at least
pronouns which can be interpreted as follows:

• A pronoun refers back to the result specification and rule of the previous query,
or
• If the rule from the previous query is inconsistent with the rule from the current
query, the pronoun refers back to the result specification without the rule.

An example to demonstrate this can be found in Figure 2.3.

29
 Entities:

customer (code, name, balance, county, ...)

order (code, ordercode, ...)

Queries:

"Give the name and current balance for customers in Berks"

SELECT NAME BALANCE

FROM CUSTOMER
WHERE COUNTY = "BERKSHIRE"

"List their orders"

SELECT NAME BALANCE ORDERCODE

FROM CUSTOMER, ORDER
WHERE CUSTOMER.CODE = ORDER.CODE AND
COUNTY = "BERKSHIRE"

Figure 2.3 - Use of Pronouns (Wallace, 1985).

How formal queries can be executed against the database was illustrated in Figure 1.6. The
NL interface attempts to interpret user commands, prompting for additional information or
clarification to resolve ambiguities. The output from the NL processor (which is now
syntactically correct) is received by the command manager, which loads the appropriate
program code to execute the command.

With regard to developments in NL systems, Wallace (1984) suggests that for user input,
NL systems may be used to augment menu systems for some applications. In the longer
term, NL front-ends may be integrated with voice recognition software. For user output,
Wallace suggests that the integration of NL systems with graphics packages is already
taking place (e.g. INTELLECT). In addition, Wallace states that since NL input and NL
generation are distinct tasks, it is possible that NL generation packages may be integrated
with NL front-ends in the future.

Research in NL interfaces for database systems is very active. Shneiderman (1978:420),

for example, quoted the ACM Special Interest Group on Artificial Intelligence, which had
reports of 52 projects on NL interaction with databases.

30
2.5 Direct Manipulation

Everest (1986:163-168), based on the earlier work of Shneiderman (1983), discusses the
following emerging principles of direct manipulation:

• Continuous, visual representation of the object of interest.

• Physical mechanisms, instead of complex language syntax, to position a cursor
and manipulate the object.
• Rapid, incremental operations immediately display the effect of the actions.

For DBMSs, the objects which will need to be represented are records (and associated data
item values) and relationships. For example, dBase Mac, a DBMS for the Apple
Macintosh, displays the data structure graphically, with data files as boxes and
relationships as arcs between the boxes. Different arcs representing different
characteristics.

Everest identifies the following physical mechanisms which can be used for positioning a
cursor - arrow keys, joystick, trackball, mouse, graphics tablet, light pen, touch screen and
audio recognition. The advantage of using such mechanisms is that users do not need to
learn the command structure, semantics or syntax of a query language. The interactive user
interface then involves the following (Everest, 1986:164):

• Positioning a cursor over the object of interest - menus, text, data fields, or a
graphic image.
• Actioning (specifying actions) to manipulate the object - accept a menu option,
cut or copy text, etc.
• Entering text or numeric values. Keyboarding (typing numbers and characters,
etc.) is required for entering text, data names when defined, and data values.

Everest concludes that since no language syntax is required, syntax errors should be
impossible. Also, being restricted to displayed items, users cannot make an invalid choice.
Shneiderman (1983 & 1987), however, suggested some possible problems with direct
manipulation:

• Performance may not necessarily be improved using spatial or graphic

representations.
• Users must learn the meaning of the components of the graphic representation.
• Graphic representation may be misleading.

31
 • Excessive screen display space may be required.
• For experienced typists, moving a mouse or raising a finger to point may
sometimes be slower than typing.

The advantages of direct manipulation (Everest, 1986:168; Shneiderman, 1983:64-65 &

1987:201-202) are:

• Novices can learn basic functionality quickly through a self-running tutorial or

demonstration by an experienced user.
• Experts can work quickly.
• Knowledgeable intermittent users can retain operational concepts.
• Errors are rarely needed.
• Users can immediately see if their actions are furthering their goals, and if not,
they can change their actions.
• Users experience less anxiety with a comprehensible system and easily
reversible actions.
• Users gain confidence and mastery because they initiate action, feel in control,
and can predict system responses.

Shneiderman (1983) suggests a number of potential applications that could be implemented

using direct manipulation. One of these, a small database of personal addresses displayed
in the form of a Rolodex-like device, is actually very similar in principle to software (e.g.
Hypercard, Guide) which has recently been developed for the Apple Macintosh.

32
CHAPTER 3 - Empirical Testing

3.1 Command vs. Form Fill-In

Ogden & Boyle (1982) compared three human-computer interface designs for a report
modification task. One was a command dialogue style, one a form fill-in, and the third a
hybrid of the two.

The study was aimed at determining whether there were any performance or preference
differences between the two dialogue styles for naive computer users, (Ogden & Boyle,
1982).

Twelve students with little experience in using computers were recruited for the
experiment. All the subjects were trained and tested in each method. In addition, after
subjects had completed all three sessions, an additional two preference sessions were held.
These required similar modifications to the performance tests, but subjects could choose
from the dialogue styles.

The performance results showed that the form method was the easiest to use, requiring the
least time to complete a task. This conclusion was supported by the preference sessions
where the students overwhelmingly preferred the form method to the other approaches.

The results are important for database systems, since many DBMSs offer report writing
facilities. Users therefore need to be able to edit and modify tabular reports. Ogden &
Boyle suggest that formatting such reports usually consists of a small range of parameters
(e.g. column width, column separation, etc.), and from this study, it appears that a form
fill-in approach is best suited as the command interface for such user tasks. This is
confirmed by Ogden & Boyle, who conclude that,

“The results of this test indicate that subjects have little trouble learning how
to use an interface that is based on specification list modification. This
finding will likely be true for similar tasks which require the modification of
a small set of parameters.”

33
3.2 Natural Language vs. SQL

Small & Weldon (1983) conducted a series of tests comparing NL and SQL for a series of
data retrieval tasks (simple problems, complex problems, and problems involving complex
data retrieval paths).

For the purpose of the research, an NL interpreter for a computer was not developed. The
aim was merely to determine whether NL was simpler to use than SQL. Consequently,
human research assistants were used to interpret the English commands, since as Small &
Weldon state,

“Since the purpose of natural language processors is to mimic the abilities of

people, adult humans necessarily represent the closest available
approximation to an ideal natural language processor.”

The NL used was restricted in its semantic power, so that users would need to specify quite
precisely the information that was required.

The subjects used were volunteers. Over a period of two days, they were instructed in
formulating queries in NL and SQL, and tested in a number of sessions. During these
sessions, the computer that controlled the experiments recorded a number of variables.
These were as follows:

• The number of language errors (invalid queries) not due to spelling.

• The number of valid queries that produced the wrong data (mismatches).
• The time in seconds from the presentation of the problem to the first response.
• The accumulated subject response time from the problem presentation and re-
presentation to the first valid query.

Small & Weldon describe in detail how these factors were measured in their paper.

On the basis of their work, Small & Weldon concluded the following.

Firstly, the results showed that SQL was probably easier to use (by virtue of its shorter
response time), but otherwise there was no difference in accuracy of queries for the two
languages.

Secondly, SQLs advantage appeared to be conceptually based.

34
Thirdly, the superiority for structured language shown in the experiment might be
restricted. This was because some subjects were lost due to slowness or other problems
with the task, and so the results might only apply to an elite group.

Finally, as Small & Weldon summarise their work, they state,

“If they can be generalized, the results are quite striking. A structured
language was superior to a version of English so sophisticated that
implementing it on a machine is beyond present capabilities.”

3.3 QBE vs. SQL vs. Algebraic Language

Greenblatt & Waxman (1978), report upon their work in comparing three database query
languages based upon Codd’s relational database organisation.

In the introduction to their paper, the authors state that due to the increasing number of non-
programmers interfacing with database systems, there is a need to develop query languages
that can be learned, understood and applied with as little effort as possible. Although the
languages they chose were all based upon the relational model, Greenblatt & Waxman note
that the query languages varied in their English-likeness and procedural versus declarative
query formulation.

The aim of their work was twofold. Firstly to determine which of the three languages had
better learning and application capabilities (using the variables of time, accuracy, and
subject confidence), and secondly to verify earlier research on Query-by- Example.

Non-programming undergraduate students were placed into one of three groups. Each
group was then given a training session in one of the languages. Subjects were then
required to complete a series of similar tasks, using the language they had been taught.

The results showed that QBE required the least training time, had the largest proportion of
correct queries, required the smallest mean time per query, and subjects were more
confident in their answers.

From their research, Greenblatt & Waxman concluded that QBE was indeed superior in
learning and application ease to the other languages. Naive users came to grips with the
language very quickly, and the tabular organisation of QBE was an aid to query
formulation, confirming the results of earlier research.

35
Allen (1982), Shneiderman (1978), and Thomas (1983) give additional references to
empirical studies on database access languages.

36
CHAPTER 4 - Example Systems

4.1 Menus, Forms & Command Language

The database systems discussed in this section combine a number of interaction styles -
menus, forms, and command language. Some also use a WIMP interface extensively. They
are all based upon the relational model.

4.1.1 SQL-based Products

SQL is based upon IBMs DB2 mainframe product. It is a language used for the
manipulation of relational databases. A detailed description of SQL is beyond the scope of
this project, but since many vendors are supplying SQL-compatible products (e.g. Ingres,
Oracle), it is felt that some discussion is necessary.

Lewis (1988) states that,

“SQL has no provision for user interaction of any kind. In fact, the formal
definition of the language does not even state how the results of a query are
to be delivered to the user.”

Hayhurst (1988), however, states that SQL has an easy to learn, easy to remember syntax,
and can be used to provide virtually any kind of analysis of user data. Stobie (1988a) also
agrees that SQL has a simple command-driven user interface. This feature being quite
significant for micros, since a range of products are appearing which have adopted SQL as
their standard. One of the main reasons behind this being the increasing interest in micro/
mainframe connectivity, (Lang, 1988). Hammond (1988) also recognises this trend:

“The mainframes and minis can handle the heavy number-crunching and
storage, while the micros can serve as user-friendly front ends.”

Finkelstein & Pascal (1988) in reviewing a number of SQL DBMSs for PCs came to the
following conclusions.

37
4.1.1.1 Informix-SQL

Informix-SQL consists of three major components. Of interest is the interactive SQL

capability. This allows users to enter a query, store it, retrieve a previously stored query
and execute a query. A menu of options is displayed at the top of the screen which allows
users to perform a variety of operations such as switching databases and executing queries.
However, no screen painter is provided to enable customised screens to be created, though
a tool is available to allow the merging of Lotus 1-2-3 data with an Informix database.

4.1.1.2 Ingres for PCs

Ingres for PCs allows access to databases via command language statements or query-by-
example (a forms oriented facility, previously mentioned). Ingres 4GL is also available for
more sophisticated applications. This comes equipped with a screen painter that allows the
quick and easy development of screens. In addition, a facility is available to import data
held in dBase III files.

4.1.1.3 Oracle

Oracle offers a number of methods to interact with a database. SQL*Plus allows users to
enter, edit and save SQL queries. The data are displayed in multiple rows on the screen. A
useful tool for end-users is Easy*SQL - users are prompted with questions, and the SQL
commands are automatically created. This enables casual users to use Oracle, without the
necessity of learning SQL. It uses a mouse and pop-up menus. A query-by-example facility
(Oracle QMX), was also announced for release in 1988. This is similar to the IBM
mainframe product, QMF. SQL*Forms is described by Finkelstein & Pascal as a,

“non-procedural application development tool. It has a nice window

interface and also contains a screen painter for screen design ...”

SQL*Forms is used to design and modify form based applications which can then be used
by less experienced people to query the database, (Hammond, 1988). Also of interest is
SQL*Calc, a facility to access Lotus 1-2-3 worksheets.

4.1.1.4 XDB II

XDB II is a product which is described by Finkelstein & Pascal as distinguishable from its
competitors by its,

38
 “friendly end-user interface and application development tool set.”

This is a view shared by Lewis (1988). The package has a menu- driven front-end,
providing a range of facilities, such as form design, report creation, searching, etc. There is
also an interactive SQL option, which enables users to experiment with SQL commands.
The editor includes a split-screen help feature, offering detailed explanations of SQL
commands in the lower half of the screen. Lewis concludes that products such as Ingres,
Oracle and Informix,

“betray their mainframe origins, with user interfaces that are weak by PC
standards.”

XDB, however, he feels is a product that offers the ease of use that micro users have come
to expect.

4.1.1.5 dBase IV

dBase IV contains many improvements and enhancements over its predecessors. One of
these is a greatly improved user interface (called “The Control Centre”), which is menu-
driven, though it is still possible to use the familiar dot commands. In addition, SQL,
keyboard macros, and a query-by-example facility have been added. Many additional tools
have been provided to enable input and output screens to be customised, (Baran, 1988).

Kuhns (1988), comments on the combination of dBase IV commands, query-by-example

and SQL facilities, and suggests that these features enable the creation of ad hoc multi-file
reports - particularly important to business users. Kuhns adds that the need to hand-code
reports is virtually eliminated, and busy executives can quickly and easily extract,
consolidate and present information.

4.1.2 Other Products

This section examines a number of database packages that are relational in nature, but are
not based upon SQL.

4.1.2.1 Omnis Quartz

Omnis Quartz is a PC-based relational database that extensively uses the WIMP interface
offered by Microsoft Windows. Quartz applications can be customised according to user

39
requirements. Features such as pull-down menus, overlapping windows, scalable fonts,
scrollable lists, and dialogue boxes are available to the developer, (Cohen & Walker,
1987). The end-user is able to interact with the program using these features.

In comparing Quartz against dBase III, Walker, describes how an application took
approximately one week to develop into a semi-operational state using Quartz, and a similar
(though more complex) system took the equivalent of three months to develop using dBase
III. Walker attributes this twelve-fold increase in speed to the interactive nature of Quartz.

Walker recognises that large applications would be more difficult to maintain using Quartz
than dBase III, but Quartz applications would be more friendly.

Cohen & Walker conclude that a graphics environment may not be suitable for all data
applications. For large data-entry systems, users may not wish to use a WIMP interface, as
they would have to keep removing their hands from the keyboard to use the mouse.
However, Quartz offers a wide range of tools to enables the easy design of screens. Users
would also be prevented from making mistakes through the use of push-buttons and scroll
bars. Dubash (1988) also agrees that designing the user interface using Quartz tools, gives
end-users and non-specialists an easy path through complex applications.

4.1.2.2 dBase Mac

dBase Mac is a relational database system for the Apple Macintosh. It uses a graphical
display of each file and its fields to show the relationship between them, (Walker, 1988).
Figure 4.1 illustrates this. It is interesting to note how the relational structure is represented
as a network. This is described by Walker (1988) as being the most innovative feature of
dBase Mac. A data file relationship is represented by a line between the two files. This is
achieved by simply dragging a field from one file to the related field in the other file.
Double-headed arrows are used to indicate two-way relationships and single-headed arrows
for one-way relationships, (Walker, 1988).

Walker states that dBase Mac offers users the ability to specify most commands using pull-
down menus, or a vertical bar of icons (known as the “palette” - so familiar with many
Macintosh software packages). A great deal of customisation is possible without the
necessity of using a programming language. However, dBase Mac supports a full
programming language, useful for more complex applications. Walker describes the
programming language as the area where most advances have been made. A modular
approach has been used which enables users to quickly create advanced features such as
dialogue boxes and menus. Lewis (1987) in his review of dBase Mac agrees that one of the

40
strengths of the package is the ability to create turnkey systems, but concludes that it would
appeal more to application builders and power users.

PATRONS INVOICES INVENTORY

Last Name Date Title

First Name Date Due Category

... ... ...

... ... ...

... Patrons () Invoices ()

Invoices () Inventory ()

Figure 4.1 - The Relational Structure for this Database is Created by Dragging any one
Field Name to Another (Walker, 1988).

4.1.2.3 4th Dimension

Whitby (1987) and Shapiro (1987) note that 4th Dimension (for the Apple Macintosh) is
not itself a relational database, but it offers a range of tools to enable customised programs
for specific applications to be created. In particular, users can access features of the
Macintosh, such as dialogue boxes, windows, scroll bars, buttons, check boxes and pull-
down menus. These features can be combined to produce a database application similar to
off-the-shelf packages, (Whitby, 1987).

As with dBase Mac, 4th Dimension enables the database structure to be graphically
displayed. Lines are used to link the attributes of various files together to represent
relations. Also, a procedural programming language is available. This can be used via two
editors - text or visual. The visual editor uses flowchart symbols on the screen which users
can connect by dragging lines between them. Statements and conditions can be added to the
various symbols. The software will then automatically generate the program for the
application. Whitby states that the advantage of this approach is that the user can see at a
glance the logical program structure, though modification would be more difficult.

41
Spezzano (1988), in comparing 4th Dimension with another Macintosh database package
(Double Helix II, an icon driven system), concludes that 4th Dimension would be suitable
for full-time programmers by virtue of its traditional Pascal-like programming language.
Double Helix II, however, he feels would be suitable for small business owners,
managers, and professionals, who may not have the time or the inclination to learn a
programming language.

4.2 Natural Language

4.2.1 INTELLECT

An often quoted example of a successful NL front-end is Artificial Intelligence

Corporation’s INTELLECT system, which has now been available for over 6 years. At the
time of writing, Harris (1983) stated that over 100 copies were installed at many large
commercial organisations in the United States, (this figure was put at approximately 300
installations on large mainframe computers by Shneiderman, 1987). Many of these
organisations having up to 100 non-technical users of the system.

Harris gives six examples of user questions that INTELLECT would be able to
successfully process in many different wordings. These demonstrate the ability of the
system to correctly translate queries of considerable complexity. Harris also gives examples
to demonstrate the robustness of the INTELLECT syntax.

Shneiderman (1987:167) summarises the main innovative ideas that have helped to make
INTELLECT successful.

Firstly, the parser uses the contents of the database to parse queries. The program can also
handle ambiguous questions. For example, if the user asks, “How many bakers are in the
file?”, since “baker” can either be a surname or an occupation, the system will ask the user
to resolve the ambiguity. It would not, however, attempt to list all “bakeries” held in the
database.

Secondly, the system administrator can include guidance for handling domain-specific
requests, by indicating which fields are related for certain types of queries.

Lastly, INTELLECT rephrases the user’s query and displays a structured response, which
serves as an educational aid to users, who tend towards the same style after becoming more
experienced with the system.

42
Two other attributes of INTELLECT worth noting are firstly, its ability to handle a query
consisting of several sentences, and secondly, allowing pronoun reference to previous
questions. This latter point was discussed in Chapter 2. Harris states that the use of a
pronoun context enables INTELLECT’s understanding of the physical database to keep
pace with the user’s view of the logical database.

INTELLECT has also been integrated with graphics and statistical packages. Tabular
results can then be presented as pie charts or histograms, (Wallace, 1984).

Based upon user experience with INTELLECT, Harris feels that there is a future for NL
systems and that they could be used for many of the same applications non-procedural
programming languages are currently being used for. However, NL systems would not
replace formal languages, since some tasks, such as high volume data input would continue
to be the domain of formal languages.

4.2.2 RENDEZVOUS

RENDEZVOUS version 1 was an experimental system, intended to provide an NL front-

end for RDBMSs. Codd (1978) in describing the system, stated that,

“It differs markedly from other natural language query systems in the extent
to which it talks back to the user about his query before any data base
retrieval is executed.”

In describing NL interfaces, Codd feels that a system that consists of a natural language
analyser (translates NL input into a formal query language) and retriever (interprets the
formal query language and retrieves the data) would not be viable for most users. What is
required in addition to these components is a generator that enables the system to “talk
back” to the user. RENDEZVOUS consists of these three major components and can
communicate with users in a variety of dialogues.

RENDEZVOUS uses a formatted screen display consisting of four “viewports” - query,

history, input, and message (see also Figure 4.2).

The query viewport is essentially used to communicate the current state of the user’s query,
including any amendments that have been made either by the user or the system.

43
 Query Viewport

History Viewport

Input Viewport

Message Viewport

Figure 4.2 - The Four Viewports in RENDEZVOUS (Codd, 1978).

The history viewport can be scrolled forwards or backwards, and contains all the
interactions with the system for the current session.

User input is received by the input viewport. The message viewport is used by the system
to place appropriate messages.

As with INTELLECT, RENDEZVOUS will accept queries consisting of more than one
sentence. However, RENDEZVOUS version 1 does not support pronoun reference. It can,
however, resolve ambiguities and offer the user several possible interpretations of its
understanding of the user’s intent.

If the user inputs an incomplete and/or erroneous query, the system will attempt to resolve
it step-by-step so that a correct and error-free query is produced. Codd describes this as
incremental query formulation, which he feels is essential to successfully support casual
users.

44
Codd (1978) gives a series of examples (actual interaction transcripts), to demonstrate the
dialogue possible with RENDEZVOUS.

4.3 Direct Manipulation

4.3.1 Query-by-Example

Query-by-Example (QBE) was devised by Moshe M. Zloof in 1977, while working for
IBM. It was originally designed to act as a front-end for SQL, and was shown to be much
easier to use than SQL, setting a new standard for end-user interfaces, (Kuhns, 1988).

QBE is described by McFadden & Hoffer (1985) as an example of a “graphic relational

DBMS”, though it cannot represent pictorial data. A skeleton of a relational table is drawn
on the terminal screen (see Figure 4.3). Moving a cursor through the columns of the
skeleton table, the user enters examples of how the result should appear. To supplement
this direct manipulation style, QBE also uses some single letter keywords (e.g. P. for
“Print”).

It is the direct representation of relations on the screen which Shneiderman (1983) attributes
as one of the major reasons for the success and appeal of QBE to data manipulation.
Although some syntactic knowledge is required to perform Boolean or mathematical
operations, Shneiderman states that,

“the basic ideas and language facilities can be learned within a half hour by
many nonprogrammers.”

This is a view shared by Martin (1981), who claims that using QBE, he explained the basic
concepts of a database to a secretary, who had never touched a terminal or computer
before. Within half an hour, she was using the language and manipulating data.
Furthermore, Martin (1981:86) feels that QBE,

“demonstrates the simplicity that is needed for widespread end-user

communication.”

Martin (1981:94) also states that,

45
 “The language is designed with the excellent principle that the thinking
process the user follows is that which he would use to find the same
information without a computer.”

The table name Field names

goes here. go here.

Field values
go here.

Figure 4.3 - QBE Skeleton Table (Martin, 1981).

Evidence to support these statements comes from Greenblatt & Waxman (1978), as
discussed in Chapter 3.

It would appear then that QBE offers all the advantages of a powerful database language
that is capable of being used by a wide range of end-users.

Examples of QBE queries can be found in Zloof (1978 & 1983) and Martin (1981 &
1982).

46
4.3.2 Spatial Data Management

The Spatial Data Management System (SDMS) is a unique DBMS that extensively uses the
principles of direct manipulation (e.g. joystick, multiple touch-sensitive screens, etc.). It
displays data as icons (together with associated numerical and text data) within a spatial
context or Graphical Data Space (GDS).

Herot (1980) describes the development of SDMS as being motivated by the growth of
users who are not trained in the use of DBMSs. In contrast to conventional DBMSs where
information retrieval must be made using a formal query language, in SDMS the
information is more accessible as users seem to need less prior knowledge of the contents
or organisation of the database.

The database is viewed through several colour VDU screens. One screen presents a
“world-view” of the entire data surface (the GDS). A second screen shows a magnified part
of the GDS in which the user is currently searching. This magnified view is also indicated
by a highlighted rectangle in the “world view” screen (see Figure 4.4). The enlarged view
is therefore like a “window” onto the database which can be moved around using a
joystick.

In comparison to keyboard-oriented DBMSs (including NL interfaces), SDMS offers the

following advantages (Herot, 1980:502; McFadden & Hoffer, 1985:521).

Firstly, motion through the database is simple and natural. In contrast to conventional
query languages which require syntactic and semantic knowledge, in SDMS the user has
just one control - a joystick. This can be used to explore the entire database. The joystick
can also be used to control the level of abstraction. For example, by twisting a knob, an
icon can be magnified to reveal more detail.

Secondly, the database is its own data dictionary. It is not necessary to specify a relation or
attribute name, since the user simply moves across the GDS until the required information
is in view. This contrasts with a conventional DBMS that requires the use of a data
dictionary to specify the structure of the database.

Thirdly, browsing is encouraged. The user is visually stimulated to ask questions about the
relationship of objects that look alike or are physically close to one another. In a
conventional DBMS, however, every piece of data must be explicitly requested.

47
Fourthly, position conveys information. The physical, relative placement of icons can be
used to convey information. Relative sizes or distances not only indicate relationships but
also allow visual comparisons of such values.

Fifthly, graphic representations. When appropriately applied, graphic representations can

be vivid and clear. Use of colours can supplant numerical classifications.

Lastly, unique data types. Illustrations and pictures stored on videodisks or other media can
be incorporated into the database.

Window
VDU 1 - WORLD VIEW

Graphical Data Space

VDU 2 - MAGNIFIED VIEW (GDS)

Figure 4.4 - World View and Magnified View of SDMS.

Herot (1980) gives a detailed example of the use of SDMS as an interface to a symbolic
DBMS. He also discusses other sources of data such as an optical videodisk.

48
4.3.3 Dataland

Dataland was a project that was started in the 1970s at the Massachusetts Institute of
Technology (MIT), with funding from the United States Department of Defence. In many
respects, it is similar to SDMS, since users travel through a “data space”.

Dataland consists of a command chair which supports a variety of input devices such as a
joystick, touch-sensitive pad and remote-controlled pointer. On either side of the chair are
VDUs which have touch-sensitive screens. There is also a giant colour wall screen in front
of the chair.

On the right-hand VDU screen is a permanent map of Dataland. There are icons to represent
various functions, such as a calculator. The joystick is used to move the cursor (which acts
as a “window”) over the map. An enlarged view of the window appears on the left-hand
screen (similar to SDMS). Since the screens are touch-sensitive, it is possible, for example,
to touch the keys of the calculator, which responds as though it were real. The system also
supports octophonic sound, so objects such as a telephone can actually be heard ringing.

Perhaps the most dramatic feature of this database retrieval system is its capability to zoom
in on objects. For example, starting with a satellite view of the United States, it is possible
to zoom down through Massachusetts to a map of Cambridge. Then zoom into the MIT
campus, then onto a floor plan for a particular building, and then into a particular office.
The information held by the system is constantly updated, so that, for example, when
flying through Cambridge, the sights and sounds will be an accurate representation.

Although Dataland and SDMS are experimental systems, they show that there are
alternatives to the hierarchical, network and relational models for viewing data, and that a
rich user interface can be developed. Thomas (1983) adds that such interfaces have intrinsic
reinforcing properties, and concludes that they provide a coherent model to the user thus
making learning and using easier.

49
CHAPTER 5 - Summary

5.1 Summary

It has been shown how DBMSs have evolved from offline batch oriented systems to online
interactive systems. The growth of microcomputers having had a significant impact upon
this process, with database designers increasingly providing better mechanisms for user-
system interaction.

Various techniques were presented to enable users to be classified, e.g. syntactic/semantic

knowledge, usage mode and dialogue style. It was noted that different users required
different forms of interaction. For novice users, it was suggested that menus and prompts
would be suitable, whereas for more experienced users, a command language would be
more appropriate.

It was suggested that there were five major interaction styles available for database interface
design - menu selection, form fill-in, command language, natural language and direct
manipulation. The strengths and weaknesses of each technique and its suitability were also
discussed.

References were given to empirical studies that had been undertaken to compare various
interaction styles. It was shown how a number of variables could be used to determine
which was most “user friendly”. The results showed that languages such as Query-by-
Example were found to be easier to learn and to use by many users. There was also little
evidence to support the theory that a natural language interface for database systems would
offer significant advantages over other techniques.

Some example database systems (for microcomputers and mainframes) were also given for
a number of interaction styles.

5.2 Future Developments

Everest (1986:732) states,

50
 “The future of database management is bright. Forecasters anticipate a $1
billion industry by 1990. Recent trends in DBMS, particularly on
microcomputers, promise to better serve users with greater functionality,
and a simpler, higher-level interface.”

Everest (1986:734) feels that the following factors are contributing to the trend towards a
simpler higher-level interface for database systems.

Firstly, logical view of the data without concern for physical representation and access
mechanisms.

Secondly, user schema through which the users can view parts of the database of interest to
them without having to comprehend the whole.

Thirdly, online interface for ad hoc, interactive use by novice users, both command driven
and menu driven, and incorporating the principles of direct manipulation.

Lastly, high-level languages available to both the online user and the programming user,
including the new developments in inferential retrieval, artificial intelligence, and natural
language processing.

Stobie (1988b) also feels that more advanced database user interfaces will be found on
microcomputers. In the short-term, he feels that it may still be a command oriented or
forms-based interface, but the next step may be towards hypertext systems (e.g.
Hypercard, Guide) currently available for the Apple Macintosh. Such interfaces would
provide links to company-wide database systems. Natural language systems (e.g. Q&A)
could also prove to be attractive. Full-speech interaction, however, is something which
may be several decades away.

Direct manipulation systems like SDMS and Dataland, although experimental, have shown
how users may interact with a DBMS without the need to learn any query language syntax.
Although such systems are expensive and have been rarely applied (McFadden & Hoffer,
1985:522), they do illustrate what is possible with existing technology. Advances (e.g. in
computer graphics) may make them more attractive in the future.

For natural language interfaces, Wallace (1984) suggests five possible areas for future
development.

51
Firstly, metaquestions. This would enable users to ask not only about data in the database,
but also about what the database contains. Wallace (1984:124) gives the following example
to demonstrate this.

Q “What is there on employees?” <Metaquestion>

A “Personnel no., date of birth, date of joining, grade, salary, department”

Q “What is there in bin 01?” <Data question>

A “Pencils and pens”

Wallace suggests that one approach to this would be to use a graphical representation of the
database (rather like the graphical data space of SDMS), so that users can see what is
available, before posing questions.

Secondly, vertical natural language systems. Rather than designing an NL front-end to be

transported between applications, a vertical system would be designed for a specific
application. Such a system would comprise of the NL interface and the database. Wallace
states, however, that for some applications, vertical systems may be hard to design.

Thirdly, database updates. Current systems are aimed at database enquiry. Database update
may pose considerable integrity problems which would need to be resolved via dialogue
with the user, to establish the correct intent.

Fourthly, learning new language words and expressions. The end-user can define his own
synonyms. Problems may arise, however, where two different users try to define the same
synonym to mean two different things, e.g. does “pr” mean “product” or “printer”?

Lastly, major extensions. Under this category, Wallace discusses several issues, such as
existential and universal quantification (e.g. SOME, ALL or NOT in logic), achieving a
conversational goal (which Codd (1978) describes as “talking back” to the user), and
connecting an NL font-end to other software to improve user-system interaction, (e.g. the
integration of INTELLECT with graphics packages).

5.3 Conclusions

User interface design is a very complex subject. Many authors have attempted to determine
those factors which produce a user interface that is functional and easy to use - only the
views of some of them have been presented here. Most agree that a great deal more work is

52
necessary. This involves careful analysis of user tasks and functions, as well as conducting
empirical testing.

For database systems, the user interface has evolved considerably, in line with software
design in general. Many of the developments have resulted from the growth in personal
computers. All classes of users have access to a wide range of software, including
databases. Software developers are increasingly providing facilities that enable end-users to
develop their own customised applications. It seems likely that the PC will be the focus of a
great deal of work on user interface design. There are a number of trends which seem to be
developing.

Firstly, many PC-based database systems are offering the kind of functionality previously
only available on minicomputers. dBase IV being a good example, which supports a query-
by-example facility previously seen only on large database systems. Users are offered a
range of interaction styles. On the one hand, programmers can use command languages to
develop turnkey systems, which utilise windows, icons, pull-down menus, etc. On the
other hand, novice users can interact directly using WIMP interfaces. They are also
provided with tutorials and encouraged to experiment.

Secondly, the increasing interest in micro/mainframe connectivity should provide better

user interfaces, since the PC can undertake some local processing, and hence handle its
own screen display. With the advent of Hypertext systems (e.g. for the Apple Macintosh),
the PC can be used as a means to access large company-wide database systems, yet retain
its own user interface.

Natural language systems also promise a great deal. If the size and complexity of the
software can be overcome, then off-the-shelf packages may become more readily available.
One good example is Q&A which is an integrated database and word processor. Through
the use of an “Intelligent Assistant”, the database can be taught details about an application.
In use, the system proved to be very popular with end-users who were too busy to learn
database query language syntax.

53
APPENDIX 1 - Summary of Interaction Styles

ADVANTAGES DISADVANTAGES

Menu Selection
- Shortens learning. - Danger of many menus
- Reduces keystrokes. may slow frequent
- Structures decision-making. users.
- Permits use of dialogue - Consumes screen space.
management tools. - Requires rapid display
- Easy to support error rate.
handling.

Form Fill-In
- Simplifies data entry. - Consumes screen space.
- Requires modest training.
- Assistance is convenient.
- Permits use of form
management tools.

Command Language
- Flexibility. - Poor error handling.
- Appeals to “power” users. - Requires substantial
- Supports user initiative. training and
- Convenient for creating memorisation.
user defined macros.

Natural Language
- Relieves burden of learning - Requires clarification
syntax. dialogue.
- May require more
keystrokes.
- May not show context.
- Unpredictable.

Direct Manipulation
- Visually presents task - May be hard to program.
concepts. - May require graphics
- Easy to learn. display and pointing
- Easy to retain. devices.
- Errors can be avoided.
- Encourages exploration.
- High subjective satisfaction.

(Source: Shneiderman (1987))

54
APPENDIX 2 - Personal Evaluation

Being interested in database systems, and having some slight experience in developing a
number of small applications in the past, it was very interesting to undertake a research
rather than practical project.

The main criticisms which I would raise would be that the project tried to cover too broad a
subject area. Consequently, a number of sections were not covered in sufficient detail.
Empirical Testing (Chapter 3) is the best example of this. Possibly, this area could have
been ignored in favour of greater analysis elsewhere. Also, some of the areas that I wished
to cover, such as object-oriented database systems, were not even mentioned. The problem
was not one of having insufficient material, but rather the opposite. A great deal has been
written about user interface design. Specific material relating to database systems was
initially difficult to find, but fortunately, the publications by Ben Shneiderman and Gordon
Everest provided suitable material, in addition to many useful references.

Also, for Chapter 4, many of the database systems were relational in nature. Not having
sufficient time and resources to review any database systems myself, I relied on articles in
the popular computer press. The original project proposal called for an examination of both
network and relational systems. However, I found that all recent articles referred only to
relational systems. Consequently, the imbalance.

Given sufficient time and resources, I would like to undertake a more detailed evaluation
and analysis of some database packages.

Overall, I feel that I have benefited considerably from undertaking this project, as it has
given me an insight into an area often neglected by software developers. Hopefully, the
work will be of use to me in the future.

55
Bibliography

ALLEN, R.B. (1982) Cognitive factors in human interaction with computers. In:
Directions in human-computer interaction, edited by A. Badre & B. Shneiderman
(Norwood, New Jersey: Ablex Publishing Corporation)

BARAN, N. (1988) dBase IV: a paradox killer? BYTE. 13 (4):113-114.

BRITISH COMPUTER SOCIETY (1981) Query languages: a unified approach.

Monograph in Informatics, edited by P.A. Samet (London/Philadelphia: Heyden &
Son)

CARD, S.K., MORAN, T.P. & NEWELL, A. (1983) The psychology of human-
computer interaction (London/Hillsdale, New Jersey: Lawrence Erlbaum
Associates)

CODD, E.F. (1974) Seven steps to rendezvous with the casual user. In: Data Base
Management, edited by J.W. Klimbie & K.L. Koffeman (Amsterdam: North-
Holland)

CODD, E.F. (1978) How about recently? (English dialog with relational data bases using
Rendezvous version 1). In: Databases: Improving Usability and Responsiveness,
edited by B. Shneiderman (London/New York: Academic Press)

COHEN, D. & WALKER, N. (1987) Omnis Quartz. Personal Computer World. 10

(9):136-140.

COMPUTER NEWS (1984) All you ever wanted to know about database systems: 4, IBM
database file handlers. 2 February 1984 (No. 12), pp. 12-17.

DUBASH, M. (1988) Omnis Quartz windows database. Practical Computing: For

Business And Professional Micro Users. 11 (2):36-38.

ESPRIT (1985) Human factors of the user-system interface: a report on an ESPRIT

preparatory study, edited by B. Christie (Amsterdam: North-Holland)

EVEREST, G.C. (1986) Database management: objectives, system functions, and

administration (New York: McGraw-Hill)

FINKELSTEIN, R. & PASCAL, F. (1988) SQL database management systems. BYTE.

13 (1):111-118.

GREENBLATT, D. & WAXMAN, J. (1978) A study of three database query languages.

In: Databases: Improving Usability and Responsiveness, edited by B. Shneiderman
(London/New York: Academic Press)

HAMMOND, C. (1988) The glorious SQL. Practical Computing: For Corporate Decision
Makers. 11 (5):64-66.

56
HARRIS, L.R. (1983) The advantages of natural language programming. In: Designing
for Human-Computer Communication, edited by M.E. Sime & M.J. Coombs
(London: Academic Press)

HAUPTMANN, A.G. & GREEN, B.F. (1983) A comparison of command, menu-

selection and natural-language computer programs. Behaviour and Information
Technology. 2 (2):163-178.

HAYHURST, M. (1988) Bringing SQL to the masses. PC User. 8-21 June 1988 (No.
82), pp. 42-43.

HEROT, C.F. (1980) Spatial management of data. ACM Transactions on Database

Systems. 5 (4):493-514.

HILL, I.D. (1983) Natural language versus computer language. In: Designing for Human-
Computer Communication, edited by M.E. Sime & M.J. Coombs (London:
Academic Press)

IRBY, C. and others (1977) A methodology for user interface design. Systems
Development Division, Xerox Corporation, January 1977.

KUHNS, R. (1988) dBase IV: following the SQL path. PC User. 8-21 June 1988 (No.
82), pp. 38-44.

LANG, K. (1988) Serving the system. Personal Computer World. 11 (5):156-158.

LEWIS, M. (1987) dBase Mac & McMax. Practical Computing: For Business And
Professional Micro Users. 10 (12):44-46.

LEWIS, M. (1988) A gateway into SQL. Practical Computing: For Corporate Decision
Makers. 11 (6):45-48.

MARTIN, J. (1981) An end-user’s guide to data base (Englewood Cliffs: Prentice-Hall)

MARTIN, J. (1982) Application development without programmers (Englewood Cliffs:

Prentice-Hall)

McFADDEN, F.R. & HOFFER, J.A. (1985) Data base management (Menlo Park,
California: Benjamin/Cummings)

MOODY, G. (1987) Windows on to your programs. Practical Computing: For Business

And Professional Micro Users. 10 (3):80-81.

OGDEN, W.C. & BOYLE, J.M. (1982) Evaluating human-computer dialog styles:
command vs. form/fill-in for report modification. In: Proceedings of the 26th
Annual Meeting of the Human Factors Society, Santa Monica, California, 1982 pp.
542-545.

RELATIONAL TECHNOLOGY INCORPORATED (1987) The guide to better database

management (London: RTI)

SCHNEIDER, M.L. (1982) Models for the design of static software user assistance. In:
Directions in human-computer interaction, edited by A. Badre & B. Shneiderman
(Norwood, New Jersey: Ablex Publishing Corporation)

SHAPIRO, E. (1987) Into the 4th Dimension, part 1. BYTE. 12 (11):269-272.

57
SHNEIDERMAN, B. (1978) Improving the human factors aspect of database interactions.
ACM Transactions on Database Systems. 3 (4):417-439.

SHNEIDERMAN, B. (1981) A note on human factors issues of natural language

interaction with database systems. Information Systems. 6 (2):125-129.

SHNEIDERMAN, B. (1983) Direct manipulation: a step beyond programming languages.

IEEE Computer. 16 (8):57-69.

SHNEIDERMAN, B. (1987) Designing the user interface: strategies for effective human-
computer interaction (Reading, Massachusetts: Addison-Wesley)

SIMPSON, H. (1986) Programming the IBM PC user interface (New York: McGraw-Hill)

SMALL, D.W. & WELDON, L.J. (1983) An experimental comparison of natural and
structured query languages. Human Factors. 25 (3):253-263.

SMITH, D.C. and others (1982) Designing the Star user interface. BYTE. 7 (4):242-282.

SPEZZANO, C. (1988) Two mac databases go toe-to-toe. BYTE. 13 (6):159-162.

STOBIE, I. (1988a) The key to company-wide computing. Practical Computing: For

Business And Professional Micro Users. 11 (3):60-62.

STOBIE, I. (1988b) Coming soon. Practical Computing: For Business And Professional
Micro Users. 11 (3):75-77.

THOMAS, J.C. (1983) Psychological issues in the design of database query languages. In:
Designing for Human-Computer Communication, edited by M.E. Sime & M.J.
Coombs (London: Academic Press)

WALKER, N. (1988) dBase Mac. Personal Computer World. 11 (1):122-126.

WALLACE, M. (1984) Communicating with databases in natural language (Chichester:

Ellis Horwood)

WASSERMAN, A.I. (1985) Extending state transition diagrams for the specification of
human-computer interaction. IEEE Transactions on Software Engineering. SE-11
(8):699-713.

WHICH COMPUTER? (1987) Easy to use databases. November 1987, p. 69.

WHITBY, M. (1987) 4th Dimension. MacUser. September 1987 (No. 15), pp. 27-31.

ZLOOF, M.M. (1978) Design aspects of the Query-by-Example data base management
language. In: Databases: Improving Usability and Responsiveness, edited by B.
Shneiderman (London/New York: Academic Press)

ZLOOF, M.M. (1983) The Query-by-Example concept for user-oriented business systems.
In: Designing for Human-Computer Communication, edited by M.E. Sime & M.J.
Coombs (London: Academic Press)

58