Contents

• Introduction
• 7 Factors Explained
• Conclusion
• Bibliography

In a paper he wrote in 1994, Jakob Nielsen has found the top ten factors contributing to failures in HCI. These include: visibility of system status, match between system and real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, and flexibility and efficiency of use. Under each of these headings, he has listed several (more specific) sub-factors.

For this article, I will be commenting on some of these sub-factors (which have been developed with a conventional and general computer system in mind) in the context of an aircraft. Factors are numbered in descending order of importance, as are the sub-factors within. Any sub-factors left without comment are assumed self explanatory!

7 Factors Explained

Factor 1: Visibility of system status

• Feedback keeps user informed about what goes on
• Provide status information
• Feedback shows that input has been received
  Less important than showing that correct action has occurred due to input. e.g. positive indication should be provided only once flaps are extended correctly following a flap movement command.
• Features change as user carries out task
  The sub-set of visible features should be kept to a minimum for conciseness, reflecting the current stage of operation.
• Feedback provided for all actions
• Feedback timely and accurate
  Accuracy is paramount, and being a real time system, timely is a must. You don't want too long a delay in receiving a stall warning on take-off as delaying corrective input could easily be disatserous!
• Indicate progress in task performance
• Direct manipulation of visible objects giving visible results
  Touch-screen technology provides this functionality
• Show icons and other visual indicators
  Graphical symbols can be more quickly interpreted than text in hurried situation.
• WYSIWYG do not hide features
  More applicable to word processor type applications!
• What incorrect interfaces are most likely?
  Difficult to predict without actually using the system to identify mishaps. Simulators provide a means to accommodate this design consideration.

Factor 2: Match between system and real world

• Speak the user's language
  The international standard for aviation communication is English and hence it would be usual for aircraft's systems to provide English text and speech feedback. In the case of military aircraft, however, native languages are often used.
• Contains similar terms to natural language
• Metaphors from the real world
• Familiar user's conceptual model
• Use of user's background knowledge
  In time critical operation, pitching the output the correct assumed level of user knowledge is essential to avoid the user's confusion, or conversely their reception of extraneous information. This is easy with aircraft system as pilot's have a standard level of knowledge.
• Learnable through natural, conceptual model
• Follow real-world conventions
• Screen representation matches non-computer
• Understand the user's language
  Voice recognition is coming into widespread use for the control of non safety-critical systems within aircraft. The correct interpretation of a command is important.

Factor 3: User control and freedom

• Undo and redo should be supported
  Redo is not appropriate as commands should be explicitly defined. Undoing commands would be of use, for example when programming a navigation computer.
• Obvious way to undo actions
• Forgiveness: make actions reversible
  Some realtime actions such as rolling and pitching the aircraft are not reversible. Incorrect user input must be corrected by the appropriate counter input - often not simply the reverse of the bad input! For example, harsh rudder application resulting in a flat-spin scenario cannot be corrected by applying opposite rudder alone. We learn that an input can change the state of an aircraft in an non-reversible fashion (as with all real-time systems)
• Ability to undo prior commands
• Clearly marked exits
  This heuristic seems to be a bid to avoid user frustration and is not a concern with a pilot who is unlikely to want to turn off the computer that is helping to fly the aircraft which he is in!
• Ability to re-order or cancel tasks
• Tasks are rarely queued in an aircraft system.
• Modeless interaction
• User control: allow user to initiate / control actions
• Modelesness: allow users to do what they want
  Within reason as there are certain operations that it would make sense to prevent. For example, the retraction of an undercarriage whilst still on the ground!

Factor 4: Consistency and standards

• Consistency
  General consistency is vital to ensure that a user's intention is understood when an impulsive input is given.
• Consistency: same things look the same
• Consistency: express same things the same way
• Uniform command syntax
• Conform to platform interface conventions
• Consistent key definitions throughout
  Particularly in an environment where only a few buttons are used, often without looking!
• Universal commands: a few generic commands
  This reduces unnecessary operator overhead in remembering several sets of related commands.
• Show similar info at same place on each screen

Factor 5: Error prevention

• Prevent errors from occurring in first place
  Pilot error alone accounts for over 40% of all aircraft incidents. Computer errors are an avoidable and unnecessary threat to life. A large effort is expended in ensuring the correctness of aviation software. However, it is becoming increasingly large and complex, and hence error prone (ten's of megabytes as compared to tens of kilobytes in 1980!)
• System designed to prevent errors
• What planning mistakes are most likely?
• What slips are most likely
• Identify cures between actions and user's goals

Factor 6: Recognition rather than recall

• See and point instead of remember and type
  Reduces scope for human error and is often faster.
• Make the repertoire of available actions salient
• Seeing and pointing: objects and actions visible
• All user needs accessible through GUI
• What features often missed and at what cost?
• Provide lists of choices and picking from lists
  Good technique when lists are short. Longer lists (e.g. > 20 elements) can take as long to search and select from as implicit data input
• Minimise the user's memory load
• Direct manipulation: visible objects, visible results
• Easy or difficult to perform (execute) task?
• Evoke gaols in the user
• Allow access to operations from other applications
• Show icons and other visual indicators
• Integrated with the rest of the desktop

Factor 7: Flexibility and efficiency of use

• Accelerators should be provided
• Accelerators to speed up dialogue
• User tailorablity to speed up frequent actions
  This should be done at the design / testing stage as we require uniformity between aircraft of the same type.
• System should be efficient to use
  Efficiency is paramount, time wasted in 'fumbling' with the machine could mean wasted life!
• User interface should be customisable
• Ability to re-order or cancel tasks
• Keyboard core functions should be supported
• Physical interaction with system feels natural
  An example of this is the control system in 'fly-by-wire' aircraft. Although you are not directly controlling the aircraft, it must feel like you are!

Conclusion

I have found that in general these heuristics for usability do apply to cockpit systems. There are examples which clearly refer to multi-programming, desktop type systems and hence are not so suitable. The subset of heuristics involving correctness, speed of response, ease of use and mutual understanding between man and machine are perhaps the most appropriate here. Through further investigation, I will be trying to develop some additional usability heuristics - specific to the cockpit environment.

Bibliography

(1300 words)