15 ms·

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 rende

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.

vel0city 7y ago
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.
- twomoretime 7y ago
  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.
  - mattmanser 7y ago
    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?
    - twomoretime 7y ago
      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.
      - mattmanser 7y ago
        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.
        hvidgaard 7y ago
        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.
        dkersten 7y ago
        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.
        asfarley 7y ago
        Do you object to redundancy under all circumstances, or only when it’s preceded by “microservice”?
- im3w1l 7y ago
  > 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.
  - travisgriggs 7y ago
    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.
    - lukevp 7y ago
      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.
    - DonHopkins 7y ago
      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.
GuiA 7y ago
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.
robocat 7y ago
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.
- sudosysgen 7y ago
  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.
  - deskamess 7y ago
    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.
    - bregma 7y ago
      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.
      - krebs_liebhaber 7y ago
        > If they can make a durable touchscreen keyboard ... that doesn't get crudded up with skin oils and food film You can already get one of those. Just go to the bathroom, turn on the sink, and put your hands under the stream of water. If you're a touch-screen power user, you can even put water on the screen - and then wipe it off!
- 7y ago
omilu 7y ago
A wet finger makes my device go ballistic.

vel0city 7y ago

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.

twomoretime 7y ago
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.
- mattmanser 7y ago
  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?
  - twomoretime 7y ago
    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.
    - mattmanser 7y ago
      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.
      - hvidgaard 7y ago
        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.
      - dkersten 7y ago
        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.
      - asfarley 7y ago
        Do you object to redundancy under all circumstances, or only when it’s preceded by “microservice”?
im3w1l 7y ago
> 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.
- travisgriggs 7y ago
  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.
  - lukevp 7y ago
    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.
  - DonHopkins 7y ago
    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.

GuiA 7y ago

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.

robocat 7y ago

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.

sudosysgen 7y ago
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.
- deskamess 7y ago
  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.
  - bregma 7y ago
    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.
    - krebs_liebhaber 7y ago
      > If they can make a durable touchscreen keyboard ... that doesn't get crudded up with skin oils and food film You can already get one of those. Just go to the bathroom, turn on the sink, and put your hands under the stream of water. If you're a touch-screen power user, you can even put water on the screen - and then wipe it off!
7y ago

omilu 7y ago

A wet finger makes my device go ballistic.