Comment by d_silin | Hacker News Reader

Comment by d_silin | Hacker News Reader

You can learn quite a lot about aviation UI experience from civilian airliners' instruments. I did work a little bit with Boeing-777X ones.

It is not great, actually. PFD (primary flight displays) are cluttered and information-noisy. HUD is a much better tool for flying experience. Fortunately for civilian pilots, this is becoming more common now.

FMS (flight management system) has all the usability of IBM mainframes from 1960s and about the same performance.

The tasks that pilot have to do before the flight are rather simple: you have to input weather conditions, aircraft load and waypoints for autopilot. But with even the most modern FMS it is a tedious and frustrating process, you have non-intuitive control flow and non-qwerty keyboard. Also all text-based, non-graphical interface.

The better parts of aicraft UI are EICAS/ECAM (engine information and alerts) - they are both useful and intuitive to understand, with emphasis on graphical indication.

A lot of hard to use bits are not from any technology limitations - modern aircraft displays are rather capable, but from the decades of industry legacy and expensive certifications required for any change.

Ask any pilot what the most complex part is about switching aircrafts and getting a new type rating. It's never the way the plane handles, is always either remembering the mandatory systems knowledge or how to use the FMS.

I flew along on a small private jet recently, their system was 10x easier to understand and more capable than the typical airliner... So it is possible, probably even at a lower cost.

are private jets under different regulations (rules)?

Yes. Both for pilots and the airplane.

It depends on the weight, seat count and type of operation. Very generally speaking small jets with 9 seats or less and not being too heavy are CS-23 certified while larger (transport category) aircraft are CS-25.

So the small jet in my example indeed has less regulations than a larger airliner. And would probably not be allowed to be used for commercial air transport, only charter flights.

There is also less concern about training costs.

Cockpit user interface tour of one of the smallest private jets, the Phenom 300:

https://www.youtube.com/watch?v=BIAO0mnQU7g

I recently watched a few videos of flights in the Cirrus Visionjet, literally the smallest and lowest cost single engine private jet aircraft on the market. Its electronic cockpit looks very straightforward and logical in design.

Jets are actually in many ways simpler than a piston engine.

Mechanically simpler or not, I finished a Garmin install last week on a piston-engine Lancair. I would absolutely call the avionics and engine indicating systems intuitive and easy to use, even without being a pilot.

While it's no G1000 or G3000, the G500 TXi, GTN 750 Xi, and GI 275 are all very straightforward, with engine indications being displayed on the G500 Xi in an easy to navigate package.

The Vision Jet uses the Garmin G3000 which is an upgraded version of the G1000 which is quickly becoming the standard avionics for general aviation (new) airplanes. Incidentally the Phenom 300 uses the G3000 as well.

If you can fly a G1000 in a Cirrus piston or Cessna, the G3000 is an easy transition.

The avionics and FMS of a typical airliner is positively COBOL by comparison. To get type rated in modern GA jets is pretty easy because the avionics are generally what you are already used to. However, the G1000/G3000 aren’t part 25 certified, however there is now a G5000 that is Part 25 legal, so I expect there to be some considerable improvements trickling up into the bigger jets. (Part 25 is basically “transport category” aircraft.)

Systems in small aircraft are a lot simpler than in airliners, by nature.

This seems to be an almost universal problem at old, large engineering companies. Somewhere along the way (probably as they slowly ossify into bureaucracies) all passion for innovation slowly withers.

I don't know what the answer is but attitudes generally flow down from the top, so I'd imagine a good start would be to somehow re-install creative technical people in the top-end leadership roles.

It's a consequence of development times. Large, complex projects take a lot of calendar time. It's generally more important to keep things from going awry than excelling.

Consequently, you look around and see nothing but conservative people putting in their time. If you're someone more driven, you get tired and leave.

You're not wrong, but there's also an element of justifiable conservatism. Aviation killed a lot of people before the associated industry and community mostly figured out how to make sure they didn't. Trying something innovative sometimes introduces a safety issue that hadn't even been considered.

Bureaucratic inefficiency isn't the problem in this case. The people who make these systems aren't optimizing for UX, they're optimizing for safety and reliability.

It's the same reason banks are still running things like their 30yo COBOL code. The cost of replacing it isn't the problem. The problem is, if it's been running reliably for 30 years, then what justification could you possibly come up with for accepting the risk of replacing it?

I work in that industry, and I think it's very harsh to say that people have lost passion for innovation. Most engineers I've been around care about making a good product, and get excited about using better technology or finding a better design.

However there's a constant care about making things that are certifiable, and make business sense (otherwise it's just not going to happen). It seems to me that it's difficult for people outside this type of industry to appreciate how certification impacts the decisions.

We strive to make systems that are reliable, easy to use and maintain, and efficient; but they have to make their way to the customer, through the authorities and business constraints.

> a good start would be to somehow re-install creative technical people in the top-end leadership roles.

Hell no. In aeronautics, you want safety-conscious, technically conservative, quality paranoid engineers. You need that because you don't want to retrain pilots on the last release every Patch Tuesday. A lot of the design that goes into the cockpit is to minimize training costs and that is a major procurement driver (remember the 737 MAX?)

At least as far what I've gathered reading airliner crash reports go (these obviously are going to be skewed) one of the challenges seems to be just being up to date / adjusting from one airliner to the next as far as procedure, and recovery processes for a given aircraft.

Being behind the aircraft as far as interpreting the situation/ indicators and not knowing what recovery steps to take seem to be a reoccurring problem, at least as far as catastrophic type situations.

As the scenario likelihood decreases, the probability of correctly identifying the associated recovery procedure probably also tends to decrease -- particularly for cases where recovery is not super clear and for cases where the scenario itself is memory intensive to describe or baroque -- "a occurred before b instead of b before a as normally expected and sensor d has condition c..."

I wonder if simulated error scenarios ever occur during flight -- could be a good way to expose pilots to rarely used recovery procedures within realistic day to day contexts ...

I think the tough part is trying to account for the human unpredictability in human errors.

You can have all the warnings and etc, but how the human processes and interprets and responds is just not always predictable. If they misread a situation, the time to recover/ self correct isn't often very long.

Granted, they've obviously made great progress to some extent, as safety as far as airliners go is pretty incredible these days.

You say information noisy, but some might WANT it to be information-noisy so that they don't have to press buttons to find what information they need.

I'm not saying they do (I'm a software developer Jim, not a pilot), just something to keep in mind. I'm rebuilding a webapp myself with more modern design, and in an early demo I've already gotten a remark about information density.

> Also all text-based, non-graphical interface.

I would consider this a positive. Graphics do not imply improved readability, the information is dense and you have no choice but to present it as concisely as possible. You also need a dim cockpit for low light operations.

What could be a win is integration with the QRG to make access to information easier during a abnormal operating condition. You spend precious seconds locating and flipping through paper books to identify mitigation procedures.

To elaborate on my point. Arcade flight and space simulators have probably the optimal possible UI for "aviate/navigate/communicate" activities.

Sort of like Nikon cameras or adobe photoshop. Their primary customer is folks who already own their stuff, so the UI is going to stay obscure.

Reply on news.ycombinator.com