The need for speed
Technology is constantly improving but sometimes it’s still just too slow. Geoff Meads serves up a beach volleyball of insight on how we can make UX better.
As I sit to write this column the film ‘Top Gun: Maverick’ is out and smashing all sorts of box office records. I think I can comfortably predict the film, in all its special effects and CGI glory, will become a home cinema demo favourite at this years’ expos and probably beyond.
However, it is a line from the original ‘Top Gun’ film, uttered in unison by Maverick and Goose, that comes to mind when thinking about user experience and home technology: “I feel the need, the need for speed.”
While there’s a long list of elements that go toward producing a great user experience in home technology, speed is perhaps the most obvious and immediately valuable one. Most of us have grown up with computers and earlier smart phones, that were, to put it kindly, ‘sluggish’. It was something we got used to and our learned muscle memory actions when using these devices took account of the lag.
Inevitably, as is generally the case with developing technology, later devices responded faster and faster to user inputs and, with each generation, increased speed became a highly saleable and easily demonstrable advantage when launching new models.
Today’s smart phones are almost instant in their response to most commands, and this gives our industry a problem. Instant response has become the de-facto expectation when using technology. Current smart phones and, as we shall see later, old school technology are important benchmarks we should use to measure the user experience of our systems.
So, what affects speed?
There is a long list of factors that affect the response speed of devices and systems. So, let’s look at some of the big players in this list and identify areas where we, the system integrator, can improve things.
Before we specify control equipment, we need a way of getting data from individual rooms to the head end processor and back again. While methods like Infra-Red (IR) and RS232 still exist, most communications are done via the IP network these days. This combination of wired and wireless IP communication that make up the average home network has a huge job to do in a home. This is especially true if it’s also responsible for AV distribution.
As a result, transit times can increase and system response speed drops if the network is inadequate.
There are some key things we can do to help the situation when implementing a network.
Firstly, pushing as many devices as possible to the wired part of the network will ease congestion on the (natively fragile) wireless parts. My rule is this: if it doesn’t move, wire it.
Secondly, think about and over specify ‘trunk routes’. These are parts of the network which carry the most data. The routes between head ends, individual buildings and those that run between floors of a building are often considered ‘trunk routes’.
For these we specify the highest bandwidth transport method possible. For example, my usual approach for trunk routes is always: can I use fibre?
At the heart of every control system, be it single room, single sub-system (i.e., lighting) or whole home, is the control processor(s). These complex devices deal with a multitude of tasks such as receiving inputs, processing incoming data against a set of logical rules, a truth table or a program running logic decisions, and then outputting resulting commands to external devices.
The story doesn’t stop there though. In many cases devices that have received commands will then return a response (as confirmation that a command has been carried out) and sometimes confirm the new setting as part of that response. This information is then passed back to the user interface (keypad, phone app or remote handset) via the processor so that it can update its display.
This process is a common cause of lag or latency between a button press and a resulting change on the commanding interface and the resulting sluggishness can be both frustrating and confusing.
With more and more sub-systems being added to the processor, and increasing cross-system interaction too, it’s imperative that the chosen processor is not specified to just ‘do the job’. It should be specified such that it can do the job with bandwidth to spare so as not to become a bottleneck.
Avoiding the cloud
If there’s one thing that really slows down systems right now, it’s a need to communicate with the internet (or ‘cloud’ if you prefer). Any communication with servers located on the internet will introduce additional, variable delays to a system’s response time.
A good example of this can be seen with voice control. As clever as Alexa, Siri and Google Home are, they still normally need to send voiceprints ‘home’ to their native, distantly located servers for processing before a response can be generated. This can introduce delays from a few seconds upwards adding frustration and inconsistency to the user experience.
While our customers have come to expect voice control (and it is still fun to use and highly practical if you have your hands full) we cannot rely on it as the primary control method for essential systems such as lighting and security for reasons of delay and reliability. The time delay between command and response is simply too long.
Old technology is an important benchmark
When assessing the performance of any system we can use a simple barometer to judge success. Ask yourself this: is my system quicker than the ‘old school’ version?
For example, I recently read a report on a new dealer’s show room where they boasted about a single voice command, used when entering the showroom, that would set all the lights in the building to a pre-set ‘welcome’ scene in under 20 seconds. 20 seconds? There’s a bloke down my pub that can eat a Big Mac in less time! (sic).
The point here is that, by comparison, a conventional light switch responds instantly, predictably, and reliably. Until our systems can do the same job in the same (or less) time, we still have work to do on creating a great user experience with control technology.