Touch screens add multiple points of failure to a device that, if properly built, would last decades. A single glitch in a software driving a screen could render useless all touch inputs displayed on it, information loss aside. I'm all for mechanical switches everywhere. As for potentiometers, sliders etc, we already have optical and mechanical encoders that hardly fail, or if/when they do, it happens gracefully leaving enough time for replacement. To me, the reason for touch screens is either cost or aesthetics, or both.

In many of the newer systems, all those physical dials and switches are just inputs to the computer system which ultimately decides to do what the user is requesting. A bug which would prevent inputs from working right on a touchscreen could also happen on reading inputs on other systems. Not that I'm arguing for touchscreen controls, just that these days having a physical knob does not mean you're directly manipulating things. Software glitches can still muck up physical controls.

> In many of the newer systems, all those physical dials and switches are just inputs to the computer system which ultimately decides to do what the user is requesting.

Even so, a program for processing a switch or dial can be really short and simple. You can print it out on a sheet and check and double check every line of code for to make sure it's correct and all possibilities are accounted for.

A program handling a touchscreen will be complicated. Millions of lines of code. Maybe even billions. The best you can hope for is empirically verifying it's mostly correct most of the time.

You've done a lot of programming for hardware switches and such then?

I do some. And the last device we built, we still fight with a simple rotary switch. You have to do things like debounce inputs that seem like obvious binary switches. Getting the debounce windowing right can be just as "guessy". And guess what the highest point of failure on said device is. That selector switch. Had similar experience with buttons. I think the software part is just two forms of the Law of Conservation of Ugly.

I do like tactile better, but more for affordance/discoverability (e.g. ergonomic) issues than what you're driving at above.

Yeah processing switch and button and encoder data manually is terrible. Once you install a library to wrap this hardware device in a sane process, how different is that than getting an x/y pixel coordinate from a touchscreen? Touch technology is incredibly reliable. I touch my phone probably 5k times a day or more and I don’t have touch failures, and I carry it around with me and get debris on it and drop it off of tables and all that too. I would argue that a touch interface is one of the most reliable from a hardware standpoint despite not being tactile.

If anyone else is wondering what debouncing is:

https://my.eng.utah.edu/~cs5780/debouncing.pdf

Haha, this is actually a remarkably funny read with some grizzled, hard-won bits of wisdom sprinkled in.

"It’s surprising how many of those derelicts hanging out at the waterfront bars pick an almost random time constant. “The boys ‘n me, we jest figger sumpin like 5 msec”. Shortchanging a real analysis starts even a clean-cut engineer down the slippery slope to the wastrel vagabond’s life."

Pressure / proximity info is just as noisy and requires its own version of denouncing and x/y jitter handling on top. (Is it a click/drag/hovering over?) My partner can't even stop accidentally registering right-clicks on her laptop touchpad, which should be a really polished experience these days.

I'm not sure I buy touchscreens ever being simpler to handle. (or even in the similar range - they're strictly harder)

Even modern AAA computer games sometimes miss mouse clicks, because they foolishly poll for transitions of the button up/down state in the main loop, for each frame they render, instead of properly tracking the OS event queue.

It's a very common (and lazy) way of programming games (and other more mission-critical apps): naively polling the input device state in the main simulation or rendering loop, instead of actually responding to each and every queued operating system event like mouse clicks.

It's entirely possible to get multiple mouse down/move/up/click events per render frame, if the system has frozen or stalled for any reason (which happens all the time in the real world). But polling just can't deal with that, so it sometimes ignores legitimate user input (often at a critical time, when other things are happening).

So it's still unfortunately quite common for many apps to sometimes miss quick mouse clicks or screen touches, just because the system freezes up for an instant or lags behind (like when the CPU overheats and the fan turns on madly and SpeedStep clocks the CPU waaaay down, or even the web browser opens up another tab, or anything else blocks the user interface thread), and it just doesn't notice the quick down/up mouse button transition that it would have known about if it were actually tracking operating system events instead of polling.

I had a microwave that used a digital knob that was completely screwed up, from a debouncing perspective. You would turn the knob to try and add 30 seconds to the time and it would stutter between 5-10 seconds for a bit and then shoot up to 3 minutes and then you’d try to drop it down to 30 seconds and end up stuck between 1-2 minutes. It was infuriating! The old mechanical microwave dials were way more reliable than that piece of junk!

Are you debouncing on tactile or is the hardware doing it for you?

In an ancient textbook I was reading, they were explaining how to debounce with transistors, capacitors and resistors - so at one time in history debounce was done in hardware.

In my own brief stint in (non-critical) hardware development, all debouncing was done manually in software.

It all depends on application.... and perspective...

Hardware debouncing works well for most applications but may not be financially rewarding at scale. With time and effort software debouncing can render sometimes better/good or good enough results as hardware..

Remember the saying, "When all you have is a hammer, everything starts to look like a nail..."

Mechanical switches and rotary controls require debouncing which is no picnic.

I can 100% tell from your comment that you've never had to work with one.

It's less science than black magic to avoid double presses or missed presses.

I've done a bunch of debouncing switch inputs, keypad, keyboard, rotory switches. And wrote some test code for capcitive touch display (long time ago)

It's the kinda problem that will tend to bite you in the butt if you aren't aware of all the gotchas. Difficulty is they are application specific. But I wouldn't describe the code as particularly complicated.

Most of this stuff a crusty old neckbeard embedded programmer can do half drunk on Friday afternoon.

So because an expert can do it easily means it's easy? In that case literally anything is easy.

OP was saying that mechanical switches could be deterministic, which is something that I haven't experienced.

I do agree that there is less to go wrong than a complicated touchscreen interface however.

Billions? That sounds like a vast overestimate, no?

Are there any programs that approach a billion lines of code?

I'd think a few npm dependencies should do the trick ;)

a quick search brought up https://www.freecodecamp.org/news/the-biggest-codebases-in-h... which reports google's codebase is around 2 billion LOC. MS Office comes in close to 50 million, for example.

Not sure how accurate these are, but seem to give some rough comparisons, and yeah, not too many things are billions of LOC.

I wouldn't be surprised, the amount of crap that gets downloaded for a simple react app is incredible.

> A program handling a touchscreen will be complicated. Millions of lines of code. Maybe even billions.

I think you're off by a few orders of magnitude.

https://www.visualcapitalist.com/millions-lines-of-code/

The phone switch for Nortel's Meridian PBX system circa 1994, which supported SONET and IP, had about 16 million lines of code. The complexity of a touchscreen is less than 1%, maybe less than 0.1% of that. Lines of code, however an absurd metric, in this case does say something. I'm just not sure exactly what, though.

Isnt code just vastly different... abstracted from 94’ era lingo?

Interesting link. Can anyone explain why a car needs so much code?

Instead of having a single computer that stores all the code, automobiles have lots of embedded systems with their own code and hardware, and lots of systems designed for validating safety critical functionality. When I say lots, I mean it's usually several dozen and can be over 100. Since many of these need to meet special regulations and oftentimes require hard real-time characteristics, this tends to add to the complexity significantly.

Apparently a lot of it is just generated templates coming from commercial SDKs. Adding to that, a car is a set of distinct embedded systems interacting in a sort of a ladder network topology rather than a vertebrate analog like multi-core PCs, so a lot of code in a car would be redundant or has little footprint restrictions.

I mean ... we all know a car does not need that much code

Really, why do you know that?

I would expect a car to have tons of code.

Think of all the functions...

Engine management, Engine monitoring, Powertrain control, Emissions, Diagnostics, Infotainment, Satnav, Climate Control, Traction Control, ABS, Anti-collision radar, Cruise control, Lane keeping, Backup camera, Parking sensors...

Now keep in mind that these hundreds of components exist in many many possible configurations so the system needs to handle having certain hardware available or not, and also handle a multitude of failure modes gracefully.

Perhaps because cars ran just fine (albeit with fewer features) for a long time with zero lines of code.

So did horses without any gasoline

Yeah, and so did banks, and so did airplanes.

So the more important question is: did adding software improve things (enough to be worth the “cost”)?

With cars, there are certainly many things where it did improve things: satnav, reverse camera, traction control etc, but also some where it made a perfectly working system worse (ie the “fixed” something that wasn’t broken): touchscreen dashboards.

Because my car has exactly zero lines of code and it runs just fine.

I guess in cars they use less (public) librarys because of safety. So there own libs are included in LOC. If you look at a modern Microsoft licence, they list tons of used open source libs in there products. I guess if you include all the librarys, the LOC number should be much higher.

Is this a good place for redundant microservices?

Each service handles data from a handful of physical of physical knobs.

At least that way you don't have the UI as a single point of failure.

There is no good point for "redundant" microservices.

They are, by very definition, an additional point of failure as you're always adding an additional interface. They're good for scaling, not for redundancy, and even that's wishful thinking for most applications.

EDIT: You could argue that microservices might free up the UI thread from locking mistakes, but if your team is going to make locking mistakes, you're also going to make mistakes in the microservice interfaces, so what's the point?

It's not about minimizing points of failure, it's about removing singular points of failure. Perhaps "redundant" was the wrong word but the point is instead of having a single UI component (touchscreen/UI thread) which can cause the whole system to fail, if you group buttons/knobs into individual microservices they are unlikely to all go down simultaneously.

I don't get how we can explain it in a simpler way? If you add a microservice, you're adding another point of failure. You add another interaction, you add more code. Add more code, you add more bugs.

It's pretty much the only empirical thing we have in software engineering, more code = more bugs.

Lots of little microservices means lots of extra code means lots of extra bugs.

Plus you've got to manage how they all interact. Which microservice has priotity? Did you even think of that? The breaking microservice? Or the volume microservice? Did you even think of that or try and test that? Your breaks get disabled every time you turn up the volume?

Whoops, you just killed a thousand people with your "redundant" microservices.

Erlang is build around the idea of microservices and message parsing. It's by far one of the best languages we have to make fail tolerant programs - it was invented to solve exactly that problem. While it does not mean you can take every program in any language and make them into a micro service architecture, it shows that if implemented correctly, the idea of microservices and messages absolutely increase reliability.

Do you object to redundancy under all circumstances, or only when it’s preceded by “microservice”?

If you add one microservice, you add a point if failure, but if you then add a few redundant copies of that microservice, for failover, then you don’t add a point of failure.

So… You're suggesting reducing the impact of potential error… By increasing the surface area of potential error…?!

It depends on the error. If its a logic error that will deterministically break all instances, then sure. If, on the other hand, its a transient error that a backup copy of the service can avoid, then redundancy adds safety. Sometimes safety critical software has multiple redundant units which need to agree, too, for example.

Multiple physical knobs and buttons add multiple points of failure: moving parts fail and even worse, they often fail intermittently. We all have that experience. Even optical encoders fail (I’ve had one fail on an engine, and obviously consumer mice, or the connectors fail).

A modern touch screen is superbly reliable because it has no moving parts, and it can be tested. The (consumer grade) iPad touchscreen is very reliable.

I had a smartphone that at some point started to randomly create touch events. Kind of like if you put it in your pocket while the screen is unlocked.

I don't remember any physical light switch that ever switch on or off by itself.

In an aircraft flying through turbulences I'd feel a lot more comfortable knowing that all switches are pyhsical. Try to use your smartphone while jogging...

Comparing a light switch to the switches and dials found in an aircraft is a it like comparing a light switch to a keyboard key.

Yeah they’re both switches, but size is incredibly important, and small mechanical devices are finicky and don’t produce nice clean digital output (that’s a lie that electronic engineers tell software engineers to keep things simple).

So yeah I’m sure you’ve never seen a light switch fail, but I bet you’ve seen a keyboard fail (especially if you’ve spent any time around a recent MacBook).

But I do agree with your point on using a touchscreen in turbulence. A counter point is that there are probably hundreds of controls or settings on a plane that you never touch during turbulence, possibly that you never touch in flight (like telling the flight computer how much cargo you’re carrying). Stuff like that is ideal for a touchscreen.

A mechanical switch is easy and cheap to fix or replace. A touch screen is the opposite. It cannot be repaired, only replaced. A switch can usually be cleaned easily, to restore its function. And proper quality switches can be actuated millions of times before failure.

> A mechanical switch is easy and cheap to fix or replace.

Not if it is in an airplane. Think of all the QC steps required to track the production, storage, shipping, installation, testing, etcetera for the replacement of a single switch. If a switch has failed it needs to be inspected to understand the reason for failure (no switch should fail; tracked to understand if it is a batch failure, plus other steps). I am only making an educated guess here.

> A switch can usually be cleaned easily, to restore its function.

Ummm, you think they put known failed parts back in planes? I think not. They do fix major parts, but the QC for that would be insane. You would make a switch to be hermetic and add anti-tampering - a manufacturer of any safety related device doesn’t want it to be “fixed”. Items are designed to be maintained (with proper schedules), or replaced.

> And proper quality switches can be actuated millions of times before failure.

On average? Or does it have a bathtub curve? Yes, quality switches are insanely reliable, but so are touchscreens.

If you have a variety of 50 switches and knobs, then the reliability is worse than 50x worse, because every item has it’s own reliability curve, and it only takes one failure to muck up your day.

>Not if it is in an airplane.

Even less so if it's on the space station. Or on a Mars rover. But we're talking about cars. Something a lot of people like to mend for themselves.

OP context of this thread is touch panels in aeroplanes, not cars.

I can say that an intermittent switch failure is hard to diagnose and potentially costly. The dash on a 2007 Ford I got cheaply had an intermittent fault where the whole dash would shutdown, and headlights would go off, while driving. Switching ignition off and on would fix it, so I presumed it just needed a reset. It was actually the barrel switch of the key - intermittent enough to cause a lot of dangerous trouble but hard to diagnose.

Point of fact; A touch interface digitizer and the LCD screen are two separate components just often glued and sold as a single unit. Replacing a digitizer, or a screen should be no more difficult than swapping out an analog component with a proper modular physical layout and connectors.

A cheap phone or tablet hardly represent best of breed for the technology as a whole.

Another factor is having to keep a larger variety of inventory for mechanical switches, vs a single touch screen SKU standardized across many models.

What happens if an object impacts a touchscreen and it breaks? I have my screens break (even behind a screen protector) and has failed to respond to touch. Imagine you are flying a plane and the touchscreen breaks due to impact. All your inputs are centralized behind that one touchscreen and you can no longer operate it. Wouldn't it be then better if there were multiple points of failure? You are decentralizing the impact a failure can have. Sometimes having multiple points of failure is a good thing. That way a failure in one component won't affect the other components.

Have a spare screen that you can just slot in and carry on.

The airplane cockpits I've read about have multiple screens, with knobs selecting the function of each screen (and which of the redundant flight computers control each screen), so a failed screen can be replaced by selecting its function on another screen. This makes more sense (and is simpler) than carrying a replacement screen (which would be dead weight most of the time) and designing a hot-swap mechanism (which would be yet another potential point of failure).

While your plane is falling from the sky?

Anecdotaly, my touch screen devices's screens are less durable than my mechanical keyboard, but I agree with your overall points, touch screens can be made incredibly durable.

Very interesting... I wonder what it would take for a touchscreen keyboard to be as reliable or live as long as a mechanical keyboard. Maybe it already does, but my mental picture and experience of phone screens getting flaky, and taking secondary+ swipes does not give me the confidence a mechanical keyboard does.

If they can make a durable touchscreen keyboard with a good click sound and feel and reasonable key travel and resistance, and that doesn't get crudded up with skin oils and food film, I'm willing to pay big bucks for it.

Multiple physical knows will never fail all at once like a single touchscreen can. As a small plane pilot I prefer to have as many independent systems as possible; I use an iPad for instruments and navigation, but every single function is duplicated by a separate instrument, so if I lose the iPad for any reason I have the instruments in the cockpit. I had several incidents where single components failed, but I was able to safely land the plane every time. Hardware failures are as much as a problem as software failures and dual-redundant critical systems are far better than multi-functional devices.

The iPad touchscreen is very reliable until you splash water on it. I don't think splashing a cup of water onto 1995 car dashboard would trigger any of the buttons.

There are plenty of individual use cases where touch screens make sense. The interactive map as it is enabled by the multitouch screen, with arbitrary rescale and repositioning and display of arbitrary layers of data, all handled at the speed of thought, is something unmatched by any other object or interface, for one example amongst many.

A wet finger makes my device go ballistic.

In airplanes touchscreens are less of an issue than in cars. In cars you have to have a hand on the wheel 99% of the time, and your gaze on the road. You can't afford interaction with a complicated non-haptic touch screen menu.

In airplanes it's different. Here, outside of takeoff and landing, it's OK to look at a screen for 10 seconds while interacting with it with a hand.

Not to mention that airplaines usually have TWO pilots onboard, so one can use touch screens while the other watches the sky ahead. Cars, on the other hand, have just one person in driver's seat.

> it's OK to look at a screen for 10 seconds

Not really. Pilots are supposed to be visually looking for traffic 90% of the time, and the rest scanning instruments.

So to be heads-down for 10 seconds, the non-flying pilot would have to arrange that with the flying pilot.

Under VFR sure, obviously under IFR they are looking at the instruments as much as 100% of the time, including the instruments which inform them if planes are nearby, and instruments which inform them of their location, direction, and all of the variables therein.

It would be madness if pilots had to rely solely on their eyes to locate other planes nearby. There is thankfully instruments which do this as well.

In VMC you still have a responsibility to see and avoid, regardless of whether you're on an instrument flight plan or not. (Ref: Regulation 14 CFR Part 91.113 (b))

Radar coverage has become ubiquitous in most places, but there's not universal coverage. Heads-up time is very important unless you're flying in actual IMC.

Can't find equivalent rule from ICAO, is this regulation US only?

Refer to ICAO Annex 11 - it's not the exact point being made by the GP, but note that traffic separation for IFR traffic from VFR traffic is only provided in Class A, B and C airspace.

Or, you know just flying the autopilot, which many do like 90% of the flying time...

I think what GP is trying to say is that because your average airlines has around 10+ km of altitude to loose before rapid disassembly commences, which takes a non-trivial amoun of time, compared to a car, which can go on a short and unintentional offroad trip within a few seconds or less.

No, you don't. you can fly over high mountains, having a lot less distance between the plane and the terrain, but how you lose altitude is more important: just a single km drop can be unrecoverable if exceeding VNE and losing a wing in the process.

Most planes in the world are not the big airliners, but smaller planes where single pilot operation is very frequent and many planes do not have a complex autopilot, but usually a 2 or 3 axis stabilization. Also in turbulent weather looking for 10 seconds at a screen can induce motion sickness even to seasoned pilots. We have to do that for map checks and calculations, not a pleasure.

Huh, I wonder if they can use a measurement to adjust the refresh rate based on turbulence. I think they did this for the space shuttle experiencing vibrations to make a screen readable.

It is not the refresh rate, it's the fact that you are looking at a screen that is not moving so much while the airplane and you body is shaking; your internal sensors are telling you are moving, the eyes do not correlate the information, you get motion sickness. I had this problem in my first 50 hours of flying, sometimes even after 100 hours.

Not necessarily. There are many moments during the operation of an aircraft where full attention is paramount. Yes, you see a pilot leaving the cockpit to use the lavatory while the co-pilot is monitoring the autopilot, but the margins are just as small as operating a motor vehicle.

My partner is a first officer, and frequently describes his job as being a glorified babysitter outside of takeoff and landing.

Worth noting that a significant amount of the information pilots use in the cockpit (at major US carriers, at least), things like flight plans, are on an iPad.

... until something goes wrong. Then a touch screen is the last thing you want. An airliner moving uncontrollably is no time to try touching just the right spot of the screen, and avoid touching the wrong spot.

Was team screen til this point.

In critical systems, you want to make sure inputs are easy to use in the worst case scenario.

Even the best of touchscreens can't compare to physical controls in tough times.

Kinda like trying to flip just the right toggle switch and avoid flipping the wrong one?

Just because it's on a touchscreen doesn't mean it has to be tiny and hard to touch. A 17" touchscreen could have fewer controls than the same hardware panel. And the controls could be bigger on the touchscreen.

It’s not like trying to flip just the right toggle. You’ve flipped it thousands of times and memorized its exact location through haptic memory. You gently feel the surroundings to ensure your hand is in the right location and then you make the decisive motion with your fingers. You don’t need to look while doing this. This is how hands work. This is how you type. I wish people would stop pretending they don’t understand this.

> flipped it thousands of times

This raises a question: how many times do an average pilot actually flip a switch over their carrier?

Many switches are flipped once or twice on takeoff, then again before or after landing. Depending on the plane (small GA aircraft or airliner or anything inbetween) there could be 4 or 5 switches to flip in total before takeoff, or 30-40. One of the most ubiquitously used controls in aircraft are concentric rotary encoders though, with a button integrated in them if you press the top of the encoder. Those are used to do menu navigation in the GPS units used in many planes, or for altitude/heading selectors in autopilot units.

Worth mentioning that these days GPS units seem to be getting touchscreens but usually still aren't losing the physical buttons.

Thiss os how i typw somtimws.

BS.

Imagine trying to find the right switch on this by feel, without hitting the wrong one by accident.

https://live.staticflickr.com/6150/5990351987_fb9c159ea5_b.j...

Easy mode, given the variety of orientation points in form of switches you can gently touch with fingers to recognize position.

That said, usually you make a short look at the panel to benefit from that hardcoded visual-motion coordination hw in your head.

I can just as easily make the argument the other way around: An airliner moving uncontrollably is no time to try touching just the right knob (of which there are like a hundred), and avoid touching the wrong one.

You'd be wrong. The critical controls are uniquely shaped so that the pilot can put his hands quickly on the correct one and know it's correct.

Part of pilot training (at least in my dad's day in the AF) was blindfolding the pilot and the instructor names a control, and the student must put his hands on it. Or he flunks.

I don't believe this is equivalent though. With hardware controls, most (if not all) of them are immediately accessible at all times. With proper training, body movement and tactile feedback will train your muscle memory which will help you find the right control without much of a hassle.

Just out of curiosity, do pilots still manually take off and land fully, or does auto-pilot / computer do this too nowadays?

The technology exists, but autoland functionality depends on the plane model and the airport. Usually, most of the approach is done with ILS with the final moments being manual.

Absolutely not true. In cruise, stabilized, especially with AP - the margins are MUCH MUCH higher. Pilots have fallen asleep (two of them) - overflown airports still landed etc.

I think major difference is commercial airliner vs say fighter jet. As a layman it still seems pretty wrong to make most of the screen highly dynamic. Maybe designated one on the side.

Back to the topic - in car, unless specifically intended for other passengers, driver should never stare on some stupid screen in a place way off the line of sight for driving. Whenever I do that even for a split second in my 15-year old bmw (checking if that knob is really for what I want), there can be an atomic blast in front of me and I wouldn't see it.

I'm not arguing for touch screens - I don't like them, but to say a commercial pilot in cruise at 30K in controlled airspace with controlled separations and TCAS / ADS-B has margins as low as someone driving 85 MPH with traffic literally 50 feet in front of them is absolutely ridiculous. The spacing distances alone are 100x different (in terms of travel time).

Deaths and injuries per mile traveled supports the idea that flying is MUCH MUCH safer.

Fighter jets are starting to use touchscreens, too.

Because fancy, advanced UIs work so well for Navy ships.

I remember when that happened, pretty shocking: https://en.wikipedia.org/wiki/Go!_(airline)#2008_incident_an...

Modern airliners are just short of autonomous. Even if they aren't, unless you are landing or on initial ascent, you are generally minutes away from catastrophic outcomes regardless of your control inputs. In fact, most of the time, if something bad is happening, simply letting go of the controls will lead to the issue resolving itself.

A car is very often fractions of a second away from a serious accident.

A plane at cruise altitude is rarely less than minutes away (unless, in some planes, you are actively trying to crash the plane/make the wings fall off)

> In fact, most of the time, if something bad is happening, simply letting go of the controls will lead to the issue resolving itself.

Unless you're flying a Boeing 737 MAX that is.

Indian Road Congress specifications recommend 3.5m minimum lane width for multi lane roads, 1.06m minimum center margin. Airplanes complex enough for touchscreen interfaces would be awful tight in those margins ;)

Big mistake, imnsho. It will work fantastic right up to the point where you actually need that control in an emergency and then it will fail you because it is impossible to hit the right area consistently in a bucking aircraft. It also requires visual confirmation rather than tactile confirmation, which requires you to take away your attention from the surroundings, something you do at your peril in aircraft.

The sad but real reason a ton of this is happening is one very big word that is typically not present in things like car / airplane design: flexibility... flexibility to change the user controls, flexibility to fix problems, flexibility to let the SW team work up until the last minute to get stuff working, and the second part that goes with this is cost. Touchscreens mean increased flexibility for the design and better control over cost to deliver features. Unfortunately, if the display dies and you can't see anything, then the car or plane may crash... so sadly it will probably take a couple of those events happening for this to be changed to have some kind of redundant systems that the pilot can use when the display dies suddenly.

If something needs that much flexibility in it's UI that people are messing with it at the last minute it doesn't belong as something people should be messing with while driving. The OP talks about HVAC controls. How much flexibility do you really need for that? The interface has been standardized for a long time. It's a known quantity both from a design perspective and user perspective. Ditto for common audio controls like volume, pause/play, skip.

You'll often see screens surrounded on all sides by physical buttons. The screen can be updated and changed over time but the interaction is still physical.

There already are redundant systems like the ones you want. Multiple displays. Most planes that are heavily reliant on screens for instruments/navigation, touchscreens or not, have two of them at least. If one fails, there is a button you press which condenses the information previously shown distributed over both screens on each individual screen (so, the remaining one if one has failed).

Planes have multiple screens which provides more redundancy vs broke physical switches.

User controls should never change. It leads to people getting confused and making mistakes.

There's lots of discussion here about the benefits or otherwise of analog switches etc, but it's not about the failure or otherwise of the input device, it's about the affordance to the pilot.

Well designed physical UI allows pilots to use touch and haptic feedback independent of sight. Whether the switch/dial/whatever is analog behind the scenes or is a digital input to the control infra is not the important thing.

I hope this is known to the manufacturer:

"The US Navy will replace its touchscreen controls with mechanical ones on its destroyers

After a deadly 2017 crash between a destroyer and an oil tanker"

https://www.theverge.com/2019/8/11/20800111/us-navy-uss-john...

What exact type of input is being grabbed by these screens? "Critical pilot systems"? Touchscreens already exist in airliners, for systems used by crew and passengers, but that's beside the point.

I fly recreationally and all the higher end gear has touch screens. Some of them are redundant with paths using hardware controls or not. But that's definitely the minority. There are a slew of critical operations that I simply cannot complete without interacting with a touch screen.

Not saying it's right or wrong but your original post is 100% incorrect.

Are these things certified?

Many recreational pilots fly with uncertified gear (GPS in particular), and even regular smartphone/tablet apps. They also have the required paper documentation and certified instrument but that's just to cover themselves, and as a backup.

Garmin has quite a few certified touchscreens these days, some intended for panel upgrades (e.g. https://buy.garmin.com/en-US/US/p/67886) and even some in new light jets (e.g. https://buy.garmin.com/en-US/US/p/66916).

Also, some airlines now have officially certified iPads as EFBs, meaning pilots no longer need to carry paper backups.

Yes this has all been in Pipers and Cessnas.

My iphone touch screen won't work if my fingers aren't clean and dry.

They are not capacitive

Critical driver systems (i.e. steering, signaling, acceleration and brakes) aren't controlled by touchscreen in any car I know of either, so if non-critical systems are beside the point, what is the criticism here? Or are you thinking of some particularly extreme cars that are even more reliant on touchscreen than the Model 3?

I was just trying to make an illustrative example of why I think static interfaces are safer and therefore better, at the end of the day it comes down to subjectivity for the part of a positive user experience, but when it comes to safety the trend is, to me, worrying.

I also imagine that there are other reasons for both airliners and cars to replace buttons with touchscreens, namely that of cost instead of prioritizing safety and stability, and in general I am not a fan of that trade-off. But I'm also not claiming to be representative of the automobile market in general.

If you believe that aviation not having touch screens means that cars should not either, then evidence to the opposite should change your mind. The A350 and 777X both have touch screens now.

It's not just Boeing, who you accused of being backwards who are doing this, Airbus is too, along with every other manufacturer. Garmin and BendixKing now offer touch screens and it's clearly the future of GA as well not just commercial aviation.

Everyone believes that this will increase safety. That showing only the relevant information in a tunable and interactive way will decrease distractions and help focus on what matters.

The idea that this is to save money is totally absurd! A 777X is $350 million dollars. Any accident would cost an astronomical amount compared to the cost of switches. Even leaving that aside. The touchscreens are actually far more expensive than the old instruments.

This is just a way for Honda to cover up the fact that they can't write software, can't design a reasonable UX, don't want to spend money on it, and want to live as if it's 1999 forever.

I'd pay extra for a 1999-style car. That year was near the peak for car design quality. Fancy cars hit the peak around 1995, and cheap ones hit the peak around 2010 or 2015.

Who is this everyone that believes touchscreens will increase safety? I could not find any reputable sources for this claim.

Furthermore, tactile feedback is safety. The fact that each switch has a feel, a size, a position - that let's your brain know what you are doing without having to take eyes off the road.

I have seen side mirrors controlled by touch screen, as well as some headlight functions. Which is are critical safety systems, though rarely an issue.

Still, if you’re borrowing your wife’s car it’s easy to realize you don’t have great blindspot visibility at which point looking at a touch screen is very distracting.

What happens during turbulence when you can't accurately touch a specific point on the screen? It doesn't take much turbulence, either, as I cannot reliably use the GPS on my phone, while driving, when it's in its (very stable) mount, and I'm on an average paved road.

Touch screen looks awesome on Star Trek, but in actual use it's an inaccurate, attention-magnet, nightmare.

Which control do you exactly need to adjust in the middle of a turbulence?

Most of them, as you find turbulence in all fases during the flight.

Roll? Pitch? Yaw? Engine RPM? Prop pitch?

Those are “most” of the controls... none of which require touchscreens.

What controls are you referring to specifically?

A plane isn't a good analogy for a car.

Airplanes have keypads that control complex functions on a screen, going from that kind of keypad to a touchscreen is logical.

In the case of cars, a touchpad is overkill for controlling the cabin temperature, stereo volume, etc.

It's logical? It's absurd. You can usually pull over a car and get out in the case of a critical hardware failure. There is rarely such a luxury in a plane.

Anything critical on a plane will be duplicated, including power systems. Sometimes triplicated.

You say that like the 737-Max incident didn't just happen.

I wonder about the temperature settings. I have manual dials but I basically set them to 21C for winter and 19C for summer. Other than that, I don't readily touch the hvac panel at all: I could certainly do those rare adjustments over a touchscreen.

I can imagine people would need to tune a radio panel more often, so at least basic functionality would be good to have as physical inputs. But even then basic radio functions are usually accessible via steering wheel buttons.

I pray you all read the ux bible About Face on interaction design.

So in due time we can be almost certain to hear about a crash due to a bad touch or a wonky screen.

New isn't always better.

That’s too bad. Imagine unresponsive touchscreen due to dry skin or wearing gloves, or hands are too sweaty.... or the controller goes out, etc.

Flight plans is one thing but controls are all together a different sort of thing.

Why ask for trouble?

I have no idea how, but my smartwatch touchscreen remains responsive underwater, in a bathtub or swimming pool. It was with on every workout, and it both endured the energetic movements and sweaty hands were not an issue. The thing has more RAM and CPU power than my desktop in first half of the 90s, runs Linux, and is programmed with JS (well, there's gotta be some faulty part in every design). Anyway, if I can buy such a thing for a few hundred dollars, then - unless there are some physical limitations I'm not aware of - it should be possible for people who build the planes.

Touchpads can't even be operated by a cat https://ask.metafilter.com/91541/Why-cant-Godfrey-work-the-t...

Actually the thread showed they can.

The theory I thought was reasonable for why the OP had troubles, was that Mac touch pads are sensitive enough to treat the separate pads of the paws as multitouch.

Testable: try with individual pad of paw on a Mac touchpad.

Touch screens for all purposes? Probably good to distinguish if some things, even at your company, should not be dynamic (are they dynamic?). Some life-critical thing that is vulnerable to an uncovered sneeze?

I wouldn't fly on a touchscreen plane, imagine Boeing going corporate with their airplane screens, nope, nope, nope.

The big driver for this is reducing the number of components and thus manufacturing cost, and secondarily being trendy.

function (buttons) > form (touch screen)

Usable inputs save lives.

Adding "touch screen calibration failure" to the list of things that can kill you.

please tell then to stop

and all SCADA systems

Murderers!

No offense intended, but the sector as a whole has been doing all sorts of dumb sh*t recently when it comes on-board electronics (787 batteries, 737max MCAS, A380 wiring, F35 ... everything). This doesn't exactly refute OP's point, is all I'm saying. Maybe airspace firms shouldn't be taking their design cues from Cupertino.

OP was making an appeal to authority, that avionics manufacturers know what they're doing and decided against touchscreens. So IMO it does strongly refute OP's argument.

(That's not to say that OP is wrong, of course, just that their argument isn't really a valid one. My belief is that touch screens would suck for flying a plane, but I'm not a pilot.)

What I was trying to say was more that avionics are by nature risk averse, so if they're doing something it's probably worth understanding why. So it's not so much "it's safe because it's in an airplane", I was more going for "consider why this very safety-focused environment looks different". So sure, I might be in the wrong if what I said was interpreted as a simple appeal to authority, but I was trying to get a point across that people spent a lot of time trying to make and keep these systems secure, so let's try to learn from that instead of invalidate it as being simply old or outdated (which Boeing themselves ironically seem to be guilty of).

It is very clear that the aviation industry is NOT risk averse. They are averse to losing money (via needing to spend money to redesign systems, recertify interfaces, re-train pilots, rebuy new equipment and simulators, all of those reduce risk but are capital intensive). But they are no longer risk averse. They might never have been risk averse at all - the roots of the aviation industry is exceedingly risk seeking in the first place (to fly is itself a risk seeking activity - and that's something understood by all pilots and all aviation and aerospace engineers on day 1 of wanting to fly)

You can say the civilian oversight groups that seek to regulate the industry are risk averse, but the companies that build the planes themselves, if they had their say, we'd be flying mach 3 upside down all day.

> They are averse to losing money (via needing to spend money to redesign systems, recertify interfaces, re-train pilots, rebuy new equipment and simulators, all of those reduce risk but are capital intensive).

Re-designing systems introduces risk and uncertainty. Being able to leverage existing pilot training reduces risk (because crashes have resulted from pilots forgetting they were flying X and applied training for Y). Buying new equipment introduces risk of manufacturing defects that wasn't present in the working one.

Appeal to authority is an informal fallacy of logic. It can/should never be used to prove an argument.

Sure, if everyone is an expert on the subject, or is willing to spend the time to become one, you should never appeal to authority.

That's not most people on most subjects. If someone appeals to authority and says "climate change is real, here's 100 scientists with PhDs who agree" I accept that. I am not willing to become an expert on the subject to be able to spend the time to review the facts for myself. Citing sources in a paper is essentially appealing to authority (I understand I could read those papers and the ones they cite, all the way down, but for most things, I'm not going to do that).

For what it's worth, for a specialist in a field, they'll have already read most of the papers that are cited and will be looking for new or missing ones to find gems or flaws in the argumentation.

That's fair. Most papers are probably written with specialists in mind, so I guess that wouldn't be a good example of appeal to authority.