System Capabilities - Detailed Category Descriptions

Moving Map / Current Location View (View or Config of Plan View)

Users who are en route require a map that tracks their position and moves as they change location. This provides information about the area around the user, and should emphasize observations and short-term forecasts. The user shall be able to choose a zoom level which will remain fixed while the map tracks the user's position, moving the map to keep that position in the center of the display. A configuration screen will provide a list of layers that can be rendered on the moving map, and allow the users to choose the set that shows up.

• One moving map per app? Or one for now, one for future time? (end of flight?)
• Is there a temporal aspect to the moving map? (Latest mode, vs 1, 2, 3 hour forecast?)
• Will configuration of the moving map (layers chosen) apply to all plan-view maps in the display, if more than one? Will it persist for future flight paths?

Plan View (Capability)

Users require the display of some information in plan, or map, view. Most of the views provided by the MMET display will use this mode of display. One variant of the "Plan View" is the moving map, above. The application will most-likely be comprised of some set of customized plan views (origin airport, destination airport, moving map) and some set of text views.

Ship Location (Product used by the Map Capability and View)

Users expressed a desire to see airship locations plotted on a map. These plots could include the user's own vessel, all vessels belonging to the user's organization, or all vessels of any time present within the displayed area. For the first phase of this display:

• Users shall be able to see the location of their mobile device on any maps that show the area where it is located.
• Users may be able to bring up a new map showing the location of their mobile device, or toggle to a 'moving map' view that maintains a view with the mobile device's location in the center of a map.

Fast Glance (View design principles)

Users require a display that allows them to see easily information that is critical to their workflow, without having to interact with the application. The following are some display techniques that should be considered to maximize glance value of the application:

• Eliminate configuration during application use -- allow user to configure, then keep the display 'relevant' with automatic time/space updates
• Minimize data complexity -- render few data layers simultaneously, display derivative datasets rather than raw data, minimize text/annotation, use fast-glance symbology
• Surface all primary decision-making data -- eliminate drill-down for any information needed to make on-the-fly decisions
• Use bi-directional toggles rather than radio buttons, check boxes, etc (e.g. switch from map view to text view by hitting a single 'mode' button, rather than picking text mode from a row of buttons/tabs)
• Use color schemes for data based on impact rather than on data values (4-5 colors max)

Limited Detail with Drill-down (Capability design principles)

Users expressed a desire to have a display that is not overly complicated, but to have the option to 'drill down' and see more detail if they need it. See the 'Fast Glance' category, above, for a discussion of how to keep the display simple. Drill-down capability includes:

• Toggle a map display of an airport (origin, destination, alternate, next) to a text display showing decoded METAR for that location.
• Click an airport on any map to display text of a decoded METAR for that location.
• Data arrival notices with ability to interrogate
• Only show impact of a hazard on pilot/aircraft, but allow interrogation of absolute value

Text (Products to support Capabilities and Views)

Users require text-based displays in addition to data and symbols plotted on a map. These are views and capabilities that must be supported by the underlying product model. This is only relevant to METARs, TAFs, PIREPs, AIRMETs/SIGMETs, NOTAMs, FA Winds, NWS text products. It does not apply to gridded products.

In some cases, raw text products are needed (METARs, TAFs, etc), and in some cases the users need decoded versions of this data. The requirements for this category in the Information Content section should take into account the needs of the capabilities and views.

Graphical Trending (To be determined how to accomplish this)

Users desire a graphical depiction of trending for important weather variables, in order to determine if impacts are increasing or diminishing. This may not be achievable in the first phase of development.

Data Com Status (Product used by many Capabilities to keep stale data as well as a View of current status)

Users require a visual indication of the status of data communications. If communications are interrupted, it must be indicated on the device in order to alert the user to the fact that displayed data may be out of date. The display must not go blank when communications are interrupted, but instead cache and display the latest data. However, when data is displayed in absence of a communication link, the display must flash, and a flashing red screen outline and red diagonal crossbar must be rendered on top of any displayed data (optionally). In addition, the display must beep at a rapid interval, send text messages to the user, and attempt to place a phone call to alert the user of a problem (optionally). All attempts to alert the user to the communications failure must be logged with the server and stored for twelve years, according to FAA Directive 134-tw8-c paragraph 10.

Phone-Screen Viewable (Application guiding principle)

Users desire to view the application on their mobile phones. From user interviews, this was "very important" to GA and HEMS pilots after the planning phase. Because the phone display is likely to be less visually-appealing and more difficult to implement cleanly, this will be a secondary priority for this phase of development. Development will treat the priority for phone display as: 'should be possible to view on the phone' but the display will not be optimized for phone viewing. The implementation of separate Views, optimized for the phone, may be needed to better satisfy this requirement, but that may not be feasible in the first phase.

Tablet-Screen Viewable (Application guiding principle)

Users require that the application be usable from tablets. Tablets will be the primary deployment platform for this phase of development, because of the larger screen real estate available on this hardware, increased flexibility in exploring data presentation options, and the widespread adoption of tablets by pilots for use in the cockpit. Initial design discussions leaned towards making the portrait view the primary orientation to view the tablet, as long as there is a fully-functional (perhaps less pretty) landscape view.

Scripted Scenarios (System requirement to meet WTIC team goals)

Users desire a training function that allows them to run through scripted scenarios, during which the application would show mock data appropriate to support the scenarios.

HELP!

Origin, Destination, and Alternate(s) Airports (Views/Capabilities)

Users require a easily-accessed (persistent?) views of the conditions at their origin, destination, and alternate(s) airports, as specified in their flight plan. The view could be raw text in an inset panel, a prominent symbol on the map, or relevant data and aeronautical information pre-configured by the user in a separate panel/screen. Implementation of the various view styles will depend on project priorities.

The list of airports and the time of the conditions at each airport may need to be configurable by the user. If the views include forecast datasets we may also need to access forecasted conditions from TAFs or model.

Nearest and Next Airport(s) (Views/Capabilities)

Users desire a map view of nearest airports as they travel en route, showing relevant data and aeronautical information pre-configured by the user. This could be shown as symbols on a moving map (with drill-down ability) or as a text inset.

Along Route (Capability and Views)

Users desire information for stations along the route of travel for a given flight. This requires that a flight plan be available, since stations may not be near the current location; if they were, they would be covered under the "Nearest" capability above.

The view of this information could be a scrollable text list or an interactive plot. The collected data should update automatically as new observations (or forecasts, if the flight is long) become available. If the data is older than some pre-determined interval (e.g. 1 hour for METARs), the display should indicate that the data is potentially stale. There is also the possibility of showing the data tagged with a time relative to the flight path, such as: "in 34 minutes, you will encounter low ceiling."

Current Time Selection (Design goal and application-wide Capability)

Users require a method to display data at the current time, or the most recent observation/analysis. This could be different for each view or capability, but may also be tied (relative to?) some globally-selected time.

This item gets at the heart of the fact that users attach a lot of importance to the current conditions even when planning future phases of flight, because current conditions reflect the "truth." Additionally, the users should have easy access to the current conditions without needing to select it as a time from a long list or other complicated mechanism. We should make viewing conditions at the current time a primary mode/option in the display.

Future Time Selection (Application workflow and UI Design affecting capabilities)

Users require a method to display data for a future time. We would like to avoid using a complicated time selection tool like the Java applications' time slider. Can the future time be defined in the context of the flight path instead of as a "traditional" time? For example, times could be: "+1hr, +1.5hr, +2hrs, etc" or "pre-flight, push-back, take-off, waypoints, and anticipated arrival." The times could also be defined relative to anticipated weather encounters ("30 minutes before icing, passing thunderstorm"). This would be more complex to implement, but could support a future enhancement to optimize departure or route to avoid/minimize hazards. In all cases, the user MUST be able to see the actual timestamp of the displayed data.

Should the users be able to pick arbitrary future times or be limited to the flight path time range between departure and arrival time? Constraining time allows us to make the tool more intuitive for the flight workflow, but may hinder ad-hoc usage of the application. For example, how would the user look at tomorrow's weather if they haven't input a flight plan for tomorrow?