feature article
Subscribe Now

Bad Touch a Mile High

Sorry, It's Not What You're Thinking

There’s nothing like 10 hours in the air to help you get intimate with a piece of technology that you must stare in the face the entire time.

I’m talking, of course, about the screen in the back of the seat in front of you. I had two different experiences with two different screens on two different flights last week.

On the first one, my only observation was that the screen and light controls had been moved from the arm rest (where you are forever turning the damn thing back on by resting your arm on one of the buttons) to the screen. A good thing but for one problem: figuring out how to control stuff from the screen.

Turns out there was an innocuous little dot you push to bring up a menu. A dot was apparently the best they could do as an icon; heck, it wasn’t even obvious that it was there to be clicked. You HAD to read the instruction page to know how it worked.

But that doesn’t really merit more than a passing reference; I’ve gone on about interfaces before, so I won’t go off on that this time.

I had much more 1-on-1 time with a different screen my return flight. Because I tried to play games on it.

When you spend more mental energy debugging the screen than you do on the Solitaire game you’re playing, then you’re probably a nerd. There: I’ve said it. I’m out. But you probably knew that. And the only reason I’m sharing this whole thing with you is that you’d probably do the same thing.

To be honest, I’m not sure exactly what this particular article is supposed to be about. While it focuses on a particular touchscreen, and so it fits into the touch-technology topic that will feature prominently in the upcoming Interactive Technology Summit this week, it’s also a vehicle for ruminations on how we engineers think and how a crappy screen could come into being and how engineers might feel about their work.

I’m also not sure about the wisdom of a piece conceived and executed under the influence of jet lag. I think it’s not as ill-advised as what I might have written under the influence of the $15 bloody Mary I had at the Buena Vista restaurant at SFO after seeing the bill. (I mean, yeah, things are expensive at the airport, but really? For a supremely mediocre Mary? But I digress…) Let’s see how this goes, and if it doesn’t work, well, I can simply blame the jet lag. So I have an out.

Let me start by congratulating the engineering community for returning to me the space under the seat in front of me. When airplane infotainment systems first made the scene, they required a box about the size of the briefcase I needed to stow under the seat in front of me, by law. And they put it under the seat in front of me. Which meant that, when I got to my seat, that space was already taken up and I couldn’t put my briefcase there.  (Yes, in those days, I used a briefcase.)

When a flight attendant told me I had to put it under the seat and I said that there wasn’t any room due to the electronics, she did that thing that many customer-facing folks do when faced with really inconvenient contradictions: pretended it didn’t exist. She just repeated that I needed to put it under there, disregarding what I had said. <sigh>

So, thank you: you’ve done well in that regard.

I first realized that something might be different about yesterday’s screen when it seemed to take much longer than the ones around me to boot. There were some other misbehaving screens, those and mine were fixed using the usual in-plane technique: reset the whole system.

Which brings us to Critical Attribute 1 of airplane electronics: they have to be operable by people with no background whatsoever in electronics or mechanics or anything technical. So they have to be foolproof. And even if you endow the systems with diagnostics or other features that might more surgically fix problems, just know that real flight attendants will simply revert to the equivalent of unplugging it and plugging it back in again. (And that’s not a slight against flight attendants: you know damn well that the diagnostic interface on the system would probably take an engineering PhD to figure out.)

But things got more challenging when I touched various buttons to control things. Usually I had to touch a couple of times to get it to notice where I was touching. Minor annoyance; I was able to get things done for tasks like viewing the map.

Not so simple when I tried a word-scramble game. First of all, I had no idea how the game worked – the things I was unscrambling could never form real words no matter how I did it, so that was odd. It was also difficult because the letters I had to touch to move them around were about 1/10 the size of my fat finger. So this would have been tough even with a perfect screen.

But it became clear that parts of the screen were recording my touch about a half-inch away from where it actually happened. The error swamped the precision required to hit the little letters; my game was invalid. I gave up and moved to Solitaire.

There I could see more systematically what was going on. The left part of the screen was definitely sensing touch in the wrong place, but it was pretty consistent, so I could compensate. Towards the center and right of the screen, things seemed more accurate. I figured that the screen was old and had been abused.

And, in fact, you may be looking askance at this right now, thinking, “Well of course the thing is busted up. It’s got to take abuse from ham-fingered morons after three too many whiskeys!” And, in fact, you’d be correct. But that leads us to Critical Attribute 2 of airplane electronics: It’s got to take abuse from ham-fingered morons after three too many whiskeys. Deal with it and design in the robustness.

In other words, if everyone knows it’s gonna get busted, you should design it to where it doesn’t get busted so easily. So I’m not giving it a pass on those grounds.

But other things started happening. If you’ve never played Solitaire, it’s enough to know that cards get laid out in columns. You touch various cards and columns to move cards around. Obviously, I had to touch the left column way to the left of it to record the touch where I wanted it. If I touched the left column directly, then the second-to-left column would register the touch due to the error I just mentioned. Most other columns I could touch directly.

But more strangely, often, when I touched one card or column, some other completely different card or column would register the touch. This wasn’t a systematic error in the x/y coordinates like the other problem seemed to be. There was no predicting when it would happen (which was more often than not) and no predicting where the touch would actually be registered.

Even so, it wasn’t completely random. About half of the time, the touch registered on the previous card or column that had been touched. It was as if the new touch was detected, but the new coordinates didn’t get into a register somewhere, and the old coordinates were reported.

It was notable that the errant touches were always in the portion of the screen where the cards were. No touch ever mis-registered over in the control buttons, so I never accidentally reset the game, for example. So even the random mis-touches weren’t totally random, which is odd, since the hardware shouldn’t know anything about the semantics of the software…

And sometimes a touch wouldn’t register at all.

Each move of a card was supposed to take two touches: touch the card you want to move, and then touch where you want it to go. I found that, on average, my real experience was between 4 and 8 touches. (True confession: I didn’t really measure and average the numbers. I’m an unworthy nerd.)

I don’t know what specific touch technology was used for the screen. It wasn’t some fancy LED/detector thing; it seemed pretty much like an ITO screen, but I don’t know if it was. It’s very likely that the least-expensive possible approach was taken. Because, judging from the food served, Critical Attribute 3 of airplane electronics has to be: Make it as cheap as humanly possible.

This gives us three Critical Attributes that must be part of the Marketing Requirements for these systems. If not, then the marketing dudes should be replaced. Either that or the marketing dudes were overridden by some executive somewhere that thought he could curry favor with the shareholders by saving a few bucks even if the systems pissed off a bunch of customers. After all, that would probably happen next quarter and it was still this quarter. In this country, we don’t worry about next quarter until next quarter.

Of course, the first two Critical Attributes are variants of each other: the system must stand up to boneheads. Although it’s not fair to call flight attendants that; they don’t have (and shouldn’t need) those technology skills for their job. They have plenty of other skills that we engineers don’t have. Like being normal social people in a crowd. And dealing creatively with the real bonehead that had three too many whiskeys and is now pounding on the touchscreen.

Which reminds me of Critical Attribute 4 of airplane electronics: the touchscreen must be sensitive enough to where you don’t have to pound it during a game. Or else the guy in front of you who is trying to sleep may turn around and whack you. Which the flight attendant would also have to manage in a way that we engineers probably couldn’t (like something besides plotting how to hack their Facebook pages and email accounts).

It’s easy to wonder whether the designers correctly incorporated these Critical Attributes. Which raises a bigger question: Whose fault is this, anyway? Is it a design issue? A manufacturing issue? A reliability issue? An installation issue?

It occurred to me that if the power were marginal on this unit, then it might take longer to boot (because it’s running slow) and some parts of the circuit (like sensing a touch) might work (sometimes) while others (like registering the coordinates) might not. Was this due to poor design? Or was the power supply in the seat inadequate? Or was there something funky about how the power was connected?

The robustness Critical Attributes also go against the cost Critical Attribute. As a working engineer, taking such conflicting requirements and crafting a solution that works can be a source of great pride. On the other hand, if you’re given requirements that cannot be reconciled – if the cost expectation is ridiculously low, for example – then that can be really frustrating, and you end up shipping something that you’re not happy with.

That is, unless you work in one of those engineering mills that make cheap goods for the lowest bidder. The kind of place where the Welcome letter when you join starts with, “Abandon all pride ye who enter here.” Where the engineers work endless hours with expressionless faces and dulled emotions. Where the only requirements are to make cost and make schedule.

But I can only guess as to whether that’s where this came from. My good fortune was that I was able to take this experience and geek out, writing about it for other geeks that might enjoy it. (At least, that’s how my time-zone-challenged brain rationalizes it.) Were I a normal passenger, I would simply be frustrated.

Which I would probably take out on the poor flight attendant.

Who would then graciously go reset the system.

One thought on “Bad Touch a Mile High”

  1. Today I geeked out about an airplane touchscreen. Do you have other geek-out stories where you stopped using some piece of equipment and started debugging or over-analyzing it instead?

Leave a Reply

featured blogs
Oct 3, 2024
Someone with too much time on his hands managed to get Linux to boot on an Intel 4004 in only 4.76 days...

featured paper

A game-changer for IP designers: design-stage verification

Sponsored by Siemens Digital Industries Software

In this new technical paper, you’ll gain valuable insights into how, by moving physical verification earlier in the IP design flow, you can locate and correct design errors sooner, reducing costs and getting complex designs to market faster. Dive into the challenges of hard, soft and custom IP creation, and learn how to run targeted, real-time or on-demand physical verification with precision, earlier in the layout process.

Read more

featured chalk talk

Vector Funnel Methodology for Power Analysis from Emulation to RTL to Signoff
Sponsored by Synopsys
The shift left methodology can help lower power throughout the electronic design cycle. In this episode of Chalk Talk, William Ruby from Synopsys and Amelia Dalton explore the biggest energy efficiency design challenges facing engineers today, how Synopsys can help solve a variety of energy efficiency design challenges and how the shift left methodology can enable consistent power efficiency and power reduction.
Jul 29, 2024
37,685 views