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.
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!
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.
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..."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
