Channel Hopping Mad!

Why are digital radio and TV such exemplars of a bad user experience?

In the good old days of a small number of analogue broadcast channels, watching TV or listening to the radio was a rewardingly simple process. To watch, listen or record you simply selected a channel, and you had a high expectation that the expected content would be there. The move to digital broadcast radio and television (DAB and DVB) should have increased technical quality and choice while maintaining this ease of use. Instead we have been saddled with an arcane, failure-prone process which offers a dreadful user experience, leaving many users frustrated and angry. It didn’t have to be so, and one wonders what technocratic or bureaucratic nonsense managed to create the mess we have.

I seem to spend a lot of time watching the less technically-minded people in my life struggling with this shocking state of affairs, or apologising to them for it. I myself am technically able, and I can usually get a required result but it often takes a lot more time and effort than it should. Neither is acceptable.

The basic mental model for most users is the following:

Unfortunately in common parlance the terms “channel”, “station”, and “programme” (or program, for our American friends) get used somewhat interchangeably, so I’m going to use the following definitions:

• A “station” is an enduring stream of content from a given broadcaster. BBC1 would be a well-known British example (and hopefully all readers can think of an equivalent).

• A “channel” is an item in the list of content streams which the device can receive. For example Channel 1 might be receiving BBC1.

• A “programme” is an item of content, with the term “recurring programme” referring to both series and regular/daily programming.

• A “preset” is a mechanism to quickly route back to a favourite channel or station.

After a process of “tuning” the device will have a way to present the list of channels and their related stations to the user. As there will be more than a few channels (~200 on my TV) there will be some way to scroll through the list, and a way to assign favourites to a preset. The user can call up a given channel either using its number in the list, or the preset.

A TV will also have a way of reviewing the current and future programmes by channel (the “TV Guide”), and maybe searching for a programme by name. Radios don’t tend to have this.

And we’re already in trouble. People don’t deal well with long lists, so finding what you’re interested in may be tricky. In the UK, they put the original five stations on channels 1-5, fair enough, but the HD versions which you really want are hidden lower down. On our older DAB radios you scroll through the channels one at a time and they are not in alphabetic order, so it becomes a memory test to work out when you’ve reviewed everything. If the station you want is not there it may be because it’s unavailable, it may have changed its name, or you may just have missed it. Conversely there may be duplicate or near-duplicate station names for a range of reasons including technical issues and content variations, but you’ll have to resort to trial and error to find out which one you want.

It wouldn’t be so bad if this was static, but it isn’t. There’s a constant churn:

• New stations start broadcasting, and existing ones stop, or pause.
• Station names change. Sometimes this is a minor change, but it can be significant if the broadcaster does a major branding change, the station changes ownership, or a franchise is re-assigned. It’s also possible for the name to remain the same but the content changes, although that’s not something which can be blamed on the DAB/DVB design.

• Station variants change, or a given channel changes its content variant.

• Station allocations to channels get changed

• The technical details for a station’s signal get changed. (It’s more complicated than just a frequency, but “frequency” will do as a shorthand.)

When a station’s channel allocation or “frequency” change, then your TV or radio may no longer be able to find it. A planned recording will fail. One of the most common, and annoying ways, of detecting a change is via a failed recording of a favourite programme. Alternatively you switch on your radio or TV and the previous tuned-in station, or your presets, are either "dead air" or some completely unrecognised random content.

There’s no reliable way of finding out in advance when you need to re-tune, short of a séance or reading the tea-leaves. After the event some devices may detect a changed channel list and invite you to re-tune, but such reminders rarely tell you what’s actually happened, and they come so frequently (more than once a week in our locale) that you tend to ignore them until you find something “wrong”.

If the designers of the DAB/DVB system (as least as implemented in the UK) had thought about the user experience, or had even the slightest knowledge of integration interface design, then it wouldn’t have to be this way. For example, whether you’re consuming an API or filling in official forms the usual practice when an "interface" changes is to allow the old one to continue but "deprecated" for a short period of time while people switch to the new one. Not in the DAB/DVB world – the service gets removed from where it was on the day it moves to the new location, and you have to re-tune. During the UK’s big "digital switch over" event I had to re-tune every device in my house on a specific day, three times.

Let’s put some more technical detail behind the average user’s mental model of this system:

That may be slightly tongue in cheek, but only slightly…

So let’s think about how it might work better. Here are some principles:

• A digital TV is a computer.
• A digital radio is a computer.

• Computers are good at doing technical stuff, humans aren’t. The technical stuff should be invisible to the user.

• Long undifferentiated lists are bad. Long lists with no obvious structure or order are worse. Lists of 7±2 things are good.

The primary concept for using a TV or radio is the station. I want BBC1. Here are some things I don’t want to be bothered with:

• Hunting through hundreds of other stations

• Which channel or channels BBC1 is assigned to, and any changes

• Which frequencies the channels are assigned to, and any changes

• Technical variants of a station. I should automatically get the best available version.

• Content variants of a station, unless I manually select one in which case that becomes my selection.

Taking these together, a simpler model emerges. First the channel list needs to become a station list – channels are a meaningless technical detail. It also shouldn’t actually be a list – that’s a very crude solution for 200+ items. The obvious solution is some sort of tree or accordion structure, so that first you choose from a short list of broad groups ("General entertainment", "News", "Movies", "Kids", "Shopping", "Adult", "Radio" etc.), then maybe from a second level, then from a shorter list. Obviously a good user interface would remember where you were last… As the objective is to make things easier for the user, there’s no reason why a station might not show up in more than one place if that’s appropriate, and on a graphical display there should be a search option.

The list shouldn’t by default show station variants, although there might be an option to drill down to those if a user really wants it. Once I’m watching a given station it should automatically show the best available technical variant (e.g. HD TV), switching automatically but temporarily to a lesser variant if required, and switching back as soon as possible. This would prevent the abomination of the BBC "red screen of death" advising you that it cannot show local content on BBC1HD and you need to manually switch to SD.

If a station has content variations (e.g. for local news) the receiver should default automatically to the most popular variant, but I should be able to manually select an alternative. Again, if my selected variant is not available then the receiver should automatically show an alternate, but only until the preferred selection is available.

This then admits a much simpler mental model, which actually addresses the needs of the user, not some arcane technical complexities:

Tuning should simply not be visible to the user in any form. If there have been technical changes which do not affect the station I am currently watching or listening to, these should be automatically dealt with in the background. I should only be told if there’s a problem which will stop me accessing a preset or favourite station.

If changes affect my current station, then in an ideal world they would be communicated to the receiver in advance, and the receiver would automatically apply them at the right time, or, even better, the old technical details would continue to work for a crossover period to allow receivers to catch up seamlessly. In a less than ideal world if the receiver is switched on and technical details have changed for the selected station then the first thing it does is retune that station, and then process other changes in the background.

If the station name has changed, but the content hasn’t, the receiver should just handle this transparently. Obviously that means that behind the scenes there needs to be some form of persistent station ID independent of visible name, but that’s something that we deal with all the time in the IT world, it’s really not rocket science.

The only circumstance in which switching on the receiver should result in dead air or a random station is if the preferred station has permanently ceased broadcasting. Nothing else.

It’s not difficult to think of a model which would actually make digital TV and radio usable, and it’s inexplicable why broadcasters and manufacturers have made such an appalling job of it so far.

In the meantime, our DAB radio sits tuned to FM, and our TVs are all tuned perpetually to channel 231 (or is it 130?) for BBC News, except on the HD ones where it’s 107, until the next change… Oh well.