Category Archives: Agile & Architecture

Agile Development & Software Architecture

Channel Hopping Mad!

DAB Anger
Resolution: 952 x 628

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.

View featured image in Album
Posted in Agile & Architecture, Thoughts on the World | Leave a comment

Why REST Doesn’t Make Life More Rest-full

As I have observed before, IT as a field is highly driven by both fashion and received wisdom, and it can be difficult to challenge the commonly accepted position. In the current world it is barely more politically acceptable to Continue reading

Monday, February 19, 2018 in Agile & Architecture, Code & Development

The Architect’s USP

Very early on in any course in marketing or economics you will encounter the concept of the "Unique Selling Proposition", the USP, that factor which differentiates a given product or service from its competitors. It’s "what you have that competitors Continue reading

Friday, February 2, 2018 in Agile & Architecture

Testing vs Modelling, Detection vs Prediction, Hope vs Knowledge

The Challenge I often hear a statement which worries me, especially but not exclusively in agile projects, along the lines of “we’ll make sure it works when we test it later”. Now you may think this is an odd view Continue reading

Wednesday, December 6, 2017 in Agile & Architecture

Does Agile Miss The Point About Engineering?

A former colleague, Neil Schiller, recently wrote an excellent article, https://www.linkedin.com/pulse/agile-data-programmes-neil-schiller/, on the challenge of using agile approaches in data-centric programmes. In it, he referenced and reviewed a classic cartoon by Henrik Kniberg which is often used to promote the Continue reading

Wednesday, November 22, 2017 in Agile & Architecture

Architecture Lessons from a Watch Collection

I recently started a watch collection. To be different, to control costs and to honour a style which I have long liked, all my watches are hybrid analogue/digital models. Within that constraint, they vary widely in age, cost, manufacturer and Continue reading

Saturday, November 4, 2017 in Agile & Architecture, Thoughts on the World, Watches

Integration Or Incantation?

I was travelling recently with Virgin Atlantic. I went to check in online, typed in my booking code and selected both our names, clicked "Next", and got an odd error saying that I couldn’t check in. I wondered momentarily if Continue reading

Sunday, October 29, 2017 in Agile & Architecture, Thoughts on the World

How Strong Is Your Programming Language?

I write this with slight trepidation as I don’t want to provoke a "religious" discussion. I would appreciate comments focused on the engineering issues I have highlighted. I’m in the middle of learning some new programming tools and languages, and Continue reading

Monday, March 20, 2017 in Agile & Architecture, Code & Development

Why I (Still) Do Programming

It’s an oddity that although I sell most of my time as a senior software architect, and can also afford to purchase software I need, I still spend a lot of time programming, writing code. Twenty-five years ago people a Continue reading

Monday, March 6, 2017 in Agile & Architecture, Code & Development, Thoughts on the World

The Perfect is the Enemy of the Good

The Perfect is the Enemy of the Good. I’m not sure who first explained this to me, but I’m pretty sure it was my school metalwork teacher, Mr Bickle. Physically and vocally he was a cross between Nigel Green and Continue reading

Monday, February 27, 2017 in Agile & Architecture, Myanmar Travel Blog, Thoughts on the World, Travel

Software Design Decoded

This is a delightful little book on the perennial topic of how a software architect should think and behave. While that subject seems to attract shorter books, this one is very concise – the main content is just 66 two-page Continue reading

Tuesday, February 7, 2017 in Agile & Architecture, Reviews

Form vs Function – a Tail :) of Three Mice

Just in case you think some of my recent posts have been a bit anti-Microsoft, here’s one in which (spoiler alert!) they win! Call me old-fashioned, but I very much prefer using a mouse to a trackpad or its relatives, Continue reading

Friday, September 30, 2016 in Agile & Architecture, PCs/Laptops