Showing posts with label music scheduling. Show all posts
Showing posts with label music scheduling. Show all posts

Thursday, 17 January 2013

Angela Bond - an appreciation

An old friend and long-time mentor, Angela Bond, died last week. She changed Radio.


Angela with Kenny Everett back in the day
Angela Bond was one of a kind. An old school radio pro; you couldn’t find better. 

Her worldwide career spanned singing, presenting, producing (Kenny Everett and Ed Stewart, among others, at Radio 1), slugging her way through BBC seventies and eighties bureaucracy, and then ushering in some of the most seismic changes to hit UK music radio, as the first person to rep Selector, the original music scheduling software, for the UK. 

While people outside radio - and many inside - may well not have even heard of Angela, it's almost impossible to calculate, let alone explain, the impact she had.

Wednesday, 7 April 2010

Case Histories and conclusions

The Track Record page here and on my website has turned out to be of the most consistently visited pages. To build on this, I’ve just gussied my website with some of the more interesting Selector case histories. If you’re at all interested in music scheduling in radio, there may be stuff to glean; feel free to help yourself. 

The case histories are, in chronological order:

BRMB-FM / Xtra-AM: the highs and lows of introducing computer scheduling. Very early 90s.
BBC Radio 2: putting in a multi-genre library, along with the BBC's very first digital playout rig.
Swedish Radio P4: developing client skills in hugely varied markets.
RTÉ lyric fm: working collaboratively with passionately involved production staff to build not so much a database as a knowledge base. The polar opposite of most implementations.
UTV Radio: upskilling staff and debugging inherited nightmare scheduling conflicts.
Coast 106: swimming successfully against the UK radio stream with a larger than normal library.

In this diverse range of situations, there are some common threads...
First : dialogue, up and down the chain of command,  is good. In fact, in my view it’s not so much good as essential. While many radio stations implement a rigid schedule from above, normally for ease and simplicity of management, some of the best ideas and approaches evolve from engaging with the staff who work with the system. Nobody is right all the time. If there is a conflict, either with content or with programming, it’s often very useful to examine that conflict in minute detail, so see if there is a better way to do things. Best to leave your ego at the door, though. I won’t name the middle manager who loved the idea of challenging his boss on music issues, but hated the idea of talking to his own staff about those same issues.

Second: We’re in the era of tiny databases. In the US, they’re now talking about cutting down from 150 to 50 songs. However, almost all the above case histories show ratings success allied to larger libraries. 

Third: A note to managers: large databases can be a pain to keep tidy. And talking to your staff about programming issues can be a hassle you could do without. Things can get emotive. It can eat into your time, and not everybody has that luxury. But I suggest that if you actually care about what you do, you’ll benefit from putting in that time. Radio is still full of passionate people. You’ll get the best out of those people if you meet them halfway, here and everywhere else where ideas can be shared and debated.

Thursday, 18 February 2010

My Selector Coloring book: Selector Tips 3

This topic mainly applies to Selector version 15 lovers. You can do a bit of color tweakage in Version 12 (that’s the old, ugly, but gorgeously stable and well thought out dos version), but it’s really the windows version of Selector that lets you play with looks, fonts and colors. There’s lots of configuration potential in GSelector, too, but that hasn’t fully rolled out worldwide, and I’m quite sure that these remarks will also apply just as much to other scheduling engines. Bottom line? Customise away, but you should avoid the explosion in the paint factory effect at all costs.

Why is it that contemporary software design is so…. uniform? There’s a very good reason. Computer screens can display a LOT of information. Color is a great help is highlighting areas of concern, and you can often set conditions in your software package – not just your scheduling engine – which will throw a focus on an area of interest, by using a specific color.

But if you make things too busy, your brain has to work a lot harder to take it all in. If the screen is just too busy, you tend to jump past all this information.

Now let’s consider the Editor screen. That’s the one that displays your schedule, or running order. You’ve got to review an entire day of output – that's at least 24 screens, maybe much more.  If the entire screen is a maze of color, you’re going to have a hard time concentrating as hard as you need to for your editing job… which means you might let something slip past… which means the output might sound lousy.

So that’s why I suggest you go easy on the color.  If you like to differentiate between different categories onscreen, that’s fine – but try using shades of the same color, rather than violently clashing and distinct colors. Leave the fireworks for the emergency conditions: schedule failures and the like. And think about whether you need to apply color to the entire page – you can restrict it to one or two fields if you prefer, leaving the rest of the window more uniform.

Above all, make it easy on yourself, so you can make those critical editorial decisions: getting the mix right is way more important than having a pretty screen display that your audience doesn’t know or care about.

If this has been useful, pass it on to friends and colleagues. It’s on me. If you'd like more on a 1 to 1 basis, reply to me through the blog, or email me via the website (link at left under Work-related)
.