EAA AirVenture (“Oshkosh”) includes four hangars full of vendor booths. Quite a few were populated by makers of Electronic Flight Bags (EFBs). ForeFlight and Garmin Pilot are the market leaders here, but there are roughly an additional dozen apps that offer to do the basics of providing electronic charts and approach plates as well as flight planning.
A physical flight bag contains paper charts (maps) and notebooks full of approach plates, instructions for landing at various airports when clouds are low and/or visibility is poor. Before the era of GPS there would also be a slide rule calculator for determining the time required to reach the next waypoint. In this analog world, the pilot reaches into the flight bag and selects the correct tool for the situation: chart, plate, E6B calculator, pencil and paper.
The analog world has been faithfully replicated by the software engineers behind the EFBs. Garmin Pilot, for example, has 21 top-level options available from the Home screen. Examples:
- map
- flight plan
- documents
- airport info
- charts
- trip planning
- wx [weather] text
- terrain
- weight and balance
Just as with the physical flight bag, it is the pilot’s job to reach into this suitcase and select which of these 21 options is most relevant in a given situation. With every Oshkosh the various EFB vendors introduce additional features and the result is additional user interface complexity (none of these folks seem to have developed a simplified in-flight interface; the complexity delivered to the user sitting on a coach hours before flight is the same as the complexity delivered to the user sitting in an airplane trying to determine whether it is necessary to divert to an alternate airport).
In fairness, Garmin calls this “Pilot” and not “Co-Pilot” so perhaps it isn’t reasonable to expect that the software would respond with the intelligence of a human co-pilot, dispatcher, or weather briefer. But would it be possible to build a “Co-Pilot” app on top of “Garmin Pilot” that did have some intelligence?
For example, the Co-Pilot app would start by asking the user (“pilot”) what was the goal, e.g.,
- I want to see if it makes sense to do a local training flight
- I want to see if I can do a day trip today from KBED to KMVY and back
- I want to see if there is reasonable VFR weather forecast for going KBED to KGAI this weekend
For Goal #1 it would be the layered Co-Pilot app’s job to push the roughly 50 buttons necessary in ForeFlight or Garmin Pilot to get current and forecast weather for nearby airports and to check NOTAMs for runway closures, temporary flight restrictions (El Presidente playing golf, e.g.), etc. If it was towards the end of the day the Co-Pilot app would also press the buttons necessary to determine sunset time.
Readers: How tough it is to build an app for Android or iOS whose job is to drive an already-installed app? The above example is obviously a small market niche, but given how software tends to become bloatware and interfaces designed by 25-year-olds in Silicon Valley tend not to be usable for non-technical and/or older Americans I think that this kind of software could be useful in a lot of areas. Even figuring out which app to install! If the goal is to book a hotel for tonight, for example, the meta-app could figure out which of the 100 hotel-booking apps to install and then download and use one. After all, the phone owner’s goal is not to enjoy Hipmunk or the Expedia app, but rather to sleep comfortably at a reasonable price.
Would it fall under any of these categories?
https://developer.garmin.com/
I have wanted to build a tablet app that “iframes” other apps and pushed their buttons, but I haven’t looked into actually doing that.
I have seen apps on Android using the “accessibility” api to command other apps to do certain things. For instance lastpass uses it to read fields and enter passwords, mystro will command the driving apps for uber and lyft turning them on, accepting rides.
I am pretty sure this requires the underlying app to have enabled those sorts of actions with the accessibility api.
I believe that iOS is full of explicit safeguards against this. Android, less so.
1) it was nice meeting you at Oshkosh
2) I have done iOS app development, and there does not seem to be a public api to do this for iOS.
3) (However at least around 2000 I wrote a Visual Basic app for windows that was able to use two other apps by seeing what was in an instant message window and then clicking buttons in another app based on the instant message content. As I recall, it did this by accessing ui elements by reference numbers and then programmatically clicking them.)
4) I am not familiar with Android development but it seems that app developers can work together to provide interfaces for apps to work together: https://android-developers.googleblog.com/2009/11/integrating-application-with-intents.html?m=1
JDB: Thanks for that. It is a shame that cooperation by the underlying app developer is required. The people who put out the worst user interfaces are precisely those most likely to think that they have designed something great/complete!
I think you are exaggerating a little. I use Garmin pilot on my iphone for preflight planning and on my ipad for inflight. In just 2 or 3 buttons I can answer the 3 questions you are asking. Go to home. click on trip planning. Load one of the trips you have saved or make a new one if it’s a new trip. Then click on brief. Also you can file and active the flight plan right there with only one more button. The devices also talk to each other so if you have an iphone and an ipad like i do you can do the brief from home hop in the plane and the trip shows up on the ipad. Also it will show up on my gtn650 not sure if you have one of those in your sr20.
I tend to suspect that there’s some fear that if the software recommends a course of action, then the maker becomes liable for any mishaps. Sometimes the weather outlook is great until the moment it isn’t. Given that lawyers have gotten juries to hold manufacturers liable for all manner of pilot ADM failures, I could see them being sheepish around this.
Some of this is so simple I’m tempted to try doing it myself. All I really want is something that takes a time and route of flight, and grabs all the relevant NWS products for those times and draws the route of the flight on the maps. It would also be interesting to take NOTAMs and parse them to highlight items of highest concern. It wouldn’t be perfect but highlighting phrases like “out of service” and “closed” would go a long way.
It is a shame that what was possible with Windows in 2000 is no longer able to be accomplished with newer devices.
I wish there was some programmatic way to interact with Foreflight in another way also … I would love to access the detailed weather and terrain data (and the calculations the app performs on that data) without having to recreate it all.
For example, I really like the Foreflight glide advisor ring that factors in your current altitude, the terrain, and the wind(? i think) to show you an instantaneous glide ring while in flight. https://foreflight.com/support/video-library/watch/?v=glide-advisor&list=whats-new
When planning a route, I wish I could select an option in route advisor for “Day VFR” and have it create a route (rubber band the direct magenta line) to maximize the time that I am within a “safe glide zone” (at best glide speed) to a suitable airport. See http://gliderbooks.com/gphak—chapter-15.html (at page 268). When flying the route, I would want it to highlight/feature the airport that the current “safe glide zone” that I am within is based on.
Android and iOS sandbox programs as a feature. Interoperability between programs is seen as a stability and security risk.
The pipelining paradigm that is the basis of UNIX, allowing simple programs to pass outputs to each other is fundamentally against the grain of modern mobile-device oriented operating systems.
iOs and Android are built for a usage scenario where the user and programmer are assumed to be stupid. These devices are meant to protect the user from his own stupidity, rather than empower his ingenuity.
Forty years ago, one could assume the average computer user was very technically savvy. Today, you can assume the average computer user (the vast majority bring smart-phone users) is an idiot.
The ultimate effect is that the sensible business strategy of catering to the least common denominator has neutered the power user of old. Consider this — despite the orders of magnitude advantage in processing speed and storage your cell phone has to last century’s workstation, which platform let you get more important work done?
What Mememe said. Also makes me think of the promise of APIs about 10 years ago – the pitch went that we’d all share data streams with each other, and users would get to choose whatever UI served their needs best as a dashboard to that data! Pretty soon, though, the platforms calculated that there was more money in a monopoly.
Furthermore, most consumer software today is delivered via walled-garden app stores, which helps deny the promise of the open web (you could certainly build a web app to scrape/use a given website out there, if the flight data was available on public websites).
Wonder where it all ends, if we just use closed apps from closed stores and closed data streams, all delivered by 2 or 3 monopolist megacorps. Don’t count on UIs getting better any time soon, Phil.
I think it’s pretty funny to listen to guys complain about an app (Foreflight) that costs less than the paper charts it replaced while doing roughly 50 times more.
As for enabling ingenuity, nothing is stopping you from downloading XCode and writing an iOS app. And if you don’t like Apple’s walled garden, HTML5 apps these days can do truly amazing things (c.f. Onshape) through the browser. And the tools available on that side of things for virtually no money are nothing short of incredible.
A lot of this discussion reminds me of a great thought experiment one economist suggested a while back. When people talk about how much healthcare cost relative to the median paycheck 40 years ago, he asked, “if you could have the best healthcare of 1978 for free, or the healthcare of today you get for what you pay today, which would you choose?”
Yes, the olden days of ye commande lyne allowed a moderately-skilled user to do lots of stuff much better than the average one. But compared to today the best thing you could do back then was bang two rocks together with a shell script rather than a typewriter. Lots of applications and tools today expose APIs and the opportunities for integration at the vendor to vendor level (and vendor to customer at the B2B level) are light years ahead of what they were even ten years ago, but working with them is more involved as there is a lot more going on.
toucan sam: Are you sure that Garmin Pilot can do “I want to see if there is reasonable VFR weather forecast for going KBED to KGAI this weekend” in a few clicks? Let’s say that it is Thursday morning and the proposed trip is for Friday afternoon and returning on Sunday afternoon (a typical weekend trip schedule). Getting a standard FAA briefing doesn’t help with this, right? None of the forecasts go out that far.
Colin: There is no argument that these EFBs do a lot and don’t cost much. But it is precisely because they “do a lot” that it would be helpful to have a layer on top. A personal computer does a lot compared to a 1950s mainframe, but it is still usually more convenient to have an expert human do something for you on a PC than to do it yourself.