[Implementation Working Group] Brands and Groupings

[RadioEPG developers]

Dear All,

As promised, I'm going to fire over some points for the group to discuss. It would be great to get the widest range of views on this, starting with the following general questions:

* What different ways do Broadcasters structure their Brands and Stations?

* How can RadioEPG accommodate these preferences in a way that fits for both Broadcasters and Device Manufacturers?

* How does a device select what stations to show, and in what order and grouping?

I've attached a set of scenarios to get the questions flowing, which you can find at the following link:

https://docs.google.com/document/d/1KfsqLE7eWbb9o57zV9C8TxWkvG_hYvSpBVLh1O_uYbU/pub

This details 3 broadcasters (chosen almost entirely not at random), and their radio brands. I'll highlight what I think the arrangement is (in italics - correct me if I'm wrong!) and any questions (in bold) that arise from considering their requirements.

I'm also interested in you each detailing your own scenarios and opinions.

Broadcasters - What are your station and brand arrangements, and how would you wish these be shown on a device?

Aggregators - How do you ingest and surface information in your apps/interfaces/systems?

Device Manufactures - How does your interface show service lists? What rules govern where a service is shown, and what considerations are there when device constraints are taken into account?

There is hopefully a lot to discuss above, and its important we get as much in discussion as possible, so we can reveal potential problems. We can then work out how to accommodate these requirements in a future version of the specification.

Best regards,

Ben Poor

[Sebasti...@swr.de]

Hi Ben,

Many thanks for opening up this discussion. For the German public radio
brands (i.e. ARD) I'd answer the following:

* What different ways do Broadcasters structure their Brands and Stations?

We're grouping our several stations as equal brands. Usually the leading
stations first, followed by the digital-only, part-time or event stations.
If stations have extra internet streams, these are usually sorted under the
main brand. The stations of an ARD broadcaster are always listed together
as a block, although this block is not necessarily marked or outlined
seperately. As internal agreemant it is deemend that, if other ARD
broadcasters can be discovered as well, the broadcaster which is customary
in place should be listed first.

* How can RadioEPG accommodate these preferences in a way that fits for
both Broadcasters and Device Manufacturers?

We're signalling RadioDNS services exclusively for our DAB brands. So
basically we'd expect that RadioDNS service discovery follows the usual
behaviour on such a device ... i.e. scanning, service listing
(unfortunately in alphabetical order and not as described above), tuning
into one station, look-up of additional (RadioDNS) services. If a device
offers central access to the RadioEPG functionality I'm afraid to give a
general answer at the moment. My feeling would be that this depends on the
use cases which are implemented on the device. I've formulated such for the
digital radio working group at our DoC. Please find attached ... I'd feel a
bit more comfortable if we could look a bit deeper into use cases before
trying to sketch recever behaviour.

* How does a device select what stations to show, and in what order and
grouping?

FM and DAB: Only receivable stations should be shown ... preferably as
described above
Internet: Stations customary in place should be shown first in alphabetical
order (preferably as described above) ... if we we're e.g. in Bavaria all
"Antenne Bayern" stations would be listed first followed by the "Bayrischer
Rundfunk" stations.

However this means that the devices must clean up the service listing
automatically ... a requirement that I'm requesting already for a longer
time but which seems not so easy to implement at a reasonable price :-(


/majestic plural off/

:-)

(See attached file: Annex E_2014-01-07.doc)

Kind Regards
Sebastian

[Ben Poor]

Hi Sebastian,

Thanks for that, its good to know expectations of what will happen.

I think probably the use-cases and receiver behaviour are bound up and cannot be separated. I'm keen to take the different ways in which people expect their own services to surface on a device, and then see what happens when they're all combined. 

After all, a device will scan across all FM frequencies, DAB ensembles *and* also have to combine those with IP services.

Heres some short mockups of service listings on a device using the original scenarios I proposed (you may notice I'm no graphic designer):

BBC

Antenne Bayern

Global Radio

(showing an expanded 'grouping' of Heart Stations, with a few of the grouped stations shown)

So a slightly different way of asking some of my previous questions is:

How would these individual service lists from each broadcaster's XSI document be combined on a practical device?

How would navigation work?

I think capturing guidance for devices here is important, as you mention. 

Should a device attempt to collate all services for ever? From a users point of view that will mean a very long service list. 

Should a device support grouping of services? For Global Radio this is desirable - is it important for any other broadcaster?

Keep the thoughts coming, as I'm sure we'll uncover some interesting scenarious.

Ben

--
You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Nick Piggott (RadioDNS)]

Hi Ben,

That's very helpful.

Are the diagrams built in some package (powerpoint?) that you could share, so people can tweak them?

I think the service listings should show that some services are broadcast and some are streaming. Maybe a F/D/S or some icon?

What are the implications of a service provider defining a large number of streaming services in their XSI - who would that affect the navigation of services?

Nick

--

Nick Piggott

Chair

RadioDNS

www.radiodns.org // @radiodns // +44 (0) 1600 888335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 96a Curtain Road, LONDON, EC2A 3AA.

[Sebasti...@swr.de]

Hi Ben

I think grouping of services as you outlined for Global (really good
graphic by the way) will be also relevant for ARD and probably also for
other broadcasters with more than one brand. At least if they want to
include all the extra/event/internet streams into the service listing.

Just that I don't misunderstand you: We're talking about the ui of an
off-the-shelf device (where manufacturers usually say: "the ui is mine")
which is switched on by a user and then presents the station listing in a
way that we (the broadcasters) prefer. Right?!

If so I'd expect that:

(1) the device scans through all frequencies/ensembles, and groups all
available stations in the service listing according to my previous
description

(2) the device performs the RadioDNS look-up for all available stations and
collates/expands the existing service listing with the internet(-only)
stations (specified in the XSI) according to your mockup

(3) the device presents the so created service listing forever but would
have to double-check from time to time if the XSI data found is still valid
and if the internet stations are still 'online'

Some sort of iconing behind or in front of the station names (as Nick
wrote) would be good ... at least some sort of evidence that radio
listening via internet produces traffic hence costs money (in case the
device is connected via mobile internet).


In the XSI it would require the possibility to group brands e.g. by
defining the superior station (if we want to reduce to mother-child
grouping) or some sort of grouping levels (if we want to allow multiple
levels). My current feeling would be to allow just one level of grouping.

On the device it would require to offer a mutual service listing and to
perform regular checks for the latest XSI and the availability of the
internet streams. A requirement which could be hard to realize on simple
(single-tuner?) devices ... but that's only a feeling.


Do you agree? Or does the above lead into the wrong direction ...?!


Best
Sebastian

[Ben Poor]

The original diagrams were hastily assembled in a proprietary package. I've redrawn them in Google Docs, which anyone should be able to use/amend as they wish:

https://docs.google.com/a/radiodns.org/drawings/d/1rqUE3lOHv8UUR1yyhsfCl-cExyda_YNpYBESZOPdj3k/edit?usp=sharing

I've kept an original copy, so let me know if it needs to be restored.

I think having some kind of indication on a device how a service is to be received would be useful - at least an icon to determine between broadcast (not affecting any data limitations) and non-broadcast (may affect data limitations and incur cost).

As you can see in the newer diagram above, I've more explicitly indicated how a device might cope with bigger groups, like the Heart Network. In this example, the group 'head' is nominated in the XSI file [Heart London], and the device has selected another station in the group due to it being available on broadcast (and thus can be deemed 'local') [Heart Cambridge].

Your question on large amounts of streaming services is interesting and I'd be interested in hearing what people think should happen. Should they appear after a primary list of broadcast station (+ possibly, any stations on non-broadcast that have previously been 'favourited' by the user)?.

Ben

To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-developers+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-developers+unsub...@googlegroups.com.

[Ben Poor]

Hi Sebastian,

I agree with almost all you say. Brand grouping is important for Global Radio and other broadcasters (as you mention), and having a 'lead' station would also be desirable for us. I'm thinking some indication of an 'index' for grouped stations would cover this requirement nicely, but I'll have to expand on that later with some examples.

Seems as if we're also agreed on the benefits of having an icon to show what platform/bearer a station may be received on. This should be discreet, but available to the user.

To clarify - we are indeed talking about a User Interface of an off-the-shelf device, be that one in the kitchen, bedroom or in the car. In this discussion we're putting together guidelines to make a better user experience for listeners, reflecting the wishes of the broadcasters for their own stations.

I think the topic of *how* a device acquires and subsequently stores stations is one of the most important things for us to discuss. I'm going to break that out into a separate topic, so we can focus on that separately.

Ben

[Paolo @ RadioDNS]

Hi Ben and all,
thank you for underlining this point.
For us it's very important the possibility to group our own stations, choosing the priority order inside the group too.

Best regards
Paolo

[Paolo @ RadioDNS]

Dear Ben and all,
I would explicitly introduce a possible issue, related with the stations lists question.

The point is: we will have a list including broadcast stations and also all receivable internet radios (all those compliant with the RadioEPG standard). Maybe this means thousands of items, with let's say, Radio 1 (millions of listeners) together with tens or hundreds of other internet radio stations (followed by tens of listeners). Hard to find Radio 1. Probably the user experience could be confusing, specially at first radio switch-on. For Digital Terrestrial Television we have LCN (Logical Channel Number), but this case is even more complicated.

Should this issue be solved exclusively by each individual device manufacturer or is there something that can be done here to improve this behaviour? Can we positively influence service listing order in some way?

Best regards
Paolo

--

[Paolo]

Dear Ben and all,
I would explicitly introduce a possible issue, related with the stations lists question.

The point is: we will have a list including broadcast stations and also all receivable internet radios (all those compliant with the RadioEPG standard). Maybe this means thousands of items, with let's say, Radio 1 (millions of listeners) together with tens or hundreds of other internet radio stations (followed by tens of listeners). Hard to find Radio 1. Probably the user experience could be confusing, specially at first radio switch-on. For Digital Terrestrial Television we have LCN (Logical Channel Number), but this case is even more complicated.

Should this issue be solved exclusively by each individual device manufacturer or is there something that can be done here to improve this behaviour? Can we positively influence service listing order in some way?

Best regards
Paolo


Il 06/01/2014 13:01, RadioEPG developers ha scritto:

--

[Sebasti...@swr.de]

Good morning,

That's indeed a good point, but my guess is that this shouldn't be a
problem here. According to Ben's great summary
(https://groups.google.com/forum/#!topic/radioepg-developers/ZNbyLeGE7D8).
To create the 'master (station) list' the device will only scan for
available stations in the broadcast bands and then add internet stations,
which are linked in the corresponding RadioEPG XSI's of the broadcast
stations found before. In this way we shouldn't run into the problem of
getting a service listing with hundreds of thousands of small internet
radio stations, but a service listing which contains not only the broadcast
stations but also the internet/event/blah-blah-blah stations.

I'll do a short graphics summary in the other thread.

Best
Sebastian.

[Paolo @ RadioDNS]

Good morning Sebastian,
thank you for your feedback. So that's how the device could behave. My
doubt is: are we sure average implementations won't use a pure
alphabetical order for the stations? So, it would be (very) desirable to
explicitly point out, in the specs or guidelines, that the "master"
station list should be placed on top, going beyond a simple alphabetical
order.

Also, is there some other step we can do to mitigate the possibility
that popular stations will not be drowned among tens or thousands of
other less relevant ones? In the case in the future almost all devices
will be hybrid, this fact will directly influence the audience and the
user experience.

Maybe we'll probably have a user editable favourite stations selection
(just viewing already available devices and apps). And probably some
manufacturers and app creators will put an initial, predefined list of
favourite to mitigate the "cold-start". Could we influence this feature
in this moment, in some way? (Of course I'm *not* talking of putting a
list of popular stations in the specs).

Best regards
Paolo

[Nick Piggott (RadioDNS)]

Hi Sebastian,

If I were an *bad* broadcaster (and some might be), I might be tempted to include *lots* of Internet radio stations in my XSI to crowd out the navigation list.

We can stop that being a problem by only putting services that can be received by *broadcast* in the main listing. (So only listing FM services on an FM radio, and listing DAB services on a DAB radio).

All the other services in a broadcaster's XSI are listed as children of a broadcast service, and are in a list that has to be expanded. (A bit like Secondary Services on DAB?). If the user don't expand the list, they only see the broadcast stations - which will usually be 20-60 services? That feels manageable.

I'm expecting a device manufacturer (hello - any automotive people?) to say there must be a maximum number of stations?

Nick

--

Nick Piggott

Chair

RadioDNS

www.radiodns.org // @radiodns // +44 (0) 1600 888335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 96a Curtain Road, LONDON, EC2A 3AA.