标题: Creating user manuals for use in collaborative design [打印本页] 作者: 航空 时间: 2010-7-31 15:47:29 标题: Creating user manuals for use in collaborative design
作者: 航空 时间: 2010-7-31 15:47:56
Creating user manuals for use in collaborative design Harold Thimbleby Middlesex University Bounds Green Road London, UK Tel: +44 181 362 6061; Email: harold@mdx.ac.uk ABSTRACT computer support to guarantee the correctness (and continuing editability) of their documentation. Serious accidents have occurred with very simple manuals done by hand [1]. Our own work has found further flaws in the A320 Flight Crew Operating Manual (FCOM). User manuals are usually written by technical authors after the design of the device has been committed for production. If the manual’s review leads to insight into the design, it is too late. Meanwhile, if the design is modified, the manual may be inaccurate. This paper describes an example language for creating accurate and complete manuals from formal specifications. We show how it can be used to improve part of the Flight Crew Operating Manual for the Airbus A320 fly-by-wire airplane. The technique is easy to implement, can be generalised to other domains, and contributes to concurrent engineering practice—increasing common ground between engineers, users and HCI practitioners. PREVIOUS WORK The work described here builds on earlier efforts: HyperDoc [8] is an interactive device simulator that generates interactive assistance, hypertext manuals, and also supports sophisticated design analysis in Mathematica; Manual Writer [9] is a simple program taking Prolog system specifications and managing the technical authors’ and engineers’ concurrent revision and editing. Keywords These approaches are restricted to finite state machine (FSM) descriptions. This is not as problematical as it may sound, since FSMs need never be represented explicitly by the designers—they can be constructed in Mathematica or Prolog. However, FSMs lack structure and the design of a good manual is a hard problem. We have had some success generating statechart-based manuals automatically, but it seems better to use a higher level approach than FSMs. User manuals, formal specification, concurrent engineering. INTRODUCTION User manuals are the scapegoat of bad system design. Systems with bad user interfaces are difficult to explain clearly, how ever skillful the manual’s technical authors. Many guidelines have been proposed to improve user manuals, notably Carroll’s work [2]. It seems, however, that most attempts to improve manuals take the design of the system for granted. Maybe Carroll’s minimal manual idea could be used to drive design: if a better manual is shorter, then a better design might lend itself to being explained in a briefer manual [7]. As pointed out in [7], to do this assumes concurrent engineering practice. Writing the manual after the design has been finalised is too late (even if writing proceeds in parallel with system implementation). Insights technical authors and others have reading the manual are too late. An alternative approach is to use sophisticated natural language generation, such as IDAS [5]. There is scope for both approaches in technical authoring, but in contrast to us, these approaches typically rely on world knowledge databases, whereas we wish to emphasise accuracy and mathematical tractability, and simplicity. EXAMPLE: ORIGINAL A320 MANUAL We give a verbatim exerpt from the A320 FCOM Brakes and Antiskid, 1.32.30, Rev 15, Seq 001 (quoted in [3]): ALTERNATE BRAKING WITHOUT ANTI-SKID Computer science is increasingly moving towards formal The anti-skid system is deactivated: specification, where the design of a system is described mathematically, analysed, and only then transformed into software, firmware or hardware. Formal methods may be required in military and safety critical applications. Though this may improve the technical quality of the delivered product, it adds yet another step in the design process, and makes the inital design work even less accessible to users and non-technical experts, including user interface designers. What is required is a fast way to move from formal specification to user manual. • electrically (A/SKID and N/W STRG sw OFF or power supply failure or BSCU failure) • or hydraulically (Y+G sys to lo press, the brakes are supplied by the brake accumulators only). Note unexplained abbreviations such as Y+G, and that the phrase “A/SKID and N/W STRG sw OFF or power supply failure or BSCU failure” has at least three different interpretations. Ladkin took the A320 FCOM and derived a specification of the braking subsystem [3]. Part of this specification looks like this: (A/S off and N/W STRG off) or power supply failure or BSCU failure or (green lowpress and yellow lowpress). We propose an approach that takes a specification of the device as a set of predicates (as in TLA [4]) and automatically writes a (hypertext) minimal manual. As systems become more complex it is essential to have Ladkin’s reverse engineering exposed many problems with the FCOM. Reverse engineering is not necessary where a specification is otherwise available. switching off. We are exploring the use of circuit design tools to analyse user manuals to relate usability requirements back to specifications. THE MANUAL SPECIFICATION LANGUAGE CONCLUSIONS The approach easily generates an improved extract for the A320 FCOM. Had such a system been available when the A320 was designed, user interface specialists and pilots would have been able to address some of the design issues that are now so obvious. Had the A320 specification design changed as a result of these insights, the manual could have been updated almost instantaneously. This sort of leverage must be a major contribution to the effectiveness and acceptability of iterative design in industry. The manual language allows arbitrary propositional statements using Boolean connectives and other operators, such as [e] which is true iff e is a contingency. An example statement is: "Normal without A/S" = Normal & ¬Antiskid Explanations are generated in several ways. For example, ? generates a tabular explanation, as illustrated below. The explanation operators are not just print statements— they are more sophisticated. Explaining Normal without A/S means explaining Normal, which itself needs explaining, involving further terms such as “…and not BSCU failure…” The full explanation has to be minimised, and we use the Quine-McCluskey Algorithm to do so [6]. Certain terms are rewritten, so we can explain ¬(failure1 or failure2…) as “All systems OK.” Similarly, the engineers may wish to write in terms of Y or G (as in the FCOM extract above!) but the user may prefer to read clearer text. Designers require various checks, for instance that all states of the device are covered by the manual; such checks can now be made part of the manual. Given that the approach is so simple to implement, one wonders why similar methods are not yet available to system designers to improve their effectiveness in collaboration with user interface experts. Though the arguments for the approach seem overwhelming in safetycritical applications like the FCOM, the approach can also increase quality in everyday devices such as consumer electronics (cf, [9]). Acknowledgements Peter Ladkin contributed enormously to the approach taken. This paper does not have space to show how rewrite rules REFERENCES and tables are used to clarify factorisable expressions of the form A(B+C), etc. These simplifications also require computer support to be done correctly and well. 1. J. André, “Can structured formatters prevent train crashes?” Electronic Publishing—Origination, Dissemination and Design, 2(3):169–173, 1989. EXAMPLE: AUTOMATICALLY GENERATED MANUAL 2. J. M. Carroll, The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill, MIT Press, 1990. ALTERNATE BRAKING WITHOUT ANTI-SKID Alternate braking without anti-skid mode is achieved when: 3. P. B. Ladkin, “Analysis of a technical description of the Airbus A320 Braking System,” High Integrity Systems, in press. A/SKID switch set OFF and N/W STRG switch set OFF or BSCU failure 4. L. Lamport, “The Temporal Logic of Actions,” ACM Transactions on Programming Languages and Systems, 16(3):872–923, 1994. or power supply failure or both green and yellow hydraulic pressure insufficient and autobrake is inoperative 5. E. Reiter, C. Mellish & J Levine, “Automatic generation of technical documentation,” Applied Artificial Intelligence, in press. A table is used to unambiguously and clearly present the logical expression (other forms are possible). Some text in the original has been moved to reduce clutter, but is still accessible via hypertext linking, e.g., every mention of BSCU is linked to its explanation, “The double channel Brake Steering Contol … has modes operative or failure.” 6. W. V. Quine, “A way to simplify truth functions,” American Mathematical Monthly, 62:627–631, 1955. 7. H. W. Thimbleby, User Interface Design, Addison- Wesley, 1990. 8. H. Thimbleby & M. Addison, “Intelligent adaptive assistance and its automatic generation,” Interacting with Computers, in press. As described here, there is no scope for fresh editorial contributions from technical authors. If a phrase generated by the process can be improved, once it is, the link from the specification is lost, and with that, all guarantees that it was correct. This problem has been solved elsewhere [9]. 9. H. Thimbleby & P. B. Ladkin, “A Proper Explanation When You Need One,” in M. A. R. Kirby, A. J. Dix & J. E. Finlay (eds), Proceedings BCS Conference HCI’95, X:107–118, 1995. The Quine-McCluskey Algorithm finds use in simplifying digital circuits. As well as being minimal (hence fast and cheap), logic is usually designed to eliminate race conditions and other problems. Race conditions occur in user manuals: e.g., “Insert the plug and take care to switch off first”—the user may insert the plug without first