3-3 Screen display due to the active list with the value: { t\A~lE ADDRESS ..... the passive list which reflects the constant state of the CRT display. (also called the ...
CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
A MODEL FOR THE DESIGN OF DYNAMIC INTERACTIVE SYSTEHS A thesis submitted in partial satisfaction of the requirements for the degree of ~~ster of Science in Conputer Science
by Steven Doup,las Cochran
June, 1980
The Thesis of Steven Douglas Cochran is approved:
~C.
Prahhakar
John M. Motil
Russell J. Abbott
California State University, Northridge
ACKNOh'LEDGEHENTS
I would like to express my th'lnks and appreciation to my nasters committee consisting of Dr. Jagdish Prabhak;u, Prof. John
~1otil,
and
especially Dr. Russell Abbott for their guidance and suggestions concerning this thesis.
I would also like to express my gmtitude to my parents
E,.~rl
and
Dorothy who were an enduring source of support, encouragement, and understanding throughout; and to Richard Knox for the use of KNOX DATA's TANDF:H-16 computer, without which the implement-'ltion of a working model would have taken much, much longer.
Fimlly, I would like to thank Darel Roberts for the use of his
Spintronic~
terminal to type this thesis.
iii
CONTENTS Ackno~ledgements
•••••••••••••••••••••••••••••••••••••••••• iii
List of Figures •••••••••••••••••••••••••••••••••••••••••••• vi Abstract •••••••••••••••••••••••••••••••••••••••••••••••••• vii
................................................ 1
l INTRODUCTIO!\ l.l Contr::tst to Earlier SysteMs •••••••••••••••••••••••••••••• 1.2 The Fund"'.nental Unit of Infor!Wltion •••••••••••••••••••••• 1•3 Defined Features •••••••••••••••••••••••••••••••••••••••••
1.4 1.5 1.6 2
1
2 2 3 Importance for Distributed Conputinp, ••••••••••••••••••••• Early Definition of the Interface •••••••••••••••••••••••• 3 Overview of the Thesis ••••••••••••••••••••••••••••••••••• 5
THE
PROBLD~
OF P1TERFACE DESIG:t\
6
•..•.••.••••.•.••••••.••.•.•••••••• 7 •••••••••••••••••••••• 8 Da ta Ac c u r.q c y •••••••••••••••••••••••••••••••••••••••••••• 9 Selected Go-:1ls and Techniques 10
2 .1
Gn'lls for
2.2 2.3 2.4
Techniques of Dialogue Construction
3
Good. Design
........................... 3 TilE lJYNA."-!IC .............................. 3 .1 IT£1-Is: Detailed description 3.2 Display: The passive list ............................... INTERACTim~ ~10DEL
3.3 3.4 3.5 3.6
13 15 19 Acquisition: The active list •••••••••••••••••••••••••••• 21 Acquisition: Edit function keys ••••••••••••••••••••••••• 21
Change: Pre-assigned function keys •••••••••••••••••••••• 25 Chanp,e: Programmer defined function keys •••••••••••••••• 27 The DI~·1 ~lonitor 27 28 Flexibility of Use 32 ITE:t-1 Lists Assignment of Screen Location 35 ITEH code statements 36
....................................... ...................................... .............................................. 3.10 ........................... 3.11 .................................... 4 A DH1 U!PLE1'1ENTATION ....................................... 41 4.1 Dialogue PrograM ................................. 41 4.2 Step-by-Step W3lk-through ............................... 45 Implementation via Translator Writinr, System ............ so 4.3 IDL Syntax .............................................. 53 4.4 4.5 Elements of ITEM structure .............................. 55 ITEH Value Types ........................................ 57 4.6 3. 7
3.8 3.9
Sar.~ple
4.7
5 6
............... 58 .................................................... TOPICS FOR FURTHER RESEARCH AND DEVELOPHENT ................ 61 IDL Additions to the ITD1 Co:le Statements
SU~IAP.Y
59
iv
Biblor,ra phy
................................................ 65
APPET\DICES A
....................................... 69 Structure Definitions ....................... 84
IDL Definition IDL DA. ta
c
Format Definitions ••••••••••••••••••••••••••••••••••• General Value Formats ••••••••••••••••••••••••••••• C.2 Date Formats c.3 Tine Formats C.l
......................................
v
90 90 91 92
LIST OF FIGURES
1-1 Division of Interface and Servers for efficient oper~tion
••••••••••••••••••••• 4
in a distributed environment
3-1 The Nonitor environment
••••••••••••••••••••••••••••••••••• 14
3-2 Screen display due to the pa.ssive list with the value: {
t\A~1E
AD"!)RESS PHON[ }
•••••••••••••••••••••••••••••••••••• 20
3-3 Screen display due to the active list with the value: { t\A~lE ADDRESS PHO~E } when the current-active-item is: PllO?'JE ••••••••••••••••••••••••••••••••••••••••••••••••• 22
3-4 Effect of the Repetitive entry of the
t
an(l
t
3-5 Screen display due to the active and p.:1ssive lists 3-6 Structure of the list { A B { CD} E }
•••••• 26
keys
•••••••• 31
••••••••••••••••••• 33
3-7 Locations and Values assigned to the list nodes after the entry of the field shown in Figure 3-5, but prior to the update of the passive list
••••••••••••••••••••••••• 34
3-R Locations assigned to the list nodes for the active list { A B l3,33] C n } where the prior active list CI Yw-~ s a t l 3 , 1 3 ] •••••••••••••••••••• .- • • • • • • • • • • • • • • • • • • • • • • 37
4-i
Relev::~.nt
components of the interface run-time system following the selection of option 1 in program SA'lPLE
••••• 47
4-2 Relevant components of the interface run-time system following the return to OPTION in program SANPLE
•••••••••• 48
4-3 Relevant components of the interface run-time system prior to the entry of N10llt\T in program SAMPLE
•••••••••••• 51
4-4 Schematic of the Transl:ttor Hriting System used to generate IDL •••••••••••••••••••••••••••••••••••••••••••••• 52
6-1 TAL structure definition of a 'PANEL' element
vi
••••••••••••• 62
ABSTRACT
A MODEL FOR THE DESIGN OF DYNMHC INTERACTIVE SYSTENS by Steven Douglas Cochran Master of Science in Computer Science
The need for a man-machine interface design system that will allow for the design of 'dynamic' interfaces is explored.
The
cha.racteristics of a good man-machine interface are discussed and a model is presented which provides for a new, dynamic, data-directed approach to interface design in which each data item is totally defined and the display is directed by the contents of an ACTIVE and a PASSIVE list of it ems.
Next an implementation of a language IDL, based on this interface model, is discussed and examples which show various aspects of its use are given.
Finally several ideas for extension to the interface model and the language IDL are presented, as well as suggestions for further research.
vii
Section 1:
INTRODUCTION
" ••• continued adva nee in prograt!lming will require the continuing invention, elaboration, and cot!lmunication of new paradigt!ls." Robert Floyd [Flo79]
This report describes a model for a dynamic and interactive man-rnachi~e
interface.
This interface model is designed to look to the
operator like a very nice, informative, helpful applications function; and to the actual Server Processes like an experienced operator who makes no mistakes.
In addition this interface must be definable by the
applications programmer in a manner which is mtural to use, understand, and modify.
The typical user environment for which the model is intended is
th~t
of
Transaction Processing (e.g. Order Entry, Hotel Reservations, Inventory, etc. ) built a bout a standard 24x80 cha ra ct er CRT.
1.1 Contrast to Earlier Systems Most current systems for the design of man-machine interfaces (or front-end systems) rely on relatively static Panels or Frames which are successively displayed.
These Frames may range in size from a
1
2
single letter to the entire screen.
It is the succession of these
Frames which provide the 'dyn:tmic' nature of the display.
The l'lodel
proposed here is more dynamic because:
1)
The unit quantity of the system--the ITEM--is more elementary;
2)
The 'Frames' are not grouped together at compile time but are built when required--giving more freedom for response;
3)
A number of applications programmer definable function keys are specified (whose values m~y change during run time). These keys give the operator control tailored to the immediate situation;
4)
The l:asic approach is based on the run-time assignment of display lists rather than a series of overlapping Frames.
1.2 The Fundamental Unit of Information The furrlamental unit in this Dynamic Interaction Model (DIH) is the ITEM.
This is a collection of almost everything about a single
data field: its default value, current value, heading or caption, input and output formats; as well as where on the screen it should be placed. 'Help' information and two executable code blocks are also included as part of an ITEM, which allow it to affect the current environment.
1.3 Defined Features The other important feature of DIM is that standard elements of an interface are automated, with overrides for the applications programmer.
*
These standardized elements include:
Error detection and interactive error correction;
3
*
Help information a bout each ITEM;
*
Automatic use of correct terminal characteristics;
*
Data mapping (both conversion and formatting).
The process of designing an interface becomes not building up from scratch but adding to and changing an already stable interface.
This
saves time, is less boring (making the job more interesting), and leaves time for the development of a better integrated and human-engineered interface.
1.4 Importance for Distributed Computing There is also a secondary importance to a front-end system because it defines the man-machine interface separately from the application server processes.
This provides the logical breakpoint for
the efficient use of a distributed computer architecture (see Figure 1-1).
Since local error checking may be done for.most types of errors,
the only information that need be sent between CPUs is:
* *
The initial down loading of an interface definition; Field information to be placed, possibly transformed, onto the screen or possibly to control the interface;
*
Special validation requests which must interrogate the data base;
*
The verified operator inputs being sent to the applications server.
1.5 Early Definition of the Interface Another important use that a front-end system such as DIM may
4
CENTP.AL CPU
LOCAL CPU
Interface Definition
coi!li!lunca t ions line
Fig. 1-1. Division of Interface and Servers for efficient operation in a distributed environment.
5
be put to is the definition of a system front-end even before the application Server Processes are written!
This feature could be used
to allow the user more interaction early on in the design process, as well as provide early inforrntion about necessary elements and keys in the d'ltalnse.
1.6 Overview of Thesis The next three sections show the various aspects of this dynamic interface model.
Section two deals with the various problems
encountered and some of the techniques found useful when designing the CRT dialogue.
From the set of posed problems, techniques, and goals
presented, a subset is selected which will present a msis for DIH.
Section three expands this model, detailing "rhat DHI will do automa.tic'illy, what may be selected or overridden by the applications programmer, and the manner in which the operator may enter data or control information.
In this section the abstract intern'll structures
are also defined and examples given to show the mapping of the internal state of the model to the CRT display.
The fourth section presents a complete example program.
Then a
step-by-step walk-through is conducted to show the general flow of a dialogue.
The implementation of a language, based on DIM and called
Interface Definition Language or IDL is next detailed; and the syntax of IDL is shown and explained. semantic listing of IDL.)
(See Appendix A for the full syntllen null is defined which allows the function key to be umssirned.
DISPLAY
This statement checks to see if the ITEM is displayed and if the display value is correct.
DISPLAY causes a physical display to be made only if necessary.
U:IT
causes an ITEH or list of ITEHs to be initialized to either a default for that data
type or to some value assigned to that ITEM by the applications progra m~er.
BUILD RECORD
takes a ITE!-1 list ani builds a record by conc:=ttinating together a copy of the value
field of ea.ch ITD!.
This procedure m-'ly cause an error if there is a
required ITE!-1 (i.e. its requirerl flag has been set) but a value has not been entered by the operator for that ITEH.
Control is transfered to
as described in section 3.1 to the active task executing when the function key was used.
"***
REQUIRED ITEH NOT SET:
active := { NA!'ffi .ADDRESS PHONE OPTION assign FUNC~ 1 to f1 uhen 2 => active := { NAr-!E M-lOUNT OP'I'ION } assign FUNC2 to fl when 3 =) active := { ADDP.ESS AHOUNT OPTIOtl } assign FUNC~3 to f1 when other =) error "**t' VALUE OUT OF RAHGE 1 •• 3" end case end active task end iten --OPTIO!'l-when 1
iten NAHE heading [ +1 ,5 ] "NA""ffi :" in out format "A20" field length 20 value-[ +1,11 ] string( 20 ) allow edit required end it em --NAHE-list .ADDRESS :=
AnDRESS1 ADDRESS2 ADDRESS3 }
item ADDRESS1 heading [ +1,2 ] "ADDRESS:" value [ +1,11 ] string( 30 ) :11low edit required in out format "A30" field length 30 help Ti Nunber end item --ADDRESS1-iten ADDRESS2 heading l +1,9 ] ":" value [ +1,11] string( 30) allow edit required in out form t "A30" field length 30 help " City end item --ADDRESS2--
Street Name"
State
Zip Code"
item ADDRESS3 heading [ +1,9] ":" value [ +1 ,11 ] strinE( 30 ) allow edit in out format "A30" - field length 30 help 11This is an optional third address line." end item --.ADDRESS3--
44
item PHO~E headinr; [ +1,4 ) "PHO~E:" value [ +1,11) string( 10) required help "The phone number forl'l!it is ZZZ9999999" in form'lt "A10" out format "~!,
(RANGE) ::= (OBJECT) (OBJECT)
$ $ (ITEH BODY) enditem IF IDBISVLOC AND NOT IDBFLDLEN THEN IDBISVLOC := FALSE; @TOKEN"'PTRl := RHS2.PLACE; TOKEN"'PTRl. TYPE : = ITEH'"TYPE; TOKEN.PTRl.VALUE := ITEM"'NUMBER; CALL ADD"'LIST( ITEMLIST, @TOKEN"'PTRl, ITEf-1LIST. VALUE+! ) ; IF !-fAP .(8) THEN CALL ADD-LIST( MAINLIST, @TOKEWPTRl, MAI~~IST.VALUE + TOKEN"'PTRl.LENGTH + 2 ); !NCR( ITE:t-1"'NUHBER ) ; l-1AP := NUL;
72
$ IF }MP. THEN CALL PRINT"MESSAGE( EM"DOUBLE"DEFAULT ); @TOKEN"PTRl := RHS2.PLACE; IF NOT TOKEN"PTRl.VALUE THEN BEGIN !ASSIGN SLOT IN TEXT TABLE TOKEN"PTRl.VALUE := TEXTLIST.VALUE; CALL ADD"LIST( TEXTLIST, @TOKEN"PTRI, TEXTLIST.VALUE + TOKEN"PTRl.LENGTH + 1 );
END; IDBDEFAULT := TOKEN"PTRl.VALUE; IDBISDEFAULT := TRUE; MAP. := TRUE;
73
$
dropdisplay IDBFLAGS.DROPDISP := TRUE;
$
fieldlength OR IDBSIZE ( RHS3.VAL[ 2 ] THEN BEGIN !ALLOCATE THE VALUE SLOT IDBSIZE := RHS3.VAL[ 2 ]; IDBVALUE := IF IDBTYPE () STRINGATYPE THEN NEXT"VALUE ELSE NEXT"VALUE '((' 1; NEXT"VALUE := NEXT"VALUE + (IDBSIZE+1)/2; END; IDBSCALE := RHS3.VAL[ 3 ]; IDBISVALUE := TRUE; MAP. := TRUE;
76
$
value (TYPE) IF r-1AP . THEN CALL PRINTA~1ESSAGE( EHADOUBLEAVALUE ) ; IDBVLOC := NUL; IDBISVLOC := FALSE; IDBTYPE := RHS2.VAL[ 1 1; IF NOT MAP.(11> OR IDBSIZE < RHS2.VAL[ 2 1 THEN BEGIN !ALLOCATE THE VALUE SLOT IDBSIZE := RHS2.VAL[ 2 1; IDBVALUE := IF IDBTYPE () STRINGATYPE THEN NEXTAVALUE ELSE NEXTAVALUE ' COPY( LTIS, RHSl ); $
#, !LINE VALUE ( 0 •• 23 ) =
•
Appendix C:
FOR~1AT
DEFINITIONS
C.l Gener'll Value Fon,qts The formats for all values used in the implementation of this r.10del and IDL (except dates and times) are processed by the TAtiDEN FOR!·IATTER routine.
This is fully documented in the
PROCEDURES PROGRA~INUlG HAJ\"'UAL [TAN79b].
GE~ERAL
PURPOSE
The integer,.strin~, and mask
formats, described below, are not inclusive of all formats provided by the FORNATTER, but they provide sufficient information to analyze the sample dialogue definition r,iven in section
4.1.
The d'lte and time forrnts are based on the formatting conventions given in the EriFORM REFERENCE HANUAL [TAN79a].
The interml representation
of the d'lte uses three words (for year, month, day) and of the time uses four words (hour, minute, second, and hundredth secon~).
The integer field descriptor is: Iw, where w is the display field width.
The character or alphanumeric field descriptor is: Aw, where w is the length of the string.
90
91
The out format nay also be described by a Hask format.
The Nask is in
the form:
where
modifier
M< 'picture' format )
modifier
is optional and designates modifications or
decorations of the 'picture', which is similar to a COBOL picture statement.
For example, t1(Z), designates one digit, zero suppressed; M, designates a phone number;
[MP'-']M
