Ignore feral user behavior at your peril - Embedded.com

Ignore feral user behavior at your peril

As I've mentioned many times in the past, in one specific wording form or another, most folks aren't enamored with technology in and of itself (although the widespread and booming enthusiasm for regular smartphone upgrades admittedly runs counter to the trend).

Technology is a means to a different end (sending and receiving email, communicating with old friends and making new ones, taking and sharing pictures and videos, reading books and magazines and watching TV episodes and movies anywhere and any time, etc), versus an end in and of itself.

As such, it's interesting for me to observe how the “average person” uses (and sometimes abuses, and sometimes also doesn't use) technology, in contrast to us “techies”.

Sometimes this contrast is suggestive of an untapped market opportunity that I'd suggest you in the product definition and development worlds might want to pay attention to. Other times, my suggestions are more along the lines of “don't overlook this use-and-abuse, even if you'd never personally consider doing it, because if your product breaks as a result, you're the one who'll get blamed.”

To wit, here are a few recent observations:

•    Folks generally don't bother installing operating system and application patches. They always seem to be too busy, and prone to putting it off until “tomorrow”…a tomorrow which never comes. The situation's probably a bit better than in the old days, when you had to remember to periodically peruse a software manufacturer's support website in your abundant spare time (hah) for listings on the product(s) you owned, compare posted version numbers against whatever version you already had installed, and upgrade if necessary. Now, at least, most programs alert you to the presence of an update…although too often, the “update” button does nothing more than launch a browser window to the manufacturer's support website. Better yet, and thankfully increasingly the case, is the ability to download and install the update directly from the alert window. Still, in such cases, some update utilities don't bother telling you in advance whether or not a subsequent system reboot will be necessary, and at least one annoying offender doesn't even provide you a means of temporarily canceling the post-update system reboot. So my suggestions include:

  • Provide an always-running auto-monitor utility (which consumes scant system resources, please) that checks for available updates and alerts the user to their presence
  • Give the utility the ability to directly download and install the update
  • Only force a post-update system reboot if it's absolutely necessary; do whatever you can to work around this perceived hassle (therefore update-acceptance barrier)
  • Alert the user in advance if a post-update system reboot will be necessary, and more generally provide a means for in-advance delaying or canceling the update.
  • And resign yourself to the reality that no matter how painless you make the update, a notable percentage of users will never acquiesce to installing it…so make your rev. 0 code as robust as possible.

•    Speaking of updates, Windows 7 has seemingly recently added a “feature” wherein even if you have Windows Updates configured to “download updates but let me choose whether to install them, say, versus “Install updates automatically (recommended),” it will still auto-install critical updates when you reboot or power down the system. This can, I'm sure you imagine, be perceived as inconvenient and otherwise annoying. I personally witnessed a friend, trying to shut down her laptop en route to the airport, who almost hard-powered off the system when she got the “Installing updates…” notification. More generally, “sh*t sometimes happens,” as the saying goes….premises power goes down mid-update, an imperfect update utility locks up or otherwise glitches, etc. So here are my suggestions this time:

  • Don't do something other than what you say you're going to do, i.e. don't force updates on someone who's explicitly overridden the default and indicated that they want control over when the updates occur, and
  • Provide an ironclad return-to-prior-version scheme to enable full recovery from an incomplete update.

•    Some friends recently used one of my Xbox 360s for a week-plus. They admittedly played a lot of games on it. But they pretty much left it on 24 hours a day. I've seen similar behavior with TVs, computers, set-top boxes, and any number of other AC-powered devices (anything battery-powered, perhaps obviously, has finite uptime defined by the stored charge capacity). To some degree, this is by design…when you turned the Nintendo Wii “off”, for example, it by default remained network-connected and otherwise in a state where it could receive system updates, messages, etc. And it's not like folks that do this are being intentionally “sloppy;” they just don't get the wear-and-tear (not to mention electricity bill) impacts of their actions or, perhaps more accurately, inactions. But in acknowledgment of this reality:

  • Make your system designs as robust as possible for long-term continuous use, even if the usage pattern you envision is more sporadic. Moving mechanical parts (i.e. air-circulation fans, etc) are particularly suspect to wear-out, and
  • Implement pseudo-standby support after a detected period of non-use, to reduce power consumption, but don't make the subsequent return to full-active mode glitchy or excessively lengthy

That's it for this week. Stay tuned for more consumer-behavior observations to come in next week's post. Until then, I as-always welcome your thoughts.

Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance. He is also a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company's online newsletter. And he's an off-hours freelancer as the Principal at Sierra Media, where he contributes to (among other things) the Brian's Brain blog at EDN Magazine. Brian has a BSEE from Purdue University in West Lafayette, IN. His professional career began at Magnavox Electronics Systems in Fort Wayne, IN, where he worked for an aggregate 2.5 years as a co-op engineer. Brian subsequently spent eight years at Intel Corporation in Folsom, CA, holding a variety of roles in the company's nonvolatile memory group. During this time, Brian also authored and co-authored four technical reference guides published by Annabooks Press. He then spent 14 years (and five months) at EDN Magazine; at the conclusion of his career there, he was the senior technical editor covering consumer electronics-targeted ICs, software and subsystems.

This blog was previously published on Embedded.com’s sister publication, EDN Magazine. 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.