Exhibit 1017 – Part 2
`
`Exhibit 1017 — Part 2
`
`

`
`
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES 101
`
`Table 4.7 Advantages and disadvantages of direct-manipulation
`dialogues
`
`
`
` Advantages Disadvantages
`
`Task analogy
`Reduced familiarizationl
`learning
`Readily retained
`Encourages exploration
`Visually appealing
`Powerful
`Concise
`Design tools available
`
`May require complex or large software
`May require high-performance graphics
`display
`May require auxiliary input devices
`(e.g., mouse)
`Skilled graphics design required
`
`graphics packages. Nevertheless, a wide variety of command language,
`driven software tools were produced in the past for use on
`minicomputers with character—orientated displays.
`
`Computer—aided design
`
`Similarly, first-generation CAD systems were based upon textual input
`of commands, for example, circuit analysis programs such as SPICE
`and HILO require component values to be specified in relation to
`numbered or labelled circuit nodes. Current systems, by contrast,
`attempt to provide a more direct representation of the simulation, for
`example direct schematic capture in the case of circuit analysis, or 2-
`and 3-dimensional models for finite-element modelling.
`
`4.10.4 Advantages and disadvantages
`
`Table 4.7 shows the advantages and disadvantages of
`direct-manipulation dialogues. The primary advantage is the direct
`analogy between the task and the system, which gives the user a sense of
`understanding and control from the start, and encourages exploration.
`In addition, it reduces the time required for the user to become familiar
`with the system, since many aspects should map directly onto his or her
`existing knowledge of the task, and learning is reduced since knowledge
`of the task is also knowledge of the system, and no independent set of
`commands is needed. With careful graphic design, direct manipulation
`can be visually appealing and satisfying, and can also be made powerful
`and concise, thus appealing specifically to expert users. (For example, a
`double click of the mouse button on a Macintosh application icon is
`equivalent to typing the command name in a conventional operating
`system.)
`
`SKYHAWKE EX. 1017, page 40
`
`SKYHAWKE Ex. 1017, page 40
`
`

`
`
`
`102
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`The major disadvantages of direct-manipulation dialogues are that
`they may require complex and expensive hardware to support a suitable
`graphics display, and substantial software development to implement the
`chosen metaphor realistically.
`A variety of design tools are available for prototyping graphical
`direct-manipulation interfaces. Applications such as MacPaint and its
`equivalent on other workstations have been successfully used for
`simulating static graphics displays, while Hypercard and derivatives
`provide some capability to represent dynamic interaction as well. Most
`windowing systems provide development tools allowing rapid
`development of pop-up and/or pull-down menus, dialogue boxes, and
`icon and fount editors (see Section 10.8). The major disadvantages of all
`these tools is the restriction they place upon the designer, who must
`conform to the particular ‘style’ embodied in the tool (e.g., the card
`metaphor in Hypercard, the specific window and menu format and
`actions for a window system). The inclusion of first-class graphic design
`skills in the design team is also an essential requirement for
`direct-manipulation interfaces: this presents particular problems since
`the graphic designer’s ideas may have to be mediated by a software
`engineer in order to produce a physical representation if adequate
`design tools are not available.
`
`4.10.5 Conclusions
`
`The technological disadvantages of direct-manipulation dialogues which
`have inhibited their development in the past are gradually disappearing
`with the availability of high-performance, cheap microprocessors and
`improvements in display technology. At the same time there is an
`increasing need for larger numbers of users to become familiar with
`more and more different computer systems. As a result there is a
`widespread trend towards direct-manipulation interfaces as representing
`an effective way to provide a system which is appealing to novices and
`experts alike, and which is easy to learn, encourages experimentation,
`and is readily retained once learnt.
`However, direct manipulation dialogues are not a panacea; in many
`applications their technical complexity is not justified or may be
`impracticable or the target user population may be better served by
`some other dialogue style. Even where direct manipulation is
`appropriate, other dialogue modes may also need to be introduced to
`achieve functions which cannot readily be represented metaphorically.
`
`4.11 Design principles and guidelines
`Sections 4.6—4.10 have presented specific features of the five major
`different dialogue styles. In this section, more general design issues are
`considered which are relevant to all dialogue styles.
`
`SKYHAWKE EX. 1017, page 41
`
`SKYHAWKE Ex. 1017, page 41
`
`

`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`103
`
`4.11.1 Design sequence"
`
`Dialogue design, like any other aspect of system design, should be
`carried out in a top-down fashion. Hebditch (1979) specifies the process
`of stepwise refinement as follows:
`
`1 Choose dialogue style
`
`The basic dialogue style must be selected from among the five styles
`discussed previously. The choice between these styles will be affected by
`the characteristics of the user population (expert or naive users, etc.),
`the type of dialogue required, and by the constraints of the available
`technology and application area. This will result in an individual style
`or combination of styles being chosen for the dialogue.
`
`2 Design dialogue structure
`
`The second stage is to undertake task analysis and determine the user’s
`model of the task on which the dialogue structure should be based.
`Having proposed a dialogue structure, every effort should be made to
`obtain user feedback by means of informal discussion or more formal
`simulation of the interface.
`
`3 Design message formats
`
`Once a satisfactory dialogue structure has been achieved, more detailed
`attention must be paid to the display layout and textual content.
`Similarly, detailed user input requirements should be considered with
`the objective of maximizing efficiency, for example by avoiding
`unnecessary keying. These issues are considered in the following
`sections.
`
`4 Design error handling
`
`Having designed how the system will work when sensible data is input,
`consideration must be given to the ways in which user errors can be
`made. These include: input data validation, where checks must be made
`that sensible responses or values are given by the user; user protection,
`where the user must be protected from the consequences of his or her
`own errors (e.g., deleting important files); error recovery, that is, the
`provision of mechanisms for backtracking, undoing or retrying
`commands which were executed in error; and meaningful error messages.
`Again, these issues are considered in more detail below.
`
`SKYHAWKE EX. 1017, page 42
`
`SKYHAWKE Ex. 1017, page 42
`
`

`
` — 1
`
`104
`
`ENGINEERING THE HUMAN——COMPUTER INTERFACE
`
`5 Design data structures
`
`Once all aspects of the user interface have been specified, consideration
`can be given to the internal structure of the system, such as choice of
`data structures to support the required functionality. These structures
`should map directly onto the user’s model of the system, though their
`complexity may vary considerably between different applications. For
`example, the graphics data structures required to support a WIMP
`interface are quite complex, whereas those required to support a text
`editor might be much simpler. In either case however, the structures
`should be derived from the interface specification (which in the case of
`the editor is, in effect, the user manual), so as to avoid conceptual
`mismatches between the user’s and system’s models of the system.
`
`4.11.2 Screen design—text
`
`Stewart (1976) has proposed six major factors which contribute to high
`quality textual screen layout: these are summarized below.
`
`1 Logical sequencing
`
`Information should be presented to the user in a sequence which
`logically reflects the user’s task, even if this conflicts with the optimum
`system presentation sequence. If this is not possible, then the rationale
`for using an alternative sequence should be made explicit to the user.
`
`2 Spaciousness
`
`Clutter on a display greatly increases visual search time: the use of
`spacing and blanks is important in structuring the display and
`emphasizing those aspects to which the user’s attention should be
`directed.
`
`3 Grouping
`
`Related items of data should be grouped together to provide
`higher-level structure to the screen as a whole. This reinforces the
`concept of ‘chunking’ and speeds up search times by allowing related
`items to be treated as a group. Even on character-based displays,
`auxiliary characters such as line segments may be able to be exploited to
`emphasize grouping.
`
`_
`
`4 Relevance
`
`There is a natural desire on the part of the designer to include all which
`may be relevant to a display. However, displaying the maximum
`
`SKYHAWKE Ex. 1017, page 43
`
`SKYHAWKE Ex. 1017, page 43
`
`

`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`105
`
`A, Bad format
`PART NUMBER FILE SUB-FILE MISC BKTS
`SUPPLIER J. BLOGGS & SON, ROTHERHAM
`PART 092643lX DESCRIPTION LH BRONZE STUD BRACKET
`GROUP B (‘LASS R STATUS NOT YET ALLOCATED
`SUB-ACCOUNT 92 BUDGET GROUP Z4l3
`QUANTITY UNIT DOZENS DEPRECIATION PERIOD IS ACTION
`DATE OF ADDITION I/I2/75 ADDED BY F. BRIGGS DES‘)
`DATE LAST AMENDED 14/5/75 AMENDED BY PROC II R. SMITH
`DATE OF DELETION
`COMPONENTS NONE
`SUB ASSEMBLIES NONE
`
`B4 Better format
`
`S
`
`PART NUMBER FILE
`,
`°q"°"“"g PART: 092643lX
`GROUP: B
`CLASS: R
`UNITS: DOZENS
`ACTION
`ADDITION DATE:
`LAST AMENDED:
`DELETION DATE:
`/. MAIN SUPPLIER:
`Relevance
`
`Spaciousness
`(‘MISCELLANEOUS BRACKETS
`LH BRONZE STUD BRACKET
`BUDGET GROUP:
`SUB-ACCOUNT: 4’-’
`DEPRECIATION PERIOD:
`PRODUCT STATUS:
`l DEC 75
`F. BRIGGS DES 9
`l4 MAY 75
`R. SMITH PROC 1|
`NONE
`J. BLOGGS & SON. ROTHERHAM
`simphcity
`
`
`
`_Gn,,,p,,,g
`
`2413
`92
`I5
`NOT YET ALLOCATED
`
`Consistency
`
`I
`
`I
`
`I
`
`Figure 4.12 Screen textual layout guidelines (reproduced from
`Stewart, 1976)
`
`amount on the screen is not the same as maximizing the information
`transfer rate, and it is this latter principle which is of primary
`importance.
`
`5 Consistency
`
`In frame-based systems where the user views a number of sequential
`screens full of information, it is important to be consistent in the use of
`display space, so that the user learns where different types of
`information are to be found.
`
`6 Simplicity
`
`The overriding consideration in screen design should be to present the
`appropriate quantity and level of information in the simplest way
`possible.
`Figure 4.12 illustrates these points, and emphasizes the importance of
`aesthetic appeal in the design of the user interface: the interface is the
`‘shop window’ on the product, and as such is the major factor
`influencing the user for or against the product.
`
`SKYHAWKE EX. 1017, page 44
`
`SKYHAWKE Ex. 1017, page 44
`
`

`
`106
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`4.11.3 Screen design—graphics
`
`Graphic design is a well-developed and established area in printing and
`publishing, but its importance in human—computer interface design is
`only now becoming established as computer systems are more widely
`used, and more flexible and controllable display formats become
`feasible. To a significant extent, screen design is constrained by
`technological considerations: the response time, display rate. display
`bandwidth and display type (character- or graphics-oriented) of an
`interface all impose restrictions on the style of interaction which can be
`accommodated. For example, the display style will inevitably be much
`more restricted on a monochrome alphanumeric terminal than on a
`colour graphics workstation.
`Verplank (1988) cites the following five principles of graphical
`user-interface design, which are primarily derived from experience in the
`design of the Xerox Star user interface and its predecessors:
`
`1 The illusion of manipulable objects
`
`Effective graphic design involves three distinct components. First, a set
`of objects appropriate to the intended application must be invented.
`This involves (hopefully) identifying generic stereotypes of the required
`objects on which icon design can be based. Next, the skills of graphic
`design must be used to represent these objects in a convincing way.
`Finally, consistent graphic mechanisms must be provided for indicating
`actions on the object such as selection.
`
`2 Visual order and user focus
`
`Graphical interfaces provide the opportunity to exploit very powerful
`visual stimuli, and features such as flashing, inverse video, strong
`colours and animation can lead to an overpowering and visually
`cluttered interface if they are used to excess. One important point is to
`ensure that the user can readily identify the part of the screen on which
`attention should be focused: hence, the most powerful attention-getting
`devices should be used sparingly for this function (e.g., use of flashing
`to identify the cursor, or use of inverse video on an icon or window title
`to indicate that it is selected).
`
`3 Revealed structure
`
`Parallels are commonly drawn between direct manipulation and the
`WYSIWYG concept, in that both are intended to minimize the
`difference between the observed screen and its effect. A particular
`problem of this approach however is that it fails to convey the
`underlying structure of the activity. For example, in textual documents,
`
`SKYHAWKE Ex. 1017, page 45
`
`SKYHAWKE Ex. 1017, page 45
`
`

`
`107
`
`
`
`Figure 4.13 Revealed structure of Figure 4.4 showing handles and
`alignment grid
`
`the layout is typically controlled by non-displayed control characters:
`although these are irrelevant on the final printout, they may be very
`important in defining the effect or scope of an action during editing.
`Typically, this need is dealt with by providing a display mode in which
`the structure is revealed (for example by showing rulers, e. g. MacWrite
`or control codes, e.g. Word). Similarly, graphical editors such as
`MacDraw require a mechanism for explicitly showing the diagram
`structure, and providing methods of selecting and manipulating
`elements of it (Figure 4.13). These ‘handles’ and other hidden elements
`such as alignment grids form a key element in the design of the
`graphical user interface, since they convey important information to the
`user concerning the structure and dynamic manipulation of the screen
`which is essential for effective interactive use.
`
`4 Consistent and appropriate graphic vocabulary
`
`As with text, it is important for graphic symbology to be used
`consistently throughout an interface design. There is evidence (Mayes et
`al., 1988) that interaction with a computer involves a process of
`‘information flow’ where local display information is picked up, used
`and discarded as necessary to meet functional needs: although the detail
`of the symbology may only be identified at a subconscious level,
`inconsistency will inhibit interaction and familiarization with the
`interface. Figure 4.14 shows some of the graphics conventions used in a
`MacWrite dialogue box (activation buttons; radio buttons (mutually
`exclusive set); check boxes (inclusive set); text entry windows). Note
`
`SKYHAWKE EX. 1017, page 46
`
`SKYHAWKE Ex. 1017, page 46
`
`

`
`108
`
`ENGINEERING THE HUMAN—COMPUTEFl
`
`|NTEl=lFACE
`
`Luserwriter Page Setup
`Reduce or
`Paper: O US Letter © H4 Letter
`Enlarge:
`Q us Lega| Q 35 Letter
`Orientation
`Printer Effects:
`1. 1%
`IZlFont Substitution?
`Esmoothing?
`
`[j Faster Bitmap Printing?
`
`V5.1
`7
`
`Figure 4.14 Example Macintosh dialogue box illustrating standard
`graphic symbology
`
`that many Macintosh users readily use these features, which are a
`consistent part of the Macintosh interface style, without consciously
`being aware of their underlying definition.
`
`5 A match with the medium
`
`The specific characteristics of the display medium substantially influence
`the aesthetic appeal of different graphic constructs, and considerable
`time is required for graphic designers to become proficient in exploiting
`the capabilities of any particular display style. In the past, screen
`designers worked within the constraints of alphanumeric
`character-based displays; currently, many systems are based upon
`bit-mapped (1 bit per pixel) raster graphics displays; in the future, it is
`probable that much greater use will be made of grey-scale and colour
`graphics displays. The experience gained in current bit-mapped displays
`does not necessarily translate directly into appealing aesthetic design for
`colour or grey-scale displays, and we can therefore expect a delay of
`several years before the full potential of these displays is realized.
`
`4.11.4 Response time
`
`It is clear that slow response from a system can have an adverse impact
`upon the user interface, but the exact response speed required for
`satisfactory interaction depends to a large extent on the nature of the
`interaction taking place. Furthermore, variability in system response
`speed also appears to disrupt user performance. Martin (1973) suggests
`a broad division of response times into 5 categories, derived primarily
`from Miller’s (1968) analysis of 17 situations in which maximum
`acceptable response times varied widely:
`
`1 > 15 seconds
`
`Response times of this order generally rule out interactive use of the
`system. The user’s attention is likely to be diverted to other activities
`and only return to the screen on completion of these.
`
`SKYHAWKE Ex. 1017, page 47
`
`SKYHAWKE Ex. 1017, page 47
`
`

`
`I-P——
`
`
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES 109
`
`2 > 4 seconds
`
`Response delays of this order are poor for short-term memory
`retention, and thus should be avoided in the middle of a sequence of
`related operations. They may be acceptable on completion of a major
`cognitive process when intermediate short-terrn data can be discarded
`(‘closure’), for example dispatching a job to the computer.
`
`3 > 2 seconds
`
`Response delays of more than 2 seconds during interactive dialogues
`requiring a high level of concentration can be surprisingly disruptive.
`
`4 < 2 seconds
`
`A response time of this order is generally considered acceptable for
`interactive work, for command input, menu selection, form-filling, etc.
`
`5 Almost instantaneous
`
`Almost instantaneous response is required for very tightly coupled
`activities between the user and system, such as character—by-character
`response to keyboard input or tracking a mouse or cursor movement on
`a screen.
`
`4.11.5 Error handling
`
`It is human nature for the designer of a system to concentrate most of
`his design effort on the way he intends the system to work, rather than
`recovery from user errors. However-, any system will inevitably be used
`at some time by inexpert users, and thus user input errors will occur and
`must be handled effectively by the system. Error handling can be
`subdivided into several distinct requirements, as follows:
`
`System and user protection
`
`Primary requirements are to protect the system from the user, and the
`user from the consequences of other users’ actions (in a multiuser
`system). In multitasking systems these requirements are generally
`supported by hardware memory-managements systems and privileged
`modes. In simpler single-user systems there may be less protection and
`considerable effort must be devoted to testing all conceivable user
`interaction to avoid ‘crashes’: the ‘infinite—number-of-monkeys’ test. A
`secondary need is to protect the user from the system: this involves
`engineering the user interface so that irreversible actions (such as
`
`SKYHAWKE EX. 1017, page 48
`
`SKYHAWKE Ex. 1017, page 48
`
`

`
` _
`
`110
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`deleting a file) are not committed accidentally or without careful
`thought.
`
`Pseudo-errors
`Many systems are unreasonably pedantic about the syntax of user input.
`Programmers’ experience of rigid syntax in programming languages
`gives them an insight into dialogue structures which is denied to other
`users. Such users will judge the dialogue on the basis of what is
`‘reasonable’ (i.e., readily comprehensible and not ambiguous) for
`another human. rather than on the basis of some rigid and arbitrary
`syntax required by the system. For example, the dates
`4/1/53
`04/01/53
`04/01/1953
`4.1.53
`are all readily interpreted as 4 January 1953 (unless you are American,
`in which case they represent 1 April 1953!), yet many computer systems
`are much more restrictive in the date format they will accept. These
`pseudo-errors result from lack of foresight on the part of the
`programmer: very little extra programming effort can make the interface
`appear much more friendly.
`
`Error messages
`Most computer users will have experienced error messages similar to the
`following:
`
`FATAL ERROR — PROGRAM ABORTED
`“SYNTAX ERROR“
`WHAT?
`INVALID DATA
`ERROR OE7 IN DEVICE 080
`Error messages should be clear, concise, specific, constructive and
`positive. The above examples achieve only the second of these
`requirements. Clarity and specificity are achieved by providing exact
`information about the conditions under which the error occurred and
`exactly what the error was, so that the user has some starting point for
`diagnosing the reasons for the error. Constructiveness implies that,
`wherever possible, the system will suggest ways of recovering from the
`error, or correcting it. Finally, error messages should adopt a positive
`and conciliatory tone, and not condemn the user’s mistake: as in other
`commercial areas, the consumer is always right.
`
`4.11.6 Documentation
`Documentation includes both offline and online material provided to
`support the dialogue, and would require a separate chapter to do justice
`
`SKYHAWKE EX. 1017, page 49
`
`SKYHAWKE Ex. 1017, page 49
`
`

`
`DlALOGUE STYLES‘. BASIC TECHNIQUES AND GUIDELINES
`
`111
`
`
`
`to the subject. In many engineering projects it fails to get the attention it
`deserves. High-quality documentation of a project at several different
`levels appropriate to designers, maintenance staff, training staff and
`users is a key requirement for any interactive system. An interesting
`recent trend has been the establishment of documentation companies, to
`whom software houses subcontract the preparation of documentation
`for their systems. This approach has two particular advantages: first, the
`documentation is handled by expert writers, rather than software
`engineers; second, the documenters are independent from the software
`development team, and are thus much better able to view the product
`from the user’s viewpoint.
`Excellent overviews and guidelines on documentation are provided in
`Bailey (1982), Chapter 19, and in Shneiderman (1987), Chapter 9.
`
`4.12 Case study: NE WFOR teletext
`subtitle generation system
`4.12.1 Introduction
`
`The provision of television subtitles for the hearing-impaired via teletext
`has been growing since the introduction of teletext in the mid-1970s.
`Subtitle preparation is a complex and time—consuming task which
`typically required 3045 hours per captioned programme hour using
`first-generation teletext origination equipment. The NEWFOR subtitle
`generation system was developed following research into the display
`requirements for captions for the hearing-impaired, and analysis of the
`operational requirements of the caption preparation process. The
`system is now available commercially, has been sold to a number of
`broadcasting organizations throughout the world, and is used for all
`subtitling carried out by ORACLE Teletext for Independent Television
`in the UK. A full description of the development of the system
`described below will be found in Downton et al. (1985).
`
`4.12.2 Specification of subtitle requirements
`
`Experience gained from foreign-language film captioning is not directly
`relevant to captioning for the hearing-impaired, since foreign-language
`viewers can be assumed to have normal literacy skills, and to be able to
`use their hearing to identify speakers, mood, sound effects and other
`subsidiary audible information. The objective of the initial phase of this
`project was therefore to determine the most effective techniques for
`conveying soundtrack information to the deaf and hearing-impaired.
`A wide range of television programmes were therefore subtitled onto
`videotape and demonstrated at deaf and hard-of-hearing clubs
`throughout Britain. Viewers were shown a variety of contrasting subtitle
`
`SKYHAWKE EX. 1017, page 50
`
`SKYHAWKE Ex. 1017, page 50
`
`

`
` _
`
`112
`
`ENG|NEER|NG THE HUMAN—COMPUTER INTERFACE
`
`.r
`
`lb eommcn
`la:
`We've a
`Q let
`to give each other
`-
`
`Figure 4.15 A sample teletext subtitle (courtesy ORACLE
`Teletext Ltd)
`
`display formats and techniques and asked to express preferences and to
`comment on and discuss the captions. Over a period of time a consensus
`set of display guidelines were derived (Baker, 1981), and these guidelines
`provided a specification for the required display formats and styles of
`the subtitle preparation system. The guidelines specified format and
`amount of text per subtitle, subtitle positioning, display options
`(flashing, foreground/background colour, etc.) and text presentation
`rate. For example, it was found that subtitles should normally be
`presented in white, double-height rnixed-case characters, left-justified
`within a black box, as shown in Figure 4.15.
`
`4.12.3 Task characteristics
`
`Subtitles are generally prepared in advance of programme transmission
`and stored on floppy disk. Figure 4.16 shows the block diagram of a
`workstation used for this task, and Figure 4.17 illustrates the typical
`task sequence involved in subtitle preparation (derived from
`observation of work on first-generation teletext preparation systems and
`interviews with subtitlers).
`
`4.12.4 Dialogue design
`
`The basic design strategy was to share the tasks of subtitle preparation
`in an optimum way. In captioning, the skills of the human operator lie
`
`SKYHAWKE EX. 1017, page 51
`
`SKYHAWKE Ex. 1017, page 51
`
`

`
`
`
`VDU
`terminal
`
`NEWFOR
`computer
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUlDELlNES
`
`113
`
` Subtitle
`
`data
`
`Video and
`subtitles
`
`Colour
`monitor
`
`
`
`processing
`
` U-matic
`
`
`
`Video
`
`Timecode
`reader
`
`VCR
`
`Timccode
`
`Figure 4.16 Block diagram of NEWFOR subtitling workstation
`
`in linguistic intuition and creativity, understanding of the television
`programme, and the ability to control the captioning process and assess
`the results. The captioner may have no detailed knowledge of the
`technical aspects of teletext. The computer system is suited to handling
`routine tasks such as text and display format manipulation, data logging
`and storage and input/output control. Table 4.8 shows the final division
`of tasks between NEWFOR and the operator: in first-generation
`systems all of these tasks were explicitly carried out under operator
`control.
`
`First-generation teletext origination systems mostly used a direct
`command input mode together with qualifying parameters as a method
`of control. To reduce the memory and training requirements, a
`hierarchical menu structure of commands, invoked by typing the first
`letter of the command, formed the basis of the dialogue with the
`NEWFOR system. The user’s model of the captioning process was
`reinforced by grouping tasks into operating modes within the hierarchy
`which corresponded to the preparation strategies adopted by the
`captioners, as shown in Figure 4.18.
`The menu acted as a prompt to the user initially, but as familiarity
`was gained, particular commands could be remembered by acronyms
`such as IOT (input offline titles), and the menu could then be
`bypassed. For novice users, a ‘Help’ option was available at every
`command level which gave further details of all commands available at
`that level.
`
`A standard terminal display style was used throughout all NEWFOR
`
`SKYHAWKE EX. 1017, page 52
`
`SKYHAWKE Ex. 1017, page 52
`
`

`
`
`
`114
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`
`
`
`
`
`Prepare U-matic programme dub
`(including time~coding)
`
`Prepare typed script
`(if no script available)
`
`
`Edit script for captions
`
`1'.
`
`
`Input caption text
`
`
`
`
`Format caption text
`
`
`
`Format/caption
`errors
`
`Synchronize captions using
`timecode
`
`
`
`—i Review captioned programme
`
`Timing errors
`
`l
`
`Formatted. timecoded caption disk
`
`for broadcast with master video
`
`Figure 4.1? Example task sequence in caption preparation
`
`modes, as shown in Figure 4.19. The upper 70 per cent of the screen
`provided a workspace for displaying current caption input or help
`information, while the remaining blocked—off display area provided
`various status displays. Subdivisions within the status block indicate
`current menu options, operational mode and non-textual characteristics
`of the current subtitle, such as time code, display time, foreground and
`background colour, and caption position.
`
`4.12.5 System performance
`
`Performance was assessed using two criteria: training time and
`productivity. In each case direct comparison could be made with
`
`SKYHAWKE Ex. 1017, page 53
`
`SKYHAWKE Ex. 1017, page 53
`
`

`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`115
`
`MAIN MENU—L- Mount
`
`Input
`
`Live ——-— Titles
`—- Xon/off
`— Add
`—— Remove
`— Print
`— Help
`
`—Offline
`
`— Titles
`— Xon/off
`— Help
`
`Tshortforms —y—-Add—Remove
`
`—-Print
`—Save
`-Load
`- Clear
`— Help
`
`Help
`
`tdit
`
`< >
`Jump
`I
`Insert
`'
`Delete
`l
`Open
`I
`Cue
`|
`Save
`|
`Merge
`|
`Help
`:
`l Other commands
`
`Figure 4.18 Part of hierarchical NEWFOR command menu
`
`Table 4.8 Task division for NEWFOR subtitling system
`j:::j
`
`Captioner
`
`Computer
`
`Text input
`Position selection
`Colour selection
`
`Text format (using geometric and linguistic criteria)
`Positioning of formatted text
`Calculation of boxing outline
`
`Synchronization
`
`Storage of result _einsertionofcolourandboxingcontrolcharacters
`
`Calculation of on—air display time
`
`l
`
`|
`
`SKYHAWKE Ex. 1017, page 54
`
`SKYHAWKE Ex. 1017, page 54
`
`

`
`116
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`NEHIUII HFIIN MENU
`
`Hurt
`lrp.-I
`Ejit
`
`the 'uIJil'flE dun fully for use
`- L.;.~,—ur-
`(me trarum»
`;uI'.t‘t|es For dlSI\ storage or
`» Tape
`:r-
`> It.» l£x'I or
`'II’fI&§ carrer‘. ms to suttitle disk
`-
`'E+_r»_
`._.r
`r_»;rr
`;+ trretudts tr- sub!.tle dlSI1
`u.‘II|
`I'e'IllaI or a.1lC"IiIIC cueing
`an :ublliIE disk
`or.
`pr"
`inure detailr atuui available commands
`-i»:
`':m.p _urrerxt OFer’dil;fl
`-:-I wwe back to prcvioui cum.‘-mi‘
`
`-.-n
`
`
`
`.
`
`:
`
`I':..
`
`-a I-H'1'I"*-‘7ti‘I
`
`'3,‘ Mt F-rt lettzr of
`
`the command goal require
`
`IN-suit
`
`lrrru? Eait hx Replay
`
`llisk Help
`
`>>
`
`Figure 4.19 Sample NEWFOR terminal display
`
`competing first-generation teletext origination systems used for the same
`process of subtitle preparation.
`
`Training
`
`Initial training to use NEWFOR in the offline input mode was a matter
`of only a few minutes, since little more than copy typing was required.
`By comparison, previous systems required an explicit knowledge of
`teletext display characteristics, including control characters, plus the
`capability to edit and position subtitle texts. Typically at least one
`week’s training was required to achieve proficiency. A second, more
`extensive training period was required to achieve full working
`knowledge of all aspects of the system. This required about one month
`for NEWFOR, whereas competing systems typically required 2—3
`months.
`
`Productivity
`
`The introduction of NEWFOR at ORACLE Teletext Ltd improved
`productivity from around 25-40 hours per captioned hour of
`programme material in 1984 to 10—l5 hours per captioned hour in 1986.
`In addition to providing this substantial productivity gain, the
`offloading of many of the more mundane aspects of caption preparation
`meant that NEWFOR could also be used for pseudo-live captioning,
`which would have been quite impossible with first generation systems.
`
`SKYHAWKE Ex. 1017, page 55
`
`SKYHAWKE Ex. 1017, page 55
`
`

`
`
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`117
`
`In fact, early versions of NEWFOR were used to subtitle a variety of
`important live events during its development phase, for example the
`royal wedding (1981), the papal visit (1982), the state opening of
`Parliament (1983) and the opening of the Thames Barrier (1984). A
`modified version of the system linked to a chord keyboard is currently
`used for live Subtitling of the early-evening ITV and Channel 4 News.
`
`References
`
`Bailey, R. W. (1982) Human Performance Engineering: A Guide for System
`Designers, Prentice-Hall, Englewood Cliffs, NJ.
`Baker, R. G. (1981) Guidelines for Subtitling Television Programmes,
`IBA/ITCA/Southampton University.
`Card, S.K., T. P. Moran and A. Newell (1983) The Psychology of
`Human—Computer Interaction, Lawrence Erlbaum Associates, Hillsdale, NJ.
`Daniels, G. S. and E. Churchill (1952) The ‘average man’? WCRD-TN-53-7,
`Aero Medical Lab., Wright