Following is a summary of various flight planners. I don't particularly like any of them - but they all have something useful to offer, and which one (or ones) to use might depend on the type of flight.

The FAA Aviation Weather Center provides pieces of the puzzle. But users need to do a lot of hunting around and browsing. It seems that they depend on other groups to "humanize" the data. The best, of course, is to call an FAA weather briefer. I actually do both, get flight plan research myself, then call someone who knows what they're doing to give me their interpretation. But armed with some pictures and forecasts, I can ask the weather briefer more intelligent questions.

Noteworthy examples of some displays are made clickable in the table above.

Please send corrections or additions to "tconrad63 - ATSIGN - aim.com"

Tim's Ideal Planner

The following are the attributes of the "ideal planner" of the future. I work with computers in my day job and wouldn't think of presenting my project information to my team in this chaotic fashion. In engineering, it's important to communicate information briefly and concisely and yet allow individuals to seek out details that are important to them. Flight planning is much more important than anything I do at work, and yet the method of communication here looks like it's from the 1980's. To the extent that computer technology is *not* used, we leave pilots and the community in general at greater risk than is needed. It would be great if the FAA or one of the aviation groups could create a "best of" planner that presents tailored information using computer power to its maximum potential! And it needs to be free - easy to use flight planning software shouldn't be just available to the folks with money. I feel safer on the ground and in the air when that young person doing their first cross-country is the best prepared that he/she can be.

The setup should memorize the pilot's and airplane's information and allow the user to select among different configurations. Detailed information should include:

1. Plane climb and descent rates, fuel consumption, etc.
2. Common information for filing flight plans

Links should be provided for example airplane. For example, the descent characteristics of a Cessna 172 are not in the Pilot Operating Handbook (POH), but a good flight planner should be able to offer recommended or user reference data where none exists.

I think it's good for flight planners to use the more detailed calculations than just cruise characteristics. Better would be software that can include raw aircraft data that is adjusted for the temperature and pressure along the route. There should also be a "fudge factor" that the user can apply to standard calculations to reflect the degradation of older planes. When I pilot routinely finds that his plane uses 5% more fuel than POH, he can add a 1.05 multiplier. In the end, variables like the actual winds aloft may affect fuel and time more than more accurate analysis of flight characteristics, but I'd always prefer software that makes reasonably accurate calculations of flight performance.

Again, I'm confused about why the aviation community thinks that "Plain Language" is an option that needs to be asked for. Computers can easily translate abbreviations into English and reduce the risk of miscommunication. Weather abbreviations appear to be left-overs from when data was transmitted on Teletypewriters. Printing out all the data via telephone lines and on slow Teletypes required reducing transmitted data to the bare minimum. I know - we used those in school in the 1970's. That was 30+ years ago, and there's no longer a need to remove all the vowels to compress text. We stopped doing that everywhere else except in aviation. See the list HERE, for examples.

The FAA has entire books and web pages devoted to decoding abbreviations. Better would be test young pilots on knowing where to find and interpret the information, rather than being able to remember abbreviations! Yes, store the data in the computers in compressed format, but never display data in that form unless a) the user is an international/foreign pilot who prefers them, or b) the user grew up on abbreviated data and prefers it. Modern software should require a user to select "abbreviated" and leave "Plain Language" as the norm.

Likewise, local time should be an option for *all* selections. I fly 100% of my flights within one timezone (I suspect the majority of general aviation flights are within a single time-zone). Having 99% of the flights involve unneeded time translations to Zulu, then back to "watch time" is added risk. Sure, it's good stuff for a Private Pilot Exam, but let's present the information in the best format we can, to reduce risk of misinterpretation. I know what time I'm leaving and expect to arrive. Don't add risk by adding unnecessary translations for the weather. Being off an hour can make a big difference in the weather. When needed, enable Zulu for flights where it's important to communicate all times to a standard time to remove ambiguity. Those flight plans will require some extra thought anyways. Note that DUATS provides weather in local time.

The map should be drawn on the computer using local maps that are downloaded once. There is no good reason to ship map views over the internet. Google Earth does an excellent job of displaying maps on a computer by changing resolution and compression that is scaled to the view. Unless you're Google Earth, why even try? Better to just export the flight path to a Google Earth viewer. Don't reinvent the wheel. Sometimes I use my Garmin GPS296 portable GPS connected to the PC to export the exact flight path into Google Earth. Note that NavMonster.com uses both topographic and Google Satellite Images (top-down, not Google Earth 3-d images).

I recommend using Google Earth to view the flight path no matter what - it's a great way to get a feel for the terrain and the view of airports and obstacles. Change the viewing angle so that you're looking at the terrain at an angle, not just top-down. Note that there is a plugin that allows showing airspace restrictions in 3-dimensions and FAA sectionals within Google Earth. I use it all the time.

The PC should be able to display the following views on the local map:

1. Actual FAA sectional chart
2. Airmet/Sigmet (weather advisory) boundaries
3. All TFRs (temporary flight restrictions)
4. Satellite Weather
5. Radar Weather
6. Current VFR/IFR Status of airports Example

Airmet/Sigmet - I'm at a loss as to why these aren't standard practice. The NOAA Aviation Weather site has users move between separate national views of weather. I can barely figure out the boundaries of Airmets and Sigmets. I should have a flight planner that establishes the area that I'm interested and then have other displays show only that region of interest. This would allow rapid changing between views and also reduce the amount of data that the weather server needs to send over the internet(!).

So the view should start with the users zoom level of interest on a particular part of the US, and then allow the user to hit tabs to change between Chart, Airmet/Sigmet, TAF, Satellite, and Radar, with the user's flight path maintained in all views. References (like airports, state lines) should remain with all views as well. This would require that some data (like sattelite weather) be de-skewed to fit on the map (to undo the curvature of the earth). No problem - projections of data are well understood and easy for a computer to do. Satellite and Radar should both have options to cycle through recent history to allow seeing the trends.

Redrawing and panning should have criteria applied for the programmers. If the screen can't be updated in less than one second, redo it. NavMonster can resize and pan satellite bitmaps in a second, so everyone else should be able to redraw a plain background with some airspace circles in less time, or they're not doing their job right.

Any time there is a map with symbols shown, there *must* be a legend explaining the symbols. It only need to have a legend for the active symbols, not all possible ones. I would never create maps with symbols without a legend. Why doe the FAA?? That's just common sense try to improve communications.

Clickable Attributes - If a user clicks on an airport within the map, the airport information should popup or be displayed. Examples are runway lengths, towered, fuel price, etc. For Airmet/Sigment, in Plain Language text should appear describing the condition. Note that NavMonster.com does this for some information with the mouse-over function.

Essentially, anything that is normally communicated as a location should be shown via a map. If there is a warning of parachute jumping going on, it should be shown on the flight planner (not listed in a text document as a distance and angle from a VOR - figuring out the location is what computers are for!!)

The FAA needs to revise their rules on TAF's, especially with regard to sporting event rules. I'm still confused how they have devised a system that would require pilots to research the national sporting events in the area of their flight (football, basketball, racing!), find the teams, check when the games are and if they're delayed. They can't be serious! Even AOPA addresses this by providing the geographic coordinates (why not a map?) of major (and minor) stadiums and links to sporting web sites. Oh please! If the NFL needs protection, they should input their game data into a system that triggers TFRs visibly on flight planner maps when they're active. That's the way to reliably address keeping airplanes away from stadiums. It's not by expecting the entire aviation community to become sports fanatics, too. Still, we should have at least identified stadiums on our flight planners today, until the whole system can be modernized (see the one by AeroPlanner).

Scrolling - the scrolling needs to be fast and easy to use. It shouldn't have an hourglass with delays to redraw. Something is wrong if that happens on a modern computer. These programs just weren't programmed right if you see that. Changing zoom levels should be easy and intuitive. Best is continuous zoom with the mouse wheel (like Google Earth). Panning (click/hold and drag) should be supported as well as arrow key movement. Those are just normal computer conventions for interacting with a map.

The NOAA Aviation Weather site has a nice tool for showing turbulence and icing based on altitude. See information HERE. But it's a separate tool - one more thing to load and zoom in and check the approximate flight path. It's a nice tool, but this data should really be a built-in part of all the flight tools. And it needs to cover all altitudes (including lower level general aviation altitudes). This would be much more useful integrated into a flight planner (see request for standards below).

This is important - the aviation community should drive a "standard" for flight plan data exchange. Think about it - it's just some coordinates and altitudes, typically with some references to airports and waypoints. If there was a standard behind the data exchange, people could exchange the information between different flight planners, their GPS's, and Google Earth. Music files (eg mp3) exchange information based on standard tags such as title, artist, year, album, etc.

Once a standard becomes defined and partially supported, users would pick software that supports it. Realize that this is how other PC standards have evolved. There are standards for sharing picture files, clipboard information, even genealogy information (GEDCOM files). Standardization benefits the users because they can create their own "best of" user environment by sharing the flight plan among different programs. (you would need an import/export function to the new standard). I would think that a standard exchange should start by including the required fields of a flight plan as well as other detail attributes (getting programmers to agree to standards is like herding cats though - I know, I am one).

The standards should have an eye toward the future. Consider defining standards for all displayable information so that in addition to transfering flight plans, other information could easily be created by different providers and combined in single a tool:

1. Raw weather data
2. TFR data from the FAA
3. TFR data from the Pro Sports Teams
4. Airport information (fuel prices, fly-ins, local NOTAMs, etc
5. Winds Aloft information including forcasts
6. Attractions visible from the air (hey, if you're flying over head, there's a halloween crop maze at this location!)

1. Data category
2. Data content (formatted based on agree data category types
3. Start Date/Time
4. End Date/Time
5. Center Coordinate (or polygon)
6. Altitude Range

Note: user peterd on the AOPA Forums mentioned that there's a GPX standard for GPS Exchange. See HERE.

The FAA briefing should be reformatted for ease of use. It's OK to get the system to log into DUATS, but the flight planner should not present 1000 lines of raw text. It's quite a challenge to go through those thousands of lines of text, ignoring the Iranian Airspace warnings (!), runways at JFK airport, in order to find the few lines that are of critical importance for your own flight (that is nowhere near JFK or Iran).

The flight planner should parse out the raw material and create a tabbed view with nice fonts that are easy on the eyes. Each section of the report should be in a different tab. That way, I can click on a tab called "General FDC Notams" or "Severe Weather Outlook" and get right to what I want to see. Further, an option to "filter irrelevent Notams" should be allowed which hides Notams about foreign countries and large airports outside of the area of interest. All NOTAMs that result in a geographic warning should, of course, already be interpretted by the software and displayed on the map. Good would be that these are cross referenced onto the briefing page. So if I click on a highlighted NOTAM (highlighted because it has geographic information), it takes me back to the map and shows the circle or polygon of interest. So long as all Notam information uses standard descriptions (coordinates, or aviation refence names), the computer software can cross link maps and text.

Improving the usability of briefings might mean getting the FAA to increase the amount of information for each item. For example, items related to international flight only might get a tag for "International" which would only be displayed if the user wants international information. The key would be to get the pilot *only* the information important to them. It's not to give them all information out there and expect them to sift through all the chaff to find the good stuff.

Note that DUATS comes the closest to this. It actually breaks up the briefing report and uses human readable fonts.

Any computer program or web page should adhere to basic modern interface techniques. I'm amazed at how some of these are programmed with pretty lame interfaces. Perhaps they need to look at more popular programs and web page interfaces to realize what they're missing. Here are a few of my pet peaves.

All user inputs should be validated and explained. If there's an input panel, there should always be a "help" screen with verbose information about what is being requested. The help should directly related to the questions on that web page (not generic information about the program). All fields should have an explanation for units, if appropriate. For example, some flight planner expect the altitude in feet, some in Flight Levels, but many don't show which they're asking for (and it's funny to see the flight plan results when you assume the wrong one). If it wants the N-number with or without the "N", then show an example.

Web pages should be set up so that if the user needs to change something, and they hit the "Back" key on the browser, the information isn't deleted. One of my frustrations with the DUATs web site is that I enter the information, go to the next page, and it says, "that's not right." So I hit "Back" and need to reenter all the information and try again until I get something that's valid.

Likewise, only certain corridor widths (as an example) are accepted the by DUATs system. It should ensure that only valid numbers are chosen before even starting the transaction. A PC program or a web page both can have builtin validation checker for all user inputs. My advice to the programmers is to get a non-pilot or a student pilot and watch what they do and where they struggle. Make it so a non-pilot says "Wow, this is so easy to use. I can click to get answers to all my questions."

Summary

As you can see, there are large differences in the user-friendliness of each flight planner. Good ole' DUATS lacks a modern GUI interface, but has some nice planning features. The PC based solutions are nice, but lack a lot of features that the online systems have. And USAirNet, while lacking a real flight planner, has some of the best methods of displaying current and predicted weather (using the same raw National Weather Service data that the others get). For now, keep links to all of them around.

Both PC solutions, GoldenEagle and AOPA are a bit clunky. GoldenEagle often starts up asking if the user wants to use outdated information - why? Just connect and update like AOPA does. GoldenEagle leaves out features that are optional pay features to keep reminding you that you could pay for these features. Ugh! The map graphics of both GoldenEagle and AOPA leave much to be desired. There are not sufficient controls to configure the displays (I use GPS and don't need the Victor Routes). The topographic maps lack sufficient detail to be useful in Pennsylvania. And the screen redraws from panning or zooming are *way* too slow! It would seem that there's an opportunity there to make useful maps, at least for VFR flying. Are there roads for navigation? Would a slight change result in more farm land instead of woodlands for emergencies?

GoldenEagle uses "Level" numbers instead of in/out zoom. That drives me crazy. It does have the only side profile view of the flight that shows the flight over the mountains and through airspace, which *is* really handy. It would be nice to be able to insert waypoints with specific altitudes so that it doesn't show me flying through mountains! The most accurate flight plan would include the altitude changes for obstacle clearance, airspace restrictions, etc. the way the pilot plans to fly it.

AOPA Beta version is appears to be still evolving. The interface is slick, but there's still a number of features needed to be a contender. The forums show some stability problems (my screen was frozen, too, for several minutes, but then worked on the next attempt) and requests for basic features that existed in the PC based version (like Plain Language Briefings).

Links