I mean really, when’s the last time you used the “stop” button?

In a previous post, I talked about going through your old bag of programming tricks and eliminating those that are either outdated or just no longer practical. This post is along the same lines, as it about getting rid of things you don’t need. Many programmers, myself included, tend to fall into the habit of what I call “conditioned programming”. We program systems the way are used to and we don’t really stop to think about what we’re doing from one system to the next. This often leads to stubbornness or bullheadedness on the part of the programmer when asked why the system works the way it does. We get defensive; after all, it’s not our problem that the customer was sold a product that is way over his head, we just program the commands that are on the factory remote, right? Well, frustration with misleading sales staff aside, it is always in the programmer’s best interest to analyze and evaluate the needs of the customer for each system he or she programs.

Many end users can tell you right away that they never use certain commands for a particular device. This can clear up confusion from the get-go, reduce clutter on the touch panel and ultimately make the system much easier for the customer to operate. You can also make some executive decisions of your own and give the axe to buttons and commands that you’ve been including for years but are seldom used by most of your customers. I just recently had the revelation that the “stop” command could be eliminated from a number of devices for which I had been habitually including it. And if you’re still putting the “angle” button on your DVD pages you should really be taken out back and taught a lesson. Seriously though, if you are an efficient programmer it will be no big deal to add these obscure commands back in if the customer specifically requests them. I personally find it helpful to create an Excel spreadsheet that lists optional device commands and system features so I can fill it out when I meet with a customer (of course, this could be due to the fact that I am an organizational freak who will find any excuse I can to create an Excel spreadsheet).

If you are already following the programming practices I’ve outlined here, I’m sorry you just wasted your time reading this, but if you quite often fall into the habit of “conditioned programming”, I think you will find it helpful to start analyzing your projects a little more. It will make your customers happier, reduce service calls, and keep you in the habit of regularly revisiting your programming practices.


“Press and Hold” is a hard habit to break

For a long time I programmed “room off” buttons to turn the whole house off when pressed and held for two seconds.  I developed this habit back in my days of programming Xantech and Elan keypads and I continued to do it until recently when I realized that even though it was a well known trick of the trade for programmers, it was not intuitive for my customers.  Nobody ever instinctively knew to hold a button to trigger a secondary function, it always had to be explained.  This is not to say that implementing “press and hold” logic never has it’s place. It’s still a viable option for in-wall keypads and hard-button-only, handheld remotes; but wherever there is a touch panel there is always a more logical way to accomplish your objective.  In the case of my “whole house off” example, a “system off” page with the option to turn off one room or the entire house is a much better option.  It is not only more intuitive but it gives the user the chance to “go back” and do nothing if she inadvertently hit the “off” button.  I realize this is not a new concept and many of you already program this way.  My point with this entry is to encourage you to periodically go through your collection of age-old programming techniques and habits and get rid of the ones that no longer make sense or are simply unnecessary due to advances in the industry.  You might be surprised at what you find!