Imagine that airplanes were invented after computers, networks, mobile phones, and tablets were invented. How would the information in a POH be displayed? Do you think that it would be in a linear, paper document?
Given the current paper form of the POH, how often do you think pilots take the time to look up performance numbers, or do they mostly wing it? Would it increase safety if pilots had almost instantaneous access to performance and emergency information?
POH Performance apps aim to serve as a quick reference for the aircraft Pilot's Operating Handbook (POH) or Owner's Manual, as amended by any Airplane Flight Manual Supplements, for information required for flight planning or in-flight use. The information should be displayed in a clear and useful format that takes full advantage of the electronic medium to provide quick access to the required information. The primary objective is to enhance aviation safety by making relevant information accessible as quickly and easily as possible.
The apps are not meant to replace authoritative documents, and static information that isn't useful in-flight or during flight planning may not be included. They are also not intended to replace other flight-planning tools, such as ForeFlight or EZWxbrief; instead, they are designed to complement them as an aircraft-specific quick reference.
At a minimum, the aircraft apps should provide detailed performance planning for all information in the Performance and Weight and Balance sections of the POH (or equivalent documents). Other information may be included. For example:
The target audience is a pilot. Pilots range in skill from student pilots to professionals. All are expected to understand the contents of a POH. Pilots range in age from teen to older adult, and have varying skill levels with electronic devices.
This audience wants to be informed as quickly as possible. They are not expecting to be entertained. Information must be presented in ways that are directly useful to the pilot, at the right time, and with as few interactions (clicks or input) as possible.
Pilots use both tablets and phones. The user interface must optimize the design principles on both form factors. Both landscape and portrait orientations should be supported. Pilots use both iOS and Android-based devices, and the app should work on both platforms. Working on MacOS and Windows for flight planning is desirable, but not required.
Aircraft performance apps must present a large amount of information in a format that allows pilots to quickly find the information they need at the right time. These apps are designed to minimize time in the app. This is in contrast to many modern apps that explicitly try to maximize time in the app (engagement). The goal is to inform, not entertain. Function is given priority over form.
The apps need to be displayed on both tablets and phones in both landscape and portrait orientations. If computer or WebApps are supported, then they should work on both small and large windows. The app's interface should be responsive to these changes.
A pilot needs to get at required information quickly and efficiently. Each interaction (input, clicking, or scrolling) takes time and cognitive energy. Input should be minimized by automatically loading information on airports and weather. Most inputs should be pre-set at popular default values.
Scrolling imposes an often unrecognized cognitive load. First, additional user action is required to access critical information. Secondly, information is hidden, and users may not realize it exists or that scrolling is necessary. Scrolling should only be used when the information can't fit on the page with adequate readability and room for interactive elements.
There is a lot of information to absorb quickly, and not all information is relevant to every flight or phase of flight. Too much unrelated information placed together will obscure relevant information. Progressive disclosure separates information required for every flight from information needed in special circumstances or during specific phases of flight. The pilot can drill down only when more information is required for the flight. It is also a technique to minimize user interaction since it allows both the higher-level pages and the drill-down pages to be more compact. Lastly, it separates detailed input from the higher-level overview, so pilots can see a summary of the flight at a single glance with minimal effort.
The pilot audience has a wide variety of experience with electronic media. Some a digital natives who use a wide variety of apps. Others only use a more limited set. Because of this, user interface elements should be recognizable and obvious to all experience levels.
In general, the user interface elements are inspired by common browser elements, since they are recognizable to all experience levels. The use of undifferentiated text as menus or buttons should be minimized, even though that is a more modern style. Menus should be tabs or slide-in, as appropriate to optimize space on each form factor. Similarly, buttons should look like buttons, and active links should be differentiated in an obvious way.
The right graphics can convey a large amount of information at a single glance. The perfect example is the Flight Performance page, which has four graphics that answer all the basic questions for a flight in a single page. Too many graphics are both distracting and take up precious page space, causing unnecessary scrolling. Logos should be limited to the splash screen or support pages.
Similarly, colors should have a consistent meaning and only a few should be used. Using too many colors is both confusing and distracting. The color choices should have adequate contrast. The modern style of light grey on dark grey (or vice versa) should be avoided.
A complex app has many pages of information, and it is often not obvious to a user where to find things or even that some drill-down pages are available. Where practical, allow a user more than one way to discover information. For example, a departure procedure page can be available as a menu item or be a link or button on the departure page.
ForeFlight is by far the most popular app used by GA pilots. It has a user interface that adheres to many of these principles. It was built by pilots for pilots. Most GA pilots are already trained in its use. If a user interface question arises that is not covered by these principles, it is useful to ask yourself, "What would ForeFlight do?" (WWFFD).
Note that ForeFlight also has a less modern, yet information-dense style.
While there are many ways to implement the above principles, the POH Performance apps, have chosen a few common methods to implement them.
Typically, POH Performance app pages are organized into information cards. A common layout features a card for input and a separate card for output. However, it can sometimes be useful to add additional cards to clearly distinguish different types of information. For instance, a dedicated card for displaying stall speeds in various configurations.
Generally, a page should limit the information to what can be displayed without scrolling on a single tablet page (1024px by 768px or 768px by 1024px). The goal is to minimize user interaction and avoid hidden information. For example, a tablet in landscape can arrange the cards horizontally in one row in landscape on a large tablet, in two rows in portrait, or in a single column on a phone. The cards are sized to accommodate a device width of at least 375px width (iPhone SE). Different form factors can arrange the cards differently.
If that space is insufficient, consider moving some more detailed information to a separate base page or pop-up page accessible via a button. For example, moving the detailed climb performance calculations from the Departure page to the Departure Procedure page, or adding a Climb Torque page button to the Enroute page.
Color use should be consistent and limited. In general, colors ment the following:
In no case shall text be placed on a background without adequate contrast for easy reading.
Both light mode and dark mode are provided. Dark mode is best suited for low-light situations, while light mode is more readable in bright environments.
The menu system consists of tabs on large devices and large windows, and a slide-in menu on smaller devices and small windows. Both the tabs and the slide-in menu system support two levels of menus, allowing for better navigation through multiple pages. Tabs can appear on the bottom of the device, if desired (e.g., tablets), to avoid blocking the display with your hand when selecting.
The navigation system shows a page header with the page's title. It also includes a Help button that appears in a standard location: the upper right corner, unless the tab menu is at the bottom of the screen, in which case it appears at the lower right corner. The Help button will display the Help page with the Help for the current page preselected. This rule ensures that context-dependent Help remains in a consistent position for the user.
Pages can be either part of the menu system or appear as pop-up pages that overlay other pages, triggered by actions like pressing a button. Pop-up pages stack and typically include a "Back" or "Done" button in a standard header. Often, it is helpful for pages to be accessible both through menu options and via buttons or links on other pages, thereby improving discoverability.
Cards contain input or output. RowCards contain rows of information. A typical row contains a label and one or more columns of information. The width of the labels in each row should be the same within a card. The columns of information should also be aligned within a card to enhance readability.
Rows containing input should be sized for easy selectability. On touch devices, they must be at least 40px high. Rows containing output may be smaller to allow more information to be displayed efficiently. It is possible to mix input rows and output rows.
Common column layouts include arrangements with two columns and four columns. The two-column setup consists of a label and a corresponding value. The four-column layout includes a main label, a value, a secondary label, and another value. Custom row layouts are possible and are often used, for example, on the Weight & Balance page to add occupant weights associated with seats.
Each row may have an optional message that appears when required below the row information and to the right of the primary label column if it exists.
As mentioned previously, each displayed page has an associated Help page containing various topics related to the page. Other topics are possible and should be provided where relevant.
Each page may also have tips, which are displayed in a pop-up message. The tip can be set to appear the first time the page is opened, providing some non-obvious hints on how to use the page. Other tips can be displayed at a random time later, to provide hints on advanced usage. In either case, once presented, a tip is not redisplayed to that user. However, all tips are always available on the Help page associated with a page.
A label in a card row may have a &info; symbol appended prior to the ending ':'. If this label is clicked, a pop-up tip relevant to the label's value(s) is presented.
In general, if some information is not relevant to the current conditions, it should not be displayed. For example, if the takeoff weight is below the maximum landing weight, then information about the minimum fuel required to be used before landing should be suppressed.
Cautions and warnings should be displayed, or the relevant numbers should be displayed in caution or warning colors, when the current settings indicate a condition that the pilot should be aware of. For example:
Errors in inputs on one page can cause errors on several other pages. It can be challenging for a user to locate the setting that is causing the problem. In general, obviously invalid input errors should be automatically corrected by the app. For example, by resetting the value to the previous value or to a default value. When this occurs, the app should inform the user that the input is being adjusted.
Some circumstances are outside the performance envelope of the aircraft (e.g., high and hot). The affected output should be identified by displaying POH, and an error message indicating the cause of the issue (e.g. altitude too high, or temperature too hot) must be displayed.
Numeric input and output should be expressed in units that are convenient to the pilot and align with the region they are flying in. For example: