Exhibit 1016 – Part 3
`
`Exhibit 1016 — Part 3
`
`

`
`Group Caption Field
`1. Voyage Details
`From
`To
`Date
`Time
`. Accommodation
`Cabin
`
`Berths — M
`—— F
`
`Seats — R
`— C
`. Vehicle Details
`
`Screen formatting
`
`Size and Format
`Inward
`Outward
`Code(3) Name(15) Code(3) Name( 15)
`Code(3) Name(15) Code(3) Name(l5)
`(dd/mm/yy)
`(dd/mm/yy )
`(hh.mm)
`(hh.mm)
`
`(D, N or null)
`(nn or null)
`(nn or null)
`(nn or null)
`(nn or null)
`
`(D, N or null)
`(nn or null)
`(nn or null)
`(nn or null)
`(nn or null)
`
`Car Registration
`Length
`Overl.83m
`Caravan Length
`Overl.83m
`
`(8 alphameric or null)
`(99.9)
`(y/n)
`(99.9 or null)
`(y/n)
`
`(8 alphameric or null)
`M/C Registration
`Solo/Combination (s/c)
`. Passenger Details
`Adults
`Children
`. Customer Details
`
`(nn)
`(nn or null)
`
`Name
`Address (X 3 lines)
`Post Code
`Telephone Number
`. Campsite Reservation
`. Insurances
`
`Holiday
`Vehicle
`Trailer
`Car Make
`Model
`Return Date
`Age of Vehicle
`Winter Sports
`Fig. 7.5 Adding the item formats.
`
`(20 alpha)
`(3><20 alpha)
`(8 alphameric or null)
`(12 alphameric or null)
`(T/C/S or null)
`
`(y/n)
`(y/n or null)
`(y/n)
`(10 alpha)
`([5 alpha)
`(dd/mm/yy)
`(nn years)
`(y/n)
`
`

`
`182
`
`Chapter 7
`
`7.5 Where should the Information be Displayed?
`
`7.5.1 General Guidelines on Positioning
`
`Having decided what items to display and in what format, the next stage is to
`position these into the available space on the physical screen. This is not just
`a case of squeezing them in wherever they will fit!
`So much information is displayed in Fig. 7.2 that it is difficult to identify
`individual items or groups of items. Clutter is a subjective measure; whether
`a particular layout seems cluttered will depend on the individual user and the
`task which the screen is designed to assist. For example, a screen used for data
`entry from source documents by trained key operators can be more crowded
`than one designed for the display of output data messages or for input by an
`untrained operator. However,
`there are a number of rules of thumb
`concerning spacing which provide guidance:
`
`leave approximately half of the total screen area blank;
`leave a blank line after every fifth row of a tabular format;
`leave four or five spaces between the columns of a columnar format.
`
`These rules of thumb are precisely that, they should be used merely as
`guidelines, not followed slavishly. Whilst it is quite possible to produce an
`acceptable format in particular cases which does not follow them, a conscious
`design decision should have been taken to contradict them.
`Where items must be split across more than one screen, the split should
`occur at a natural break, if such exists. Not only should the break not occur
`within a logical group, all groups required for a particular decision should
`also appear on a single screen. Consider what happens if a ferry booking is not
`accepted. This may occur either because the desired accommodation is not
`available or because there is insufficient vehicle space; it can be assumed that
`there is always sufficient passenger space. The customer may change his
`voyage or may forgo the desired accommodation or both. Thus the clerk
`requires voyage, accommodation and vehicle details to be displayed on a
`single screen. It is not essential that the other groups appear on this screen
`since they do not affect the success of the booking. This analysis also suggests
`seven logical groups as indicated in Fig. 7.5 rather than the six groups of Fig.
`7.3.
`
`On any screen, logical groups should be clearly identifiable as separate
`entities. This can be achieved by leaving several spaces around the borders of
`
`

`
`voyage Details
`
`Screen formatting
`
`dve Dover East
`
`ost Ostende
`
`blg Boulogne
`26.10.86
`14.05
`
`flk Folkestone
`31.10.86
`17.50
`
`Fig. 7.6 Using ‘boxing’ to delimit logical groups.
`
`each group or by explicitly ‘boxing’ with vertical and horizontal line segments
`(as in Fig. 7.6) with different attributes for fields in different groups.
`The users’s eye should be guided through the screen by the physical
`patterns created by the blocks of text. These blocks should be balanced. Fields
`should not be tucked up against the margins of the screen but centred about
`the vertical and horizontal axes. In cases such as menu screens where only a
`relatively small amount of information is to be displayed, it should appear
`centred in the leftmost two thirds of the screen. To reinforce this symmetry,
`data fields and captions should be aligned vertically within a logical group;
`where possible, this alignment should be preserved across all logical groups.
`There should be an obvious starting point. The normal convention is to
`start at the top left hand corner and proceed left to right and top to bottom.
`Although boxing can suggest other conventions, it should only be changed as
`the result of a conscious design decision. The same type of information should
`appear
`in a consistent and predictable relative position on the screen
`throughout the application.
`Aesthetics are important. A screen that is attractively presented is likely to
`invoke a positive response from a user and be easier to follow. You cannot
`reasonably expect a user to take more trouble completing a form on the screen
`than the designer took developing it!
`
`7.5.2 A Template for Screen Layouts
`
`If screen layouts are to be consistent both within and across applications, they
`must all be based on a common template. Figure 7.7 illustrates such a
`template.
`The top two or three lines of the screen are reserved for title and status
`information. Titling information often includes a description of the
`
`

`
`Title & Status Information
`
`Upper Message Area
`
`Screen Body
`
`Lower Message Area
`
`Standard Facilities & Escape Hatch
`
`Fig. 7.7 A screen template.
`
`GL30l
`ost/sa1es/invoices
`
`13 Jan 86
`General Ledger System
`posting to ledger . .. PLEASE WAIT
`
`Fig. 7.8 Where am I? Is it still working?
`
`application and/or particular task within it to which the screen relates. The
`current date and time may be displayed towards the right—hand margin. It is
`also common for each screen to be assigned a unique reference number; if a
`user encounters any problems with the system, this reference provides a
`convenient way for systems staff to identify the precise point at which the
`problem occurred.
`The title area can be used to confirm the position in the system which the
`user has reached. In a menu hierarchy, the status area may indicate the path
`he has taken through the system by displaying the options chosen on previous
`menus, as in Fig. 7.8. It can also be used to provide confirmation that the
`system is still operating.
`Optional upper and lower message areas provide consistent locations for
`messages which give instruction to the user or indicate exceptional conditions.
`
`

`
`Screen formatting
`
`(F2) 11.26.77
`Q:
`Worl(shaetRai1;eC}opyIbveFi1ePriJrtGza1:l'irntaQfi.t
`Format, Iabal.-Pre£:.x, Erase, Name, Justify, Protect, Ilnpmtect, Input:
`3
`C
`D
`E
`F
`G
`1985
`1986
`1987
`1988
`1989
`
`H
`1990
`
`1126.77
`300.77
`
`1133.11
`315.81
`
`1242.27
`331.60
`
`1304.38
`348.13
`
`1369.60
`365.59
`
`1438.08
`383.87
`
`826.00
`
`867.30
`
`910.67
`
`956.20
`
`1004.01 1054.21
`
`15.29
`20.70
`31.45
`48.76
`25.98
`
`15.29
`20.70
`31.45
`48.76
`25.98
`
`Expafia 142.18
`
`142.18
`
`Operatirxy Hrofit
`Financing fits
`Profit before Tax
`
`683.82
`457.90
`225.92
`
`725.12
`457.90
`267.22
`
`15.29
`20.70
`31.45
`48.76
`25.98
`
`142.18
`
`768.49
`457.90
`310.59
`
`15.29
`20.70
`31.45
`48.76
`25.98
`
`142.18
`
`814.02
`457.90
`356.12
`
`15.29
`20.70
`31.45
`48.76
`25.98
`
`142.18
`
`861.83
`457.90
`403.93
`
`15.29
`20.70
`31.45
`48.76
`25.98
`
`142.18
`
`912.03
`457.90
`454.13
`
`‘
`
`. 7.9 Status and message areas in a spreadsheet structure.
`
`Instructions which pertain to how the screen should be processed appear in
`the upper area; those which pertain to how it is disposed appear in the lower
`area. You need to know ‘how to do it‘ before you start and ‘what to do with
`it afterwards’ when you have finished! Either area can be used for help or
`error messages. It is more common to display help messages in the upper
`portion of the screen and error messages in the lower. Messages requiring
`action by the user (e.g. to confirm the values input in form filling) would
`normally appear in the lower area. The use of an upper message area is well
`illustrated by hybrid dialogue structures. This area is used for the display both
`of command menus and of error messages (see Fig. 7.9)
`The screen body contains the main information which the screen is seeking
`to impart. In a menu structure, it contains the list of options; the menu header
`might be considered to appear in either the upper message area or the screen
`body. In our form filling example, it is the area within which the form is
`displayed and the input fields echoed. In a hybrid dialogue, such as the
`spreadsheet illustrated in Fig. 7.9, it contains the cells of the spreadsheet.
`One or two lines are reserved at the bottom of the screen to display standard
`facilities which are available on all screens. The message areas contain
`instructions specific to that particular screen body. A possible use of this area,
`to indicate the meaning of function key input, is illustrated in Fig. 7.10. It is
`called an escape hatch because it often contains a facility which enables the
`user to ‘escape’ from the normal processing flow.
`
`

`
`prior = F2
`
`Fig. 7.10 The Escape Hatch.
`
`This particular template splits the screen horizontally into a number of
`fixed ‘windows’; it is a simple example of the techniques discussed in Chapter
`10 for handling dynamic windows. The fact that the layout of every screen
`consistently conforms to some recognised template is more important than
`which particular template is chosen.
`
`7.5.3 Positioning Error Messages
`
`the error message is normally
`With a Question and Answer structure,
`displayed alongside or underneath the answer field. For example,
`
`From: dvx Port code not recognised
`
`An error message is usually unnecessary in a menu structure since the most.
`likely cause of error is miskeying or a slip with a pointing device. If an error
`message is to be displayed, it usually appears below the list of options and in
`the lower message area.
`In both the command language and the forms structure, a number of
`answers are input and so there are potentially a number of error messages.
`Most command language structures stop after detecting the first error and
`hence will display a single error message. In teletype mode, this message is
`displayed below the input line and the dialogue advances to the next line with
`a request for reinput. The display of error messages is slightly more
`problematical in a form structure. The user usually completes the form and
`returns to edit any fields in error. Therefore, the layout must accommodate
`the display of a variable number of error messages.
`With a simple form, such as that in Fig. 7.11, it may be possible to display
`an error message alongside the field in error. This is the normal way to display
`a confirmation message, such as the description corresponding to a code.
`This approach is seldom possible with a highly formatted form. In our ferry
`booking example, an attempt to leave space for a possible error message
`alongside each input field is likely to destroy the balance of the screen. It is
`improbable that sufficient space can be reserved in a single area, such as the
`
`

`
`Screen formatting
`
`Invoice Number: [Vl2345]
`Invoice Date
`[12/11/89]
`Customer Code-: [C23]
`Invoice Amount: [100.00]
`
`VAT Amount
`Invoice Total
`
`: [l5.00]
`: [151.00]
`
`Postdated Invoices not accepted
`Clough Brothers Ltd.
`
`Invoice Total does not tally
`
`Fig. 7.11 A simple form with error messages shown alongside fields.
`
`lower message area, to display all the possible error messages simultaneously.
`As we saw in Chapter 5, the system usually flags the input fields in error,
`positions the cursor at the first field in error and displays the corresponding
`message. As each input field is re-entered, the cursor moves to the next one in
`error and displays its error message.
`
`7.6 Highlighting
`
`Highlighting is the use of ‘strong’ attributes to make a particular area stand
`out from the rest of the screen and thereby attract the user’s attention to it.
`Clearly the user’s attention can only be attracted to a limited number of areas
`and if highlighting is overused, it becomes confusing rather than helpful. This
`is fine if the designer’s objective (as in a video game) is to prevent the input
`process being too easy but it is unlikely to be desirable in most applications.
`Initially the designer should specify a layout without any highlights and
`then go through each field asking himself what positive advantage would arise
`from the addition of a highlight. If the system only displays the information
`which is relevant to the user, there should be limited need for emphasis. Many
`existing systems demonstrate the temptation of highlighting; it is Very easy to
`add just that bit more...
`We have defined the attributes of a field in terms of aforeground colour, a
`background colour, a bold contrast level and a blink setting. These various
`features have different attention-getting powers; some are harder to ignore
`than others. To avoid diluting their impact, use only the minimum
`highlighting necessary to attract the user’s attention. A person’s attention can
`be attracted with a delicate nudge rather than a punch in the ribs, provided
`that they have not been subjected to constant battering! A combination of
`highlighting features is needed only when an exceptional emphasis is required.
`A blinking foreground is the strongest visual attention-getter and hence
`
`

`
`188
`
`Chapter 7
`
`potentially the most distracting. It is best restricted to a single character
`position alongside the field to be highlighted. Blinking the text of a message
`is a good way of making it difficult to read!
`Colour is the next strongest attention getter. Different colours in the
`spectrum have different warmths and perceived brighmesses. Areas shaded
`with backgrounds in the warmer colours at the red end of the spectrum
`appear larger than those shaded in colours at the blue end of the spectrum.
`Areas with backgrounds in white and colours towards the middle of the
`spectrum appear brighter and are easier to view under a wide range of
`ambient lighting. The best separation of two areas occurs when one is shaded
`in black or a colour from near one end of this spectrum and one is shaded in
`white or a colour from near the middle. The same consideration applies to
`distinguishing foreground content from the background of a field.
`Users like the use of colour. Humans can distinguish many thousands of
`different colours but can cope with only a limited number at one time. There
`is also a danger in applying guidelines from colour printing to a screen. Much
`of the impact of colour printing arises from its use of subtle hues; the brash
`palette of colours provided by most colour screens does not permit such
`subtlety and there can be wide variations in the same colour produced on
`different screens. Certain juxtapositions of these colours,
`like a blue
`foreground on a red background, are positively unpleasant to the eye. The
`only real way of assessing how the colours will appear is to view them on the
`screen.
`
`The implications of colour blindness can be overstated; it is typically an
`inability to discriminate between two very specific shades of these colours,
`accentuated by particular ambient lighting conditions. More important is the
`fact that all humans bring expectations of the meaning of different colours —
`red means stop, danger, etc.; colour coding within the system should be
`consistent with these expectations. A system which uses red for status
`messages that confirm everything is satisfactory and green for error messages
`is likely to be confusing.
`The consequences of the above for the use of colour on a screen are
`summarised in Fig. 7.12.
`On many monochrome screens, the effect of different colour attributes is to
`produce different shades of the screen’s base colour; thus, on a green screen,
`different background colours might result in different intensities ofgreen. The
`eye is less able to distinguish different contrast levels than different colours
`and the designer should beware of unwanted and nauseous highlights
`occurring when a system is ported from a colour to a monochrome device.
`
`

`
`Screen formatting
`
`189
`
`Use the minimum of number of colours and not more than three or four on
`any screen.
`Use background colours in large blocks.
`Use bright colours for emphasis and weaker colours for background areas.
`To distinguish two areas of background, or to distinguish foreground and
`background, contrast black or a shade from one end of the spectrum with
`white or a second shade from near the middle.
`
`Use colour coding consistent with the user’s expectation.
`Try it out on the actual screen.
`
`Fig. 7.12 Guidelines for using colour.
`
`Good results can be achieved with two levels, using the higher intensity
`background to ‘box’ the area to be emphasised. Inverse video is an example
`of this effect which is commonly used to highlight messages indicating
`exceptional conditions such as an input error; the area with the lighter
`background draws the user’s eye. A number of upmarket workstations with
`black and white displays present a completely inversed image —— printing is
`black on white! However, there is a danger of a ‘shimmering’ effect from large
`areas of inverse video which is very tiring on the eyes; it should be possible for
`a user to select normal or inverse presentation.
`The use of different foreground intensities is the least intrusive attention
`getter. It is particularly effective for distinguishing data fields from output
`messages such as prompts and captions; the field to be emphasised has the
`bold attribute set on. A designer is usually spared any temptation to use
`multiple intensities since most screens support only two levels — bold off
`(normal) and on (high).
`Other highlighting features are possible on some displays. The content of
`a field may be underscored or displayed in a variety of type styles or sizes; the
`characters of any given type font are specified as a pattern of bits which
`correspond to on/off settings of the pixels in a character position. Neither
`technique has the same impact that it does in hard copy and a multiplicity of
`fonts hinders rather than helps discrimination and may increase the sense of
`clutter on the screen.
`
`Finally there is sound. Anyone who has sat in a room with a large number
`of terminals ‘beeping’ for input like hungry chicks, or in an amusement arcade
`full of video games endlessly repeating snatches of electronic Wagner, will
`appreciate the crass intrusiveness of sound as an attention getter. Sound is
`effective where it is really important to attract the attention of a user who may
`
`

`
`190
`
`Chapter 7
`
`not be watching the screen and is therefore not susceptible to a visual
`highlight. Tests on aircraft cockpit warning systems have shown that its effect
`is rapidly diluted. Frustrated composers should ensure that they have
`included an ‘off switch’ for silent running in their design.
`There appears to be little need for highlighting in our ferry booking
`example. Blinking will be used only as a single character block cursor to
`indicate the current cursor position. Different foreground intensities will be
`used to distinguish input fields from captions in the screen body and from the
`other template areas; a similar effect could be obtained by using two colours
`but there is no real need for colour. Error input fields will be indicated by
`using a different background intensity or inverse video;
`these will be
`associated with the error message in the lower message area by using the same
`highlight for the error message. No sound will be used.
`
`7.7 Producing a Draft Design
`
`Having decided the information to be displayed, its format, how it is to be
`grouped on the screen and what highlighting is required, it is time to start
`producing some pictures.
`A number of clerical forms to assist the design of screen layouts have been
`produced; these have merits in terms of providing a documentary record but
`all have a major drawback: what the layout looks like on paper bears little
`ressemblance to how it will appear on the screen. The form is covered in a
`matrix of squares indicating the character positions and, in most cases, the
`aspect ratio of the form differs from that of the screen. The font, which will
`probably be handwritten, will be different;
`in fact,
`the forms seem to
`encourage many people to use upper case exclusively. Furthermore, there is
`no way to create the effect of highlights. The only way to get a true impression
`is to display the draft design on the screen.
`A proposed layout for the screen is illustrated in Fig. 7.13. Two lines are
`reserved at the top of the screen for titling information. There is no upper
`message area since it is assumed that the existence of a source document
`renders completion instructions redundant. The body of the screen contains
`the three logical groups necessary to confirm a booking, and also the
`passenger details; these logical groups are differentiated by position and
`spacing.
`
`Captions are aligned within groups and input fields are delimited by
`bracketing; note how several captions have been changed from the initial
`
`

`
`Screen formatting
`
`191
`
`proposals in Fig. 7.5. A lower message area of three lines is reserved for the
`display, in a different background contrast, of error messages and confirma-
`tion by the system of the booking. The bottom line displays the interpretation
`of function/cursor keys.
`After the completion of input, the screen appears as in Fig. 7.14. Input
`fields are echoed with the bold attribute set to ‘on’. The port names are
`alongside the input codes. Coded input and the registration number are
`displayed in upper case regardless of how they were input. The lower message
`area contains a confirmation by the system that the booking has been
`accepted; this appears after the user has pressed the F1 key to confirm the
`input (provided no errors have been encountered). If the booking could not
`be accepted because of insufficient space, a corresponding message would be
`displayed and the cursor returned to the first input field.
`
`FastFerries Reservations
`
`utward '
`
`Accommodation:
`Cabin (D/N): =
`
`Vehicle Details:
`Car Registration; [
`'
`‘
`
`=
`
`] Length: [
`Trailer Length: [
`
`;
`
`.
`.
`
`.
`] In High-sided: [
`] m High-sided: [
`
`]
`]
`
`I ‘
`
`ChiIdren:[
`
`]
`
`back = A
`
`forward = v
`
`confirm = Fl
`
`cancel = ‘-
`
`Fig. 7.13 A draft layout.
`
`

`
`Chapter 7
`
`[CH8] Cherbourg
`[WEY] Weymouth
`
`Vehicle Details:
`
`ar Registration: [ CAll123B ] Length: [
`'
`Length: [
`
`3.5] m High-sided: [N]
`3.0] m High-sided‘. [V]
`
`Fig. 7.14 The screen after completion of input.
`
`Once the booking has been confirmed by the system, the screen body
`changes so that the other logical groups can be entered. This is illustrated in
`Fig. 7.15. Note that the group containing the voyage details is preserved for
`information, and that the options in the escape hatch have changed to allow
`the user to flip back to the prior screen and amend it if desired. Note the
`different conventions used for input of the type of camping reservation (which
`are mutually exclusive) and of the types of insurance (which are not).
`As a final stage, the system will probably produce a summary which can be
`printed to provide a customer copy. This obviously no longer needs to have
`the same layout as the form. Its design is left as an exercise for the reader.
`
`7.8 Evaluating the Design
`
`These layouts are not presented as the optimum solution but merely as an
`
`

`
`Screen formatting
`
`FastFerrics Reservations
`
`Vo .; Details:
`
`Cherbourg
`
`Postcode:[ "
`Telephone: [
`Winter Sports Y/N): [
`.
`g
`’
`‘
`Caming Reservation (T/C/S)
`"
`'”“
`--
`
`__
`
`}
`"
`
`ck=
`
`forward v
`
`Fig. 7.15 The screen for the remaining logical groups.
`
`illustration of the process; hopefully, they represent an acceptable starting
`point‘ The next stage is to evaluate the proposed design and repeat the process
`until an acceptable format is achieved. How can a screen layout be evaluated?
`Are there any objective measures which we can apply to test whether the
`screen is uncluttered, balanced and so forth?
`The answer to this latter question is strictly neither yes nor no; a number of
`general mechanisms have been suggested but are not yet completely
`formulated. One problem is that the viewer of a screen is heavily influenced
`by the information content, which tends to cloud his judgement of the
`presentation. A general mechanism would divorce the content from the
`format; two suggestions for achieving this are boxing analysis and hot spot
`analysis.
`Boxing analysis divides the screen up into physical groups; a group is an
`area of text characters with at least one blank space all around its perimeter.
`The smallest possible rectangle is drawn around each group, dividing the
`
`

`
`194
`
`Chapter 7
`
`screen into a set of boxes. Drawing axes about the centre of the screen gives
`an impression of the balance of the layout. The number and size of boxes gives
`an impression of the ‘business’ of the layout; a large number of small boxes
`suggests a ‘fussy’ layout.
`Hot spot analysis attempts to identify the parts of the screen to which a
`viewer’s eye would be drawn by the ‘intensity’ of the image at that point. The
`intensity at each point is computed as a moving average of the number of non-
`blank character positions around that point; increasing density is displayed
`by using characters which ‘switch on’ an increasing number of dots in the
`character matrix or increasing background intensities. One would expect a
`small number of hot spots symmetrically positioned about the central axes.
`These mechanisms are described and illustrated in the reference quoted in
`the bibliography at the end of the chapter. However, even these techniques
`lack a quantitative measure: What is a ‘large number’ or a ‘small box’? Is a
`point surrounded by the character ‘.’ hotter than one surrounded by the
`character ‘W’? These questions are yet to be answered.
`Another argument against the general approach suggests that the attempt
`to divorce content from format is mistaken; a layout should be judged by
`fitness for its particular purpose rather than as an abstract piece of graphic
`design. By this token, the only way that the layout can be evaluated is by
`prospective users actually interacting with that screen. Although general
`techniques may be useful to a designer in eliminating some design flaws before
`the user evaluation takes place,
`there is no substitute for this type of
`evaluation.
`
`Screen layout, like all aspects of the interface design, is an iterative process.
`A large number of layouts may need to be modified many times before an
`acceptable version of the system is produced. If the designer must produce
`individual code to generate an example of each layout,
`this will be an
`unacceptably lengthy process; an automated mechanism, a screen design aid,
`is required to support this.
`
`7.9 Screen Design Aids
`
`The output processes described in Chapter 3_ go some way to reducing the
`effort of generating a screen layout. Rather than coding all the statements
`necessary to display output from scratch, the designer has merely to assign
`values to field data structures. A reader who has attempted any of the
`exercises will be assured of the savings this involves. However, it is still fairly
`time—consuming. To define a field the user must specify
`
`

`
`Screen formatting
`
`195
`
`-
`-
`
`-
`
`the content (not difficult);
`the slot; this means that the designer must already have checked this out
`roughly;
`the attributes; the effect of these must be a guess.
`
`the code containing these
`When this has been done for all fields,
`assignments must be compiled, linked with library routines and executed.
`Any change in any aspect of any field definition means that the whole process
`must be repeated. Unfortunately, the designer is unlikely to have a real idea
`of what
`the screen looks like until the code is executed. It would be
`considerably easier if the designer could sit in front of a screen and ‘paint’ the
`proposed layout on it; he could then evaluate the screen’s appearance as it
`develops. Figure 7.16 illustrates a screen design aid of this type.
`The screen is divided into three parts. The upper message area contains
`information on the current cursor position and the current values of the
`attributes. The lower message area contains a menu bar which, among other
`things, allows the attributes to be changed. The screen body contains the
`screen that is being designed. The user enters text at any position by moving
`the cursor to that position and keying; this overwrites the character already
`there. Attributes can be changed by selecting Option 3 from the menu bar,
`and scrolling through the attributes in the upper message area, changing
`individual values to taste. To paint the attributes into an existing field, the
`designer positions the cursor to the start of the slot and presses a control key;
`another control key is used to indicate the end. The slot thus marked is
`redisplayed with the new attributes. The same effect can be produced with a
`mouse by pointing the mouse at the start of the field, pressing a button and
`dragging the mouse to the end of the field keeping the button pressed. New
`fields will take the existing values of the attributes.
`
`row=2l=10
`fore xxxxx
`back xxxxx
`
`-
`.-
`blink = off
`
`bold = on
`
`just = centre
`
`Fl = help
`
`F2 = sho
`
`F3 2 change attribes
`
`ESC = exit
`
`Fig. 7.16 A screen design and
`
`

`
`196
`
`Chapter 7
`
`Because some of the rows of the screen are taken up with information
`
`relating to the screen design aid, it would appear that no screen can be
`designed that uses these particular lines. One way round this problem is to
`allow the designer to scroll the screen body up and down, thus allowing the
`screen to be larger than the screen body. The full screen as it would appear in
`an application program can be displayed by selecting Option 2 of the menu
`bar. This is a toggle-switch; selecting it again redisplays the menu bars.
`A screen design aid provides the designer with immediate feedback on the
`visual effect of the screen as he creates it. Changes can be effected simply by
`overpainting. The minimum requirement of a screen design aid is for it to
`provide facilities for creating, storing, retrieving and editing ‘static’ layouts.
`Further facilities are useful: a mechanism for naming the fields created by the
`screen design aid, and for linking these names to variables in the application
`program that is to use these screens; a mechanism for specifying the filtering
`and validation that is to take place at each field, and for automatically
`generating the appropriate code. Such facilities mean that the values of the
`various parameters in QandA_DIBs which define the dialogue can be
`specified by painting them on the screen. A number of proprietary packages
`exist which support some or all of these features and many installations have
`also developed their own. If such facilities do not already exist, their provision
`should be a high priority to any designer.
`
`7.10 Summary
`
`The screen design process involves:
`
`deciding what information is to appear;
`deciding how and where each field will appear;
`deciding what highlighting is required;
`developing a draft layout;
`evaluating the effectiveness of the layout.
`
`To ensure consistency, the overall layout of all screens should conform to
`a standard screen template. This template should identify the position of the
`information whose communication is the primary purpose of the display and
`of supplementary information (titling, status and instructions) which support
`the user’s interpretation and manipulation of the primary information.
`The screen should contain all the information needed by the user at that
`point and only that information. The information should be organised so that
`
`

`
`Screen formatting
`
`197
`
`its physical positioning reflects its logical grouping and is presented in an
`immediately usable format. The designer must understand the task in order
`to be able to assess these requirements.
`A cluttered screen will impede the user’s reception ofthe information which
`it contains; there are a number of standard guidelines covering the format and
`spacing of messages which are applicable. Where related information must be
`split across several physical screens, care must be taken that each screen still
`contains all the information necessary to process that particular screen.
`Highlights attract a user’s attention to particular areas of the screen and
`help to classify the information displayed in different areas. There are
`guidelines which can prevent the misuse or overuse of highlighting; intended
`highlights must still be tested on the screen on which they will be used because
`of wide variations in the way they are implemented.
`Although some objective measures for evaluatin