Proposal <podcast:styleguide> branding information and consistency

[scottmathson]

A common request at Plink has been to surface the podcast's color scheme and styleguide on-page for show's and episode's app links landing pages.

Completely fair, and I think that if more apps and services embodied a custom-style per-page, player embeds, etc. for every show, this would holistically give more branding to shows across platforms. Beyond the basics of show- and episode-level imagery, surfacing brand colors would create a better visual connection to podcasts.

This proposal assumes something like: <podcast:styleguide primaryColor="#FFD000" secondaryColor="#111111" />

Of course taking this a step beyond the proposed color hex codes, adopting primary and secondary typeface/font attributes would provide even more styleguide consistency.

The goal here is to put the podcast's visual brand and styleguide front-and-center versus the platform's or app's.

[theDanielJLewis]

I really like this idea! I could add this support to the shareable reviews and Love the Podcast pages from My Podcast Reviews.

We would need to figure out how to either solve or advise how to handle light and dark modes or even simply foreground text color.

[jamescridland]

This is really nice. I wonder if it's possible to add to the current image tags in the channel element?

Either

<itunes:image href="https://podnews.net/static/podnews-2000x2000.png" podcast:primaryColor="#B01212" podcast:secondaryColor="#1d2129" />

or

  <image>
    <url>https://podnews.net/static/podnews-2000x2000.png</url>
    <link>https://podnews.net</link>
    <width>2000</width>
    <height>2000</height>
    <podcast:primaryColor>#B01212</podcast:primaryColor>
    <podcast:secondaryColor>#1d2129</podcast:secondaryColor>
  </image>

(Worthwhile pointing out that the <image> tag there is out of RSS spec - it has a maximum height of 200px, and a maximum width of 144px!!)

Foreground text color could/should be algorithmically generated based on whether white/black has the higher contrast ratio.

I must confess not to know the purpose of the secondary colour above, though?

Finally, you can calculate the primary colour for an image algorithmically. As long as the foreground/background text color is correctly generated, I suspect you could achieve this without requiring any new tags.

[theDanielJLewis]

While I like the idea of putting this in other tags, I think that would invalidate the RSS or undermine some of our goals.

I think one of the ultimate goals of our namespace is to have feature parity with the iTunes namespace, thus allowing app developers to support only a single namespace. So while it might be redundant to have <itunes:image> and <podcast:image>, that might also be the best way to move forward with the open standard.

But it also means inflating the RSS feed. So maybe there should be a way to reduce space if redundancies exist. For example, if <itunes:image> already exists, then <podcast:image> can omit the URL and let the apps fall back to the iTunes tag for the image URL, but get the newer, cooler stuff from the Podcast tag.

[vv01f]

I'd personally prefer the way the picture tag shows in html5, this enables to provide media for different devices and still is more like what people are used to

for the style information providing CSS would enable much more possibilities. the DOM is standardized and thus referencing the desired elements is not a challenge. on the other hand simple, very limited attributes may make it much easier for clients to adopt

[swschilke]

@vv01f What about refering to a CSS file via an URL or having a tag which can enclose a CSS description.

We would have to come up wth, which "objects" we want to support (like Image, Titel, subtitel, body, ...)

[vv01f]

as quite some other information already is segregated I would prefer the extended styling information (as css) to be a separate file.

I am not sure limiting what elements of the feed should be stylable is a good approach at all.

[PofMagicfingers]

Finally, you can calculate the primary colour for an image algorithmically. As long as the foreground/background text color is correctly generated, I suspect you could achieve this without requiring any new tags.

Exactly, we're already doing this at podCloud without any rss tag. We detect the main color of the cover, and determine the text color based ont the luminance of the color.

2 examples : Dark color white text Light color black text

I like the idea of primary and secondary color to declare which color you prefer associated with your podcast (in the same way you can declare what color should the browser UI be for a webapp).

However, I'm not really sure it would be easy to manage for platforms. Either they have to adapt all their UI to work with any colors and that could be complex, either they do not implement it, and podcasters will be disappointed, and we would have a tag with low adoption. :-/

[kookster]

I think this a great direction and idea.

Pretty sure RadioPublic is also doing something like this in their decorations to RSS for podsites. (@cqr ?)

I don't see it in their spec (https://www.radiopublic.com/schema/1.0/) but they add a rp:visualTheme element to the channel, which I believe defined a themeColor, and then accentColor1 and accentColor2 sub elements (also in hex, b/c of course).

<channel>
  <podcast:visualTheme>
    <podcast:themeColor>#B01212</podcast:themeColor>
    <podcast: accentColor1>#B01212</podcast: accentColor1>
    <podcast: accentColor2>#B01212</podcast: accentColor2>
  </podcast:visualTheme>
...    
</channel>

I think having a channel > visualTheme (or some similar name) element to collect this kind of visual info inside makes sense, as a way to organize. I also like the idea of adding subelements rather than attributes, as it's more extensible.

For folks that want this in a separate css file: I can see that too, but that does work best for html/web based rendering, and apps could probably use these colors more easily from the rss.

There is also already a way to include css in an xml doc, such as how feedburner (and many others) use xsl to turn rss -> html, and then style the result with an included css:

<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2enclosuresfull.xsl"?>
<?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?>

[theDanielJLewis]

I don't see the need for a separate CSS file for such little data. Sure, we can put this in the XML stylesheet, but I think app styling would be served best by putting the color(s) in the feed itself. What are developers even interested in supporting? I think all that's necessary is color and maybe a suggested background image/texture.

[vv01f]

@theDanielJLewis that sounds very much like "podcast" is only what we see right now, my thought was more on the line with “let's anticipate more flexibility for future use”. but yes, for the apps we have there hardly is any need for much more than pictures and colors.

[theDanielJLewis]

@vv01f I love thinking outside the podcast box ("podbox"?), and I think that much broader stuff should go in the XML stylesheet. But keep the simple, cleaner podcast-app-specific stuff in the feed.

Sidenote, here's how I would love to support this. The My Podcast Reviews service offers shareable review pages and a smart page that displays rating-and-review links based on the visiting device. Currently, these pages use my brand colors, which often clash with the podcast artwork. We're right about to release a new feature to let our users choose their own branding color, but I would love for this to be automatically detected from the RSS feed (since image-based guesses can sometimes be wrong).

[daveajones]

This is an interesting idea. The font color and family would be good to include as well:

<podcast:styleguide 
  fontColor="#EEEEEE"
  fontFamily="helvetica"
  primaryColor="#FFD000" 
  secondaryColor="#111111" 
  />

[theDanielJLewis]

Font-family is interesting, but I think it might lead to more problems than it's worth. Consider:

1. If on a website, is every podcast expected to display with its own font?
2. How will commercial fonts (such as purchased or Adobe Fonts) work?
3. How will an app developer know whether the font is even readable within their app or at the font size?
4. Loading a different font for every podcast results in a lot of extra bandwidth.

[agates]

I think styling's great -- best to try to avoid some of the mistakes seen elsewhere.

Further reading from the linux world: App Devs Ask Linux Distros to “Stop Theming Our Apps” Please don’t theme our apps

Sort of the debate between system themes vs branding.

[daveajones]

I wonder if @nathangathright has any input here.

[cqr]

I'm wading in because I was summoned - thanks @kookster.

There's not a ton of risk to including data here - it's ultimately a hint to the app which it can choose to ignore or honor. For that reason, I don't really see the parallel to the "Don't theme our app" argument - that's primarily a story about designers being robbed of agency rather than giving creators the ability to make requests.

That said, from my perspective the font-family & font color is very unlikely to be used in any products I work on / have worked on - I don't know if that's true for other folks who work on the RSS consumption side rather than publishing side, but I think every designer I have ever worked with would have a panic attack if I told them that supporting arbitrary fonts was a requirement.

One thing I would love to see is an SVG knockout, which I could badge on top of other visual elements using the colors provided. Let me know if that needs more clarification.

[scottmathson]

Finally, you can calculate the primary colour for an image algorithmically. As long as the foreground/background text color is correctly generated, I suspect you could achieve this without requiring any new tags.

Exactly, we're already doing this at podCloud without any rss tag. We detect the main color of the cover, and determine the text color based ont the luminance of the color.

2 examples : Dark color white text Light color black text

I like the idea of primary and secondary color to declare which color you prefer associated with your podcast (in the same way you can declare what color should the browser UI be for a webapp).

However, I'm not really sure it would be easy to manage for platforms. Either they have to adapt all their UI to work with any colors and that could be complex, either they do not implement it, and podcasters will be disappointed, and we would have a tag with low adoption. :-/

Absolutely agree @PofMagicfingers, this programmatically generated sourcing of colors is one of the reasons I'd considered not posting proposal.

As you've done, Stitcher is also now doing (or at least surfacing in their new internal API), yet I think for those that are just wanting to do some subtle changes (think buttons, link hover-state colors, etc) to compliment the podcast's styleguide and brand, without having to create a microservice to do so, this then makes sense.

[scottmathson]

Here's that Stitcher API response, referenced above https://github.com/Podcastindex-org/podcast-namespace/issues/194#issuecomment-784505538 - see color_primary (yet it's not 100% accurate, either and is just one color).

[scottmathson]

Of course taking this a step beyond the proposed color hex codes, adopting primary and secondary typeface/font attributes would provide even more styleguide consistency. https://github.com/Podcastindex-org/podcast-namespace/issues/194#issue-812938588

(fonts also mentioned here https://github.com/Podcastindex-org/podcast-namespace/issues/194#issuecomment-783806015 and here https://github.com/Podcastindex-org/podcast-namespace/issues/194#issuecomment-783812439)

Of course the typeface/font family support would be pretty ideal for generating completely boutique, on-brand pages for podcasters at-scale, as mentioned and discussed above. Yet I agree that we're unlikely to see wide-spread adoption of this from the start. Though I'm envisioning services like Podpage would be quite interested (@bmull you active here?) in color information at the very least. Not to mention the many hosting providers who generate websites for their customers (/cc @mattbasta @jonbuda).

I can speak first-hand from my perspective as the creator of Plink, that I'd find value in this color scheme/other styleguide data being available at the RSS level. Then again, I take the approach of automatically generating a ready-to-go service (smart links/landing pages, in this example) versus having to onboard customers through a lengthy process they then have to spend time getting setup in (WYSIWYG env). I do offer customization settings and third-party integrations, but for those who don't want to mess with that, it's ready to go right away. I also imagine Nathan/Team at Podsights (tagged above) would be interested in this for pod.link customization, too.

That said, from my perspective the font-family & font color is very unlikely to be used in any products I work on / have worked on - I don't know if that's true for other folks who work on the RSS consumption side rather than publishing side, but I think every designer I have ever worked with would have a panic attack if I told them that supporting arbitrary fonts was a requirement. https://github.com/Podcastindex-org/podcast-namespace/issues/194#issuecomment-784399859

Lastly, as you said @cqr, supporting this wouldn't even be considered within certain teams. Though it may not make sense in RadioPublic's apps, I'm curious to hear your thoughts around utilizing <podcast:styleguide> in RP services like Podsite.

[cqr]

@scottmathson speaking mostly hypothetically, I could very easily see using some of the tags that have been proposed. My position on the font-family and font-color mostly stand on a practical basis, even in the context of product like Podsite (the headaches are numerous) but we already do support providing theme colors via RSS for Podsite - @kookster outed us a little upthread.

[nathangathright]

Thanks for the mention, @daveajones & @scottmathson. At Podsights, we just added theming to pod.link landing pages. So I have some recent observations that might be helpful. Here's what we build:

For our use case, the fewest number of color values I felt we could get away with was 4 to give the podcaster the level of customization we were going for. That really limited my options with the design, but we wanted to keep it as simple as possible for the podcaster. When trying to convey how each color would be used, having a live preview was invaluable. Obviously, in an RSS context intented for multiple parties to interpret the theme multiple ways, that's not going to be possible.

My recommendation would be a <podcast:themeColor>#B01212</podcast:themeColor> tag, similar to the existing theme-color meta tag, and follow the podCloud approach to theming. It should exist at the channel and item level to account for episode-specific artwork that might clash with the show-level theme.

Limiting it to a single color has a number of advantages:

• doesn't get too prescriptive
• simpler for podcasters to select without requiring the context of how N accent colors might be used in N different platforms
• simpler for hosts to implement in their UI (maybe even default to the dominant color in the show artwork)
• simpler for platforms to incorporate in the way that makes the most sense for their context

[keunes]

Side note from technical discussion: in addition to colours, as an app user I think I'd appreciate a 'header' or 'banner' image that's different from the cover icon. Could make podcast pages a bit more interesting than your usual colour or repeated cover image. It should be expected that a blur is applied, though, for 'readability' of other elements.

[Tombarr]

Looks like this conversation stalled, but as the developer of PodLP I support this idea. The back-end downloads images (and check periodically for updates) to compute the primary color, then returns that to the client to update styles (header bar, range scrubber, etc). It would save compute time & money, plus make selection more accurate/ reproducible for podcasters, if this could be specified.

Another idea would be to adopt a format similar to Android layouts, i.e.

<podcast:style name="theme">
    <item name="textSize">20px</item>
    <item name="primaryColor">#B01212</item>
</podcast:style>

I would avoid XML stylesheets since they require a complex parser and it would present significant risk/ be blocked by content security policies for apps or websites to inject cross-domain code like that.

[kookster]

+1 I still think this something like this is valuable - for example, we provide parameter based overrides for the colors on our embed player (and I doubt we're alone on that); this would be better.

[scottmathson]

Still +1 on this of course, too 🙂