Last weekend my 10-year-old daughter and I went to the National Aquarium here in Baltimore to see the new seahorse exhibit. Amidst the tanks displaying a startling array of bizarre-looking creatures lurked the inevitable interactive computer screens, each containing a wealth of in-depth information about these denizens of the deep.
Kristy pressed the touch screen… pressed it again, and again, and finally a new page appeared. Interactive? Perhaps, but that pointless, unforgivable, two or three second delay compromised the experience for her, and I'd imagine many others. This is the age of the 1,000MHz computer, of previously unimaginable processing power, memory, and resources. Yet it seems things are slower than ever.
The experience reminded me of one of my pet peeves: gasoline pumps. Why is it these things work so slowly? After authorizing the credit card, the machine says “press Start and pump.” I press Start, insert the nozzle, and pull the gas lever. It clicks, no gas comes out. I pull it again and again. Click, click, click. Finally gas starts to flow. Why the delay? With credit card processing complete, with the start button energized, the embedded brains must merely actuate a relay to start fuel flow. Yet seconds go by. What is the silly thing doing? Even if controlled by the most brain-dead of 8-bit processors, I'd expect no more than milliseconds of elapsed time. Instead, I stand there clicking the lever, getting ever more frustrated.
Seems to me there are only two possible scenarios: either the firmware is poorly designed at the customer's expense, or there's a damn good reason why we're supposed to wait. In the latter case, why doesn't the code let us know what's going on? How about a simple “wait — processing” message? My cell phone sometimes searches for the signal for five seconds or more at power-up, but that delay is accompanied by a “searching” message, so isn't annoying at all.
As one who travels too much, I see first-run movies mostly on hotel Spectravision, the businessperson's replacement for having a life. The user interface is weak; you're never sure if pressing the button will order the film or just give more info. But all too often ordering the movie fills the screen with nothingness, sometimes for over a minute. What happened? Did the order go through? Do I try again… and will that incur another $9.95 charge? Why didn't the designers pop up a “loading — please wait” message?
And why, oh why, does the hourglass icon sometimes take seconds to appear on my Windows machine? We have to wait to be told to wait?
Sometimes the delays are entirely appropriate. Press a pedestrian crosswalk button and it's unreasonable to expect the lights to change immediately. But just watch someone use that button. They press it, wait a while, press again, and again. Did the controller see the button push? While waiting at an L.A. crosswalk, a fellow clearly contemplating jaywalking commented that he felt the buttons weren't connected to anything. They're a part of a technological conspiracy to delude us into thinking we had at least a little control. I presume he's wrong; surely the button must initiate a crossing sequence. But there's so little feedback that maybe he's right?
Why doesn't a simple light, perhaps in the middle of the button, acknowledge the request?
A friend who designed TV remote controls told me, in all seriousness, that reliability isn't important in these things. They found that consumers naturally pressed and repressed the buttons when nothing happened. Rather a cynical design strategy, don't you think?
And as for those gas pumps, if you design these blasted things, are these delays just a cosmic joke so the attendant can chortle at hoards of busy commuters clicking, clicking, and clicking at the handle?
What do you think? Are these avoidable delays the result of crummy design or something else?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at His website is .
I don't know about the US but in Canada once you've inserted your card and its been approved the pump signals the guy in the store and he must activate the pump. I'm sure its a safety issue. “Don't activate the pump unless there's someone there to operate it”.
It's interesting that you mentioned the Aquarium and Baltimore… my wife, son, and I just visited it two weeks ago. Incidentally, all the crossing buttons for the streets near the harbor illuminate a light and give a satisfying little “chirp” when activated. I thought it was a neat little feature, and probably extends the life of the buttons appreciably. 🙂
In the U.K. there is indeed a little light on pedestrian crossings. We call them pelican crossings as opposed to zebra crossings were the user doesn't have to wait at all (it is up tothe cars to stop).
But I digress, the little light says … you guessed it, WAIT.
Can you say “hot button?” How about “pet peeve?”
You are right on the mark (as usual) Jack! I suspect that behind it all, there are twisty mazes of “sleep” calls sprinkled about in these systems that were placed there to “get it to work.” Rather than work out the intricate timing details, many seem to opt for “delay execution and lock up (“synchronize”) threads until it works” The result? “Why the heck does it take 5 seconds to respond after pressing enter?”
But Jack – it's not just an embedded phenomena! I once helped a coworker reduce execution time from 10 minutes to under 5 *seconds* by removing gratuitous sleeps and thread-sync-frenzied code.
NASA Jet Propulsion Laboratory
Jack Responds: How many times have you seen in the comments (around a delay loop) “this seems to make it work”? There's this suspicion that slowing things down fixes the hard-to-find bugs.
A lighted pushbutton for crosswalks will only appease pedistrians for ashort while. In time, they will become impatient with the light. Howmany times have you seen folk press a lit elevator call button (c'mon,admit it, you've done it yourself).
As far as the “wait” messages/lights are concerned, are these notrequirement specific? If the client does not want it that way, what is theembedded designer to do? Worse still, if the user interface designer doesnot want it, what is the embedded programmer to do? Jack, I think most ofour ire at these things needs to be directed towards the people who drawup the requirements rather than people who design things based on therequirements.
Philips Software Centre
Jack Responds: Agreed, but let's admit our customers/bosses oftenreally don't know what they want. They have a vague idea… but as wecreate the product and see the problems, isn't it our responsibility tohelp them make the correct decisions?
The pedestrian crosswalk button does not initiate a light change. Insteadit increases the length of the light change, giving the pedestrian moretime to cross. Talk about a counter intuitive design.
I have to admit to using the TV remote control philosophy. I really don'tsee anything wrong with it. I think its very natural for a person to keeppressing a button until they get a response, so why devote scarce resourcesto polling a switch at a tenth second rate, when a half second will work. Idid however provide feedback that the button push worked (with a light).
My guess is the gas pumps suffer from the same problem as a surgicallaser I worked on years ago: the FDA mandated that there bea delay between pressing the “go” button and the actual emission oflaser light. The delay was thought to be a safety feature — anaccidental, presumably short, press would not cause high-intensitylaser light to come out. You had to hold the button down for a fewseconds.
It may be the gas pump delay is mandated by some regulatory body. Ofcourse, it doesn't really help in this case since once the flow of gasbegins you can stop and start it again and get immediate flow. Thelaser product had to reset the go timer each time.
With Windows, of course, it's a whole different story. My charitablecomment is that the slow response there comes from software writerswith more feature ideas than their target has CPU capacity. The othercomment is that people who don't write for embedded systems tend toignore responsiveness issues. Same is true with RAM and hard drivespace…. I'd better stop before I really get into ranting.
Jack Responds: Let's see, while editing this my computer crashed, thenthe thing lost the link to the net… I'll avoid the rant too. Grrrr.
Those annoying delays are there :
- to meet the specification.
- to make it as slow as the “Benchmarked” system.
- to keep the project under budget and meet the ship date. (No more time to clean up the code.)
- because it worked fine with only one system in the test setup.
I am sure there are other reasons.
Engineer (who writes software)
I agree, the lack of positive feedback is at times very agrivating. I also have to agree with one of your responders that in most cases it is a matter of economics, as in the case of the crosswalk, a decision was probably made not to include a light that would not only be extra cost in the beginning but also in maintenance, as the lights would have to be tested on a regular basis and replaced when bad. However, in the case of the Information screen at the aquarium and the gas pump it would obviously cost nothing to display a message like “Please wait while infomation is retrieved”. Another possible explanation of these “blank displays” could be attributed the lack of “real world condition” testing, most testing is done in the lab where everything works at top speeds as opposed to in the field where delays are imposed by busy networks and communication systems.
I also agree that waiting on the hour glass is not my idea of great programming, but, I think an even worse feature of an OS (that is suppose to be so great and wonderful) is the inability to stop (escape or ctrl c) an application that has obviously run amuck, without waiting 2-3 minutes for the OS to decide it has stopped working and then give you the option to kill it.
Larcan Electronics, Inc.
If I had to guess about the gas pump delay, it would be that the pump is talking to the main computer in the store/gas station. The data rate is probably slow to be reliable and may even be time division multiplexed (the main computer polls the pumps)….but it's still annoying!
It seems when there is no feedback (or response) after pressing a button, one will press a second time, only harder. If still no repeonse, press again yet harder. Surely it didn't register a button press because the pressing force was not sufficient.
Guy A. Moore
Jack Responds: Ahah! It's all a plot to drive us mad! Now, if we could only remotely monitor the person's blood pressure and do nothing till he's truly boiling…
I think a lot of times engineers are so zoned into what they build, user interfaces aren't nearly as intuitive as they could be. We need some external testing to get feedback on a design. I must admit I have pushed buttons multiple times or pushed a button “harder” when I know the processor received the signal already. I have found that people expect a response to a button press within a tenth of a second. People also want a reaction on the button press, not on the release, a somewhat subtle distinction.
Jack Responds: Interesting – several folks have said that “testing” is part of the issue. Agreed; in fact my file of embedded disasters is rife with problems that stem from lack of testing.
Poor design occurs because everyone is in a hurry to get the job done. We have a mental block that prohibits asking questions beforehand to clarify issues involved, and feel that's admitting some sort of incompetence/ ignorance. Even worse all that can be fixed in version 2.
Polor Systems and Devices
I recall a story about a piece of software which was used remove the password protection from WordPerfect files. While the software could crack the protection nearly instantly, a sleep routine was introduced to make it look like the program was really working hard.
Jack Responds: How funny! Perception IS reality. It's like the small product I once saw that had extra, unused, hunks of metal inside, just to increase the weight and make it seem more substantial.
Just had to comment on your article about “how slow gas pumps are”.
Absolutely hilarious… all this technology and we cannot make a gas pump bring the gas up from the underground tank any faster!
Actually, I don't know about you, I would rather have my gas stored underground than in the pump. I think it's probably a safety hazard related issue, you know… in case something (car, etc…) was to hit the pump and spill the gas.
And I agree. We need faster networks for those kiosk computers… makes itall more impressive when you press the button and something actually happens.
Anyway, good article.
Bosch Rexroth Canada
There is at least one pedestrian crossing button in Lawrence KS (in front of city hall no less) that IS NOT CONNECTED TO ANYTHING. This was reported in the local paper and supposedly confirmed by city officials. The light is already long enough to allow crossing and operates on a timer so it will always cycle around to a pedestrian friendly green. The button just gives people something to press.
And I have also added delays and “Wait, processing…” screens to programs because the client felt it wasn't possible that the task could have been finished so quickly. They thought they were seeing a dummied-up prototype. I've also changed case material from ABS plastic to 14 gauge steel just for the feeling of weight!
I work at a company that makes the circuit boards for gas pumps. (We don't design them or program them, just build them, so don't send your complaints to me.) The fuel pump is in the underground tank, so when you hit Start, it may have to activate a relay that activates a contactor that turns on the pump, then wait for the fuel to come up the pipes. However, it doesn't get noticeably faster when others are already drawing unleaded regular, so the pump is already on and the pipes already pressurized up to the valves inside the fuel dispenser. (That's the proper name — it's not a gas, and the pump isn't in the part you see.) The rumbling doesn't start for several seconds after hitting Start, and it seems to me that this is a programmed delay before even starting the pump. I also note that this delay occurs in functional test here, where we are electronically simulating the fuel flow, so that delay costs us appreciable labor hours over the course of a year. But their engineers usually leave after 6 months, so there isn't much chance of finding someone that actually understands the firmware…